RE: Option to use 63 Fixed Stuff columns for payload
Dave:
We are aligned.
Regards,
Nevin R. Jones
Lucent Microelectronics
Rm 7E-321
Murray Hill, NJ
07974
Ph: 908-582-5343
Fax: 908-582-4185
nrjones@xxxxxxxxxx
> ----------
> From: David Martin[SMTP:dwmartin@xxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, November 01, 2000 7:20 PM
> To: IEEE 802.3ae HSSG
> Subject: RE: Option to use 63 Fixed Stuff columns for payload
>
>
> Nevin,
>
> Isn't it fair to say that the fixed stuff columns ensure that
> the source VC-4-64c payload rate equals the combined
> payload rates of 64x STM-1s? That way there is no rate adaptation
> required. I think the context of the discussion to date has
> centered around bandwidth/rate. I agree that the actual sequencing
> etc is contained in POH - no one would know that topic better than you.
>
> ...Dave
>
> -----Original Message-----
> From: Jones, Nevin R (Nevin) [ mailto:nrjones@xxxxxxxxxx]
> Sent: Wednesday, November 01, 2000 2:14 PM
> To: Martin, David [SKY:1I63-M:EXCH]; IEEE 802.3ae HSSG; 'Dr. Gary
> Nelson'
> Cc: Jones, Nevin R (Nevin)
> Subject: 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
> >
> >
>
>