Subject: Limitations of the ifStackTable

From: Dave Fowler <[email-masked]>
Date: Tue, 03 Feb 1998 16:48:16 -0500

Gary,

I agree with your proposal.  It sounds very useful and we should put it
in the next ds0 draft.  Any objections?

Regards,
David

> I am concerned about a limitation of the current ifStackTable.  (I will
> raise it to the trunk-mib WG before raising it to the if-mib WG, since
> the limitation applies directly to the usage of the DS0-MIB.)
> 
> Since the ifStackTable only shows the high-to-low mapping, it is EASY
> for a manager to find the ds1 ifEntry upon which a given ds0 ifEntry is
> stacked.  However, it is comparatively DIFFICULT for a manager to find
> the various ds0 ifEntries that are stacked above a given ds1 ifEntry.
> 
> For example, if you know that H is the ifIndex of a particular ds0
> ifEntry, issuing a get-next of ifStackStatus.H that returns the value
> L for ifStackStatus.H.L accomplishes a trivial table lookup for the
> underlying ds1 ifEntry with an ifIndex of L.
> 
> However, if you know that L is the ifIndex of a particular ds1 ifEntry,
> a manager must either walk the entire ifStackStatus column to find
> entries of the form ifStackStatus.X.L, or else walk those portions of
> the ifStackStatus.X column where X was seen as an ifIndex INDEX of the
> dsx0ConfigTable.
> 
> Similarly, because the ifStackTable reveals the downward multiplexing
> much more readily than the upward demultiplexing, it is EASY for a
> manager to find the various ds0 ifEntries that are bundled with a given
> ds0Bundle ifEntry.  However, it is comparatively DIFFICULT for a manager
> to find the ds0Bundle ifEntry into which a particular ds0 ifEntry has
> been bundled.
> 
> I raise this concern because I am not a big fan of requiring a manager
> to walk over a whole table or multiple tables when it is possible to
> instrument a MIB to replace this with a single table lookup.  While
> some classes of management entities maintain their own cache copies of
> the ifTable and the ifStackTable, and monitor them for the slightest
> changes, other classes of management entities exist which do not even
> pretend to remember all that is in a particular agent's ifTable and
> ifStackTable, and must walk them for each such table lookup.  Since
> the ifTable and ifStackTable can grow to large proportions in large
> systems, especially in those that do DS0 channelization, it seems that
> it would be wise for us to anticipate the need for facilitating the act
> of finding low-to-high mapping values in the ifStackTable.
> 
> My first thought would be to re-invent the dsx1FracTable.  Except for
> the minor indulgence of providing duplicate information covered by the
> newer ifStackTable, and for the major indecency of allowing managers
> to assign ifIndex values, it was not such a bad table after all.  What
> it had going for it, that would help in the present case, was indexing
> first by the ifIndex value of a ds1 ifEntry, followed by indexing by the
> channel number.  In one shot this gave the ds1/chan to ds0 mapping
> information that takes a potentially lengty walk over the ifStackTable
> to find the various stacked ds0 ifEntries followed by table lookups of
> the dsx0Ds0Number, an average of half of which might turn out to be
> false hits, given that the DS0 channel number ordering is not explicitly
> indicated within the ifStackTable.
> 
> My first preference would be to add an ifInverseStackTable to the
> existing IF-MIB in RFC 2233.  Such a table would provide exactly the
> same information as in the ifStackTable (which is one minor strike
> against it), but it would also serve as a tool for demultiplexing
> interfaces in general, and not only for the present case (which is one
> major strike for it).  [Since it is too late to get that into the IF-MIB,
> and since I don't think we want to churn the IF-MIB at proposed one more
> time, I will assume that such a table may have to be added outside the
> IF-MIB.  In any case, I won't present draft text for such a table, since
> I think it is fairly obvious from what I have described.]
> 
> However, even if such an ifInverseStackTable were added to the IF-MIB,
> it still would not solve the problem of having to check potentially many
> dsx0Ds0Number values before finding the right ds1/chan to ds0 mapping.
> This leads me back to considering whether a modified version of the
> ds1FracTable would be warranted.  It would allow for immediate table
> lookup of ds1/chan to ds0 mapping, but would NOT be used to indicate
> the ds0 bundling, nor to allow the manager to assign ifIndex values.
> 
> Here is some proposed ASN.1 for such a revised dsx1FracTable.
> 
> First, expand the comments for the DS0 Config Group to include a second
> new table:
> 
>           -- The DS0 Config Group
> 
>           -- Implementation of this group is mandatory for all
>           -- systems that use a DS0 Interface.
> 
>           -- The DS0 Config Group consists of three tables:
>           --    DS0 Configuration
>           --    DS0 Channelization Control
>           --    DS0 Channel Mapping
> 
> Second, add the new table:
> 
>           dsx0ChanMappingTable OBJECT-TYPE
>               SYNTAX  SEQUENCE OF Dsx0ChanMappingEntry
>               MAX-ACCESS  not-accessible
>               STATUS  current
>               DESCRIPTION
>                       "The DS0 Channel Mapping table."
>               ::= { ds0 4 }
> 
>           dsx0ChanMappingEntry OBJECT-TYPE
>               SYNTAX  Dsx0ChannelizationEntry
>               MAX-ACCESS  not-accessible
>               STATUS  current
>               DESCRIPTION
>                       "An entry in the DS0 Channel Mapping table.  There is
>                       an entry in this table corresponding to each ds0(81)
>                       ifEntry within any interface that is channelized to
>                       the individual ds0(81) ifEntry level.
> 
>                       This table is intended to facilitate mapping from
>                       channelized interface / channel number to DS0 ifEntry.
> 
>                       While this table provides information that can also
>                       be found in the ifStackTable and dsx0ConfigTable,
>                       it provides this same information with a single table
>                       lookup, rather than by walking the ifStackTable to
>                       find the various constituent ds0(81) ifTable entries,
>                       and testing various dsx0ConfigTable entries to check
>                       for the entry with the applicable DS0 channel number."
>               INDEX   { ifIndex, dsx0Ds0Number }
>               ::= { dsx0ChanMappingTable 1 }
> 
>           Dsx0ChanMappingEntry ::=
>               SEQUENCE {
>                   dsx0ChanMappedIfIndex  InterfaceIndex
>           }
> 
>           dsx0ChanMappedIfIndex OBJECT-TYPE
>               SYNTAX  InterfaceIndex
>               MAX-ACCESS  read-only
>               STATUS  current
>               DESCRIPTION
>                       "This object indicates the ifIndex value assigned by
>                       the agent for the individual ds0(81) ifEntry that
>                       corresponds to the given DS0 channel number (specified
>                       by the INDEX element dsx0Ds0Number) of the given
>                       channelized interface (specified by INDEX element
>                       ifIndex)."
>               ::= { dsx0ChanMappingEntry 1 }
> 
> Third, add conformance information regarding the new table and objects:
> - The dsx0ChanMappingTable would be mandatory for those agents that
>   support DS0 channelization.
> - The dsx0ChanMappedIfIndex object would be a mandatory object.
> 

