Nabble - GENI Substrate WG

DRAFT agenda for Substrate WG meeting at GEC5

2009-07-14T12:32:48Z

(I'm the new Substrate WG system engineer here at the GPO)

GENI Substrate WG Members, and interested GENI participants,

GEC5 will be held in Seattle:
From Monday 7/20 1pm, through Wednesday 7/22 12:30pm.

The Substrate Working Group will meet:
Tuesday 7/21 3:30pm - 5:30pm

The DRAFT agenda includes:

1) Welcome
Joe Evans and Patrick Crowley, Substrate WG co-chairs

2) Review of recent vertical and horizontal integration examples:

a) ORCA integration with BEN, including cross layer setup in
BEN, and setup of
VLANs through BEN and NLR (stitching)
Yufeng Xin, RENCI

b) ORBIT (OMF) integration with a WiMAX base station into
ORBIT
(vertical integration) and plans to connect WINLAB and NICTA sites via
I2, etc.
(horizontal integration)
Ray Raychaudhuri, WINLAB/Rutgers

(others pending)

3) Evolution of the substrate working group charter, and future of
substrate catalog
Joe Evans and Patrick Crowley

4) Introduction of new co-chair(s), effective GEC6.
Joe Evans and Patrick Crowley

5) Wrapup and review of action items
WG Systems Engineer

Are there other topics you would like to see discussed?

We hope to see you all in Seattle!

Sincerely,

Harry E. Mussman
Substrate WG Systems Engineer

GENI Project Office
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
(617) 873-4282 - Office
(781) 266-8479 - Mobile
(617) 873-4888 - Fax
hmussman@...
www.bbn.com

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

Embedded Real-Time Measurements within GENI

2009-06-01T06:25:10Z

The project group working on "Embedded Real-Time Measurements within
GENI" would like to announce the completion of Milestone 4
(http://groups.geni.net/geni/wiki/Embedded%20Real-Time%20Measurements)
and invite all interested parties to provide comments.

This milestone deals with the development of a measurement framework
based on GENI real-time measurement requirements and other
developments/resources within the GENI prototyping activities.
Interacting with other prototype efforts, we identify and leverage
relevant activities, software architectures, protocols, and products.
This work deals with a number of software architectures dedicated to
network measurements which could serve as an interface between a
unified measurement framework (UMF), the control framework, and the
GENI experimenter. We assess several network management protocols and
data exchange formats with respect to their ability of exchanging
measurement and control information between the substrate's
performance monitors and the UMF, as well as between the UMF and the
GENI control frameworks.

Thank you and best regards
Franz Fidler, Caroline Lai, Keren Bergman

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

GEC-4 substrate working group plans - seeking presentations

2009-03-05T06:41:02Z

The substrate working group chairs and systems engineer are planning the
agenda for GEC4 and are now seeking volunteers from the GENI community
to present ideas and implementations on the topic of vertical
integration. Within the context of GENI, vertical integration defines
the software interfaces between substrate components or aggregates and
the component/aggregate manager of the control framework. This
discussion will be divided into two categories, the first is based on
specific implementations of these interfaces appearing in spiral-1
prototyping activities. The second category is a more general discussion
on a forward looking GENI design based on unification (generalization)
of interfaces for similar types of GENI resources (i.e. ethernet
switches, programmable routers, wireless access, optical switches,
processor clusters, etc.)

Category 1. As spiral-1 integration is well under way, we are now in a
position to learn about specific integration solutions. The spiral-1
projects are working to meet specific milestones with aggressive
schedules in order to realize an operational GENI prototype within the
next several months. As such, this discussion is intended to provided a
basis for real-world GENI integration, and is not for critiquing
solutions or to suggest additional tasks. Each spiral 1 substrate
project is focussed on the interfaces required to get their specific
aggregates integrated into their cluster's control framework to satisfy
the primary goal of realizing an operational GENI prototype in year one.

If you are part of a spiral-1 substrate project (i.e. listed in the
spiral-1 substrate catalog) please let us know if you can brief the
working group session on your designs and requirements regarding
vertical integration into your cluster's control framework.

Category 2. Looking forward towards the "GENI design" we would like to
open a community wide discussion on the topic of generalized interfaces.
In a simple model, vertical integration through an aggregate manager can
be viewed as a top layer (technology independent) abstraction belonging
to a specific control framework implementation defining how resources
are controlled. A lower layer is then necessary to translate the control
messages between the abstraction layer and very specific (technology
dependent) substrate components. It is believed that specific low layer
integration code will always be required as interfaces to networking
and compute resources are make, model and version specific. However, the
question to be discussed in this category is whether an intermediate
interface can be defined which is general to all networking and compute
resources of the same type. For example, can all ethernet switches (HP
Procurve 5400, Raptor ER 1010e, Netgear GSM7224, Juniper Ex 3200)
providing programmable VLAN topologies and bandwidth integrate
vertically through a common, generalized interface? The same question
applies to all substrate technologies of the same type (i.e. all optical
switches, all wireless access, etc.), offering the same resources. The
intent of this discussion is to layout plans for subsequent working
group activity on specifying generalized interfaces for all substrate
aggregate and component types. These specifications will be captured in
a document per our stated working group deliverables.

As a member of the GENI community, if you have ideas regarding
generalized (unified) interfaces, we would like you to present those
ideas during the substrate working group session.

We would like to have 2-3 presentations (15-20 minutes) for each
category. Please let us know within the next week if you are willing to
accept this invitation.

Thanks
John Jacob (Systems Engineer)
Joe Evans, Peter O'Neil, and Patrick Crowley (Substrate working group
chairs)

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

Substrate working group deliverable - Spiral one substrate catalog (draft)

2009-01-05T11:26:33Z

To: GENI developers and Substrate Working Group members,

An initial draft catalog of substrate technologies funded through spiral
1 can be found on the deliverables wiki page for the substrate working
group: http://groups.geni.net/geni/wiki/DeliverablePage
Input to this catalog was requested from all of the substrate providers
funded in spiral 1 as discussed at GEC3. If you believe that your GENI
spiral 1 project should be included in this catalog, please provide the
requested information discussed in section 4.

If you are currently a spiral 1 substrate provider listed in a section
of this document, please note that the current version of this draft is
inconsistent across the spiral-1 projects, and in some instances is
incomplete or absent of information. It is my near term goal to achieve
a level of consistency and completeness across all the spiral 1 projects
providing substrates for GENI resources (i.e. components and aggregates
registered with a prototype GENI clearinghouse). Please review the
project sections (5 thru 20) and plan to modify your contribution
towards meeting this goal. I encourage all recipients of this email to
use the substrate working group mailing list to discuss the baseline
level of information we should expect from each project.

I am also requesting that all recipients of this email read chapters
three and four which discusses the scope and rationale for the cataloged
information. I would also like to see comments and discussions regarding
these sections posted to the substrate working group mailing list.

Thank you,
John Jacob, GENI Substrate Systems Engineer

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

Re: GENI IP space?

2008-12-01T14:01:47Z

I made a comment along these lines at the microphone at GEC3.

The general problem is that if GENI uses a slice of address space "borrowed"
from an ongoing production network, then GENI potentially exposes the owner of
the address space to churn caused by defective or erratic routing
announcements.

As I noted at the mic everyone attached to GENI will be happy as long as GENI
has some other IP address space, but nobody will want to share addresses with
GENI.

I suggest another option, that is solicit the wider community for unused
address space that is disjoint from current production announcements, or can
otherwise tolerate potential churn caused by GENI. NLR may have space too.

How much space does GENI need? We certainly have unused class C's from the
swamp that are available. They should be fine in the global R&E Internet, but
may be blocked by some commercial and International ISPs. We may also be able
to find some other larger blocks... How much space does GENI need and for how
long?

Thanks,
--MM--
-------------------------------------------
Matt Mathis http://staff.psc.edu/mathis
Work:412.268.3319 Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

On Mon, 1 Dec 2008, Aaron Falk wrote:

> Hi Joe-
>
> I agree this is a broad topic and am cc'ing the wg list.
>
> Can you expand more on why "Options (1) and (2) will not support
> independent routing policies"? I can see that the campus would need
> to cooperate on developing GENI-needed policies. Is that what you
> meant?
>
> We do plan to get some addresses from ARIN, although not for every
> GENI component. There is no timeline yet. Our assumption has been
> that, in general, if you were deploying something you would provide
> addresses for it (your 'option 1' below) and we would assist you to
> work with your IT dept on getting appropriate policies in place.
> Perhaps this is simple-minded, but if it won't work it I'd like to
> understand why.
>
> I think the goal of collecting parameters we need to register is a
> good one. Is there anything other than IP addresses and AS numbers?
>
> --aaron
>
> On Dec 1, 2008, at 3:42 PM, Joseph B. Evans wrote:
>
>> Aaron:
>> GpENI is going to need IP space for its control and management
>> plane, and perhaps for parts of the data path as well. I assume
>> projects in other clusters are going to come up against this as well.
>>
>> GpENI is looking into a few options, (1) using KU or KANREN space,
>> (2) using Internet2 space, (3) getting GpENI space from ARIN, or (4)
>> getting space through a coordinated request to ARIN from the GPO.
>> Note that eventually, we will also likely want to have at least one
>> AS number for GENI. Options (1) and (2) will not support
>> independent routing policies, and (3) is unlikely to be successful.
>>
>> So the question is, is the GPO pursuing IP space for the whole of
>> GENI, and if so, what is the timeline? If not, well, I'd recommend
>> that it should.
>>
>> There is some urgency to this, since renumbering will be
>> increasingly irritating as the systems grow.
>>
>> I've copied the Substrate WG co-chairs because I think this is a
>> general substrate issue.
>>
>> Cheers,
>> Joe
>>
>> ---
>> Joseph B. Evans, Ph.D. <evans@...>
>> Distinguished Professor, Electrical Engineering & Computer Science
>> Director, Information & Telecommunications Technology Center
>> University of Kansas
>>
>
>
> _______________________________________________
> substrate-wg mailing list
> substrate-wg@...
> http://lists.geni.net/mailman/listinfo/substrate-wg
>

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

