Re: Pointer processing issue
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
>-----------------------------------------