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,

Kent did not make the distinction between packet voice services emulating a 
T1 and T1 private line business services.  This is important because the 
current vernacular for the term "T1" often refers to a leased circuit 
private line at 1.45 Mb effective bandwidth.

This type of confusion is similar to what has occurred with the term 
"broadband".  For many of us in the transmission industry, the term 
"broadband" means high bandwidth.  When the marketing of cable Internet 
services began to use the term "broadband" is was used to refer to the use 
of multiple channels at low bandwidths over a common media.  The use of the 
term "broadband" has lead many to believe that if refers to high bandwidth, 
when in reality, it does not.

In my initial response, I did make that distinction between packet voice 
services emulating a "T1" and the commonly understood leased circuit 
private line "T1".  I stated that packet voice services emulating at T1, 
similar to what ATM VBR does today, which is a "packet" service would be 
supported under current functionality of the 802.3ah PON.   I am not sure 
how stable constant bit rate services would be with the current PON, or its 
economic viability.

What I stated would not be supportable by the PON under current ITU 
standards would be leased circuit private line services, at any 
bandwidth.   This does not preclude dedicating the physical media, fiber or 
copper to the exclusive use of a single customer which would provide by 
default, the criteria for a leased circuit facility.

Thank you,
Roy Bynum

At 12:33 PM 12/6/2002 -0800, Richard Brand wrote:
>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@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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >