Subject: Which ifIndex?

From: Jeff Johnson <[email-masked]>
Date: Fri, 17 Apr 1998 15:44:57 -0700

Hi folks,
Although I'm not new to network management, I am new to ATM, and have
recently spent a considerable amount of time with RFC 1695, as well as with
the atm1ng and atm2 drafts.  I've noticed that that most of the tables in
these mibs contain at least one ifIndex-based index.  The problem I keep
having is that since an atm port consists of layers of interfaces, I'm
never quite sure if I'm using the correct ifIndex value.  For example, note
that in the atm2 draft, both the atmVclStatEntry and the
atmAal5VclStatEntry are indexed by {ifIndex, atmVcpVpi, atmVclVpi}, but
presumably the former table uses the atm layer ifIndex and the latter uses
the aal5 layer ifIndex.  Of course, I'm just guessing since the MIB doesn't
explicitly tell me.  I'd feel better about my presumptions if the
description clauses for the individual tebales told me which ifIndex to use
;-)

/jeff

---

From: Rajesh Abbi <[email-masked]>
Date: Mon, 20 Apr 1998 11:02:04 -0400

I fully agree with Jeff that all tables that are based on ifIndex (which
is
almost all of them), should clearly specify the "type" of interfaces
which
are applicable to them.  Although in most cases the interface type is
apparent, clearly documenting it will avoid potential interpretation
problems between different implementors.

Rajesh

========================================================================
Rajesh Abbi
Alcatel Network Systems
2912 Wake Forest Road
Raleigh, NC 27609-7860
Phone: (919) 850-6194
Fax  : (919) 850-6670
Email: [email-masked]
========================================================================

---

From: Gary Hanson <[email-masked]>
Date: Mon, 20 Apr 1998 11:45:56 -0700 (PDT)

Rajesh and Jeff,

I agree that the ATM-MIB and ATM2-MIB drafts could stand to be
more explicit about identifying which types of interfaces can be
used for the various ifIndex INDEX values.

However, prior to noting WHICH table entries need to be clarified,
let's first make sure that we are all thinking along the same lines
about what interface types are to be used for indexing each table
entry.

Here is my list of table entries that use ifIndex-like INDEX
objects, along with my notion of interface types that apply.

atmInterfaceConfEntry:
- ifIndex of atm or atmLogical interface
atmInterfaceDs3PlcpEntry:
- ifIndex of atm interface
atmInterfaceTCEntry:
- ifIndex of atm interface
atmVplEntry:
- ifIndex of atm interface
atmVclEntry:
- ifIndex of atm or atmLogical interface
atmVpCrossConnectEntry:
- atmVpCrossConnectLowIfIndex of atm interface
- atmVpCrossConnectHishIfIndex of atm interface
atmVcCrossConnectEntry:
- atmVcCrossConnectLowIfIndex of atm or atmLogical interface
- atmVcCrossConnectHishIfIndex of atm or atmLogical interface
aal5VccEntry:
- ifIndex of atm or atmLogical interface (NOT aal5 interface!)
atmSvcVpCrossConnectEntry:
- atmSvcVpCrossConnectLowIfIndex of atm interface
- atmSvcVpCrossConnectHishIfIndex of atm interface
atmSvcVcCrossConnectEntry:
- atmSvcVcCrossConnectLowIfIndex of atm or atmLogical interface
- atmSvcVcCrossConnectHishIfIndex of atm or atmLogical interface
atmSigStatEntry:
- ifIndex of atm or atmLogical interface
atmSigSupportEntry:
- ifIndex of atm or atmLogical interface
atmIfRegisteredAddrEntry:
- ifIndex of atm or atmLogical interface
atmVclAddrEntry:
- ifIndex of atm or atmLogical interface
atmAddrVclEntry:
- atmAddrVclAtmIfIndex of atm or atmLogical interface
atmVplStatEntry:
- ifIndex of atm interface
atmVclStatEntry:
- ifIndex of atm or atmLogical interface
atmAal5VclStatEntry:
- ifIndex of atm or atmLogical interface (NOT aal5 interface!)
atmIlmiSrvcRegEntry:
- atmIlmiSrvcRegIndex of atm or atmLogical interface
atmIlmiNetworkPrefixEntry:
- ifIndex of atm or atmLogical interface
atmCurrentlyFailingPVplEntry:
- ifIndex of atm interface
atmCurrentlyFailingPVclEntry:
- ifIndex of atm or atmLogical interface

