RE: Pointer processing issue
Ben,
As you point out, this is not just an issue of being able to
configure the WIS to turn off the fixed stuff columns. The MAC
and the PCS have to know the average data rate provided by the
WIS. The MAC has to have the ifsExtensionRatio set to a value
that adjusts the non-idle data rate to fit within the WIS address
rate. If there is only one value for this parameter, then eliminating
the 63 fixed stuff columns will not give any higher packet
throughput. The extra space will just be idle.
Since the WIS not the PCS actually deletes the idles to
give WIS a payload at its average data rate, then the PCS
would also have to know the WIS average data rate. Depending
on how tightly the implementation links these two sublayers
(which will vary since they are not separated by a compatability
layer) this may be no extra effort or it may be a pain.
MAC, PCS and WIS all have to adapt to make use of the additional
bandwidth. How much bandwidth are we talking about. 63 columns
in 16,704 column payload. That is less than half a percent, 0.38%.
Therefore, I can not agree with your statement. I expect we
could come up with a mechanism for interoperability. But it
would be another option when we already have too many. The
gain just doesn't justify another option adding complexity.
Regards,
Pat Thaler
-----Original Message-----
From: Ben Brown [mailto:bbrown@xxxxxxxx]
Sent: Tuesday, October 31, 2000 4:32 PM
To: 802.3ae
Subject: Re: Pointer processing issue
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
-----------------------------------------