Re: Pointer processing issue
I whole heartedly agree to it. It is easy to get caught in small
incremental improvements,
and once they get in standard they cost huge in terms of design and
verification (remember
the burst mode and 64K byte limit for half duplex mode for Gigabit) at
later stage.
Regards,
Tripathi.
At 11:50 AM 11/1/00 -0800, Norival Figueira wrote:
>All,
>
>I want to make sure we all understand what we gain with this
>discussion. According to my calculations, using the 63 columns for
>data increases the payload rate to 9.620928Gb/s from 9.58464Gb/s.
>This is an increase of 0.036288 Gb/s (or 0.38%). Is it worth the
>implications described below to allow for both options? I guess
>not. We should have only one option. The one that always works
>is the one we have in the draft.
>
>Regards,
>Norival
>
>
>At 07:32 PM 10/31/00 -0500, Ben Brown wrote:
>
>
> >David,
> >
> >Thanks for putting me on the spot :)
> >
> >I don't know too much about the uses or requirements of the 63
> >fixed stuff columns in the SPE. It seems to me that this type
> >of a change has larger ramifications to the entire standard.
> >
> >Yes, this feature can be provisioned.
> >
> >Yes, it is another option adding 1 more piece of confusion to
> >an already confusing part of the standard (how the WAN fits
> >into a LAN standard...).
> >
> >I doubt that WAN PHY A, provisioned to insert and expect the
> >63 columns can easily interoperate with WAN PHY B, provisioned
> >to use that space for payload. How do they sort that out?
> >Without any "auto negotiation", is this another OAM&P field
> >that needs to be sorted out at connection time like path trace?
> >
> >The MAC then needs to change its ifsStretchRatio value based
> >on what type of WAN PHY it is attached to.
> >
> >These are just a few thoughts that come to mind about this
> >topic. I'm sure others have concerns even further ranging
> >than mine.
> >
> >I'd love to hear a response to the comment:
> >
> >"If we could specify an option where the 63 fixed stuff columns
> >are available for payload, and the general consensus is that
> >(non)interoperation wouldn't be an issue, then I could agree."
> >
> >Ben
> >
> >> David Martin wrote:
> >>
> >> Gary,
> >>
> >> Being a transmission person I can appreciate your effort
> >> to optimize available bandwidth. However, I thought we had an
> >> underlying goal of minimizing optionality & provisioning
> >> in order to continue to provide the plug 'n play feature
> >> Ethernet is reknown for.
> >>
> >> If we could specify an option where the 63 fixed stuff columns
> >> are available for payload, and the general consensus is that
> >> (non)interoperation wouldn't be an issue, then I could agree.
> >>
> >> I'd like to hear from some of the longtime members for direction.
> >> Ben?
> >>
> >> ...Dave
> >>
> >> -----Original Message-----
> >> From: Dr. Gary Nelson [mailto:gnelson@xxxxxxxxxx]
> >> Sent: Tuesday, October 31, 2000 3:09 PM
> >> To: Martin, David [SKY:1I63-M:EXCH]
> >> Cc: Prosun Chatterjee; Louis Lin; IEEE 802.3ae HSSG
> >> Subject: Re: Pointer processing issue
> >>
> >> David and all,
> >> I agree that we need to retain the stuff columns as a requirement, but
> >>
> >> that is not
> >> to say that NOT using them cannot be an option. What you describe is a
> >>
> >> valid
> >> application, and perhaps it is specifically a market you are
> >> targeting.
> >> No problem.
> >>
> >> But there is no need to burden applications that do not require SDH
> >> virtual concatenation
> >> with the fixed stuff columns. The equipment vendor who devleops
> >> products
> >> with the *option*
> >> to disable fixed stuff will have no problem provisioning an SDH
> >> service
> >> with the feature as long
> >> as it is REQUIRED. And in many applications, it should be the case
> >> that
> >> the same provisioning tools
> >> could simply turn off the feature.
> >>
> >> Is your position that for the life of this standard, all
> >> STS-192c/STM-64-VC-4-64c services will be done by
> >> virtual concatenation? If that were to be the case, then I would
> >> agree
> >> that the fixed stuff option cannot be optional.
> >> However, I don't think that will be the reality, and I doubt if you
> >> do.
> >> OC-768/STM-256 products are in the pipeline already.
> >> We can't assume that they will fail to reach the market. Once a
> >> service
> >> provider can provision an STS-192c
> >> path circuit without using virtual concatenation, then all we would
> >> need
> >> is a second C2 Signal Label that says
> >> "10GbE without fixed stuff". Then it is a provisioning option, and
> >> good
> >> capitalists will get to decide what to
> >> do with the bandwidth they are selling and buying. In my opinion, it
> >> is
> >> simply good business to offer flexibility
> >> where it costs nothing real to do so. There is no cost to adding this
> >> level of flexibility.
> >>
> >> Best regards,
> >> Gary
> >>
> >> David Martin wrote:
> >>
> >> > Prosun,Our job is to define a 10GE WAN PHY compatible with
> >> > currentinfrastructure. To achieve this for the SDH market we need
> >> > toretain the 63 stuff columns. At the WAN edge, for example
> >> an'ELTE',
> >> > the translation to 64x STM-1s virtually concatenatedwould be done.
> >> At
> >> > that point the 64 pointers etc are generated.At the egress ELTE
> >> > the 10GE WAN PHY (VC-4-64c) would be reconstructed....Dave
> >> >
> >> > -----Original Message-----
> >> > From: Prosun Chatterjee [mailto:prosun@xxxxxxxxxxxxxxx]
> >> > Sent: Tuesday, October 31, 2000 12:29 AM
> >> > To: Dr. Gary Nelson; Martin, David [SKY:1I63-M:EXCH]
> >> > Cc: Louis Lin
> >> > Subject: RE: Pointer processing issue
> >> >
> >> >
> >> >
> >> >
> >> > Hi,
> >> >
> >> > I am a bit unclear on this:
> >> >
> >> > Ref. from Dave's mail : It's the port card on the source
> >> > equipment that splits, for example, a VC-4-64c POS signal
> >> > fabric side) into 64x STM-1s (fiber side). The transport
> >> > equipment only sees the 64x STM-1s.
> >> >
> >> > My confusion: is this ('port card')a patch work thought
> >> > out by vendors to support concatenation which otherwise
> >> > they couldn't?
> >> >
> >> > In this case, isn't it incorrect, since according to the
> >> > SDH standards, the other pointers are set to the
> >> > concatenation indication?
> >> >
> >> > I.e, they SHOULD NOT be interpretted individually; while
> >> > this 'port card' does a patch work of rewriting the pointer
> >> > over all the pointer bytes. - is this what it does? And,
> >> > if so, should we support it.
> >> >
> >> > If no, I tend to agree with Gary's argument of putting in
> >> > optional usage of the 63 bytes.
> >> >
> >> > Prosun
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: Dr. Gary Nelson [mailto:gnelson@xxxxxxxxxx]
> >> > Sent: Monday, October 30, 2000 11:30 PM
> >> > To: David Martin
> >> > Cc: Louis Lin; stds-802-3-hssg@xxxxxxxx
> >> > Subject: Re: Pointer processing issue
> >> >
> >> > .................(cut out)
> >> >
> >> > When Virtual Concatentation is used, then we must have the
> >> > means to
> >> > generate those Fixed Stuff colums. But when the service is
> >> > P-P over
> >> > a wavelength, there is no need whatsoever to support Fixed
> >> > Stuff.
> >> >
> >> > The WIS mapping makes no mention of the complex mechanism of
> >> > handling 64
> >> > separate pointers to do Virtual Concatenation, so it looks
> >> > as if we are assuming that point to point delivery will be
> >> > the norm. If
> >> > so, make the fixed stuff columns Required, but make turning
> >> > off that
> >> > feature Optional. That will improve the overall value of the
> >> > standards
> >> > we are defining.
> >> > --
> >> >
> >> --
> >>
> >> Dr. Gary A. Nelson
> >> Zynrgy Group Inc
> >> 20708 Deerpath Road
> >> Barrington, IL 60010-3787
> >> USA
> >> +1.847.304.0000
> >> +1.847.304.1929 fax
> >> gnelson@xxxxxxxxxx
> >
> >--
> >-----------------------------------------
> >Benjamin Brown
> >AMCC
> >2 Commerce Park West
> >Suite 104
> >Bedford NH 03110
> >603-641-9837 - Work
> >603-491-0296 - Cell
> >603-647-2291 - Fax
> >603-798-4115 - Home Office
> >bbrown@xxxxxxxx
> >-----------------------------------------
Best Regards,
Devendra Tripathi
Vitesse Semoconductor Corporation
3100 De La Cruz Boulevard
Santa Clara, CA 95054
Phone: (408) 986-4380 Ext 103
Fax: (408) 986-6050