NOTES:
- The ifIndex value of aal5 interfaces is NOT used for indexing any
  of the above table entries.  The DESCRIPTIONs for the VPI and VCI
  objects in the AAL5-related tables all indicate that they are for
  the interface identified by the ifIndex.  It should be noted also
  that if the aal5 interface were used instead of the atm interface
  or the atmLogical interface, there might need to be multiple table
  entries that share the same ifIndex, VPI, and VCI value, since the
  VPI and VCI values might be for DIFFERENT atm interfaces or
  atmLogical interfaces.
- The atmIlmiSrvcRegIndex object could well have been called
  atmIlmiSrvcRegIfIndex.  Even more importantly, its SYNTAX should
  be changed to InterfaceIndexOrZero, in order to allow the special
  value of 0.

Are we thinking along the same lines?

Regards,
Gary

 ______
| ///  |       TM   Gary Hanson                [email-masked]
|   ADC|Kentrox     14375 NW Science Park Dr.  503-641-3321 (FAX)
|______|            Portland, Oregon  97229    800-733-5511 x6333

---

From: Dewulf Natalie <[email-masked]>
Date: Tue, 21 Apr 1998 12:25:18 +0200

Hi,

I would like to have some clarification on how you index the
aal5VccTable.
In our system, we have a switch model for AAL5 connections.
This implies that we create a crossconnection between a VCL on 
an atmInterface and an AAL5 VCL on a virtual interface.
Which one is then represented in the aal5VccTable ? I thought it 
was the AAL5 VCL on the virtual interface.

Regards,

Natalie Dewulf

---

From: Rajesh Abbi <[email-masked]>
Date: Tue, 21 Apr 1998 09:26:01 -0400

Hi Natalie & Gary,

The ATM-MIB draft is indeed not clear about which interface is
referenced by the ifIndex in the aal5VccTable.  However, the
basic premise behind the virtual AAL5 interface is to establish
a new entity to represent the AAL5 process in a switch [sec. 9.1].
This section does identify the AAL5 interface to be used for PM
of the AAL5 resources in the switch , but is not clear about the
AAL5 VCCs themselves.

Clearly the AAL5 VCCs may be referenced either via the internal 
(pseudo)VPI/VCI on the AAL5-interface, or the real VPI/VCI on the 
ATM-interface.  I would agree with Gary that using the "real"
VCC on the ATM-interface is more useful to a user who normally
does not care about the internal (pseudo) VPI/VCI.

Comments ???

-Rajesh

---

From: Gary Hanson <[email-masked]>
Date: Tue, 21 Apr 1998 09:26:29 -0700 (PDT)

Natalie,

You raise a good point.  I neglected to consider the important (!)
case where a switch models an AAL5 entity by an aal5 interface that
is stacked on top of a propVirtual interface, and models an AAL5 VCL
on the propVirtual interface as being cross-connected to a VCL on
an atm or atmLogical interface above some physical layer interface.

I would thus add propVirtual to the list of possible ifTypes for the
INDEX objects of each of the following VCL-oriented table entries:
- atmVclEntry
- atmVcCrossConnectEntry
- aal5VccEntry
- atmSvcVcCrossConnectEntry
- atmVclAddrEntry
- atmAddrVclEntry
- atmVclStatEntry
- atmAal5VclStatEntry
- atmCurrentlyFailingPVclEntry

You might even find value in using atmInterfaceConfTable entries for
such internal propVirtual interfaces, depending on how you choose to
model things (e.g., for atmInterfaceMaxVccs, atmInterfaceConfVccs,
etc.).

The more I think of it, the question of whether an aal5 interface is
actually used to index the AAL5-related table entries instead of an
atm, atmLogical, or propVirtual interface is probably better left as 
a matter of implementation choice.  I could easily see advantages
and disadvantages to both approaches, and I would not want to see us
dictate an approach that may invalidate existing implementations.

