Subject: RE: TC If MIB table index with IMA

From: "Faye Ly" <[email-masked]>
Date: Fri, 11 Apr 2003 17:54:26 -0700

Thierry,

RFC 2515 is in the process of 'soliciting implementation report'.  We
could address this issue during the process however:

1. ATM IMA was not covered by RFC 2515.  This can be changed giving that
you or Nolish express your interest to the list.
2. ATM IMA MIB is not on the Atommib working group charter.  If you or
someone on the list is interested, please express you interest to the
list.

In the meantime, I believe this is merely a description clarification to
fix the ATMif -> IMA -> TC problem in RFC 2515.  But first of all I need
to see some explicit request to do so to RFC 2515.  Thanks.

-faye

-----Original Message-----
From: Thierry Arnoux [mailto:[email-masked]] 
Sent: Friday, April 11, 2003 6:16 AM
To: [email-masked]
Subject: TC If MIB table index with IMA

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

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 13 Apr 2003 19:59:47 -0700 (PDT)

> to see some explicit request to do so to RFC 2515.  Thanks.

I believe that this is correct.  Thierry, if these changes would be
useful to you and/or your company, you might want to consider proposing
specific wording changes to RFC 2515.  It's normal for specifications to
be republished when they are avanced on the standards track, and a change
like this one (e.g., to adopt the Kevin Nolish proposal) would not block
advancement, since it's not introducing new objects into the MIB module.

Mike Heard

(aka "nobody", who wrote:)
> is what I would implement if I were in your shoes.

---

From: Kaj Tesink <[email-masked]>
Date: Mon, 14 Apr 2003 17:39:55 -0400

>advancement, since it's not introducing new objects into the MIB module.

this is probably correct, depending what the exact proposed fix would be.
it should also have to avoid changes to the semantics of the existing
objects (unless backward compatible).

the current TC table's scope says:
-- This table contains TC sublayer configuration and
-- state parameters of those ATM interfaces
-- which use TC sublayer for carrying ATM cells over
-- SONET/SDH or DS3.

so i guess you're proposing an addition to cover the IMA.
and the addition would be to expand (rather than change) the semantics of
atmInterfaceTCEntry (?)

kaj

> > is what I would implement if I were in your shoes.

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. In.
331 Newman Springs Road
Red Bank, NJ 07701
Email: kaj @research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 14 Apr 2003 15:19:12 -0700 (PDT)

> and the addition would be to expand (rather than change) the semantics of

Yes, I think so.  At least that's my understanding of what Kevin
Nolish's proposal, i.e.,

entails.  The atmInterfaceTCEntry indexing scheme can stay as-is for
existing SONET/SDH, DS3, or DS1 interfaces without IMA, since the TC
sublayer and ATM layer have a one-to-one relationship in that case.  
Only for systems with IMA where there is a many-to-one relationship
between the TC sublayer an the ATM layer would the indexing scheme
have to change.  That could probably be accomodated with some edits
to the DESCRIPTION clause alongs the lines of this:

     atmInterfaceTCEntry OBJECT-TYPE
          SYNTAX         AtmInterfaceTCEntry
          MAX-ACCESS     not-accessible
          STATUS         current
          DESCRIPTION
           "This list contains TC Sublayer parameters
            and state variables.  For systems without
            IMA there is a one-to-one relationship between
            the TC Sublayer and the ATM Layer, and in
            those cases this list is indexed by the
            ifIndex value of the ATM interface.  For systems
            with IMA there is a many-to-one relationship
            between the TC Sublayer and the ATM Layer, and
            in those cases this list is indexed by the 
            ifIndex value of the underlying physical layer
            imterface."
          INDEX  {ifIndex }
          ::= { atmInterfaceTCTable 1}

plus some re-writing of Section 4.4.  However, I'd like to ask that
the folks who are interested in having this feature please volunteer
to draft the text.  (Thierry already drafted a nice diagram that
could go there.)

Thanks,

Mike Heard