Subject: TC If MIB table index with IMA

From: Thierry Arnoux <[email-masked]>
Date: Fri, 11 Apr 2003 15:16:18 +0200

Hi AToM MIB,

  I have a question about the ATM MIB, when used together with IMA
(Inverse
Multiplex for ATM). 
An interface TC table is forseen for the TC sublayer underlying a given
ATM interface:
RFC 2515 says this table is "indexed by the ifIndex value of the ATM
interface", so there should be a one-to-one relationship between the ATM
layer and the IMA layer.

  However, according to the IMA spec (ATM Forum af-phy-0086-001), the
IMA sublayer is  "a new sublayer located between the Transmission
Convergence (TC) sublayer and the ATM layer". The multiplexing
capability enables to run ATM over several physical interfaces as if
they were one.
So, one ATM interface can be stacked on several DS1 physical interfaces,
that is, several TC sublayers, through an IMA interface (for which an
entry in the interface table is also forseen).
The IMA spec draws the following interface stack:

 +------------------------------------+
 |                atm                 |
 +------------------------------------+
                   |
 +------------------------------------+
 |              atmIma                |
 +------------------------------------+
     |         |                  |
 +-------+ +-------+          +-------+
 |  ds1  | |  ds1  |  . . .   |  ds1  |
 +-------+ +-------+          +-------+

Which means, there is no one-to-one relationship between ATM interface
and TC interface, so the TC interface table can't be indexed by the
ifIndex of the ATM interface, but rather by the ifIndex value of the
underlying DS1 interface...

In that case, how is the atmInterfaceTCTable to be implemented ? 
In a short thread with "nobody" on comp.dcom.cell-relay, it appeared
to us that the best solution would be to use the ifIndex value of the
underlying DS1 interface to index the atmInterfaceTCTable.

But this means that the RFC needs to be adapted. This is also the 
solution proposed by Kevin Nolish on this list, that was not followed
since then (as I could not see any other message on the same topic).

Are you considering addressing this problem ?

Thank you and best regards,
_
Thierry Arnoux

> From: "Nolish, Kevin" <[email-masked]>
> To: "[email-masked]'" <[email-masked]>
> Subject: RFC 2515 Comment
> Date: Tue, 10 Apr 2001 14:47:12 -0400
> 
> There is a problem with the definition of the atmInterfaceTcTable
> that ought to be addressed in the next revision of RFC 2515.  As
> defined, the table does not interwork well with the Atm Forum
> IMA Specification.
> 
> The problem is that the index of atmInterfaceTcTable is defined
> to be the ifIndex of the ATM interface associated with the 
> cell stream in question.  For IMA, there may, potentially, be
> several different TC entities associated with a particular
> ATM Interface.  Additionally, in IMA there's an extra ifEntry,
> the IMA Group ( IANAifType atmIma(107) ) stacked between the AtmIf
> and the underlying physical layer object.
> 
> In an IMA implementation, the TC layer is in one to one correspondence
> with the underlying physical link.  Each physical link carrying its
> portion of the inversed multiplexed cell stream may enter or exit the
> LCD condition independently.  Together these links are used to transport
> the traffic of an IMA group which would be in one to one correspondence
> with an Atm Interface.
> 
> The simplest way to correct the MIB would be to use the ifIndex of the
> underlying physical layer object, say Dsx1 interface, as the value for
> the index of the atmInterfaceTCEntry table.
> 
> Kevin Nolish
> 724-742-6989
> <mailto:[email-masked]>

nobody wrote:
> > P.S.  You should send questions/comments like this
> > to the IETF AToM MIB working group mailing list.  See
> > http://www.ietf.org/html.charters/atommib-charter.html
> > for subscription info.
> 
> This surely helped - I could find the following mail in the archives
> of the IETF AToM MIB working group, which described exactly my problem !

You probably had to do quite a bit of legwork to find that message.

> However, it was not followed up. I presume that I have to wait for
> the next revision of RFC 2515 to have it officially solved...
> 
> I will maybe post in the IETF AToM MIB working group mailing list
> anyway.

I think that you should do that.  The WG is now finishing up on three
important specifications ... last call closed today on the updates to
the
SONET-MIB (RFC 2558bis) and the closely allied PerfHistTC-MIB (RFC2493
bis),
and last call expires tomorrow on the initial version of OPT-IF-MIB
(optical
interface MIB).  One of the next new work items will be advancing (or
recycling) the ATM-MIB (RFC 2515).  Whether this work is undertaken will
depend in part on whether there is sufficient interest (and, possibly,
the availability of an editor).  So, please let your interest be known.
Things _won't_ move if everyone just waits for something to happen.

In the meantime, the suggestion made by Kevin Nolish, viz.

% The simplest way to correct the MIB would be to use the ifIndex of the
% underlying physical layer object, say Dsx1 interface, as the value for
% the index of the atmInterfaceTCEntry table.

is what I would implement if I were in your shoes.  It's the obvious
solution, and when RFC 2525bis appears it's almost certainly what will
be in it.  I would be surprised if it's not already a "de facto"
standard adopted by many IMA vendors.  Asking on the AToM MIB list
is a very good way to find out if that is really true.  Hope to see
you there!

nobody