Based on that, it may be less useful in the long-term to add rigid
rules to the ATM-MIB and ATM2-MIB than to allow different vendors to
reach their own conclusions about how best to model things.  After
all, the ATM-MIB and ATM2-MIB do not address EVERYTHING that can be
supported in an ATM host, switch, or service/network.  Such things
as ATM access devices (concentrators, multiplexers, etc.) that can
support cross-connects or other mappings to interworking functions
need to find special ways to model the various interface stackings
and interworking functions that are simply beyond the scope of these
MIBs.  (I know I am getting off the subject, but I see a need for
eventually defining a standard generic IWF-MIB to model interworking
functions between stacks of interfaces; that would go a long way to
handling these things; if anyone is interested in helping create an
initial internet-draft, please let me know.  I think we would be
able to capitalize on using existing MIBs such as the ATM-MIB, while
at the same time helping extend their capabilities in ways that are
needed to model large classes of hybrid products that don't always
neatly fit into existing MIB models.  Even with a standard IWF-MIB,
I would not want to see a rigid set of rules that precludes useful
deviations in unforeseen cases, however.)

I am not sure if I helped clarify things for you, or if I may have
alarmed you by suggesting that we DON'T add specific clarifications
for such things to the MIB documents (in the interest of freedom of
implementation).

Regards,
Gary

 ______

---

From: Gary Hanson <[email-masked]>
Date: Tue, 21 Apr 1998 09:59:00 -0700 (PDT)

Rajesh,

> does not care about the internal (pseudo) VPI/VCI.

Thank you for agreeing with me, but at the time I was only thinking
about the ATM host case, and not about the ATM switch case that
Natalie apparently had in mind.

True, the first choice in this case is whether to use the VPI/VCI
on the external atm interface or the VPI/VCI on the internal
propVirtual interface.  If you choose the latter, then the second
choice is whether to use the ifIndex of the propVirtual interface or
the aal5 interface to index the relevant AAL5 VCC tables.

In the case Natalie was talking about, it sounds more appropriate to
me to pick the VPI/VCI on the internal propVirtual interface.  For
the second decision, I would lean towards using the ifIndex of the
propVirtual interface rather than the aal5 interface, but I am not
sure it is crucial to dictate that choice for all implementations.

Regards,
Gary

---

From: "Michael H. Grobelch" <[email-masked]>
Date: Tue, 21 Apr 1998 11:36:10 -0700

Rajesh,

I believe the aal5Vcc entries should be based on
the interface at which the AAL5 SAR is performed.
Typically in a switch, this is at the internal interface.

Mike

 >Message-ID: <[email-masked]>
 >Date: Tue, 21 Apr 1998 09:26:01 -0400
 >From: Rajesh Abbi <[email-masked]>
 >Organization: Alcatel Network Systems, Inc Raleigh, NC
 >X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4m)
 >MIME-Version: 1.0
 >To: Dewulf Natalie <[email-masked]>,
 >        Gary Hanson <[email-masked]>
 >CC: [email-masked]
 >Subject: Re: Which ifIndex?
 >References: <Pine.SUN.3.96.980420094950.2409I-100000@skeeter> <[email-masked]>
 >Content-Type: text/plain; charset=us-ascii
 >Content-Transfer-Encoding: 7bit
 >Content-Length: 6659
 >
 >Hi Natalie & Gary,
 >

---

From: Rajesh Abbi <[email-masked]>
Date: Fri, 24 Apr 1998 17:28:15 -0400

Hi Mike & Gary,

I have the following comments:

Firstly, regarding Gary's position that the MIB should not dictate
the selection of the interface that is used for individual tables -
I believe that the purpose of a 'standard' MIB is to ensure common
behavior.  To the extent each implementation can choose it's own
behavior is contrary to this position.  Thus, I still believe that
the MIBs should clearly state the use of interfaces - especially
if there is possible ambiguity.

Secondly, regarding the use of internal interface of the switch for the
aal5Vcc entries - I can see the logic of using the internal VCL since 
it models the internal representation more closely, however, I do not 
believe that is very useful. 
Clearly, the main purpose of the MIB is to manage ATM UNIs.
The VCCs to be managed are the ones on the UNI.  Thus, any counters
associated with these VVCs should be associated with the VCC at the
UNI (ie. the VPI/VCI used at the UNI).  
The fact that the AAL5 VCC's VCL on the UNI may need to be 
cross-connected to some proprietary VCL on the virtual interface in
order to terminate it, is necessary configuration overhead for the 
system.  The ATM manager must display any AAL5 statistics to the
operator in reference to the VCL on the UNI - because that's what
the operator is interested in.  Choosing to implement the aal5VccTable
using the virtual interface and the internal VPI/VCI of the proprietary
VCL in the Switch model will require the manager to always have to 
translate the values to the VPI/VCI at the UNI using the 
atmVcCrossConnectTable.  Moreover, the interface used for this table
will be different for NEs using the Host and the Switch models.
Using the UNI interface for this table will simplify the manager's job, 
as well as have consistent behavior for both Host and Switch model
devices.
Thus it makes more sense to implement the aal5VccTable for VCLs on
the UNI interface.

