Re: [EFM] Moving forward on extended temperature range optics
Jonathan,
I understand your concerns.
My thoughts were still evolving when I sent my initial proposal. My
goal was to get 802 out of the business of specifying multiple sets of
environmental conditions and yet provide defacto support for an extended
temperature range using market forces.
My thoughts on how to do this have evolved and my current thinking may
address some of the issues that you raise. Therefore, please consider
the following approach.
1) 802.3ah defines a single Extended Temperature Range.
2) 802.3ah requires that each pluggable 802.3ah (optical only?)
interface or group of interfaces be labeled with a color code, according
to the following rules, indicating the temperature range over which it's
operation is guaranteed. If the temperature range over which the
operation of the interface or group of interfaces is equal to or
includes the "802.3ah Extended Temperature Range", the interface(s)
shall be labeled with an operating temperature range color code of
COLOR1. If the temperature range over which the operation of the
interface or group of interfaces is neither equal to nor includes the
"802.3ah Extended Temperature Range", the interface(s) shall be labeled
with an operating temperature range color code of COLOR2. COLOR1 and
COLOR2 shall be complementary colors (to minimize the possibility of
creative use of colors that are difficult to classify as COLOR1 or COLOR2).
3) 802.3ah specifies COLOR1 shall be BLUE and COLOR2 shall be YELLOW.
(The selection of specific colors is obviously subjective and the TF
might prefer a different set of complementary colors.)
4) An interface or group of interfaces shall be compliant with all
specifications (electrical, optical, etc.) over the operating
temperature range that is claimed.
As should be immediately obvious, this approach focuses on a single
extended temperature whose definition is well specified and labeling
that is easily recognized and understood.
An interface must
Hopefully, this revised proposal is responsive to your concerns.
Thanks,
wlq
Jonathan Thatcher wrote:
>
> Bill,
>
> I am certainly in support of the labeling. But, I can't quite see the wonderment.
>
> If the equipment claims extended temperature compliance on its label, then
> 1. the compliance specifications must be clear (else, there is no meaning to compliance), and
> 2. the specifications must be common (else, there is no substance to this future standard), and
> 3. the work must meet the 5 criteria (else, there is no broad market potential for the work).
>
> Note: "specifications" above indicates not just the temperature range, but also all the optical specifications implicit with compliance to the standard.
>
> You are correct that no one will purchase equipment that doesn't meet their needs. This was never the question; this is a given. The question is whether 802.3ah will be specified as the solution of choice, or, in other words, whether or not 802.3ah meets the needs of the market. My point has been that without clear and unequivocal support for extended temperature, 802.3ah does not meet the broad requirements of the market.
>
> I see no fault in Howard's note responding to this same message with A) B) C) & D).
>
> jonathan
>
> | -----Original Message-----
> | From: Bill Quackenbush [mailto:billq@xxxxxxxxxxxxx]
> | Sent: Thursday, January 23, 2003 4:31 PM
> | To: Howard Frazier
> | Cc: stds-802-3-efm@ieee.org
> | Subject: Re: [EFM] Moving forward on extended temperature range optics
> |
> |
> |
> | All,
> |
> | After listening to this thread for a while, I am beginning to
> | wonder an
> | 802.3ah extended temperature specification is needed at all.
> |
> | It seems absolutely clear that customers who need extended range
> | operation simply will not buy equipment that is not rated for the
> | temperature range they require. If the vendors don't provide extended
> | temperature components and systems, the their stuff will not be
> | purchased. I think that this is an area where the market can function
> | quite well.
> |
> | I would suggest the following.
> |
> | 1) That 802.3ah define a single recommended extended
> | temperature range.
> |
> | 2) That 802.3ah REQUIRE that compliant systems and
> | field pluggable
> | components be clearly labeled with the operating temperature
> | range over
> | which their operation is guaranteed.
> |
> | Okay, flame shields have been raised :-)
> |
> | Thanks,
> |
> | wlq
> |
> | Howard Frazier wrote:
> | >
> | > Bruce,
> | >
> | > I never meant to imply that you or anyone else was suffering from
> | > Klew Deficit Disorder (with your help, we will find a cure).
> | >
> | > I was trying to get us focused on a specific task, and I think we
> | > are making progress. This is due in no small part to your
> | willingness
> | > to lead the effort.
> | >
> | > I am still mulling over the concept of adding an optional PICS item.
> | > At first blush, it seems okay to me, but I wonder if it is
> | truly necessary.
> | > I am not raising an objection to Jonathan's addition, just
> | scratching my
> | > head and thinking about it.
> | >
> | > I would like us to avoid writing a test procedure for
> | extended temperature
> | > operation. There are literally thousands of requirements
> | in IEEE Std 802.3,
> | > and they ALL have to be testable requirements, but ALMOST NONE of
> | > them has an associated test procedure written into the standard. The
> | > exceptions
> | > are cases where the requirement is unique to 802.3, and the
> | test procedure
> | > is not otherwise well documented.
> | >
> | > When it comes to temperature testing, there are reams of
> | documents and
> | > a vast amount of experience to rely on. I can't imagine
> | why we would write
> | > a test procedure for extended temperature operation into P802.3ah.
> | >
> | > I think we're getting very close to a solution. Anybody
> | see a serious flaw
> | > in the logic?
> | >
> | > Howard
> | >
> | > Bruce Tolley wrote:
> | >
> | > >
> | > > Howard
> | > > I did not mean to imply that we are totally clueless on what to do
> | > >
> | > > Yes 90% of the defining the 'WHAT" involves defining the
> | temperature
> | > > range for the OLTs and the remaining 10% is making sure the range
> | > > means something in the STD by having PICs for testing
> | operation over
> | > > the extended range.
> | > >
> | > > In short, I agree with Jonathan.
> | > >
> | > > Bruce
> | > >
> | > > At 12:56 PM 1/23/2003 -0800, Jonathan Thatcher wrote:
> | > >
> | > >> 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_3000190104v0
> | > >> | >> 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
> | > >> | >
> | > >> | >
> | > >> | >
> | > >> | >
> | > >> |
> | > >> |
> | > >> |
> | > >
> | > >
> | > >
> | > > 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
> | > >
> | > >
> | > >
> | > >
> |