XID objects

"Dean D. Throop" <throop@dg-rtp.dg.com> Fri, 24 January 1992 23:29 UTC

Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa21878; 24 Jan 92 18:29 EST
Received: from dg-rtp.rtp.dg.com by NRI.NRI.Reston.VA.US id aa21863; 24 Jan 92 18:29 EST
Received: from commtg3.rtp.dg.com by dg-rtp.dg.com (5.4/dg-rtp-proto) id AA03229; Fri, 24 Jan 1992 18:12:45 -0500
Received: by commtg3 (5.4/rtp-s04) id AA28416; Fri, 24 Jan 1992 18:12:44 -0500
Date: Fri, 24 Jan 1992 18:12:44 -0500
From: "Dean D. Throop" <throop@dg-rtp.dg.com>
Message-Id: <9201242312.AA28416@commtg3>
To: x25mib@dg-rtp.dg.com
Subject: XID objects

Some people didn't get the original posting of this message due
to a mailng list error.

I have started thinking about the objects we need to add  to  the
LAPB  MIB  to  support XID (ala ISO 8885).  I presume the current
lapbParam* objects will become the  objects   that   define   how
the   link   is  actually    operating    (i.e.    contain    the
results  after  XID negotiation has completed).

I have a number of questions I would like comments  on  before  I
actually revise the current LAPB MIB draft.

I believe we need an optional table for the values to propose  in
parameter  negotiation (i.e. the values to send in an XID frame).
Do we also want tables  for  Address  Resolution,  and  Multilink
parameter negotiation values to go in the XID frame?

(I'm willing to add objects for MLP operation  to  the  LAPB  MIB
providing  people  have  concrete  proposals  and the discussions
don't impede progress.  All such objects would be optional.)

We have some inconsistencies between the parameters in  8885  and
the current lapbParam* objects.

The current MIB only  reports  transmit  window  size  (k)  while
negotiated  parameters  contains  fields  for  both  transmit and
receive.  Should we add a MIB object for the receive window  size
in use?

What about Maximum frame size?  Should we add  an  object  so  we
have a separate object for the transmit and receive maximum frame
size?  If we have separate transmit  and  receive  maximum  frame
sizes,  how  does  that affect the ifMtu value for the interface?
(I suspect we as MIB writers can simply say the ifMtu  should  be
chosen  to  achieve  internal  consistency  and  it  need have no
relation to the transmit and receive maximum frame size.)

Should we add a parameter for port number (for multilink use)?

Should we add an object to record the ID value  from  the  remote
DTE/DCE?   If  so, which values?  Maybe we should just record the
entire XID frame and  let  the  NMS  crack  it  and  display  the
negotiation options available but not selected.

Do we need to add other cases in the lapbParamAction* objects  to
handle  XID?  Should we make the value of these objects an Object
Identifier to make it easier to add other values in the future?

Currently the MIB time values for T1, T2, T3, and T4 are  defined
to  be  1/100ths  of  a  second.  However the XID field for these
values specifies these values as msec.  What should we  do  about
the units difference?

Dean Throop             throop@dg-rtp.dg.com