Re: X.25 MIB Questions

["Dean D. Throop" <[e-mail]>]

> From [e-mail]  Wed Sep 29 10:41:23 1993
> Message-Id: <[e-mail]>
> Date: Wed, 29 Sep 93 09:36:41 EDT
> From: "Glenn C. Aikens (919-254-4588)" <[e-mail]>
> To: [e-mail]
> Subject: X.25 MIB Questions
> Status: O
> 
> I have a couple of questions that I hope the work group can answer:
> 
> 1)  Want to make sure I understand the description for the x25Restart TRAP
>     (X.25 Packet Layer MIB RFC1382).  This is how I understand it:
> 
>     - When an X.25 link is brought up, a linkUp TRAP is sent, but a x25Restart
>       TRAP is NOT sent.
>     - When an X.25 link receives a restart packet, an x25Restart TRAP is
>       sent, but linkUp and linkDown TRAPS are NOT sent.
>     - When an X.25 link sends/receives a frame reject packet, a linkDown TRAP
>       is sent, but an x25Restart TRAP is NOT sent
> 
>     Is this correct?  Am I missing anything?

Correct

> 
> 2)  Couple of questions on the Call Parm Table (X.25 Packet Layer MIB RFC1382):
> 
>     - What is the intent of the Call Parm Table?  Default, intended, current, or
>       past Call Parms?  All of them?  Implementer's choice?

It contains all call parameters in a single place with a 
single defintion which allows other tables to reference it.  The 
Call Parm Table does not define how the call parameters are 
used.  Each entry in the table contains a single set of values 
for the parameters that affect a call.  

How a set of values is used depends on how it is referenced.  
There is no need to keep entries in the table if they are not 
referenced.  If a set of call parameters is referenced from the 
IP o X.25 MIB (rfc 1461), those values probably are the values 
to be used to make a call.  That same set of value can be 
referenced from a circuit table and that reference will be 
using the call parameter values for the currently existing 
call.  Of cource all references to the same entry in the Call 
Param table must agree to (want to specify) the same values.  

The call parameter table is a little difficult to understand 
but consider how to organize the MIB without it.  The 
alternative would be to duplicate the call parameter 
definitions in the circuit table, in the ple table, in RFC
1461, etc.  Clearly we don't want to duplicate all those 
definitions every place.  We want the circuit table and the PLE 
table, etc, to simply pointer to a set of values to use (or in 
use).  

> 
>     - Maintaining a huge Call Parm Table (with past Call Parms) could require
>       a tremendous amount of memory/processing cycles.  Because of timing and
>       memory constraints, an implementation may only want to keep a subset
>       (maybe just current) of the total Call Parms.
>       What is the recommended use of the Call Parm Table for
>       implementations that may have storage/memory/processing constraints?

There is not need to keep old call parameters.  The call 
parameter table should reduce the number of objects defined 
because all circuits with the same set of value should all be 
able to share the same entry in call parameter table.  If a 
system has a couple hundred circuits open, there may only be 10 
or 20 different entries in call parameters table because many 
of the circuits will be using the same call parameters.  Of 
course the actualy numbers will be different but I'm trying to 
illustrate the idea.  

> 
> 3)  The Multiprotocol Interconnect over X.25 MIB is an Internet draft, not an
>     RFC.  Should someone who is implementing RFC1356 support the
>     Multiprotocol Interconnect MIB, or wait until the MIB is a standard?
>     Implement the draft now and the standard later?  How close is the
>     Multiprotocol Interconnect MIB to becoming a standard?

The MIB for RFC1356 is a proposed standard and can be found in RFC 1461.

> 
> 4)  What is the value of having mioxPleMaxCircuits=0 (Multiprotocol Interconnect
>     MIB) in the mioxPleTable?  The time interval when an interface is going down
>     is probably split-second and so it is probably not a great help to the
>     user since he will almost always never see it.

Setting it to zero tells the RFC1356 entity to stop accepting 
or placing calls to other entities.  Stopping new calls 
allows the administrator to gracefully terminate existing 
calls.  Once all calls are terminated, the administrator can 
change configuration, take the system down, or whatever was 
intended.  

Dean Throop		[e-mail]