RE: AW: [EFM] PON Optics Telephone Conference, December 5th
Geoff
I have
broadly similar views to yours, as expressed in my email just after the LA
interim (which should be on the archive).
I
particularly dislike the prospect of an access method other than null (as in p2p
full duplex) or CSMA/CD being part of the Ethernet CSMA/CD standard. I don't
have a problem with a full duplex symmetric DSL PHY so long as the payload is
Ethernet frames and the MAC access method is null.
Sorry
Gerry, I just do not approve of the gate function in EPON, however, I am
not going to hinder progress by making formal negative comments at this stage.
If enough 802.3 people support the final draft I will abstain on EPON
issue.
Best
regards
Bob
-----Original Message-----
From:
owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Geoff
Thompson
Sent: 16 December 2002 05:25
To: Roy
Bynum
Cc: Jonathan Thatcher;
stds-802-3-efm@ieee.org
Subject: 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
| > > > >
> >