Subject: Optcial Interface MIB status

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Mon, 22 Jul 2002 17:52:26 -0400

Dear all,

The Optical Interface MIB version 05, which incorporates all the resolutions from the Doctor review, has been discussed in the Yokohama meeting. The meeting confirms the acceptance of the resolutions.

For the banded amplifier proposal (Rishi's July 3 email), 
the meeting accepts the proposal. I will incorporate Rishi's proposed text into the next version (-06) of the mib. Note that as pointed out by Mike on July 8 and concurred with by Rishi on July 9, the optIfOChGroupCurrentStatus object will not be incorporated into version -06. Also the associated optIfOChGroupSinkGroupBasic GROUP will not be included.

For monitoring input, output power, and laser temperature on both source and transmit directions (Rishi's July 9 email): The meeting suggests to bring this to the list for any other DWDM vendor is supporting this.  If yes, incorporate Rish's suggestion.  If not, suggest to use the Sensor MIB done in the Entity MIB. So if there is additional support to this proposal, please raise to the list and provide the specific text soon.

It is expected version 06 will soon go for 2nd WG last call.

Regards,
Kam

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 28 Jul 2002 22:54:49 -0700 (PDT)

On Mon, 22 Jul 2002, Lam, Hing-Kam (Kam) wrote:

> The Optical Interface MIB version 05, which incorporates all
> the resolutions from the Doctor review, has been discussed
> in the Yokohama meeting. The meeting confirms the acceptance
> of the resolutions.
> 
> the meeting accepts the proposal. I will incorporate Rishi's
> proposed text into the next version (-06) of the mib.  Note
> that as pointed out by Mike on July 8 and concurred with by
> Rishi on July 9, the optIfOChGroupCurrentStatus object will
> not be incorporated into version -06. Also the associated
> optIfOChGroupSinkGroupBasic GROUP will not be included.

One point that I raised before but would like to raise again
is that it seems like the objects in the following groups

   optIfOMSnPostAmpPreOtnPMGroup
   optIfOMSnPostAmpPreOtnPMThresholdGroup
   optIfOMSnPreAmpPreOtnPMGroup
   optIfOMSnPreAmpPreOtnPMThresholdGroup

seem to become redundant if there are exactly corresponding
optIfOChGroup PM objects, which was the case in Rishi's proposal.
Here is why.  If there is a pre- or post-amp that covers all the
channels, there certainly seems to be no compelling reason to
prefer associating it with the OMSn layer rather than with an
optical channel group that that includes all of the OCh's.  The
OMSn layer is, after all, fundamentally associated with the OMSn
overhead signals and not with amplifiers and such (the functional
model in G.798 allows for the presence of pre- or post- amplifiers
in the OMSn source or sink but they are not required to be present).
It would -- in my opinion -- be preferable to avoid such redundancy.

> For monitoring input, output power, and laser temperature
> on both source and transmit directions (Rishi's July 9 email):
> The meeting suggests to bring this to the list for any other
> DWDM vendor is supporting this.  If yes, incorporate Rish's
> suggestion.  If not, suggest to use the Sensor MIB done in
> the Entity MIB. So if there is additional support to this
> proposal, please raise to the list and provide the specific
> text soon.

Although I am not directly involved with this technology I
have made some inquiries of colleagues who do work for DWDM
vendors, and I have also looked at some manufacturer's data
sheets that are available on the Web.  The results of these
inquiries suggest to me that current and proposed pre-OTN PM
objects do not represent an optimum choice of monitored
parameters, either from the standpoint of what seems to
be expected by customers or from what is made available
by amplifier vendors.

Point one:  the persons whom I've consulted have all stated
their internal requirements documents specify that both input
power and output power shall be monitored on every amplifier.
Moreover, the sense I get from the data sheets I've read is
that these parameters are provided by most manufacturers.
So these parameters do indeed seem to be good candidates
for standardization.  Current proposals fall somewhat short.
For a full-band amplifier associated with the OTSn sink one
could construe the optIfOMSnSink*AggregatedInputPower parameters
as the amplifier output power, and for a full-band amplifier
associated with the OTSn source once could construe the
optIfOMSnSrc*OutputPower as the amplifier input power.  However,
there is no similar provision for both input and output power
monitoring in Rishi's proposal.

Point two:  opinions vary widely with resect to laser temperature
monitoring, and so do equipment capabilities.  Some of the
people I've consulted seem to think monitoring is a good idea,
others prefer to monitor TEC current, some want both, and still
others dislike exposing all this stuff and think it is sufficient
to raise an equipment alarm if temperature or TEC current goes
out of range.  Then there is the question of "which temperature".
One amplifier model whose data sheet I looked at -- the Agere 1724
-- has five temperature monitors:  one for each pump laser (it is a
four-stage amplifier), and one for the amplifier case.  For these
reasons, temperature monitoring does not seem to be such a good
thing to standardize.  If laser temperature managed objects are
provided, then they should at least be optional.

Point three:  a similar story holds for mid-stage power monitoring
in multi-stage amplifiers.  Some multistage  amplifiers provide
it;  others don't.  The aforementioned Agere 1724, for example,
does not provide sensors to monitor mid-stage power.  So this
would not be a good thing to standardize.

I like the idea of using the Sensor MIB for stuff that tends to
be very equipment specific.  I think that the best choice would
probably be to provide both input and output power pre-OTN PM
objects for any amplifier that is modelled, and relegate laser
temperature, mid-stage power, and any other technology-dependent
parameters to the Sensor MIB or a vendor MIB.

Comments?

Mike