Re: GENI IP space?

2008-12-01T13:07:17Z

Hi Joe-

I agree this is a broad topic and am cc'ing the wg list.

Can you expand more on why "Options (1) and (2) will not support
independent routing policies"? I can see that the campus would need
to cooperate on developing GENI-needed policies. Is that what you
meant?

We do plan to get some addresses from ARIN, although not for every
GENI component. There is no timeline yet. Our assumption has been
that, in general, if you were deploying something you would provide
addresses for it (your 'option 1' below) and we would assist you to
work with your IT dept on getting appropriate policies in place.
Perhaps this is simple-minded, but if it won't work it I'd like to
understand why.

I think the goal of collecting parameters we need to register is a
good one. Is there anything other than IP addresses and AS numbers?

--aaron

On Dec 1, 2008, at 3:42 PM, Joseph B. Evans wrote:

> Aaron:
> GpENI is going to need IP space for its control and management
> plane, and perhaps for parts of the data path as well. I assume
> projects in other clusters are going to come up against this as well.
>
> GpENI is looking into a few options, (1) using KU or KANREN space,
> (2) using Internet2 space, (3) getting GpENI space from ARIN, or (4)
> getting space through a coordinated request to ARIN from the GPO.
> Note that eventually, we will also likely want to have at least one
> AS number for GENI. Options (1) and (2) will not support
> independent routing policies, and (3) is unlikely to be successful.
>
> So the question is, is the GPO pursuing IP space for the whole of
> GENI, and if so, what is the timeline? If not, well, I'd recommend
> that it should.
>
> There is some urgency to this, since renumbering will be
> increasingly irritating as the systems grow.
>
> I've copied the Substrate WG co-chairs because I think this is a
> general substrate issue.
>
> Cheers,
> Joe
>
> ---
> Joseph B. Evans, Ph.D. <evans@...>
> Distinguished Professor, Electrical Engineering & Computer Science
> Director, Information & Telecommunications Technology Center
> University of Kansas
>

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

Re: GENI Spiral 1 Substrate infrastructure catalog

2008-11-25T07:00:23Z

Dear PI's.

I have received input from half of the projects listed below. I will
review this information over the next few days and will get back to you
with any questions. Thank you for your on-time response. For the other
projects, please try to get this information to me as soon as possible.

Thank you,
John Jacob

John Jacob wrote:

> Dear PI's,
>
> I would like to follow-up on a discussion from our recent substrate
> working group session at GEC#3. As the substrate systems engineer, I
> am working to catalog a broad set of technical details pertaining to
> the spiral-1 substrate infrastructure. If your name and project
> appears in the list below, it is because I believe that you are
> contributing substrate infrastructure to GENI spiral-1 as part of your
> project. As such, I am requesting some information from you. I would
> like to have your initial response no later than Monday, Nov 24. If
> you feel that your project either does not belong on this list or has
> been omitted please notify me as soon as possible. Please note that a
> copy of this email has been sent to the substrate-wg mailing list.
>
> Enterprise GENI - Nick McKeown
> GpENI - James Sterbenz
> Mid-Atlantic Crossroads - Peter O'Neill
> ORCA/BEN - Ilia Baldine
> Measurement System - Paul Barford
> CMU Testbeds - David Anderson
> Vehicular Mobile Testbed - Brian Levine
> Sensor/Actuator Network - Jim Kurose
> Kansei Sensor Network - Anish Arora
> Orbit Framework - Marco Gruteser
> WiMAX - Dipankar Raychaudhuri
> ProtoGENI - Robert Ricci
> PlanetLab - Larry Peterson
> DETER Trial Integration - John Wroclawski
> SPP Overlay Hosting Nodes - Jon Turner
> Programmable Edge Node - Yan Luo
>
> The following is a general list of topics I plan to cover in the
> Spiral 1 substrate capabilities catalog. There may be topic areas
> which cannot be addressed at this time. Please respond to the extent
> you know the information, note any caveats, and let me know which
> topics do not apply. If some of this information is available on web
> sites you maintain or found in existing documentation, please point me
> to that information and I will extract the necessary information. All
> collected information will be compiled into an MS Word document and
> will also appear on each of your GPO established project wiki pages.
> As information changes, you are encouraged to keep the GPO informed
> and I will keep the document up-to-date.
>
> 1. Provide an overview of the hardware systems in your contribution.
> 2. Discuss the GENI resources offered by your substrate contribution,
> and how they are shared, programmed, and/or configured. Include in
> this discussion to what extent you believe the shared resources can be
> isolated.
> 3. Provide an overview of the physical connections within the
> substrate aggregate, as well as between the aggregate and the GENI
> backbones. Identify to the extent possible, non-GENI equipment,
> services and networks involved in these connections.
> 4. Identify the physical connections and software interfaces for
> integration into your cluster's assigned control framework
> 5. Identify any measurement capabilities, either embedded in your
> substrate components or as dedicated external test equipment.
> 6. Describe any tools or services which may be available to users and
> unique to your substrate contribution.
>
> Please do not hesitate to ask for clarification on any of these items.
>
> Thanks
> John
> -------------------------------------------------
> John Jacob
> GENI Substrate Systems Engineer
> BBN Technologies
> 10 Moulton St
> Cambridge, MA 02138
>
> tel. 617-873-8031
> email jjacob@...
> -------------------------------------------------
>

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

GENI Spiral 1 Substrate infrastructure catalog

2008-11-11T04:22:25Z

Dear PI's,

I would like to follow-up on a discussion from our recent substrate
working group session at GEC#3. As the substrate systems engineer, I am
working to catalog a broad set of technical details pertaining to the
spiral-1 substrate infrastructure. If your name and project appears in
the list below, it is because I believe that you are contributing
substrate infrastructure to GENI spiral-1 as part of your project. As
such, I am requesting some information from you. I would like to have
your initial response no later than Monday, Nov 24. If you feel that
your project either does not belong on this list or has been omitted
please notify me as soon as possible. Please note that a copy of this
email has been sent to the substrate-wg mailing list.

Enterprise GENI - Nick McKeown
GpENI - James Sterbenz
Mid-Atlantic Crossroads - Peter O'Neill
ORCA/BEN - Ilia Baldine
Measurement System - Paul Barford
CMU Testbeds - David Anderson
Vehicular Mobile Testbed - Brian Levine
Sensor/Actuator Network - Jim Kurose
Kansei Sensor Network - Anish Arora
Orbit Framework - Marco Gruteser
WiMAX - Dipankar Raychaudhuri
ProtoGENI - Robert Ricci
PlanetLab - Larry Peterson
DETER Trial Integration - John Wroclawski
SPP Overlay Hosting Nodes - Jon Turner
Programmable Edge Node - Yan Luo

The following is a general list of topics I plan to cover in the Spiral
1 substrate capabilities catalog. There may be topic areas which cannot
be addressed at this time. Please respond to the extent you know the
information, note any caveats, and let me know which topics do not
apply. If some of this information is available on web sites you
maintain or found in existing documentation, please point me to that
information and I will extract the necessary information. All collected
information will be compiled into an MS Word document and will also
appear on each of your GPO established project wiki pages. As
information changes, you are encouraged to keep the GPO informed and I
will keep the document up-to-date.

1. Provide an overview of the hardware systems in your contribution.
2. Discuss the GENI resources offered by your substrate contribution,
and how they are shared, programmed, and/or configured. Include in this
discussion to what extent you believe the shared resources can be isolated.
3. Provide an overview of the physical connections within the substrate
aggregate, as well as between the aggregate and the GENI backbones.
Identify to the extent possible, non-GENI equipment, services and
networks involved in these connections.
4. Identify the physical connections and software interfaces for
integration into your cluster's assigned control framework
5. Identify any measurement capabilities, either embedded in your
substrate components or as dedicated external test equipment.
6. Describe any tools or services which may be available to users and
unique to your substrate contribution.

Please do not hesitate to ask for clarification on any of these items.

Thanks
John
-------------------------------------------------
John Jacob
GENI Substrate Systems Engineer
BBN Technologies
10 Moulton St
Cambridge, MA 02138

tel. 617-873-8031
email jjacob@...
-------------------------------------------------

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

Lightning talks at GEC-3

2008-10-21T09:52:36Z

Dear Substrate WG members,

At GEC-3 next week, there will be a substrate working group session on
Wednesday from 2pm to 5pm. The session agenda will include:

* a WG overview,

* presentations from 5 Spiral-1 PIs with substrate-related projects,

* a discussion of the substrate-wg Spiral 1 document, and the
contributions needed from Spiral 1 projects, and

* a series of lightning talks from folks who have substrate-related
opinions to offer or who have substrate components to contribute in
future spirals.

If you wish to give a 5-10 minute lightning talk, either to describe a
substrate you would like to propose in a future spiral or to offer an
opinion related to the GENI substrate, please let us know via email (to
pcrowley@...), as soon as you can. Lightning talks can be as
(in)formal as you like, with or without a prepared presentation.

All are welcome, but we are particularly interested in hearing from
those not part of a Spiral 1 project.

Sincerely,
Patrick Crowley
on behalf of my fellow substrate working group chairs Joe Evans and
Peter O'Neil

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

smime.p7s (4K) Download Attachment

it's time to register for GEC3

2008-09-03T13:26:21Z

Folks-

If you are planning to attend, please register for the GEC3 meeting
ASAP.

Registration site: http://www.edjassociates.com/geni3

Agenda: http://www.geni.net/GEC3/agenda.html

Thanks,

--aaron

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

Re: Rural heath Care

2008-04-30T06:34:28Z

Geoff,

I have forwarded your message to Aaron Falk, with a copy to Chip Elliott and Henry Yeh. They are the appropriate contacts for this type of inquiry.

Kristin

On Apr 29, 2008, at 12:46 PM, Roberts, Geoffrey P wrote:

Who in GENI is looking at federating with other high level initiatives, specially the Rural Heathcare Initiative which is one of the few programs that could potentially be leveraged to give GENI the experimental testbed reach it needs. That is they are funding network down to the clinic/small community.

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