-- 
David Fowler                                   email:
[email-masked]
Newbridge Networks Corporation                 voice: (613) 599-3600 
ext.6559
600 March Rd, Kanata, Ontario, Canada K2K 2E6  fax:   (613) 599-3619

---

From: Gary Hanson <[email-masked]>
Date: Thu, 5 Feb 1998 15:19:10 -0800 (PST)

Dave,

Although I pointed it out as another limitation of the ifStackTable,
I completely forgot to also suggest ASN.1 text for objects to help
with finding the ds0Bundle to which a given ds0 might belong.

Also, although I forgot to point it out earlier, it seems to me that the
exact same issue holds for finding the various ds1 interfaces that result
from channelization of other ds3 or ds1 interfaces.  The ifStackTable
again does not make this an easy operation to perform.  Are we willing
to also add one more table, suitable for two purposes: to provide the
ds3/chan to ds1 mapping, and to provide the ds1/chan to ds1 mapping
(i.e., for DS2 to DS1, or for E2 to E1)?

Let me know, and I can suggest ASN.1 text for it.  Or you can probably
clone it easily from that for the dsx0ChanMappingTable.  Based on what
is already proposed, the table would belong in the DS1-MIB, and would
be the dsx0ChanMappingTable renamed as the dsx1ChanMappingTable, with
appropriate textual modifications to indicate that the channelized
interface might be a ds3(30) interface or another ds1(18) interface.
It would be indexed by ifIndex and a dsx1Ds1Number.

The latter INDEX component would be applicable for any ds1(18) interface,
so the name dsx1Ds1Number (chosen to correspond with dsx0Ds0Number) might
be less than appropriate.

Back to the first topic: Here is what I would suggest for facilitating
finding the ds0Bundle to which a given ds0 might belong.  It does not
require the addition of a new table, but instead requires that one new
read-only object be added to the existing dsx0ConfigEntry.

First, add the IMPORT-ing of InterfaceIndexOrZero from the IF-MIB,
since we would want a value of 0 to indicate that a given ds0 ifEntry
does NOT belong to any ds0Bundle.

Second, add the new object to the Dsx0ConfigEntry SEQUENCE.  I suggest
the name dsx0BundleMappedIfIndex, in order to conform to the name for
dsx0ChanMappedIfIndex.  (This might lead to confusion about which table
in which MIB it belongs to, since the latest text you suggested for the
dsx0BundleTable in the DS0BUNDLE-MIB also has attribute descriptors that
begin with the term "dsx0Bundle".  But that is probably ok, unless you
want to suggest another potentially less-confusing prefix.)

Anyway, here is the proposed SEQUENCE including the new object:

          Dsx0ConfigEntry ::=
              SEQUENCE {
                  dsx0Ds0Number            INTEGER,
                  dsx0RobbedBitSignalling  TruthValue,
                  dsx0BundleMappedIfIndex  InterfaceIndexOrZero
          }

Third, add the new object to the dsx0ConfigEntry:

          dsx0BundleMappedIfIndex OBJECT-TYPE
              SYNTAX  InterfaceIndexOrZero
              MAX-ACCESS  read-only
              STATUS  current
              DESCRIPTION
                      "This object indicates the ifIndex value assigned by
                      the agent for the ds0Bundle(80) ifEntry to which the
                      given ds0(81) ifEntry may belong.

                      If the given ds0(81) ifEntry does not belong to any
                      dsx0Bundle(80) ifEntry, then this object has a value
                      of zero.

                      While this object provides information that can also
                      be found in the ifStackTable, it provides this same
                      information with a single table lookup, rather than
                      by walking the ifStackTable to find the possibly
                      non-existent dsx0Bundle(81) ifTable entry that may
                      be stacked above the given ds0(81) ifTable entry."
              ::= { dsx0ConfigEntry 3 }

Fourth, add conformance information regarding the new table and objects:
- The dsx0BundleMappedIfIndex object would be a mandatory object.

Regards,
Gary

---

From: Gary Hanson <[email-masked]>
Date: Fri, 6 Feb 1998 14:46:57 -0800 (PST)

Dave and Jason,

I was apparently quite sloppy yesterday and mistyped "ds0Bundle(82)" as
"ds0Bundle(80)", as "dsx0Bundle(80)", and as "dsx0Bundle(80)", all in the
DESCRIPTION for dsx0BundleMappedIfIndex.

I also mistyped it in my message to Jason as "ds0Bundle(80)".

Whoops!  Sorry about that.  It obviously should have been "ds0Bundle(82)"
in each case.  I have shown the offending text in the proposed DESCRIPTION
below.

On Thu, 5 Feb 1998, Gary Hanson wrote:

> [...]
  should be:            the agent for the ds0Bundle(82) ifEntry to which the
>                       dsx0Bundle(80) ifEntry, then this object has a value
  should be:            ds0Bundle(82) ifEntry, then this object has a value
>                       non-existent dsx0Bundle(81) ifTable entry that may
  should be:            non-existent ds0Bundle(82) ifTable entry that may
> [...]

Regards,
Gary

---

From: Roy Spitzer <[email-masked]>
Date: Mon, 09 Feb 1998 10:07:05 -0500

Gary,

Since both E1 and DS1 may be fractionalized, is there any problem referring to
E1 timeslots as DS0s and groups of timeslots as DS0 bundles or are there more
appropriate terms (terminology) for those time slots and time slot bundles?

Thank you for your help.

Regards,
Roy

--
Roy Spitzer                             Telogy Networks
Phone (301) 515-6531                    20250 Century Boulevard
FAX:  (301) 515-7687                    Germantown, Maryland 20874
email [email-masked]