RE: Pointer processing issue
David,
I believe the stuff byte issue should be addressed in T1X1 and ITU, not
IEEE. The format and structure of the transmission systems that will be
supporting 10GbE is from T1X1 and ITU. P802.3ae is "borrowing" the
SONET/SDH standard framing to provide service and operational performance
reporting functionality needed for extended enterprise and Internet
networks. I think that if it is desire to use the "stuff" bytes as active
payload, then the issue needs to be brought to T1X1 and ITU.
Thank you,
Roy Bynum
At 03:37 PM 10/31/00 -0500, 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>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>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>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