Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [EFM] Moving forward on extended temperature range optics



Bruce:
Now you may be the one out of the country (Paris?) but I wanted to know the results of the phone conf in your first call.  Since  I was unable to attend, I would like to catch up.  Is another call scheduled?
Advise,
Richard

"Mccammon, Kent G." wrote:

Carlos and all,

At least we could try to agree on a common set of specifications including
temperature here in EFM, I think that would help from having a myriad of
different PMD types based on diverse operator temp requirements. Brian,
Rich, and I have tried to work with the group to develop common
specifications for temperature to be helpful. For a motivator, I wanted to
share with you a link showing an outside mounted ONT being deployed by a
utility in Washington state. It's the January Lightwave magazine story. Some
optics vendors want to serve this market for hardened optics clearly shown
here!

http://lw.pennnet.com/Articles/Article_Display.cfm?Section=Articles&Subsecti
on=Display&ARTICLE_ID=165755&KEYWORD=chelan

-Kent
> -----Original Message-----
> From: Carlos Ribeiro [mailto:cribeiro@xxxxxxxxxxxxxxxx]
> Sent: Friday, January 24, 2003 7:05 AM
> To: Mccammon, Kent G.; 'Jonathan Thatcher'; Howard Frazier
> Cc: stds-802-3-efm@ieee.org
> Subject: Re: [EFM] Moving forward on extended temperature range optics
>
>
>
> Kent,
>
> I couldn't agree more. I share about the same concerns as
> you. 802.3ah still
> has to realize as a whole what do 'market potential' and
> 'cost effectiveness'
> mean when you are talking about telecom AND customer devices.
>
> Carlos Ribeiro
> Independent Consultor
> (with no money to spend on EFM gear, but still believing it
> WILL happen)
>
> On Friday 24 January 2003 12:56 am, Mccammon, Kent G. wrote:
> > Howard,
> > I agree with Jonathan that an optional PIC would be a task for the
> > group. Its seems a reasonable compromise.
> >
> > I want to describe the reasons why hardening is a requirement in
> > response to your email asking for feedback.
> >
> > An inside ONT is not viable for FTTH for the existing residences in
> > the USA. Would subscribers want to allow someone to drill a hole in
> > your outside wall, run fiber and put a box in your closet, then run
> > the metallic wire back out to your NID? Since we are all
> engineers we
> > would probably say that we would do it just to have the
> privilege to
> > be a first adopter and the chance to pay more for higher
> speeds, more
> > channels. Most people would not want to do this work.  In addition,
> > when it fails and you need your service back, you allow the service
> > tech to arrange a visit to fix it and you stay at home for
> a certain
> > time and meet the service tech to let them in your house.
> Or, you can
> > have an outside ONT and the service tech stays outside and
> fixes the
> > box for you to get your service up as fast as possible
> whether you are
> > at home at the time.
> >
> > A controlled environmental vault for housing an ONU is really only
> > cost-effective for a thousand homes not for a neighborhood
> of 200 or a
> > street of 16 homes.  You can choose to cheapen the optics by not
> > hardening, but it still destroys the economics for the
> operators for
> > getting fiber deeper.  I would bet hardened optics  would not cost
> > more than drilling holes in walls or digging holes in the
> > neighborhood.
> >
> > Labor always will go up while equipment prices typically go
> down over
> > time. Hardening optics makes sense compared to more labor today and
> > into the future.
> >
> > What about reliability? If you want to put telephony on
> fiber deeper,
> > the vendor better qualify parts that withstand extended temperature
> > over long periods of time. The enterprise market for
> Ethernet NICS can
> > accommodate a lifetime of 3 years since speeds increase, not so for
> > access. The naysayers on FTTH say that putting optics at
> every home is
> > setting operators up for a maintenance nightmare compared to a
> > metallic network termination. While we would save
> maintenance cost by
> > not having to fix the copper when it rains, but it may get all the
> > cost back replacing failed optics at the ONT. Advocates for FTTcurb
> > suggest its better to have a node with only one expensive/hardened
> > optical PMD shared among many homes with a protected fiber link to
> > deal with optics that fail a lot in the outside plant.
> >
> > I have a growing concern about how feasible the current
> 802.3ah draft
> > optical specifications are today over a extended temperature range.
> > Can FTTH optics be qualified and hardened while still keeping cost
> > reasonable? Nothing I have heard in this discussion leads me to
> > believe companies who make optics for the enterprise
> Ethernet market
> > are eager to come to the plate and help with compliance to
> an extended
> > range. I suggest, making an attempt at compliance testing
> and writing
> > specs to allow cost reduction is one giant step toward
> feasibility for
> > our specs. If we confront extended temperature and work thru
> > compliance tests, we may find out now that we need to loosen
> > specifications and the promise of EFM can be strengthened.
> >
> > Hardening is really a solid requirement.  When IEEE said
> they would do
> > hardened optics for EFM, I took notice and told others that these
> > engineers are going to really address the optical access market. I
> > observe that taking on temperature  that has not been done in the
> > enterprise specs to date shows a serious dedication to addressing a
> > new access market.  I think those in the group have the
> expertise to
> > take this issue head on.  I personally don't know what
> other standards
> > group would be better to work the issue in a liaison.
> >
> > I have seen this group rule many topics out of scope over 2
> years.  I
> > am not going to support weakening extended temperature objectives.
> > The 802.3ah participants will be famous if specs developed
> can break
> > the cost barrier for hardened PMD's that is required for FTTH.  The
> > low-cost reputation of Ethernet enterprise ports could then
> really be
> > extensible to the access market.
> >
> > -Kent
> >
> > > -----Original Message-----
> > > From: Jonathan Thatcher
> > > [mailto:Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx]
> > > Sent: Thursday, January 23, 2003 12:56 PM
> > > To: Howard Frazier
> > > Cc: stds-802-3-efm@ieee.org
> > > Subject: RE: [EFM] Moving forward on extended temperature range
> > > optics
> > >
> > >
> > >
> > > Howard,
> > >
> > > I think that there is one additional essential task:
> > >
> > > C) Provide an ***optional*** PIC for each PMD indicating
> operation
> > > over the "extended temperature range."
> > >
> > > jonathan
> > >
> > > | -----Original Message-----
> > > | From: Howard Frazier [mailto:millardo@xxxxxxxxxxxxxxxxxx]
> > > | Sent: Thursday, January 23, 2003 9:19 AM
> > > | To: stds-802-3-efm@ieee.org
> > > | Subject: Re: [EFM] Moving forward on extended temperature
> > >
> > > range optics
> > >
> > > | I think that the essential tasks are to:
> > > |
> > > | A) Ensure that all of the Active Optical Input and
> Active Optical
> > > | Output Interface
> > > | parameters in clauses 58-60 can be met, and the
> corresponding links
> > > | function
> > > | properly, across an "extended temperature range" of operation.
> > > |
> > > | B) Define what an "extended temperature range" is, and
> place this
> > > | definition in an informative annex (Annex 66A) of P802.3ah.
> > > |
> > > | If we can do this, we will have satisfied our
> objectives and all
> > > | of our prior
> > > | motions on the subject, according to my interpretation.
> > > |
> > > | I believe that we are prepared to do this, and we
> should do this,
> > > | without further delay.  We will then have a follow on task to
> > > | prove that optical components and
> > > | links can simultaneously satisfy A and B above, and meet the
> > > | 5 criteria.
> > > |
> > > | We are past the point of deciding "what we are going to
> do". Our
> > > | job is to carry out our decisions, and to prove that we
> have done
> > > | so to the satisfaction
> > > | of our Working Group and our Sponsor.
> > > |
> > > | Howard Frazier
> > > | Chair, IEEE 802.3ah EFM Task Force
> > > |
> > > | Bruce Tolley wrote:
> > > | > Piers
> > > | >
> > > | > I am not exactly sure why you felt compelled to disagree
> > > |
> > > | with what was
> > > |
> > > | > essentially an invitation to a meeting, but here goes
> > > | >
> > > | > 1) Network operator requirements
> > > | > Yes not all the network operators from every region of the
> > > |
> > > | world are
> > > |
> > > | > coming to our meetings, but I think it speaks to broad market
> > > | > potential to listen to the customers who care enough
> to come and
> > > | > participate in the debate.
> > > | >
> > > | > Yes, network operators want all kinds of things and often
> > >
> > > different
> > >
> > > | > things, but we are discussing optical PMDs across extended
> > > |
> > > | temperature
> > > |
> > > | > here. Let's not cloud the issue. We do not have goals to
> > > |
> > > | define fire
> > > |
> > > | > safety or 48V DC power over fiber optic cabling.
> > > | >
> > > | > 2) Scope
> > > | > We have a goal that defines the scope. Just because we have
> > > |
> > > | not done
> > > |
> > > | > things in the past, does not mean we cannot do it in this
> > > |
> > > | project if
> > > |
> > > | > it is within our charter as defined by the PAR and our
> > > | > objectives. 802.3 never worked on an electrical power
> spec and
> > > | > it is now completing (rapidly I hope) the  DTE power.
> We define
> > > | > many interfaces and performance parameters in our
> > > |
> > > | documents
> > > |
> > > | > some of which are not exposed as external interfaces to end
> > > |
> > > | customers
> > > |
> > > | > or testable by end customers.
> > > | >
> > > | > 3) Interpretation of Past motions
> > > | > The thread of motions shows that we are trying to fulfill the
> > > | > objective but we are not quite sure of the path to
> success.  My
> > > | > personal opinion is that if the extended temperature ranges
> > > |
> > > | are only
> > > |
> > > | > informative, we will not be fulfilling the objective. Some
> > > |
> > > | good work
> > > |
> > > | > has gone into the draft, but we still have some real
> > > |
> > > | technical work to
> > > |
> > > | > do. The Task Force voted down the motion that said P802.3ah
> > > | > would define two sets of optical PMDs but gave us no clear
> > > |
> > > | direction on how
> > > |
> > > | > to move forward.
> > > | >
> > > | > Thanks
> > > | >
> > > | > Bruce
> > > | >
> > > | > At 03:54 PM 1/23/2003 +0100, piers_dawe@xxxxxxxxxxx wrote:
> > > | >> Bruce, Brian and Richard,
> > > | >>
> > > | >> I'd like to point out where this chain of thought
> goes wrong,
> > > | >> especially as the logical disconnects have been repeated
> > > |
> > > | later in the
> > > |
> > > | >> thread.  See below:
> > > | >> > -----Original Message-----
> > > | >> > From: Bruce Tolley [mailto:btolley@xxxxxxxxx]
> > > | >> > Sent: 16 January 2003 19:59
> > > | >> > To: piers_dawe@agilent.com; stds-802-3-efm@ieee.org
> > > | >> > Subject: [EFM] Moving forward on extended temperature
> > > |
> > > | range optics
> > > |
> > > | >> > Piers and all
> > > | >> >
> > > | >> > I gave my self the action to help move forward the
> > > |
> > > | outstanding issue
> > > |
> > > | >> > regarding extended temperature ranges for P2P and
> P2MP optics
> > > | >> >
> > > | >> > We have an objective to include in our
> specification of PHYs,
> > > | >> > support for extended temperature range optics
> > > | >>
> > > | >> Yes.  Support, not mandatory requirement.
> > > | >>
> > > | >> > The task force has in the past passed motions to
> specify EFM
> > > | >> > optics at -40 to +85 C
> > > | >>
> > > | >> To specify the optics, not the temperature.  This is very
> > > |
> > > | clear from
> > > |
> > > | >> the January and March 2002 motions.  See e.g. the March
> > > |
> > > | Joiner motion
> > > |
> > > | >> "The basis for the first draft of the 802.3ah
> > >
> > > 1000Base-LX extended
> > >
> > > | >> temperature objective be met with text that uses
> > >
> > > 1000Base-LX 5 km
> > >
> > > | >> single mode specification (clause 38) as the starting
> > > |
> > > | point with the
> > > |
> > > | >> following changes and additions:
> > > | >> - Informative temperature range -40-+ 85 deg C
> > > | >> etc
> > > | >>
> > > | >> and
> > > | >>
> > > | >> January Motion #11
> > > | >> Motion: to create informative annex to address environmental
> > > | >> considerations.
> > > | >> Mover: Chris DiMinico
> > > | >> Second: Alan Flatman
> > > | >>
> > > | >> > Network operators have on multiple occasions
> communicated the
> > > | >> > requirement for extended temperature solutions.
> > > | >>
> > > | >> This is where the logic really falls apart.
> > > | >>
> > > | >> First, is it not just a small subset of network operators
> > > |
> > > | (US ones)
> > > |
> > > | >> who aren't installing much FTTB.  Other network
> > >
> > > operators may have
> > >
> > > | >> different physical strategies, climates, and requirements.
> > > | >>
> > > | >> Second, network operators need many things; working capital,
> > > | >> fire safety, an electricity supply...  It does not follow
> > >
> > > that 802.3 is
> > >
> > > | >> bound to provide any of them.  Environmental
> > >
> > > requirements such as
> > >
> > > | >> these are out of scope of this standard - that's why
> > > |
> > > | temperature is
> > > |
> > > | >> to be addressed in an informative annex.
> > > | >>
> > > | >> Of course, customers will impose environmental
> > > |
> > > | requirements in their
> > > |
> > > | >> procurement specs - and Telcordia specs for example are
> > > |
> > > | effectively,
> > > |
> > > | >> procurement specs.
> > > | >>
> > > | >> > As recently as the Vancouver meeting, several box vendors
> > > | >> > (including me)b communicated the requirement for extended
> > > | >> > temperature range optics.
> > > | >>
> > > | >> Same lack of connected logic.  Someone's need doesn't mean
> > > |
> > > | that 802.3
> > > |
> > > | >> is bound to supply.  Temperature specs are available in
> > >
> > > the market
> > >
> > > | >> from other sources, who have more expertise in the matter.
> > > | >>
> > > | >> Piers
> > > | >>
> > > | >> > We need
> > > | >> > to agree on a path to move forward.
> > > | >> >
> > > | >> > So if interested parties want to forward to me their email
> > > | >> > addresses, I will host a conference call next week
> > >
> > > dedicated to
> > >
> > > | >> > this issue. I think we
> > > | >> > need to focus on a test specified in each PMD clause, to
> > > |
> > > | agree on the
> > > |
> > > | >> > ranges for OLT and ONU optics, to consider the
> > >
> > > possible special
> > >
> > > | >> > case of bidis that include 1550 nm DFBs, and to
> > >
> > > identify any PMD
> > >
> > > | >> > that might only
> > > | >> > need to be supported at standard, commercial temperatures.
> > > | >> >
> > > | >> > thanks
> > > | >> >
> > > | >> > Bruce Tolley
> > > | >> > Cisco Systems
> > > | >> >
> > > | >> >   At 04:11 PM 1/8/2003 +0100, piers_dawe@xxxxxxxxxxx wrote:
> > > | >> > >G.983.3 refers to ETS 300 019.  This is a very readable
> > > |
> > > | series of
> > > |
> > > | >> > >documents from the European Telecommunications Standards
> > > | >> >
> > > | >> > Institute, giving
> > > | >> >
> > > | >> > >a classification of environmental conditions, e.g.
> > > |
> > > | weatherprotected
> > > |
> > > | >> > >locations, non-weatherprotected, underground.  It
> uses four
> > > | >> >
> > > | >> > classes of
> > > | >> >
> > > | >> > >climatic conditions:
> > > | >> > >         "applies to most of Europe"
> > > | >> > >         extended
> > > | >> > >         extremely cold
> > > | >> > >         extremely warm dry
> > > | >> > >
> > > | >> > >And even better, up-to-date drafts are available on the
> > > |
> > > | web, e.g. at
> > > |
> > > | >> >
> >http://webapp.etsi.org/action%5COP/OP20030321/en_3000190104v
> > > | >> > >0
> > > | >>
> > > | >> 20101o.pdf .
> > > | >>
> > > | >> >It is not the business of 802 to pick between these
> > > |
> > > | classes but we can
> > > |
> > > | >> >refer the readers of our standard to this information.
> > > | >> >
> > > | >> >ITU-T and ANSI T1 do not have similar documents.
> > > | >> >
> > > | >> >Both G.983.3 and refer to IEC 60721, classification of
> > > |
> > > | environmental
> > > |
> > > | >> >conditions.
> > > | >> >
> > > | >> >IEC 60721-3-4 - Ed. 2.0  Classification of environmental
> > > |
> > > | conditions
> > > |
> > > | >> - Part
> > > | >>
> > > | >> >3: Classification of groups of environmental parameters
> > >
> > > and their
> > >
> > > | >> >severities - Section 4: Stationary use at
> non-weatherprotected
> > > | >> >locations  1995-01 is available for CHF99 at
> > > | >> >https://domino.iec.ch/webstore/webstore.nsf/artnum/019208 .
> > > | >> >
> > > | >> >Piers
> > > | >>
> > > | >> 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
> > > | >
> > > | > 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
>

begin:vcard 
n:Brand;Richard C.
tel;work:(408) 495 2462  ESN 265 2462
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:rbrand@xxxxxxxxxxxxxxxxxx
fn:Richard C. Brand
end:vcard