Option to use 63 Fixed Stuff columns for payload
David,
I understand and appreciate your position. There may be other players
that will prefer the option to bypass the fixed stuff feature.
I would like to hear from the wider membership on this issue. Does
anyone else out there care about this issue?
My rather simple recommendation is that:
1. The use of 63 fixed stuff columns is the default mode and is
required. No change.
2. The present codepoint for the C2 Signal Label is the default and
identifies the use of fixed stuff. No change.
3. The use of those 63 columns be optionally available for payload
codewords. New addition.
4. That the choice of this new option be encoded in a new C2 Signal
Label codepoint, value tbd. New addition.
No functional changes are involved -- this is an optional addition. I
will write the text for the necessary addition
after I have obtained a copy of the document.
Thanks for your consideration
Gary
David Martin wrote:
>
>
> Dr. Gary Nelson,
>
> I believe that maintaining compatibility with SDH is
> important & that it be achieved without provisioning
> effort - that's why we proposed the current WIS format.
>
> Note that something like an 'ELTE' would be doing the
> conversion to/from virtual concatenation - that's why
> such details haven't been presented, it's out of scope.
>
> ...Dave
>
> -----Original Message-----
> From: Dr. Gary Nelson [mailto:gnelson@xxxxxxxxxx]
> Sent: Monday, October 30, 2000 1:00 PM
> To: Martin, David [SKY:1I63-M:EXCH]
> Cc: Louis Lin; stds-802-3-hssg@xxxxxxxx
> Subject: Re: Pointer processing issue
>
>
> The qustion about setting the pointer to 522 is the function of the
> originating SONET/SDH Path terminating equipment.
> PTE sets the pointer to some default value and never changes it. 522
> is
> a comforting choice that puts the payload envelope in alignment
> with the Transport Frame, but that has no particular significance from
>
> the bigger network-wide picture. At STS-192c, there is at
> present no SONET or SDH equipment that can process the pointer, but
> when
> there is, it will be necessary for the receiving end
> to be able to deal with different incoming pointer values and also for
>
> changes in the position of the pointer as encoded by pointer
> justifications. The general purpose de-mapping of the 64:66 code will
> need to be able to handle arriving pointer justifications.
>
> In my opinion, we ought to make using the capacity those 63 Fixed
> Stuff
> columns an Option that can be provisioned as required by the users
> of the equipment and/or services. The only reason to squander those
> 63
> columns is to support Virtual Concatenation which might or might
> not be important to any specific application. Virtual Concatenation is
>
> used by some carriers to transport big pipes as integer multiples of
> the VC-4/(STS-3c SPE). It is the SONET/SDH equivalent of Inverse
> Multiplexing where the big pipe payload is eqally divided among the
> VC-4 components and sent across the network to be switched and
> processed
> by VC-4/AU-4 crossconnects and the like. At the receiving
> end, the constituent VC-4s will arrive with different delays and hence
>
> different pointer values. Like BONDING for 64kb/s circuits, delay is
> added to the different VC-4 parts to get them all into alignment so
> that
> the big pipe service can be recreated.
>
> The liklihood is very high that this Virtual Concatentaion service
> delivery will be less important than point-to-point delivery over
> wavelengths.
> 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
>
--
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