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

From: "Rishi Grover" <[email-masked]>
Date: Wed, 3 Jul 2002 10:42:08 -0700

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.
 
Rgds,
Rishi
 
P.S. 
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.

	-----Original Message----- 
	From: Rishi Grover 
	Sent: Tue 6/25/2002 10:22 AM 
	To: [email-masked] 
	Cc: 
	Subject: Optical Interface MIB [draft 05] - proposal to model band amps.

	Hi, 

	Following some email discussions with Kam Lam and Mike Heard regarding the subject of modeling band-amplifiers in the Optical Interface MIB, I am putting forth a proposal for further comment in this mailing list.

	ISSUE: 
	There is a need to model sub-band amplifiers in the OPT-IF-MIB. The sub-band modeling describes the C and L band wavelengths muxed and amplified seperately before finally being muxed and transported over an OTN.

	REQUIREMENT: 
	There is one set of OMS overhead corresponding to the OTS. So we need to maintain a 1-1 relationship between OTSn and OMSn. 

	PROPOSAL: 
	One possible approach which makes the most efficent use of what is already proposed in the OPT-IF-MIB (draft 5) and at the same time allows us to model the banded amplifiers is described below:

	[NOTE: I have taken Figures 5 and 6 from draft-05 and modified them to allow representation of C and L band amps]. 

	        OCh (1 thru 80) 
	         | 
	         |               OChGroup1  OMSn 
	         |                   |       | 
	         |                   |       |        OTSn 
	         |                   |       |         | 
	         V                   |       |   |\    | 
	 ___|\_________|\      |\    V   |\  V   | \   V 
	    |/       . | \_____| \_______| \_____|  \______ 
	             . | /     | /      _| /     |  / 
	           ----|/      |/      | |/      | / 
	          C-Band MUX   Amp     | Mux  +--|/ 
	                               |      |  
	                               |      | 
	 ___|\_________|\      |\      |     OSC 
	    |/       . | \_____| \_____| 
	             . | /     | /        OSC Add Filter 
	        ^  ----|/      |/   ^      
	        | L-Band MUX   Amp  | 
	        |                   | 
	        |                   | 
	        |              OChGroup2 
	        | 
	   OCh (81 through 160) 
	  
	          Figure 1 - Source Side Monitoring Points 

	       OCh (1 thru 80) 
	         | 
	         |               OChGroup1  OMSn 
	         |                   |       | 
	         |                   |       |        OTSn 
	         |                   |       |         | 
	         V                   |       |         | 
	                             V       V     /|  V 
	 __/|__________/|       /|        /|      / | 
	   \|      .  / |______/ |_______/ |____ /  |_____ 
	           .  \ |      \ |     __\ |     \  | 
	 __/|__________\|       \|    |   \|     _\ | 
	   \|   C-Band Demux   Amp    |  Demux  |  \| 
	                              |         | 
	                              |         | 
	 __/|__________/|       /|    |     OSC Drop Filter 
	   \|      .  / |______/ |____| 
	           .  \ |      \ |      
	 __/|__________\|       \|       
	   \|   L-Band Demux   Amp   ^            
	                             | 
	        ^                    | 
	        |                    | 
	        |                    | 
	        |                OChGroup2 
	        | 
	   OCh (81 through 160) 

	         Figure 2 - Sink Side Monitoring Points 

	  +-----+-----+-----+   +-------+-----+------+  --- 
	  |OCh1 | ... |OCh80|   | OCh81 | ... |OCh160|   | <-- och ifEntries 
	  +-----+-----+-----+   +-------+-----+------+  --- 
	  |    OChGroup1    |   |     OChGroup2      |   | <-- ochGroup ifEntries 
	  +-----------------+---+--------------------+  --- 
	  |                 OMSn                     |   | 
	  +------------------------------------------+   | <-- otn ifEntries 
	  |                 OTSn                     |   | 
	  +------------------------------------------+  --- 
	  
	Figure 3 - OCh, OMS, OTS Layering for DWDM Transport using Sub-Bands 

	If an implementation does not wish to model the banded-amplifiers, the OChGroup layer will be absent and the layering degenerates to what is currently proposed in the OPT-IF-MIB.

	By introducing this capability in the MIB, the following changes would be required to draft 05: 

	- Introduce a new ifType enumeration called "OpticalChannelGroup" 
	- Define additional group of tables to handle config and performance information for the OChGroup. 
	- Conformance statements 

	Any other suggestions that you may have regarding this are most welcome. 

	Rgds, 
	Rishi

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 8 Jul 2002 13:11:47 -0700 (PDT)

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 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