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