Re: AW: [EFM] PON Optics Telephone Conference, December 5th
Richard
The issue about commonality with other forums might be a rathole, but I
think it is still legitimate to ask about the performance of the protocol
and for the sub TF to be prepared to show the TF and the WG simulated and
empirical data that shows acceptable performance.
After all we signed up in our PAR and 5 criteria to write a document that
would specify technology that would be technically feasible and have broad
market potential.
Bruce
.At 11:57 PM 12/12/2002 -0800, Richard Brand wrote:
>Kent:
>I fully agree and as a previous component vendor, I support your combined
>volume
>question to those PMD vendors and would say that I have not yet seen a
>satisfactory answer. I would recommend that you vendors not be myopic
>about the
>commonality question and look to those SP's that have trials in place. There
>are still many variables in this first mile Ethernet equation.
>Sincerely,
>Richard
>
>
>"Mccammon, Kent G." wrote:
>
> > 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > >
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