RE: AW: [EFM] PON Optics Telephone Conference, December 5th
Roy-
At 11:37 AM 12/13/2002 -0600, Roy Bynum wrote:
Jonathan,
802.3ah is not a LAN product technology.
I have become resigned to that.
The inherent characteristics of Ethernet as
people have gotten used to them may no longer be
there.
This is the part that I have trouble with.
If this is the case then why are we doing the project?
If the only goal is to attach the Ethernet name to a "me too"
spec in the access space then I, for one, will vote against the
result.
When this work started it was for "Ethernet in the Last (First)
Mile".
I take that very seriously. I expect it to be just that.
If it turns out to be "Something that doesn't look like Ethernet in
the First Five Miles" then it will not have my support.
It may turn out that Ethernet does not perform
any better than any other protocol. It may not save any costs to
the service providers in its implementation, except perhaps to the end
customer.
Thank you,
Roy Bynum
Geoff
At 09:23 AM 12/13/2002 -0800, Jonathan
Thatcher wrote:
Roy,
What does "How 802.3ah will perform relative to the
"jitter" issue has yet to be seen. It is most likely that
the data stability that LAN people are used to will no longer be
there" mean?
Does extending the 5km to 10km impact jitter / data stability?
Does adding OAM frames impact jitter / data stability?
Does support of bidirectional rather than dual fiber transceivers impact
jitter / data stability?
Does EDSL solution impact jitter / data stability?
What, exactly, are you trying to say? That because of EFM, Ethernet is no
longer Ethernet?
jonathan
| -----Original Message-----
| From: Roy Bynum
[mailto:rabynum@xxxxxxxxxxxxxx]
| Sent: Friday, December 13, 2002 8:24 AM
| To: Mccammon, Kent G.; 'Richard Brand'
| Cc: Mccammon, Kent G.; stds-802-3-efm@ieee.org
| Subject: RE: AW: [EFM] PON Optics Telephone Conference, December
5th
|
|
|
| Kent,
|
| Until 802.3ah, Ethernet does not induce any jitter in the
| transmission of
| application data. I spent over a year in the lab looking at
| this. The
| 802.3 stack, up until now was a pure streaming environment
| without any
| store and forward queues.
|
| This may sound like a bit of heresy as I am the original host
| master for
| MCI. The worst culprit in inducing jitter in the transmission
of
| application data in today's environment is Internet Protocol.
| This occurs
| across all vendor lines using IP stack code from multiple
vendors. I
| believe that it is because the IP stack is fairly "deep"
and
| there are
| several locations in the stack where some form of "store and
| forward" is
| required. (Even forward looking code does not solve this
problem.)
|
| You can have your lab people verify this. Testing applications
in
| non-routing environments will change the level of jitter that
| introduced in
| the communications infrastructure. This effect of streaming
| switching was
| one of the main reasons that the "legacy free service
| providers" were able
| to deliver packet voice that had better clarity and sound
| quality than the
| local RBOC. Testing using a non-routing stack such as
| NetBEUI will change
| the amount of jitter that is introduced at the end systems
| supporting the
| applications. Interactive video becomes very "tight" in
a
| non-IP environment.
|
| How 802.3ah will perform relative to the "jitter" issue has
yet to be
| seen. It is most likely that the data stability that LAN
| people are used
| to will no longer be there.
|
| Thank you,
| Roy Bynum
|
|
|
| At 09:30 PM 12/8/2002 -0800, 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@xxxxxxxx;
| > > 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
| > > > > > >