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
- XID objects Dean D. Throop