********************************************

Kristin Rauschenbach

Technical Director of Optical Networking

BBN Technologies

krausche@...

617-873-8005

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

Rural heath Care

2008-04-29T09:46:15Z

Who in GENI is looking at federating with other high level initiatives, specially the Rural Heathcare Initiative which is one of the few programs that could potentially be leveraged to give GENI the experimental testbed reach it needs. That is they are funding network down to the clinic/small community.

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

Re: Sample Resource Specifications forSubstrate Components

2008-04-28T05:37:49Z

I am concerned with the complexity added by including some advertisement
and then guarantee of isolation. The idea of simply 'shared/not shared'
makes a lot of sense to me. With just this information, the designer of
the experiment will then be able to craft the trial in such a way that
provides the level of resource guarantees she needs without pushing this
complexity down into the Substrate infrastructure.

What we may want to think about is what we mean by "best effort"
sharing. For example, is it an average resource availability over some
long time period or is it a peak availability of that resource? Having,
at least as a target, a common view of what form sharing will take will
make experiment designers' tasks easier. If we allow every type of
sliceable resource to have its own type of "best effort" we will need a
much more elaborate advertising scheme than 'shared/not shared' and the
task of experiment design will require detailed Substrate network
engineering expertise beyond what should be required of a 'user'.

-Stu Elby
Verizon

-----Original Message-----
From: substrate-wg-bounces@...
[mailto:substrate-wg-bounces@...] On Behalf Of Heidi Picher Dempsey
Sent: Thursday, April 24, 2008 11:57 AM
To: John Jacob
Cc: Substrate-WG@...; Ted Faber
Subject: Re: [substrate-wg] Sample Resource Specifications forSubstrate
Components

On Apr 24, 2008, at 8:08 AM, John Jacob wrote:

> Ted Faber wrote:
>> On Tue, Apr 22, 2008 at 03:23:56PM -0400, John Jacob wrote:
>>
>>> Ted,
>>>
>>> Yes, this is the issue I was getting at. The basic question is how
>>> to identify slicing granularity, and possibly isolation, in an
>>> Rspec. You captured the issue well. I agree that there will be many
>>> ways to slice the diverse substrate technologies as well as
>>> different ways to slice similar substrate technologies, which is one

>>> of the reason we might want to advertise the granularity. In a
>>> similar manner, two similar resources with similar slice
>>> granularities may have different isolation properties, which is
>>> something else we might need to consider in an advertisement of a
>>> resource. On this latter point, is isolation a prerequisite for
>>> slicing, or can a resource be sliced with different degrees of
>>> isolation?
>>>
>>
>> People have certainly put forth the idea of allocating resources as
>> "best effort," which sounds a lot like "with minimal isolation" to
>> me.
>> It's a little tough to think of isolation in terms other than "as
>> complete as we can make it" and "no guarantees," though. Are you
>> thinking of a scale that's more experessive than that?
>>
>
> Ted,
>
> I am not thinking of a specific scale, I am just wondering if some
> information regarding the isolation of a shared resource has a place

> in the RSpecs.
>
> John

From a practical point of view, I think I would want to know whether I
had all or part of a resource in my slice in some cases, because some
techniques for sharing might be more likely to always work than others.
For example, getting an entire node dedicated to me might be virtually
"guaranteed" in the sense used previously in this message, but getting a
certain amount of bandwidth on an experimental router that was using
priority queuing might not be. I wouldn't expect the RSPEC to give me
any scale of how "shared" it was, but a shared/not shared bit could be
useful for debugging.

>
>
> _______________________________________________
> substrate-wg mailing list
> substrate-wg@...
> http://lists.geni.net/mailman/listinfo/substrate-wg

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

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

Re: Sample Resource Specifications for Substrate Components

2008-04-25T01:38:53Z

> > So by sliceable you mean virtualizable? If I hand you exclusive
> > control of a resource I haven't sliced it?

> When I use the term sliceable I mean shareable. Virtualization is a
> technique for sharing but there are others.

Let's distinguish between a single resource and a set of resources
(perhaps represented as an aggregate component). Eg, a single Mica2
sensor mote won't be simultaneously shareable by multiple slices.
However, a set of motes clearly can be space-shared.

In general, when we refer to "a resource" in GENI, we've been
referring to a single physical entity, not a set of them.
And that affects the kind of sharing possible on a single resource.

That doesn't mean we can't clarify the docs and explicitly address
sets of resources.

Just trying for clarity...

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

Re: Sample Resource Specifications for Substrate Components

2008-04-24T08:57:07Z

On Apr 24, 2008, at 8:08 AM, John Jacob wrote:

> Ted Faber wrote:
>> On Tue, Apr 22, 2008 at 03:23:56PM -0400, John Jacob wrote:
>>
>>> Ted,
>>>
>>> Yes, this is the issue I was getting at. The basic question is how
>>> to
>>> identify slicing granularity, and possibly isolation, in an
>>> Rspec. You
>>> captured the issue well. I agree that there will be many ways to
>>> slice
>>> the diverse substrate technologies as well as different ways to
>>> slice
>>> similar substrate technologies, which is one of the reason we
>>> might want
>>> to advertise the granularity. In a similar manner, two similar
>>> resources
>>> with similar slice granularities may have different isolation
>>> properties, which is something else we might need to consider in an
>>> advertisement of a resource. On this latter point, is isolation a
>>> prerequisite for slicing, or can a resource be sliced with different
>>> degrees of isolation?
>>>
>>
>> People have certainly put forth the idea of allocating resources as
>> "best effort," which sounds a lot like "with minimal isolation" to
>> me.
>> It's a little tough to think of isolation in terms other than "as
>> complete as we can make it" and "no guarantees," though. Are you
>> thinking of a scale that's more experessive than that?
>>
>
> Ted,
>
> I am not thinking of a specific scale, I am just wondering if some
> information regarding the isolation of a shared resource has a place
> in the RSpecs.
>
> John

From a practical point of view, I think I would want to know whether
I had all or part of a resource in my slice in some cases, because
some techniques for sharing might be more likely to always work than
others. For example, getting an entire node dedicated to me might be
virtually "guaranteed" in the sense used previously in this message,
but getting a certain amount of bandwidth on an experimental router
that was using priority queuing might not be. I wouldn't expect the
RSPEC to give me any scale of how "shared" it was, but a shared/not
shared bit could be useful for debugging.

>
>
> _______________________________________________
> substrate-wg mailing list
> substrate-wg@...
> http://lists.geni.net/mailman/listinfo/substrate-wg

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

Re: Sample Resource Specifications for Substrate Components

2008-04-24T06:15:39Z

On my way into work, I was thinking more about a variation of your
question. Lets say the device has 2x1Gb plus 4x100Mb links. A user has
a need for 8x100Mb links as a virtual switch. If the device is not
sliceable, it cannot satisfy this request. Assuming it can slice, the
device has multiple ways of satisfying this request, including
allocating all 4 as slices from the same single 1Gb link. The
constraints on which links can be used will fall to connectivity on the
other side of those links.

So how would the device advertise it's resources? Somewhere the user
must be able to discern that "the device can support up to 24x100Mb
links" and in addition "the device can support up to 2 1Gb links". They
can't *all* be satisfied at the same time, but they represent the
capability.

My primary concern is that an RSpec for the 1Gb link stating it can be
sliced to 10Mb granularity then puts the work elsewhere divide up the
link to determine just how many links it can support. This may be
necessary if the granularity is highly variable (ie. in 10Mb chunks).

It seems there is room in the gray area between the RSpec and the end
user that does this calculation such that the user

As such it seems there is need for a third parameter indicating the
upper bound on how much the link can be split. I.e, [1Gb - 100Mb, in
10Mb gran, max 8 virtual links].

...cj

On Thu, 2008-04-24 at 07:47 -0400, John Jacob wrote:

> Christopher White wrote:
> > For example, take a 1Gb Ethernet link. The RSpec might
> > advertise the set [1GB, 100Mb, 10Mb]. If the user asks for 100Mb, the
> > device must slice the link to satisfy it.
> >
> > ...cj
> >
> >
> Chris,
>
> I agree with this, but it was not clear to me that the two examples
> which started this discussion included a set of resources divided in
> this way. If I take your example above, and apply what we had in the
> two worked examples, the Rspec for this case would only list the 1GB
> link. Rephrasing the original question being asked, shouldn't the Rspec
> also list 100Mb and 10Mb, where the 10Mb is the slicing granularity?
>
> John
>

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

Re: Sample Resource Specifications for Substrate Components

2008-04-24T05:08:27Z

Ted Faber wrote:

> On Tue, Apr 22, 2008 at 03:23:56PM -0400, John Jacob wrote:
>
>> Ted,
>>
>> Yes, this is the issue I was getting at. The basic question is how to
>> identify slicing granularity, and possibly isolation, in an Rspec. You
>> captured the issue well. I agree that there will be many ways to slice
>> the diverse substrate technologies as well as different ways to slice
>> similar substrate technologies, which is one of the reason we might want
>> to advertise the granularity. In a similar manner, two similar resources
>> with similar slice granularities may have different isolation
>> properties, which is something else we might need to consider in an
>> advertisement of a resource. On this latter point, is isolation a
>> prerequisite for slicing, or can a resource be sliced with different
>> degrees of isolation?
>>
>
> People have certainly put forth the idea of allocating resources as
> "best effort," which sounds a lot like "with minimal isolation" to me.
> It's a little tough to think of isolation in terms other than "as
> complete as we can make it" and "no guarantees," though. Are you
> thinking of a scale that's more experessive than that?
>

Ted,

I am not thinking of a specific scale, I am just wondering if some
information regarding the isolation of a shared resource has a place
in the RSpecs.

John

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

Re: Sample Resource Specifications for Substrate Components

2008-04-24T05:08:18Z

On Apr 24, 2008, at 4:09 AM, Ted Faber wrote:
>> But via your many examples it seems that your "sliceable" has now
>> lost all its semantics.
>
> So by sliceable you mean virtualizable? If I hand you exclusive
> control
> of a resource I haven't sliced it?

