RE: [EFM] Moving forward on extended temperature range optics
Answers in line, with apologies for the delay in replying.
> -----Original Message-----
> From: Mccammon, Kent G. [mailto:kmccammon@xxxxxxxxxxx]
> Sent: 31 January 2003 01:00
> To: 'piers_dawe@xxxxxxxxxxx'; Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx;
> Cc: billq@xxxxxxxxxxxxx
> Subject: 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.
We have made decisions about optical specifications as favourable as we know how, for economic feasibility including the extended temperature range. Our wavelength ranges are wide enough, and in general as wide as we are allowed, given the fibre specs and the decision to enable a video overlay. The specs are temperature-agnostic in that a compliant transmitter and receiver can be at any temperature the manufacturer allows, and they will still interwork, and each end does not have to know or consider the temperature of the other end in any way. We have some work to do to validate the PON power levels and penalties but that is an absolute question not a temperature-related one.
The question that remains is: is the best we can do, really feasible enough? The committee will want to form an opinion about this over the coming months, just as in other generations of Ethernet. Ingredients which go into this decision include cost, price and temperature among others - all formally out of scope and not to be specified IN THE STANDARD. But people will (properly) vote for / against the standard because they think its implementations will / will not be economically viable.
> 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.
It's getting very close, and the situation varies from PMD to PMD. The most temperature-sensitive item is the laser. In recent years the industry has got better at making lasers that can run hot enough, but making them transmit well, on dispersive fibre, over a very large temperature RANGE, is a challenge. The 1000 Mb/s PMDs face more challenge than the 100 Mb/s ones, which I think people see as technically feasible.
For DFB lasers (for 1000 Mb/s - not needed at 100 Mb/s), one widely used manufacturing process deliberately delivers a range of DFBs in each batch, which are tested and sorted. Some are scrap, others will achieve different temperature ranges. A customer for the pick of the crop (most extended temperature fraction) benefits from the sale of the other fraction(s) of more "vin ordinaire" DFBs. So, unlike most mass production processes where all the parts can be made the same and commoditization drives costs and prices down, here some diversity in the market is good - a little like agriculture or oil refining. Attempts to outlaw non-premium temperature grades would be counter-productive and create a further cost obstacle to be surmounted. In today's financial conditions, we need an evolutionary path forward instead.
This effect would not be significantly affected by tweaking any specification. It's just the way DFBs are - years ago the "cure" was Peltier coolers, but the temperature range has been stretched.
> 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
It's one of those "last straw" situations: every additional 10'C of range is tougher than the one before. For example, -10 to 85'C might be noticeably easier at the optics level. "Difficulty" might go as the square of the temperature range, so -40 to 85'C (125'C range) is about 3 times more "difficult" than 0-70'C. But cost would be a very non-linear function of "difficulty".
> the SFP MSA consider extended temperature range in scope? Is
> that an area
> where temperature is better suited to be hammered out?
It seems that some recent MSAs have done a great deal of work on temperature and cooling, but what shows up in the MSA may be a very condensed output of a much larger study, and mostly I suspect they addressed the equipment room. An MSA would be a suitable place to define what is meant by the temperature of a transceiver (i.e. where do you measure it and how?).
Some MSAs define maximum temperatures which are not to be exceeded to stop people getting burns from hot metal surfaces. Presumably someone handling metal parts in a hot sunny desert just has to protect himself.
I don't have the specific answer about the SFP MSA.
> I have heard many arguments about applying the vast volume of
> 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.
There is still the point of principle about the "normative" angle: the fact because someone wants to install optics in a certain environment does not mean that someone else, who wants to address a different environment, should be burdened by extra costs for the first person's sake, and that we are writing a global standard for a diverse market. But you're right: if it was easy, no-one would spend their time trying to add it to a standard, they'd just define it on the purchase order - so the point would not arise.
> 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.
I believe the vast volume of enterprise Ethernet ports is still the right starting point. No-one wants to develop new technology for a fledgling market, in present financial conditions. Re-using and stretching the current technology is the best bet, and trying to create independent "economies of scale" for such nascent volumes, seems misguided; something like Ethernet has economies of scale; something that isn't like existing optics, doesn't.
In fact, under the surface it's the same semiconductor materials that are causing the same temperature issues whether it's enterprise or telecomms.
> 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?
> Kent G. McCammon
> Broadband Access
> SBC Technology Resources, Inc
> 4698 Willow Road
> Pleasanton, CA 94588
> > -----Original Message-----
> > From: piers_dawe@xxxxxxxxxxx [mailto:piers_dawe@xxxxxxxxxxx]
> > Sent: Tuesday, January 28, 2003 10:07 AM
> > To: Jonathan.Thatcher@worldwidepackets.com; firstname.lastname@example.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