RFC 1028
Simple Gateway Monitoring Protocol
RFC 1028: A Simple Gateway Monitoring Protocol 🎀
Okay bestie, this is RFC 1028, dated November 1987, and it's all about A Simple Gateway Monitoring Protocol 🦋. Four authors wrote it: J. Davin from Proteon, Inc., J. Case from the University of Tennessee at Knoxville, M. Fedor from Cornell University, and M. Schoffstall from Rensselaer Polytechnic Institute. The header doesn't list a category, and it doesn't say this one obsoletes or updates anything, so I'm not making that up 🙈.
1. Status of this Memo ✨
This document is going out to the Internet community so people can react to the proposals in it 💬. The issues might not be directly relevant to the Internet's research problems, but plenty of researchers and implementors could still find them interesting 👀.
It defines a simple application-layer protocol that lets logically remote users look at or change a gateway's management information 🧚.
This is only meant as an interim fix for urgent gateway monitoring needs 🌸. Meanwhile, the fancier and sturdier designs get the careful thought they deserve. So if better proposals show up later, long-term use of these mechanisms should be seriously questioned 💅. Distribution of this memo is unlimited.
2. Protocol Design Strategy 💜
The big idea is to keep the number and complexity of management functions that the gateway itself has to run as small as possible 🍓. That's attractive for at least four reasons:
- Building the gateway software needed to support the protocol costs less, accordingly.
- More management functions can be supported remotely, so you get the fullest use of internet resources for management 🌐.
- More management functions can be supported remotely, so management tools face the fewest possible restrictions on their form and sophistication 🔥.
- A simpler set of management functions is easy for developers of gateway management tools to understand and use 🫶.
Design goal number two: the functional paradigm for monitoring and control has to be extensible enough to handle extra aspects of gateway operation, even ones nobody saw coming 🔮.
Design goal number three: the design should be as independent as possible from the architecture and mechanisms of particular hosts or particular gateways 🧩.
Now for the decisions that follow from all that. 💖
Decision one is to treat every gateway management function as either altering or inspecting parameter values 🎛️. A protocol entity on a logically remote host (which could be the gateway itself) talks to a protocol entity on the gateway to change or fetch named portions of the gateway state, called variables. This has two good consequences:
- The gateway only has to realize two essential management functions: one to assign a value to a specified configuration parameter, and one to retrieve that value. Very minimal, very iconic 👑.
- Imperative management commands stay out of the protocol definition 🙅♀️. Their number keeps growing in practice, and their semantics can be arbitrarily complex, so no thank you.
Leaving imperative commands out probably doesn't block any useful gateway operation. Most gateway commands are either setting a parameter or retrieving one, and the few imperative commands that exist can be handled asynchronously in this model 🦄. An imperative command could just be a parameter setting that later triggers the desired action.
Decision two is to handle any needed authentication in a separate protocol layer that serves the monitoring protocol 🔐. The biggest win here is that each protocol layer gets less complicated, which makes implementation way easier 💅.
Decision three follows the layered approach: a peer only knows the identity of an application protocol entity through the underlying authentication protocol 🪪. Access control is then managed through the link between application entities and authentication protocol sessions. So multi-level access to gateway variables works through multiple instances of the application protocol entity, and each instance is characterized by:
- the set of gateway variables known to that entity,
- the mode of access (
READ-ONLYorREAD-WRITE) given to that set of variables, and - the authentication protocol session that the messages sent and received by that entity belong to.
Decision four is to use the CCITT X.409 recommendation [1] conventions for representing the information exchanged between protocol entities 📚. The cost is a modest bump in implementation complexity. The payoff is that protocol data ends up on the network in a machine-independent form that's widely understood and widely accepted 🌈. There's a bonus too: the form of the protocol messages can be described concisely and clearly in the X.409 language.
Decision five, which also keeps the gateway simple, is that the variables only ever take integer or octet string values 🔢.
Decision six, again for gateway simplicity, is that the exchange of protocol messages only needs an unreliable datagram transport 📮. Every protocol message also has to fit entirely and independently inside a single transport datagram. This document specifies exchanging messages over UDP [2], but the design works with a wide variety of transport mechanisms too 🧚♀️.
Decision seven is about naming. Variables are named by octet string values 🏷️. That breaks from the Internet's usual tradition of identifying objects with assigned integer values, but octet string names come with at least two big perks. Since the set of octet string values is a name space that can be flat or hierarchical as needed:
- a single simple mechanism gives you both random access to individual variables and sequential access to semantically related groups of variables, and
- the name space can grow to cover unforeseen needs without messing up the relationships among existing variables or the room for future extensions 🌸.
Decision eight is to keep unsolicited messages to a minimum 🤫. This fits the simplicity goal, and it comes from wanting maximal control over how much traffic the network management function creates, even if that means extra protocol overhead. The plan is that monitoring network state at any meaningful level of detail happens mainly through polling by the monitoring center 📡. Unsolicited messages are limited to the ones strictly needed to help the monitoring center decide when and what to poll 🎯.
3. The Gateway Monitoring Protocol 🌈
The gateway monitoring protocol is an application protocol that lets you inspect or change the variables in a gateway's configuration 🛠️.
Application protocol entities talk by exchanging protocol messages through the services of the authentication protocol described elsewhere in this document 🔁. Each protocol message is entirely and independently represented by a single message of the underlying authentication protocol. An implementation need not accept protocol messages longer than 484 octets 📏.
There are four message types that a protocol entity recognizes, and their form and function get explained next 💖. A message's type is shown by the value of the implicit type tag for the data structure it represents, following the CCITT X.409 conventions ✨.
3.1. The Get Request Message Type 💖
Okay so, the Get Request is the message that asks for stuff 🎀 Its form is written in CCITT X.409 notation, which is giving very old-school vibes 💀 Here's the whole thing:
var_value_type ::= CHOICE {
INTEGER,
OCTET STRING
}
var_name_type := OCTET STRING
var_op_type ::= SEQUENCE {
var_name var_name_type,
var_value var_value_type
}
var_op_list_type ::= SEQUENCE OF var_op_type
error_status_type ::= INTEGER {
gmp_err_noerror (0),
gmp_err_too_big (1),
gmp_err_nix_name (2),
gmp_err_bad_value (3)
}
error_index_type ::= INTEGER
request_id_type ::= INTEGER
get_req_message_type ::= [ APPLICATION 1 ] IMPLICIT
SEQUENCE {
request_id request_id_type,
error_status error_status_type,
error_index error_index_type,
var_op_list var_op_list_type
}Once a receiver gets one of these, it checks the list below and responds according to whichever rule applies 👀
- If, for some var_op_type component of the received message, the value of the var_name field does not lexicographically precede the name of some variable known to the receiving entity, then the receiving entity sends to the originator of the received message a message of identical form except that the indicated message type is Get Response, the value of the error_status field is gmp_err_nix_name, and the value of the error_index field is the unit-based index of said var_op_type component in the received message.
- If the size of the Get Response type message generated as described below would exceed the size of the largest message for which the protocol definition requires acceptance, then the receiving entity sends to the originator of the received message a message of identical form except that the indicated message type is Get Response, the value of the error_status field is gmp_err_too_big, and the value of the error_index field is zero.
If none of the foregoing rules apply, the receiver sends back a Get Response type message 🦋 For each var_op_type component of the received message, the matching component of the reply holds the name and value of the variable that comes right after the requested name in the lexicographical ordering of all variables the receiver knows about, together with the value of that component's var_name field. The reply's error_status is gmp_err_noerror and its error_index is zero. The request_id is copied over from the received message, so everything lines up 🧚
Get Request messages only get generated by a protocol entity when the application user asks for them ✨
3.2. The Get Response Message Type 🌸
The Get Response is basically the same shape as the Get Request, just with a different message type tag. In X.409 it looks like this:
get_rsp_message_type ::= [ APPLICATION 2 ] IMPLICIT
SEQUENCE {
request_id request_id_type,
error_status error_status_type,
error_index error_index_type,
var_op_list var_op_list_type
}When a protocol entity gets one of these, it just shows the contents to the application user 💅
Get Response messages only get generated by a protocol entity after it receives a Set Request or Get Request type message, as described elsewhere in this document 🫶
3.3. The Trap Request Message Type 🚨
Trap Requests are described in X.409 too 🙈 Here's the grammar:
val_list_type ::= SEQUENCE OF var_value_type
trap_type_type ::= INTEGER
trap_req_message_type ::= [ APPLICATION 3 ] IMPLICIT
SEQUENCE {
trap_type trap_type_type,
val_list val_list_type
}Same deal as before: a protocol entity presents the contents to the application user when it gets one of these 💜
Trap Request messages only get generated by a protocol entity when the application user asks for one ✨
The meaning of the val_list component in a Trap Request is implementation-specific, so it's up to whoever builds the thing 🌈
Negative trap_type values are also implementation-specific. Non-negative trap_type values have defined meanings, and they're listed in the subsections below 🍓
3.3.1. The Cold Start Trap Type ❄️
A Trap Request with a trap_type field of 0 means the sender is reinitializing itself, and the gateway configuration or the protocol entity implementation might get changed in the process 🧊
3.3.2. The Warm Start Trap Type 🌤️
A Trap Request with a trap_type field of 1 means the sender is reinitializing itself, but neither the gateway configuration nor the protocol entity implementation gets changed 🌷
3.3.3. The Link Failure Trap Type 🔗
A Trap Request with a trap_type field of 2 means the sender has noticed that one of the communication links in the gateway configuration has failed 💥
3.3.4. The Authentication Failure Trap Type 🔐
A Trap Request with a trap_type field of 3 means the sender is the addressee of a protocol message that didn't pass authentication properly 🙅♀️
3.3.5. The EGP Neighbor Loss Trap Type 📡
A Trap Request with a trap_type field of 4 means an EGP neighbor, one the sender was an EGP peer for, has been marked down, and the peer relationship doesn't hold anymore 😭
3.4. The Set Request Message Type 🎀
Set Requests look just like Get Requests, except for the message type tag. In X.409:
set_req_message_type ::= [ APPLICATION 4 ] IMPLICIT
SEQUENCE {
request_id request_id_type,
error_status error_status_type,
error_index error_index_type,
var_op_list var_op_list_type
}When one of these arrives, the receiver checks the rules below and responds according to whichever one applies ✍️
- If, for some var_op_type component of the received message, the value of the var_name field names no variable known to the receiving entity, then the receiving entity sends to the originator of the received message a message of identical form except that the indicated message type is Get Response, the value of the error_status field is gmp_err_nix_name, and the value of the error_index field is the unit-based index of said var_op_type component in the received message.
- If, for some var_op_type component of the received message, the contents of the var_value field does not, according to the CCITT X.409 recommendation, manifest a type, length, and value that is consistent with that required for the variable named by the value of the var_name field, then the receiving entity sends to the originator of the received message a message of identical form except that the indicated message type is Get Response, the value of the error_status field is gmp_err_bad_value, and the value of the error_index field is the unit-based index of said var_op_type component in the received message.
- If the size of the Get Response type message generated as described below would exceed the size of the largest message for which the protocol definition requires acceptance, then the receiving entity sends to the originator of the received message a message of identical form except that the indicated message type is Get Response, the value of the error_status field is gmp_err_too_big, and the value of the error_index field is zero.
If none of those apply, then for each var_op_type component of the received message, in the order those components appear in the message, the value in its var_value field gets assigned to the variable named by that component's var_name field 🎉 The receiver then sends back a message of identical form, except the message type is Get Response, the error_status is gmp_err_noerror, and the error_index is zero 💖
Set Request messages only get generated by a protocol entity when the application user asks for one 🫧
Handling Set Request type frames isn't required by the protocol definition, so it's totally optional for an implementation to do it 🌸
That's the end of section 3's message types, bestie, we're making progress! 🌈
4. The Authentication Protocol 🔐✨
okay so the authentication protocol is a session-layer protocol 💅 its whole job is picking which messages a protocol user's message gets delivered to, and the protocol design makes sure nothing reaches a user if the protocol representation doesn't have an "authentic" form for it 🛡️
every protocol message talks to the others through a single UDP datagram 📦 each message fits in exactly one datagram, all by itself. An authentication protocol entity listens for these at UDP port 153 on its host 🎀
a half-session is, for any ordered pair of protocol users, all the messages that go from the first user to the second 💌 a session is the union of the two complementary half-sessions, so it's every message swapped between a given pair of users 🫶 each half-session comes with a triplet of functions 🧚
- The authentication function is a boolean-valued function for a given half-session. It tells you which authentication protocol messages have acceptable, authentic form, out of all the possible authentication protocol messages 👀
- The message interpretation function is a mapping. It takes the authentication protocol messages that the authentication function accepted for that half-session and turns them into user messages 💜
- The message representation function is the inverse of the message interpretation function for that same half-session 🔄
this document doesn't define how half-sessions connect to triplets of functions, so that part is left open 🤷♀️
a protocol entity recognizes exactly one message type 🌸 which one it is comes from the implicit type tag on the data structure the message represents, following the CCITT X.409 recommendation 📚
4.1. The Data Request Message Type 🍓
Data Request messages are a sequence of fields, and here's what each one means 📝
4.1.1. The Message Length Field 📏
The Message Length field of a Data Request message is the length of that message as an unsigned, 16-bit, binary integer 🔢 the bits go most significant first, and the length counts the Message Length field too 💕
4.1.2. The Session ID Length Field 🪪
The Session ID Length field tells you how many octets long the Session ID field is 🎯 it's an unsigned, 8-bit, binary integer 🌈
4.1.3. The Session ID Field 🏷️
The Session ID field names the protocol session the message belongs to 💖 it's a sequence of octets, and its length is whatever the Session ID Length field says ✨
4.1.4. The User Data Field 💌
The User Data field carries a message being passed from one protocol user to another 🫶 its encoding follows the conventions built into the message representation function for the right half of the session, the one named in the Session ID field 🧩
when a Data Request comes in, the receiving entity checks its form by running the authentication function for its half of the session named in the Session ID field 🕵️♀️ if that function says the form is "authentic," the message interpretation function turns the User Data value into a user message, and that message gets handed to the protocol user along with which session it came from 🎀
if the authentication function doesn't accept it, the message gets thrown out, and the protocol user gets told an unauthenticated message came in 🚫💀
a Data Request is only generated when a protocol user asks to send a message to another user 📤 that request names both the user message and the session it belongs to 📋 the generated message's Session ID is the session name from the request, and its User Data is the specified user message run through the message representation function for the right half of that session 💅
5. Variable Names 🧸
the variables the application protocol retrieves or changes are named by octet string values 🏷️ this document shows those strings in two ways 👀
- Numerically, as a sequence of hexadecimal numbers, where each number is the value of the matching octet in the string 🔢
- Symbolically, as a character string that follows the octets of the name and also hints at what the variable means to a human reader 🧠
symbolic representation follows two rules 📜
- A zero-length variable name is represented by the zero-length character string 🫧
- A variable name of length n is represented by the symbolic representation of its first (n - 1) octets, then an underscore (
_), then a character string with no underscore in it. That last string has to be unique among the symbolic representations of all variable names of length n 💜
for example, these numeric names:
01 01 01,
01 01 02,
01 02 01,
01 03 01 03 01,
01 03 01 03 02,
01 03 01 04 01, and
01 03 01 04 02could be shown symbolically as:
_GW_version_id,
_GW_version_rev,
_GW_cfg_nnets,
_GW_net_if_type_net1,
_GW_net_if_type_net2,
_GW_net_if_speed_net1, and
_GW_net_if_speed_net2.every variable name ends with an implementation-specific octet string of non-zero length 🌸 so none of the variables in this document have a complete name spelled out. Instead, each one gets a specified prefix, and whatever comes on the right end belongs to the implementation 🎀
to get the most out of the Get Request type message, related variable names should sit next to each other in the lexicographic ordering of every variable name an application protocol entity recognizes 📚 this document follows that idea for its current variables, and future revisions of this document and individual implementations should follow it too 💖
an implementation can show variables beyond the ones defined here, as long as no implementation-specific variable ever has the same name as one defined here 🧁 by convention, an implementation's own variables start with a shared prefix, which sets them apart from this document's variables and from variables other implementations show 🫶 for example, version 1.3 of the Squeaky gateway product from the Swinging Gateway company might use these names:
01 FF 01 01 13 01,
01 FF 01 01 13 02, and
01 FF 01 01 13 03,and their symbolic forms could be:
_GW_impl_Swinging_Squeaky_v1.3_variableA,
_GW_impl_Swinging_Squeaky_v1.3_variableB, and
_GW_impl_Swinging_Squeaky_v1.3_variableC.this document doesn't otherwise define the names or meanings of implementation-specific variables 🤍 but implementors are encouraged to publish those definitions, either as appendices to this document or some other appropriate way 📖✨
variable names that start with 02, symbolically _HOST, are reserved for future use 🚧 the same goes for names that start with 03, symbolically _TS 🔒
6. Required Variables 📋
if the gateway this protocol runs on also stores information that a variable in this section represents, then at least one application protocol entity tied to that gateway must give access to that variable 🔑
6.1. The _GW_version_id Variable 🪪
this variable's name starts with _GW_version_id symbolically and 01 01 01 numerically 🎀
its octet string value identifies the protocol entity implementation, for example "ACME Packet-Whiz Model II" 💻
6.2. The _GW_version_rev Variable 🔖
this variable's name starts with _GW_version_rev symbolically and 01 01 02 numerically 🌈
its integer value gives the revision level of the entity implementation 🔢 how that revision level gets encoded as an integer is up to the implementation 🧩
6.3. The _GW_cfg_nnets Variable 🌐
this variable's name starts with _GW_cfg_nnets symbolically and 01 02 01 numerically 💜
its integer value is the number of logical network interfaces the gateway configuration provides 🔌
6.4. Network Interface Variables 🛰️
this section describes a group of related variables that represent attributes of the logical network interfaces the gateway configuration provides 🫶 each network interface is uniquely identified by an octet string 🏷️ how those names get assigned to a gateway's network interfaces depends on the implementation 💅
6.4.1. The _GW_net_if_type Variable Class
okay so this one tells you what kind of network interface you're looking at 🔌 A variable whose name starts with _GW_net_if_type (that's 01 03 01 03 in the numbers 🔢) holds an integer, and that integer says what type of network the interface in the rest of the name is. The value follows the conventions in Appendix 1, so go peek there for the actual meanings 💅
01 03 01 036.4.2. The _GW_net_if_speed Variable Class
this is the speed one 🏎️💨 The name starts with _GW_net_if_speed, numerically 01 03 01 04. Its integer value is the estimated nominal bandwidth in bits per second for the interface named by the rest of the variable's name ✨
01 03 01 046.4.3. The _GW_net_if_in_pkts Variable Class
bestie this one is giving packet counting 📦 The name starts with _GW_net_if_in_pkts, numerically 01 03 01 01 01. The integer value is how many packets the gateway has received over the interface named by the rest of the name 🦋
01 03 01 01 016.4.4. The _GW_net_if_out_pkts Variable Class
same energy, opposite direction 🔁 The name starts with _GW_net_if_out_pkts, numerically 01 03 01 02 01. The integer value counts how many packets the gateway has transmitted over the interface named by the rest of the name 🚀
01 03 01 02 016.4.5. The _GW_net_if_in_bytes Variable Class
now we're counting bytes, and the spec calls them octets 🧁 The name starts with _GW_net_if_in_bytes, numerically 01 03 01 01 02. The integer value is how many octets the gateway has received over the interface named by the rest of the name 💜
01 03 01 01 026.4.6. The _GW_net_if_out_bytes Variable Class
the outgoing version of the byte counter 🌸 The name starts with _GW_net_if_out_bytes, numerically 01 03 01 02 02. The integer value is how many octets the gateway has transmitted over the interface named by the rest of the name ✨
01 03 01 02 026.4.7. The _GW_net_if_in_errors Variable Class
ugh, errors 😭 The name starts with _GW_net_if_in_errors, numerically 01 03 01 01 03. The integer value is how many reception errors the gateway ran into on the interface named by the rest of the name. Here's the tea: what counts as a reception error is implementation-specific, and it may vary depending on the network type 🫶
01 03 01 01 036.4.8. The _GW_net_if_out_errors Variable Class
the transmit-side error counter 🙈 The name starts with _GW_net_if_out_errors, numerically 01 03 01 02 03. The integer value is how many transmission errors the gateway hit on the interface named by the rest of the name. Same deal as before: what counts as a transmission error is implementation-specific, and it may vary by network type 🌈
01 03 01 02 036.4.9. The _GW_net_if_status Variable Class
last one in this bunch, and it's the vibe check 🔥 The name starts with _GW_net_if_status, numerically 01 03 01 05. The integer value shows the current status of the interface named by the rest of the name. Status values are explained in Appendix 2 💅
01 03 01 056.5. Internet Protocol Variables
okay now we're in the big-deal IP zone 🌐 This section covers variables about the protocols and mechanisms of the Internet Protocol (IP) family [3] 💖
6.5.1. Protocol Address Variable Classes
this is a whole family of variables about the IP interfaces a gateway shows off on each network it's plugged into 🎀 Every protocol interface gets identified by an octet string, and how those names get assigned for a gateway is totally up to the implementation 🧚
6.5.1.1. The _GW_pr_in_addr_value Variable Class
the name starts with _GW_pr_in_addr_value, numerically 01 04 01 01 01. The value is an octet string that literally represents the 32-bit Internet address of the IP interface named by the rest of the variable's name 🦋
01 04 01 01 016.5.1.2. The _GW_pr_in_addr_scope Variable Class
the name starts with _GW_pr_in_addr_scope, numerically 01 04 01 01 02. The value is an octet string that names the network interface the IP interface (from the rest of the name) is associated with 🔗
01 04 01 01 026.5.2. Exterior Gateway Protocol (EGP) Variables
this section is all about the EGP protocol [4] and the info it carries 🛰️ Let's go 💜
6.5.2.1. The _GW_pr_in_egp_core Variable
the name is _GW_pr_in_egp_core, numerically 01 04 01 03 01. The value is an integer that tells you how the gateway stacks up against the set of INTERNET core gateways. A nonzero value means the gateway is part of the INTERNET core 👑
01 04 01 03 016.5.2.2. The _GW_pr_in_egp_as Variable Class
the name starts with _GW_pr_in_egp_as, numerically 01 04 01 03 02. The integer value literally identifies the Autonomous System this gateway belongs to 🌟
01 04 01 03 026.5.2.3. The EGP Neighbor Variable Classes
this is a whole crew of variables about the "neighbors" a gateway might be connected to through EGP 🫶 Each EGP neighbor gets identified by an octet string, and how those names get assigned is implementation-specific, so no judgment here 🌸
6.5.2.3.1. The _GW_pr_in_egp_neighbor_addr Variable Class
the name starts with _GW_pr_in_egp_neighbor_addr, numerically 01 04 01 03 03 01. The value is an octet string that literally represents the 32-bit Internet address of the EGP neighbor named by the rest of the name 📍
01 04 01 03 03 016.5.2.3.2. The _GW_pr_in_egp_neighbor_state Variable Class
the name starts with _GW_pr_in_egp_neighbor_state, numerically 01 04 01 03 03 02. The value is an octet string showing the EGP protocol state of the gateway with respect to the neighbor named by the rest of the name. The meaningful values are "IDLE", "ACQUISITION", "DOWN", "UP", and "CEASE" 🔄
01 04 01 03 03 026.5.2.4. The _GW_pr_in_egp_errors Variable
this one's the name _GW_pr_in_egp_errors, numerically 01 04 01 03 05. It's an integer that counts the number of EGP protocol errors 😬
01 04 01 03 056.5.3. Routing Variable Classes
this crew is all about the IP routes a gateway uses to send packets to different destinations on the Internet 🗺️ Each route is identified by an octet string made from two parts stuck together: the literal 32-bit value of the destination's Internet address, plus an implementation-specific octet string. Everything else about how routes get named is implementation-specific too 🧩
6.5.3.1. The _GW_pr_in_rt_gateway Variable Class
the name starts with _GW_pr_in_rt_gateway, numerically 01 04 01 02 01. The value is an octet string that literally represents the 32-bit Internet address of the next gateway that the route (named by the rest of the name) sends traffic to ➡️
01 04 01 02 016.5.3.2. The _GW_pr_in_rt_type Variable Class
the name starts with _GW_pr_in_rt_type, numerically 01 04 01 02 02. The integer value shows the type of the route named by the rest of the name. Route types follow the conventions in Appendix 3 📚
01 04 01 02 026.5.3.3. The _GW_pr_in_rt_how-learned Variable Class
the name starts with _GW_pr_in_rt_how-learned, numerically 01 04 01 02 03. The value is an octet string that tells you where the route's info came from. The meaningful values are "STATIC", "EGP", and "RIP" 🕵️♀️
01 04 01 02 036.5.3.4. The _GW_pr_in_rt_metric0 Variable Class
the name starts with _GW_pr_in_rt_metric0, numerically 01 04 01 02 04. The integer value shows how good the route is, measured by cost, distance from the ultimate destination, or some other metric 💅
01 04 01 02 046.5.3.5. The _GW_pr_in_rt_metric1 Variable Class
the name starts with _GW_pr_in_rt_metric1, numerically 01 04 01 02 05. Same as metric0: an integer for the quality of the route, in terms of cost, distance from the ultimate destination, or another metric 🌈
01 04 01 02 056.6. DECnet Protocol Variables
this section covers variables about protocols and mechanisms of the DEC Digital Network Architecture 🖥️ Quick reminder: DEC and DECnet are registered trademarks of Digital Equipment Corporation ™️💕
6.7. XNS Protocol Variables
this section covers variables about protocols and mechanisms of the Xerox Network System 🖨️ Also a quick reminder: Xerox Network System and XNS are registered trademarks of the XEROX Corporation ✨
7. Implementation-Specific Variables
extra variables might be shown for inspection or manipulation by particular protocol entity implementations 🔧 Those are described in the Appendices of this document 🎀
8. References
[1] CCITT, "Message Handling Systems: Presentation Transfer Syntax and Notation", Recommendation X.409, 1984.
[2] Postel, J., "User Datagram Protocol", RFC-768, USC/Information Sciences Institute, August 1980.
[3] Postel, J., "Internet Protocol", RFC-760, USC/Information Sciences Institute, January 1980.
[4] Rosen, E., "Exterior Gateway Protocol", RFC-827, Bolt Beranek and Newman, October 1982.
9. Appendix 1: Network Type Representation
Okay bestie, let's get into the network type cheat sheet 🌈 Each network gets its own number, so you can always tell what you're looking at:
Value Network Type
====================
0 Unspecified
1 IEEE 802.3 MAC
2 IEEE 802.4 MAC
3 IEEE 802.5 MAC
4 Ethernet
5 ProNET-80
6 ProNET-10
7 FDDI
8 X.25
9 Point-to-Point Serial
10 Proprietary Point-to-Point Serial
11 ARPA 1822 HDH
12 ARPA 1822
13 AppleTalk
14 StarLAN10. Appendix 2: Network Status Representation ✨
Okay so this is the network status list 💅 Same deal, every status gets a number, and it's giving very clean energy:
Value Network Status
======================
0 Interface Operating Normally
1 Interface Not Present
2 Interface Disabled
3 Interface Down
4 Interface Attempting Link11. Appendix 3: Route Type Representation 🦋
Next up, the route types 🌸 These are the numbers for each kind of route:
Value Route Type
==================
0 Route to Nowhere -- ignored
1 Route to Directly Connected Network
2 Route to a Remote Host
3 Route to a Remote Network
4 Route to a Sub-Network12. Appendix 4: Initial Implementation Strategy 💅
The goal for the first implementations of this protocol is to give us a way to monitor Internet gateways 👀 The design does have some room for gateway management functions too, but that part isn't fully cooked yet. It needs more refinement before anyone could ship a generally useful implementation. So, for now, initial implementations will not generate or respond to the optional Set Request message type.
The protocol defined here might get refined later, based on what we learn from early implementations or from further study of gateway management. It could also get superseded by other proposals in the area of gateway monitoring and control 🔥
Authentication is a whole other vibe 🔐 Implementations of the authentication protocol in this document are likely to change as users' security and privacy needs change. In general, how particular half-sessions of the authentication protocol connect to the described triplets of functions is up to each implementation, and that's outside the scope of this document. But everyone wants initial implementations to work together right away, so the best move is to temporarily adopt a common authentication scheme. That means initial implementations will associate every possible half-session with a triplet of functions that does a trivial authentication mechanism:
- The authentication function is defined to have the value TRUE over the entire domain of authentication protocol messages.
- The message interpretation function is defined to be the identity function.
- The message representation function is defined to be the identity function.
This starting point for authentication probably won't stay acceptable forever, so implementors are urged to design things that isolate the authentication mechanism as much as possible from the other components of the implementation. Future us will thank us 🫶
13. Appendix 5: Routing Information Propagation Variables 🎀
This section is all about a group of related variables that describe the sources and destinations of routing information sent out by different routing protocols. Lowkey a bit technical, but stay with me 💜 These variables only mean something for routing protocol implementations that give you more flexibility in propagating routing information than the routing protocol specifications require.
Each IP interface that the gateway's configuration makes available for routing information to propagate over via a routing protocol (target interface) is named by a string of four octets. That string literally represents the IP address for that protocol interface.
Each IP protocol interface that the gateway's configuration makes available for routing information to arrive on, via any routing protocol (source interface), is also named by a string of four octets. Again, that string literally represents the IP address for that protocol interface.
Each routing protocol that a gateway receives information through, which it uses to route IP traffic (source routing protocol), is named by a single-octet string. Use the conventions in Appendix 6 of this document for that.
Each routing protocol that a gateway uses to propagate routing information that other hosts or gateways use to route IP traffic (target routing protocol) is also named by a single-octet string. Again, follow the conventions in Appendix 6 of this document 🧚
Now for the variable names 💖 A variable's name starts with the following concatenation:
- the octet string represented symbolically as
_GW_pr_in_rifand numerically as01 04 01 04, followed by: - the name of a target routing protocol, followed by
- the name of a target interface, followed by
- the name of a source routing protocol, followed by
- the name of a source interface
The variable then has an integer value that characterizes how routing information propagates between the sources and destinations identified by that initial part of the name. A non-zero value means routing information received via the source routing protocol (the fourth component of the name) on the source interface (the fifth component) is propagated via the target routing protocol (the second component) over the target interface (the third component).
A zero value means routing information received via the source routing protocol on the source interface named in the variable is NOT propagated via the target routing protocol over the target interface named in the variable. Zero means nope, not happening 🙈
14. Appendix 6: Routing Protocol Representation 🧚
Numeric representations for routing protocols are below. These are the ones you'll see in the conventions mentioned above:
Value Routing Protocol
========================
0 None -- Reserved
1 Berkeley RIP Version 1
2 EGP
3 GGP
4 Hello
5 Other IGRP15. Appendix 7: Proteon p4200 Release 7.4 Variables 🍓
Okay, this is the big implementation-specific one 🍓 This section describes implementation-specific variables from the implementation of this protocol in Software Release 7.4 for the Proteon p4200 Internet Router. Fair warning: these variable definitions are subject to change without notice, so don't get too attached 🥺
15.1. The Network Interface Variables
This section describes a related set of variables that represent attributes of a network interface in the Proteon p4200 Internet Router gateway. Each network interface is uniquely named by an implementation-specific octet string of length 1. Simple, but important 💅
15.1.1. The Generic Network Interface Variables
This section describes a related set of variables that represent attributes common to all network interfaces in the Proteon p4200 Internet Router gateway. Each generic network interface of a p4200 configuration is uniquely named by the concatenation of the octet string represented symbolically as _GW_impl_Proteon_p4200-R7.4_net-if and numerically as:
01 FF 01 01 01After that comes the name of the network interface, as described above ✨
15.1.1.1. The Generic _ovfl-in Variable Class
A variable whose name starts with the name of a generic network interface, followed by the octet string represented symbolically as _ovfl-in and numerically as 01, has an integer value. That value is the number of input packets dropped due to gateway congestion for the network interface identified by the start of its name 📉
15.1.1.2. The Generic _ovfl-out Variable Class
A variable whose name starts with the name of a generic network interface, followed by the octet string represented symbolically as _ovfl-out and numerically as 02, has an integer value. That value is the number of output packets dropped due to gateway congestion for the network interface identified by the start of its name 📉
15.1.1.3. The Generic _slftst-pass Variable Class
A variable whose name starts with the name of a generic network interface, followed by the octet string represented symbolically as _slftst-pass and numerically as 03, has an integer value. That value is the number of times the interface self-test procedure succeeded for the network interface identified by the start of its name 🎉
15.1.1.4. The Generic _slftst-fail Variable Class
A variable whose name starts with the name of a generic network interface, followed by the octet string represented symbolically as _slftst-fail and numerically as 04, has an integer value. That value is the number of times the interface self-test procedure failed for the network interface identified by the start of its name 😭
15.1.1.5. The Generic _maint-fail Variable Class
A variable whose name starts with the name of a generic network interface, followed by the octet string represented symbolically as _maint-fail and numerically as 06, has an integer value. That value is the number of times the network maintenance procedure failed for the network interface identified by the start of its name 🛠️
15.1.1.6. The Generic _csr Variable Class
A variable whose name starts with the name of a generic network interface, followed by the octet string represented symbolically as _csr and numerically as 07, has an integer value. That value is the internal address of the device CSR for the network interface identified by the start of its name 🔧
15.1.1.7. The Generic _vec Variable Class
A variable whose name starts with the name of a generic network interface, followed by the octet string represented symbolically as _vec and numerically as 08, has an integer value. That value identifies the device interrupt vector used by the network interface identified by the start of its name 🌟
15.1.2. The ProNET Network Interface Variables 🌸
okay so this section is all about a ProNET type network interface on the Proteon p4200 Internet Router gateway 🦋 every network interface on a p4200 config that supports ProNET media gets its own unique name. You build it by sticking together the octet string _GW_impl_Proteon_p4200-R7.4_devpn (written numerically as the bytes below) and then the name of that interface from earlier 💅
01 FF 01 01 0415.1.2.1. The ProNET _node-number Variable Class 💖
so this variable's name starts with the ProNET interface name, then _node-number (that's 01 in numeric form) 🫶 its integer value is the ProNET node number for the interface it's attached to. simple and iconic ✨
15.1.2.2. The ProNET _in-data-present Variable Class 🎀
the name is the ProNET interface name plus _in-data-present (numerically 02) 🌈 the integer value counts how many times unread data was sitting in that interface's input packet buffer. the buffer was just... waiting 😭
15.1.2.3. The ProNET _in-overrun Variable Class 💜
ProNET interface name plus _in-overrun (numerically 03) 💅 this one is an integer counting how many times a packet copied off the ring was bigger than the input packet buffer on that interface. that's a whole overflow moment, bestie 💀
15.1.2.4. The ProNET _in-odd-byte-cnt Variable Class 🍓
ProNET interface name plus _in-odd-byte-cnt (numerically 04) 🧚 the integer here is how many times a received packet had an odd number of bytes on that interface. odd byte packets are lowkey a mood 🙈
15.1.2.5. The ProNET _in-parity-error Variable Class ⭐
ProNET interface name plus _in-parity-error (numerically 05) ✨ integer value = how many times a parity error got detected in a packet copied off the ring on that interface. caught red-handed 👑
15.1.2.6. The ProNET _in-bad-format Variable Class 🦋
ProNET interface name plus _in-bad-format (numerically 06) 🌸 integer value = how many times a format error showed up in a packet copied off the ring on that interface. not the packet's finest hour 💀
15.1.2.7. The ProNET _not-in-ring Variable Class 🫶
ProNET interface name plus _not-in-ring (numerically 07) 🔥 this integer counts how many times the ProNET wire center relays were found in an unenergized state for that interface. the relays were literally just sitting there off, no power, no cap 😭
15.1.2.8. The ProNET _out-ring-inits Variable Class 💅
ProNET interface name plus _out-ring-inits (numerically 08) 🎀 integer value = how many times ring initialization got attempted on that interface. it's the "try again" counter, periodt 🔁
15.1.2.9. The ProNET _out-bad-format Variable Class 🌈
ProNET interface name plus _out-bad-format (numerically 09) ✨ this one counts how many times an improperly formatted packet got caught during an output operation on that interface. we don't send messy packets, bestie 🙈
15.1.2.10. The ProNET _out-timeout Variable Class 💜
ProNET interface name plus _out-timeout (numerically 0A) 🧚 the integer value is how many times an attempt to originate a message got delayed by more than 700 ms on that interface. 700 ms is a long time to wait in networking land 😭
15.1.3. The Ethernet Network Interface Variables 🍓
this section is the Ethernet version of the same vibe 🦋 an Ethernet type network interface on the Proteon p4200 Internet Router gateway. every interface on a p4200 config that supports Ethernet media gets a unique name, made by sticking together the octet string _GW_impl_Proteon_p4200-R7.4_dev-ie (numerically the bytes below) and then the interface name from earlier 💖
01 FF 01 01 0315.1.3.1. The Ethernet _phys-addr Variable Class 🌸
the name is the Ethernet interface name plus _phys-addr, which is numerically 01 🫶 its value is an octet string that literally represents the Ethernet station address for that interface. the MAC address, bestie, just in its raw form ✨
15.1.3.2. The Ethernet _input-ovfl Variable Class 🎀
Ethernet interface name plus _input-ovfl (numerically 02) 💅 integer value = how many times a received frame was bigger than the max allowed on that interface. oversized frames, not it 🙅
15.1.3.3. The Ethernet _input-dropped Variable Class 💜
Ethernet interface name plus _input-dropped (numerically 03) 🌈 this integer counts how many times the loss of one or more frames got detected on that interface. dropped frames hit different 😭
15.1.3.4. The Ethernet _output-retry Variable Class 🧚
Ethernet interface name plus _output-retry (numerically 04) 🍓 integer value = how many output operations got retried because of a transmission failure on that interface. it's the comeback arc ⭐
15.1.3.5. The Ethernet _output-fail Variable Class 🔥
Ethernet interface name plus _output-fail (numerically 05) 💀 this one counts how many failed output operations got detected on that interface. no thoughts, just failures 😭
15.1.3.6. The Ethernet _excess-coll Variable Class 🦋
Ethernet interface name plus _excess-coll (numerically 06) 👑 integer value = how many times a transmit frame ran into 16 successive collisions while trying to get media access through that interface. sixteen in a row?? that's a whole collision saga 💀
15.1.3.7. The Ethernet _frag-rcvd Variable Class 🌸
Ethernet interface name plus _frag-rcvd (numerically 07) 🫶 this counts the collision fragments (the "runt packets," iykyk) that the controller for that interface received and filtered out. tiny broken leftovers, gone ✨
15.1.3.8. The Ethernet _frames-lost Variable Class 💅
Ethernet interface name plus _frames-lost (numerically 08) 🎀 integer value = how many frames the Receive FIFO didn't accept because there wasn't enough space for that interface. no room at the FIFO, literally 😭
15.1.3.9. The Ethernet _multicst-accept Variable Class 🌈
Ethernet interface name plus _multicst-accept (numerically 09) ✨ this integer counts the frames received with a multicast-group destination address that matches one assigned to the controller for that interface. the ones that were invited to the party 🎉
15.1.3.10. The Ethernet _multicst-reject Variable Class 💜
Ethernet interface name plus _multicst-reject (numerically 0A) 🧚 integer value = how many frames had a multicast-group destination address that matched none of the ones assigned to the controller for that interface. not on the list, not coming in 🚫
15.1.3.11. The Ethernet _crc-error Variable Class 🍓
Ethernet interface name plus _crc-error (numerically 0B) 🔥 this counts the frames received with a CRC error on that interface. the checksum said nope 💀
15.1.3.12. The Ethernet _alignmnt-error Variable Class ⭐
Ethernet interface name plus _alignmnt-error (numerically 0C) 👑 integer value = how many frames came in with an alignment error on that interface. and a frame has an alignment error when its received length isn't a whole multiple of 8 bits. not byte-aligned, not it 🙈
15.1.3.13. The Ethernet _collisions Variable Class
okay so this one is a collision counter 💥 A variable whose name starts with the name of an Ethernet type network interface, followed by the octet string _collisions (that's 0D numerically) 🎀, holds an integer. That integer is the number of collisions that happened during transmissions on the interface named at the start of the variable's name. it's literally just a tally 💅
15.1.3.14. The Ethernet _out-of-window-coll Variable Class
this one is giving late collision energy 😭 A variable whose name starts with the name of an Ethernet type network interface, followed by the octet string _out-of-window-coll (that's 0E numerically) 🦋, holds an integer. That integer is the number of out-of-window collisions during transmissions on the interface named at the start of the name. and the spicy part is how we define "out-of-window": those are the collisions that happen after the first 51.2 microseconds of slot time ⏱️ so not the early ones, only the late ones 🙈
15.1.4. The Serial Network Interface Variables
okay now we're switching to serial line interfaces 🧚 this section describes a related set of variables that represent attributes of a serial line type network interface in the Proteon p4200 Internet Router gateway 🌐 every network interface on a p4200 configuration that supports serial communications gets uniquely named. the name is the octet string _GW_impl_Proteon_p4200-R7.4_dev-sl, which is numerically:
01 FF 01 01 05and then you stick on the name of that network interface, as described above 🫶 that's the whole prefix situation ✨
15.1.4.1. The Serial _tx-pkts Variable Class
A variable whose name starts with the name of a serial line type network interface, followed by the octet string _tx-pkts (that's 01 numerically) 💖, holds an integer. It's the number of packets transmitted on the interface named at the start of the variable's name 📦
15.1.4.2. The Serial _tx-framing-error Variable Class
A variable whose name starts with the name of a serial line type network interface, followed by the octet string _tx-framing-error (that's 02 numerically) 🌸, holds an integer. It's the number of transmission framing errors for the interface named at the start of the name. not the vibe, but we track it 😭
15.1.4.3. The Serial _tx-underrns Variable Class
A variable whose name starts with the name of a serial line type network interface, followed by the octet string _tx-underrns (that's 03 numerically) 🍓, holds an integer. It's the number of transmission underrun errors for the interface named at the start of the name 💀
15.1.4.4. The Serial _tx-no-dcd Variable Class
A variable whose name starts with the name of a serial line type network interface, followed by the octet string _tx-no-dcd (that's 04 numerically) 💜, holds an integer. It counts the number of times transmission failed because the EIA Data Carrier Detect signal was absent on the interface named at the start of the name. no signal, no send, periodt 🙅♀️
15.1.4.5. The Serial _tx-no-cts Variable Class
A variable whose name starts with the name of a serial line type network interface, followed by the octet string _tx-no-cts (that's 05 numerically) 🎀, holds an integer. It counts the number of times transmission failed because the EIA Clear To Send signal was absent on the interface named at the start of the name 🫠
15.1.4.6. The Serial _tx-no-dsr Variable Class
A variable whose name starts with the name of a serial line type network interface, followed by the octet string _tx-no-dsr (that's 06 numerically) 🧚, holds an integer. It counts the number of times transmission failed because the EIA Data Set Ready signal was absent on the interface named at the start of the name 🌈
15.1.4.7. The Serial _rx-pkts Variable Class
A variable whose name starts with the name of a serial line type network interface, followed by the octet string _rx-pkts (that's 07 numerically) ⭐, holds an integer. It's the number of packets received on the interface named at the start of the name. incoming mail, bestie 📬
15.1.4.8. The Serial _rx-framing-err Variable Class
A variable whose name starts with the name of a serial line type network interface, followed by the octet string _rx-framing-err (that's 08 numerically) 🦋, holds an integer. It's the number of receive framing errors on the interface named at the start of the name 😤
15.1.4.9. The Serial _rx-overrns Variable Class
A variable whose name starts with the name of a serial line type network interface, followed by the octet string _rx-overrns (that's 09 numerically) 🔥, holds an integer. It's the number of receive overrun errors on the interface named at the start of the name 🥲
15.1.4.10. The Serial _rx-aborts Variable Class
A variable whose name starts with the name of a serial line type network interface, followed by the octet string _rx-aborts (that's 0A numerically) 🌷, holds an integer. It's the number of aborted frames received on the interface named at the start of the name 💅
15.1.4.11. The Serial _rx-crc-err Variable Class
A variable whose name starts with the name of a serial line type network interface, followed by the octet string _rx-crc-err (that's 0B numerically) 🎀, holds an integer. It's the number of frames received with CRC errors on the interface named at the start of the name 🫶
15.1.4.12. The Serial _rx-buf-ovfl Variable Class
A variable whose name starts with the name of a serial line type network interface, followed by the octet string _rx-buf-ovfl (that's 0C numerically) 💖, holds an integer. It's the number of received frames whose size went over the maximum allowable on the interface named at the start of the name. too big, not allowed 🙈
15.1.4.13. The Serial _rx-buf-locked Variable Class
A variable whose name starts with the name of a serial line type network interface, followed by the octet string _rx-buf-locked (that's 0D numerically) 🍓, holds an integer. It's the number of received frames that got lost because there was no available buffer on the interface named at the start of the name 🥺
15.1.4.14. The Serial _rx-line-speed Variable Class
A variable whose name starts with the name of a serial line type network interface, followed by the octet string _rx-line-speed (that's 0E numerically) 🚀, holds an integer. It's an estimate of the serial line bandwidth in bits per second for the interface named at the start of the name. the number is an estimate, so read it with that in mind ✨
📦 where this page comes from
- ietf: rfc1028 1987-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms