RFC 1028 HISTORIC NETWORK MANAGEMENT · MONITORING · GATEWAYS
SGMP: Simple Gateway Monitoring Protocol
An early way to read and change the settings of an Internet router from a remote machine.
RFC EDITOR
Davin, J., Case, J.D., Fedor, M., and M.L. Schoffstall, "Simple Gateway Monitoring Protocol", RFC 1028, DOI 10.17487/RFC1028, November 1987, <https://www.rfc-editor.org/info/rfc1028>.
BIBTEX
@misc{rfc1028,
series = {Request for Comments},
number = 1028,
howpublished = {RFC 1028},
publisher = {RFC Editor},
doi = {10.17487/RFC1028},
url = {https://www.rfc-editor.org/info/rfc1028},
author = {J. Davin and J.D. Case and M. Fedor and M.L. Schoffstall},
title = {{Simple Gateway Monitoring Protocol}},
pagetotal = 35,
year = 1987,
month = nov,
} RFC text
Contents
Network Working Group J. Davin
Request for Comments: 1028 Proteon, Inc.
J. Case
University of Tennessee at Knoxville
M. Fedor
Cornell University
M. Schoffstall
Rensselaer Polytechnic Institute
November 1987
A Simple Gateway Monitoring Protocol
1. Status of this Memo
This document is being distributed to members of the Internet
community in order to solicit their reactions to the proposals
contained in it. While the issues discussed may not be directly
relevant to the research problems of the Internet, they may be
interesting to a number of researchers and implementors.
This memo defines a simple application-layer protocol by which
management information for a gateway may be inspected or altered by
logically remote users.
This proposal is intended only as an interim response to immediate
gateway monitoring needs while work on more elaborate and robust
designs proceeds with the care and deliberation appropriate to that
task. Accordingly, long term use of the mechanisms described here
should be seriously questioned as more comprehensive proposals emerge
in the future. Distribution of this memo is unlimited.
2. Protocol Design Strategy
The proposed protocol is shaped in large part by the desire to
minimize the number and complexity of management functions realized
by the gateway itself. This goal is attractive in at least four
respects:
(1) The development cost for gateway software necessary to
support the protocol is accordingly reduced.
(2) The degree of management function that is remotely
supported is accordingly increased, thereby admitting
fullest use of internet resources in the management task.
(3) The degree of management function that is remotely
supported is accordingly increased, thereby imposing the
fewest possible restrictions on the form and sophistication
of management tools.
(4) A simplified set of management functions is easily
understood and used by developers of gateway management
tools.
A second design goal is that the functional paradigm for monitoring
and control be sufficiently extensible to accommodate additional,
possibly unanticipated aspects of gateway operation.
A third goal is that the design be, as much as possible, independent
of the architecture and mechanisms of particular hosts or particular
gateways.
Consistent with the foregoing design goals are a number of decisions
regarding the overall form of the protocol design.
One such decision is to model all gateway management functions as
alterations or inspections of various parameter values. By this
model, a protocol entity on a logically remote host (possibly the
gateway itself) interacts with a protocol entity resident on the
gateway in order to alter or retrieve named portions (variables) of
the gateway state. This design decision has at least two positive
consequences:
(1) It has the effect of limiting the number of essential
management functions realized by the gateway to two: one
operation to assign a value to a specified configuration
parameter and another to retrieve such a value.
(2) A second effect of this decision is to avoid introducing
into the protocol definition support for imperative
management commands: the number of such commands is in
practice ever-increasing, and the semantics of such
commands are in general arbitrarily complex.
The exclusion of imperative commands from the set of explicitly
supported management functions is unlikely to preclude any desirable
gateway management operation. Currently, most gateway commands are
requests either to set the value of some gateway parameter or to
retrieve such a value, and the function of the few imperative
commands currently supported is easily accommodated in an
asynchronous mode by this management model. In this scheme, an
imperative command might be realized as the setting of a parameter
value that subsequently triggers the desired action.
A second design decision is to realize any needed authentication
functionality in a distinct protocol layer that provides services to
the monitoring protocol itself. The most important benefit of this
decision is a reduction in the complexity of the individual protocol
layers - thereby easing the task of implementation.
Consistent with this layered design strategy is a third design
decision that the identity of an application protocol entity is known
to its peers only by the services of the underlying authentication
protocol. Implicit in this decision is a model of access control by
which access to variables of a gateway configuration is managed in
terms of the association between application entities and sessions of
the authentication protocol. Thus, multi-level access to gateway
variables is supported by multiple instances of the application
protocol entity, each of which is characterized by:
(1) the set of gateway variables known to said entity,
(2) the mode of access (READ-ONLY or READ-WRITE) afforded to
said set of variables, and
(3) the authentication protocol session to which belong the
messages sent and received by said entity.
A fourth design decision is to adopt the conventions of the CCITT
X.409 recommendation [1] for representing the information exchanged
between protocol entities. One cost of this decision is a modest
increase in the complexity of the protocol implementation. One
benefit of this decision is that protocol data are represented on the
network in a machine-independent, widely understood, and widely
accepted form. A second benefit of this decision is that the form of
the protocol messages may be concisely and understandably described
in the X.409 language defined for such purposes.
A fifth design decision, consistent with the goal of minimizing
gateway complexity, is that the variables manipulated by the protocol
assume only integer or octet string type values.
A sixth design decision, also consistent with the goal of minimizing
gateway complexity, is that the exchange of protocol messages
requires only an unreliable datagram transport, and, furthermore,
that every protocol message is entirely and independently
representable by a single transport datagram. While this document
specifies the exchange of protocol messages via the UDP protocol [2],
the design proposed here is in general suitable for use with a wide
variety of transport mechanisms.
A seventh design decision, consistent with the goals of simplicity
and extensibility, is that the variables manipulated by the protocol
are named by octet string values. While this decision departs from
the architectural traditions of the Internet whereby objects are
identified by assigned integer values, the naming of variables by
octet strings affords at least two valuable benefits. Because the
set of octet string values constitutes a variable name space that, as
convenient, manifests either flat or hierarchical structure,
(1) a single, simple mechanism can provide both random access
to individual variables and sequential access to
semantically related groups of variables, and
(2) the variable name space may be extended to accommodate
unforeseen needs without compromising either the
relationships among existing variables or the potential
for further extensions to the space.
An eighth design decision is to minimize the number of unsolicited
messages required by the protocol definition. This decision is
consistent with the goal of simplicity and motivated by the desire to
retain maximal control over the amount of traffic generated by the
network management function - even at the expense of additional
protocol overhead. The strategy implicit in this decision is that
the monitoring of network state at any significant level of detail is
accomplished primarily by polling for appropriate information on the
part of the monitoring center. In this context, the definition of
unsolicited messages in the protocol is confined to those strictly
necessary to properly guide a monitoring center regarding the timing
and focus of its polling.
3. The Gateway Monitoring Protocol
The gateway monitoring protocol is an application protocol by which
the variables of a gateway's configuration may be inspected or
altered.
Communication among application protocol entities is by the exchange
of protocol messages using the services of the authentication
protocol described elsewhere in this document. Each such message is
entirely and independently represented by a single message of the
underlying authentication protocol. An implementation of this
protocol need not accept protocol messages whose length exceeds 484
octets.
The form and function of the four message types recognized by a
protocol entity is described below. The type of a given protocol
message is indicated by the value of the implicit type tag for the
data structure that is represented by said message according to the
conventions of the CCITT X.409 recommendation.
3.1. The Get Request Message Type
The form of a message of Get Request type is described below in the
language defined in the CCITT X.409 recommendation:
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
}
Upon receipt of a message of this type, the receiving entity responds
according to any applicable rule in the list below:
(1) 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.
(2) 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, then the receiving entity sends
to the originator of the received message a Get Response type message
such that, for each var_op_type component of the received message, a
corresponding component of the generated message represents the name
and value of that variable whose name is, in the lexicographical
ordering of the names of all variables known to the receiving entity
together with the value of the var_name field of the given component,
the immediate successor to that value. The value of the error_status
field of the generated message is gmp_err_noerror and the value of
the error_index field is zero. The value of the request_id field of
the generated message is that for the received message.
Messages of the Get Request type are generated by a protocol entity
only at the request of the application user.
3.2. The Get Response Message Type
The form of messages of this type is identical to that of Get Request
type messages except for the indication of message type. In the CCITT
X.409 language,
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
}
The response of a protocol entity to a message of this type is to
present its contents to the application user.
Messages of the Get Response type are generated by a protocol entity
only upon receipt of Set Request or Get Request type messages as
described elsewhere in this document.
3.3. The Trap Request Message Type
The form of a message of this type is described below in the language
defined in the CCITT X.409 recommendation:
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
}
The response of a protocol entity to a message of this type is to
present its contents to the application user.
Messages of the Trap Request type are generated by a protocol entity
only at the request of the application user.
The significance of the val_list component of a Trap Request type
message is implementation-specific.
Interpretations for negative values of the trap_type field are
implementation-specific. Interpretations for non-negative values of
the trap_type field are defined below.
3.3.1. The Cold Start Trap Type
A Trap Request type message for which the value of the trap_type
field is 0, signifies that the sending protocol entity is
reinitializing itself such that the gateway configuration or the
protocol entity implementation may be altered.
3.3.2. The Warm Start Trap Type
A Trap Request type message for which the value of the trap_type
field is 1, signifies that the sending protocol entity is
reinitializing itself such that neither the gateway configuration nor
the protocol entity implementation is altered.
3.3.3. The Link Failure Trap Type
A Trap Request type message for which the value of the trap_type
field is 2, signifies that the sending protocol entity recognizes a
failure in one of the communication links represented in the gateway
configuration.
3.3.4. The Authentication Failure Trap Type
A Trap Request type message for which the value of the trap_type
field is 3, signifies that the sending protocol entity is the
addressee of a protocol message that is not properly authenticated.
3.3.5. The EGP Neighbor Loss Trap Type
A Trap Request type message for which the value of the trap_type
field is 4, signifies that an EGP neighbor for whom the sending
protocol entity was an EGP peer has been marked down and the peer
relationship no longer obtains.
3.4. The Set Request Message Type
The form of messages of this type is identical to that of Get Request
type messages except for the indication of message type. In the
CCITT X.409 language:
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
}
Upon receipt of a message of this type, the receiving entity responds
according to any applicable rule in the list below:
(1) 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.
(2) 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.
(3) 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, then for each var_op_type
component of the received message, according to the sequence of such
components represented by said message, the value represented by the
var_value field of the given component is assigned to the variable
named by the value of the var_name field of that component. 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_noerror,
and the value of the error_index field is zero.
Messages of the Set Request type are generated by a protocol entity
only at the request of the application user.
Recognition and processing of Set Request type frames is not required
by the protocol definition.
4. The Authentication Protocol
The authentication protocol is a session-layer protocol by which
messages specified by a protocol user are selectively delivered to
other protocol users. The protocol definition precludes delivery to
a protocol user of any user message for which the protocol
representation lacks a specified "authentic" form.
Communication among authentication protocol entities is accomplished
by the exchange of protocol messages, each of which is entirely and
independently represented by a single UDP datagram. An
authentication protocol entity responds to protocol messages received
at UDP port 153 on the host with which it is associated.
A half-session of the authentication protocol is, for any ordered
pair of protocol users, the set of messages sent from the first user
of the pair to the second user of said pair. A session of the
authentication protocol is defined to be union of two complementary
half-sessions of the protocol - that is, the set of messages
exchanged between a given pair of protocol users. Associated with
each protocol half-session is a triplet of functions:
(1) The authentication function for a given half-session is a
boolean-valued function that characterizes the set of
authentication protocol messages that are of acceptable,
authentic form with respect to the set of all possible
authentication protocol messages.
(2) The message interpretation function for a given half-
session is a mapping from the set of authentication
protocol messages accepted by the authentication function
for said half-session to the set of all possible user
messages.
(3) The message representation function for a given half-
session is a mapping that is the inverse of the message
interpretation function for said half-session.
The association between half-sessions of the authentication protocol
and triplets of functions is not defined in this document.
The form and function of the single message type recognized by a
protocol entity is described below. The type of a given protocol
message is indicated by the value of the implicit type tag for the
data structure that is represented by said message according to the
conventions of the CCITT X.409 recommendation.
4.1. The Data Request Message Type
Messages of this type are represented by a sequence of fields whose
form and interpretation are described below.
4.1.1. The Message Length Field
The Message Length field of a given Data Request message represents
the length of said message as an unsigned, 16-bit, binary integer.
This value is encoded such that more significant bits precede less
significant bits in the order of transmission and includes the length
of the Message Length field itself.
4.1.2. The Session ID Length Field
The Session ID Length field of a given Data Request message
represents the length, in octets, of the Session ID field of said
message. This value is encoded as an unsigned, 8-bit, binary
integer.
4.1.3. The Session ID Field
The Session ID field of a given Data Request message represents the
name of the protocol session to which said message belongs. The
value of this field is encoded as asequence of octets whose length is
the value of the Session ID Length field for said message.
4.1.4. The User Data Field
The User Data field of a given Data Request message represents a
message being passed from one protocol user to another. The value of
this field is encoded according to conventions implicit in the
message representation function for the appropriate half of the
protocol session named by the value of the Session ID field for said
message.
Upon receipt of a Data Request type message, the receiving
authentication protocol entity verifies the form of said message by
application of the authentication function associated with its half
of the session named by the value of the Session ID field in the
received message. If the form of the received message is accepted as
"authentic" by said function, then the user message computed by the
application of the message interpretation function for said half-
session to the value of the User Data field of the received message
is presented to the protocol user together with an indication of the
protocol session to which the received message belongs.
Otherwise, the message is discarded and an indication of the receipt
of an unauthenticated message is presented to the protocol user.
A message of this type is generated only at the request of the
protocol user to communicate a message to another user of the
protocol. Such a request specifies the user message to be sent as
well as the session of the authentication protocol to which said user
message belongs. The value of the Session ID field of the generated
message is the name of the session specified in the user request.
The value of the User Data field of the generated message is computed
by applying the message representation function for the appropriate
half of the specified session to the specified user message.
5. Variable Names
The variables retrieved or manipulated by the application protocol
are named by octet string values. Such values are represented in
this document in two ways:
(1) A variable name octet string may be represented
numerically by a sequence of hexadecimal numbers, each of
which denotes the value of the corresponding octet in
said string.
(2) A variable name octet string may be represented
symbolically by a character string whose form reflects
the sequence of octets in said name while at the same
time suggesting to a human reader the semantics of the
named variable.
Variable name octet strings are represented symbolically according to
the following two rules:
(1) The symbolic character string representation of the
variable name of zero length is the character string of
zero length.
(2) The symbolic character string representation of a
variable name of non-zero length n is the concatenation
of the symbolic character string representation of the
variable name formed by the first (n - 1) octets of the
given name together with the underscore character ("_")
and a character string that does not include the
underscore character, such that the resulting character
string is unique among the symbolic character string
representations for all variable names of length n.
Thus, for example, the variable names represented numerically as:
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 02
might be represented symbolically by the character strings:
_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.
All variable names are terminated by an implementation specific octet
string of non-zero length. Thus, a complete variable name is not
specified for any of the variables defined in this document. Rather,
for each defined variable, some prefix portion of its name is
specified, with the understanding that the rightmost portion of its
name is specific to the protocol implementation.
Fullest exploitation of the semantics of the Get Request type message
requires that names for related variables be chosen so as to be
contiguous in the lexicographic ordering of all variable names
recognized by an application protocol entity. This principle is
observed in the naming of variables currently defined by this
document, and it should be observed as well for variables defined by
subsequent revisions of this document and for variables introduced by
particular implementations of the protocol.
A particular implementation of a protocol entity may present
variables in addition to those defined by this document, provided
that in no case will an implementation-specific variable be presented
as having a name identical to that for one of the variables defined
here. By convention, the names of variables specific to a particular
implementation share a common prefix that distinguishes said
variables from those defined in this document and from those that may
be presented by other implementations of an application protocol
entity. For example, variables specific to an implementation of this
protocol in version 1.3 of the Squeaky gateway product of the
Swinging Gateway company might have the names represented by:
01 FF 01 01 13 01,
01 FF 01 01 13 02, and
01 FF 01 01 13 03,
for which the corresponding symbolic representations might be:
_GW_impl_Swinging_Squeaky_v1.3_variableA,
_GW_impl_Swinging_Squeaky_v1.3_variableB, and
_GW_impl_Swinging_Squeaky_v1.3_variableC.
The names and semantics of implementation-specific variables are not
otherwise defined by this document, although implementors are
encouraged to publish such definitions either as appendices to this
document or by other appropriate means.
Variable names of which the initial portion is represented
numerically as 02 and symbolically as "_HOST" are reserved for future
use. Variable names of which the initial portion is represented
numerically as 03 and symbolically as "_TS" are similarly reserved.
6. Required Variables
To the extent that the information represented by a variable defined
in this section is also represented internally by a gateway for which
this protocol is realized, access to that variable must be afforded
by at least one application protocol entity associated with said
gateway.
6.1. The _GW_version_id Variable
The variable such that the initial portion of its name is represented
symbolically as "_GW_version_id" and numerically as:
01 01 01
has an octet string value that identifies the protocol entity
implementation (e.g., "ACME Packet-Whiz Model II").
6.2. The _GW_version_rev Variable
The variable such that the initial portion of its name is represented
symbolically as "_GW_version_rev" and numerically as:
01 01 02
has an integer value that identifies the revision level of the entity
implementation. The encoding of the revision level as an integer
value is implementation-specific.
6.3. The _GW_cfg_nnets Variable
The variable such that the initial portion of its name is represented
symbolically as "_GW_cfg_nnets" and numerically as:
01 02 01
has an integer value that represents the number of logical network
interfaces afforded by the configuration of the gateway.
6.4. Network Interface Variables
This section describes a related set of variables that represent
attributes of the logical network interfaces afforded by the gateway
configuration. Each such network interface is uniquely identified by
an octet string. The convention by which names are assigned to the
network interfaces of a gateway is implementation-specific.
6.4.1. The _GW_net_if_type Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_type" and numerically as:
01 03 01 03
has an integer value that represents the type of the network
interface identified by the remainder of the name for said variable.
The value of a variable of this class represents network type
according to the conventions described in Appendix 1.
6.4.2. The _GW_net_if_speed Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_speed" and numerically as:
01 03 01 04
has an integer value that represents the estimated nominal bandwidth
in bits per second of the network interface identified by the
remainder of the name for said variable.
6.4.3. The _GW_net_if_in_pkts Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_in_pkts" and numerically as:
01 03 01 01 01
has an integer value that represents the number of packets received
by the gateway over the network interface identified by the remainder
of the name for said variable.
6.4.4. The _GW_net_if_out_pkts Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_out_pkts" and numerically as:
01 03 01 02 01
has an integer value that represents the number of packets
transmitted by the gateway over the network interface identified by
the remainder of the name for said variable.
6.4.5. The _GW_net_if_in_bytes Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_in_bytes" and numerically as:
01 03 01 01 02
has an integer value that represents the number of octets received by
the gateway over the network interface identified by the remainder of
the name for said variable.
6.4.6. The _GW_net_if_out_bytes Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_out_bytes" and numerically as:
01 03 01 02 02
has an integer value that represents the number of octets transmitted
by the gateway over the network interface identified by the remainder
of the name for said variable.
6.4.7. The _GW_net_if_in_errors Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_in_errors" and numerically as:
01 03 01 01 03
has an integer value that represents the number of reception errors
encountered by the gateway on the network interface identified by the
remainder of the name for said variable. The definition of a
reception error is implementation-specific and may vary according to
network type.
6.4.8. The _GW_net_if_out_errors Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_out_errors" and numerically as:
01 03 01 02 03
has an integer value that represents the number of transmission
errors encountered by the gateway on the network interface identified
by the remainder of the name for said variable. The definition of a
transmission error is implementation-specific and may vary according
to network type.
6.4.9. The _GW_net_if_status Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_status" and numerically as:
01 03 01 05
has an integer value that represents the current status of the
network interface identified by the remainder of the name for said
variable. Network status is represented according to the conventions
described in Appendix 2.
6.5. Internet Protocol Variables
This section describes variables that represent information related
to protocols and mechanisms of the Internet Protocol (IP) family [3].
6.5.1. Protocol Address Variable Classes
This section describes a related set of variables that represent
attributes of the the IP interfaces presented by a gateway on the
various networks to which it is attached. Each such protocol
interface is uniquely identified by an octet string. The convention
by which names are assigned to the protocol interfaces for a gateway
is implementation-specific.
6.5.1.1. The _GW_pr_in_addr_value Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_addr_value" and numerically as:
01 04 01 01 01
has an octet string value that literally represents the 32-bit
Internet address for the IP interface identified by the remainder of
the name for said variable.
6.5.1.2. The _GW_pr_in_addr_scope Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_addr_scope" and numerically as:
01 04 01 01 02
has an octet string value that names the network interface with which
the IP interface identified by the remainder of the name for said
variable is associated.
6.5.2. Exterior Gateway Protocol (EGP) Variables
This section describes variables that represent information related
to protocols and mechanisms of the EGP protocol [4].
6.5.2.1. The _GW_pr_in_egp_core Variable
A variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_egp_core" and numerically as:
01 04 01 03 01
has an integer value that characterizes the associated gateway with
respect to the set of INTERNET core gateways. A nonzero value
indicates that the associated gateway is part of the INTERNET core.
6.5.2.2. The _GW_pr_in_egp_as Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_egp_as" and numerically as:
01 04 01 03 02
has an integer value that literally identifies an Autonomous System
to which this gateway belongs.
6.5.2.3. The EGP Neighbor Variable Classes
This section describes a related set of variables that represent
attributes of "neighbors" with which the gateway may be associated by
EGP. Each such EGP neighbor is uniquely identified by an octet
string. The convention by which names are assigned to EGP neighbors
of a gateway is implementation-specific.
6.5.2.3.1. The _GW_pr_in_egp_neighbor_addr Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_egp_neighbor_addr" and numerically as:
01 04 01 03 03 01
has an octet string value that literally represents the 32-bit
Internet address for the EGP neighbor identified by the remainder of
the name for said variable.
6.5.2.3.2. The _GW_pr_in_egp_neighbor_state Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_egp_neighbor_state" and numerically as:
01 04 01 03 03 02
has an octet string value that represents the EGP protocol state of
the gateway with respect to the EGP neighbor identified by the
remainder of the name for said variable. The meaningful values for
such a variable are: "IDLE," "ACQUISITION," "DOWN," "UP," and
"CEASE."
6.5.2.4. The _GW_pr_in_egp_errors Variable
The variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_egp_errors" and numerically as:
01 04 01 03 05
has an integer value that represents the number of EGP protocol
errors.
6.5.3. Routing Variable Classes
This section describes a related set of variables that represent
attributes of the the IP routes by which a gateway directs packets to
various destinations on the Internet. Each such route is uniquely
identified by an octet string that is the concatenation of the
literal 32-bit value of the Internet address for the destination of
said route together with an implementation-specific octet string.
The convention by which names are assigned to the Internet routes for
a gateway is in all other respects implementation-specific.
6.5.3.1. The _GW_pr_in_rt_gateway Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_rt_gateway" and numerically as:
01 04 01 02 01
has an octet string value that literally represents the 32-bit
Internet address of the next gateway to which traffic is directed by
the route identified by the remainder of the name for said variable.
6.5.3.2. The _GW_pr_in_rt_type Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_rt_type" and numerically as:
01 04 01 02 02
has an integer value that represents the type of the route identified
by the remainder of the name for said variable. Route types are
identified according to the conventions described in Appendix 3.
6.5.3.3. The _GW_pr_in_rt_how-learned Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_rt_how-learned" and numerically as:
01 04 01 02 03
has an octet string value that represents the source of the
information from which the route identified by the remainder of the
name for said variable is generated. The meaningful values of such a
variable are: "STATIC," "EGP," and "RIP."
6.5.3.4. The _GW_pr_in_rt_metric0 Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_rt_metric0" and numerically as:
01 04 01 02 04
has an integer value that represents the quality (in terms of cost,
distance from the ultimate destination, or other metric) of the route
identified by the remainder of the name for said variable.
6.5.3.5. The _GW_pr_in_rt_metric1 Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_rt_metric1" and numerically as:
01 04 01 02 05
has an integer value that represents the quality (in terms of cost,
distance from the ultimate destination, or other metric) of the route
identified by the remainder of the name for said variable.
6.6. DECnet Protocol Variables
This section describes variables that represent information related
to protocols and mechanisms of the DEC Digital Network Architecture.
DEC and DECnet are registered trademarks of Digital Equipment
Corporation.
6.7. XNS Protocol Variables
This section describes variables that represent information related
to protocols and mechanisms of the Xerox Network System. Xerox
Network System and XNS are registered trademarks of the XEROX
Corporation.
7. Implementation-Specific Variables
Additional variables that may be presented for inspection or
manipulation by particular protocol entity implementations are
described in Appendices to 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
Numeric representations for various types of networks are presented
below:
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 StarLAN
10. Appendix 2: Network Status Representation
Numeric representations for network status are presented below.
Value Network Status
======================
0 Interface Operating Normally
1 Interface Not Present
2 Interface Disabled
3 Interface Down
4 Interface Attempting Link
11. Appendix 3: Route Type Representation
Numeric representations for route types are presented below.
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-Network
12. Appendix 4: Initial Implementation Strategy
The initial objective of implementing the protocol specified in this
document is to provide a mechanism for monitoring Internet gateways.
While the protocol design makes some provision for gateway management
functions as well, this aspect of the design is not fully developed
and needs further refinement before a generally useful implementation
could be produced. Accordingly, initial implementations will not
generate or respond to the optional Set Request message type.
The protocol defined here may be subsequently refined based upon
experience with early implementations or upon further study of the
problem of gateway management. Moreover, it may be superceded by
other proposals in the area of gateway monitoring and control.
Implementations of the authentication protocol specified in this
document are likely to evolve in response to the particular security
and privacy needs of its users. While, in general, the association
between particular half-sessions of the authentication protocol and
the described triplets of functions is specific to an implementation
and beyond the scope of this document, the desire for immediate
interoperability among initial implementations of this protocol is
best served by the temporary adoption of a common authentication
scheme. Accordingly, initial implementations will associate with
every possible half-session a triplet of functions that realizes a
trivial authentication mechanism:
(1) The authentication function is defined to have the value
TRUE over the entire domain of authentication protocol
messages.
(2) The message interpretation function is defined to be the
identity function.
(3) The message representation function is defined to be the
identity function.
Because this initial posture with respect to authentication is not
likely to remain acceptable indefinitely, implementors are urged to
adopt designs that isolate authentication mechanism as much as
possible from other components of the implementation.
13. Appendix 5: Routing Information Propagation Variables
This section describes a set of related variables that characterize
the sources and destinations of routing information propagated by
various routing protocols. These variables have meaning only for
those routing protocol implementations that afford greater
flexibility in propagating routing information than is required by
the various routing protocol specifications.
Each IP interface afforded by the configuration of the gateway over
which routing information may propagate via a routing protocol
(target interface) is named by a string of four octets that literally
represents the IP address associated with said protocol interface.
Each IP protocol interface afforded by the configuration of the
gateway over which routing information may arrive via any routing
protocol (source interface) is named by a string of four octets that
literally represents the IP address associated with said protocol
interface.
Each routing protocol by which a gateway receives information that it
uses to route IP traffic (source routing protocol) is named by a
single-octet string according to the conventions set forth in
Appendix 6 of this document.
Each routing protocol by which a gateway propagates routing
information used by other hosts or gateways to route IP traffic
(target routing protocol) is named by a single-octet string according
to the conventions set forth in Appendix 6 of this document.
A variable such that the initial portion of its name is the
concatenation of:
(1) the octet string represented symbolically as "_GW_pr_in_rif"
and numerically as 01 04 01 04 followed by:
(2) the name of a target routing protocol followed by
(3) the name of a target interface followed by
(4) the name of a source routing protocol followed by
(5) the name of a source interface
has an integer value that characterizes the propagation of routing
information between the sources and destinations of such information
that are identified by the initial portion of that variable's name. A
non-zero value for such a variable indicates that routing information
received via the source routing protocol named by the fourth
component of the variable name on the source interface named by its
fifth component is propagated via the target routing protocol named
by the second component of the variable name over the target
interface named by its third component. A zero value for such a
variable indicates that routing information received via the source
routing protocol on the source interface identified in the variable
name is NOT propagated via the target routing protocol over the
target interface identified in the variable name.
14. Appendix 6: Routing Protocol Representation
Numeric representations for routing protocols are presented below.
Value Routing Protocol
========================
0 None -- Reserved
1 Berkeley RIP Version 1
2 EGP
3 GGP
4 Hello
5 Other IGRP
15. Appendix 7: Proteon p4200 Release 7.4 Variables
This section describes implementation-specific variables presented by
the implementation of this protocol in Software Release 7.4 for the
Proteon p4200 Internet Router. These variable definitions are
subject to change without notice.
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 such network interface is uniquely named by an
implementation-specific octet string of length 1.
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 01
followed by the name of said network interface as described above.
15.1.1.1. The Generic _ovfl-in Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a generic network interface followed by
the octet string represented symbolically as "_ovfl-in" and
numerically as 01, has an integer value that represents the number of
input packets dropped due to gateway congestion for the network
interface identified by the initial portion of its name.
15.1.1.2. The Generic _ovfl-out Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a generic network interface followed by
the octet string represented symbolically as "_ovfl-out" and
numerically as 02, has an integer value that represents the number of
output packets dropped due to gateway congestion for the network
interface identified by the initial portion of its name.
15.1.1.3. The Generic _slftst-pass Variable Class A variable
such that the initial portion of its name is the concatenation of the
name for a generic network interface followed by the octet string
represented symbolically as "_slftst-pass" and numerically as 03, has
an integer value that represents the number of times the interface
self-test procedure succeeded for the network interface identified by
the initial portion of its name.
15.1.1.4. The Generic _slftst-fail Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a generic network interface followed by
the octet string represented symbolically as "_slftst-fail" and
numerically as 04, has an integer value that represents the number of
times the interface self-test procedure failed for the network
interface identified by the initial portion of its name.
15.1.1.5. The Generic _maint-fail Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a generic network interface followed by
the octet string represented symbolically as "_maint-fail" and
numerically as 06, has an integer value that represents the number of
times the network maintenance procedure failed for the network
interface identified by the initial portion of its name.
15.1.1.6. The Generic _csr Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a generic network interface followed by
the octet string represented symbolically as "_csr" and numerically
as 07, has an integer value that represents the internal address of
the device CSR for the network interface identified by the initial
portion of its name.
15.1.1.7. The Generic _vec Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a generic network interface followed by
the octet string represented symbolically as "_vec" and numerically
as 08, has an integer value that identifies the device interrupt
vector used by the network interface identified by the initial
portion of its name.
15.1.2. The ProNET Network Interface Variables
This section describes a related set of variables that represent
attributes of a ProNET type network interface in the Proteon p4200
Internet Router gateway. Each network interface of a p4200
configuration that supports ProNET media is uniquely named by the
concatenation of the octet string represented symbolically as
"_GW_impl_Proteon_p4200-R7.4_devpn" and numerically as:
01 FF 01 01 04
followed by the name of said network interface as described above.
15.1.2.1. The ProNET _node-number Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a ProNET type network interface
followed by the octet string represented symbolically as "_node-
number" and numerically as 01, has an integer value that represents
the ProNET node number associated with the network interface
identified by the initial portion of its name.
15.1.2.2. The ProNET _in-data-present Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a ProNET type network interface
followed by the octet string represented symbolically as "_in-data-
present" and numerically as 02, has an integer value that represents
the number of times that unread data was present in the input packet
buffer for the network interface dentified by the initial portion of
its name.
15.1.2.3. The ProNET _in-overrun Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a ProNET type network interface
followed by the octet string represented symbolically as "_in-
overrun" and numerically as 03, has an integer value that represents
the number of times that a packet copied from the ring exceeded the
size of the packet input buffer on the network interface identified
by the initial portion of its name.
15.1.2.4. The ProNET _in-odd-byte-cnt Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a ProNET type network interface
followed by the octet string represented symbolically as "_in-odd-
byte-cnt" and numerically as 04, has an integer value that represents
the number of times that a packet was received with an odd number of
bytes on the network interface identified by the initial portion of
its name.
15.1.2.5. The ProNET _in-parity-error Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a ProNET type network interface
followed by the octet string represented symbolically as "_in-
parity-error" and numerically as 05, has an integer value that
represents the number of times that a parity error was detected in a
packet copied from the ring on the network interface identified by
the initial portion of its name.
15.1.2.6. The ProNET _in-bad-format Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a ProNET type network interface
followed by the octet string represented symbolically as "_in-bad-
format" and numerically as 06, has an integer value that represents
the number of times that a format error was detected in a packet
copied from the ring on the network interface identified by the
initial portion of its name.
15.1.2.7. The ProNET _not-in-ring Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a ProNET type network interface
followed by the octet string represented symbolically as "_not-in-
ring" and numerically as 07, has an integer value that represents the
number of times that the ProNET wire center relays were detected in
an unenergized state for the network interface identified by the
initial portion of its name.
15.1.2.8. The ProNET _out-ring-inits Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a ProNET type network interface
followed by the octet string represented symbolically as "_out-ring-
inits" and numerically as 08, has an integer value that represents
the number of times that ring initialization has been attempted on
the network interface identified by the initial portion of its name.
15.1.2.9. The ProNET _out-bad-format Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a ProNET type network interface
followed by the octet string represented symbolically as "_out-bad-
format" and numerically as 09, has an integer value that represents
the number of times that an improperly formatted packet was detected
in the course of an output operation on the network interface
identified by the initial portion of its name.
15.1.2.10. The ProNET _out-timeout Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a ProNET type network interface
followed by the octet string represented symbolically as "_out-
timeout" and numerically as 0A, has an integer value that represents
the number of times that an attempt to originate a message has been
delayed by more than 700 ms on the network interface identified by
the initial portion of its name.
15.1.3. The Ethernet Network Interface Variables
This section describes a related set of variables that represent
attributes of an Ethernet type network interface in the Proteon p4200
Internet Router gateway. Each network interface of a p4200
configuration that supports Ethernet media is uniquely named by the
concatenation of the octet string represented symbolically as
"_GW_impl_Proteon_p4200-R7.4_dev-ie" and numerically as:
01 FF 01 01 03
followed by the name of said network interface as described above.
15.1.3.1. The Ethernet _phys-addr Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for an Ethernet type network interface
followed by the octet string represented symbolically as "_phys-addr"
and numerically as 01 has an octet string value that literally
represents the Ethernet station address associated with the network
interface identified by the initial portion of its name.
15.1.3.2. The Ethernet _input-ovfl Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for an Ethernet type network interface
followed by the octet string represented symbolically as "_input-
ovfl" and numerically as 02, has an integer value that represents the
number of times the size of a received frame exceeded the maximum
allowable for the network interface identified by the initial portion
of its name.
15.1.3.3. The Ethernet _input-dropped Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for an Ethernet type network interface
followed by the octet string represented0 symbolically as "_input-
dropped" and numerically as 03, has an integer value that represents
the number of times the loss of one or more frames was detected on
the network interface identified by the initial portion of its name.
15.1.3.4. The Ethernet _output-retry Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for an Ethernet type network interface
followed by the octet string represented symbolically as "_output-
retry" and numerically as 04, has an integer value that represents
the number of output operations retried as the result of a
transmission failure on the network interface identified by the
initial portion of its name.
15.1.3.5. The Ethernet _output-fail Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for an Ethernet type network interface
followed by the octet string represented symbolically as "_output-
fail" and numerically as 05, has an integer value that represents the
number of failed output operations detected on the network interface
identified by the initial portion of its name.
15.1.3.6. The Ethernet _excess-coll Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for an Ethernet type network interface
followed by the octet string represented symbolically as "_excess-
coll" and numerically as 06, has an integer value that represents the
number of times a transmit frame incurred 16 successive collisions
when attempting media access via the network interface identified by
the initial portion of its name.
15.1.3.7. The Ethernet _frag-rcvd Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for an Ethernet type network interface
followed by the octet string represented symbolically as "_frag-rcvd"
and numerically as 07, has an integer value that represents the
number of collision fragments (i.e., "runt packets") that were
received and filtered by the controller for the network interface
identified by the initial portion of its name.
15.1.3.8. The Ethernet _frames-lost Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for an Ethernet type network interface
followed by the octet string represented symbolically as "_frames-
lost" and numerically as 08, has an integer value that represents the
number of frames not accepted by the Receive FIFO due to insufficient
space for the network interface identified by the initial portion of
its name.
15.1.3.9. The Ethernet _multicst-accept Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for an Ethernet type network interface
followed by the octet string represented symbolically as "_multicst-
accept" and numerically as 09, has an integer value that represents
the number of frames received with a multicast-group destination
address that matches one of those assigned to the controller for the
network interface identified by the initial portion of said variable
name.
15.1.3.10. The Ethernet _multicst-reject Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for an Ethernet type network interface
followed by the octet string represented symbolically as "_multicst-
reject" and numerically as 0A, has an integer value that represents
the number of frames detected as having a multicast-group destination
address that matches none of those assigned to the controller for the
network interface identified by the initial portion of said variable
name.
15.1.3.11. The Ethernet _crc-error Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for an Ethernet type network interface
followed by the octet string represented symbolically as "_crc-error"
and numerically as 0B, has an integer value that represents the
number of frames received with a CRC error on the network interface
identified by the initial portion of its name.
15.1.3.12. The Ethernet _alignmnt-error Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for an Ethernet type network interface
followed by the octet string represented symbolically as "_alignmnt-
error" and numerically as 0C, has an integer value that represents
the number of frames received with an alignment error on the network
interface identified by the initial portion of its name. A received
frame is said to have an alignment error if its received length is
not an integral multiple of 8 bits.
15.1.3.13. The Ethernet _collisions Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for an Ethernet type network interface
followed by the octet string represented symbolically as
"_collisions" and numerically as 0D, has an integer value that
represents the number of collisions incurred during transmissions on
the network interface identified by the initial portion of its name.
15.1.3.14. The Ethernet _out-of-window-coll Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for an Ethernet type network interface
followed by the octet string represented symbolically as "_out-of-
window-coll" and numerically as 0E, has an integer value that
represents the number of out-ofwindow collisions incurred during
transmissions on the network interface identified by the initial
portion of its name. Outof-window collisions are those occurring
after the first 51.2 microseconds of slot time.
15.1.4. The Serial Network Interface Variables
This section describes a related set of variables that represent
attributes of an serial line type network interface in the Proteon
p4200 Internet Router gateway. Each network interface of a p4200
configuration that supports serial communications is uniquely named
by the concatenation of the octet string represented symbolically as
"_GW_impl_Proteon_p4200-R7.4_dev-sl" and numerically as:
01 FF 01 01 05
followed by the name of said network interface as described above.
15.1.4.1. The Serial _tx-pkts Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a serial line type network interface
followed by the octet string represented symbolically as "_tx-pkts"
and numerically as 01, has an integer value that represents the
number of packets transmitted on the network interface identified by
the initial portion of its name.
15.1.4.2. The Serial _tx-framing-error Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a serial line type network interface
followed by the octet string represented symbolically as "_tx-
framing-error" and numerically as 02, has an integer value that
represents the number of transmission framing errors for the network
interface identified by the initial portion of its name.
15.1.4.3. The Serial _tx-underrns Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a serial line type network interface
followed by the octet string represented symbolically as "_tx-
underrns" and numerically as 03, has an integer value that represents
the number of transmission underrun errors for the network interface
identified by the initial portion of its name.
15.1.4.4. The Serial _tx-no-dcd Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a serial line type network interface
followed by the octet string represented symbolically as "_tx-no-dcd"
and numerically as 04, has an integer value that represents the
number of times transmission failed due to absence of the EIA Data
Carrier Detect signal on the network interface identified by the
initial portion of its name.
15.1.4.5. The Serial _tx-no-cts Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a serial line type network interface
followed by the octet string represented symbolically as "_tx-no-cts"
and numerically as 05, has an integer value that represents the
number of times transmission failed due to absence of the EIA Clear
To Send signal on the network interface identified by the initial
portion of its name.
15.1.4.6. The Serial _tx-no-dsr Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a serial line type network interface
followed by the octet string represented symbolically as "_tx-no-dsr"
and numerically as 06, has an integer value that represents the
number of times transmission failed due to absence of the EIA Data
Set Ready signal on the network interface identified by the initial
portion of its name.
15.1.4.7. The Serial _rx-pkts Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a serial line type network interface
followed by the octet string represented symbolically as "_rx-pkts"
and numerically as 07, has an integer value that represents the
number of packets received on the network interface identified by the
initial portion of its name.
15.1.4.8. The Serial _rx-framing-err Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a serial line type network interface
followed by the octet string represented symbolically as "_rx-
framing-err" and numerically as 08, has an integer value that
represents the number of receive framing errors on the network
interface identified by the initial portion of its name.
15.1.4.9. The Serial _rx-overrns Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a serial line type network interface
followed by the octet string represented symbolically as "_rx-
overrns" and numerically as 09, has an integer value that represents
the number of receive overrun errors on the network interface
identified by the initial portion of its name.
15.1.4.10. The Serial _rx-aborts Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a serial line type network interface
followed by the octet string represented symbolically as "_rx-aborts"
and numerically as 0A, has an integer value that represents the
number of aborted frames received on the network interface identified
by the initial portion of its name.
15.1.4.11. The Serial _rx-crc-err Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a serial line type network interface
followed by the octet string represented symbolically as "_rx-crc-
err" and numerically as 0B, has an integer value that represents the
number of frames received with CRC errors on the network interface
identified by the initial portion of its name.
15.1.4.12. The Serial _rx-buf-ovfl Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a serial line type network interface
followed by the octet string represented symbolically as "_rx-buf-
ovfl" and numerically as 0C, has an integer value that represents the
number of received frames whose size exceeded the maximum allowable
on the network interface identified by the initial portion of its
name.
15.1.4.13. The Serial _rx-buf-locked Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a serial line type network interface
followed by the octet string represented symbolically as "_rx-buf-
locked" and numerically as 0D, has an integer value that represents
the number of received frames lost for lack of an available buffer on
the network interface identified by the initial portion of its name.
15.1.4.14. The Serial _rx-line-speed Variable Class
A variable such that the initial portion of its name is the
concatenation of the name for a serial line type network interface
followed by the octet string represented symbolically as "_rx-line-
speed" and numerically as 0E, has an integer value that represents an
estimate of serial line bandwidth in bits per second for the network
interface identified by the initial portion of its name.
ISO Plain Language
On this page
PROBLEMGateways needed to be monitored, and the monitoring had to be built into the gateway itself. Every new management command added to the gateway meant more software to write, test and get right.
MECHANISMThe protocol models all gateway management as reading or writing named parameter values, so the gateway implements only two operations. The variables are named by octet strings, hold only integers or octet strings, and are exchanged as four message types written in the CCITT X.409 encoding, carried over UDP inside an authentication session.
WHY IT FADEDRFC 1028 is Historic and the RFC Editor recommends it for no further use. The memo describes itself as an interim answer to immediate gateway monitoring needs, and says that long term use of the mechanisms it describes should be seriously questioned as more comprehensive proposals emerge.
§1An Interim Answer to Gateway Monitoring
The memo is distributed to members of the Internet community in order to solicit reactions to the proposals it contains. It says that while the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementors.
It defines a simple application-layer protocol by which management information for a gateway may be inspected or altered by logically remote users. The proposal is intended only as an interim response to immediate gateway monitoring needs while work on more elaborate and robust designs proceeds with the care and deliberation appropriate to that task. Accordingly, long term use of the mechanisms described in the memo should be seriously questioned as more comprehensive proposals emerge in the future.
The authors are explicit that this is a stopgap. Gateways needed monitoring straight away, and a full management design was going to take time, so this memo offers something small enough to build now and says plainly that it should not be relied on for long.
§2The Design Decisions
The protocol is shaped by the desire to minimise the number and complexity of management functions the gateway itself realises. The memo argues this in four ways: the development cost of gateway software is reduced; the amount of management function that can be supported remotely is increased, admitting the fullest use of Internet resources in the management task and imposing the fewest possible restrictions on the form and sophistication of management tools; and a simplified set of management functions is easily understood and used by developers of gateway management tools. A second goal is that the paradigm for monitoring and control be sufficiently extensible to accommodate additional, possibly unanticipated aspects of gateway operation. A third goal is that the design be, as much as possible, independent of the architecture and mechanisms of particular hosts or particular gateways.
Eight decisions follow from those goals. First, all gateway management functions are modelled as alterations or inspections of parameter values, so that a protocol entity on a logically remote host interacts with a protocol entity resident on the gateway to alter or retrieve named portions of the gateway state. This limits the essential management functions on the gateway to two, one to assign a value to a configuration parameter and one to retrieve such a value, and it avoids support for imperative management commands, whose number grows and whose semantics are arbitrarily complex. An imperative command can still be accommodated, by making it the setting of a parameter value that subsequently triggers the desired action.
Second, any needed authentication functionality is realised in a distinct protocol layer that provides services to the monitoring protocol itself, which reduces the complexity of the individual layers and eases implementation. Third, the identity of an application protocol entity is known to its peers only by the services of the underlying authentication protocol, which implies a model of access control where access to gateway variables is managed in terms of the association between application entities and authentication sessions. Multi-level access is then supported by multiple instances of the application protocol entity, each characterised by the set of gateway variables it knows, the mode of access, READ-ONLY or READ-WRITE, afforded to that set, and the authentication protocol session it belongs to.
Fourth, the conventions of the CCITT X.409 recommendation are adopted for representing the information exchanged between protocol entities. The cost is a modest increase in implementation complexity; the benefit is that protocol data are represented on the network in a machine-independent, widely understood and widely accepted form, and that the form of the messages can be concisely described in the X.409 language.
Fifth, the variables manipulated by the protocol assume only integer or octet string type values. Sixth, the exchange of protocol messages requires only an unreliable datagram transport, and every protocol message is entirely and independently representable by a single transport datagram. The memo specifies the exchange via UDP but notes that the design is in general suitable for a wide variety of transport mechanisms. Seventh, the variables are named by octet string values. This departs from the architectural traditions of the Internet, where objects are identified by assigned integer values, but the octet string name space can manifest flat or hierarchical structure, so a single simple mechanism can provide both random access to individual variables and sequential access to semantically related groups, and the name space can be extended to accommodate unforeseen needs without compromising the relationships among existing variables. Eighth, the number of unsolicited messages is minimised, so that the monitoring of network state is accomplished primarily by polling from the monitoring centre, and the definition of unsolicited messages is confined to those strictly necessary to guide the monitoring centre about the timing and focus of its polling.
The central decision is that nothing about a router is controlled by a command. A command would need new code in the router every time one was invented, and its behaviour would have to be defined. Instead everything is a setting with a name and a value, and the router only ever reads or writes settings. The other decisions follow from that: authentication is kept in its own layer so the monitoring code stays small, values are only numbers or strings, names are strings so they can be grouped and extended, and the router almost never sends anything unasked for, because the monitoring centre does the asking.
- Variables, not commandsThe gateway only reads and writes named values.
- Authentication in its own layerKeeps the monitoring code simple.
- Identity from the authentication layerAccess rights follow the authenticated session.
- CCITT X.409 encodingMachine-independent, widely understood message format.
- Integers and octet strings onlyTwo value types, so little to implement.
- Unreliable datagram transportEach message fits in one datagram; no resending.
- Octet string variable namesNames can be grouped and extended without renumbering.
- Few unsolicited messagesThe monitoring centre polls; the router mostly stays quiet.
§3The Four Message Types
Communication among application protocol entities is by the exchange of protocol messages using the services of the authentication protocol, and each such message is entirely and independently represented by a single message of that protocol. An implementation need not accept protocol messages whose length exceeds 484 octets. The type of a protocol message is indicated by the value of the implicit type tag for the data structure it represents, according to the conventions of CCITT X.409.
Four message types are recognised. The Get Request carries a request identifier, an error status, an error index and a list of variable operations, each of which pairs a variable name with a value. On receipt, if the name in some variable operation does not lexicographically precede the name of some variable known to the receiving entity, the reply is a Get Response with the error status set to gmp_err_nix_name and the error index set to the unit-based index of that component. If the Get Response would exceed the largest message the protocol definition requires to be accepted, the reply carries gmp_err_too_big and an error index of zero. Otherwise the reply is a Get Response whose components give the name and value of the variable that immediately succeeds the requested name in the lexicographic ordering of all variable names known to the receiving entity, with the error status gmp_err_noerror and the error index zero, and the same request identifier as the request. Get Request messages are generated only at the request of the application user.
The Get Response has the same form as the Get Request, differing only in the indication of message type, and the response of a protocol entity to it is to present its contents to the application user. Get Response messages are generated only upon receipt of Set Request or Get Request messages.
The Trap Request carries a trap type and a list of values whose significance is implementation-specific. Interpretations for negative trap types are implementation-specific, while five non-negative values are defined: 0, the cold start trap, means the sending entity is reinitialising itself in a way that may alter the gateway configuration or the protocol entity implementation; 1, the warm start trap, means it is reinitialising itself in a way that alters neither; 2, the link failure trap, means it recognises a failure in one of the communication links represented in the gateway configuration; 3, the authentication failure trap, means it is the addressee of a protocol message that is not properly authenticated; and 4, the EGP neighbour loss trap, means an EGP neighbour for whom it was a peer has been marked down and the peer relationship no longer obtains.
The Set Request has the same form as the Get Request, differing only in the message type. On receipt, if the name in some variable operation names no variable known to the receiving entity, the reply is a Get Response with the error status gmp_err_nix_name and the error index of that component. If the contents of the value field do not, according to CCITT X.409, manifest a type, length and value consistent with that required for the named variable, the reply carries gmp_err_bad_value and the error index of that component. If the response would exceed the largest message the protocol requires to be accepted, the reply carries gmp_err_too_big and an error index of zero. Otherwise each value is assigned to the variable named in the matching component, in the order the components appear, and the reply is a Get Response with gmp_err_noerror and an error index of zero. Recognition and processing of Set Request messages is not required by the protocol definition.
There are four kinds of message: ask for a variable, the answer to that ask, a change to a variable, and an unsolicited notice from the router. Errors are reported in the reply itself, with a status code and the position in the request that caused it. The router is allowed to ignore change requests altogether, since the memo says the protocol does not require them.
- APPLICATION 1Get Request — Asks for the values of one or more variables, or for the variable that follows a given name.
- APPLICATION 2Get Response — The answer to a Get Request or a Set Request, carrying the error status and the values.
- APPLICATION 3Trap Request — An unsolicited notice from the gateway, such as a cold start or a link failure.
- APPLICATION 4Set Request — Asks the gateway to change the value of a variable. Processing these is not required.
§4The Authentication Protocol
The authentication protocol is a session-layer protocol by which messages specified by a protocol user are selectively delivered to other protocol users. The protocol definition precludes delivery to a protocol user of any user message for which the protocol representation lacks a specified authentic form. Communication among authentication protocol entities is accomplished by the exchange of protocol messages, each of which is entirely and independently represented by a single UDP datagram. An authentication protocol entity responds to protocol messages received at UDP port 153 on the host with which it is associated.
A half-session of the authentication protocol is, for any ordered pair of protocol users, the set of messages sent from the first user of the pair to the second. A session is the union of two complementary half-sessions, the set of messages exchanged between a given pair of protocol users. Each half-session is associated with a triplet of functions. The authentication function for a half-session is a boolean-valued function that characterises the set of authentication protocol messages that are of acceptable, authentic form. The message interpretation function maps the messages accepted by the authentication function to the set of all possible user messages. The message representation function is the inverse of the message interpretation function. The association between half-sessions and triplets of functions is not defined in the memo.
One message type is recognised, the Data Request, made up of four fields. The Message Length field gives the length of the message as an unsigned 16-bit binary integer, encoded so that more significant bits precede less significant bits in the order of transmission, and it includes the length of the Message Length field itself. The Session ID Length field gives the length in octets of the Session ID field, as an unsigned 8-bit binary integer. The Session ID field names the protocol session to which the message belongs, encoded as a sequence of octets of that length. The User Data field carries the message being passed from one protocol user to another, encoded according to the conventions implicit in the message representation function for the appropriate half of the session named by the Session ID field.
On receipt, the receiving authentication protocol entity verifies the form of the message by applying the authentication function associated with its half of the named session. If the form is accepted as authentic, the user message computed by applying the message interpretation function is presented to the protocol user together with an indication of the session it belongs to. Otherwise the message is discarded and an indication of the receipt of an unauthenticated message is presented to the protocol user.
Every monitoring message is wrapped in an authentication session, which is a separate layer that decides whether a message is genuine before passing it on. Each session has a name, and each direction of a session has its own rule for what a valid message looks like and how to interpret it. The wrapper travels as one UDP datagram to port 153 on the host.
- Monitoring applicationReads and writes gateway variables
- Gateway monitoring protocolGet Request, Get Response, Trap Request, Set Request
- Authentication protocolSession layer that checks each message
- UDPOne datagram per message, to port 153
§5Variable Names and Required Variables
The variables retrieved or manipulated by the application protocol are named by octet string values. A name may be represented numerically as a sequence of hexadecimal numbers, each denoting the value of the corresponding octet, or symbolically as a character string whose form reflects the sequence of octets while suggesting the semantics of the named variable. The symbolic form of the name of zero length is the character string of zero length, and the symbolic form of a name of non-zero length n is the concatenation of the symbolic form of the name formed by the first n-1 octets with the underscore character and a string that does not include the underscore, so that the result is unique among the symbolic representations for all names of length n.
So the 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 02 might be represented 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. All variable names are terminated by an implementation specific octet string of non-zero length, so a complete variable name is not specified for any of the variables defined in the memo; for each defined variable some prefix portion of its name is specified, with the understanding that the rightmost portion is specific to the protocol implementation.
Fullest exploitation of the semantics of the Get Request message requires that names for related variables be chosen so as to be contiguous in the lexicographic ordering of all variable names, so that one request can walk through a group of them. An implementation may present variables in addition to those defined in the memo, provided no implementation-specific variable is presented as having the name of one defined here. By convention the names of implementation-specific variables share a common prefix that distinguishes them from those defined in the memo and from those of other implementations; the memo gives the example of variables specific to version 1.3 of the Squeaky gateway product of the Swinging Gateway company, named 01 FF 01 01 13 01, 01 FF 01 01 13 02 and 01 FF 01 01 13 03. Names beginning 02, symbolically _HOST, and names beginning 03, symbolically _TS, are reserved for future use.
Where the information represented by a variable defined in the memo is also represented internally by a gateway, access to that variable must be afforded by at least one application protocol entity associated with the gateway. The required variables are _GW_version_id, an octet string value identifying the protocol entity implementation; _GW_version_rev, an integer identifying the revision level of that implementation; and _GW_cfg_nnets, an integer giving the number of logical network interfaces afforded by the configuration of the gateway. Each network interface is uniquely identified by an octet string, and the convention for naming them is implementation-specific. For each interface there are classes of variable: _GW_net_if_type, an integer giving the type of the interface, _GW_net_if_speed, an integer giving the estimated nominal bandwidth in bits per second, _GW_net_if_in_pkts and _GW_net_if_out_pkts counting packets received and transmitted, _GW_net_if_in_bytes and _GW_net_if_out_bytes counting octets received and transmitted, _GW_net_if_in_errors and _GW_net_if_out_errors counting reception and transmission errors, and _GW_net_if_status, an integer giving the current status of the interface.
The memo also defines variables for the Internet Protocol interfaces of the gateway, for the Exterior Gateway Protocol, including a variable for the EGP neighbour state, and for routing information, and it adds interface-specific classes for Ethernet and for the serial lines of the Proteon p4200 Internet Router gateway.
Variable names are strings rather than numbers, and the strings are written so that related names sit next to each other in alphabetical order. That means one request can walk through a whole group of related settings, such as the packet counters for one interface, by asking for each name in turn. Each name is a prefix plus a part the implementation chooses, so vendors can add their own settings without colliding with the standard ones.
§6References
[1]CCITT Recommendation X.409, "Application Protocol for the Exchange of Fully-Structured Information"
[2]RFC 768Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, 28 August 1980.August 1980[3]RFC 791Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981.September 1981