When I use the term sliceable I mean shareable. Virtualization is a
technique for sharing but there are others.

--aaron

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

Re: Sample Resource Specifications for Substrate Components

2008-04-24T04:47:56Z

Christopher White wrote:
> For example, take a 1Gb Ethernet link. The RSpec might
> advertise the set [1GB, 100Mb, 10Mb]. If the user asks for 100Mb, the
> device must slice the link to satisfy it.
>
> ...cj
>
>
Chris,

I agree with this, but it was not clear to me that the two examples
which started this discussion included a set of resources divided in
this way. If I take your example above, and apply what we had in the
two worked examples, the Rspec for this case would only list the 1GB
link. Rephrasing the original question being asked, shouldn't the Rspec
also list 100Mb and 10Mb, where the 10Mb is the slicing granularity?

John

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

Re: Sample Resource Specifications for Substrate Components

2008-04-24T04:33:21Z

On Tue, 2008-04-22 at 17:58 -0700, Ted Faber wrote:
> Slicable doesn't necessarily mean programmable to me. If I'm allocated
> half the capacity of a link, that doesn't mean I get to program the
> controller, but the link's been sliced.

I think of an experimenter looking at RSpecs as the list of what is
available for reservation. The fact that the device advertising the
RSpec must slice an underlying device to achieve a reservation is an
implementation detail.

It seems much like a newspaper offering advertising space. You can
purchase advertisements of multiple sizes (1 inch, 1 column, 1/4 page,
etc.) As someone purchasing ad space, I don't care what the ultimate ad
capacity of the entire paper is, nor how many ways that capacity can be
chopped up, I only care what sizes are available for me to purchase.

As such, the RSpec should define the bounds possible for a single
reservation, but the fact that it's a slice of something larger is less
interesting. For example, take a 1Gb Ethernet link. The RSpec might
advertise the set [1GB, 100Mb, 10Mb]. If the user asks for 100Mb, the
device must slice the link to satisfy it.

...cj

--
Christopher J. White
cwhite@...
Principal Software Engineer
Mazu Networks

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

Re: Sample Resource Specifications for Substrate Components

2008-04-23T22:58:41Z

> So by sliceable you mean virtualizable? If I hand you exclusive control
> of a resource I haven't sliced it?

Yes.

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

Re: Sample Resource Specifications for Substrate Components

2008-04-23T19:09:13Z

On Wed, Apr 23, 2008 at 12:49:39PM -0600, Jay Lepreau wrote:
> Sounds like we're in violent agreement.

Great.
>
> But via your many examples it seems that your "sliceable" has now
> lost all its semantics.

So by sliceable you mean virtualizable? If I hand you exclusive control
of a resource I haven't sliced it?

--
Ted Faber
http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

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

attachment0 (202 bytes) Download Attachment

Re: Sample Resource Specifications for Substrate Components

2008-04-23T11:49:39Z

> In my understanding slicable and allocable are synonyms.

Seems strange. This definition devalues/reduces the word "sliceable"
from its intuitive and historical meaning. I think that's a bad
idea in terms of documentation and clarity.

But, the result is that you and I agree about what resources are sliceable.

> I may slice a
> resource by handing it all to you, virtualizing some set of resources
> and handing them to you, or scheduling your use so they don't interfere
> with others. That's a pretty wide range of techniques swallowed up in
> one word, but I understand slicing to imply an allocation of resources
> isolated temporally, spatially, or virtually.

Good, we agree (except for the definition of the word).

> Slicable doesn't necessarily mean programmable to me. If I'm allocated
> half the capacity of a link, that doesn't mean I get to program the
> controller, but the link's been sliced.

Right. Programmable is orthogonal.

> If I understand your example above of unslicable virtual resources
> above, I think they're still slicable by my broader definition: I could
> give them to another researcher as a whole. I understand that they're
> probably not further virtualizable.

> By talking about resources that slicable by that definition, RSpecs talk
> about anything a user could ask to be given or that a component can
> allocate. That seems like a small, clean thing to describe, and it's
> what I think RSpecs are for.

Sounds like we're in violent agreement.

But via your many examples it seems that your "sliceable" has now
lost all its semantics.

> Even if we disagree on "slicable" do you
> believe the goal of describing resources researchers can ask for and
> receive?

Absolutely.

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

Re: Sample Resource Specifications for Substrate Components

2008-04-22T18:13:42Z

On Tue, Apr 22, 2008 at 03:23:56PM -0400, John Jacob wrote:

> Ted,
>
> Yes, this is the issue I was getting at. The basic question is how to
> identify slicing granularity, and possibly isolation, in an Rspec. You
> captured the issue well. I agree that there will be many ways to slice
> the diverse substrate technologies as well as different ways to slice
> similar substrate technologies, which is one of the reason we might want
> to advertise the granularity. In a similar manner, two similar resources
> with similar slice granularities may have different isolation
> properties, which is something else we might need to consider in an
> advertisement of a resource. On this latter point, is isolation a
> prerequisite for slicing, or can a resource be sliced with different
> degrees of isolation?

People have certainly put forth the idea of allocating resources as
"best effort," which sounds a lot like "with minimal isolation" to me.
It's a little tough to think of isolation in terms other than "as
complete as we can make it" and "no guarantees," though. Are you
thinking of a scale that's more experessive than that?

I agree with you that an expression of granularity could be useful. I
worry that with the many axes on which one can slice, coming up with the
right abstraction for granularity is tricky. I wonder if a combination
of aggregation and simple time/space granularity expressions is
sufficient...

--
Ted Faber
http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

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

attachment0 (202 bytes) Download Attachment

Re: Sample Resource Specifications for Substrate Components

2008-04-22T17:58:47Z

On Tue, Apr 22, 2008 at 05:18:03PM -0600, Jay Lepreau wrote:
>
> Ted said:
> > Patrick or Rob will correct me if I say something bogus, but the intent
> > is that resources described by an RSpec are intended to be slicable.
>
> This must-be-sliceable requirement makes no sense to me
> and I do not remember ever hearing it before.

Let me see if my reasoning makes any sense to you.

>
> Reasons:
> -RSpecs are the universal way to describe resources of this type
> (computational, network, probably storage, maybe measurment),
> including virtual resources (the virtual resources/network requested
> by the experimenter) which by definition and practice are clearly not
> sliceable.
>
> -The GENI design, docs, and our discussions in the architecture group
> explicitly allow "virtualization" through space-sharing as well as
> intra-resource slicing. The docs use sensor nodes as onme example,
> but there are plenty of cases where it will make sense to do
> space-sharing or exclusive assignment, e.g. devices with poor or
> costly or not yet developed isolation mechanisms, such as NetFPGAs.
>
> -What's the value and motivation for proposing such a restriction?

In my understanding slicable and allocable are synonyms. I may slice a
resource by handing it all to you, virtualizing some set of resources
and handing them to you, or scheduling your use so they don't interfere
with others. That's a pretty wide range of techniques swallowed up in
one word, but I understand slicing to imply an allocation of resources
isolated temporally, spatially, or virtually.

Slicable doesn't necessarily mean programmable to me. If I'm allocated
half the capacity of a link, that doesn't mean I get to program the
controller, but the link's been sliced.

If I understand your example above of unslicable virtual resources
above, I think they're still slicable by my broader definition: I could
give them to another researcher as a whole. I understand that they're
probably not further virtualizable.

By talking about resources that slicable by that definition, RSpecs talk
about anything a user could ask to be given or that a component can
allocate. That seems like a small, clean thing to describe, and it's
what I think RSpecs are for. Even if we disagree on "slicable" do you
believe the goal of describing resources researchers can ask for and
receive?

--
Ted Faber
http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

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

attachment0 (202 bytes) Download Attachment

Re: Sample Resource Specifications for Substrate Components

2008-04-22T16:18:03Z

Ted said:
> Patrick or Rob will correct me if I say something bogus, but the intent
> is that resources described by an RSpec are intended to be slicable.

This must-be-sliceable requirement makes no sense to me
and I do not remember ever hearing it before.

Reasons:
-RSpecs are the universal way to describe resources of this type
(computational, network, probably storage, maybe measurment),
including virtual resources (the virtual resources/network requested
by the experimenter) which by definition and practice are clearly not
sliceable.

-The GENI design, docs, and our discussions in the architecture group
explicitly allow "virtualization" through space-sharing as well as
intra-resource slicing. The docs use sensor nodes as onme example,
but there are plenty of cases where it will make sense to do
space-sharing or exclusive assignment, e.g. devices with poor or
costly or not yet developed isolation mechanisms, such as NetFPGAs.

-What's the value and motivation for proposing such a restriction?

John said:
> In a similar manner, two similar resources with similar slice
> granularities may have different isolation properties, which is
> something else we might need to consider in an advertisement of a
> resource.

This is a good point I had not thought of. Could do an arbitrary metric
from 1-N (eg 5), or avoid that with an enumeration of the isolation
mechanisms (vservers, Xen VMs, flow tables, ...)

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

Re: Sample Resource Specifications for Substrate Components

2008-04-22T12:23:56Z

Ted,

Yes, this is the issue I was getting at. The basic question is how to
identify slicing granularity, and possibly isolation, in an Rspec. You
captured the issue well. I agree that there will be many ways to slice
the diverse substrate technologies as well as different ways to slice
similar substrate technologies, which is one of the reason we might want
to advertise the granularity. In a similar manner, two similar resources
with similar slice granularities may have different isolation
properties, which is something else we might need to consider in an
advertisement of a resource. On this latter point, is isolation a
prerequisite for slicing, or can a resource be sliced with different
degrees of isolation?

John

Ted Faber wrote:

