Substrate Resouces
|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Re: Substrate Resouces
by Kristin Rauschenbach
::
Rate this Message:
John is away this week, so I am sending around the latest version of the
component list. This list includes the most recent wireless updates from Peter Steenkiste. I added measurement (test equipment component), a timing resource in the network component, a fiber facility component that includes routes and fibers, and entries for "middleware." Before I explain these entries, I'll provide some background, mostly based on the email discussions. I want to thank everyone who has taken the time to contribute to the email discussion and encourage more participation. These exchanges are the primary mechanism to refine the collective understanding about the GENI substrate and to move the GENI design forward. More participation in the email discussion leads directly to a better informed design. The inputs we have to date are extremely useful, and I look forward to more discussion. The GPO recognizes that consistent terminology is important. When the working group wiki's are up and running, we will create a reference area for the terms we use, especially those central to the architecture (e.g. slice, aggregate, component, resource, shareable, etc.). There are definitions for most of the frequently used terms in the planning group documents, but some terms need further refinement to avoid confusion and ensure consistency across the working groups. Also, the definition of some terms will take time to settle out. For now, the definitions for substrate, component, and resource at the bottom of the component list are "as close as possible" to the current understanding. I added shareable, which is the replacement for dividable (and multiplexed) and consistent with the Narrow Waist group's usage. We should aim to have the component/resource list include all the fundamental building blocks we are aware of today, whether from commercial experience, or existing network testbeds. At the same time, traditional network resources are expanding to include e.g. computers and storage clusters, and traditional service offerings are diversifying. It follows that researchers will expect a rich menu from which to compose their slices. As such, we should think very broadly as we make this initial component/resource list. If we generate an overly-complete set of resources, we can pare it down later by combining and cutting as necessary. This also means that in addition to the most basic building blocks, it makes sense to carry the more complex, perhaps "virtual" to some of us, elements, especially early on. Note that eventually we will address the notion of "sphere of control" (i.e. ownership or operational stewardship of a part of the substrate) for the components and resources we are considering. While sphere of control is clearly important to the eventual design and construction/procurement of GENI, for now we should address resources from the standpoint of interest and utility to the researcher. We will address issues of ownership and management/control at a later phase and in collaboration with the OMIS group. I haven't yet seen this issue restrict any of the discussions, but suspect it is not looming too far in the future, especially when we think about resources that are more like managed services than the underlying hardware/software network elements. Now to the List: 1) Measurement. As suggested by Deniz, I added a test equipment component and included some measurements that might conceivable be part of a slice. Measurement is an area that crosses working groups, but in the spirit of "over inclusiveness" I think we should carry some measurements as resources. The cross-layer experimenters frequently express interest in a shared resource that provides measurements, especially measurements outside the traditional service-layer boundaries. We will need to define what types of measurements make sense as a resource, and understand how they might be provided (cost effectively) as part of GENI, but I think this is work well worth doing. 2) Timing. At Paul Morton's suggestion, I added a timing resource within the "network" component. We will need more detailed examples, and understand how this relates to services such as NTP and BITS facilities. Again, this is a resource that will require additional work to develop, but is an important candidate for evaluation. 3) Fiber facility. I think that the optical resources list needs some additional work. Stu and Keren's inputs included some good points that are not yet fully reconciled in the list. By adding the fiber facility, I was trying to relate to Stu's notion that we need some physical and some logical representations for " connections", along with the appropriate binding. While the idea of nodes (ports) and links must be carried forward, we should think hard about how experiments might be "tied together" in a GENI context. In particular, we need to be sure we support alien waves, alien spectrum and transparent optical switches properly. I plan to generate some additional use case examples, along the lines Stu and Masanori provided, to try to help us through this. Please feel free to make other suggestions. I also think reconciling "connectivity" between the optical and the wireless resources will be a useful exercise. So, more work to come on this front. 4) Middleware. This was based on some discussion at the GEC. I suggest we keep placeholder for these "resources" in the substrate list, recognizing that they may end up residing within services and/or OMIS. 5) The wireless node additions came from Peter Steenkiste, and seem right on track. Are there more inputs from others with wireless interests? 6) Does anyone have comments on the processor and storage components? I welcome comments and suggestions on any or all of the above. -----Original Message----- From: substrate-wg-bounces@... [mailto:substrate-wg-bounces@...] On Behalf Of Heidi Picher Dempsey Sent: Monday, November 05, 2007 2:58 PM To: John Jacob Cc: substrate-wg@... Subject: Re: [substrate-wg] Substrate Resouces On Nov 5, 2007, at 2:20 PM, John Jacob wrote: > Deniz, > > I believe there are two distinct uses for measurements, one is the > traditional use to gauge the performance of an experiment, and the > other, as you mention, is to support cross-layer communications which > can be used to drive networking decisions. Measurements are also used by operations to troubleshoot problems, monitor "hot spots," and, over the longer term, to provide inputs to trend analysis and network engineering/planning. There is also the potential in GENI that measurements could be of interest to not only the users who are running the experiments, but also to users who are using the infrastructure for their traffic, but not explicitly running experiments themselves. There is a potential for overlap with operations measurements in both the experimental measurements, the cross-layer communications measurements, and the non-experimental user measurements. > The traditional measurements > fall under the GENI Instrumentation and Measurement System (GIMS) > which is a separate entity, and currently does not reside in the > substrate working group charter. I'm not sure it is as clean as all that. The measurements may fall into many systems, which may also need to be coupled with the substrate, though perhaps not so tightly. > However, GIMS and the substrate will be tightly > coupled. There will exist component resources which support the > measurement demands of GIMS and others that will be supported by > external test equipment. The second use of measurements to support > networking decisions via cross-layer communications is one which does > belong to the substrate working group. I believe this also overlaps with the operations working group > These measurements should be > captured in our list, but I am not sure if these should be considered > as > component resources. Furthermore, the use of external measurements from > devices not currently inside networking equipment for this purpose > should also be discussed. I would like to get others thoughts on this > topic. Certainly there will be external measurements from devices not in the networking equipment for both operations and users. Although the distinction between substrate component and resource is very useful for identifying what types of data can be collected and where, it is not so useful for deciding how to manage that data or determine which systems will access. Two things that have been useful in my experience for those type of decisions have been the time frame over which the data is useful (the data "sell by" date) and the ownership demarcation for the component that produces the data. Time frame is useful because it helps rule out some interfaces (planning systems probably don't need fine-grained queue stats). Demarc is useful because it highlights when the producers and consumers of measurements are not in the same organization. In GENI's case, it seems likely the demarc extends to the slice. In the OMIS group we also discussed whether (and if so how far) it extends into the slivers, but we did not have enough time to really reach a conclusion about that. You might want to consider whether these concepts could be incorporated in the substrate spreadsheet. Or perhaps we need another spreadsheet specifically about measurements. > > Thanks, > John > > > > Deniz Gurkan wrote: >> I am not sure if I understand measurement aspect correctly: >> measurements will >> open up cross-layer communications from/to the substrate components >> as well >> as enabling experiments by users. The measurement devices can be >> installed >> to report on BER, optical/wireless link quality parameters, etc. >> >> Is the measurement going to be part of the component or a separate >> entity? >> Initially, I would guess that it will be a separate entity - since >> optical >> switches, ROADMs, etc are not built to respond/monitor comprehensive >> list of >> parameters that GENI would expect them to. We might need to list them >> as >> part of the components. In addition, they can help with sliceability >> assessment of a link at any given time. >> >> In time, as nodes become intelligent enough to report on their >> status, measurements and functions would be integrated into one. Am I on >> right >> track with measurements? >> >> Deniz >> >> >> >> John Jacob-2 wrote: >> >>> Peter, >>> >>> I will post an email later today summarizing all of the recent >>> input, and will address your points in the form of questions to the >>> group. However, I would like to clarify what I meant by "sliceable" >>> and "programmable" >>> >>> sliceable - the ability to divide a components resource into >>> multiple independent units, supporting parallel and isolated >>> experiments. programmable - the ability for a user to define the >>> nature of a component and or its resources. One example is the >>> ability to use programmable framers and processors to define a node >>> as circuit or packet switch. >>> >>> I believe programmability applies to the nature of the resource, as >>> well >>> as the specific implementation. For example, GENI could be comprised >>> of >>> multiple networking boxes which provide the same functions, but one >>> instance of the box may use a stable product based on ASICS, whereas >>> another instance may use an emerging product based on FPGA's. They >>> both >>> provide the same function (e.g. a switch) but not the same degree of >>> programmability. >>> >>> John >>> >>> Peter Steenkiste wrote: >>> >>>> A couple of comments, mostly about the structure: >>>> >>>> Following up on Jay's comment, it looks like Column A has a mixture >>>> of >>>> what I think of as substrates (e.g. a network) and components (e.g. >>>> a >>>> switch or optical line). >>>> >>>> It is not clear that the three level hierarchy (substrate - >>>> component >>>> - resource) will always be sufficient. For example, we will have >>>> computing devices (including CPU, memory, etc. resources) in >>>> switches, >>>> computing clusters, etc. So at least it looks like components can >>>> be >>>> part of larger components? The people working on resource >>>> descriptors >>>> probably know a lot more about this already. >>>> >>>> It would be useful to clarify what it means to have an "X" in the >>>> sliceable and programmable column. Does it mean that this resource >>>> will always be sl/pr or that it will sometimes be sl/pr (i.e. some >>>> instances will be and others will not). I assume it is the latter? >>>> >>>> It is also possible to emulate (certain aspects of) a network (I am >>>> mostly familiar with this in wireless). Should such emulated >>>> networks >>>> be listed as a separate type of resource or substrate? >>>> Alternatively, >>>> they could be viewed as simply instances of the non-emulated >>>> substrate >>>> or component (i.e. it is a more programmable version). The former >>>> seems cleaner, but it will drive up the number of rows. This is of >>>> course related to the previous paragraph. >>>> >>>> Peter >>>> >>>> >>>> >>>> Jay Lepreau wrote: >>>> >>>>> On sheet2, do columns C,D,E correspond to the Physical, Logical, >>>>> and >>>>> Synthetic >>>>> classes of resources you outline at the bottom? >>>>> >>>>> And I guess that col A is "Substrate" and B is "Component" that >>>>> you outline below? >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> >> >> >> ----- >> --------------------------------------------------------------------- >> - >> ---------- >> Deniz Gurkan, PhD >> Assistant Professor >> Engineering Technology (Room 230-B) >> University of Houston >> T: 713-743-4037 >> dgurkan@... >> http://tech.uh.edu/faculty/gurkan/ >> >> > > > _______________________________________________ > 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: Substrate Resouces
by John Jacob-2
::
Rate this Message:
All,
I modified the most recent version of the resource spreadsheet (16 Nov 07) to include "User Opt-in traffic". I would argue that multiple experiments which rely on realistic traffic scenarios, would want to carry the User Opt-In traffic over their slice. In this case, User Opt-In traffic may look like a network resource. As a reminder, we are building this spreadsheet with a very wide filter in an effort to capture many entries to be culled at a later date. Regarding test equipment, I suggest dividing this into two categories; 1. stand-alone test equipment and 2. embedded measurements. The latter recognizes the inherent ability of network device performance monitoring functions. I have also included equipment for deep packet inspection. This will be an interesting subject as it raises an important issue regarding privacy of User Opt-In traffic. Comments? John _______________________________________________ substrate-wg mailing list substrate-wg@... http://lists.geni.net/mailman/listinfo/substrate-wg |
|
|
|
Re: Substrate Resouces
by Drew Perkins
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
John, et. al, The spreadsheet has entries under DWDM Terminal and
Optical Switch for “ITU Lambda” and “Alien Spectrum”.
ITU Lambdas could be pretty well-defined things through references to
appropriate ITU standards (G.694.1, etc.) though they are not yet well-refined
here. In particular they are going to have to be highly parameterized to
understand bandwidth, attenuation, chromatic dispersion, PMD, etc. etc. etc. I’m not sure what “Alien Spectrum” is
though. Can you please define this further? The whole concept of “alien
wavelengths” is a pretty undefined thing due to lack of appropriate standards.
But what is “Alien Spectrum”? Is that trying to refer to a “Wave
Band”? Drew
-----Original Message----- All, I modified the most recent version of the resource
spreadsheet (16 Nov 07) to include "User Opt-in traffic". I would
argue that multiple experiments which rely on realistic traffic scenarios,
would want to carry the User Opt-In traffic over their slice. In this case,
User Opt-In traffic may look like a network resource. As a reminder, we are
building this spreadsheet with a very wide filter in an effort to capture many
entries to be culled at a later date. Regarding test equipment, I suggest dividing this into
two categories; 1. stand-alone test equipment and 2. embedded measurements. The
latter recognizes the inherent ability of network device performance monitoring
functions. I have also included equipment for deep packet inspection. This will be an interesting subject as it raises an
important issue regarding privacy of User Opt-In traffic. Comments? John _______________________________________________ substrate-wg mailing list substrate-wg@... http://lists.geni.net/mailman/listinfo/substrate-wg |
|
|
|
Re: Substrate Resouces
by John Jacob-2
::
Rate this Message:
|
|
|
|
Re: Substrate Resouces
by stuart.d.elby
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Drew, all; I share your concern about alien wavelengths.
If the intent of including this concept as a resource is to allow
experimentation end-to-end with non-standard modulation formats and coding
schemes, then I suggest the following. We keep the spectrum plan (channel
centers and channel spacings) of the substrate aligned with ITU
standards. The ‘alien spectrum’ requirement is handled by
allocating the appropriate number of concatenated, unlit ITU channels to that
experiment. Your point about PMD, chromatic
dispersion, etc, is still the big problem facing a researcher wishing to launch
her own experimental optical signal across GENI. -Stu From:
substrate-wg-bounces@... [mailto:substrate-wg-bounces@...] On Behalf Of Drew Perkins John,
et. al, The
spreadsheet has entries under DWDM Terminal and Optical Switch for “ITU
Lambda” and “Alien Spectrum”. ITU Lambdas could be pretty
well-defined things through references to appropriate ITU standards (G.694.1,
etc.) though they are not yet well-refined here. In particular they are going
to have to be highly parameterized to understand bandwidth, attenuation,
chromatic dispersion, PMD, etc. etc. etc. I’m
not sure what “Alien Spectrum” is though. Can you please define
this further? The whole concept of “alien wavelengths” is a pretty
undefined thing due to lack of appropriate standards. But what is “Alien
Spectrum”? Is that trying to refer to a “Wave Band”? Drew
-----Original
Message----- All, I
modified the most recent version of the resource spreadsheet (16 Nov 07)
to include "User Opt-in traffic". I would argue that multiple
experiments which rely on realistic traffic scenarios, would want to carry the
User Opt-In traffic over their slice. In this case, User Opt-In traffic may
look like a network resource. As a reminder, we are building this spreadsheet
with a very wide filter in an effort to capture many entries to be culled at a
later date. Regarding
test equipment, I suggest dividing this into two categories; 1. stand-alone
test equipment and 2. embedded measurements. The latter recognizes the inherent
ability of network device performance monitoring functions. I have also
included equipment for deep packet inspection. This
will be an interesting subject as it raises an important issue regarding
privacy of User Opt-In traffic. Comments? John _______________________________________________ substrate-wg mailing list substrate-wg@... http://lists.geni.net/mailman/listinfo/substrate-wg |
|
|
|
Re: Substrate Resouces
by John Jacob-2
::
Rate this Message:
|
|
|
|
Re: Substrate Resouces
by Drew Perkins
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
John, Thanks for the clarification. In this case I suggest we
drop the word “Alien” and substitute the word “Optical”
as in “Optical Spectrum”. We’re simply talking about how to
carve out optical spectrum here whether it is in the form of multiple optical
channels or a single contiguous slice of bandwidth. Given what you said below
about not wanting to constrain us to the ITU grid or any other standards, I’d
also suggest substituting “Optical Channel” for “ITU Lambda”.
I will note that we also should do the same things on the wireless side. The
concepts of wireless channels and spectrum are currently missing. I’m
sure most people recognize that wireless and optical are almost identical
except for the frequencies involved. We might even consider how “DWDM Terminal” fits
into the larger scope of optical networking as DWDM is just one of several possible
multiplexing mechanisms to carve up optical bandwidth, e.g. OTDM and OCDMA. Drew
-----Original Message----- All; These are certainly valid concerns regarding unspecified
access to optical spectrum, especially as it pertains to dispersion
management, channel power balancing and alien power regulation.
However, at this stage we do not want to constrain GENI to the ITU grid or
any other standards. GENI could be comprised of different models,
e.g. some of the network based on the ITU grid wavelength services and
other portions open to arbitrary optical spectrum. The intent of alien
spectrum is to be broadly supportive of future research and not
necessarily solely for the purpose of non-standard mod formats and coding
schemes. However this does raise an important point. As we begin to build out
use-cases and cross-reference these with our "rich" resource
list, we will likely flag resources in need of stronger justification, i.e. use
cases. Alien spectrum, for example, could be such a resource. John stuart.d.elby@... wrote: > > Drew, all; > > I share your concern about alien wavelengths. If the
intent of > including this concept as a resource is to allow
experimentation > end-to-end with non-standard modulation formats and
coding schemes, > then I suggest the following. We keep the spectrum
plan (channel > centers and channel spacings) of the substrate
aligned with ITU > standards. The ‘alien spectrum’
requirement is handled by allocating > the appropriate number of concatenated, unlit ITU
channels to that > experiment. > > Your point about PMD, chromatic dispersion, etc, is
still the big > problem facing a researcher wishing to launch her
own experimental > optical signal across GENI. > > -Stu > >
------------------------------------------------------------------------ > > *From:* substrate-wg-bounces@... > [mailto:substrate-wg-bounces@...] *On Behalf Of
*Drew Perkins > *Sent:* Wednesday, November 21, 2007 12:18 PM > *To:* John Jacob; substrate-wg@... > *Subject:* Re: [substrate-wg] Substrate Resouces > > John, et. al, > > The spreadsheet has entries under DWDM Terminal and
Optical Switch for > “ITU Lambda” and “Alien
Spectrum”. ITU Lambdas could be pretty > well-defined things through references to
appropriate ITU standards > (G.694.1, etc.) though they are not yet well-refined
here. In > particular they are going to have to be highly parameterized
to > understand bandwidth, attenuation, chromatic
dispersion, PMD, etc. > etc. etc. > > I’m not sure what “Alien Spectrum”
is though. Can you please define > this further? The whole concept of “alien
wavelengths” is a pretty > undefined thing due to lack of appropriate
standards. But what is > “Alien Spectrum”? Is that trying to
refer to a “Wave Band”? > > Drew > > cid:image001.jpg@... > > Drew Perkins > > Chief Technology Officer > > Infinera Corporation > > 169 Java Drive > > Sunnyvale, CA, 94089 > > Direct: (408) 572-5308 > > Fax: (408) 904-4644 > > Mobile: (408) 666-1686 > > dperkins@...
<mailto:dperkins@...> > > http://www.infinera.com
<http://www.infinera.com/> > > -----Original Message----- > From: substrate-wg-bounces@... > [mailto:substrate-wg-bounces@...] On Behalf Of
John Jacob > Sent: Wednesday, November 21, 2007 5:28 AM > To: substrate-wg@... > Subject: Re: [substrate-wg] Substrate Resouces > > All, > > I modified the most recent version of the resource
spreadsheet (16 Nov > > 07) to include "User Opt-in traffic". I
would argue that multiple > experiments which rely on realistic traffic
scenarios, would want to > carry the User Opt-In traffic over their slice. In
this case, User > Opt-In traffic may look like a network resource. As
a reminder, we are > building this spreadsheet with a very wide filter in
an effort to > capture many entries to be culled at a later date. > > Regarding test equipment, I suggest dividing this
into two categories; > 1. stand-alone test equipment and 2. embedded
measurements. The latter > recognizes the inherent ability of network device
performance > monitoring functions. I have also included equipment
for deep packet > inspection. > > This will be an interesting subject as it raises an
important issue > regarding privacy of User Opt-In traffic. > > Comments? > > John > _______________________________________________ substrate-wg mailing list substrate-wg@... http://lists.geni.net/mailman/listinfo/substrate-wg |
|
|
|
Re: Substrate Resouces
by ibaldin
::
Rate this Message:
|
|
|
|
Re: Substrate Resouces
by John Jacob-2
::
Rate this Message:
|
Substrate WG - 16Nov07.xls (48K) 
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
