Subject: RE: Optical Interface MIB questions - draft 04 (now draft 5)

From: "Rishi Grover" <[email-masked]>
Date: Mon, 17 Jun 2002 14:17:47 -0700

Kam, Mike, 

Thanks for your feedback. I concur with your statements.

However I would like to make a suggestion that can hopefully be incorporated in the MIB which would not only preserve the existing structure and interpretations of the MIB but allow for some flexibilty in modeling.

I think that there should be provisions in the MIB (or statements to the effect) that allow for sub-band modeling of the amplifiers in the DWDM transport service. The sub-band modeling describes the C and L band wavelengths muxed and amplified seperately before finally being muxed and transported over an OTN.

As an example, the ifStackTable representation would be something like the following:

 +-----+-----+-----+   +-------+-----+------+
 |OCh1 | ... |OCh80|   | OCh81 | ... |OCh160|
 +-----+-----+-----+   +-------+-----+------+
 |    OMS1         |   |      OMS2          |
 +-----------------+---+--------------------+
 |                 OTN                      |
 +------------------------------------------+

       OCh (1 thru 80)
        |
        |                  OMS1    OMSn 
        |                   |       |
        |                   |       |        OTSn 
        |                   |       |         |
        V                   |       |   |\    |
___|\_________|\      |\    V   |\  V   | \   V
   |/       . | \_____| \_______| \_____|  \______
            . | /     | /      _| /     |  /
          ----|/      |/      | |/      | /
         C-Band MUX           |   OSC --|/
                              |
___|\_________|\      |\      |      OSC add filter          
   |/       . | \_____| \_____|
            . | /     | /             
          ----|/      |/    ^          
         L-Band MUX         |
      ^                     |
      |                     |
      |                    OMS2
      |
   OCh (81 through 160)

         Figure 1 - Source Side Monitoring Points

where 

OMS1 represents the muxed layer for C-band amplifier.
 
OMS2 represents the muxed layer for L-band amplifier.

OTN represents the orignal OMS-OTN fixed connectivity as described in the draft OPT-IF MIB. The "ifConnectorPresent" for this ifEntry would indicate "TRUE".

A particular implementation may choose to ignore the sub-band modeling in which case the ifStackTable representation becomes OCh over OTN (as currently described in the OPT-IF MIB).

By allowing the modeling of sub-bands in a DWDM transport service, a user is more accurately able to capture the PM parameters defined in this MIB rather than aggregating them over the two (or more) sub-bands which may not be an accurate representation.

What do you think?

Rgds,
Rishi

-----Original Message-----
From: Lam, Hing-Kam (Kam) [mailto:[email-masked]]
Sent: Thursday, June 13, 2002 9:15 AM
To: [email-masked]
Subject: RE: Optical Interface MIB questions - draft 04

Rishi,

A single external interface should not be represented by two or more opticalTransport ifTable entries.
The OMS, when it exists, is one-to-one with the OTS. 

Given that, both of your approaches are not consistant with the MIB.

--Kam

> -----Original Message-----
> From: C. M. Heard [mailto:[email-masked]]
> Sent: Wednesday, June 12, 2002 4:25 PM
> To: [email-masked]
> Subject: RE: Optical Interface MIB questions - draft 04
> 
> 
> On Wed, 12 Jun 2002, Rishi Grover wrote:
> 
> > Pls allow me to ask a follow-on question relating to this.
> > 
> > For a DWDM service that transports multiple channels (160 
> total) that
> > are divided into C (80 lambdas) and L (80 lambdas) band wavelengths,
> > does this MIB have any provision to monitor the C and L 
> bands seperately?
> 
> No, it does not have a way to model banded amplifiers.
> 
> > Here is the dilemma. In our implementation, the C and L bands are
> > implemented and amplified in separate cards (and hence have seperate
> > physical interfaces).  Finally the 80 lambdas from each 
> band are muxed
> > into one DWDM fiber using a passive component. This passive 
> component
> > cannot measure PM params like aggregate power etc. for the 
> 160 lambdas.
> 
> In other words the system looks something like this, possibly with the
> order of the filters and amplifiers reversed:
> 
>           |\      C-band   C-band amp|\
>           | |____ add/drop ____|\____| |
>   RX      | |     filters      |/    | |      TX
>  from ____| |                        | |____  to
>  West     | |     L-band   L-band amp| |     East
>           | |____ add/drop ____|\____| |
>           | |     filters      |/    | |
>           |/                         |/
>         passive                     passive
>          demux                        mux
> 
> > The PM params defined in the MIB can only be captured on a 
> band-basis
> > (i.e. C-band and L-band) because their specific cards have 
> the active
> > circuitry to measure such parameters.
> > 
> > So would this all mean that I would need to model the 
> C-band physical
> > interface as one "OTN" ifEntry and the the L-band physical interface
> > an another "OTN" ifEntry in the ifTable?  And then in the 
> ifStackTable
> > represent OCh1-OCh80 over OTN1 and OCh81-OCh160 over OTN2.
> 
> No, this is not correct.  An opticalTransport ifTable entry 
> is intended
> to represent a single external interface (ifConnectorPresent 
> is true(1)),
> so it would be wrong to divide the wavelengths in a single 
> fiber between
> two such interfaces.
> 
> > OR
> > 
> > Would I represent the C and L bands as seperate OMS's over 
> one OTS?  In
> > which case the interface stacking would be OCh1-OCh80 over 
> OMS1 over OTS.
> > And OCh81-OCh160 over OMS2 over OTS?
> 
> This is not right either, since the OMSn sublayer has a 
> 1-for-1 relationship
> with the OTSn sublayer.
> 
> The problem is that the pre-OTN PM objects in the OPT-IF-MIB 
> just don't fit
> your NE very well.  You could _calculate_ the OTSn input and 
> output power
> by summing the corresponding C-band and L-band parameters, 
> but the OTSn
> laser temperature object does not fit at all.  Perhaps you 
> should consider
> defining proprietary PM objects in your enterprise MIB that 
> better fit the
> structure of the equipment that you are trying to manage.
> 
> Perhaps the MIB authors could jump in here and comment on this.
> 
> Mike
>