RE: [EFM] Moving forward on extended temperature range optics
Piers,
One of the primary economic advantages that Ethernet has always had is that
very little in the way of interoperable functionality, including the
physical connector and specifications for the cabling, have been left to
the "procurement process". One of the hazards and a primary cause of the
higher costs of "telecom" has been that so much of the equipment
specifications have been left to the "procurement process". One of the
primary reasons for seeking the higher temperature specifications within
802.3ah was to standardize and hopefully reduce the cost of the physical
interface for the telecom industry by not leaving it to the "procurement
process".
Without the higher temperature specification and a PICS for it, a distinct
identity for the P2P optics might be in question. The ability of companies
that do not have their on test labs to be able to know that they are
getting standardized higher temperature environmental systems for their
service deployment would be in question without that higher operating
temperature specification with a PICS being part of the standard. To meet
these issues, I believe that having a PICS, a label, and possibly a visual
code identifier was the intention of those that voted to have the higher
temperature specifications as part of the objectives.
Thank you,
Roy Bynum
At 07:07 PM 1/28/2003 +0100, piers_dawe@xxxxxxxxxxx wrote:
>"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