Re: Initialing X.25 calls

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

>To: [e-mail]
>Date: 	Mon, 3 Feb 1992 18:39:36 -0500
>From: Ragnar Paulson <[e-mail]>
>Message-Id: <[e-mail]>
>
...
> > I believe you are correct.  The IP to X.25 address mapping for
> > addresses not in use comes from an ipNetToMediaTable.
> > This table does not have any way to indicate X.25 call parameters
> > to use to place the call.
> > 
> > The ioxConTable only contain entries for existing calls and 
> > that table does indicate the call parameters used for the call.
> > 
> 
> Way back when, we discussed being able to specify various facilities
> for various calls.  I started it with a request to have a specail version
> of the ipNetToMediaTable for the iox MIB.  As I recall the ioxConTable
> was the result of that discussion.   The comment in my copy of the MIB
> (Dated October 4 1991) says:
> 	
>           ioxConTable OBJECT-TYPE
>                   SYNTAX  SEQUENCE OF IoxConEntry
>                   ACCESS  not-accessible
>                   STATUS  mandatory
>                   DESCRIPTION
>                           "The information available about possible or
>                           existing   X.25   connections   carrying  IP
>                           traffic for this interface."
> 
> 
> The keyword being possible.  There doesn't seem to be any reason why this
> table can't be used to define the entries for making calls as well as for
> existing calls.  

I agree this would be the best way to handle this.  It looks like the
tables currently in the MIB(s) don't quite satisify the requirements.
I'll change the objects in the iox MIB to contain the X.25
call parameters used to place calls and also handle connections
already active.

> 
> In the case of incoming calls the above table probably is no good for
> displaying the facilities that were present, unless they set that appeared
> just happen to match a preconfigured table in the PLP MIB.
> So if anything it seems to be more suited for configuring our table of IP 
> to Facility mappings than for displaying what facilities appeared on an 
> existing call.

I believe that for a currently active connection, the x25ConInfoTable,
and x25ConTimrTable should contain the parameters in use for that connection.  
The parameters pointed by iox objects should only be 
for parameters used to place a call.

> 
> On the other hand, if we're re-examining all this why don't we simplify
> it and get rid of the 
> 
>           ioxConX25FcltyIndex
>           ioxConX25fcltyCcittIndex
>           ioxConX25CallParamIndex
> 
> and just specify the facilities in the iox table.  Any decent API 
> to X.25 will allow a higher layer entity to specify whatever facilities
> it needs on a per call basis.  Having to preconfigure a table in
> the PLP and then specify the table when making the call seems like 
> unnecessary overhead.  This is not how our implementation of X.25 or
> RFC877 works.  Does anyones?  If not why, why implement the MIB this 
> way.
> 
> I should have brought this all up a long time ago I guess, but I just
> let it slip by.  At the time I thought it was a reasonable compromise 
> but judging by the past couple weeks mail we should go back and look
> at it again.

I don't believe any implementation will have such a preconfigured table.
My intention was to put the definition for the call parameters into
the X.25 MIB so each higher level MIB could just reference the table
without repeating the declarations.  I don't believe any system will
have a global data base of call parameters which higher layer entities
reference.  The global table of call parameters is to assist future
MIB writers.

I have wondered if it will be possible to easily map such a table
onto an existing implementations.  I believe the global table really
resides in the SNMP agent.  When a NMS asks an
agent for some information, such as the ioxConX25FcltyIndex,
the agent would get the information from the system data base and
then figure out what index to use for it.  The index is only for SNMP
protocol use.

When a NMS wants to change the parameters used to place a call, it
would create a new row entry in the x25CallFcltyTable and then
store the value of that row in the ioxConX25FcltyIndex.  The agent
must recognize the change and copy the facilities information from
its internal global table out to the system data 
base actually used to place calls.
If the NMS wanted to, it could change one of the parameters in the
x25CallFcltyTable and that would cause the agent to change all
entries that mapped to that row.

I haven't tried to implement this but those are my intentions.
The hardest question for implmentors would be knowing when to
reuse an index in the x25CallFcltyTable because none of the
real system tables map to it.
I would be possible for Agent implementators to simply create
a uniqu index in the x25CallFcltyTable for each entry in the
system data base that contained X.25 call parameters.
Keeping a one to one mapping between index and physical table
might simplify the agent coding at the expense of duplicating
entries in the table.

We could get rid of the
	   ioxConX25FcltyIndex,
           ioxConX25fcltyCcittIndex, and
           ioxConX25CallParamIndex
objects in the iox MIB and put in objects for call parameters directly.
This would mean the next MIB for a protocol entity above X.25
would have to duplicate all the definitions in the iox MIB.
As currently designed, the newer higher MIB could just
specify three indexes and be done.

We could combine the x25CallFcltyTable, the x25CallParamTable, and
the x25CallFcltyCcittTable into one table if you feel this
simplifies things.  They are separate becasuse ISO 8208
defines them in separate sections.  

If you still feel the call parameter definitions should not be
part of the X.25 MIB, please let us know your concerns.

Dean Throop			[e-mail]