> On Fri, Apr 18, 2008 at 07:38:05AM -0400, John Jacob wrote:
>
>> Patrick, Ted and Rob
>>
>> It is not clear to me that these resources can be sliced? Is this
>> something that needs to be identified in the Rspec? As presented in
>> these examples, it seems like the two machine types do not support
>> simultaneous, isolated slices. Is this true? How might an Rspec differ
>> for the case of simultaneously shared resources?
>>
>
> Patrick or Rob will correct me if I say something bogus, but the intent
> is that resources described by an RSpec are intended to be slicable.
>
> Maybe the issue is that there's no indication of how thickly the
> resources can be sliced? That does seem like the kind of thing one
> would like to communicate in an advertisement, and that one would
> consider in picking which components to try to instantiate on.
>
> Rob, does that sound like something we need to add? I'm worried that
> there's a pretty big can of worms under there (there are lots of ways to
> slice). Do you think there's a simple, general slicing granularity
> metric that we can communicate?
>
> I'm tempted to say that for each resource there's a granularity
> parameter (2.5 GHz of CPU in 500 MHz slices). That certainly may get
> more complex for connectivity.
>
> John, is that the issue you're getting at or did I miss it.
>
>

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

Re: Sample Resource Specifications for Substrate Components

2008-04-22T11:51:23Z

On Fri, Apr 18, 2008 at 07:38:05AM -0400, John Jacob wrote:
> Patrick, Ted and Rob
>
> It is not clear to me that these resources can be sliced? Is this
> something that needs to be identified in the Rspec? As presented in
> these examples, it seems like the two machine types do not support
> simultaneous, isolated slices. Is this true? How might an Rspec differ
> for the case of simultaneously shared resources?

Patrick or Rob will correct me if I say something bogus, but the intent
is that resources described by an RSpec are intended to be slicable.

Maybe the issue is that there's no indication of how thickly the
resources can be sliced? That does seem like the kind of thing one
would like to communicate in an advertisement, and that one would
consider in picking which components to try to instantiate on.

Rob, does that sound like something we need to add? I'm worried that
there's a pretty big can of worms under there (there are lots of ways to
slice). Do you think there's a simple, general slicing granularity
metric that we can communicate?

I'm tempted to say that for each resource there's a granularity
parameter (2.5 GHz of CPU in 500 MHz slices). That certainly may get
more complex for connectivity.

John, is that the issue you're getting at or did I miss it.

--
Ted Faber
http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

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

attachment0 (202 bytes) Download Attachment

Re: Sample Resource SpecificationsforSubstrate Components

2008-04-21T10:35:25Z

Here is a strawman Rspec for a BERT as a measurement instrument:

Example: MP1800 Signal Quality Analyzer (SQA) by Anritsu - I am not sure
whether this will be one of the measurement instruments to be deployed -
it would enable cross-layer communications with optical layer. Just
wanted to start the discussion from somewhere.

External Communication: Ethernet (dedicated line or can be muxed with
data)
Storage: limited to the PC (or mechanism) that enables communication of
the instrument with the rest of the network
Number of concurrent tests (slices): 4 (if Anritsu mux/demux is
available)
Test links: combination of links/channels depending on how much clock
recovery is possible - only a mutually exclusive list of links/channels
can be tested concurrently
User access mechanism: web-enabled LabView interface or proprietary
manufacturer's interface
Measurement update rate (can be configured)
Measurement channel (wavelength channel - should be configurable)
Measurement bit rate (can be configured)
Clock recovery availability: explicitly state which links would be able
to provide clock synchronization between the instrument and the end
points

Many other options can be added such as eye diagram, assistance in power
penalty, etc.

Number of concurrent tests, user access method/format,
measurement-related fields will be key to measurement instrument Rspec.

Deniz

> -----Original Message-----
> From: substrate-wg-bounces@... [mailto:substrate-wg-
> bounces@...] On Behalf Of John Jacob
> Sent: Friday, April 18, 2008 6:38 AM
> To: Patrick Crowley
> Cc: Substrate-WG@...
> Subject: Re: [substrate-wg] Sample Resource Specifications
forSubstrate

> Components
>
> Patrick, Ted and Rob
>
> It is not clear to me that these resources can be sliced? Is this
> something that needs to be identified in the Rspec? As presented in
> these examples, it seems like the two machine types do not support
> simultaneous, isolated slices. Is this true? How might an Rspec differ
> for the case of simultaneously shared resources?
>
> John
>
>
>
> Patrick Crowley wrote:
> > Dear substrate working group members,
> >
> > At the recent GENI engineering conference, it was suggested that we
> > begin generating example resource specifications (Rspecs) for the
> > various substrate components people are currently contemplating (or
> > building). The exercise has two explicit objectives: 1) to get
> > substrate creators to think about how to characterize the assets

they
> > offer, and 2) to get the control working group members thinking
about

> > how to characterize, control, and allocate the rich variety of
> > substrate types that people care about.
> >
> > After a bit of discussion, Ted, Rob and I have two examples to offer
> > to get the conversation started. Below, you will find two sample
> Rspecs:
> >
> > 1. A PC, and
> > 2. A Supercharged PlanetLab Platform (something we've built at WU)
> >
> > As you can see, there is no explicit, machine-readable syntax in
> place
> > yet; so do not feel constrained by syntax in any way. We hope that
> the
> > examples are rich enough to get you started, and to help you uncover
> > anything that may be difficult when trying to generate an Rspec for
> > your favorite substrate type.
> >
> > Please use this mailing list to publish your example Rspecs, along
> > with any questions or feedback you may have. Ted and Rob are both
> > members of this email list, and they (and I) will no doubt value

your
> > contributions and questions.
> >
> > We hope to have a nice batch of examples to discuss at the July GEC.
> > We hope and expect that all of the substrate presenters from the
> > recent GEC will submit example Rspecs to the email list; you know
who

> > you are (and so do we).
> >
> > Sincerely,
> > Patrick
> >
> > Strawman Rspec for a PC (from Ted & Rob)
> > ****************************************
> >
> > I think what we're looking for (Rob will correct me if I'm wrong) is
> > constrained attributes for each category. If you add new ones, give
> an
> > idea what attributes would be needed to cover your substrate. For
> > example a PC advertisement might look like (for a 1.8 Ghz x86
> processor
> > with 2 network interfaces configurable as bare HW or w/Linux):
> >
> > Computation: 1.8 Ghz x86 (2 attribs speed and type)
> > External Communication: 100 Mb/s Ethernet
> > External Communication: 100 Mb/s Ethernet
> > Storage: 2 GB DRAM
> > Storage: 200 GB rotating disk
> > Extended options
> > Interface: Bare 386, Lunix RH4
> >
> > I've sort of implicitly defined some attributes that I'll make
> explicit:
> > processor speed
> > processor type
> > interface bandwidth
> > interface MAC
> > storage size
> > storage type
> > PC interfaces: x86, Windows, Linux, FreeBSD, AmigaDOS
> >
> > That will give us an idea how many attributes need to be in the core
> > RSpec and where there's overlap. Constraints might look like this:
> > (
> > Computation: 1.8 Ghz x86
> > External Communication: 100 Mb/s Ethernet
> > External Communication: 100 Mb/s Ethernet
> > )
> > OR
> > (
> > Computation: 2.5 Ghz x86
> > Computation: 2.5 Ghz x86
> > External Communication: 100 Mb/s Ethernet
> > )
> > Storage: 2 GB DRAM
> > Storage: 200 GB rotating disk
> > Extended options
> > Interface: Bare 386, Lunix RH4
> >
> > Indicating that one could get a dual processor or a dual ethernet
> > machine, but not both. That sort of advertisement might come from

> > aggregate rather than a single component.
> >
> > Strawman Rspec for Supercharged PlanetLab Platform (SPP, from
> Patrick)
> >
> **********************************************************************
> >
> > I am providing two types of specifications:
> > - Physical resources, i.e. "system characteristics that determine
> > class of system"
> > - Requestable resources, i.e. "available control interfaces and
> > resources"
> >
> > Note that we decided to define entities hierarchically.
> >
> > SYSTEM CHARACTERISTICS
> > **********************
> >
> > GPE_x86:
> > Computation: 2 Ghz Dual-core Xeon x86
> > Computation: 2 Ghz Dual-core Xeon x86
> > V Storage: 4 GB DRAM
> > NV Storage: 37 GB rotating disk
> > Interface: RH4 Linux, Planetlab Version 3.1.15
> > Internal Communication: 10 Gb/s Ethernet (GGE)
> >
> >
> > NPE_IXP2850:
> > Computation: 1.4GHz IXP 2850
> > Computation: 1.4GHz IXP 2850
> > V Storage: 768 MB DRAM per IXP #total of 1.536 GB
> > V Storage: 26 Mb SRAM per IXP #3 Banks of 8 MB each and
> > #1 Bank of 2 MB (total of 52 MB)
> > V Storage: 18 Mb TCAM # Shared between IXPs, each with
> > # a dedicated interface
> > Interface: Bare IXP 2850, RH4 Linux, Planetlab fast paths
> > Internal Communication: 10 Gb/s Ethernet (NGE)
> >
> >
> > Linecard_IXP2850:
> > Component: NPE_IXP2850
> > Internal Communication: 10 Gb/s Ethernet (LCGE)
> > External Communication: 1000 Mb/s Ethernet
> > External Communication: 1000 Mb/s Ethernet
> > External Communication: 1000 Mb/s Ethernet
> > External Communication: 1000 Mb/s Ethernet
> > External Communication: 1000 Mb/s Ethernet
> > External Communication: 1000 Mb/s Ethernet
> > External Communication: 1000 Mb/s Ethernet
> > External Communication: 1000 Mb/s Ethernet
> >
> > SPP:
> > Component: GPE_x86 (G1)
> > Component: GPE_x86 (G2)
> > Component: NPE_IXP2850 (I1)
> > Component: NPE_IXP2850 (I2)
> > Component: Linecard_IXP2850 (L1)
> > Component: Backplane_10GE (B)
> >
> > Backplane_10GE:
> > Internal Communication: 10 Gb/s Ethernet (BGE1) -> G1/GGE
> > Internal Communication: 10 Gb/s Ethernet (BGE2) -> G2/GGE
> > Internal Communication: 10 Gb/s Ethernet (BGE3) -> I1/NGE
> > Internal Communication: 10 Gb/s Ethernet (BGE4) -> I2/NGE
> > Internal Communication: 10 Gb/s Ethernet (BGE5) -> L1/LCGE
> > Internal Communication: Crossbar, Fully provisioned
> >
> > RESOURCES THAT CAN BE REQUESTED
> > *******************************
> > PlanetLab 3.1.15 node
> > PlanetLab fast paths: Bare IXP 2850, IPv4, I3
> > Network links: 1-10
> > Link bandwidth : 1-1000 Mbps
> > Link service: Best Effort, Guaranteed
> >

