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

RE: AW: [EFM] PON Optics Telephone Conference, December 5th




Richard,
Controlling jitter over an Ethernet network is a project that we support in
other forums than 802.3ah.  My comment and question was  attempting to
gather more information in the debate over common PMD timing specifications.
If the Options A-D in the debate of PON timing have different possible
services enabled, I think that is a fair question to ask on this exploder.
I don't  support multiple Gigabit PON timing specifications each one for a
only subset of potential service applications. 
Thanks,
-Kent

> -----Original Message-----
> From: Richard Brand [mailto:rbrand@xxxxxxxxxxxxxxxxxx] 
> Sent: Friday, December 06, 2002 12:34 PM
> To: Roy Bynum
> Cc: kmccammon@tri.sbc.com; stds-802-3-efm@ieee.org
> Subject: Re: AW: [EFM] PON Optics Telephone Conference, December 5th
> 
> 
> Roy:
> So here we go.  I agree with everything you state except that 
> Kent did not ask about "Leased Circuit Private Line services 
> " or "Ethernet Private Line" but about T1 services over a 
> draft 802.3 P2MP network. In addition Ethernet private line 
> or leased line services are just as much out of scope for 
> 802.3 as is TDM based T1 services. That's why we have taken 
> on that work in the MEF with a close liaison to the ITU work 
> to which you make reference.  That also gets into 
> encapsulation, but that is surely out of scope for .3. 
> Therefore, I am correct in saying that your message did not 
> answer his question.  I do believe Arial's note makes an 
> attempt to address the efficiency question, but I
> believe that the potential for added jitter is real.   It is 
> however, out of scope
> for .3.  Kent, any comments?
> Regards,
> Richard
> 
> 
> Roy Bynum wrote:
> 
> > Richard,
> >
> > You are incorrect. 802.3 in and of itself can NOT be used 
> to provide 
> > Leased Circuit Private Line services. I am the author of 
> the term and 
> > definition of "Ethernet Private Line" services. Ethernet 
> Private Line 
> > is based on SONET/SDH, not 802.3
> >
> > ITU standards for leased circuit private line services specifically 
> > states that the customer of the leased circuit has exclusive use of 
> > the circuit facility. This is in contrast to "packet" 
> services that do 
> > emulation via a "virtual" circuit. Since 802.3ah PON does 
> not provides 
> > virtual circuit emulation via the frame "header", called a 
> "preamble" 
> > by 802.3 and not any type of physical or time based facilities 
> > segregation, it falls under the category of a 
> "packet/frame" service 
> > technology, not a leased circuit service technology.
> >
> > The existing ITU standards already provides for permanent virtual 
> > circuit emulation at fixed bandwidths over packet/cell 
> based services. 
> > These can be at T1 or any other fixed bandwidth.  The ITU standards 
> > makes a specific distinction between the "leased circuit" 
> services and 
> > the emulated circuit services over packet/cell/frame transport 
> > protocols.
> >
> > I didn't write the ITU standards. I just spent the last year that I 
> > was at Worldcom researching the specifics of defined standards for 
> > different types of data communications services.
> >
> > 802.3 in and of itself does not provide leased circuit private line 
> > services. The fact that a single customer using 802.3 can be 
> > provisioned as the only customer on a "dark" fiber, makes the dark 
> > fiber, a leased circuit private line service, not the 802.3. This 
> > format would also hold for 802.3ah copper facilities that 
> are used by 
> > a single customer.
> >
> > The service "Ethernet Private Line" is not based on an 
> 802.3 standard, 
> > other than it provides a "mapping" for Ethernet frames. The 
> ITU x.86 
> > "Ethernet over LAPS" provides for "mapping" of Ethernet frames into 
> > SONET/SDH by replacing the IFG/Preamble with LAPS, a HDLC 
> derivative 
> > and then using TDM nature of SONET/SDH to provision the 
> service as a 
> > standard leased circuit facility.  This would also hold for g.GFP.
> >
> > Thank you,
> > Roy Bynum
> >
> > At 02:40 PM 12/5/2002 -0800, Richard Brand wrote:
> > >Thomas:
> > >I would offer that Roy's note does not answer question 1 
> and I have 
> > >sent a note to Roy to detail.  As Kent is aware, there is 
> an ongoing 
> > >project in the MEF right now to specify circuit services (read TDM 
> > >including T1) over Ethernet including 802.3 networks.
> > >The timing issue could be critical to some implementations 
> and is one of the
> > >reasons I voted "no" in Kauai.  Vipal, do you want to take it on?
> > >Regards,
> > >Richard Brand
> > >
> > >
> > >
> > >Thomas.Murphy@xxxxxxxxxxxx wrote:
> > >
> > > > Hi Kent,
> > > >
> > > > Thanks for your input on this topic. I believe that question 1) 
> > > > has already been addressed by Roy Bynum; there are 
> others who are 
> > > > in a better position to answer this than me.
> > > >
> > > > Regarding testing I see two different levels/types of testing. 
> > > > Firstly there is module testing where different response times 
> > > > will not present a problem (the response time is 
> probably one of 
> > > > the parameters that would be determined). Beyond this there is 
> > > > then system/interoperability testing. When testing with
> > > 'non-intelligent'
> > > > equipment, the guardband between bursts would be set to the 
> > > > Upper-Bound values agreed upon. By guardband I mean the 
> time delay 
> > > > between the Tx_On signal and the time when the Rx 
> starts examining 
> > > > bit to determine the BER. With an intelligent system, i.e. 
> > > > protocol implementation with negotiated parameters,
> > > > interoperability is not a problem as the optimal 
> guardband is calculated.
> > > >
> > > > The above tests determine if one Tx communicates optically with 
> > > > the
> > > expected
> > > > BER
> > > > with another Rx. Setting the guardband equal to the upper limit 
> > > > determines that the timing requirements of the combined 
> link are 
> > > > met. Direct module testing delivers the individual Rx and Tx 
> > > > times.  Hence, I don't see a problem with testing 
> depending on the 
> > > > option choice for the timing parameters.
> > > >
> > > > Regards
> > > >
> > > > Tom
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Mccammon, Kent G. [mailto:kmccammon@xxxxxxxxxxx] 
> Gesendet am: 
> > > > Donnerstag, 5. Dezember 2002 02:45
> > > > An: Murphy Thomas (COM FO D O); stds-802-3-efm@ieee.org; 
> > > > Vipul_Bhatt@xxxxxxxx; wdiab@xxxxxxxxx
> > > > Betreff: RE: [EFM] PON Optics Telephone Conference, December 5th
> > > >
> > > > Tom,
> > > > Since I have a conflict with the call tomorrow and I am 
> interested 
> > > > in this decision, here are some questions.
> > > >
> > > > 1)Do any of the options for PON timing impact the delivery of 
> > > > services such as toll quality voice, a T1, or multicast 
> video? We 
> > > > had this concern previously and the answer previously 
> was claimed 
> > > > to be only an efficiency hit for loose timing. Are the modeling 
> > > > assumptions to compare efficiency valid for TDM services or is 
> > > > that not a consideration in this debate to date? 2)The 
> negotiation 
> > > > of timing parameters rather than a tight specification have any 
> > > > impact on future interoperability testing?  If we ever 
> decide to 
> > > > test interoperability of EPON OLT and ONT, can a lab testing 
> > > > system be reasonably built to test compliance to a 
> specification 
> > > > for OLT/ONT timing for the various options under debate? 3)Do 
> > > > operating temperature swings have an impact on timing 
> options. Is
> > > their
> > > > reason to add extra margin or extra negotiation time of timing 
> > > > parameters due to temperature variations? What about 
> cold start in 
> > > > cold temperatures, that was an issue for power levels, does it 
> > > > also impact the electronics of the PMD?
> > > >
> > > > Comment: As an advocate of PON technologies I echo my earlier 
> > > > comments
> > > about
> > > > striving for common PON PMD to get the volume started in today's
> > > economy.  I
> > > > am optimistic a compromise can be found in January. Thanks,
> > > > -Kent
> > > >
> > > > > -----Original Message-----
> > > > > From: Thomas.Murphy@xxxxxxxxxxxx 
> > > > > [mailto:Thomas.Murphy@xxxxxxxxxxxx]
> > > > > Sent: Wednesday, December 04, 2002 10:12 AM
> > > > > To: stds-802-3-efm@ieee.org; Vipul_Bhatt@ieee.org; 
> wdiab@xxxxxxxxx
> > > > > Subject: [EFM] PON Optics Telephone Conference, December 5th
> > > > >
> > > > >
> > > > > Hello Again,
> > > > >
> > > > > Attacted two possible approaches to this discussion 
> forming two 
> > > > > decision trees. Glen and I worked on these I I did not have a 
> > > > > chance to co-ordinate with him and refine to one slide.  The 
> > > > > first slide is mine and I would like to start here as 
> it allows 
> > > > > us to generate values without having to make 
> decisions. When the 
> > > > > values are agreed upon, we can work towards the decision and 
> > > > > perhaps this is simpler with the values we have.
> > > > >
> > > > > If this does not work, we can try the seconf slide, Glen's 
> > > > > approach, which is a more top-down attack.
> > > > >
> > > > > Talk to you tomorrow
> > > > >
> > > > > Tom
> > > > >
> > > > >  <<PON Timing Decision Tree.ppt>>
> > > > >
> > > > > Hello All,
> > > > >
> > > > > Items to Be Covered
> > > > >
> > > > > 1)  Determine the exact meaning of the terms "Fixed 
> Value" and 
> > > > > 'Upper Bound" in terms
> > > > >     of their use for PMD timing parameters.
> > > > >
> > > > > 2)  Try assign placeholder values for all of the options
> > > > >
> > > > > 3)  Are these values fixed or bounded for the 
> different options.
> > > > >
> > > > > 4)  Other items
> > > > >
> > > > > Regards
> > > > >
> > > > > Tom
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
>