While we are on this subject, what about other attributes of the
VCL at the UNI which is associated with an AAL5 VCC that is terminated 
in the NE - especially in the atmVclTable ?  
In the Switch model, the VCL at the UNI of the terminated  VCC will NOT
be considered terminated since it is cross-connected to the internal
VCL.  Also, that will imply that the atmVcc_xxx objects will NOT be
available for this VCL, but will only be available in the entry
associated
with the internal VCL.  This forces all configuration of the AAL5
parameters for the VCC to be done using the internal VCL.
This behavior will be different in the Host model, where the 'real' VCL
at the UNI would be used for everything.  A little bit of ugliness for 
a manager.
And how does the manager figure out if a device being managed is using 
the "Switch" or the "Host" model ?  It would be nice to have an
additional object to indicate that - perhaps 'atmSystemModel' ???

Rajesh

---

From: "Michael H. Grobelch" <[email-masked]>
Date: Mon, 27 Apr 1998 12:43:44 -0700

Hi Rajesh, 

see below for comments:

 >Date: Fri, 24 Apr 1998 17:28:15 -0400
 >To: "Michael H. Grobelch" <[email-masked]>, Gary Hanson <[email-masked]>
 >References: <[email-masked]>
 >Content-Length: 11081

I disagree. This MIB is used to manage UNI and NNI interfaces, and to 
manage ATM connections, used for any purpose. In the case of a switch
virtual interface, some of the VCs may be used for signalling or ILMI, 
and have an association with an external interface.  But these
are not the only VCs to be managed. Most switch VCs are transit VCs,
and will not have AAL5 information. The switch virtual interface also 
can transport VCs which are no  more associated with the external
interface as the virtual interface (e.g. LES/BUS LANE services, or LANE
client used to manage the switch)

 >atmVcCrossConnectTable. 
 
Yes, the SNMP management station can choose to display the statistics
as it pleases. I think it is appropriate to put the overhead there, if
it is desired.  Placement of aal5VccTable on the interface
doing the SAR function provides important information that can
be used in managing the switch. Cells received on an external interface 
may never reach the virtual interface SAR, as a result of discarding by the 
switch fabric. It is important to correlate the AAL5 statistics for a VC
with the  ATM statistics for the VC at the point at which SAR takes place. 

Mike
----------------------------------------------------------
Michael Grobelch ([email-masked]) (408)-526-7348  SJ-H

 >Moreover, the interface used for this table

---

From: Gary Hanson <[email-masked]>
Date: Tue, 28 Apr 1998 19:10:43 -0700 (PDT)

Hi Mike and Rajesh,

I agree with Rajesh that it is important in this case to try to find
a common way to index the AAL5 VCC tables, although in general there
may be cases where dictating a common solution is antiproductive.

In this case, I agree with Mike that for ATM switches, where the
AAL5 entity is at the end of a cross-connect, that the AAL5
statistics should be maintained where the SAR is done.  Since the
SAR is done at the end of the cross-connect, the ifIndex should be
that of the propVirtual(53) interface below the aal5(49) interface,
if the ATM-MIB document is to followed to the letter. 

For ATM hosts, where the AAL5 entity is directly above the ATM layer
or ATM logical port layer, the SAR is done at the ATM UNI, so the
ifIndex for the AAL5 VCC statistics should be that of the atm(37) or
the atmLogical(80) interface, whichever is immediately below the
aal5(49) interface.  Again, this is my take on reading the ATM-MIB
(in conjunction with the ATM2-MIB).

I don't see a need for an object to distinguish between whether an
agent implements an ATM switch vs. an ATM host.  If it follows the
conformance statements, an agent for an ATM host should never need
to implement cross-connects, so a simple test to see if a manager is
dealing with an ATM host or an ATM switch would presumably be to get
the value of atmVcCrossConnectIndexNext.  If one gets noSuchObject
(or noSuchName in SNMPv1) as a response, it could conclude that it
was NOT dealing with an ATM switch.

Regards,
Gary

 ______

On Mon, 27 Apr 1998, Michael H. Grobelch wrote:

>  >[...]