---------------------------------------------------------------------

> ---
> >
> > _______________________________________________
> > substrate-wg mailing list
> > substrate-wg@...
> > http://lists.geni.net/mailman/listinfo/substrate-wg
> >
>
>
> _______________________________________________
> substrate-wg mailing list
> substrate-wg@...
> http://lists.geni.net/mailman/listinfo/substrate-wg

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

Re: Sample Resource Specifications for Substrate Components

2008-04-18T04:38:05Z

Patrick, Ted and Rob

It is not clear to me that these resources can be sliced? Is this
something that needs to be identified in the Rspec? As presented in
these examples, it seems like the two machine types do not support
simultaneous, isolated slices. Is this true? How might an Rspec differ
for the case of simultaneously shared resources?

John

Patrick Crowley wrote:

> Dear substrate working group members,
>
> At the recent GENI engineering conference, it was suggested that we
> begin generating example resource specifications (Rspecs) for the
> various substrate components people are currently contemplating (or
> building). The exercise has two explicit objectives: 1) to get
> substrate creators to think about how to characterize the assets they
> offer, and 2) to get the control working group members thinking about
> how to characterize, control, and allocate the rich variety of
> substrate types that people care about.
>
> After a bit of discussion, Ted, Rob and I have two examples to offer
> to get the conversation started. Below, you will find two sample Rspecs:
>
> 1. A PC, and
> 2. A Supercharged PlanetLab Platform (something we've built at WU)
>
> As you can see, there is no explicit, machine-readable syntax in place
> yet; so do not feel constrained by syntax in any way. We hope that the
> examples are rich enough to get you started, and to help you uncover
> anything that may be difficult when trying to generate an Rspec for
> your favorite substrate type.
>
> Please use this mailing list to publish your example Rspecs, along
> with any questions or feedback you may have. Ted and Rob are both
> members of this email list, and they (and I) will no doubt value your
> contributions and questions.
>
> We hope to have a nice batch of examples to discuss at the July GEC.
> We hope and expect that all of the substrate presenters from the
> recent GEC will submit example Rspecs to the email list; you know who
> you are (and so do we).
>
> Sincerely,
> Patrick
>
> Strawman Rspec for a PC (from Ted & Rob)
> ****************************************
>
> I think what we're looking for (Rob will correct me if I'm wrong) is
> constrained attributes for each category. If you add new ones, give an
> idea what attributes would be needed to cover your substrate. For
> example a PC advertisement might look like (for a 1.8 Ghz x86 processor
> with 2 network interfaces configurable as bare HW or w/Linux):
>
> Computation: 1.8 Ghz x86 (2 attribs speed and type)
> External Communication: 100 Mb/s Ethernet
> External Communication: 100 Mb/s Ethernet
> Storage: 2 GB DRAM
> Storage: 200 GB rotating disk
> Extended options
> Interface: Bare 386, Lunix RH4
>
> I've sort of implicitly defined some attributes that I'll make explicit:
> processor speed
> processor type
> interface bandwidth
> interface MAC
> storage size
> storage type
> PC interfaces: x86, Windows, Linux, FreeBSD, AmigaDOS
>
> That will give us an idea how many attributes need to be in the core
> RSpec and where there's overlap. Constraints might look like this:
> (
> Computation: 1.8 Ghz x86
> External Communication: 100 Mb/s Ethernet
> External Communication: 100 Mb/s Ethernet
> )
> OR
> (
> Computation: 2.5 Ghz x86
> Computation: 2.5 Ghz x86
> External Communication: 100 Mb/s Ethernet
> )
> Storage: 2 GB DRAM
> Storage: 200 GB rotating disk
> Extended options
> Interface: Bare 386, Lunix RH4
>
> Indicating that one could get a dual processor or a dual ethernet
> machine, but not both. That sort of advertisement might come from an
> aggregate rather than a single component.
>
> Strawman Rspec for Supercharged PlanetLab Platform (SPP, from Patrick)
> **********************************************************************
>
> I am providing two types of specifications:
> - Physical resources, i.e. "system characteristics that determine
> class of system"
> - Requestable resources, i.e. "available control interfaces and
> resources"
>
> Note that we decided to define entities hierarchically.
>
> SYSTEM CHARACTERISTICS
> **********************
>
> GPE_x86:
> Computation: 2 Ghz Dual-core Xeon x86
> Computation: 2 Ghz Dual-core Xeon x86
> V Storage: 4 GB DRAM
> NV Storage: 37 GB rotating disk
> Interface: RH4 Linux, Planetlab Version 3.1.15
> Internal Communication: 10 Gb/s Ethernet (GGE)
>
>
> NPE_IXP2850:
> Computation: 1.4GHz IXP 2850
> Computation: 1.4GHz IXP 2850
> V Storage: 768 MB DRAM per IXP #total of 1.536 GB
> V Storage: 26 Mb SRAM per IXP #3 Banks of 8 MB each and
> #1 Bank of 2 MB (total of 52 MB)
> V Storage: 18 Mb TCAM # Shared between IXPs, each with
> # a dedicated interface
> Interface: Bare IXP 2850, RH4 Linux, Planetlab fast paths
> Internal Communication: 10 Gb/s Ethernet (NGE)
>
>
> Linecard_IXP2850:
> Component: NPE_IXP2850
> Internal Communication: 10 Gb/s Ethernet (LCGE)
> External Communication: 1000 Mb/s Ethernet
> External Communication: 1000 Mb/s Ethernet
> External Communication: 1000 Mb/s Ethernet
> External Communication: 1000 Mb/s Ethernet
> External Communication: 1000 Mb/s Ethernet
> External Communication: 1000 Mb/s Ethernet
> External Communication: 1000 Mb/s Ethernet
> External Communication: 1000 Mb/s Ethernet
>
> SPP:
> Component: GPE_x86 (G1)
> Component: GPE_x86 (G2)
> Component: NPE_IXP2850 (I1)
> Component: NPE_IXP2850 (I2)
> Component: Linecard_IXP2850 (L1)
> Component: Backplane_10GE (B)
>
> Backplane_10GE:
> Internal Communication: 10 Gb/s Ethernet (BGE1) -> G1/GGE
> Internal Communication: 10 Gb/s Ethernet (BGE2) -> G2/GGE
> Internal Communication: 10 Gb/s Ethernet (BGE3) -> I1/NGE
> Internal Communication: 10 Gb/s Ethernet (BGE4) -> I2/NGE
> Internal Communication: 10 Gb/s Ethernet (BGE5) -> L1/LCGE
> Internal Communication: Crossbar, Fully provisioned
>
> RESOURCES THAT CAN BE REQUESTED
> *******************************
> PlanetLab 3.1.15 node
> PlanetLab fast paths: Bare IXP 2850, IPv4, I3
> Network links: 1-10
> Link bandwidth : 1-1000 Mbps
> Link service: Best Effort, Guaranteed
> ------------------------------------------------------------------------
>
> _______________________________________________
> substrate-wg mailing list
> substrate-wg@...
> http://lists.geni.net/mailman/listinfo/substrate-wg
>

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

Re: Sample Resource Specifications for Substrate Components

2008-04-17T14:11:49Z

Greetings Patrick,

Has anyone in the substrate WG looked at the Common Information
Model (CIM) from DMTF: http://www.dmtf.org/standards/cim/?

The CIM has a UML data model description for just about anything
you can plug in. This isn't necessarily a good thing, e.g.,
the CIM diagram for network components is 38 pages long!
http://www.dmtf.org/standards/cim/cim_schema_v2171/CIM_Network.pdf

And the Processor description is probably not rich enough:
http://www.dmtf.org/standards/cim/cim_schema_v2171/CIM_Device.pdf
(goto Page 3)

I'm personally interested in using UML (or a rational subset) to
formally define a data model for existing PlanetLab components,
and I tripped over CIM while learning about UML.

Why UML? Because there are a lot of tools that generate
useful artifacts from UML descriptions, e.g., an XML Schema
for your data model, Java/Python class files, etc.

I think this could be a big win for people working on RSpecs
if they had easy-to-use tools for specifying their devices/components
and they could generate the necessary schemata automatically.

Thanks, Mary

On Fri, 2008-04-11 at 17:16 -0500, Patrick Crowley wrote:

