RFC 1382
SNMP MIB Extension for the X.25 Packet Layer
SNMP MIB Extension for the X.25 Packet Layer 🦋
okay bestie, this is RFC 1382 💖 It was written by D. Throop, who is the Editor, from Data General Corporation, and it's dated November 1992 📅. It's an IAB standards track protocol for the Internet community, so it's an official protocol spec, not just an opinion piece. The header doesn't list any Obsoletes or Updates lines, so this doc doesn't replace or change any other RFC according to its own title block 🫶
Status of This Memo ✨
so this RFC is an IAB standards track protocol that the Internet community can discuss and suggest improvements for 💬 for where it stands officially, you have to check the current edition of the "IAB Official Protocol Standards" 📚 and distribution of this memo is unlimited 🌈
Abstract 🌸
this memo defines a chunk of the Management Information Base (MIB) for network management protocols in TCP/IP-based internets 🖥️ specifically, it's all about managing the Packet Layer of X.25 🎀 the objects here work together with the objects in the "SNMP MIB Extension for LAPB" [9] and the "Definitions of Managed Objects for RS-232-like Hardware Devices" [8] so you can manage a whole X.25 protocol stack 💅
Table of Contents 📋
1. The Network Management Framework ....................... 2
2. Objects ................................................ 2
2.1 Format of Definitions ................................. 3
3. Overview ............................................... 3
3.1 Informal Overview ..................................... 3
3.2 Textual Conventions ................................... 4
3.3 Structure of MIB ...................................... 4
3.4 Tables ................................................ 5
3.5 Table Usage ........................................... 6
3.6 Conformance ........................................... 6
4. Object Definitions ..................................... 7
5. Appendix: Revision History ............................. 62
July 30 1992 ........................................... 62
June 26 1992 ........................................... 62
June 1992 .............................................. 63
April 1992 ............................................. 63
February 1992 .......................................... 65
October 1991 ........................................... 65
June 1991 .............................................. 66
April 1991 ............................................. 66
6. Acknowledgements ....................................... 66
7. References ............................................. 67
8. Security Considerations ................................ 68
9. Author's Address ....................................... 691. The Network Management Framework 🧚
the Internet-standard Network Management Framework has three parts 🎯 they tell you the rules for defining objects, the definitions of those objects, and the protocol for manipulating them
the framework organizes objects into an abstract information tree 🌳 the branches name the objects and the leaves hold the values you use to actually manage stuff. this tree is called the Management Information Base, or MIB 🫧 the concepts are in STD 16/RFC 1155, "The Structure of Management Information" or SMI [1]. the SMI is the trunk of the tree and defines the kinds of objects you use for the leaves 🌿 STD 16/RFC 1212, "Towards Concise MIB Definitions" [4], gives you a shorter way to describe things and still keeps all the principles of the SMI ✨
the core MIB definitions for the Internet suite of protocols are in RFC 1156 [2], "Management Information Base for Network Management of TCP/IP-based internets". STD 17/RFC 1213 [5] is MIB-II, which is the evolved version of MIB-I, updated with what people learned from implementing it and with new operational needs 📈
STD 15/RFC 1157 [3] is the SNMP protocol itself 📨 it defines how you manipulate the objects in a remote MIB
the tree structure lets you define new objects for experimenting and evaluating things 🧪
2. Objects 🎀
defining an object in the MIB needs an object name and a type 🏷️ object names and types are written using the subset of Abstract Syntax Notation One (ASN.1) [6] that the SMI [1] defines 💕 objects get names using ASN.1 object identifiers, which are administratively assigned names that tell you what object type you're looking at. the object name plus an optional object instance uniquely identifies one specific instance of an object 🎯 for human convenience, people often use a textual string called the OBJECT DESCRIPTOR to refer to objects too 💬
objects also have a syntax that defines the abstract data structure for that object type 🧩 the ASN.1 language [6] gives you the primitives for this. the SMI [1] purposely limits which ASN.1 constructs you can use, to keep things simple and easy to implement 🙌 the encoding of an object type just describes how to represent an object using ASN.1 encoding rules [7], so SNMP can deal with it 🫶
2.1. Format of Definitions 📝
Section 4 has the spec for every object type in this MIB module 📖 the object types use the conventions from the SMI, as extended by the stuff in "Towards Concise MIB Definitions" [4] 💅
3. Overview 🦋
3.1. Informal Overview 💭
this section explains how the objects below relate to other MIBs ✨ it's only informational, to help you see how all the pieces fit together
the objects below get used together with MIB-II and other MIBs like the LAPB MIB [9] 🖇️ a system with a complete X.25 stack running over a synchronous line will have at least two interfaces in the ifTable defined in MIB-II 🧁 one interface is for LAPB and another is for the X.25 packet layer. there are also objects in the RS-232-like MIB for the physical sync line 🔌
each software interface names the layer below it that it uses to send and receive packets 📦 the X.25 MIB object, x25OperDataLinkId, points to an instance of lapbAdmnIndex for the LAPB interface under that X.25 layer. the LAPB object, lapbOperPortId, points to an instance of rs232PortIndex for the Sync line that LAPB uses 🔗
for X.25 running over LAPB over Ethernet, lapbOperPortId would point to the instance of ifIndex for the Ethernet interface 🌐
each X.25 subnetwork gets its own entries in the ifTable 🧭 so a system with two X.25 lines has two ifTable entries for the two X.25 packet layers, and two more entries for the two LAPB interfaces. each X.25 Packet Layer MIB identifies the LAPB MIB instance under it, and each LAPB MIB identifies the Sync line under it. the system also has two entries in the rs232PortTable and the rs232SyncPortTable for the two physical lines 👯
the ifTable in MIB-II is device independent, so it doesn't have anything specific to any one type of interface 🙈 the objects below define the X.25 packet layer info for an interface of type X.25 💖 you can also tell different X.25 interfaces apart by matching the values of ifIndex with x25AdmnIndex 🔍
3.2. Textual Conventions 🎨
this MIB introduces a new data type as a textual convention for X.25 📚 it makes the spec easier to read and makes it simpler to compare with other specs when that makes sense. the important bit is that textual conventions don't change the syntax or semantics of any managed object at all 🙅♀️ they're just a tool for explaining things. objects defined with one of these are always encoded using the rules for the primitive type underneath, so no changes to the SMI or SNMP are needed to support them. they exist purely for the convenience of readers and writers chasing the elusive goal of clear, concise, and unambiguous MIB docs 🥹
this MIB introduces the data type:
X121Address3.3. Structure of MIB 🧱
instances of the objects below represent attributes of an X.25 Packet Layer interface 🎀 right now, these interfaces are identified by an ifType object in the Internet-standard MIB-II [5] with the values:
ddn-x25(4), and
rfc887-x25(5).for these interfaces, the value of the ifSpecific variable in MIB-II [5] has this OBJECT IDENTIFIER value:
x25 OBJECT IDENTIFIER ::= { transmission 5 }the objects below are similar to the ones in a draft ISO document for X.25 management [11]. some object definitions also reference the ISO spec for X.25 [10], pointing you to the section with more info about that object. having access to those docs might be useful (but isn't essential) for understanding some object names and semantics 📖 the similarity to the ISO objects also means systems that support both OSI and TCP/IP management don't need extra instrumentation 🫶
the objects here extend the Internet Standard MIB [2], and since that's an extension of MIB-II [5], these objects explicitly don't duplicate anything already in existing standards 🙌 sometimes the doc gives clarification on how to apply those existing objects 💡
the relationship between an X.25 Packet Layer interface and an interface in the Internet-standard MIB [5] is one-to-one 💞 so the value of an ifIndex object instance can be used directly to identify the matching instances of the objects defined below 🎯
3.4. Tables ✨
okay so the spec has a bunch of tables 🧚 here they are, all 7 of them:
x25AdmnTable
x25OperTable
x25StatTable
x25ChannelTable
x25CircuitTable
x25ClearedCircuitTable
x25CallParmTablethe x25AdmnTable is where the admin keeps the X.25 interface settings they can read AND set 💅 these get used when the interface starts up. once it's running, changing them might not do anything right away. they only take effect after the interface gets re-initialized, so keep that in mind bestie 🫶
the x25OperTable shows the parameters a running interface is actually using. it's read-only, so look but don't touch 👀
the x25StatTable has the operational stats for an X.25 interface. these are read-only counters that tick up whenever something happens on the interface 📈
the x25ChannelTable lets the admin manage how the channel numbers get split up 🌸
the x25CircuitTable holds info about the X.25 circuits that already exist. they show up here either because the PLE placed or answered a call, or because they're PVCs 🦋
the x25ClearedCircuitTable is the place to record the termination info for circuits that got cleared in an abnormal way. it's giving "the crime scene log" 💀
the x25CallParmTable holds the call parameters used when calling other systems. other tables point at these entries instead of copying them, which is so iconic 👑 for example, the x25AdmnTable has one object that points to the entry with the default PLE parameters. the x25CircuitTable has one object that points to the entry with the parameters that circuit is using. other MIBs can point at these entries too, to figure out which call parameters to use when making X.25 calls 🎀
3.5. Table Usage
every table does a different job, so let's go through the flow 🌈 first the admin sets the starting X.25 parameters in the x25AdmnTable for the X.25 PLE. those objects include a reference to an x25CallParmTable entry, which tells the PLE what the default call parameters are. once everything is set, the admin initializes the interface. during that init, the operating parameters get copied from the x25AdmnTable into the interface, and you can check them by reading the objects in the x25OperTable. (the interface can also be started by setting ifAdminStatus to up 💖) if there are any PVCs, their parameters can be set in the x25CircuitTable before the interface is initialized. and this should happen together with setting up the higher layer entities to use those PVCs, through the MIBs for those entities 🧚
once the PLE finishes initializing, it adds new entries to the x25CircuitTable for calls that get placed or answered. when a circuit is cleared, its entry status gets set to closed. if the clear was abnormal, an entry also gets made in the x25ClearedCircuitTable 😭 a closed entry in the x25CircuitTable maybe gets deleted by the agent whenever it has time. but a closed entry will always be reused when the PLE gives its channel number to another call, so it's not gone forever 🦋 you can find the call parameters for any circuit by checking the x25CircuitTable and following the x25CircuitCallParamId pointer to the matching entry in the x25CallParmTable.
there's no mechanism in the X.25 MIB for telling the PLE to place an X.25 call. that stuff belongs in the MIBs for the higher layer entities that actually use the X.25 circuits 🙈
3.6. Conformance
all the objects defined here are mandatory 🫶 to claim conformance with this MIB, an implementation has to support every single object. some objects are about optional features, though, so there are defined values that say "this feature isn't supported" 💅 an agent for an implementation like that still has to let you read the object and return the value that means unsupported. it also has to reject set requests that try to change it 🙅♀️
some optional features have more than one object tied to them. for example, window rotation has a timer, a count, and a counter for timer runouts 🌀 in that case, if any one of those objects says the feature isn't supported, that's enough to show the feature is unsupported. the values of the other objects for that feature are undefined then 🤷♀️
4. Object Definitions 🎀
the MIB module starts here:
RFC1382-MIB DEFINITIONS ::= BEGIN
IMPORTS
Counter, Gauge, TimeTicks
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC-1212
DisplayString, transmission
FROM RFC1213-MIB
TRAP-TYPE
FROM RFC-1215
EntryStatus
FROM RFC1271-MIB
PositiveInteger,
IfIndexType
FROM RFC1381-MIB;
x25 OBJECT IDENTIFIER ::= { transmission 5 }
-- Support of the X25 subtree and all subtrees under it
-- is mandatory for all agents of system that implement X.25.
X121Address ::= OCTET STRING (SIZE(0..17))
-- 0 to 17 bytes in length containing the ASCII
-- characters [0-9], each octet contains one digit
-- of the address.
-- ###########################################################
-- X.25 Administration Table
-- ###########################################################
x25AdmnTable OBJECT-TYPE
SYNTAX SEQUENCE OF X25AdmnEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This table contains the administratively
set configuration parameters for an X.25
Packet Level Entity (PLE).
Most of the objects in this table have
corresponding objects in the x25OperTable.
This table contains the values as last set
by the administrator. The x25OperTable
contains the values actually in use by an
X.25 PLE.
Changing an administrative value may or may
not change a current operating value. The
operating value may not change until the
interface is restarted. Some
implementations may change the values
immediately upon changing the administrative
table. All implementations are required to
load the values from the administrative
table when initializing a PLE."
::= { x25 1 }
x25AdmnEntry OBJECT-TYPE
SYNTAX X25AdmnEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Entries of x25AdmnTable."
INDEX { x25AdmnIndex }
::= { x25AdmnTable 1 }
X25AdmnEntry ::= SEQUENCE {
x25AdmnIndex
IfIndexType,
x25AdmnInterfaceMode
INTEGER,
x25AdmnMaxActiveCircuits
INTEGER,
x25AdmnPacketSequencing
INTEGER,
x25AdmnRestartTimer
PositiveInteger,
x25AdmnCallTimer
PositiveInteger,
x25AdmnResetTimer
PositiveInteger,
x25AdmnClearTimer
PositiveInteger,
x25AdmnWindowTimer
PositiveInteger,
x25AdmnDataRxmtTimer
PositiveInteger,
x25AdmnInterruptTimer
PositiveInteger,
x25AdmnRejectTimer
PositiveInteger,
x25AdmnRegistrationRequestTimer
PositiveInteger,
x25AdmnMinimumRecallTimer
PositiveInteger,
x25AdmnRestartCount
INTEGER,
x25AdmnResetCount
INTEGER,
x25AdmnClearCount
INTEGER,
x25AdmnDataRxmtCount
INTEGER,
x25AdmnRejectCount
INTEGER,
x25AdmnRegistrationRequestCount
INTEGER,
x25AdmnNumberPVCs
INTEGER,
x25AdmnDefCallParamId
OBJECT IDENTIFIER,
x25AdmnLocalAddress
X121Address,
x25AdmnProtocolVersionSupported
OBJECT IDENTIFIER
}
x25AdmnIndex OBJECT-TYPE
SYNTAX IfIndexType
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The ifIndex value for the X.25 Interface."
::= { x25AdmnEntry 1 }
x25AdmnInterfaceMode OBJECT-TYPE
SYNTAX INTEGER {
dte (1),
dce (2),
dxe (3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Identifies DCE/DTE mode in which the
interface operates. A value of dxe
indicates the mode will be determined by XID
negotiation."
REFERENCE "10733 5.9 interfaceMode"
::= { x25AdmnEntry 2 }
x25AdmnMaxActiveCircuits OBJECT-TYPE
SYNTAX INTEGER (0..4096)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The maximum number of circuits this PLE can
support; including PVCs."
REFERENCE "10733 5.9 maxActiveCircuits;
See ISO 8208, Section 3.7"
::= { x25AdmnEntry 3 }
x25AdmnPacketSequencing OBJECT-TYPE
SYNTAX INTEGER {
modulo8 (1),
modulo128 (2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The modulus of the packet sequence number
space."
REFERENCE "10733 extendedPacketSequencing;
See ISO 8208 Section 7.1.1"
::= { x25AdmnEntry 4 }
Okay so the X.25 admin table is where we're really getting into the nitty-gritty, bestie 🧚 Every one of these timers and counters is a little knob that tells an X.25 interface how long to wait and how many times to retry, and they're all read-write and mandatory. Main character energy 💖
Each entry below is numbered in x25AdmnEntry, so the order matters. Timers are in milliseconds, and 2147483647 is the special "no timer in use" value 🙈
x25AdmnRestartTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The T20 restart timer in milliseconds."
REFERENCE "10733 5.9 restartTime
See ISO 8208 Section 4.1, table 26"
::= { x25AdmnEntry 5 }
x25AdmnCallTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The T21 Call timer in milliseconds."
REFERENCE "10733 callTime;
See ISO 8208 Section 5.2.1, table 26"
::= { x25AdmnEntry 6 }
x25AdmnResetTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The T22 Reset timer in milliseconds."
REFERENCE "10733 resetTime;
See ISO 8208 Section 8.1, table 26"
::= { x25AdmnEntry 7 }
x25AdmnClearTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The T23 Clear timer in milliseconds."
REFERENCE "10733 clearTime;
See ISO 8208 Section 5.5.1, table 26"
::= { x25AdmnEntry 8 }
x25AdmnWindowTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The T24 window status transmission timer in
milliseconds. A value of 2147483647
indicates no window timer in use."
REFERENCE "10733 5.10.1 windowTime (opt);
See ISO 8208 Section 11.2.2, table 26"
::= { x25AdmnEntry 9 }
x25AdmnDataRxmtTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The T25 data retransmission timer in
milliseconds. A value of 2147483647
indicates no data retransmission timer in
use."
REFERENCE "10733 5.10.1 dataRetransmissionTime (opt);
See ISO 8208 Section 11.2.1, table 26"
::= { x25AdmnEntry 10 }
x25AdmnInterruptTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The T26 interrupt timer in milliseconds. A
value of 2147483647 indicates no interrupt
timer in use."
REFERENCE "10733 interruptTime;
See ISO 8208 Section 6.8.1, table 26"
::= { x25AdmnEntry 11 }
x25AdmnRejectTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The T27 Reject retransmission timer in
milliseconds. A value of 2147483647
indicates no reject timer in use."
REFERENCE "10733 5.10.1 dataRejectTime (opt);
See ISO 8208 Section 13.4.1, table 26"
::= { x25AdmnEntry 12 }
x25AdmnRegistrationRequestTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The T28 registration timer in milliseconds.
A value of 2147483647 indicates no
registration timer in use."
REFERENCE "10733 5.8.1 registrationRequestTime (opt)
See ISO 8208 Section 13.1.1.1, table 26"
::= { x25AdmnEntry 13 }
x25AdmnMinimumRecallTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Minimum time interval between unsuccessful
call attempts in milliseconds."
REFERENCE "10733 5.9 minimum RecallTimer"
::= { x25AdmnEntry 14 }
x25AdmnRestartCount OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The R20 restart retransmission count."
REFERENCE "10733 5.9 restartCount;
See ISO 8208 Section 4.1, table 27"
::= { x25AdmnEntry 15 }
x25AdmnResetCount OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The r22 Reset retransmission count."
REFERENCE "10733 resetCount;
See section ISO 8208 8.1, table 27"
::= { x25AdmnEntry 16 }
x25AdmnClearCount OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The r23 Clear retransmission count."
REFERENCE "10733 clearCount;
See ISO 8208 Section 5.5.1, table 27"
::= { x25AdmnEntry 17 }
x25AdmnDataRxmtCount OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The R25 Data retransmission count. This
value is irrelevant if the
x25AdmnDataRxmtTimer indicates no timer in
use."
REFERENCE "10733 5.10.1 dataRetransmissionCount (opt)
See ISO 8208 Section 11.2.1, table 27"
::= { x25AdmnEntry 18 }
x25AdmnRejectCount OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The R27 reject retransmission count. This
value is irrelevant if the
x25AdmnRejectTimer indicates no timer in
use."
REFERENCE "10733 5.10.1 dataRejectCount (opt)"
::= { x25AdmnEntry 19 }
x25AdmnRegistrationRequestCount OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The R28 Registration retransmission Count.
This value is irrelevant if the
x25AdmnRegistrationRequestTimer indicates no
timer in use."
REFERENCE "10733 5.8.1 registrationRequestCount (opt);
See ISO 8208 Section 13.1.1.1, table 27"
::= { x25AdmnEntry 20 }
x25AdmnNumberPVCs OBJECT-TYPE
SYNTAX INTEGER (0..4096)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The number of PVC configured for this PLE.
The PVCs use channel numbers from 1 to this
number."
::= { x25AdmnEntry 21 }
x25AdmnDefCallParamId OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This identifies the instance of the
x25CallParmIndex for the entry in the
x25CallParmTable which contains the default
call parameters for this PLE."
::= { x25AdmnEntry 22 }
x25AdmnLocalAddress OBJECT-TYPE
SYNTAX X121Address
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The local address for this PLE subnetwork.
A zero length address maybe returned by PLEs
that only support PVCs."
REFERENCE "10733 5.9 localDTEAddress"
::= { x25AdmnEntry 23 }
x25AdmnProtocolVersionSupported OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Identifies the version of the X.25 protocol
this interface should support. Object
identifiers for common versions are defined
below in the x25ProtocolVersion subtree."
REFERENCE "10733 5.9 protocolVersionSupported"
::= { x25AdmnEntry 24 }
-- ###########################################################
-- X.25 Operational Table
-- ###########################################################
x25OperTable OBJECT-TYPE
SYNTAX SEQUENCE OF X25OperEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The operation parameters in use by the X.25
PLE."
::= { x25 2 }
x25OperEntry OBJECT-TYPE
SYNTAX X25OperEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Entries of x25OperTable."
INDEX { x25OperIndex }
::= { x25OperTable 1 }
X25OperEntry ::= SEQUENCE {
x25OperIndex
IfIndexType,
x25OperInterfaceMode INTEGER,
x25OperMaxActiveCircuits
INTEGER,
x25OperPacketSequencing
INTEGER,
x25OperRestartTimer
PositiveInteger,
x25OperCallTimer
PositiveInteger,
x25OperResetTimer
PositiveInteger,
x25OperClearTimer
PositiveInteger,
x25OperWindowTimer
PositiveInteger,
x25OperDataRxmtTimer
PositiveInteger,
x25OperInterruptTimer
PositiveInteger,
x25OperRejectTimer
PositiveInteger,
x25OperRegistrationRequestTimer
PositiveInteger,
x25OperMinimumRecallTimer
PositiveInteger,
x25OperRestartCount
INTEGER,
x25OperResetCount
INTEGER,
x25OperClearCount
INTEGER,
x25OperDataRxmtCount
INTEGER,
x25OperRejectCount
INTEGER,
x25OperRegistrationRequestCount
INTEGER,
x25OperNumberPVCs
INTEGER,
x25OperDefCallParamId
OBJECT IDENTIFIER,
x25OperLocalAddress
X121Address,
x25OperDataLinkId
OBJECT IDENTIFIER,
x25OperProtocolVersionSupported
OBJECT IDENTIFIER
}Okay, so that's the whole column list for the x25OperEntry, and every one of these is a column we'll now walk through, one by one. 🎀 Here's the first one, the index.
x25OperIndex OBJECT-TYPE
SYNTAX IfIndexType
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The ifIndex value for the X.25 interface."
::= { x25OperEntry 1 }Next up is the interface mode, which is giving main character energy 💅. It tells you whether the interface is acting as DCE, DTE, or dxe. And dxe is the fun one: it means the role gets figured out by XID negotiation at the Link Layer, and that negotiation hasn't happened yet 🫶.
x25OperInterfaceMode OBJECT-TYPE
SYNTAX INTEGER {
dte (1),
dce (2),
dxe (3)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Identifies DCE/DTE mode in which the
interface operates. A value of dxe
indicates the role will be determined by XID
negotiation at the Link Layer and that
negotiation has not yet taken place."
REFERENCE "10733 5.9 interfaceMode"
::= { x25OperEntry 2 }Now the max active circuits, which is capped at 4096 and tells you how many circuits this PLE can support 🌸. The reference also points at ISO 8208, Section 3.7.
x25OperMaxActiveCircuits OBJECT-TYPE
SYNTAX INTEGER (0..4096)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Maximum number of circuits this PLE can
support."
REFERENCE "10733 5.9 maxActiveCircuits
See ISO 8208, Section 3.7"
::= { x25OperEntry 3 }Packet sequencing is ngl a little bit iconic 🦋. It's either modulo8 or modulo128, and it's the modulus of the packet sequence number space.
x25OperPacketSequencing OBJECT-TYPE
SYNTAX INTEGER {
modulo8 (1),
modulo128 (2)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The modulus of the packet sequence number
space."
REFERENCE "10733 extendedPacketSequencing;
See ISO 8208 Section 7.1.1"
::= { x25OperEntry 4 }Now we're into the timers, and they are all giving the same energy, so let's go. The restart timer is T20 and it's in milliseconds 🍓.
x25OperRestartTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The T20 restart timer in milliseconds."
REFERENCE "10733 5.9 restartTime;
See ISO 8208 Section 4.1, table 26"
::= { x25OperEntry 5 }The call timer is T21, also in milliseconds ⏱️ ✨.
x25OperCallTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The T21 Call timer in milliseconds."
REFERENCE "10733 callTime;
See ISO 8208 Section 5.2.1, table 26"
::= { x25OperEntry 6 }Reset timer is T22, same unit, same slay 💖.
x25OperResetTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The T22 Reset timer in milliseconds."
REFERENCE "10733 resetTime;
See ISO 8208 Section 8.1, table 26"
::= { x25OperEntry 7 }Clear timer is T23 🌈.
x25OperClearTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The T23 Clear timer in milliseconds."
REFERENCE "10733 clearTime;
See ISO 8208 Section 5.5.1, table 26"
::= { x25OperEntry 8 }Window timer is T24, and here's the detail I'm obsessed with: 2147483647 means no window timer is in use 🙈. It's basically the "I'm off duty" value.
x25OperWindowTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The T24 window status transmission timer
milliseconds. A value of 2147483647
indicates no window timer in use."
REFERENCE "10733 5.10.1 windowTime (opt);
See ISO 8208 Section 11.2.2, table 26"
::= { x25OperEntry 9 }Data retransmission timer is T25, and it uses that same 2147483647 "nothing running here" sentinel 🫶.
x25OperDataRxmtTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The T25 Data Retransmission timer in
milliseconds. A value of 2147483647
indicates no data retransmission timer in
use."
REFERENCE "10733 5.10.1 dataRetransmissionTime (opt);
See ISO 8208 Section 11.2.1, table 26"
::= { x25OperEntry 10 }Interrupt timer is T26. If it reads 2147483647, then interrupts simply aren't being used 🔥.
x25OperInterruptTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The T26 Interrupt timer in milliseconds. A
value of 2147483647 indicates interrupts are
not being used."
REFERENCE "10733 interruptTime;
See ISO 8208 Section 6.8.1, table 26"
::= { x25OperEntry 11 }Reject timer is T27, and yep, you guessed it, 2147483647 means no reject timer in use 💀.
x25OperRejectTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The T27 Reject retransmission timer in
milliseconds. A value of 2147483647
indicates no reject timer in use."
REFERENCE "10733 5.10.1 dataRejectTime (opt);
See ISO 8208 Section 13.4.1, table 26"
::= { x25OperEntry 12 }Registration request timer is T28. Same sentinel, same vibe 🧚.
x25OperRegistrationRequestTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The T28 registration timer in milliseconds.
A value of 2147483647 indicates no
registration timer in use."
REFERENCE "10733 5.8.1 registrationRequestTime (opt);
See ISO 8208 Section 13.1.1.1, table 26"
::= { x25OperEntry 13 }Minimum recall timer is the minimum time interval between unsuccessful call attempts, in milliseconds. Honestly the cutest part of this whole thing 🌸.
x25OperMinimumRecallTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Minimum time interval between unsuccessful
call attempts in milliseconds."
REFERENCE "10733 5.9 minimum RecallTimer"
::= { x25OperEntry 14 }Now the counts, which are all bounded at 0..65535 🍓. Restart count is R20, and it's the restart retransmission count.
x25OperRestartCount OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The R20 restart retransmission count."
REFERENCE "10733 5.9 restartCount
See ISO 8208 Section 4.1, table 27"
::= { x25OperEntry 15 }Reset count is r22, the Reset retransmission count 💜.
x25OperResetCount OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The r22 Reset retransmission count."
REFERENCE "10733 resetCount;
See section ISO 8208 8.1, table 27"
::= { x25OperEntry 16 }Clear count is r23, the Clear retransmission count 🦋.
x25OperClearCount OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The r23 Clear retransmission count."
REFERENCE "10733 clearCount;
See ISO 8208 Section 5.5.1, table 27"
::= { x25OperEntry 17 }Data retransmission count is R25. This one has a catch: it's undefined if the x25OperDataRxmtTimer says no timer is in use 👀.
The data retransmission count is undefined whenever x25OperDataRxmtTimer indicates no timer in use. Don't go reading meaning into it then 🙈.
x25OperDataRxmtCount OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The R25 Data retransmission count. This
value is undefined if the
x25OperDataRxmtTimer indicates no timer in
use."
REFERENCE "10733 5.10.1 dataRetransmissionCount (opt);
See ISO 8208 Section 11.2.1, table 27"
::= { x25OperEntry 18 }Reject count is R27, and same deal: it's undefined if x25OperRejectTimer indicates no timer in use 🌈.
x25OperRejectCount OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The R27 reject retransmission count. This
value is undefined if the x25OperRejectTimer
indicates no timer in use."
REFERENCE "10733 5.10.1 dataRejectCount (opt)"
::= { x25OperEntry 19 }Last one in this batch: the registration request count, R28 ✨. Like the data and reject counts, it's undefined when its timer isn't in use.
x25OperRegistrationRequestCount OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The R28 Registration retransmission Count.
This value is undefined if the
x25OperREgistrationRequestTimer indicates no
timer in use."
REFERENCE "10733 5.8.1 registrationRequestCount (opt);
See ISO 8208 Section 13.1.1.1, table 27"
::= { x25OperEntry 20 }Okay bestie, we're picking up right where the X.25 operational stuff leaves off 🎀✨ Here's the next batch of object definitions, and yes, they're all in the code blocks so nothing gets lost 💅
x25OperNumberPVCs OBJECT-TYPE
SYNTAX INTEGER (0..4096)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of PVC configured for this PLE.
The PVCs use channel numbers from 1 to this
number."
::= { x25OperEntry 21 }
x25OperDefCallParamId OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This identifies the instance of the
x25CallParmIndex for the entry in the
x25CallParmTable that contains the default
call parameters for this PLE."
::= { x25OperEntry 22 }
x25OperLocalAddress OBJECT-TYPE
SYNTAX X121Address
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The local address for this PLE subnetwork.
A zero length address maybe returned by PLEs
that only support PVCs."
REFERENCE "10733 5.9 localDTEAddress"
::= { x25OperEntry 23 }
x25OperDataLinkId OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"This identifies the instance of the index
object in the first table of the most device
specific MIB for the interface used by this
PLE."
::= { x25OperEntry 24 }
x25OperProtocolVersionSupported OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Identifies the version of the X.25 protocol
this interface supports. Object identifiers
for common versions are defined below in the
x25ProtocolVersion subtree."
REFERENCE "10733 5.9 protocolVersionSupported"
::= { x25OperEntry 25 }So the first few are the operational bits: how many PVCs there are (channel numbers 1 up to that count ✨), which call-parameter row holds the defaults 📋, the local X.121 address (which can be zero-length on PVC-only PLEs, so don't panic if you see that 🙈), the data link pointer 🔗, and the X.25 version this interface speaks 🦋
Next up is the bit where the MIB-II objects get some comment love 💜
-- MIB-II also provides:
-- ifDescr:
-- On an X.25 interface this must include sufficient
-- information to enable the system's administrator
-- to determine the appropriate configuration
-- information on a system having multiple X.25
-- subnetworks.
-- ifType: ddn-x25 or rfc877-x25
-- an interface of type ddn-x25 will use an algorithm to
-- translate between X.121 address and IP addresses.
-- An interface of type rfc877-x25 will use a
-- configuration table to translate between X.121
-- addresses and IP addresses.
-- ifMtu: the maximum PDU a higher layer can pass to X.25 or
-- receive from X.25
-- ifSpeed:
-- This will be the value of the local clock for this line.
-- A value of zero indicates external clocking.
-- ifAdminStatus:
-- ifOperStatus
-- ifLastChangeNow we're into the statistics table, which is basically the X.25 scorecard 📊🔥 Every counter in here is tracking something different, so read the descriptions carefully, periodt 💅
-- ###########################################################
-- X.25 Statistics Table
-- ###########################################################
x25StatTable OBJECT-TYPE
SYNTAX SEQUENCE OF X25StatEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Statistics information about this X.25
PLE."
::= { x25 3 }
x25StatEntry OBJECT-TYPE
SYNTAX X25StatEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Entries of the x25StatTable."
INDEX { x25StatIndex }
::= { x25StatTable 1 }
X25StatEntry ::= SEQUENCE {
x25StatIndex
IfIndexType,
x25StatInCalls
Counter,
x25StatInCallRefusals
Counter,
x25StatInProviderInitiatedClears
Counter,
x25StatInRemotelyInitiatedResets
Counter,
x25StatInProviderInitiatedResets
Counter,
x25StatInRestarts
Counter,
x25StatInDataPackets
Counter,
x25StatInAccusedOfProtocolErrors
Counter,
x25StatInInterrupts
Counter,
x25StatOutCallAttempts
Counter,
x25StatOutCallFailures
Counter,
x25StatOutInterrupts
Counter,
x25StatOutDataPackets
Counter,
x25StatOutgoingCircuits
Gauge,
x25StatIncomingCircuits
Gauge,
x25StatTwowayCircuits
Gauge,
x25StatRestartTimeouts
Counter,
x25StatCallTimeouts
Counter,
x25StatResetTimeouts
Counter,
x25StatClearTimeouts
Counter,
x25StatDataRxmtTimeouts
Counter,
x25StatInterruptTimeouts
Counter,
x25StatRetryCountExceededs
Counter,
x25StatClearCountExceededs
Counter
}
x25StatIndex OBJECT-TYPE
SYNTAX IfIndexType
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The ifIndex value for the X.25 interface."
::= { x25StatEntry 1 }
x25StatInCalls OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of incoming calls received."
::= { x25StatEntry 2 }
x25StatInCallRefusals OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of incoming calls refused. This
includes calls refused by the PLE and by
higher layers. This also includes calls
cleared because of restricted fast select."
::= { x25StatEntry 3 }
x25StatInProviderInitiatedClears OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of clear requests with a cause
code other than DTE initiated."
REFERENCE "10733 providerInitiatedDisconnect"
::= { x25StatEntry 4 }
x25StatInRemotelyInitiatedResets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of reset requests received with
cause code DTE initiated."
REFERENCE "10733 remotelyInitiatedResets"
::= { x25StatEntry 5 }
x25StatInProviderInitiatedResets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of reset requests received with
cause code other than DTE initiated."
REFERENCE "10733 ProviderInitiatedResets"
::= { x25StatEntry 6 }
x25StatInRestarts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of remotely initiated (including
provider initiated) restarts experienced by
the PLE excluding the restart associated
with bringing up the PLE interface. This
only counts restarts received when the PLE
already has an established connection with
the remove PLE."
REFERENCE "10733 5.9 remotelyInitiatedRestarts"
::= { x25StatEntry 7 }
x25StatInDataPackets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of data packets received."
REFERENCE "10733 5.9 dataPacketsReceived."
::= { x25StatEntry 8 }
x25StatInAccusedOfProtocolErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of packets received containing a
procedure error cause code. These include
clear, reset, restart, or diagnostic
packets."
REFERENCE "CD 10733 5.9 accusedOfProtocolError"
::= { x25StatEntry 9 }
x25StatInInterrupts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of interrupt packets received by
the PLE or over the PVC/VC."
REFERENCE "10733 interruptPacketsReceived"
::= { x25StatEntry 10 }
x25StatOutCallAttempts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of calls attempted."
REFERENCE "10733 5.9 callAttempts"
::= { x25StatEntry 11 }
x25StatOutCallFailures OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of call attempts which failed.
This includes calls that were cleared
because of restrictive fast select."
::= { x25StatEntry 12 }
x25StatOutInterrupts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of interrupt packets send by the
PLE or over the PVC/VC."
REFERENCE "10733 InterruptPacketsSent"
::= { x25StatEntry 13 }okay bestie, the next batch of stat objects is all about counting things 🧾✨ every one of them is read-only, and they're basically receipts for everything that happened on the PLE. literally iconic 💅
x25StatOutDataPackets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of data packets sent by this
PLE."
REFERENCE "10733 dataPacketSent"
::= { x25StatEntry 14 }
x25StatOutgoingCircuits OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of active outgoing circuits.
This includes call requests sent but not yet
confirmed. This does not count PVCs."
::= { x25StatEntry 15 }
x25StatIncomingCircuits OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of active Incoming Circuits.
This includes call indications received but
not yet acknowledged. This does not count
PVCs."
::= { x25StatEntry 16 }
x25StatTwowayCircuits OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of active two-way Circuits.
This includes call requests sent but not yet
confirmed. This does not count PVCs."
::= { x25StatEntry 17 }
x25StatRestartTimeouts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times the T20 restart timer
expired."
REFERENCE "10733 5.9 restartTimeouts"
::= { x25StatEntry 18 }
x25StatCallTimeouts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times the T21 call timer
expired."
REFERENCE "10733 5.9 callTimeouts"
::= { x25StatEntry 19 }
x25StatResetTimeouts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times the T22 reset timer
expired."
REFERENCE "10733 5.9 resetTimeouts"
::= { x25StatEntry 20 }
x25StatClearTimeouts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times the T23 clear timer
expired."
REFERENCE "10733 5.9 clearTimeouts"
::= { x25StatEntry 21 }
x25StatDataRxmtTimeouts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times the T25 data timer
expired."
REFERENCE "10733 5.9 dataRetransmissionsTimerExpiries"
::= { x25StatEntry 22 }
x25StatInterruptTimeouts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times the T26 interrupt timer
expired."
REFERENCE "10733 5.9 interruptTimerExpires"
::= { x25StatEntry 23 }
x25StatRetryCountExceededs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times a retry counter was
exhausted."
REFERENCE "10733 5.9 retryCountsExceeded"
::= { x25StatEntry 24 }
x25StatClearCountExceededs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times the R23 clear count was
exceeded."
REFERENCE "10733 5.9 clearCountsExceeded"
::= { x25StatEntry 25 }ngl the timeout objects are giving main character energy 🕰️💀 each T-timer (T20, T21, T22, T23, T25, T26) gets its own counter, so you can see exactly which timer went off and how often. the retry and clear-count ones are the same vibe, just counting when a limit got hit 🙈
then there's this little MIB-II cameo, which is just comments. it's basically the MIB-II stuff that overlaps with X.25, written out as notes 🌸
-- MIB-II also contains:
-- ifInOctets: Number of data octets delivered to upper
-- layer entities.
-- ifInUcastPkts: Number of packets with a clear M-bit
-- delivered to higher layer entities.
-- ifDiscards: Number of packets dropped for lack of buffering
-- ifInErrors: Number of packets received containing errors
-- REFERENCE ProtocolErrorsDetectedLocally
-- ifInUnknownProtos: Number of packets with unknown circuit
-- identifier.
-- ifOutOctets: Number of data octets delivered by
-- X.25 to upper layers.
-- ifOutUcastPkts: Number of packets with a clear M-bit
-- received from higher layer entities.next up is the X.25 Channel Table 🧚✨ this one is about the channel number configuration on a PLE. the big thing to know is that these are the configured values, so if you change them after the interface has started, the operating PLE might not reflect that. bestie, that's a whole vibe 💅
-- ###########################################################
-- X.25 Channel Table
-- ###########################################################
x25ChannelTable OBJECT-TYPE
SYNTAX SEQUENCE OF X25ChannelEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"These objects contain information about the
channel number configuration in an X.25 PLE.
These values are the configured values.
changes in these values after the interfaces
has started may not be reflected in the
operating PLE."
REFERENCE "See ISO 8208, Section 3.7"
::= { x25 4 }
x25ChannelEntry OBJECT-TYPE
SYNTAX X25ChannelEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Entries of x25ChannelTable."
REFERENCE "This provides the information available
in 10733 logicalChannelAssignments."
INDEX { x25ChannelIndex }
::= { x25ChannelTable 1 }
X25ChannelEntry ::= SEQUENCE {
x25ChannelIndex
IfIndexType,
x25ChannelLIC
INTEGER,
x25ChannelHIC
INTEGER,
x25ChannelLTC
INTEGER,
x25ChannelHTC
INTEGER,
x25ChannelLOC
INTEGER,
x25ChannelHOC
INTEGER
}
x25ChannelIndex OBJECT-TYPE
SYNTAX IfIndexType
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The ifIndex value for the X.25 Interface."
::= { x25ChannelEntry 1 }
x25ChannelLIC OBJECT-TYPE
SYNTAX INTEGER (0..4095)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Lowest Incoming channel."
::= { x25ChannelEntry 2 }
x25ChannelHIC OBJECT-TYPE
SYNTAX INTEGER (0..4095)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Highest Incoming channel. A value of zero
indicates no channels in this range."
::= { x25ChannelEntry 3 }
x25ChannelLTC OBJECT-TYPE
SYNTAX INTEGER (0..4095)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Lowest Two-way channel."
::= { x25ChannelEntry 4 }
x25ChannelHTC OBJECT-TYPE
SYNTAX INTEGER (0..4095)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Highest Two-way channel. A value of zero
indicates no channels in this range."
::= { x25ChannelEntry 5 }
x25ChannelLOC OBJECT-TYPE
SYNTAX INTEGER (0..4095)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Lowest outgoing channel."
::= { x25ChannelEntry 6 }
x25ChannelHOC OBJECT-TYPE
SYNTAX INTEGER (0..4095)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Highest outgoing channel. A value of zero
indicates no channels in this range."
::= { x25ChannelEntry 7 }last bit for this part is the X.25 Per Circuits Information table 🦋 it holds general info about one specific circuit on the PLE, and it's indexed by both the ifIndex and the channel, so each circuit gets its own little row. the entry we're in the middle of is already loaded with status, establish time, direction, and a bunch of counters 🎀
-- ###########################################################
-- X25 Per Circuits Information Table
-- ###########################################################
x25CircuitTable OBJECT-TYPE
SYNTAX SEQUENCE OF X25CircuitEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"These objects contain general information
about a specific circuit of an X.25 PLE."
::= { x25 5 }
x25CircuitEntry OBJECT-TYPE
SYNTAX X25CircuitEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Entries of x25CircuitTable."
INDEX { x25CircuitIndex,
x25CircuitChannel }
::= { x25CircuitTable 1 }
X25CircuitEntry ::= SEQUENCE {
x25CircuitIndex
IfIndexType,
x25CircuitChannel
INTEGER,
x25CircuitStatus
INTEGER,
x25CircuitEstablishTime
TimeTicks,
x25CircuitDirection
INTEGER,
x25CircuitInOctets
Counter,
x25CircuitInPdus
Counter,
x25CircuitInRemotelyInitiatedResets
Counter,
x25CircuitInProviderInitiatedResets
Counter, x25CircuitInInterrupts
Counter,
x25CircuitOutOctets
Counter,
x25CircuitOutPdus
Counter,
x25CircuitOutInterrupts
Counter,
x25CircuitDataRetransmissionTimeouts
Counter,
x25CircuitResetTimeouts
Counter,
x25CircuitInterruptTimeouts
Counter,
x25CircuitCallParamId
OBJECT IDENTIFIER,
x25CircuitCalledDteAddress
X121Address,
x25CircuitCallingDteAddress
X121Address,
x25CircuitOriginallyCalledAddress
X121Address,
x25CircuitDescr
DisplayString
}okay so that's the full list of columns in the circuit entry 💖 every single one of them gets its own little object definition down below, so let's go meet them 🦋
x25CircuitIndex OBJECT-TYPE
SYNTAX IfIndexType
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The ifIndex value for the X.25 Interface."
::= { x25CircuitEntry 1 }
x25CircuitChannel OBJECT-TYPE
SYNTAX INTEGER (0..4095)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The channel number for this circuit."
::= { x25CircuitEntry 2 }
x25CircuitStatus OBJECT-TYPE
SYNTAX INTEGER { -- state table states
invalid (1),
closed (2), -- (p1)
calling (3), -- (p2,p3,p5)
open (4), -- (p4)
clearing (5), -- (p6,p7)
pvc (6),
pvcResetting (7),
startClear (8), -- Close cmd
startPvcResetting (9), -- Reset cmd
other (10)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This object reports the current status of
the circuit.
An existing instance of this object can only
be set to startClear, startPvcResetting, or
invalid. An instance with the value calling
or open can only be set to startClear and
that action will start clearing the circuit.
An instance with the value PVC can only be
set to startPvcResetting or invalid and that
action resets the PVC or deletes the circuit
respectively. The values startClear or
startPvcResetting will never be returned by
an agent. An attempt to set the status of
an existing instance to a value other than
one of these values will result in an error.
A non-existing instance can be set to PVC to
create a PVC if the implementation supports
dynamic creation of PVCs. Some
implementations may only allow creation and
deletion of PVCs if the interface is down.
Since the instance identifier will supply
the PLE index and the channel number,
setting this object alone supplies
sufficient information to create the
instance. All the DEFVAL clauses for the
other objects of this table are appropriate
for creating a PVC; PLEs creating entries
for placed or accepted calls will use values
appropriate for the call rather than the
value of the DEFVAL clause. Two managers
trying to create the same PVC can determine
from the return code which manager succeeded
and which failed (the failing manager fails
because it can not set a value of PVC for an
existing object).
An entry in the closed or invalid state may
be deleted or reused at the agent's
convence. If the entry is kept in the
closed state, the values of the parameters
associated with the entry must be correct.
Closed implies the values in the circuit
table are correct.
The value of invalid indicates the other
values in the table are invalid. Many
agents may never return a value of invalid
because they dynamically allocate and free
unused table entries. An agent for a
statically configured systems can return
invalid to indicate the entry has not yet
been used so the counters contain no
information."
REFERENCE "See ISO 8208,
table 33 for (p<n>) state table"
::= { x25CircuitEntry 3 }the status object is literally the main character here 👑 it has so many states and so many little rules attached, so read it slowly bestie 🫶 ngl the way it lists every single allowed value is iconic 💅
x25CircuitEstablishTime OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of sysUpTime when the channel was
associated with this circuit. For outgoing
SVCs, this is the time the first call packet
was sent. For incoming SVCs, this is the
time the call indication was received. For
PVCs this is the time the PVC was able to
pass data to a higher layer entity without
loss of data."
::= { x25CircuitEntry 4 }
x25CircuitDirection OBJECT-TYPE
SYNTAX INTEGER {
incoming (1),
outgoing (2),
pvc (3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The direction of the call that established
this circuit."
REFERENCE "10733 direction"
DEFVAL { pvc }
::= { x25CircuitEntry 5 }
-- X25 Circuit data flow statistics
x25CircuitInOctets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of octets of user data delivered
to upper layer."
REFERENCE "5.11 octetsReceivedCounter"
::= { x25CircuitEntry 6 }
x25CircuitInPdus OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of PDUs received for this
circuit."
REFERENCE "10733 5.11 dataPacketsReceived"
::= { x25CircuitEntry 7 }
x25CircuitInRemotelyInitiatedResets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of Resets received for this
circuit with cause code of DTE initiated."
REFERENCE "10733 remotelyInitiatedResets"
::= { x25CircuitEntry 8 }
x25CircuitInProviderInitiatedResets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of Resets received for this
circuit with cause code other than DTE
initiated."
REFERENCE "10733 ProviderInitiatedResets"
::= { x25CircuitEntry 9 }
x25CircuitInInterrupts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of interrupt packets received
for this circuit."
REFERENCE "10733 interruptPacketsReceived"
::= { x25CircuitEntry 10 }
x25CircuitOutOctets OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of octets of user data sent for
this circuit."
REFERENCE "10733 5.11 octetsSentCounter"
::= { x25CircuitEntry 11 }
x25CircuitOutPdus OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of PDUs sent for this circuit."
REFERENCE "10733 5.11 dataPacketsSent"
::= { x25CircuitEntry 12 }
x25CircuitOutInterrupts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of interrupt packets sent on
this circuit."
REFERENCE "10733 interruptPacketsSent"
::= { x25CircuitEntry 13 }
-- X25 circuit timer statistics
x25CircuitDataRetransmissionTimeouts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times the T25 data
retransmission timer expired for this
circuit."
REFERENCE "10733 5.11 dataRetransmissionTimerExpiries"
::= { x25CircuitEntry 14 }
x25CircuitResetTimeouts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times the T22 reset timer
expired for this circuit."
REFERENCE "10733 5.11 resetTimeouts"
::= { x25CircuitEntry 15 }
x25CircuitInterruptTimeouts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times the T26 Interrupt timer
expired for this circuit."
REFERENCE "10733 interruptTimerExpiries"
::= { x25CircuitEntry 16 }the counters are giving whole scrapbook energy 📖 every stat gets its own little entry, in-octets, out-octets, resets, interrupts, timers, the works 🌸 the timer ones are my fave, they count every time something times out and that's so dramatic 😭
Okay bestie, we're deep in the X.25 circuit stuff now and it's giving main character energy 💅✨ Here's the next batch of object definitions, with the circuit's call parameters, addresses, and description, then the whole cleared circuit table 🦋
x25CircuitCallParamId OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This identifies the instance of the
x25CallParmIndex for the entry in the
x25CallParmTable which contains the call
parameters in use with this circuit. The
entry referenced must contain the values
that are currently in use by the circuit
rather than proposed values. A value of
NULL indicates the circuit is a PVC or is
using all the default parameters."
DEFVAL { {0 0} }
::= { x25CircuitEntry 17 }
x25CircuitCalledDteAddress OBJECT-TYPE
SYNTAX X121Address
ACCESS read-write
STATUS mandatory
DESCRIPTION
"For incoming calls, this is the called
address from the call indication packet.
For outgoing calls, this is the called
address from the call confirmation packet.
This will be zero length for PVCs."
REFERENCE "10733 calledDTEAddress"
DEFVAL { ''h }
::= { x25CircuitEntry 18 }
x25CircuitCallingDteAddress OBJECT-TYPE
SYNTAX X121Address
ACCESS read-write
STATUS mandatory
DESCRIPTION
"For incoming calls, this is the calling
address from the call indication packet.
For outgoing calls, this is the calling
address from the call confirmation packet.
This will be zero length for PVCs."
REFERENCE "10733 callingDTEAddress"
DEFVAL { ''h }
::= { x25CircuitEntry 19 }
x25CircuitOriginallyCalledAddress OBJECT-TYPE
SYNTAX X121Address
ACCESS read-write
STATUS mandatory
DESCRIPTION
"For incoming calls, this is the address in
the call Redirection or Call Deflection
Notification facility if the call was
deflected or redirected, otherwise it will
be called address from the call indication
packet. For outgoing calls, this is the
address from the call request packet. This
will be zero length for PVCs."
REFERENCE "10733 originallyCalledAddress"
DEFVAL { ''h }
::= { x25CircuitEntry 20 }
x25CircuitDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A descriptive string associated with this
circuit. This provides a place for the
agent to supply any descriptive information
it knows about the use or owner of the
circuit. The agent may return the process
identifier and user name for the process
using the circuit. Alternative the agent
may return the name of the configuration
entry that caused a bridge to establish the
circuit. A zero length value indicates the
agent doesn't have any additional
information."
DEFVAL { ''h }
::= { x25CircuitEntry 21 }
-- ###########################################################
-- The Cleared Circuit Table
-- ###########################################################
x25ClearedCircuitEntriesRequested OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The requested number of entries for the
agent to keep in the x25ClearedCircuit
table."
::= { x25 6 }
x25ClearedCircuitEntriesGranted OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The actual number of entries the agent will
keep in the x25ClearedCircuit Table."
::= { x25 7 }
x25ClearedCircuitTable OBJECT-TYPE
SYNTAX SEQUENCE OF X25ClearedCircuitEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A table of entries about closed circuits.
Entries must be made in this table whenever
circuits are closed and the close request or
close indication packet contains a clearing
cause other than DTE Originated or a
Diagnostic code field other than Higher
Layer Initiated disconnection-normal. An
agent may optionally make entries for normal
closes (to record closing facilities or
other information).
Agents will delete the oldest entry in the
table when adding a new entry would exceed
agent resources. Agents are required to
keep the last entry put in the table and may
keep more entries. The object
x25OperClearEntriesGranted returns the
maximum number of entries kept in the
table."
REFERENCE "See ISO 8208 Section 12.2.3.1.1
and 12.2.3.1.2"
::= { x25 8 }
x25ClearedCircuitEntry OBJECT-TYPE
SYNTAX X25ClearedCircuitEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Information about a cleared circuit."
INDEX { x25ClearedCircuitIndex }
::= { x25ClearedCircuitTable 1 }
X25ClearedCircuitEntry ::= SEQUENCE {
x25ClearedCircuitIndex
PositiveInteger,
x25ClearedCircuitPleIndex
IfIndexType,
x25ClearedCircuitTimeEstablished
TimeTicks,
x25ClearedCircuitTimeCleared
TimeTicks,
x25ClearedCircuitChannel
INTEGER,
x25ClearedCircuitClearingCause
INTEGER,
x25ClearedCircuitDiagnosticCode
INTEGER,
x25ClearedCircuitInPdus
Counter,
x25ClearedCircuitOutPdus
Counter,
x25ClearedCircuitCalledAddress
X121Address,
x25ClearedCircuitCallingAddress
X121Address,
x25ClearedCircuitClearFacilities
OCTET STRING
}
x25ClearedCircuitIndex OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An index that uniquely distinguishes one
entry in the clearedCircuitTable from
another. This index will start at
2147483647 and will decrease by one for each
new entry added to the table. Upon reaching
one, the index will reset to 2147483647.
Because the index starts at 2147483647 and
decreases, a manager may do a getnext on
entry zero and obtain the most recent entry.
When the index has the value of 1, the next
entry will delete all entries in the table
and that entry will be numbered 2147483647."
::= { x25ClearedCircuitEntry 1 }
x25ClearedCircuitPleIndex OBJECT-TYPE
SYNTAX IfIndexType
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of ifIndex for the PLE which
cleared the circuit that created the entry."
::= { x25ClearedCircuitEntry 2 }
x25ClearedCircuitTimeEstablished OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of sysUpTime when the circuit was
established. This will be the same value
that was in the x25CircuitEstablishTime for
the circuit."
::= { x25ClearedCircuitEntry 3 }
x25ClearedCircuitTimeCleared OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of sysUpTime when the circuit was
cleared. For locally initiated clears, this
will be the time when the clear confirmation
was received. For remotely initiated
clears, this will be the time when the clear
indication was received."
::= { x25ClearedCircuitEntry 4 }
x25ClearedCircuitChannel OBJECT-TYPE
SYNTAX INTEGER (0..4095)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The channel number for the circuit that was
cleared."
::= { x25ClearedCircuitEntry 5 }
x25ClearedCircuitClearingCause OBJECT-TYPE
SYNTAX INTEGER (0..255)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The Clearing Cause from the clear request
or clear indication packet that cleared the
circuit."
REFERENCE "See ISO 8208 Section 12.2.3.1.1"
::= { x25ClearedCircuitEntry 6 }
x25ClearedCircuitDiagnosticCode OBJECT-TYPE
SYNTAX INTEGER (0..255)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The Diagnostic Code from the clear request
or clear indication packet that cleared the
circuit."
REFERENCE "See ISO 8208 Section 12.2.3.1.2"
::= { x25ClearedCircuitEntry 7 }The cleared circuit table is lowkey my favourite part because it's basically the circuit's diary 📓🫶 It keeps track of the clears, and the index counts down from 2147483647 like a whole countdown to a party 🎀
okay bestie, the call parameter table is about to get SO good 💅✨
x25ClearedCircuitInPdus OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of PDUs received on the
circuit."
::= { x25ClearedCircuitEntry 8 }
x25ClearedCircuitOutPdus OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of PDUs transmitted on the
circuit."
::= { x25ClearedCircuitEntry 9 }
x25ClearedCircuitCalledAddress OBJECT-TYPE
SYNTAX X121Address
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The called address from the cleared
circuit."
::= { x25ClearedCircuitEntry 10 }
x25ClearedCircuitCallingAddress OBJECT-TYPE
SYNTAX X121Address
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The calling address from the cleared
circuit."
::= { x25ClearedCircuitEntry 11 }
x25ClearedCircuitClearFacilities OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..109))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The facilities field from the clear request
or clear indication packet that cleared the
circuit. A size of zero indicates no
facilities were present."
::= { x25ClearedCircuitEntry 12 }
-- ###########################################################
-- The Call Parameter Table
-- ###########################################################
x25CallParmTable OBJECT-TYPE
SYNTAX SEQUENCE OF X25CallParmEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"These objects contain the parameters that
can be varied between X.25 calls. The
entries in this table are independent of the
PLE. There exists only one of these tables
for the entire system. The indexes for the
entries are independent of any PLE or any
circuit. Other tables reference entries in
this table. Entries in this table can be
used for default PLE parameters, for
parameters to use to place/answer a call,
for the parameters currently in use for a
circuit, or parameters that were used by a
circuit.
The number of references to a given set of
parameters can be found in the
x25CallParmRefCount object sharing the same
instance identifier with the parameters.
The value of this reference count also
affects the access of the objects in this
table. An object in this table with the
same instance identifier as the instance
identifier of an x25CallParmRefCount must be
consider associated with that reference
count. An object with an associated
reference count of zero can be written (if
its ACCESS clause allows it). An object
with an associated reference count greater
than zero can not be written (regardless of
the ACCESS clause). This ensures that a set
of call parameters being referenced from
another table can not be modified or changed
in a ways inappropriate for continued use by
that table."
::= { x25 9 }
x25CallParmEntry OBJECT-TYPE
SYNTAX X25CallParmEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Entries of x25CallParmTable."
INDEX { x25CallParmIndex }
::= { x25CallParmTable 1 }
X25CallParmEntry ::= SEQUENCE {
x25CallParmIndex
PositiveInteger,
x25CallParmStatus
EntryStatus,
x25CallParmRefCount
PositiveInteger,
x25CallParmInPacketSize
INTEGER,
x25CallParmOutPacketSize
INTEGER,
x25CallParmInWindowSize
INTEGER,
x25CallParmOutWindowSize
INTEGER,
x25CallParmAcceptReverseCharging
INTEGER,
x25CallParmProposeReverseCharging
INTEGER,
x25CallParmFastSelect
INTEGER,
x25CallParmInThruPutClasSize
INTEGER,
x25CallParmOutThruPutClasSize
INTEGER,
x25CallParmCug
DisplayString,
x25CallParmCugoa
DisplayString,
x25CallParmBcug
DisplayString,
x25CallParmNui
OCTET STRING,
x25CallParmChargingInfo
INTEGER,
x25CallParmRpoa
DisplayString,
x25CallParmTrnstDly
INTEGER,
x25CallParmCallingExt
DisplayString,
x25CallParmCalledExt
DisplayString,
x25CallParmInMinThuPutCls
INTEGER,
x25CallParmOutMinThuPutCls
INTEGER,
x25CallParmEndTrnsDly
OCTET STRING,
x25CallParmPriority
OCTET STRING,
x25CallParmProtection
DisplayString,
x25CallParmExptData
INTEGER,
x25CallParmUserData
OCTET STRING,
x25CallParmCallingNetworkFacilities
OCTET STRING,
x25CallParmCalledNetworkFacilities
OCTET STRING
}
x25CallParmIndex OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A value that distinguishes this entry from
another entry. Entries in this table are
referenced from other objects which identify
call parameters.
It is impossible to know which other objects
in the MIB reference entries in the table by
looking at this table. Because of this,
changes to parameters must be accomplished
by creating a new entry in this table and
then changing the referencing table to
identify the new entry.
Note that an agent will only use the values
in this table when another table is changed
to reference those values. The number of
other tables that reference an index object
in this table can be found in
x25CallParmRefCount. The value of the
reference count will affect the writability
of the objects as explained above.
Entries in this table which have a reference
count of zero maybe deleted at the convence
of the agent. Care should be taken by the
agent to give the NMS sufficient time to
create a reference to newly created entries.
Should a Management Station not find a free
index with which to create a new entry, it
may feel free to delete entries with a
reference count of zero. However in doing
so the Management Station much realize it
may impact other Management Stations."
::= { x25CallParmEntry 1 }
x25CallParmStatus OBJECT-TYPE
SYNTAX EntryStatus
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The status of this call parameter entry.
See RFC 1271 for details of usage."
::= { x25CallParmEntry 2 }
x25CallParmRefCount OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of references know by a
management station to exist to this set of
call parameters. This is the number of
other objects that have returned a value of,
and will return a value of, the index for
this set of call parameters. Examples of
such objects are the x25AdmnDefCallParamId,
x25OperDataLinkId, or x25AdmnDefCallParamId
objects defined above."
::= { x25CallParmEntry 3 }
x25CallParmInPacketSize OBJECT-TYPE
SYNTAX INTEGER (0..4096)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The maximum receive packet size in octets
for a circuit. A size of zero for a circuit
means use the PLE default size. A size of
zero for the PLE means use a default size of
128."
REFERENCE "10733 proposedPacketSize;
See ISO 8208 Section 15.2.2.1.1"
DEFVAL { 128 }
::= { x25CallParmEntry 4 }Okay bestie, the call parameter objects are where it gets spicy 🌶️💅 Every one is read-write and mandatory, and most of them lean on a PLE default, so a zero on a circuit means "use the PLE default" 🫶
Starting with the max transmit packet size, x25CallParmOutPacketSize 📦✨ It's an INTEGER from 0 to 4096, and its DEFVAL is 128. A zero on a circuit means use the PLE default size, and a zero for the PLE default means fall back to 128. It's stored at { x25CallParmEntry 5 } 🎀
x25CallParmOutPacketSize OBJECT-TYPE
SYNTAX INTEGER (0..4096)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The maximum transmit packet size in octets
for a circuit. A size of zero for a circuit
means use the PLE default size. A size of
zero for the PLE default means use a default
size of 128."
REFERENCE "10733 proposedPacketSize;
See ISO 8208 Section 15.2.2.1.1"
DEFVAL { 128 }
::= { x25CallParmEntry 5 }Next up is the receive window, x25CallParmInWindowSize 🪟💖 It goes from 0 to 127, and the DEFVAL is 2. Same deal as before: zero on a circuit means the PLE default, and zero for the PLE default means 2. It lives at { x25CallParmEntry 6 } 🧚
x25CallParmInWindowSize OBJECT-TYPE
SYNTAX INTEGER (0..127)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The receive window size for a circuit. A
size of zero for a circuit means use the PLE
default size. A size of zero for the PLE
default means use 2."
REFERENCE "10733 proposedWindowSize;
See ISO 8208 Section 15.2.2.1.2"
DEFVAL { 2 }
::= { x25CallParmEntry 6 }The transmit window is x25CallParmOutWindowSize 🦋 Its range and default match the receive window (0 to 127, DEFVAL 2), and it follows the same zero rules, so it's giving consistency 💜 It's at { x25CallParmEntry 7 }.
x25CallParmOutWindowSize OBJECT-TYPE
SYNTAX INTEGER (0..127)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The transmit window size for a circuit. A
size of zero for a circuit means use the PLE
default size. A size of zero for the PLE
default means use 2."
REFERENCE "10733 proposedWindowSize;
See ISO 8208 Section 15.2.2.1.2"
DEFVAL { 2 }
::= { x25CallParmEntry 7 }Now x25CallParmAcceptReverseCharging 💸🙈 This one is an enumeration with four values: default (1), accept (2), refuse (3), and neverAccept (4). The DEFVAL is refuse. neverAccept is only meant for the PLE default, and it means the PLE will never accept reverse charging. If a PLE default is set to default, it means refuse. Lowkey a lot of rules in one object, but we love a detailed queen 👑
x25CallParmAcceptReverseCharging OBJECT-TYPE
SYNTAX INTEGER {
default (1),
accept (2),
refuse (3),
neverAccept (4)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"An enumeration defining if the PLE will
accept or refuse charges. A value of
default for a circuit means use the PLE
default value. A value of neverAccept is
only used for the PLE default and indicates
the PLE will never accept reverse charging.
A value of default for a PLE default means
refuse."
REFERENCE "10733 acceptReverseCharging"
DEFVAL { refuse }
::= { x25CallParmEntry 8 }Next is x25CallParmProposeReverseCharging 🔄✨ It's another enumeration: default (1), reverse (2), and local (3). This one is about whether the PLE should propose reverse or local charging. A default on a circuit means use the PLE default, and a default for the PLE default means local. The DEFVAL is local. Fun fact: its REFERENCE line says proposedPacketSize, which is exactly what the original says, so we're keeping it as is 🙈
x25CallParmProposeReverseCharging OBJECT-TYPE
SYNTAX INTEGER {
default (1),
reverse (2),
local (3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"An enumeration defining if the PLE should
propose reverse or local charging. The
value of default for a circuit means use the
PLE default. The value of default for the
PLE default means use local."
REFERENCE "10733 proposedPacketSize;
See ISO 8208 Section 15.2.2.6"
DEFVAL { local }
::= { x25CallParmEntry 9 }Now x25CallParmFastSelect 🚀💅 It has six enumerated values, from default (1) through noRestrictedFastResponse (6). The vibe here is "expresses preference," and it's a preference for using the fast select facility. A default on a circuit means the PLE default, and a default for the PLE means noFastSelect. If a circuit has noFastSelect or noRestrictedFastResponse, it may not use fast select or restricted fast response. The DEFVAL is noFastSelect. It sits at { x25CallParmEntry 10 }.
x25CallParmFastSelect OBJECT-TYPE
SYNTAX INTEGER {
default (1),
notSpecified (2),
fastSelect (3),
restrictedFastResponse (4),
noFastSelect (5),
noRestrictedFastResponse (6)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Expresses preference for use of fast select
facility. The value of default for a
circuit is the PLE default. A value of
default for the PLE means noFastSelect. A
value of noFastSelect or
noRestrictedFastResponse indicates a circuit
may not use fast select or restricted fast
response."
REFERENCE "10733 fastSelect;
Sec ISO 8208 Section 15.2.2.6"
DEFVAL { noFastSelect }
::= { x25CallParmEntry 10 }Time for the throughput classes 🍓 x25CallParmInThruPutClasSize is the incoming one. It's an enumeration with eighteen values, and they're a whole mix: tc75 through tc64000 (numbers 3 to 13), a few reserved slots (tcReserved1, tcReserved2, tcReserved14, tcReserved15, tcReserved0), plus tcNone (17) and tcDefault (18). The DEFVAL is tcNone. A tcDefault on a circuit means use the PLE default, and a tcDefault for the PLE default means tcNone. A tcNone value means do not negotiate the throughput class. It's stored at { x25CallParmEntry 11 } ✨
x25CallParmInThruPutClasSize OBJECT-TYPE
SYNTAX INTEGER {
tcReserved1 (1),
tcReserved2 (2),
tc75 (3),
tc150 (4),
tc300 (5),
tc600 (6),
tc1200 (7),
tc2400 (8),
tc4800 (9),
tc9600 (10),
tc19200 (11),
tc48000 (12),
tc64000 (13),
tcReserved14 (14),
tcReserved15 (15),
tcReserved0 (16),
tcNone (17),
tcDefault (18)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The incoming throughput class to negotiate.
A value of tcDefault for a circuit means use
the PLE default. A value of tcDefault for
the PLE default means tcNone. A value of
tcNone means do not negotiate throughtput
class."
REFERENCE "See ISO 8208 Section 15.2.2.2, table 18"
DEFVAL { tcNone }
::= { x25CallParmEntry 11 }The outgoing one, x25CallParmOutThruPutClasSize, is basically its twin 👯♀️ It has the exact same eighteen values and the same DEFVAL of tcNone. The rules are the same too: tcDefault on a circuit means the PLE default, and tcDefault on the PLE default means tcNone. The only difference is that it's for the outgoing direction. It lives at { x25CallParmEntry 12 }.
x25CallParmOutThruPutClasSize OBJECT-TYPE
SYNTAX INTEGER {
tcReserved1 (1),
tcReserved2 (2),
tc75 (3),
tc150 (4),
tc300 (5),
tc600 (6),
tc1200 (7),
tc2400 (8),
tc4800 (9),
tc9600 (10),
tc19200 (11),
tc48000 (12),
tc64000 (13),
tcReserved14 (14),
tcReserved15 (15),
tcReserved0 (16),
tcNone (17),
tcDefault (18)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The outgoing throughput class to negotiate.
A value of tcDefault for a circuit means use
the PLE default. A value of tcDefault for
the PLE default means use tcNone. A value
of tcNone means do not negotiate throughtput
class."
REFERENCE "See ISO 8208 Section 15.2.2.2, table 18"
DEFVAL { tcNone }
::= { x25CallParmEntry 12 }Next is the Closed User Group, x25CallParmCug 🔐💜 It's a DisplayString sized 0 to 4. The description says it's two or four octets of the characters 0 through 9. A zero-length string means no facility is requested. A string of three that spells DEF means use the PLE default, and the PLE default itself can't point at DEF. The DEFVAL is ''h, and it sits at { x25CallParmEntry 13 } 🫶
x25CallParmCug OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..4))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Closed User Group to specify. This
consists of two or four octets containing
the characters 0 through 9. A zero length
string indicates no facility requested. A
string length of three containing the
characters DEF for a circuit means use the
PLE default, (the PLE default parameter may
not reference an entry of DEF.)"
REFERENCE "See ISO 8208 Section 15.2.2.3"
DEFVAL { ''h }
::= { x25CallParmEntry 13 }x25CallParmCugoa is the Closed User Group with Outgoing Access 🚪✨ It's the same size range (0 to 4) and the same DEF and zero-length rules as the CUG, except the description calls out the outgoing access version. Its ID is 14, and it's at { x25CallParmEntry 14 }.
x25CallParmCugoa OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..4))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Closed User Group with Outgoing Access
to specify. This consists of two or four
octets containing the characters 0 through
9. A string length of three containing the
characters DEF for a circuit means use the
PLE default (the PLE default parameters may
not reference an entry of DEF). A zero
length string indicates no facility
requested."
REFERENCE "See ISO 8208 Section 15.2.2.4"
DEFVAL { ''h }
::= { x25CallParmEntry 14 }The Bilateral Closed User Group is x25CallParmBcug 🤝🌸 This one is smaller: a DisplayString sized 0 to 3, with two octets of characters 0 through 9. The DEF and zero-length rules are the same as before. The DEFVAL is ''h, and it's at { x25CallParmEntry 15 }.
x25CallParmBcug OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..3))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Bilateral Closed User Group to specify.
This consists of two octets containing the
characters 0 through 9. A string length of
three containing the characters DEF for a
circuit means use the PLE default (the PLE
default parameter may not reference an entry
of DEF). A zero length string indicates no
facility requested."
REFERENCE "See ISO 8208 Section 15.2.2.5"
DEFVAL { ''h }
::= { x25CallParmEntry 15 }Last one in this batch is x25CallParmNui 🪪💖 That's the Network User Identifier facility. It's an OCTET STRING sized 0 to 108, and it's binary, not text. The value goes right after the length field, and the PLE supplies the length octet itself. A zero-length string means no facility is requested, and this value gets ignored for the PLE default parameters entry. The DEFVAL is ''h, and it's stored at { x25CallParmEntry 16 } 🌈
x25CallParmNui OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..108))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Network User Identifier facility. This
is binary value to be included immediately
after the length field. The PLE will supply
the length octet. A zero length string
indicates no facility requested. This value
is ignored for the PLE default parameters
entry."
REFERENCE "See ISO 8208 Section 15.2.2.7"
DEFVAL { ''h }
::= { x25CallParmEntry 16 }Okay so the x25CallParmChargingInfo object is first up, and it's literally the charging info facility 💅 Its value is an INTEGER with four options (default, noFacility, noChargingInfo, chargingInfo), and it's read-write and mandatory 🎀
x25CallParmChargingInfo OBJECT-TYPE
SYNTAX INTEGER {
default (1),
noFacility (2),
noChargingInfo (3),
chargingInfo (4)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The charging Information facility. A value
of default for a circuit means use the PLE
default. The value of default for the
default PLE parameters means use noFacility.
The value of noFacility means do not include
a facility."
REFERENCE "See ISO 8208 Section 15.2.2.8"
DEFVAL { noFacility }
::= { x25CallParmEntry 17 }So the vibe is: a circuit set to default just uses the PLE default 🦋 and the PLE default itself falls back to noFacility. noFacility means no facility gets included at all 🙈 The defval is noFacility too, so it's the main character by default ✨
x25CallParmRpoa is next, and it's a DisplayString that can be anywhere from 0 to 108 characters long 🌸
x25CallParmRpoa OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..108))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The RPOA facility. The octet string
contains n * 4 sequences of the characters
0-9 to specify a facility with n entries.
The octet string containing the 3 characters
DEF for a circuit specifies use of the PLE
default (the entry for the PLE default may
not contain DEF). A zero length string
indicates no facility requested."
REFERENCE "See ISO 8208, section 15.2.2.9"
DEFVAL { ''h }
::= { x25CallParmEntry 18 }Ngl the RPOA facility is giving "n times 4 digits" energy 🔢 The string holds n * 4 sequences of the characters 0-9 for n entries 💖 If a circuit's string is literally DEF, it means use the PLE default, and the PLE default entry itself can't say DEF 🙅♀️ A zero length string means no facility requested 🫶
x25CallParmTrnstDly is an INTEGER from 0 to 65537, and the number is doing a lot 🧚
x25CallParmTrnstDly OBJECT-TYPE
SYNTAX INTEGER (0..65537)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Transit Delay Selection and Indication
value. A value of 65536 indicates no
facility requested. A value of 65537 for a
circuit means use the PLE default (the PLE
default parameters entry may not use the
value 65537). The value 65535 may only be
used to indicate the value in use by a
circuit."
REFERENCE "See ISO 8208, Section 15.2.2.13"
DEFVAL { 65536 }
::= { x25CallParmEntry 19 }So 65536 means no facility requested 🙈 65537 means the PLE default for a circuit, and the PLE default entry can't use 65537 either 🚫 And 65535 is only for showing what value a circuit is actually using right now 👑
Then we hit a CCITT note 🎀
-- The following parameters are for CCITT facilities.Okay so everything after this is for the CCITT facilities 🌈
x25CallParmCallingExt is the Calling Extension facility, and it's a DisplayString from 0 to 40 characters 💅
x25CallParmCallingExt OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..40))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Calling Extension facility. This
contains one of the following:
A sequence of hex digits with the value to
be put in the facility. These digits will be
converted to binary by the agent and put in
the facility. These octets do not include
the length octet.
A value containing the three character DEF
for a circuit means use the PLE default,
(the entry for the PLE default parameters
may not use the value DEF).
A zero length string indicates no facility
requested."
REFERENCE "See ISO 8208 Section 15.3.2.1"
DEFVAL { ''h }
::= { x25CallParmEntry 20 }It can hold one of three things 🦋 First, a sequence of hex digits that the agent converts to binary and puts in the facility, without the length octet 🔥 Second, DEF for a circuit, meaning the PLE default 💜 Third, a zero length string, meaning no facility requested 🍓
x25CallParmCalledExt is the Called Extension facility, and it follows the same pattern as the calling one, just from the other side of the call 🧚
x25CallParmCalledExt OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..40))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Called Extension facility. This
contains one of the following:
A sequence of hex digits with the value to
be put in the facility. These digits will be
converted to binary by the agent and put in
the facility. These octets do not include
the length octet.
A value containing the three character DEF
for a circuit means use the PLE default,
(the entry for the PLE default parameters
may not use the value DEF).
A zero length string indicates no facility
requested."
REFERENCE "See ISO 8208 Section 15.3.2.2"
DEFVAL { ''h }
::= { x25CallParmEntry 21 }Same three options, same vibe 🫶 Hex digits get converted to binary, DEF means the PLE default, and zero length means no facility requested ✨
x25CallParmInMinThuPutCls is the minimum input throughput Class, and it's an INTEGER from 0 to 17 🌸
x25CallParmInMinThuPutCls OBJECT-TYPE
SYNTAX INTEGER (0..17)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The minimum input throughput Class. A
value of 16 for a circuit means use the PLE
default (the PLE parameters entry may not
use this value). A value of 17 indicates no
facility requested."
REFERENCE "See ISO 8208 Section 15.3.2.3"
DEFVAL { 17 }
::= { x25CallParmEntry 22 }A value of 16 on a circuit means PLE default, and the PLE entry can't use 16 🙅♀️ A value of 17 means no facility requested, and that's also the defval 💖
x25CallParmOutMinThuPutCls is the output version of the one above, with the same INTEGER range and the same rules 🦋
x25CallParmOutMinThuPutCls OBJECT-TYPE
SYNTAX INTEGER (0..17)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The minimum output throughput Class. A
value of 16 for a circuit means use the PLE
default (the PLE parameters entry may not
use this value). A value of 17 indicates no
facility requested."
REFERENCE "See ISO 8208 Section 15.3.2.3"
DEFVAL { 17 }
::= { x25CallParmEntry 23 }Input and output throughput classes are basically twins here 👯♀️ Same numbers, same meanings 💅
x25CallParmEndTrnsDly is the End-to-End Transit Delay to negotiate, and it's an OCTET STRING with a length from 0 to 6 🎀
x25CallParmEndTrnsDly OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..6))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The End-to-End Transit Delay to negotiate.
An octet string of length 2, 4, or 6
contains the facility encoded as specified
in ISO/IEC 8208 section 15.3.2.4. An octet
string of length 3 containing the three
character DEF for a circuit means use the
PLE default (the entry for the PLE default
can not contain the characters DEF). A zero
length string indicates no facility
requested."
REFERENCE "See ISO 8208 Section 15.3.2.4"
DEFVAL { ''h }
::= { x25CallParmEntry 24 }Length 2, 4, or 6 means the facility is encoded the way ISO/IEC 8208 section 15.3.2.4 says 🧚 Length 3 with DEF means the PLE default, and the PLE default entry can't contain those characters 🙈 Zero length means no facility requested 💜
x25CallParmPriority is the priority facility to negotiate, which is another OCTET STRING with length 0 to 6 🌈
x25CallParmPriority OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..6))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The priority facility to negotiate. The
octet string encoded as specified in ISO/IEC
8208 section 15.3.2.5. A zero length string
indicates no facility requested. The entry
for the PLE default parameters must be zero
length."
REFERENCE "See ISO 8208 Section 15.3.2.5"
DEFVAL { ''h }
::= { x25CallParmEntry 25 }Zero length means no facility requested 🫶 And the PLE default parameters entry has to be zero length too, so no exceptions there 🔥
x25CallParmProtection is the protection facility, and it's a DisplayString from 0 to 108 characters 🌸
x25CallParmProtection OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..108))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A string contains the following:
A hex string containing the value for the
protection facility. This will be converted
from hex to the octets actually in the
packet by the agent. The agent will supply
the length field and the length octet is not
contained in this string.
An string containing the 3 characters DEF
for a circuit means use the PLE default (the
entry for the PLE default parameters may not
use the value DEF).
A zero length string mean no facility
requested."
REFERENCE "See ISO 8208 Section 15.3.2.5"
DEFVAL { ''h }
::= { x25CallParmEntry 26 }It's a hex string that the agent converts into the actual octets in the packet 🔮 The agent supplies the length field, so the length octet isn't in the string itself 💖 DEF means PLE default, and zero length means no facility requested 🦋
x25CallParmExptData is the Expedited Data facility to negotiate, and it's an INTEGER with three options: default, noExpeditedData, and expeditedData 👑
x25CallParmExptData OBJECT-TYPE
SYNTAX INTEGER {
default (1),
noExpeditedData (2),
expeditedData (3)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Expedited Data facility to negotiate.
A value of default for a circuit means use
the PLE default value. The entry for the
PLE default parameters may not have the
value default."
REFERENCE "See ISO 8208 Section 15.3.2.7"
DEFVAL { noExpeditedData }
::= { x25CallParmEntry 27 }A circuit set to default uses the PLE default value 🎀 But the PLE default parameters entry can't be default itself, so it has to pick something real 🙅♀️ The defval here is noExpeditedData 💅
x25CallParmUserData is the call user data placed in the packet, and it's an OCTET STRING from 0 to 128 🌈
x25CallParmUserData OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..128))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The call user data as placed in the packet.
A zero length string indicates no call user
data. If both the circuit call parameters
and the PLE default have call user data
defined, the data from the circuit call
parameters will be used. If only the PLE
has data defined, the PLE entry will be
used. If neither the circuit call
parameters or the PLE default entry has a
value, no call user data will be sent."
REFERENCE "See ISO 8208 Section 12.2.1.1.6, 12.2.1.2"
DEFVAL { ''h }
::= { x25CallParmEntry 28 }This one has a little priority puzzle 🧩 If both the circuit call parameters and the PLE default have call user data, the circuit's data wins 👑 If only the PLE has data, the PLE entry gets used 💜 If neither has a value, no call user data gets sent 🙈
x25CallParmCallingNetworkFacilities is the last object in this part, and it's an OCTET STRING from 0 to 108 🦋
x25CallParmCallingNetworkFacilities OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..108))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The calling network facilities. The
facilities are encoded here exactly as
encoded in the call packet. These
facilities do not include the marker
facility code.The calling network facilities are stored exactly the way they're encoded in the call packet 🫶 And the marker facility code is not included in them 🔥 The description keeps going from here, so buckle up 🌸
A zero length string in the entry for the parameter to use when establishing a circuit means use the PLE default. A zero length string in the entry for PLE default parameters indicates no default facilities." REFERENCE "See ISO 8206 Section 15.1, category b" DEFVAL { ''h } ::= { x25CallParmEntry 29 }
x25CallParmCalledNetworkFacilities OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..108)) ACCESS read-write STATUS mandatory DESCRIPTION "The called network facilities. The facilities are encoded here exactly as encoded in the call packet. These facilities do not include the marker facility code.
A zero length string in the entry for the parameter to use when establishing a circuit means use the PLE default. A zero length string in the entry for PLE default parameters indicates no default facilities." REFERENCE "See ISO 8206 Section 15.1, category c" DEFVAL { ''h } ::= { x25CallParmEntry 30 }
-- ########################################################### -- X.25 Traps -- ###########################################################
x25Restart TRAP-TYPE ENTERPRISE x25 VARIABLES { x25OperIndex } DESCRIPTION "This trap means the X.25 PLE sent or received a restart packet. The restart that brings up the link should not send a x25Restart trap so the interface should send a linkUp trap. Sending this trap means the agent does not send a linkDown and linkUp trap." ::= 1
x25Reset TRAP-TYPE ENTERPRISE x25 VARIABLES { x25CircuitIndex, x25CircuitChannel } DESCRIPTION "If the PLE sends or receives a reset, the agent should send an x25Reset trap." ::= 2
-- ########################################################### -- X.25 Protocol Version Identifiers -- ###########################################################
x25ProtocolVersion OBJECT IDENTIFIER ::= { x25 10 }
-- X.25 CCITT 1976 version. x25protocolCcittV1976 OBJECT IDENTIFIER ::= { x25ProtocolVersion 1 }
-- X.25 CCITT 1980 version. x25protocolCcittV1980 OBJECT IDENTIFIER ::= { x25ProtocolVersion 2 }
-- X.25 CCITT 1984 version. x25protocolCcittV1984 OBJECT IDENTIFIER ::= { x25ProtocolVersion 3 }
-- X.25 CCITT 1988 version. x25protocolCcittV1988 OBJECT IDENTIFIER ::= { x25ProtocolVersion 4 }
-- X.25 1987 version of ISO 8208. x25protocolIso8208V1987 OBJECT IDENTIFIER ::= { x25ProtocolVersion 5 }
-- X.25 1989 version of ISO 8208. x25protocolIso8208V1989 OBJECT IDENTIFIER ::= { x25ProtocolVersion 6 }
-- ###########################################################
END
5. Appendix: Revision History 📜✨
okay bestie, this is the changelog and it's giving receipts 💅 every single edit, dated and numbered, so you can see how the MIB grew up
July 30 1992
The July, 1992 release (Editor's Internal Reference Number 2.14) made the following changes:
- The syntax of the index objects for tables that are congruent with the MIB-II ifTable were changed to
ifIndexType. - The
x25CallParmRefCountobject was added to thex25CallParmTable. - The description of the
x25CallParmTableandx25CallParmIndexobjects were changed to only allow writing an entry with a zero reference count. - A requirement for conformance was added after the definition of
x25in the ASN.1 definition.
June 26 1992
The June 29, 1992 release (Editor's Internal Reference Number 2.12) made the following changes:
- The range of
x25ChannelLICwas changed from(0..4096)to(0..4095). - The range of
x25ChannelHICwas changed from(0..4096)to(0..4095). - The range of
x25ChannelLTCwas changed from(0..4096)to(0..4095). - The range of
x25ChannelHTCwas changed from(0..4096)to(0..4095). - The range of
x25ChannelLOCwas changed from(0..4096)to(0..4095). - The range of
x25ChannelHOCwas changed from(0..4096)to(0..4095). - The range of
x25CircuitChannelwas changed from(1..4096)to(0..4095). - The range of
x25ClearedCircuitChannelwas changed from(1..4096)to(0..4095).
June 1992
The June 92 release (Editor's Internal Reference Number 2.11) made the following changes:
- A value of
dxewas defined forx25AdmnInterfaceModeandx25OperInterfaceMode. - The objects in the
x25ChannelTablecan now have a value of zero to indicate no channels configured in the range. - The length of an
X121Addresswas extended to 17 to accommodate the 1988 CCITT X.25 standard. - Some object descriptions have been expanded and simplified, these include: all the channel table objects except the index, and these:
x25AdmnDataRxmtCountx25AdmnRejectCountx25AdmnRegistrationRequestCountx25OperDataRxmtCountx25OperRejectCountx25OperRegistrationRequestCountx25CircuitEstablishTimex25ClearedCircuitTimeEstablishedx25ClearedCircuitTimeClearedx25CallParmIndexx25CallParmInPacketSizex25CircuitCalledAddressx25CircuitOriginallCalledAddressx25CircuitCallingAddressx25CallParmFastSelectx25CallParmCugx25CallParmCugoax25CallParmBcugx25CallParmNuix25CallParmRpoax25CallParmCallingExtx25CallParmCalledExtx25CallParmProtectionx25StatInCallRefusalsx25CallParmOutPacketSize
- The
x25StatNumberPvcsobject was deleted andx25AdmnNumberPVCsandx25OperNumberPVCsobjects added. - The object
x25StatOutDataPacketswas added. - The object
x25AdmnProtocolVersionSupportedas added. - The
x25CircuitRemoteDteAddresswas deleted. - Some ASN.1 errors were corrected.
April 1992
The April release (Editor's Internal Reference Number 2.8) made many changes to incorporate the comments of the working group meeting in March 1992.
- All reference comments were changed to reference fields.
- The type
PositiveIntegerwas imported from the RFC1381-MIB and used for all index and timer values. - The
x25PleTablewas split into thex25AdmnTable,x25OperTable, andx25StatTable. - The timer and counter objects from the
x25CircuitTablewere moved to thex25AdmnTableand replicated in thex25OperTable - The objects in the
x25CircuitTablewere reordered to put the non-integer objects at the end of the table for easier implementation. - The called and calling extension character set was extended to include a-f, and A-F.
- Additional states were added to the
x25CircuitStatusobject. - Additional values were added to
x25CircuitDirectionx25CircuitCallParamId, and the addresses in the Circuit Table for PVCs. - The length of the
X25Addresswas changed to 0..15. - The objects
x25ClearedCircuitTimeEstablished,x25ClearedCircuitInPdus, andx25ClearedCircuitOutPduswere added to thex25ClearedCircuitTable. - The name of the
x25CircuitNamewas changed tox25CircuitDescrand the description was expanded. - The access of the
x25CircuitCallParamIdwas changed to read-only. - The
x25ClearedCircuitCodesobject was split into thex25ClearedCircuitClearingCauseandx25ClearedCircuitDiagnosticCodeobjects. - The semantics of the
x25ClearedCircuitIndexwas redefined. - Some of the description clauses were changed in an attempt to add clarity.
- DEFVAL clauses were added to most objects in the
x25CallParmTable. - Additional text was added to the description section to provide an overview of the tables of the MIB.
- The minimum allowable value for maximum active circuits was changed from one to zero.
February 1992
The February release (Editor's Internal Reference Number 1.14) made many changes.
- Many of the tables were combined. For example, the
x25InfoTable,x25PktStatTable, andx25TmrStatTablewere combined into thex25PleTable. Thex25ConInfoTable,x25ConStatTable, andx25ConTimrTablewere combined into thex25CircuitTable. - The objects for call parameters were drastically reworked. All call parameters were combined in the
x25CallParmTable. Any table, such as thex25PleTableorx25CircuitTable, that needs to reference call parameters identifies an entry in the new table. As part of this thex25ConDefTablewas deleted and replaced with thex25PleDefCallParamId. - The
x25PvcTablewas deleted; thex25CircuitStatusobject provides similar information about PVCs. - The
x25ClearedCircuitTablewas added to record the status code of cleared circuits. - Many object definitions were restructured. For example, the time units for timers was changed from 1/100ths of a second to milliseconds. Some indexes into tables were replaced with object identifiers.
- Much of the introductory text was changed and the references were changed to match.
October 1991
The October release (Editor Internal Reference Number 1.10) made the following changes:
- Changed
x25ConInfoStatusto clarify the description and thepvcResetting(5)value was changed topvcResetting(6)to avoid a conflict with a previous use of the number 5. - The name of the counter object
x25TmrStatRetryCountsExceededwas changed tox25TmrStatRetryCountExceededs. - The name of the counter object
x25TmrStatClearCountsExceededwas changed tox25TmrStatClearCountExceededs. - All occurrence of Guage was changed to Gauge.
- Added the
x25CallFcltyTable,x25CallFcltyCcittTable, andx25CallParamTable.
June 1991
The June release corrected some syntax errors and cleaned up some other minor things.
April 1991
The April 26 release of this document was the first release. That version was derived from the ISO work on network layer management as presented in ISO/IEC 10733 [11]
6. Acknowledgements 🫶🌈
this is the shoutout section and everyone in it earned it 💖
This document was produced by the x25mib working group:
- Fred Baker, ACC
- Art Berggreen, ACC
- Frank Bieser
- Gary Bjerke, Tandem
- Bill Bowman, HP
- Christopher Bucci, Datability
- Charles Carvalho, ACC
- Jeff Case, Snmp Research
- Angela Chen, HP
- Carson Cheung, BNR
- Tom Daniel, Spider Systems
- Chuck Davin, MIT
- Billy Durham, Honeywell
- Richard Fox, Synoptics
- Doug Geller, Data General
- Herve Goguely, LIR Corp
- Andy Goldthorpe, british-telecom
- Walter D. Guilarte
- David Gurevich
- Steve Huston, Process Software Corporation
- Jon Infante, ICL
- Frank Kastenholz, Clearpoint
- Zbigniew Kielczewski, Eicon
- Cheryl Krupezak, Georgia Tech
- Mats Lindstrom, Diab Data AB
- Andrew Malis, BBN
- Evan McGinnis, 3Com
- Gary (G.P.)Mussar, BNR
- Chandy Nilakantan, 3Com
- Randy Pafford, Data General
- Ragnar Paulson, The Software Group Limited
- Dave Perkins, Synoptics
- Walter Pinkarschewsky, DEC
- Karen Quidley, Data General
- Chris Ranch, Novell
- Paul S. Rarey, DHL Systems Inc.
- Jim Roche, Newbridge Research
- Philippe Roger, LIR Corp.
- Timon Sloane
- Mike Shand, DEC
- Brad Steina, Microcom
- Bob Stewart, Xyplex
- Tom Sullivan, Data General
- Rodney Thayer, Sable Technology Corporation
- Mark Therieau, Microcom
- Jane Thorn, Data General
- Dean Throop, Data General
- Maurice Turcotte, Racal Datacom
- Mike Zendels, Data General
In addition, the contributions of the following individuals are also acknowledged:
- John Harper, DEC
- Chairman of the ISO committee for Network Level Management Information
7. References ✨
Okay so bestie, this is the reading list at the back, and every single entry matters because the spec leans on them. Here we go 💅
- [1] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. 📚
- [2] McCloghrie K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1156, Hughes LAN Systems, Performance Systems International, May 1990. 🎀
- [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. 🦋
- [4] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. 🌸
- [5] Rose M., Editor, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Performance Systems International, March 1991. 💜
- [6] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. 🧚
- [7] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. 🍓
- [8] Stewart, B., Editor, "Definitions of Managed Objects for RS-232-like Hardware Devices", RFC 1317, Xyplex, Inc., April 1992. ✨
- [9] Throop, D., Editor, "SNMP MIB extension for LAPB", RFC 1381, Data General Corporation, November 1992. 🌈
- [10] "Information technology - - Data communication - X.25 Packet layer Protocol for Data Terminal Equipment", International Organization for Standardization, International Standard 8208, March 1990. 👑
- [11] "Information Technology - Telecommunications and information exchange between systems - Elements of Management Information Related to OSI network Layer Standards", Committee Draft International Standard 10733, November 1990. 🔥
8. Security Considerations 💀
Okay, this section is the dramatic one, so buckle up 😭 Security issues are not discussed in this memo. Not one word. So if you're looking for threat models in here, you're going to be sad, bestie 🙈
9. Authors' Addresses 🎀
Here's who wrote it, and how to reach them if you're feeling brave 🫶
Dean D. Throop Data General Corporation 62 Alexander Dr. Research Triangle Park, NC 27709
Phone: (919)248-8421 EMail: throop@dg-rtp.dg.com
📦 where this page comes from
- ietf: rfc1382 1992-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms