RE: Option to use 63 Fixed Stuff columns for payload
Gary:
I concur with David's assessment for the need for continued compatibility
between SDH and SONET wrt the fixed stuff bytes in columns 30 and 59 of the
STS-1 frame. (See T1X1.5/2000-193 "Revised Draft T105 SONET Base Standard"
ftp://ftp.t1.org/pub/t1x1/2000x15/0x151930.doc).
I think you are mistaken about the connection of these stuff bytes and
virtual concatenation. They in fact have nothing to do with the
implementation virtual concatenation at all. High order virtual
concatenation (defined for STS-1 and STS-3c) in SONET embeds its control
overhead in a multiframe that is created from the H4 byte of the POH.
Sequence numbering, group identification, frame numbers etc. all are sourced
from this H4 generated multiframe.
For more details on virtual concatenation please see the document cited
above.
Regards,
Nevin R. Jones
Lucent Microelectronics
Rm 7E-321
Murray Hill, NJ
07974
Ph: 908-582-5343
Fax: 908-582-4185
nrjones@xxxxxxxxxx
> ----------
> From: Dr. Gary Nelson[SMTP:gnelson@xxxxxxxxxx]
> Sent: Tuesday, October 31, 2000 7:00 PM
> To: David Martin; IEEE 802.3ae HSSG
> Subject: 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
>
>