Subject: RE: Optical Interface MIB [draft 05] - proposal to model band amps.

From: "Rishi Grover" <[email-masked]>
Date: Mon, 8 Jul 2002 22:46:17 -0700

Mike, 

Thanks for identifying and correcting the "errors" in the revised MIB. Some of the errors you have pointed out are due to my carelessness (for e.g. OChGroupCurrentStautus and ifPhysAddr definition). Apologize for that.

Some additional points are summarized below that I'd like to raise that affect the PM obect definitions. Hopefully these will be dicussed at the 54th IETF Meeting:

1) Multi-Stage Amplifier Configuration 
It is quite commonly required (at least in implementations I have come across) to monitor the power reading and laser temperature at each stage of a mult-stage amplifier. The draft -05 does not have any provisions for measuring these parameters at every stage.

2) Likewise, it is desireable to capture the laser temperature, input power, and output power for an optical amplifier regardless of how it behaves (src or sink) or where it is positioned in a DWDM transport system.

3) The OChGroup PM params are "cloned" from the OMSn PM params (as you have said in your email, there is a one-to-one correspondence between them). 

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?" (I may be reiterating what you have already said but I guess you get the point).

Thanks,

Rishi

-----Original Message----- 
From: C. M. Heard [mailto:[email-masked]] 
Sent: Monday, July 08, 2002 1:12 PM 
To: [email-masked] 
Subject: RE: Optical Interface MIB [draft 05] - proposal to model band 
amps. 

On Wed, 3 Jul 2002, Rishi Grover wrote: 
> I am attaching a "revised" copy of the OPT-IF-MIB and a UNIX diff output 
> (diff between this revision and draft -05). 
> 
> The revision includes the modeling of band-amplifiers in the MIB through 
> a layer in the ifTable called the "OChGroup". 
> 
> The modifications have been run through a MIB compiler to ensure syntax 
> correctness. 

The basic layering model proposed to model banded amplifiers appears 
to me to be sound, and if there is expected to be significant deployment 
of that technology then that addition is probably worth considering. 

There are, however, some details that I think are not quite correct: 

1.)  The proposed object optIfOChGroupCurrentStatus refers to defect 
conditions that would require the presence of an OChGroup overhead 
signal, which is not defined in the OTN standards.  The definition, 
which reads as follows, 

! optIfOChGroupCurrentStatus OBJECT-TYPE 
!   SYNTAX  BITS { 
!     ssfP(0), 
!     ssfO(1), 
!     ssf(2), 
!     bdiP(3), 
!     bdiO(4), 
!     bdi(5), 
!     losP(6) 
!     } 
!   MAX-ACCESS  read-only 
!   STATUS  current 
!   DESCRIPTION 
!     "Indicates the defect condition of the entity, if any. 
!      This object is applicable only to full capability 
!      systems whose interface type is IaDI and for which 
!      optIfOChGroupDirectionality has the value sink(1) or 
!      bidirectional(3)." 
!   ::= { optIfOChGroupConfigEntry 2 } 

was cloned from that of optIfOMSnCurrentStatus.  A full-capability IadI 
system detects the listed OMSn defects via the overhead signal sent in 
the Optical Supervisory Channel.  That is functionally standardized in 
G.709.  There is no comparable overhead signal for an OChGroup.  Indeed, 
the OTN standards don't define an OChGroup layer at all;  that concept is 
introduced strictly to model banded amplifiers.  So I would suggest that 
the proposed object definition is inappropriate.  Probably the only 
defects that could be defined at this layer would be server signal failure 
(ssf -- meaning that a lower layer has failed) and loss of signal (los -- 
meaning that the in-band input power is below below threshold), and these 
would need to have explicit definitions in the MIB document since they are 
not covered by one of the referenced standards. 

2.) In the section entitled "Use of ifTable for OTN OChGroup Layer" 
the following usage is proposed for ifPhysAddress: 

!     ifPhysAddress       A string of ASCII decimal digits containing the 
!                         wavelength of the optical channel, expressed 
!                         in nanometers (e.g., 1550). 

This cannot be right, since a banded amplifier deals with a range of 
wavelengths.  Would it be reasonable to modify this to call for a string 
that specifies the range of wavelengths in some parseable format?  (The 
exact format would need to be specified so that implementors would know 
what to implement.) 

3.) In the section entitled "Use of ifTable for OTN OCh Layer" the 
following change is proposed: 

*************** 
*** 421,427 **** 

      ifOperStatus        The operational status of the interface.  This 
                          object is set to lowerLayerDown(7) if the 
!                         ifOperStatus of its otn interface is down(2). 
                          Otherwise, it is set to down(2) if one or more 
                          of the objects optIfOChCurrentStatus, 
                          optIfOTUkCurrentStatus, optIfODUkTCurrentStatus, 
--- 531,537 ---- 
  
      ifOperStatus        The operational status of the interface.  This 
                          object is set to lowerLayerDown(7) if the 
!                         ifOperStatus of its OChGroup interface is down(2). 
                          Otherwise, it is set to down(2) if one or more 
                          of the objects optIfOChCurrentStatus, 
                          optIfOTUkCurrentStatus, optIfODUkTCurrentStatus, 

The new text should read "This object is set to lowerLayerDown(7) if the 
ifOperStatus of its otn interface or of its OChGroup interface is down(2)." 

4.) For PM parameters, the proposal is to add a set of OChGroup PM 
parameters which are in one-to-one correspondence with the OMSn PM 
parameters.  It seems to me, however, that the OMSn PM parameters 
that are present for modelling full-band pre- and post- amplifiers 
(i.e. the OMSn laser temperature parameters) would no longer be 
necessary, because such amplifiers could be modelled just as well by 
using a "degenerate" OChGroup that includes all the optical channels. 

> While putting this proposal together in the MIB, I came across certain 
> PM parameter modeling issues that I would like to raise for discussion. 
> However to avoid muddling "independent" issues, I will address the 
> issue in another mail. 

It sounds like these issues are likely to affect the details of the 
PM parameter object definitions.  If so, please raise them as soon 
as possible, particularly if you think that any of the existing PM 
parameter object definitions are deficient.  Doing multiple revision 
proposal/review iterations is not an efficient use of time (and in 
addition it might be nice to have the issues on the table before next 
Tuesday's meeting at IETF54). 

Regards, 

Mike