Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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@lucent.com

> ----------
> From: 	David Martin[SMTP:dwmartin@nortelnetworks.com]
> 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@lucent.com] 
> 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@lucent.com 
> 
> > ---------- 
> > From:         Dr. Gary Nelson[SMTP:gnelson@zynrgy.com] 
> > 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@zynrgy.com] 
> > > Sent: Monday, October 30, 2000 1:00 PM 
> > > To: Martin, David [SKY:1I63-M:EXCH] 
> > > Cc: Louis Lin; stds-802-3-hssg@ieee.org 
> > > 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@zynrgy.com 
> > > 
> > 
> > -- 
> > 
> > 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@zynrgy.com 
> > 
> > 
> 
>