Subject: RE: Optcial Interface MIB status

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Fri, 9 Aug 2002 15:19:08 -0400

On Monday, July 29, 2002 1:55 AM, C. M. Heard (Mike) wrote:
> 
> 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.

The optIfOChGroup PM objects measure the banded channels (i.e., the
channels within a band), while the optIfOMSn PM objects measure all
channels across all bands. Therefore the groups

    optIfOMSnPostAmpPreOtnPMGroup
    optIfOMSnPostAmpPreOtnPMThresholdGroup
    optIfOMSnPreAmpPreOtnPMGroup
    optIfOMSnPreAmpPreOtnPMThresholdGroup

will become redundant with the groups

    optIfOChGroupPostAmpPreOtnPMGroup
    optIfOChGroupPostAmpPreOtnPMThresholdGroup
    optIfOChGroupPreAmpPreOtnPMGroup
    optIfOChGroupPreAmpPreOtnPMThresholdGroup

when (1) there is only one band and the OChGroup layer is present,
or (2) there are multiple bands but an implementation does not wish 
to model the banded configuration and a degenerated OChGroup layer is present.
However for these cases, the OChGroup layer should be absent. In the draft
version sent by Rishi on Wed 7/3/2002 1:42 PM, in the paragraph below
figure 2, it states that:

   If an implementation does not wish to model the banded configuration,
   the OChGroup layer is absent and the OTN layering model degenerates to
   the description in Figure 1.

This will also answer Rishi's question on Tue 7/9/2002 1:46 AM:
> An OChGroup models a group of lambdas associated with a particular 
> band and a "degenerate" OChGroup in nothing but all the optical 
> channels (if one does not want to model the banded amplifiers). 
> Hence this begs the question "Is there a need for OMSn PM parameters?"

On Monday, July 29, 2002 1:55 AM, C. M. Heard (Mike) also wrote:
> 
> 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.
> 

So for input and output power, is the following a proposal to
move forward?

(1) Define OutputPower objects in the OMS Sink tables  
    and add them to optIfOMSnSinkPreOtnPMGroup
(2) Define OutputPowerThreshold objects in the OMS Sink tables 
    and add them to optIfOMSnSinkPreOtnPMThresholdGroup  

(3) Define AggregatedInputPower objects in the OMS Source tables 
    and add them to optIfOMSnSourcePreOtnPMGroup
(4) Define AggregatedInputPowerThreshold objects in the OMS Source tables 
    and add them to optIfOMSnSourcePreOtnPMThresholdGroup

(5) Define and add the similar objects as (1) to (4) above for OChGroup.

And for laser temperature:

(6) Delete the following Object Groups. 
    optIfOMSnPostAmpPreOtnPMGroup
    optIfOMSnPostAmpPreOtnPMThresholdGroup
    optIfOMSnPreAmpPreOtnPMGroup
    optIfOMSnPreAmpPreOtnPMThresholdGroup
    optIfOChGroupPostAmpPreOtnPMGroup
    optIfOChGroupPostAmpPreOtnPMThresholdGroup
    optIfOChGroupPreAmpPreOtnPMGroup
    optIfOChGroupPreAmpPreOtnPMThresholdGroup

(7) For the objects listed in the above Groups, delete them 
    from the corresponding OMS and OChGroup tables.
    That is, remove all the LaserTemp objects from the 
    OMSs and OChGroup tables.

Comments?

Regards,
Kam

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 11 Aug 2002 16:15:38 -0700 (PDT)

> > optIfOChGroup PM objects, which was the case in Rishi's proposal.
[ ... ]
> channels across all bands. Therefore the [optIfOMSnXyz groups]
> will become redundant with the [optIfOChGroupXyz groups]
> to model the banded configuration and a degenerated OChGroup layer is
> present.  However for these cases, the OChGroup layer should be absent.

In other words, the proposal is to require an implementation to use
the optIfOMSn objects when there is a pre- or post-amp that covers
the whole band, rather than using the optIfOChGroup objects with a
degenerate group that covers all channels.  I would have preferred
to eliminate the OMSn objects and use the degenerate group because
there would be fewer objects in the MIB that way;  however, Kam's
proposal will work fine and covers the important point, which is to
mandate _one_ way to model this case.

> (5) Define and add the similar objects as (1) to (4) above for OChGroup.

This is OK as far as it goes, but for completeness wouldn't we still need
Output Power objects in the OTSn sink table and Input Power objects in
the OTSn source table?  It might not be wise to "overload" the OMSn
sink Input Power or OMSn source Output Power objects to serve these
functions, since there may be lossy passive components between an OTSn
amplifier (if present) and the corresponding OMSn pre- or post-amplifier.

>     OMSs and OChGroup tables.

The same should be done for the optIfOTSn laser temp objects, I think,
since they too are associated with amplifiers and tend to be
technology dependent.

Regards,

Mike