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




Roy and all
I do not think Kent was asking a question about specifications but about 
the performance of what has been specified in IEEE 802.3ah.

I think I for one would like to see an answer to Question 1 before we go to 
working group ballot.  I recall that here was a presentation in Scotland 
that talked about the need to simulation and empirical data on this 
topic.//Bruce

At 10:08 PM 12/5/2002 -0600, 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
>> >
>> > -----Ursprngliche 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@cisco.com
>> > > 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
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >


Bruce Tolley
Senior Manager, Emerging Technologies
Gigabit Systems Business Unit
Cisco Systems
170 West Tasman Drive
MS SJ H2
San Jose, CA 95134-1706
internet: btolley@xxxxxxxxx
ip phone: 408-526-4534