> Dear substrate working group members,
>
> At the recent GENI engineering conference, it was suggested that we
> begin generating example resource specifications (Rspecs) for the
> various substrate components people are currently contemplating (or
> building). The exercise has two explicit objectives: 1) to get substrate
> creators to think about how to characterize the assets they offer, and
> 2) to get the control working group members thinking about how to
> characterize, control, and allocate the rich variety of substrate types
> that people care about.
>
> After a bit of discussion, Ted, Rob and I have two examples to offer to
> get the conversation started. Below, you will find two sample Rspecs:
>
> 1. A PC, and
> 2. A Supercharged PlanetLab Platform (something we've built at WU)
>
> As you can see, there is no explicit, machine-readable syntax in place
> yet; so do not feel constrained by syntax in any way. We hope that the
> examples are rich enough to get you started, and to help you uncover
> anything that may be difficult when trying to generate an Rspec for your
> favorite substrate type.
>
> Please use this mailing list to publish your example Rspecs, along with
> any questions or feedback you may have. Ted and Rob are both members of
> this email list, and they (and I) will no doubt value your contributions
> and questions.
>
> We hope to have a nice batch of examples to discuss at the July GEC. We
> hope and expect that all of the substrate presenters from the recent GEC
> will submit example Rspecs to the email list; you know who you are (and
> so do we).
>
> Sincerely,
> Patrick
>
> Strawman Rspec for a PC (from Ted & Rob)
> ****************************************
>
> I think what we're looking for (Rob will correct me if I'm wrong) is
> constrained attributes for each category. If you add new ones, give an
> idea what attributes would be needed to cover your substrate. For
> example a PC advertisement might look like (for a 1.8 Ghz x86 processor
> with 2 network interfaces configurable as bare HW or w/Linux):
>
> Computation: 1.8 Ghz x86 (2 attribs speed and type)
> External Communication: 100 Mb/s Ethernet
> External Communication: 100 Mb/s Ethernet
> Storage: 2 GB DRAM
> Storage: 200 GB rotating disk
> Extended options
> Interface: Bare 386, Lunix RH4
>
> I've sort of implicitly defined some attributes that I'll make explicit:
> processor speed
> processor type
> interface bandwidth
> interface MAC
> storage size
> storage type
> PC interfaces: x86, Windows, Linux, FreeBSD, AmigaDOS
>
> That will give us an idea how many attributes need to be in the core
> RSpec and where there's overlap. Constraints might look like this:
> (
> Computation: 1.8 Ghz x86
> External Communication: 100 Mb/s Ethernet
> External Communication: 100 Mb/s Ethernet
> )
> OR
> (
> Computation: 2.5 Ghz x86
> Computation: 2.5 Ghz x86
> External Communication: 100 Mb/s Ethernet
> )
> Storage: 2 GB DRAM
> Storage: 200 GB rotating disk
> Extended options
> Interface: Bare 386, Lunix RH4
>
> Indicating that one could get a dual processor or a dual ethernet
> machine, but not both. That sort of advertisement might come from an
> aggregate rather than a single component.
>
> Strawman Rspec for Supercharged PlanetLab Platform (SPP, from Patrick)
> **********************************************************************
>
> I am providing two types of specifications:
> - Physical resources, i.e. "system characteristics that determine class
> of system"
> - Requestable resources, i.e. "available control interfaces and resources"
>
> Note that we decided to define entities hierarchically.
>
> SYSTEM CHARACTERISTICS
> **********************
>
> GPE_x86:
> Computation: 2 Ghz Dual-core Xeon x86
> Computation: 2 Ghz Dual-core Xeon x86
> V Storage: 4 GB DRAM
> NV Storage: 37 GB rotating disk
> Interface: RH4 Linux, Planetlab Version 3.1.15
> Internal Communication: 10 Gb/s Ethernet (GGE)
>
>
> NPE_IXP2850:
> Computation: 1.4GHz IXP 2850
> Computation: 1.4GHz IXP 2850
> V Storage: 768 MB DRAM per IXP #total of 1.536 GB
> V Storage: 26 Mb SRAM per IXP #3 Banks of 8 MB each and
> #1 Bank of 2 MB (total of 52 MB)
> V Storage: 18 Mb TCAM # Shared between IXPs, each with
> # a dedicated interface
> Interface: Bare IXP 2850, RH4 Linux, Planetlab fast paths
> Internal Communication: 10 Gb/s Ethernet (NGE)
>
>
> Linecard_IXP2850:
> Component: NPE_IXP2850
> Internal Communication: 10 Gb/s Ethernet (LCGE)
> External Communication: 1000 Mb/s Ethernet
> External Communication: 1000 Mb/s Ethernet
> External Communication: 1000 Mb/s Ethernet
> External Communication: 1000 Mb/s Ethernet
> External Communication: 1000 Mb/s Ethernet
> External Communication: 1000 Mb/s Ethernet
> External Communication: 1000 Mb/s Ethernet
> External Communication: 1000 Mb/s Ethernet
>
> SPP:
> Component: GPE_x86 (G1)
> Component: GPE_x86 (G2)
> Component: NPE_IXP2850 (I1)
> Component: NPE_IXP2850 (I2)
> Component: Linecard_IXP2850 (L1)
> Component: Backplane_10GE (B)
>
> Backplane_10GE:
> Internal Communication: 10 Gb/s Ethernet (BGE1) -> G1/GGE
> Internal Communication: 10 Gb/s Ethernet (BGE2) -> G2/GGE
> Internal Communication: 10 Gb/s Ethernet (BGE3) -> I1/NGE
> Internal Communication: 10 Gb/s Ethernet (BGE4) -> I2/NGE
> Internal Communication: 10 Gb/s Ethernet (BGE5) -> L1/LCGE
> Internal Communication: Crossbar, Fully provisioned
>
> RESOURCES THAT CAN BE REQUESTED
> *******************************
> PlanetLab 3.1.15 node
> PlanetLab fast paths: Bare IXP 2850, IPv4, I3
> Network links: 1-10
> Link bandwidth : 1-1000 Mbps
> Link service: Best Effort, Guaranteed
> _______________________________________________
> substrate-wg mailing list
> substrate-wg@...
> http://lists.geni.net/mailman/listinfo/substrate-wg

--
Mary Fernandez <mff@...>
AT&T Labs Research

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

NGMN - Reconfigurable Beyond 3G Testbed

2008-04-17T08:19:30Z

Misters,

Let me introduce myself : Guillaume FORTAINE, Consultant Service
Strategy and Innovation. It's an honor for me to send this mail to You.

I am definitely aware of Your Preeminence in the Telecommunications
World.

First of all, as Project Officers New Paradigms and Experimental
Facilities, it would be an honor for me to meet You there :

http://www.panlab.net/events/panlab-seminar-2008.html

Panlab Seminar - Testbed Federation in Europe
13-14 May 2008, Dinard, France (Brittany)

Working with Xilinx :

Multi-mode: Increasing supply chain efficiency and reducing radio …
http://www.openbasestation.org/Newsletters/February2008/Xilinx.htm

Fig.3 illustrates a Multi-Modal Radio, where all DSP processing is
accomplished using FPGA technology. Signal processing techniques are
deployed such that any mixture of air interface waveform can be realized
using a single device and the board shown is capable of CDMA2000, WiMAX,
TD-SCDMA, UMTS and 3GPP-LTE.

We are currently establishing a new Business Model to simplify the
value-chain by working directly with the end user, in this case, the
Operator.

The value-added for Them :

a) CAPEX :

Reduced cost by skipping the various OEMs margins.

b) OPEX :

The power of FPGAs combining the flexibility of Software and the Speed
of Hardware will ensure :

1) Spectrum Agility with SDR and a seamless path to new 4G (UWB) and 2G
(EDGE Evolution) Standards

2) Very precise High-Throughput Network Simulation and Accelerated
Routing + Backplane Reconfiguration

3) Reduced costs for Accelerated Multimedia Servers/end-to-end broadcast
chains

I am definitely aware of the various International Networking Testbeds :

http://groups.geni.net/geni/wiki/RelatedProjects

http://www.panlab.net/testbed-repository.html

http://www.one-lab-2.org/

http://www.celtic-initiative.org/Projects/NETLAB/abstract-netlab.asp

http://www.dai-labor.de/index.php?id=885&L=1

However, we are definitely convinced that no one will meet the Operators
requirements in terms of Spectrum Agility and Network Backplane
Flexibility ensuring cost competitiveness in a mid-term range :

*Making mobile broadband networks a success – Operator requirements*

Hartmut Kremling (CTO Vodafone D2)

Download Presentation as PDF
<http://www.ngmn.org/fileadmin/content/documents/events/2_Hartmut_Kremling.pdf>

That's why I am currently working with Xilinx, the number 1 Dynamically
Reconfigurable FPGAs Supplier, to set up a Self Reconfigurable Network
Testbed :

A self-reconfiguring platform
<http://www.kandeco.com/publications/presentations/srp.ppt>

*Berlin‘s Beyond-3G Testbed and Serviceware Framework for Advanced* …
<http://www.bib3r.de/fileadmin/pdf/bib3r.de.pdf>

Moreover, we plan to build it in a modular way, thus ensuring to IWPC
consortium goals and providing an healthy competition amongst the
various suppliers :

http://www.iwpc.org/about.shtm

/*APPENDIX*/

/* */

/*SUPPLY CHAIN MODEL IN THE WIRELESS & RF PACKAGING INDUSTRY*/

/* */

Below is a model describing the supply chain of the wireless & RF
Packaging Industry. One of the goals of the consortium is to conduct
interviews with ALL levels of the supply chain and invite members of
all levels of the supply chain to take part in the interactive
Forums. This concept provides invaluable visibility up and down the
supply chain to all present at the Forums.

and to show to the potential customers how to integrate seamlessly the
product into their core network.

We would greatly appreciate to have Your Comments on this idea.

We look forward to Your Answer,

Best Regards,

Guillaume FORTAINE

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

Sample Resource Specifications for Substrate Components

2008-04-11T15:16:41Z

Dear substrate working group members,

At the recent GENI engineering conference, it was suggested that we
begin generating example resource specifications (Rspecs) for the
various substrate components people are currently contemplating (or
building). The exercise has two explicit objectives: 1) to get substrate
creators to think about how to characterize the assets they offer, and
2) to get the control working group members thinking about how to
characterize, control, and allocate the rich variety of substrate types
that people care about.

After a bit of discussion, Ted, Rob and I have two examples to offer to
get the conversation started. Below, you will find two sample Rspecs:

1. A PC, and
2. A Supercharged PlanetLab Platform (something we've built at WU)

As you can see, there is no explicit, machine-readable syntax in place
yet; so do not feel constrained by syntax in any way. We hope that the
examples are rich enough to get you started, and to help you uncover
anything that may be difficult when trying to generate an Rspec for your
favorite substrate type.

Please use this mailing list to publish your example Rspecs, along with
any questions or feedback you may have. Ted and Rob are both members of
this email list, and they (and I) will no doubt value your contributions
and questions.

We hope to have a nice batch of examples to discuss at the July GEC. We
hope and expect that all of the substrate presenters from the recent GEC
will submit example Rspecs to the email list; you know who you are (and
so do we).

Sincerely,
Patrick

Strawman Rspec for a PC (from Ted & Rob)
****************************************

I think what we're looking for (Rob will correct me if I'm wrong) is
constrained attributes for each category. If you add new ones, give an
idea what attributes would be needed to cover your substrate. For
example a PC advertisement might look like (for a 1.8 Ghz x86 processor
with 2 network interfaces configurable as bare HW or w/Linux):

