RFC 1461
SNMP MIB extension for Multiprotocol Interconnect over X.25
RFC 1461: SNMP MIB extension for Multiprotocol Interconnect over X.25 🎀
okay bestie, here's the title block tea ✨
- Group: Network Working Group 🌸
- RFC number: 1461 💅
- Author: D. Throop, Data General Corporation 💜
- Date: May 1993 📅
- Category: IAB standards track protocol 👑
- Obsoletes / Updates: the title block doesn't say it obsoletes or updates any other RFCs 🫶
Status of this Memo 📜
so this RFC is an IAB standards track protocol for the Internet community 🦋 and it's basically asking for discussion and suggestions for improvements 💬. for the official standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 👑. also, distribution of this memo is unlimited 🌈
Abstract 💜
this memo defines a chunk of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets 🧚. the main focus is managing Multiprotocol Interconnect (including IP) traffic carried over X.25 💅. the objects defined here, plus the objects in the "SNMP MIB extension for the Packet Layer of X.25"[8], "SNMP MIB extension for LAPB"[7], and the "Definitions of Managed Objects for RS-232-like Hardware Devices" [6], team up so you can manage the traffic over an X.25 protocol stack 🔥
Table of Contents 🗂️
Table of Contents
1. The Network Management Framework ......................... 1
2. Objects .................................................. 2
2.1 Format of Definitions ................................... 2
3. Overview ................................................. 3
3.1 Scope ................................................... 3
3.2 Structure of MIB objects ................................ 3
4. Definitions .............................................. 4
5. Acknowledgements ......................................... 19
6. References ............................................... 20
7. Security Considerations ................................... 21
8. Author's Address ......................................... 211. The Network Management Framework 🌈
okay so the Internet-standard Network Management Framework has three components 💅. these give the rules for defining objects, the definitions of objects, and the protocol for manipulating objects.
the framework structures objects in an abstract information tree ✨. the branches of the tree name objects, and the leaves hold the values that get manipulated to effect management. this tree is called the Management Information Base or MIB 🌸. the concepts of this tree are given in STD 16, RFC 1155, "The Structure of Management Information" or SMI [1]. the SMI defines the trunk of the tree and the types of objects used when defining the leaves. STD 16, RFC 1212, "Towards Concise MIB Definitions" [3], defines a more concise description mechanism that preserves all the principals of the SMI 🧁
the core MIB definitions for the Internet suite of protocols live in STD 17, RFC 1213 [4], "Management Information Base for Network Management of TCP/IP-based internets" 🦋
STD 15, RFC 1157 [2] defines the SNMP protocol itself. the protocol defines how to manipulate the objects in a remote MIB 💖
the tree structure of the MIB lets new objects be defined for the purpose of experimentation and evaluation 🧪
2. Objects 🎀
defining an object in the MIB requires an object name and type 💅. object names and types are defined using the subset of Abstract Syntax Notation One (ASN.1) [5] defined in the SMI [1]. objects are named using ASN.1 object identifiers, administratively assigned names, to specify object types. The object name, together with an optional object instance, uniquely identifies a specific instance of an object. for human convenience, we often use a textual string, termed the descriptor, to refer to objects 🫶
objects also have a syntax that defines the abstract data structure corresponding to that object type. the ASN.1 language [5] provides the primitives used for this purpose. the SMI [1] purposely restricts the ASN.1 constructs which may be used, for simplicity and ease of implementation 🙈
2.1. Format of Definitions 📋
Section 4 contains the specification of all object types contained in this MIB module. the object types are defined using the conventions defined in the SMI, as amended by the extensions specified in "Towards Concise MIB Definitions" [3].
3. Overview 🦋
3.1. Scope 🔭
instances of the objects defined below provide management information for Multiprotocol Interconnect traffic on X.25, as defined in RFC 1356 [9] 💜. that RFC describes how X.25 can be used to exchange IP or network level protocols. the multiprotocol packets (IP, CLNP, ES-IS, or SNAP) are encapsulated in X.25 frames for transmission between nodes. All nodes that implement RFC 1356 must implement this MIB 🧷
the objects in this MIB apply to the software in the node that manages X.25 connections and performs the protocol encapsulation. a node in this usage maybe the end node source or destination host for the packet, or it may be a router or bridge responsible for forwarding the packet. since RFC 1356 requires X.25, nodes that implement RFC 1356 must also implement the X.25 MIB, RFC 1382 ⭐
this MIB only applies to Multiprotocol Interconnect over X.25 service 🚨 it does not apply to other software that may also use X.25 (for example PAD). so the presence, absence, or operation of that software will not directly affect any of these objects. (however, connections in use by that software will appear in the X.25 MIB) 👀
3.2. Structure of MIB objects 🧩
the objects of this MIB are organized into three tables: the mioxPleTable, the mioxPeerTable, and the mioxPeerEncTable. All objects in all tables are mandatory for conformance with this MIB 💖
the mioxPleTable defines information relative to an interface used to carry Multiprotocol Interconnect traffic over X.25 🦋. such interfaces are identified by an ifType object in the Internet-standard MIB [4] of ddn-x25 or rfc877-x25. interfaces of type ddn-x25 have a self contained algorithm for translating between IP addresses and X.121 addresses. interfaces of type rfc877-x25 do not have such an algorithm. note that not all X.25 interfaces will be used to carry Multiprotocol Interconnect traffic. those interfaces not carrying such traffic will not have entries in the mioxPleTable. the entries in the mioxPleTable are only for interfaces that do carry Multiprotocol Interconnect traffic over X.25. entries in the mioxPleTable are indexed by ifIndex to make it easy to find the mioxPleTable entry for an interface 🔍
the mioxPeerTable contains information needed to contact an X.25 Peer to exchange packets 📞. this includes information such as the X.121 address of the peer and a pointer to the X.25 call parameters needed to place the call. the instance identifiers used for the objects in this table are independent of any interface or other tables defined outside this MIB. this table contains the ifIndex value of the X.25 interface to use to call a peer 🌷
the mioxPeerEncTable contains information about the encapsulation type used to communicate with a peer 🎁. this table is an extension of the mioxPeerTable in its instance identification. each entry in the mioxPeerTable may have zero or more entries in this table. this table will not have any entries that do not have correspondent entries in mioxPeerTable ✨
4. Definitions 🧩
ok the MIB code is up next, and it's giving very precise vibes 💅 every bit matters so I've kept it exactly as written 🙈
MIOX25-MIB DEFINITIONS ::= BEGIN
IMPORTS
Counter,
TimeTicks
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC-1212
DisplayString, transmission,
ifIndex
FROM RFC1213-MIB
InstancePointer
FROM RFC1316-MIB
X121Address
FROM RFC1382-MIB
PositiveInteger
FROM RFC1381-MIB;
-- IP over X.25 MIB
miox OBJECT IDENTIFIER ::= { transmission 38 }
mioxPle OBJECT IDENTIFIER ::= { miox 1 }
mioxPeer OBJECT IDENTIFIER ::= { miox 2 }
-- ###########################################################
-- Ple Table
-- ###########################################################
-- Systems that implement RFC 1356 must also implement
-- all objects in this group.
mioxPleTable OBJECT-TYPE
SYNTAX SEQUENCE OF MioxPleEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This table contains information relative to
an interface to an X.25 Packet Level Entity
(PLE)."
::= { mioxPle 1 }
mioxPleEntry OBJECT-TYPE
SYNTAX MioxPleEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"These objects manage the encapsulation of
other protocols within X.25."
INDEX { ifIndex }
::= { mioxPleTable 1 }
MioxPleEntry ::= SEQUENCE {
mioxPleMaxCircuits
INTEGER,
mioxPleRefusedConnections
Counter,
mioxPleEnAddrToX121LkupFlrs
Counter,
mioxPleLastFailedEnAddr
OCTET STRING,
mioxPleEnAddrToX121LkupFlrTime
TimeTicks,
mioxPleX121ToEnAddrLkupFlrs
Counter,
mioxPleLastFailedX121Address
X121Address,
mioxPleX121ToEnAddrLkupFlrTime
TimeTicks,
mioxPleQbitFailures
Counter,
mioxPleQbitFailureRemoteAddress
X121Address,
mioxPleQbitFailureTime
TimeTicks,
mioxPleMinimumOpenTimer
PositiveInteger,
mioxPleInactivityTimer
PositiveInteger,
mioxPleHoldDownTimer
PositiveInteger,
mioxPleCollisionRetryTimer
PositiveInteger,
mioxPleDefaultPeerId
InstancePointer
}
mioxPleMaxCircuits OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The maximum number of X.25 circuits that
can be open at one time for this interface.
A value of zero indicates the interface will
not allow any additional circuits (as it may
soon be shutdown). A value of 2147483647
allows an unlimited number of circuits."
::= { mioxPleEntry 1 }part 2 picks up right after mioxPleMaxCircuits 🎀
Okay so the next counter is mioxPleRefusedConnections 🙈 It counts every X.25 call a remote system tries to make to this box that gets cleared, and the interface instance is supposed to say which X.25 interface the call came in on ✨
mioxPleRefusedConnections OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of X.25 calls from a remote
systems to this system that were cleared by
this system. The interface instance should
identify the X.25 interface the call came in
on."
::= { mioxPleEntry 2 }Now the lookup failure counters, which are very important bestie 💅 mioxPleEnAddrToX121LkupFlrs goes up when an Encapsulated Address can't be translated into an X.121 address. Addresses that get recognized don't count, but the weird ones that show up mean something went wrong with delivery 😭 There's also a fun little rule for when it's unclear which PLE should take the blame: pick the first likely entry in the table, and record the failure anyway even if you're not sure 🫶
mioxPleEnAddrToX121LkupFlrs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times a translation from an
Encapsulated Address to an X.121 address
failed to find a corresponding X.121
address. Encapsulated addresses can be
looked up in the mioxPeerTable or translated
via an algorithm as for the DDN. Addresses
that are successfully recognized do not
increment this counter. Addresses that are
not recognized (reflecting an abnormal
packet delivery condition) increment this
counter.
If an address translation fails, it may be
difficult to determine which PLE entry
should count the failure. In such cases the
first likely entry in this table should be
selected. Agents should record the failure
even if they are unsure which PLE should be
associated with the failure."
::= { mioxPleEntry 3 }mioxPleLastFailedEnAddr is the receipt for the most recent failure 🧾 It's an OCTET STRING, where the first octet is the encapsulation type and the rest is the address of that type. The examples are very aesthetic: an IP address is five octets with 204 (hex CC) first, and a snap encapsulation starts with 128 (hex 80) followed by the snap header 🦋
mioxPleLastFailedEnAddr OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(2..128))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The last Encapsulated address that failed
to find a corresponding X.121 address and
caused mioxPleEnAddrToX121LkupFlrs to be
incremented. The first octet of this object
contains the encapsulation type, the
remaining octets contain the address of that
type that failed. Thus for an IP address,
the length will be five octets, the first
octet will contain 204 (hex CC), and the
last four octets will contain the IP
address. For a snap encapsulation, the
first byte would be 128 (hex 80) and the
rest of the octet string would have the snap
header."
::= { mioxPleEntry 4 }mioxPleEnAddrToX121LkupFlrTime is the timestamp for that same failure, measured in sysUpTime, so you know exactly when the most recent translation fell over 🕰️
mioxPleEnAddrToX121LkupFlrTime OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The most recent value of sysUpTime when the
translation from an Encapsulated Address to
X.121 address failed to find a corresponding
X.121 address."
::= { mioxPleEntry 5 }
The reverse direction gets its own set of counters 🔁 mioxPleX121ToEnAddrLkupFlrs counts the times an X.121 address couldn't be matched to an Encapsulated Address during call acceptance. Basically, it's the moment the box met a peer it didn't recognize, and that's an abnormal situation, so it's the one to watch 👀
mioxPleX121ToEnAddrLkupFlrs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times the translation from an
X.121 address to an Encapsulated Address
failed to find a corresponding Encapsulated
Address. Addresses successfully recognized
by an algorithm do not increment this
counter. This counter reflects the number
of times call acceptance encountered the
abnormal condition of not recognizing the
peer."
::= { mioxPleEntry 6 }mioxPleLastFailedX121Address holds the last X.121 address that bumped that counter 📮 It's giving "here's the suspect" 🕵️♀️
mioxPleLastFailedX121Address OBJECT-TYPE
SYNTAX X121Address
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The last X.121 address that caused
mioxPleX121ToEnAddrLkupFlrs to increase."
::= { mioxPleEntry 7 }mioxPleX121ToEnAddrLkupFlrTime is the sysUpTime snapshot for the most recent reverse lookup failure ⏱️
mioxPleX121ToEnAddrLkupFlrTime OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The most recent value of sysUpTime when the
translation from an X.121 address to an
Encapsulated Address failed to find a
corresponding Encapsulated Address."
::= { mioxPleEntry 8 }Now the Q-bit drama 🌸 mioxPleQbitFailures counts connections that got closed because of a Q-bit failure. Nobody wants to be on this list, periodt 💀
mioxPleQbitFailures OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times a connection was closed
because of a Q-bit failure."
::= { mioxPleEntry 9 }mioxPleQbitFailureRemoteAddress tells you the remote address of the most recent connection that got closed for that reason 🫣
mioxPleQbitFailureRemoteAddress OBJECT-TYPE
SYNTAX X121Address
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The remote address of the most recent
(last) connection that was closed because of
a Q-bit failure."
::= { mioxPleEntry 10 }mioxPleQbitFailureTime is the sysUpTime for that last Q-bit closure. The description also says it's the same moment that mioxPleQbitFailures was last incremented, so the two counters are in sync 🧠
mioxPleQbitFailureTime OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The most recent value of sysUpTime when a
connection was closed because of a Q-bit
failure. This will also be the last time
that mioxPleQbitFailures was incremented."
::= { mioxPleEntry 11 }Wait, I need to correct something in that last block: the original has ACCESS read-only for mioxPleQbitFailureTime, so the block above is wrong. Here is the corrected version, which I'll use in place of the one above:
mioxPleQbitFailureTime OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The most recent value of sysUpTime when a
connection was closed because of a Q-bit
failure. This will also be the last time
that mioxPleQbitFailures was incremented."
::= { mioxPleEntry 11 }The timers are next, and these are the read-write ones so you can actually tune things ⏲️ mioxPleMinimumOpenTimer sets how many milliseconds the interface keeps a connection open before it's allowed to close. Zero means no timer, and that's the default 🎀
mioxPleMinimumOpenTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The minimum time in milliseconds this
interface will keep a connection open before
allowing it to be closed. A value of zero
indicates no timer."
DEFVAL { 0 }
::= { mioxPleEntry 12 }mioxPleInactivityTimer is for idle connections. It's the time in milliseconds the interface keeps an idle connection open before closing it. The default is 10000, and 2147483647 means no timer at all 🍓
mioxPleInactivityTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The amount of time time in milliseconds
this interface will keep an idle connection
open before closing it. A value of
2147483647 indicates no timer."
DEFVAL { 10000 }
::= { mioxPleEntry 13 }mioxPleHoldDownTimer is the minimum wait before trying another call to a host that didn't work out last time 🙅♀️ A value of 2147483647 means that host never gets retried, which is harsh but valid 💅
mioxPleHoldDownTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The hold down timer in milliseconds. This
is the minimum amount of time to wait before
trying another call to a host that was
previously unsuccessful. A value of
2147483647 indicates the host will not be
retried."
DEFVAL { 0 }
::= { mioxPleEntry 14 }mioxPleCollisionRetryTimer handles the delay between call attempts when the maximum number of circuits gets exceeded during a call attempt 🚦
mioxPleCollisionRetryTimer OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Collision Retry Timer in milliseconds.
The time to delay between call attempts when
the maximum number of circuits is exceeded
in a call attempt."
DEFVAL { 0 }
::= { mioxPleEntry 15 }Last object in the PLE table 🧚 mioxPleDefaultPeerId is an InstancePointer that points at the mioxPeerTable entry holding the default parameters. Those defaults get used for hosts that aren't in the peer table, like with ddn-x25 IP-X.25 address mapping or when accepting connections from unknown hosts 👑 The matching mioxPeerEncTable entry says which encapsulation types this PLE will accept from those unknown peers, and if that table is empty, the PLE won't accept calls from anyone outside the peer table. Very strict, very iconic 😤
mioxPleDefaultPeerId OBJECT-TYPE
SYNTAX InstancePointer
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This identifies the instance of the index
in the mioxPeerTable for the default
parameters to use with this interface.
The entry identified by this object may have
a zero length Encapsulation address and a
zero length X.121 address.
These default parameters are used with
connections to hosts that do not have
entries in the mioxPeerTable. Such
connections occur when using ddn-x25 IP-X.25
address mapping or when accepting
connections from other hosts not in the
mioxPeerTable.
The mioxPeerEncTable entry with the same
index as the mioxPeerTable entry specifies
the call encapsulation types this PLE will
accept for peers not in the mioxPeerTable.
If the mioxPeerEncTable doesn't contain any
entries, this PLE will not accept calls from
entries not in the mioxPeerTable."
::= { mioxPleEntry 16 }Now the Peer Table section 🫶 The comment block right above the table has an important note about RFC 1356, so read it carefully before you go implementing anything 📖
-- ###########################################################
-- Peer Table
-- ###########################################################
-- Systems that implement RFC 1356 must also implement
-- all objects in this group.
mioxPeerTable OBJECT-TYPE
SYNTAX SEQUENCE OF MioxPeerEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This table contains information about the
possible peers this machine may exchange
packets with."
::= { mioxPeer 1 }
mioxPeerEntry OBJECT-TYPE
SYNTAX MioxPeerEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Per peer information."
INDEX { mioxPeerIndex }
::= { mioxPeerTable 1 }Okay so this is the peer table row, bestie 🎀 every column of one MIB entry, lined up in one little SEQUENCE 💅
MioxPeerEntry ::= SEQUENCE {
mioxPeerIndex
PositiveInteger,
mioxPeerStatus
INTEGER,
mioxPeerMaxCircuits
PositiveInteger,
mioxPeerIfIndex
PositiveInteger,
mioxPeerConnectSeconds
Counter,
mioxPeerX25CallParamId
InstancePointer,
mioxPeerEnAddr
OCTET STRING,
mioxPeerX121Address
X121Address,
mioxPeerX25CircuitId
InstancePointer,
mioxPeerDescr
DisplayString
}Now the mioxPeerIndex 🦋 it's the row ID, basically. It's a read-only PositiveInteger, and it has to tell one entry apart from another, totally independent of any other index in the table ✨
mioxPeerIndex OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An index value that distinguished one entry
from another. This index is independent of
any other index."
::= { mioxPeerEntry 1 }Okay the mioxPeerStatus one is the MAIN CHARACTER 👑 it's read-write, and it tells you what state a peer entry is in. Before the object itself, the RFC leaves a little note in the comments about which set values a system can skip. Lowkey iconic, because it says all the other values have to be accepted, and implementers are encouraged to accept them anyway for richer management 🌸
-- Systems can claim conformance with this MIB without
-- implementing sets to mioxPeerStatus with a value of
-- clearCall or makeCall.
-- All other defined values must be accepted.
-- Implementors should realize that allowing these values
-- provides richer management, and implementations
-- are encouraged to accept these values.
mioxPeerStatus OBJECT-TYPE
SYNTAX INTEGER {
valid (1),
createRequest (2),
underCreation (3),
invalid (4),
clearCall (5),
makeCall (6)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This reports the status of a peer entry.
A value of valid indicates a normal entry
that is in use by the agent. A value of
underCreation indicates a newly created
entry which isn't yet in use because the
creating management station is still setting
values.
The value of invalid indicates the entry is
no longer in use and the agent is free to
delete the entry at any time. A management
station is also free to use an entry in the
invalid state.
Entries are created by setting a value of
createRequest. Only non-existent or invalid
entries can be set to createRequest. Upon
receiving a valid createRequest, the agent
will create an entry in the underCreation
state. This object can not be set to a
value of underCreation directly, entries can
only be created by setting a value of
createRequest. Entries that exist in other
than the invalid state can not be set to
createRequest.
Entries with a value of underCreation are
not used by the system and the management
station can change the values of other
objects in the table entry. Management
stations should also remember to configure
values in the mioxPeerEncTable with the same
peer index value as this peer entry.
An entry in the underCreation state can be
set to valid or invalid. Entries in the
underCreation state will stay in that state
until 1) the agent times them out, 2) they
are set to valid, 3) they are set to
invalid. If an agent notices an entry has
been in the underCreation state for an
abnormally long time, it may decide the
management station has failed and invalidate
the entry. A prudent agent will understand
that the management station may need to wait
for human input and will allow for that
possibility in its determination of this
abnormally long period.
Once a management station has completed all
fields of an entry, it will set a value of
valid. This causes the entry to be
activated.
Entries in the valid state may also be set
to makeCall or clearCall to make or clear
X.25 calls to the peer. After such a set
request the entry will still be in the valid
state. Setting a value of makeCall causes
the agent to initiate an X.25 call request
to the peer specified by the entry. Setting
a value of clearCall causes the agent to
initiate clearing one X.25 call present to
the peer. Each set request will initiate
another call or clear request (up to the
maximum allowed); this means that management
stations that fail to get a response to a
set request should query to see if a call
was in fact placed or cleared before
retrying the request. Entries not in the
valid state can not be set to makeCall or
clearCall.
The values of makeCall and clearCall provide
for circuit control on devices which perform
Ethernet Bridging using static circuit
assignment without address recognition;
other devices which dynamically place calls
based on destination addresses may reject
such requests.
An agent that (re)creates a new entry
because of a set with createRequest, should
also (re)create a mioxPeerEncTable entry
with a mioxPeerEncIndex of 1, and a
mioxPeerEncType of 204 (hex CC)."
::= { mioxPeerEntry 2 }The spicy bit is the lifecycle 💖 so basically the status is the vibe check of the entry. valid means it's in use by the agent. underCreation means it's brand new and not active yet, since the manager is still filling in values. invalid means it's done, and the agent can delete it whenever it wants (the manager can use it too). You make a new entry by setting createRequest, and only a non-existent or invalid entry can take that. Once the agent gets a valid createRequest, it makes the entry in underCreation, and you can't just set underCreation yourself 🙈 Then you can flip it to valid or invalid. If it sits in underCreation for a really long time, the agent might decide the manager has ghosted it and invalidate it, but a prudent agent gives room for humans who need time 🧚
Also remember to set up the matching mioxPeerEncTable values with the same peer index, periodt 🫶
For makeCall and clearCall, these are the "make a phone call" and "hang up" buttons for X.25 circuits 📞 They only work on valid entries, and the entry stays valid afterwards. Each set sends another call or clear (up to the max), so if you don't get a reply, query first to see if it actually happened before you retry, otherwise you could double up 😭 The RFC says these values are for devices that do Ethernet bridging with static circuit assignment and no address recognition. Devices that place calls based on destination addresses are allowed to reject them 🍓
And if an agent makes a new entry from a createRequest, it should also make a mioxPeerEncTable entry with mioxPeerEncIndex 1 and mioxPeerEncType 204 (hex CC) ✨
mioxPeerMaxCircuits is how many X.25 circuits this peer is allowed, read-write, default 1 💅
mioxPeerMaxCircuits OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The maximum number of X.25 circuits allowed
to this peer."
DEFVAL { 1 }
::= { mioxPeerEntry 3 }mioxPeerIfIndex is the ifIndex of the interface X.25 uses to call the peer, also read-write with a default of 1 🌈
mioxPeerIfIndex OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The value of the ifIndex object for the
interface to X.25 to use to call the peer."
DEFVAL { 1 }
::= { mioxPeerEntry 4 }mioxPeerConnectSeconds is the read-only counter that tracks how long calls to this peer were active ⭐ It goes up by one every second a connection is open. If two calls are open at the same time, one real second counts as two seconds of connect time, so yes, it's doubling up 💀
mioxPeerConnectSeconds OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of seconds a call to this peer
was active. This counter will be
incremented by one for every second a
connection to a peer was open. If two calls
are open at the same time, one second of
elapsed real time will results in two
seconds of connect time."
::= { mioxPeerEntry 5 }mioxPeerX25CallParamId points at the X.25 call parameters for talking to the remote host. It's read-write and it's an instance of the index in the x25CallParmTable from RFC 1382. The well-known value {0 0} just means no call parameters are specified 🦋
mioxPeerX25CallParamId OBJECT-TYPE
SYNTAX InstancePointer
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The instance of the index object in the
x25CallParmTable from RFC 1382 for the X.25
call parameters used to communicate with the
remote host. The well known value {0 0}
indicates no call parameters specified."
DEFVAL { {0 0} }
::= { mioxPeerEntry 6 }mioxPeerEnAddr is the encapsulation address of the remote host for this entry, and it's read-write, up to 128 octets 🧚 A length of zero means the remote IP address is unknown or unspecified, which lets it act as a PLE default.
The first octet is the encapsulation type, and the rest is an address of that type. So for IP, the length is five octets: the first is 204 (hex CC), and the last four are the IP address. For SNAP, the first byte is 128 (hex 80), and the rest is the SNAP header 🌸
mioxPeerEnAddr OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..128))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Encapsulation address of the remote
host mapped by this table entry. A length
of zero indicates the remote IP address is
unknown or unspecified for use as a PLE
default.
The first octet of this object contains the
encapsulation type, the remaining octets
contain an address of that type. Thus for
an IP address, the length will be five
octets, the first octet will contain 204
(hex CC), and the last four octets will
contain the IP address. For a snap
encapsulation, the first byte would be 128
(hex 80) and the rest of the octet string
would have the snap header."
DEFVAL { ''h }
::= { mioxPeerEntry 7 }Last one for this part: mioxPeerX121Address is the X.25 address of the remote host, read-write 📮 A zero-length string means the X.25 address is unspecified and can serve as the PLE default ✨
mioxPeerX121Address OBJECT-TYPE
SYNTAX X121Address
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The X.25 address of the remote host mapped
by this table entry. A zero length string
indicates the X.25 address is unspecified
for use as the PLE default."
DEFVAL { ''h }
::= { mioxPeerEntry 8 } -- Systems can claim conformance to this MIB without
-- implementing sets to mioxPeerX25CircuitId.
-- However systems that use PVCs with RFC1356
-- are encouraged to implement sets.
mioxPeerX25CircuitId OBJECT-TYPE
SYNTAX InstancePointer
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This object identifies the instance of the
index for the X.25 circuit open to the peer
mapped by this table entry. The well known
value {0 0} indicates no connection
currently active. For multiple connections,
this identifies the index of a multiplexing
table entry for the connections. This can
only be written to configure use of PVCs
which means the identified circuit table
entry for a write must be a PVC."
DEFVAL { {0 0} }
::= { mioxPeerEntry 9 }
mioxPeerDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"This object returns any identification
information about the peer. An agent may
supply the comment information found in the
configuration file entry for this peer. A
zero length string indicates no information
available."
DEFVAL { ''h }
::= { mioxPeerEntry 10 }
-- ###########################################################
-- Peer Encapsulation Table
-- ###########################################################
mioxPeerEncTable OBJECT-TYPE
SYNTAX SEQUENCE OF MioxPeerEncEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This table contains the list of
encapsulations used to communicate with a
peer. This table has two indexes, the first
identifies the peer, the second
distinguishes encapsulation types.
The first index identifies the corresponding
entry in the mioxPeerTable. The second
index gives the priority of the different
encapsulations.
The encapsulation types are ordered in
priority order. For calling a peer, the
first entry (mioxPeerEncIndex of 1) is tried
first. If the call doesn't succeed because
the remote host clears the call due to
incompatible call user data, the next entry
in the list is tried. Each entry is tried
until the list is exhausted.
For answering a call, the encapsulation type
requested by the peer must be found the list
or the call will be refused. If there are
no entries in this table for a peer, all
call requests from the peer will be refused.
Objects in this table can only be set when
the mioxPeerStatus object with the same
index has a value of underCreation. When
that status object is set to invalid and
deleted, the entry in this table with that
peer index must also be deleted."
::= { mioxPeer 2 }
mioxPeerEncEntry OBJECT-TYPE
SYNTAX MioxPeerEncEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Per connection information."
INDEX { mioxPeerIndex, mioxPeerEncIndex}
::= { mioxPeerEncTable 1 }
MioxPeerEncEntry ::= SEQUENCE {
mioxPeerEncIndex
PositiveInteger,
mioxPeerEncType
INTEGER
}
mioxPeerEncIndex OBJECT-TYPE
SYNTAX PositiveInteger
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The second index in the table which
distinguishes different encapsulation
types."
::= { mioxPeerEncEntry 1 }
mioxPeerEncType OBJECT-TYPE
SYNTAX INTEGER (0..256)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The value of the encapsulation type. For
IP encapsulation this will have a value of
204 (hex CC). For SNAP encapsulated
packets, this will have a value of 128 (hex
80). For CLNP, ISO 8473, this will have a
value of 129 (hex 81). For ES-ES, ISO 9542,
this will have a value of 130 (hex 82). A
value of 197 (hex C5) identifies the Blacker
X.25 encapsulation. A value of 0,
identifies the Null encapsulation.
This value can only be written when the
mioxPeerStatus object with the same
mioxPeerIndex has a value of underCreation.
Setting this object to a value of 256
deletes the entry. When deleting an entry,
all other entries in the mioxPeerEncTable
with the same mioxPeerIndex and with an
mioxPeerEncIndex higher then the deleted
entry, will all have their mioxPeerEncIndex
values decremented by one."
::= { mioxPeerEncEntry 2 }
-- ###########################################################
ENDokay so the peer table is still going and it gets a little more involved 💅 The mioxPeerX25CircuitId object points at the X.25 circuit that's open to the peer, and {0 0} is the vibe for "nothing is connected right now" 🫥. If you have multiple connections, it points at an index into a multiplexing table. You can only write to it to set up PVCs, so the circuit entry you're writing to has to be a PVC 🎀. You can claim conformance without implementing sets, but if you're using PVCs with RFC1356, they're encouraged to implement sets ✨.
mioxPeerDescr is basically the peer's name tag 🏷️. An agent can copy in the comment from the config file for that peer, and a zero length string just means there's no info to show 🌸.
5. Acknowledgements 🫶
This document was produced by the x25mib working group, and the whole squad deserves a flower crown 🌸🌷
- Fred Baker, ACC
- Art Berggreen, ACC
- Frank Bieser
- Gary Bjerke, Tandem
- Bill Bowman, HP
- Christopher Bucci, Datability
- Charles Carvalho, ACC
- Jeff Case, University of Tennessee at Knoxville
- 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, Consultant
- Jon Infante, ICL
- Frank Kastenholz, FTP Software
- 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
6. References 📚
[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] 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.
[3] Rose, M. and K. McCloghrie, Editors, "Towards Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991.
[4] Rose M., Editor, "Management Information Base for Network Management of TCP/IP-based internets", STD 17, RFC 1213. Performance Systems International, March 1991.
[5] "Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization. International Standard 8824, December, 1987.
[6] Stewart, B., Editor, "Definitions of Managed Objects for RS-232-like Hardware Devices", RFC 1317, Xyplex, Inc., April 1992.
[7] Throop, D., and F. Baker, "SNMP MIB extension for X.25 LAPB", RFC 1381, Data General Corporation, Advanced Computer Communications, November 1992.
[8] Throop, D., Editor, "SNMP MIB extension for the X.25 Packet Layer", RFC 1382, Data General Corporation, November 1991.
[9] Malis, A., Robinson, D., and R. Ullmann "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356, BBN Communications, Computervision Systems Integration, Process Software Corporation, August 1992.
7. Security Considerations 💀
Security issues are not discussed in this memo. Yikes, bestie, this one's a plot hole we're leaving for another day 😭
8. Author's Address 💌
Dean D. Throop
Data General Corporation
62 Alexander Dr.
Research Triangle Park, NC 27709
Phone: (919) 248-6081
EMail: throop@dg-rtp.dg.com📦 where this page comes from
- ietf: rfc1461 1993-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms