As per Relevance of the word represent, we have this rfc below:
Network Working Group J.
Request for Comments: 1028 Proteon, Inc
J.
University of Tennessee at
M.
Cornell
M.
Rensselaer Polytechnic
November 1987
A Simple Gateway Monitoring
1. Status of this
This document is being distributed to members of the
community in order to solicit their reactions to the
contained in it. While the issues discussed may not be
relevant to the research problems of the Internet, they may
interesting to a number of researchers and implementors
This memo defines a simple application-layer protocol by
management information for a gateway may be inspected or altered
logically remote users
This proposal is intended only as an interim response to
gateway monitoring needs while work on more elaborate and
designs proceeds with the care and deliberation appropriate to
task. Accordingly, long term use of the mechanisms described
should be seriously questioned as more comprehensive proposals
in the future. Distribution of this memo is unlimited
2. Protocol Design
The proposed protocol is shaped in large part by the desire
minimize the number and complexity of management functions
by the gateway itself. This goal is attractive in at least
respects
(1) The development cost for gateway software necessary
support the protocol is accordingly reduced
(2) The degree of management function that is
supported is accordingly increased, thereby
fullest use of internet resources in the management task
Davin, Case, Fedor and Schoffstall [Page 1]
RFC 1028 Simple Gateway Monitoring November 1987
(3) The degree of management function that is
supported is accordingly increased, thereby imposing
fewest possible restrictions on the form and
of management tools
(4) A simplified set of management functions is
understood and used by developers of gateway
tools
A second design goal is that the functional paradigm for
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,
of the architecture and mechanisms of particular hosts or
gateways
Consistent with the foregoing design goals are a number of
regarding the overall form of the protocol design
One such decision is to model all gateway management functions
alterations or inspections of various parameter values. By
model, a protocol entity on a logically remote host (possibly
gateway itself) interacts with a protocol entity resident on
gateway in order to alter or retrieve named portions (variables)
the gateway state. This design decision has at least two
consequences
(1) It has the effect of limiting the number of
management functions realized by the gateway to two:
operation to assign a value to a specified
parameter and another to retrieve such a value
(2) A second effect of this decision is to avoid
into the protocol definition support for
management commands: the number of such commands is
practice ever-increasing, and the semantics of
commands are in general arbitrarily complex
The exclusion of imperative commands from the set of
supported management functions is unlikely to preclude any
gateway management operation. Currently, most gateway commands
requests either to set the value of some gateway parameter or
retrieve such a value, and the function of the few
commands currently supported is easily accommodated in
asynchronous mode by this management model. In this scheme,
imperative command might be realized as the setting of a
value that subsequently triggers the desired action
Davin, Case, Fedor and Schoffstall [Page 2]
RFC 1028 Simple Gateway Monitoring November 1987
A second design decision is to realize any needed
functionality in a distinct protocol layer that provides services
the monitoring protocol itself. The most important benefit of
decision is a reduction in the complexity of the individual
layers - thereby easing the task of implementation
Consistent with this layered design strategy is a third
decision that the identity of an application protocol entity is
to its peers only by the services of the underlying
protocol. Implicit in this decision is a model of access control
which access to variables of a gateway configuration is managed
terms of the association between application entities and sessions
the authentication protocol. Thus, multi-level access to
variables is supported by multiple instances of the
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
said set of variables,
(3) the authentication protocol session to which belong
messages sent and received by said entity
A fourth design decision is to adopt the conventions of the
X.409 recommendation [1] for representing the information
between protocol entities. One cost of this decision is a
increase in the complexity of the protocol implementation.
benefit of this decision is that protocol data are represented on
network in a machine-independent, widely understood, and
accepted form. A second benefit of this decision is that the form
the protocol messages may be concisely and understandably
in the X.409 language defined for such purposes
A fifth design decision, consistent with the goal of
gateway complexity, is that the variables manipulated by the
assume only integer or octet string type values
A sixth design decision, also consistent with the goal of
gateway complexity, is that the exchange of protocol
requires only an unreliable datagram transport, and, furthermore
that every protocol message is entirely and
representable by a single transport datagram. While this
specifies the exchange of protocol messages via the UDP protocol [2],
the design proposed here is in general suitable for use with a
variety of transport mechanisms
Davin, Case, Fedor and Schoffstall [Page 3]
RFC 1028 Simple Gateway Monitoring November 1987
A seventh design decision, consistent with the goals of
and extensibility, is that the variables manipulated by the
are named by octet string values. While this decision departs
the architectural traditions of the Internet whereby objects
identified by assigned integer values, the naming of variables
octet strings affords at least two valuable benefits. Because
set of octet string values constitutes a variable name space that,
convenient, manifests either flat or hierarchical structure
(1) a single, simple mechanism can provide both random
to individual variables and sequential access
semantically related groups of variables,
(2) the variable name space may be extended to
unforeseen needs without compromising either
relationships among existing variables or the
for further extensions to the space
An eighth design decision is to minimize the number of
messages required by the protocol definition. This decision
consistent with the goal of simplicity and motivated by the desire
retain maximal control over the amount of traffic generated by
network management function - even at the expense of
protocol overhead. The strategy implicit in this decision is
the monitoring of network state at any significant level of detail
accomplished primarily by polling for appropriate information on
part of the monitoring center. In this context, the definition
unsolicited messages in the protocol is confined to those
necessary to properly guide a monitoring center regarding the
and focus of its polling
3. The Gateway Monitoring
The gateway monitoring protocol is an application protocol by
the variables of a gateway's configuration may be inspected
altered
Communication among application protocol entities is by the
of protocol messages using the services of the
protocol described elsewhere in this document. Each such message
entirely and independently represented by a single message of
underlying authentication protocol. An implementation of
protocol need not accept protocol messages whose length exceeds 484
octets
The form and function of the four message types recognized by
protocol entity is described below. The type of a given
message is indicated by the value of the implicit type tag for
Davin, Case, Fedor and Schoffstall [Page 4]
RFC 1028 Simple Gateway Monitoring November 1987
data structure that is represented by said message according to
conventions of the CCITT X.409 recommendation
3.1. The Get Request Message
The form of a message of Get Request type is described below in
language defined in the CCITT X.409 recommendation
var_value_type ::= CHOICE {
INTEGER
OCTET
}
var_name_type := OCTET
var_op_type ::= SEQUENCE {
var_name var_name_type
var_value var_value_
}
var_op_list_type ::= SEQUENCE OF var_op_
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 ::=
request_id_type ::=
get_req_message_type ::= [ APPLICATION 1 ]
SEQUENCE {
request_id request_id_type
error_status error_status_type
error_index error_index_type
var_op_list var_op_list_
Davin, Case, Fedor and Schoffstall [Page 5]
RFC 1028 Simple Gateway Monitoring November 1987
}
Upon receipt of a message of this type, the receiving entity
according to any applicable rule in the list below
(1) If, for some var_op_type component of the received message,
value of the var_name field does not lexicographically
the name of some variable known to the receiving entity,
the receiving entity sends to the originator of the
message a message of identical form except that the
message type is Get Response, the value of the error_
field is gmp_err_nix_name, and the value of the error_
field is the unit-based index of said var_op_type component
the received message
(2) If the size of the Get Response type message generated
described below would exceed the size of the largest
for which the protocol definition requires acceptance, then
receiving entity sends to the originator of the received
a message of identical form except that the indicated
type is Get Response, the value of the error_status field
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
to the originator of the received message a Get Response type
such that, for each var_op_type component of the received message,
corresponding component of the generated message represents the
and value of that variable whose name is, in the
ordering of the names of all variables known to the receiving
together with the value of the var_name field of the given component
the immediate successor to that value. The value of the error_
field of the generated message is gmp_err_noerror and the value
the error_index field is zero. The value of the request_id field
the generated message is that for the received message
Messages of the Get Request type are generated by a protocol
only at the request of the application user
3.2. The Get Response Message
The form of messages of this type is identical to that of Get
type messages except for the indication of message type. In the
X.409 language
get_rsp_message_type ::= [ APPLICATION 2 ]
SEQUENCE {
Davin, Case, Fedor and Schoffstall [Page 6]
RFC 1028 Simple Gateway Monitoring November 1987
request_id request_id_type
error_status error_status_type
error_index error_index_type
var_op_list var_op_list_
}
The response of a protocol entity to a message of this type is
present its contents to the application user
Messages of the Get Response type are generated by a protocol
only upon receipt of Set Request or Get Request type messages
described elsewhere in this document
3.3. The Trap Request Message
The form of a message of this type is described below in the
defined in the CCITT X.409 recommendation
val_list_type ::= SEQUENCE OF var_value_
trap_type_type ::=
trap_req_message_type ::= [ APPLICATION 3 ]
SEQUENCE {
trap_type trap_type_type
val_list val_list_
}
The response of a protocol entity to a message of this type is
present its contents to the application user
Messages of the Trap Request type are generated by a protocol
only at the request of the application user
The significance of the val_list component of a Trap Request
message is implementation-specific
Interpretations for negative values of the trap_type field
implementation-specific. Interpretations for non-negative values
the trap_type field are defined below
3.3.1. The Cold Start Trap
A Trap Request type message for which the value of the trap_
Davin, Case, Fedor and Schoffstall [Page 7]
RFC 1028 Simple Gateway Monitoring November 1987
field is 0, signifies that the sending protocol entity
reinitializing itself such that the gateway configuration or
protocol entity implementation may be altered
3.3.2. The Warm Start Trap
A Trap Request type message for which the value of the trap_
field is 1, signifies that the sending protocol entity
reinitializing itself such that neither the gateway configuration
the protocol entity implementation is altered
3.3.3. The Link Failure Trap
A Trap Request type message for which the value of the trap_
field is 2, signifies that the sending protocol entity recognizes
failure in one of the communication links represented in the
configuration
3.3.4. The Authentication Failure Trap
A Trap Request type message for which the value of the trap_
field is 3, signifies that the sending protocol entity is
addressee of a protocol message that is not properly authenticated
3.3.5. The EGP Neighbor Loss Trap
A Trap Request type message for which the value of the trap_
field is 4, signifies that an EGP neighbor for whom the
protocol entity was an EGP peer has been marked down and the
relationship no longer obtains
3.4. The Set Request Message
The form of messages of this type is identical to that of Get
type messages except for the indication of message type. In
CCITT X.409 language
set_req_message_type ::= [ APPLICATION 4 ]
SEQUENCE {
request_id request_id_type
error_status error_status_type
error_index error_index_type
var_op_list var_op_list_
}
Davin, Case, Fedor and Schoffstall [Page 8]
RFC 1028 Simple Gateway Monitoring November 1987
Upon receipt of a message of this type, the receiving entity
according to any applicable rule in the list below
(1) If, for some var_op_type component of the received message,
value of the var_name field names no variable known to
receiving entity, then the receiving entity sends to
originator of the received message a message of identical
except that the indicated message type is Get Response,
value of the error_status field is gmp_err_nix_name, and
value of the error_index field is the unit-based index of
var_op_type component in the received message
(2) If, for some var_op_type component of the received message,
contents of the var_value field does not, according to the
X.409 recommendation, manifest a type, length, and value that
consistent with that required for the variable named by
value of the var_name field, then the receiving entity sends
the originator of the received message a message of
form except that the indicated message type is Get Response,
value of the error_status field is gmp_err_bad_value, and
value of the error_index field is the unit-based index of
var_op_type component in the received message
(3) If the size of the Get Response type message generated
described below would exceed the size of the largest message
which the protocol definition requires acceptance, then
receiving entity sends to the originator of the
message a message of identical form except that the
message type is Get Response, the value of the error_
field is gmp_err_too_big, and the value of the error_index
is zero
If none of the foregoing rules apply, then for each var_op_
component of the received message, according to the sequence of
components represented by said message, the value represented by
var_value field of the given component is assigned to the
named by the value of the var_name field of that component.
receiving entity sends to the originator of the received message
message of identical form except that the indicated message type
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
only at the request of the application user
Recognition and processing of Set Request type frames is not
by the protocol definition
Davin, Case, Fedor and Schoffstall [Page 9]
RFC 1028 Simple Gateway Monitoring November 1987
4. The Authentication
The authentication protocol is a session-layer protocol by
messages specified by a protocol user are selectively delivered
other protocol users. The protocol definition precludes delivery
a protocol user of any user message for which the
representation lacks a specified "authentic" form
Communication among authentication protocol entities is
by the exchange of protocol messages, each of which is entirely
independently represented by a single UDP datagram.
authentication protocol entity responds to protocol messages
at UDP port 153 on the host with which it is associated
A half-session of the authentication protocol is, for any
pair of protocol users, the set of messages sent from the first
of the pair to the second user of said pair. A session of
authentication protocol is defined to be union of two
half-sessions of the protocol - that is, the set of
exchanged between a given pair of protocol users. Associated
each protocol half-session is a triplet of functions
(1) The authentication function for a given half-session is
boolean-valued function that characterizes the set
authentication protocol messages that are of acceptable
authentic form with respect to the set of all
authentication protocol messages
(2) The message interpretation function for a given half
session is a mapping from the set of
protocol messages accepted by the authentication
for said half-session to the set of all possible
messages
(3) The message representation function for a given half
session is a mapping that is the inverse of the
interpretation function for said half-session
The association between half-sessions of the authentication
and triplets of functions is not defined in this document
The form and function of the single message type recognized by
protocol entity is described below. The type of a given
message is indicated by the value of the implicit type tag for
data structure that is represented by said message according to
conventions of the CCITT X.409 recommendation
Davin, Case, Fedor and Schoffstall [Page 10]
RFC 1028 Simple Gateway Monitoring November 1987
4.1. The Data Request Message
Messages of this type are represented by a sequence of fields
form and interpretation are described below
4.1.1. The Message Length
The Message Length field of a given Data Request message
the length of said message as an unsigned, 16-bit, binary integer
This value is encoded such that more significant bits precede
significant bits in the order of transmission and includes the
of the Message Length field itself
4.1.2. The Session ID Length
The Session ID Length field of a given Data Request
represents the length, in octets, of the Session ID field of
message. This value is encoded as an unsigned, 8-bit,
integer
4.1.3. The Session ID
The Session ID field of a given Data Request message represents
name of the protocol session to which said message belongs.
value of this field is encoded as asequence of octets whose length
the value of the Session ID Length field for said message
4.1.4. The User Data
The User Data field of a given Data Request message represents
message being passed from one protocol user to another. The value
this field is encoded according to conventions implicit in
message representation function for the appropriate half of
protocol session named by the value of the Session ID field for
message
Upon receipt of a Data Request type message, the
authentication protocol entity verifies the form of said message
application of the authentication function associated with its
of the session named by the value of the Session ID field in
received message. If the form of the received message is accepted
"authentic" by said function, then the user message computed by
application of the message interpretation function for said half
session to the value of the User Data field of the received
is presented to the protocol user together with an indication of
protocol session to which the received message belongs
Davin, Case, Fedor and Schoffstall [Page 11]
RFC 1028 Simple Gateway Monitoring November 1987
Otherwise, the message is discarded and an indication of the
of an unauthenticated message is presented to the protocol user
A message of this type is generated only at the request of
protocol user to communicate a message to another user of
protocol. Such a request specifies the user message to be sent
well as the session of the authentication protocol to which said
message belongs. The value of the Session ID field of the
message is the name of the session specified in the user request
The value of the User Data field of the generated message is
by applying the message representation function for the
half of the specified session to the specified user message
5. Variable
The variables retrieved or manipulated by the application
are named by octet string values. Such values are represented
this document in two ways
(1) A variable name octet string may be
numerically by a sequence of hexadecimal numbers, each
which denotes the value of the corresponding octet
said string
(2) A variable name octet string may be
symbolically by a character string whose form
the sequence of octets in said name while at the
time suggesting to a human reader the semantics of
named variable
Variable name octet strings are represented symbolically according
the following two rules
(1) The symbolic character string representation of
variable name of zero length is the character string
zero length
(2) The symbolic character string representation of
variable name of non-zero length n is the
of the symbolic character string representation of
variable name formed by the first (n - 1) octets of
given name together with the underscore character ("_")
and a character string that does not include
underscore character, such that the resulting
string is unique among the symbolic character
representations for all variable names of length n
Davin, Case, Fedor and Schoffstall [Page 12]
RFC 1028 Simple Gateway Monitoring November 1987
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,
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,
_GW_net_if_speed_net2.
All variable names are terminated by an implementation specific
string of non-zero length. Thus, a complete variable name is
specified for any of the variables defined in this document. Rather
for each defined variable, some prefix portion of its name
specified, with the understanding that the rightmost portion of
name is specific to the protocol implementation
Fullest exploitation of the semantics of the Get Request type
requires that names for related variables be chosen so as to
contiguous in the lexicographic ordering of all variable
recognized by an application protocol entity. This principle
observed in the naming of variables currently defined by
document, and it should be observed as well for variables defined
subsequent revisions of this document and for variables introduced
particular implementations of the protocol
A particular implementation of a protocol entity may
variables in addition to those defined by this document,
that in no case will an implementation-specific variable be
as having a name identical to that for one of the variables
here. By convention, the names of variables specific to a
implementation share a common prefix that distinguishes
variables from those defined in this document and from those that
be presented by other implementations of an application
entity. For example, variables specific to an implementation of
protocol in version 1.3 of the Squeaky gateway product of
Swinging Gateway company might have the names represented by
Davin, Case, Fedor and Schoffstall [Page 13]
RFC 1028 Simple Gateway Monitoring November 1987
01 FF 01 01 13 01,
01 FF 01 01 13 02,
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,
_GW_impl_Swinging_Squeaky_v1.3_variableC
The names and semantics of implementation-specific variables are
otherwise defined by this document, although implementors
encouraged to publish such definitions either as appendices to
document or by other appropriate means
Variable names of which the initial portion is
numerically as 02 and symbolically as "_HOST" are reserved for
use. Variable names of which the initial portion is
numerically as 03 and symbolically as "_TS" are similarly reserved
6. Required
To the extent that the information represented by a variable
in this section is also represented internally by a gateway for
this protocol is realized, access to that variable must be
by at least one application protocol entity associated with
gateway
6.1. The _GW_version_id
The variable such that the initial portion of its name is
symbolically as "_GW_version_id" and numerically as
01 01 01
has an octet string value that identifies the protocol
implementation (e.g., "ACME Packet-Whiz Model II").
6.2. The _GW_version_rev
The variable such that the initial portion of its name is
symbolically as "_GW_version_rev" and numerically as
01 01 02
has an integer value that identifies the revision level of the
implementation. The encoding of the revision level as an
Davin, Case, Fedor and Schoffstall [Page 14]
RFC 1028 Simple Gateway Monitoring November 1987
value is implementation-specific
6.3. The _GW_cfg_nnets
The variable such that the initial portion of its name is
symbolically as "_GW_cfg_nnets" and numerically as
01 02 01
has an integer value that represents the number of logical
interfaces afforded by the configuration of the gateway
6.4. Network Interface
This section describes a related set of variables that
attributes of the logical network interfaces afforded by the
configuration. Each such network interface is uniquely identified
an octet string. The convention by which names are assigned to
network interfaces of a gateway is implementation-specific
6.4.1. The _GW_net_if_type Variable
A variable such that the initial portion of its name is
symbolically as "_GW_net_if_type" and numerically as
01 03 01 03
has an integer value that represents the type of the
interface identified by the remainder of the name for said variable
The value of a variable of this class represents network
according to the conventions described in Appendix 1.
6.4.2. The _GW_net_if_speed Variable
A variable such that the initial portion of its name is
symbolically as "_GW_net_if_speed" and numerically as
01 03 01 04
has an integer value that represents the estimated nominal
in bits per second of the network interface identified by
remainder of the name for said variable
6.4.3. The _GW_net_if_in_pkts Variable
A variable such that the initial portion of its name is
symbolically as "_GW_net_if_in_pkts" and numerically as
Davin, Case, Fedor and Schoffstall [Page 15]
RFC 1028 Simple Gateway Monitoring November 1987
01 03 01 01 01
has an integer value that represents the number of packets
by the gateway over the network interface identified by the
of the name for said variable
6.4.4. The _GW_net_if_out_pkts Variable
A variable such that the initial portion of its name is
symbolically as "_GW_net_if_out_pkts" and numerically as
01 03 01 02 01
has an integer value that represents the number of
transmitted by the gateway over the network interface identified
the remainder of the name for said variable
6.4.5. The _GW_net_if_in_bytes Variable
A variable such that the initial portion of its name is
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
the gateway over the network interface identified by the remainder
the name for said variable
6.4.6. The _GW_net_if_out_bytes Variable
A variable such that the initial portion of its name is
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
by the gateway over the network interface identified by the
of the name for said variable
6.4.7. The _GW_net_if_in_errors Variable
A variable such that the initial portion of its name is
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
encountered by the gateway on the network interface identified by
Davin, Case, Fedor and Schoffstall [Page 16]
RFC 1028 Simple Gateway Monitoring November 1987
remainder of the name for said variable. The definition of
reception error is implementation-specific and may vary according
network type
6.4.8. The _GW_net_if_out_errors Variable
A variable such that the initial portion of its name is
symbolically as "_GW_net_if_out_errors" and numerically as
01 03 01 02 03
has an integer value that represents the number of
errors encountered by the gateway on the network interface
by the remainder of the name for said variable. The definition of
transmission error is implementation-specific and may vary
to network type
6.4.9. The _GW_net_if_status Variable
A variable such that the initial portion of its name is
symbolically as "_GW_net_if_status" and numerically as
01 03 01 05
has an integer value that represents the current status of
network interface identified by the remainder of the name for
variable. Network status is represented according to the
described in Appendix 2.
6.5. Internet Protocol
This section describes variables that represent information
to protocols and mechanisms of the Internet Protocol (IP) family [3].
6.5.1. Protocol Address Variable
This section describes a related set of variables that
attributes of the the IP interfaces presented by a gateway on
various networks to which it is attached. Each such
interface is uniquely identified by an octet string. The
by which names are assigned to the protocol interfaces for a
is implementation-specific
6.5.1.1. The _GW_pr_in_addr_value Variable
A variable such that the initial portion of its name is
symbolically as "_GW_pr_in_addr_value" and numerically as
Davin, Case, Fedor and Schoffstall [Page 17]
RFC 1028 Simple Gateway Monitoring November 1987
01 04 01 01 01
has an octet string value that literally represents the 32-
Internet address for the IP interface identified by the remainder
the name for said variable
6.5.1.2. The _GW_pr_in_addr_scope Variable
A variable such that the initial portion of its name is
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
the IP interface identified by the remainder of the name for
variable is associated
6.5.2. Exterior Gateway Protocol (EGP)
This section describes variables that represent information
to protocols and mechanisms of the EGP protocol [4].
6.5.2.1. The _GW_pr_in_egp_core
A variable such that the initial portion of its name is
symbolically as "_GW_pr_in_egp_core" and numerically as
01 04 01 03 01
has an integer value that characterizes the associated gateway
respect to the set of INTERNET core gateways. A nonzero
indicates that the associated gateway is part of the INTERNET core
6.5.2.2. The _GW_pr_in_egp_as Variable
A variable such that the initial portion of its name is
symbolically as "_GW_pr_in_egp_as" and numerically as
01 04 01 03 02
has an integer value that literally identifies an Autonomous
to which this gateway belongs
6.5.2.3. The EGP Neighbor Variable
This section describes a related set of variables that
attributes of "neighbors" with which the gateway may be associated
EGP. Each such EGP neighbor is uniquely identified by an
Davin, Case, Fedor and Schoffstall [Page 18]
RFC 1028 Simple Gateway Monitoring November 1987
string. The convention by which names are assigned to EGP
of a gateway is implementation-specific
6.5.2.3.1. The _GW_pr_in_egp_neighbor_addr Variable
A variable such that the initial portion of its name is
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-
Internet address for the EGP neighbor identified by the remainder
the name for said variable
6.5.2.3.2. The _GW_pr_in_egp_neighbor_state Variable
A variable such that the initial portion of its name is
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
the gateway with respect to the EGP neighbor identified by
remainder of the name for said variable. The meaningful values
such a variable are: "IDLE," "ACQUISITION," "DOWN," "UP,"
"CEASE."
6.5.2.4. The _GW_pr_in_egp_errors
The variable such that the initial portion of its name is
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
errors
6.5.3. Routing Variable
This section describes a related set of variables that
attributes of the the IP routes by which a gateway directs packets
various destinations on the Internet. Each such route is
identified by an octet string that is the concatenation of
literal 32-bit value of the Internet address for the destination
said route together with an implementation-specific octet string
The convention by which names are assigned to the Internet routes
a gateway is in all other respects implementation-specific
Davin, Case, Fedor and Schoffstall [Page 19]
RFC 1028 Simple Gateway Monitoring November 1987
6.5.3.1. The _GW_pr_in_rt_gateway Variable
A variable such that the initial portion of its name is
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-
Internet address of the next gateway to which traffic is directed
the route identified by the remainder of the name for said variable
6.5.3.2. The _GW_pr_in_rt_type Variable
A variable such that the initial portion of its name is
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
by the remainder of the name for said variable. Route types
identified according to the conventions described in Appendix 3.
6.5.3.3. The _GW_pr_in_rt_how-learned Variable
A variable such that the initial portion of its name is
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
information from which the route identified by the remainder of
name for said variable is generated. The meaningful values of such
variable are: "STATIC," "EGP," and "RIP."
6.5.3.4. The _GW_pr_in_rt_metric0 Variable
A variable such that the initial portion of its name is
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
identified by the remainder of the name for said variable
6.5.3.5. The _GW_pr_in_rt_metric1 Variable
A variable such that the initial portion of its name is
Davin, Case, Fedor and Schoffstall [Page 20]
RFC 1028 Simple Gateway Monitoring November 1987
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
identified by the remainder of the name for said variable
6.6. DECnet Protocol
This section describes variables that represent information
to protocols and mechanisms of the DEC Digital Network Architecture
DEC and DECnet are registered trademarks of Digital
Corporation
6.7. XNS Protocol
This section describes variables that represent information
to protocols and mechanisms of the Xerox Network System.
Network System and XNS are registered trademarks of the
Corporation
7. Implementation-Specific
Additional variables that may be presented for inspection
manipulation by particular protocol entity implementations
described in Appendices to this document
8.
[1] CCITT, "Message Handling Systems: Presentation
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/
Sciences Institute, January 1980.
[4] Rosen, E., "Exterior Gateway Protocol", RFC-827,
Beranek and Newman, October 1982.
9. Appendix 1: Network Type
Numeric representations for various types of networks are
below
Davin, Case, Fedor and Schoffstall [Page 21]
RFC 1028 Simple Gateway Monitoring November 1987
Value Network
====================
0
1 IEEE 802.3
2 IEEE 802.4
3 IEEE 802.5
4
5 ProNET-80
6 ProNET-10
7
8 X.25
9 Point-to-Point
10 Proprietary Point-to-Point
11 ARPA 1822
12 ARPA 1822
13
14
10. Appendix 2: Network Status
Numeric representations for network status are presented below
Value Network
======================
0 Interface Operating
1 Interface Not
2 Interface
3 Interface
4 Interface Attempting
11. Appendix 3: Route Type
Numeric representations for route types are presented below
Value Route
==================
0 Route to Nowhere --
1 Route to Directly Connected
2 Route to a Remote
3 Route to a Remote
4 Route to a Sub-
12. Appendix 4: Initial Implementation
The initial objective of implementing the protocol specified in
document is to provide a mechanism for monitoring Internet gateways
While the protocol design makes some provision for gateway
Davin, Case, Fedor and Schoffstall [Page 22]
RFC 1028 Simple Gateway Monitoring November 1987
functions as well, this aspect of the design is not fully
and needs further refinement before a generally useful
could be produced. Accordingly, initial implementations will
generate or respond to the optional Set Request message type
The protocol defined here may be subsequently refined based
experience with early implementations or upon further study of
problem of gateway management. Moreover, it may be superceded
other proposals in the area of gateway monitoring and control
Implementations of the authentication protocol specified in
document are likely to evolve in response to the particular
and privacy needs of its users. While, in general, the
between particular half-sessions of the authentication protocol
the described triplets of functions is specific to an
and beyond the scope of this document, the desire for
interoperability among initial implementations of this protocol
best served by the temporary adoption of a common
scheme. Accordingly, initial implementations will associate
every possible half-session a triplet of functions that realizes
trivial authentication mechanism
(1) The authentication function is defined to have the
TRUE over the entire domain of authentication
messages
(2) The message interpretation function is defined to be
identity function
(3) The message representation function is defined to be
identity function
Because this initial posture with respect to authentication is
likely to remain acceptable indefinitely, implementors are urged
adopt designs that isolate authentication mechanism as much
possible from other components of the implementation
13. Appendix 5: Routing Information Propagation
This section describes a set of related variables that
the sources and destinations of routing information propagated
various routing protocols. These variables have meaning only
those routing protocol implementations that afford
flexibility in propagating routing information than is required
the various routing protocol specifications
Each IP interface afforded by the configuration of the gateway
which routing information may propagate via a routing
Davin, Case, Fedor and Schoffstall [Page 23]
RFC 1028 Simple Gateway Monitoring November 1987
(target interface) is named by a string of four octets that
represents the IP address associated with said protocol interface
Each IP protocol interface afforded by the configuration of
gateway over which routing information may arrive via any
protocol (source interface) is named by a string of four octets
literally represents the IP address associated with said
interface
Each routing protocol by which a gateway receives information that
uses to route IP traffic (source routing protocol) is named by
single-octet string according to the conventions set forth
Appendix 6 of this document
Each routing protocol by which a gateway propagates
information used by other hosts or gateways to route IP
(target routing protocol) is named by a single-octet string
to the conventions set forth in Appendix 6 of this document
A variable such that the initial portion of its name is
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
(3) the name of a target interface followed
(4) the name of a source routing protocol followed
(5) the name of a source
has an integer value that characterizes the propagation of
information between the sources and destinations of such
that are identified by the initial portion of that variable's name.
non-zero value for such a variable indicates that routing
received via the source routing protocol named by the
component of the variable name on the source interface named by
fifth component is propagated via the target routing protocol
by the second component of the variable name over the
interface named by its third component. A zero value for such
variable indicates that routing information received via the
routing protocol on the source interface identified in the
name is NOT propagated via the target routing protocol over
target interface identified in the variable name
Davin, Case, Fedor and Schoffstall [Page 24]
RFC 1028 Simple Gateway Monitoring November 1987
14. Appendix 6: Routing Protocol
Numeric representations for routing protocols are presented below
Value Routing
========================
0 None --
1 Berkeley RIP Version 1
2
3
4
5 Other
15. Appendix 7: Proteon p4200 Release 7.4
This section describes implementation-specific variables presented
the implementation of this protocol in Software Release 7.4 for
Proteon p4200 Internet Router. These variable definitions
subject to change without notice
15.1. The Network Interface
This section describes a related set of variables that
attributes of a network interface in the Proteon p4200
Router gateway. Each such network interface is uniquely named by
implementation-specific octet string of length 1.
15.1.1. The Generic Network Interface
This section describes a related set of variables that
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
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
A variable such that the initial portion of its name is
concatenation of the name for a generic network interface followed
the octet string represented symbolically as "_ovfl-in"
numerically as 01, has an integer value that represents the number
input packets dropped due to gateway congestion for the
interface identified by the initial portion of its name
Davin, Case, Fedor and Schoffstall [Page 25]
RFC 1028 Simple Gateway Monitoring November 1987
15.1.1.2. The Generic _ovfl-out Variable
A variable such that the initial portion of its name is
concatenation of the name for a generic network interface followed
the octet string represented symbolically as "_ovfl-out"
numerically as 02, has an integer value that represents the number
output packets dropped due to gateway congestion for the
interface identified by the initial portion of its name
15.1.1.3. The Generic _slftst-pass Variable Class A
such that the initial portion of its name is the concatenation of
name for a generic network interface followed by the octet
represented symbolically as "_slftst-pass" and numerically as 03,
an integer value that represents the number of times the
self-test procedure succeeded for the network interface identified
the initial portion of its name
15.1.1.4. The Generic _slftst-fail Variable
A variable such that the initial portion of its name is
concatenation of the name for a generic network interface followed
the octet string represented symbolically as "_slftst-fail"
numerically as 04, has an integer value that represents the number
times the interface self-test procedure failed for the
interface identified by the initial portion of its name
15.1.1.5. The Generic _maint-fail Variable
A variable such that the initial portion of its name is
concatenation of the name for a generic network interface followed
the octet string represented symbolically as "_maint-fail"
numerically as 06, has an integer value that represents the number
times the network maintenance procedure failed for the
interface identified by the initial portion of its name
15.1.1.6. The Generic _csr Variable
A variable such that the initial portion of its name is
concatenation of the name for a generic network interface followed
the octet string represented symbolically as "_csr" and
as 07, has an integer value that represents the internal address
the device CSR for the network interface identified by the
portion of its name
15.1.1.7. The Generic _vec Variable
A variable such that the initial portion of its name is
concatenation of the name for a generic network interface followed
the octet string represented symbolically as "_vec" and
Davin, Case, Fedor and Schoffstall [Page 26]
RFC 1028 Simple Gateway Monitoring November 1987
as 08, has an integer value that identifies the device
vector used by the network interface identified by the
portion of its name
15.1.2. The ProNET Network Interface
This section describes a related set of variables that
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
concatenation of the octet string represented symbolically
"_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
A variable such that the initial portion of its name is
concatenation of the name for a ProNET type network
followed by the octet string represented symbolically as "_node
number" and numerically as 01, has an integer value that
the ProNET node number associated with the network
identified by the initial portion of its name
15.1.2.2. The ProNET _in-data-present Variable
A variable such that the initial portion of its name is
concatenation of the name for a ProNET type network
followed by the octet string represented symbolically as "_in-data
present" and numerically as 02, has an integer value that
the number of times that unread data was present in the input
buffer for the network interface dentified by the initial portion
its name
15.1.2.3. The ProNET _in-overrun Variable
A variable such that the initial portion of its name is
concatenation of the name for a ProNET type network
followed by the octet string represented symbolically as "_in
overrun" and numerically as 03, has an integer value that
the number of times that a packet copied from the ring exceeded
size of the packet input buffer on the network interface
by the initial portion of its name
Davin, Case, Fedor and Schoffstall [Page 27]
RFC 1028 Simple Gateway Monitoring November 1987
15.1.2.4. The ProNET _in-odd-byte-cnt Variable
A variable such that the initial portion of its name is
concatenation of the name for a ProNET type network
followed by the octet string represented symbolically as "_in-odd
byte-cnt" and numerically as 04, has an integer value that
the number of times that a packet was received with an odd number
bytes on the network interface identified by the initial portion
its name
15.1.2.5. The ProNET _in-parity-error Variable
A variable such that the initial portion of its name is
concatenation of the name for a ProNET type network
followed by the octet string represented symbolically as "_in
parity-error" and numerically as 05, has an integer value