Computation: 1.8 Ghz x86 (2 attribs speed and type)
External Communication: 100 Mb/s Ethernet
External Communication: 100 Mb/s Ethernet
Storage: 2 GB DRAM
Storage: 200 GB rotating disk
Extended options
Interface: Bare 386, Lunix RH4

I've sort of implicitly defined some attributes that I'll make explicit:
processor speed
processor type
interface bandwidth
interface MAC
storage size
storage type
PC interfaces: x86, Windows, Linux, FreeBSD, AmigaDOS

That will give us an idea how many attributes need to be in the core
RSpec and where there's overlap. Constraints might look like this:
(
Computation: 1.8 Ghz x86
External Communication: 100 Mb/s Ethernet
External Communication: 100 Mb/s Ethernet
)
OR
(
Computation: 2.5 Ghz x86
Computation: 2.5 Ghz x86
External Communication: 100 Mb/s Ethernet
)
Storage: 2 GB DRAM
Storage: 200 GB rotating disk
Extended options
Interface: Bare 386, Lunix RH4

Indicating that one could get a dual processor or a dual ethernet
machine, but not both. That sort of advertisement might come from an
aggregate rather than a single component.

Strawman Rspec for Supercharged PlanetLab Platform (SPP, from Patrick)
**********************************************************************

I am providing two types of specifications:
- Physical resources, i.e. "system characteristics that determine class
of system"
- Requestable resources, i.e. "available control interfaces and resources"

Note that we decided to define entities hierarchically.

SYSTEM CHARACTERISTICS
**********************

GPE_x86:
Computation: 2 Ghz Dual-core Xeon x86
Computation: 2 Ghz Dual-core Xeon x86
V Storage: 4 GB DRAM
NV Storage: 37 GB rotating disk
Interface: RH4 Linux, Planetlab Version 3.1.15
Internal Communication: 10 Gb/s Ethernet (GGE)

NPE_IXP2850:
Computation: 1.4GHz IXP 2850
Computation: 1.4GHz IXP 2850
V Storage: 768 MB DRAM per IXP #total of 1.536 GB
V Storage: 26 Mb SRAM per IXP #3 Banks of 8 MB each and
#1 Bank of 2 MB (total of 52 MB)
V Storage: 18 Mb TCAM # Shared between IXPs, each with
# a dedicated interface
Interface: Bare IXP 2850, RH4 Linux, Planetlab fast paths
Internal Communication: 10 Gb/s Ethernet (NGE)

Linecard_IXP2850:
Component: NPE_IXP2850
Internal Communication: 10 Gb/s Ethernet (LCGE)
External Communication: 1000 Mb/s Ethernet
External Communication: 1000 Mb/s Ethernet
External Communication: 1000 Mb/s Ethernet
External Communication: 1000 Mb/s Ethernet
External Communication: 1000 Mb/s Ethernet
External Communication: 1000 Mb/s Ethernet
External Communication: 1000 Mb/s Ethernet
External Communication: 1000 Mb/s Ethernet

SPP:
Component: GPE_x86 (G1)
Component: GPE_x86 (G2)
Component: NPE_IXP2850 (I1)
Component: NPE_IXP2850 (I2)
Component: Linecard_IXP2850 (L1)
Component: Backplane_10GE (B)

Backplane_10GE:
Internal Communication: 10 Gb/s Ethernet (BGE1) -> G1/GGE
Internal Communication: 10 Gb/s Ethernet (BGE2) -> G2/GGE
Internal Communication: 10 Gb/s Ethernet (BGE3) -> I1/NGE
Internal Communication: 10 Gb/s Ethernet (BGE4) -> I2/NGE
Internal Communication: 10 Gb/s Ethernet (BGE5) -> L1/LCGE
Internal Communication: Crossbar, Fully provisioned

RESOURCES THAT CAN BE REQUESTED
*******************************
PlanetLab 3.1.15 node
PlanetLab fast paths: Bare IXP 2850, IPv4, I3
Network links: 1-10
Link bandwidth : 1-1000 Mbps
Link service: Best Effort, Guaranteed

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

smime.p7s (4K) Download Attachment

Re: WG overlap: GIMS

2008-03-03T05:55:14Z

I completely agree with you. We need to take into account of the requirements of all workgroups in the architecture definitions of GIMS and measurement plane in general. A sub-group that communicates with all other WGs on GIMS is a good idea. Maybe this subgroup can belong to the substrate group during the phase when we actually build the physical GENI.

In addition to the data sharing and archiving issues, we need to identify what kinds of measurements will be needed for each potential researcher's agenda. The substrate group may work on identifying what equipment needs to be deployed or initially it will be all possible commercial off-the-shelf instruments. However, each GENI island may have a different set of measurement capabilities. We need to think about how to make this diversity a strength for GENI.

We need to regard each dedicated measurement equipment as a component that needs to have a slice coordination and O&M just like any other component. There may be also some embedded measurements in components. They all need to be accessible by users as a resource. Remote access and configuration of all measurements will be very important to define.

Thanks,
Deniz

Michael A. Patton wrote:

One of the things I've been looking at for the OMIS WG is where we
overlap with other WGs. One particular area that's got both lots of
overlap and is critical and important to GENI is the instrumentation
(GIMS) for experiments. It seems like these three WGs, at least, all
have a considerable stake in it. But where the lines are drawn is not
at all clear.

Since one of the goals of the upcoming conference is to work on
cross-WG issues (since all WG sessions are in full plenary and
therefore open to all other WGs), I thought it might be fruitful to
see if we could spur some discussion on how to attack the design and
specification for GIMS.

----------------

I think that getting GIMS right is a hard (and therefore interesting)
problem. There are lots of issues, and I think some of them cross the
normal boundaries between the WGs. This leads me to think that first
we may need to decide on the meta-question of how to handle it.

One possible way to get a more consistent overall design would be to
have a sub-group (that would, in essence be a sub-grioup of each of
the WGs) to work on GIMS. This sub-group would need to have people
from all three WGs and would interact back to each of the full WGs as
needed both for input and review.

Another idea (really just a less organized version of the above, I
suspect) is to have a wiki page common to the 3 WGs (and any others
that think they have a stake) to collect the issues and work out how
the subdivision of the problem will be defined.

If you have any comments on those approaches, or want to suggest some
other alternatives, please do.

----------------

There are a lot of issues that need to be worked out, here are just
some that occur to me...these are short summaries, I could probably
write a lot more on each of them.

I think one of the big issues with GIMS is that with the 20 plus year
expected lifetime, data collection, archiving, and analysis techniques
will evolve considerably and an architecture is needed that can evolve
as well and keep all the required old data available.

Another big one is privacy, anonymity, and other concerns in the
tradeoff between disclosure and secrecy. This is especially tough as
public perception and even legislation can affect what protections are
needed, and these change over time. So, again there is a need for a
design that can adjust to changing circumstances. And, what about
combining data collected under two different sets of privacy
assumptions?

Another issue is avoiding duplication between data collected for
operating the network and for instrumentation of experiments. There
are several kinds of data that need to be collected for both purposes.
How do we integrate these systems in a way that avoids having to
collect the same information multiple times?

OK, that's a short sample of issues. Feel free to contribute your
own...

----------------

In summary, I think GIMS is going to be an important part of GENI and
getting its design going soon seems desireable. So, please contribute
your own input on this.

-MAP

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

--------------------------------------------------------------------------------
Deniz Gurkan, PhD
Assistant Professor
Engineering Technology (Room 230-B)
University of Houston
T: 713-743-4037
dgurkan@uh.edu
http://tech.uh.edu/faculty/gurkan/

WG overlap: GIMS

2008-02-28T22:53:29Z

One of the things I've been looking at for the OMIS WG is where we
overlap with other WGs. One particular area that's got both lots of
overlap and is critical and important to GENI is the instrumentation
(GIMS) for experiments. It seems like these three WGs, at least, all
have a considerable stake in it. But where the lines are drawn is not
at all clear.

Since one of the goals of the upcoming conference is to work on
cross-WG issues (since all WG sessions are in full plenary and
therefore open to all other WGs), I thought it might be fruitful to
see if we could spur some discussion on how to attack the design and
specification for GIMS.

----------------

I think that getting GIMS right is a hard (and therefore interesting)
problem. There are lots of issues, and I think some of them cross the
normal boundaries between the WGs. This leads me to think that first
we may need to decide on the meta-question of how to handle it.

One possible way to get a more consistent overall design would be to
have a sub-group (that would, in essence be a sub-grioup of each of
the WGs) to work on GIMS. This sub-group would need to have people
from all three WGs and would interact back to each of the full WGs as
needed both for input and review.

Another idea (really just a less organized version of the above, I
suspect) is to have a wiki page common to the 3 WGs (and any others
that think they have a stake) to collect the issues and work out how
the subdivision of the problem will be defined.

If you have any comments on those approaches, or want to suggest some
other alternatives, please do.

----------------

There are a lot of issues that need to be worked out, here are just
some that occur to me...these are short summaries, I could probably
write a lot more on each of them.

I think one of the big issues with GIMS is that with the 20 plus year
expected lifetime, data collection, archiving, and analysis techniques
will evolve considerably and an architecture is needed that can evolve
as well and keep all the required old data available.

Another big one is privacy, anonymity, and other concerns in the
tradeoff between disclosure and secrecy. This is especially tough as
public perception and even legislation can affect what protections are
needed, and these change over time. So, again there is a need for a
design that can adjust to changing circumstances. And, what about
combining data collected under two different sets of privacy
assumptions?

Another issue is avoiding duplication between data collected for
operating the network and for instrumentation of experiments. There
are several kinds of data that need to be collected for both purposes.
How do we integrate these systems in a way that avoids having to
collect the same information multiple times?

OK, that's a short sample of issues. Feel free to contribute your
own...

----------------

In summary, I think GIMS is going to be an important part of GENI and
getting its design going soon seems desireable. So, please contribute
your own input on this.

-MAP

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