RE: [EFM] Moving forward on extended temperature range optics
Piers and other optics experts in EFM,
I am left with a concern that we did not have the extended temperature range
and economic feasibility in mind when we made previous PMD decisions in EFM.
Perhaps I am jumping to conclusions since not everyone in the forum has
responded. So, my line of comments and questions are directed toward more
than Piers if others are so inclined.
If the optics technology is just not ready to deal with extended temps and
high reliability I would like to hear those arguments in this forum.
FTTCurb architectures that share a higher cost hardened optic among 16+
subscribers then becomes more viable than FTTH since optics cost is such a
large part of the overall cost. It may be FTTCurb market is really where
most Ethernet PMD vendors want to go after for near term profits. I
understand there is resistance to making extended temperature a normative
element in our document. Also, placing optics inside becomes a study topic
although I am fairly confident that model does not work well in single
family living units areas I want to try to serve with FTTH. I would like to
know what temperature range is supportable with little cost increase? Did
the SFP MSA consider extended temperature range in scope? Is that an area
where temperature is better suited to be hammered out?
I have heard many arguments about applying the vast volume of enterprise
Ethernet ports to lower the cost for access with an Ethernet based system.
The arguments for not doing extended temperature tells me that those volumes
don't necessarily apply when extended temperatures are part of the
requirements. If it was easy, I don't think this would be such a big issue.
I was hoping that IEEE could produce EFM specs heavily leveraging previous
specifications on B-PON, and finding ways to lower the cost of PON PMD.
Frankly, if it delivers services I can sell at a low cost, I don't care if
Ethernet, GFP, ATM is at Layer 2 on a PON. I believe this was the
methodology around taking Fiber channel specs and tweaking specs for GigE to
lower the cost. In other words, does leverage of enterprise Ethernet optics
volume really viable when extended temperature is a requirement?
Regards,
-Kent
Kent G. McCammon
Broadband Access
SBC Technology Resources, Inc
4698 Willow Road
Pleasanton, CA 94588
925-598-1246
kmccammon@xxxxxxxxxxx
> -----Original Message-----
> From: piers_dawe@xxxxxxxxxxx [mailto:piers_dawe@xxxxxxxxxxx]
> Sent: Tuesday, January 28, 2003 10:07 AM
> To: Jonathan.Thatcher@worldwidepackets.com; stds-802-3-efm@ieee.org
> Cc: billq@xxxxxxxxxxxxx
> Subject: RE: [EFM] Moving forward on extended temperature range optics
>
>
>
> "The road to hell is paved with good intentions". I thought
> Bill and Howard had got the discussion onto a sensible
> footing but a process of feature creep seems to have set in
> immediately after.
>
> Let's repeat, for those who have not yet unsubscribed from
> this reflector: environmental conditions such as temperature,
> supply voltage and so on are considered out of the scope of
> the standard. So are customer-facing requirements (parts of
> a procurement spec) such as cost, reliability and labelling,
> and component temperature. 802 concentrates on
> interoperability requirements: observable behaviour at ports.
>
> That doesn't mean we should not discuss the other conditions,
> as far as they relate to technical and economic feasibility
> or broadness of market. We can "take on" the temperature
> issue in that sense, and seek optical parameters which are
> compatible with the access environments. But we won't make
> normative requirements out of them in our standard; we'll
> leave that to the buyers, who will.
>
> We have reconciled these two conditions with an overwhelming
> vote for an informative annex. Let us all honour that agreement.
>
> An informative annex wouldn't have a PICS.
>
> We have better things to do with our time than re-invent
> wheels. We don't need to write temperature test procedures!
>
> As Bill points out, the market will provide the driving force
> for temperature specs. Following that thought, I would say
> that any environmental spec that 802 wrote would be futile -
> money talks; some operators will install their
> optoelectronics in sheltered locations and temperate
> climates, and save capex, whatever the standard says, others
> wish to install their optoelectronics in non-weatherprotected
> locations in extreme climates, whatever the standard says, to
> save opex. And it is the operator's $ that will encourage
> "more effort ... at the extended range", not empty words.
>
> Some have claimed that "access is different" and therefore we
> need to specify things which have been out of scope for many
> generations of the Ethernet standard. We compare with the
> traditional IT market where the temperature range is much
> less, so meeting it is not such a problem. But in that
> market, there still IS a temperature requirement, set by the
> market and documented in datasheets and purchase specs. Now
> in the access market, the temperature ranges are wider and
> the market is much less homogeneous. Does this mean that our
> methodology must change? Of course not, only our assumptions
> and the optical parameters which address them should change.
>
> Several people now have expressed an interest in the
> underlying issues of technical and economic feasibility or
> broadness of market (Howard's task A: Ensure that ... the ...
> Optical ... parameters ... can be met ... across an "extended
> temperature range" of operation). But while some people are
> still asking for normative material which they will vote
> against so that they can hold the standard to ransom, and
> which would waste a great deal more of our time to no effect
> (see market forces), it's difficult to have a reasonable
> discussion on these underlying issues.
>
>
> Now some information about labelling. The problem here is
> one of very restricted space and overlapping jurisdictions.
> Labels don't contain much, but that's OK, these days one can
> find the datasheet on the web. Labels have to obey national
> laws (safety marks, "made in") and the MSAs also have
> something to say:
>
> Quoting from the SFP MSA,
>
> "A5. Labeling of SFP Transceivers
> Color coding requirements for optical SFP transceivers are
> specified in Figure 1B. Each SFP transceiver should be
> clearly labeled. The complete labeling need not be visible
> when the SFP transceiver is installed. Labeling should
> include appropriate manufacturing and part number
> identification, appropriate regulatory compliance labeling,
> and a clear specification of the external port
> characteristics. The external port characteristic label may
> include such information as optical wavelength, required
> fiber characteristics, operating data rate, interface
> standards supported, and link length supported.
>
> Fig. 1B, note 4
>
> Color code: An exposed colored feature of the transceiver (a
> feature or surface extending outside the cage assembly) shall
> be color coded as follows:
> * Black or beige for multi-mode
> * Blue for single mode"
>
> And 802.3 has sections like "It is recommended that each PHY
> (and supporting documentation) be labeled in a manner visible
> to the user, with at least the applicable safety warnings and
> the applicable port type designation. Labeling requirements
> for Class 1 lasers are given in the laser safety standards
> referenced in ...."
>
> But I don't think this defeats Bill's idea; is it not the
> case already that the datasheet will give a temperature range
> (who would buy if it didn't) and an implementation claimed to
> be compliant to the (normative)
> optical/timing/electrical/protocol PICS must meet them over
> the stated temperature and supply ranges given in the
> datasheet. So I had thought Bill's point 4 was already covered.
>
> Piers
>