Re: AW: [EFM] PON Optics Telephone Conference, December 5th
Richard,
In reading my e-mail, I discovered a "typo". The correct sentence should
read: "Since 802.3ah PON 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."
Thank you,
Roy Bynum
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
>> >
>> > -----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@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
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >