Latest draft of my IP table document
Karl Auerbach <karl@eng.sun.com> Sun, 28 April 1991 15:30 UTC
Received: from nisc.psi.net by NRI.NRI.Reston.VA.US id aa13907; 28 Apr 91 11:30 EDT
Received: by nisc.psi.net (5.61/2.1-PSINet Operations ) id AA20279; Fri, 8 Mar 91 12:25:48 -0500
Received: from nisc.nyser.net by nisc.psi.net (5.61/2.1-PSINet Operations ) id AA20274; Fri, 8 Mar 91 12:25:36 -0500
Received: from Sun.COM by nisc.nyser.net (5.61/2.1-) id AA17987; Fri, 8 Mar 91 12:23:58 -0500
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA19976; Fri, 8 Mar 91 09:27:55 PST
Received: from lvs.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA26718; Fri, 8 Mar 91 09:35:35 PST
Received: by lvs.Eng.Sun.COM (4.1/SMI-4.1) id AA01666; Fri, 8 Mar 91 09:29:18 PST
Date: Fri, 08 Mar 1991 09:29:18 -0800
From: Karl Auerbach <karl@eng.sun.com>
Message-Id: <9103081729.AA01666@lvs.Eng.Sun.COM>
To: snmp-wg@nisc.nyser.net
Subject: Latest draft of my IP table document
Status: O
Here's the latest draft of my IP table document. I have made significant
changes. In particular, I have removed the requirement for a continguous
and ordered block. I have added DEFVAL clauses and restructured the
language so that presumably the proposal can be more subject to
automated interpreters.
It is still a long way from perfect. And it does not answer the issues
raised whether we need a more sophisticated instance for table entries.
I want to do some informal talks on this proposal, SNMP row creation,
and SNMP SETs in general at the IETF. The goal would be to see whether
we can come up with a specifically concrete sense of direction that we
can ask Chuck et al to charter a specific working group.
--karl--
----------cut here--------
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
Management Information Base for
IP Routing Table
9:51 PM March 7, 1991
Karl Auerbach
Sun Microsystems
karl@eng.sun.com
1. Status of this Memo
This memo defines an extension to MIB-II (RFC draft-ietf-snmp-
mib2-04.txt)[1] and is a Proposed Standard for the Internet
community.
Please send comments to: Karl Auerbach <karl@eng.sun.com>.
2. Introduction
It is possible for a device to have a routing table in which
there are multiple, alternate routes for any given destination.
Similarly, there are devices which there are multiple, alternate
IP addresses associated with the same physical interface.
MIB-I (RFC1156)[2] does not adequately support these devices.
Early drafts of MIB-II attempted to deal with these situations
through the addition of a an additional, optional distinguishing
component of the SNMP instance. However, certain problems were
recognized with the MIB-II mechanism. In order to expedite the
progress of MIB-II, the proposed changes were removed pending
further study. Consequently, MIB-II, as published, also fails to
adequately support these devices.
The problems with the MIB-II drafts were twofold:
1. The use of an optional component in the instance portion of
an object identifier was unique and would have caused
problems with existing and new implementations.
2. There were no rules to govern the generation of this new
component and the reclamation of its value. Nor were there
any rules to deal with race conditions resulting from
uncordinated SNMP activity.
Karl Auerbach DRAFT [Page 1]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
This proposal proposes a revision to MIB-II to allow multiple
routes and multiple IP addresses.
In particular, the old MIB-I and MIB-II IP addressing and IP
routing tables are superseded. The old table definitions are
"deprecated".
Both of these new tables add an additional component to the
instance specifier, similar to what was proposed in the early
MIB-II drafts. However, in this proposal, this additional
component is mandatory, not optional.
Rules are defined to govern the addition of new "rows" to these
new tables. An additional variable is added to each of the new
tables to clearly differentiate between addition of new rows and
modification of existing rows.
This proposal also corrects minor spelling errors in the MIB-II
definitions. Additional clarifying text has been added to the
definition of ipRouteMask. Two new enumerated values have been
added to ipRouteType.
This proposal does not resolve any issues with regard to devices
which may support multiple hardware interfaces which share a
common IP address.
This proposal makes no changes to the SNMP protocol.
3. Deprecation of MIB-II IP Tables
The status of the existing ipRouteTable, ipAddrTable, and all
variables contained within those tables are changed to
"deprecated".
In other words, the definitions of ipRouteTable and ipAddrTable
in MIB-II are modified as follows:
ipRouteTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpRouteEntry
ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"This entity's IP Routing table."
::= { ip 21 }
ipAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpAddrEntry
ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"The table of addressing information relevant to
this entity's IP addresses."
::= { ip 20 }
Karl Auerbach DRAFT [Page 2]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
4. New IP Routing Table
The new IP routing table is very similar to the old version found
in MIB-I and MIB-II. However, it has a new variable in each
"row", ipRouteKey. And the instance index is composed of the
ipRouteDest (like in MIB-I and MIB-I) plus the new ipRouteKey.
The ipRouteKey is essentially a differentiator between different
routes to the same destination.
The presence of a SET operation against ipRouteKey acts as a
switch to enable an agent to perform a row creation rather than
modifying an existing instance of ipRouteEntry.
The values of ipRouteKey must be unique only in the context of
routes to the same destination. In other words, the same
ipRouteKey value may be found on a route to a different
destination.
The values of ipRouteKey are not highly constrained. Values must
range between 1 and 65535, inclusive. The values need not be
densely packed. Nor need successive values bear any particular
relationship to previous values.
When generating new values, the generator may try to avoid
re-using values which have recently been removed. However, since
the scope of an ipRouteKey value is the set of routes with to the
same destination, there is ought to be no problem should a value
be quickly reused.
4.1 Contents
-- the IP routing table
-- The IP routing table contains an entry for each route
-- presently known to this entity.
ipRoutingTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpRouteEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This entity's IP Routing table."
::= { ip XX }
-- Each instance of IpRouteEntry is identified by a an
-- instance formed by the IP address of the destination
-- and a differentiating integer. This integer is
-- generated and reclaimed according to rules
-- specified in section 4.3 of this document.
Karl Auerbach DRAFT [Page 3]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
ipRouteEntry OBJECT-TYPE
SYNTAX IpRouteEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A route to a particular destination."
INDEX { ipRouteDest ipRouteKey}
::= { ipRouteTable 1 }
IpRouteEntry ::=
SEQUENCE {
ipRouteDest IpAddress,
ipRouteIfIndex INTEGER,
ipRouteMetric1 INTEGER,
ipRouteMetric2 INTEGER,
ipRouteMetric3 INTEGER,
ipRouteMetric4 INTEGER,
ipRouteNextHop IpAddress,
ipRouteType INTEGER,
ipRouteProto INTEGER,
ipRouteAge INTEGER,
ipRouteMask IpAddress,
ipRouteMetric5 INTEGER,
ipRouteInfo OBJECT IDENTIFIER
ipRouteKey INTEGER (1..65535)
}
ipRouteDest OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The destination IP address of this route. An
entry with a value of 0.0.0.0 is considered a
default route."
::= { ipRouteEntry 1 }
ipRouteIfIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The index value which uniquely identifies the
local interface through which the next hop of
this route should be reached. The interface
identified by a particular value of this index is
the same interface as identified by the same
value of ifIndex."
::= { ipRouteEntry 2 }
Karl Auerbach DRAFT [Page 4]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
ipRouteMetric1 OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DEFVAL -1
DESCRIPTION
"The primary routing metric for this route. The
semantics of this metric are determined by the
routing-protocol specified in the route's
ipRouteProto value. If this metric is not used,
its value should be set to -1."
::= { ipRouteEntry 3 }
ipRouteMetric2 OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DEFVAL -1
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the
routing-protocol specified in the route's
ipRouteProto value. If this metric is not used,
its value should be set to -1."
::= { ipRouteEntry 4 }
ipRouteMetric3 OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DEFVAL -1
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the
routing-protocol specified in the route's
ipRouteProto value. If this metric is not used,
its value should be set to -1."
::= { ipRouteEntry 5 }
ipRouteMetric4 OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DEFVAL -1
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the
routing-protocol specified in the route's
ipRouteProto value. If this metric is not used,
its value should be set to -1."
::= { ipRouteEntry 6 }
Karl Auerbach DRAFT [Page 5]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
ipRouteNextHop OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The IP address of the next hop of this route.
(In the case of a route bound to an interface
which is realized via a broadcast media, the
value of this field is the agent's IP address on
that interface.)"
::= { ipRouteEntry 7 }
ipRouteType OBJECT-TYPE
SYNTAX INTEGER
{
other(1), -- None of the following.
invalid(2), -- An invalidated route.
direct(3), -- Route to a directly
-- connected (sub-)network.
indirect(4) -- Route to a non-local
-- host, network, or
-- sub-network.
expired(5), -- A stale route.
failed(6), -- Route known but doesn't seem
to work.
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The type of route. Note that the values
direct(3) and indirect(4) refer to the notion of
direct and indirect routing in the IP
architecture.
Setting this object to the value invalid(2) has
the effect of invalidating the corresponding
entry in the ipRouteTable object. That is, it
effectively disassociates the destination
identified with said entry from the route
identified with said entry. It is an
implementation-specific matter as to whether the
agent removes an invalidated entry from the
table. Accordingly, management stations must be
prepared to receive tabular information from
agents that corresponds to entries not currently
in use. Proper interpretation of such entries
requires examination of the relevant ipRouteType
object."
::= { ipRouteEntry 8 }
Karl Auerbach DRAFT [Page 6]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
ipRouteProto OBJECT-TYPE
SYNTAX INTEGER
{
other(1), -- None of the following.
local(2), -- Non-protocol information,
-- e.g., manually configured
-- entries.
netmgmt(3), -- Set via a network
-- management protocol
icmp(4), -- Obtained via ICMP,
-- e.g., Redirect
-- The remaining values are
-- all gateway routing
-- protocols:
egp(5),
ggp(6),
hello(7),
rip(8),
is-is(9),
es-is(10),
ciscoIgrp(11),
bbnSpfIgp(12),
ospf(13),
bgp(14)
}
ACCESS read-only
STATUS mandatory
DEFVAL netmgmt(3)
DESCRIPTION
"The routing mechanism via which this route was
learned. Inclusion of values for gateway routing
protocols is not intended to imply that hosts
should support those protocols."
::= { ipRouteEntry 9 }
ipRouteAge OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DEFVAL 0
DESCRIPTION
"The number of seconds since this route was last
updated or otherwise determined to be correct.
Note that no semantics of `too old' can be
implied except through knowledge of the routing
protocol by which the route was learned."
::= { ipRouteEntry 10 }
Karl Auerbach DRAFT [Page 7]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
ipRouteMask OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Indicate the mask to be logical-ANDed with the
destination address before being compared to the
value in the ipRouteDest field. For those
systems that do not support arbitrary subnet
masks, an agent constructs the value of the
ipRouteMask by determining whether the value of
the correspondent ipRouteDest field belong to a
class-A, B, or C network, and then using one of:
mask network
255.0.0. class-A
255.255.0.0 class-B
255.255.255.0 class-C
If the value of the ipRouteDest is 0.0.0.0 (a
default route), then the mask value is also
0.0.0.0. It should be noted that all IP routing
subsystems implicitly use this mechanism.
Some implementations of IP can differentiate
between routes to networks and routes to
individual hosts. These can be distinguished by
the following convention: Routes to specific
hosts have ipRouteMask values of 0xFFFFFFFF (32
ones). All other values of ipRouteMask indicate
a network route."
::= { ipRouteEntry 11 }
ipRouteMetric5 OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DEFVAL -1
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the
routing-protocol specified in the route's
ipRouteProto value. If this metric is not used,
its value should be set to -1."
::= { ipRouteEntry 12 }
Karl Auerbach DRAFT [Page 8]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
ipRouteInfo OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-write
STATUS mandatory
DEFVAL { 0 0 }
DESCRIPTION
"A reference to MIB definitions specific to the
particular routing protocol which is responsible
for this route, as determined by the value
specified in the route's ipRouteProto value. If
this information is not present, its value should
be set to the OBJECT IDENTIFIER { 0 0 }, which is
a syntactically valid object identifier, and any
conforming implementation of ASN.1 and BER must
be able to generate and recognize this value."
::= { ipRouteEntry 13 }
ipRouteKey OBJECT-TYPE
SYNTAX INTEGER (1..65535)
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A value which distinguishes this instance of
IpRouteEntry from other instances.
A value is invalid for a write if it represents
an existing instance of ipRouteEntry unless that
instance has an ipRouteType value of 'invalid'.
Hence writes to ipRouteKey may occur only in the
context of an attempt to create a new instance of
ipRouteEntry.
An attempt to write a value indicates that
creation of a new instance of ipRouteEntry is to
be attempted."
::= { ipRouteEntry 14 }
4.2 Adding New Rows to new routing table
Construction of a new conceptual "row" to the IP is the creation
of a new instance of ipRouteEntry including all of its component
variables.
The method proposed here resolves problems found in other
schemes.
This method requires that the entire row creation be accomplished
in a single SET-REQUEST. Consequently the agent may easily avoid
race conditions caused by uncoordinated activity of two or more
manager stations.
This method gives the manager the ability to define in advance
the object instance to be used for the elements of the new
instance of ipRouteEntry. This eliminates a problem in other
Karl Auerbach DRAFT [Page 9]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
methods which require the manager to read-back the table to
determine what instance the agent assigned to the new row.
The SET-REQUEST must contain a defined minimum set of
information.
4.2.1 SET-REQUEST PDU Content Requirements
An SNMP agent shall create a new instance of IpRouteEntry for
each collection of varBinds contained in an otherwise valid a
SET-REQUEST PDU meeting the following criteria.
The following criteria are to be applied in the order shown.
1. No two or more varBinds in the varBindList may name the
same variable.
2. The collection of varBinds consists of those varBinds in
the varBindList which:
a) Name variables within ipRouteEntry, and
b) All have the same INDEX value.
3. The collection must contain a varBind naming ipRouteDest
and a varbind naming ipRouteKey.
4. The value proposed for ipRouteDest must match that found in
the INDEX for the varBinds in the collection.
5. The value proposed for ipRouteKey must match that found in
the INDEX for the varBinds in the collection.
6. In addition to those varBinds required by condition #3, the
collection must contain a varBind naming each variable
within ipRouteEntry for which there is no DEFVAL clause in
its definition.
7. The collection may contain varBinds naming variables within
ipRouteEntry for which there are DEFVAL clauses in their
definition provided that for each such varBind the value
being proposed is the same as that indicated in the DEFVAL
clause.
8. The INDEX of the varBinds in the collection must refer to
an nonexistent instance of IpRouteEntry or one in which
ipRouteType is "invalid (2)".
9. The values of varBinds in the collection must be consistent
with one another and with other, existing entries in the
routing table.
10. The agent must have sufficient resources to sustain the
creation of the proposed new instance of ipRouteEntry.
Karl Auerbach DRAFT [Page 10]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
Condition #1 is a restatement of the general rule that an SNMP
SET-REQUEST PDU may not contain two or more varBinds proposing
values (even consistent values) for the same instance of a
variable. (This rule is not expressly stated in RFC1157, but is
implicit in the requirement that the setting of all variables
must be effected logically simultaneously.)
The purpose of condition #8 is to prevent the accidental
overwriting of an existing row. This is particularly useful when
a row appears "spontaneously" (due to action of a routing
protocol) or through uncoordinated SNMP activity from another
management station.
4.2.2 Error Conditions
If condition #1 is not met, then the SET-REQUEST shall be
rejected with a badValue error with the error index referencing
the second of the erroneous varBind.
If condition #2 can not be applied to create a collection of
varBinds, then the varBinds are considered as unrelated for
purposes of the IP routing table and will succeed or fail on
their individual merits (subject, of course, to the standard SNMP
requirement that all SETs succeed or fail together.)
If conditions #1 through #2 are met, but condition #3 fails, then
the SET-REQUEST shall be rejected with a badValue error with the
error index referencing the first varBind of the collection.
If conditions #1 through #3 are met, but condition #4 or #5
fails, then the SET-REQUEST shall be rejected with a badValue
error with the error index referencing the offending varBind.
If conditions #1 through #5 are met, but condition #6 fails, then
the SET-REQUEST shall be rejected with a badValue error with the
error index referencing the first varBind of the collection.
<<***This is ambiguous with respect to a failure of condition
#3.***>>>
If conditions #1 through #3 are met, but condition #7 fails, then
the SET-REQUEST shall be rejected with a badValue error with the
error index referencing the offending varBind.
If conditions #1 through #7 are met, but condition #8 fails, then
the SET-REQUEST shall be rejected with a genErr error with the
error index referencing the first varBind of the collection.
If conditions #1 through #8 are met, but condition #9 fails, then
the SET-REQUEST shall be rejected with a badValue error with the
error index referencing the varBind which is most closely
associated with the inconsistency. <<<***This is quite
ambigous.***>>>
(Note that a route which is marked as "invalid" is considered as
nonexistent for the purposes of condition #8. Thus a collection
Karl Auerbach DRAFT [Page 11]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
of varBinds which meets all of the above conditions with respect
to an existing, but "invalid" row has the effect of resurrecting
that row.)
4.2.3 Agent Behavior
An agent must ensure that once an instance of ipRouteEntry is
created that it retains is value of ipRouteKey.
Instances of ipRouteKey may be created or destroyed as the result
of an SNMP SET-REQUEST PDU or through the action of a routing
protocol, ICMP, or local configuration tools.
4.2.3.1 SNMP Triggered Agent Behavior
Upon receipt of a SET-REQUEST PDU with meets the previously
stated criteria, the agent shall create a new instance of
ipRouteEntry.
4.2.3.2 Autonomous Creation of ipRouteEntry Instances
Instances of ipRouteEntry may come into existence and disappear
apart from any SNMP activity (e.g. as the result of routing
protocols, ICMP activity, or local configuration.) In these
situations the agent is responsible for building an appropriate
and internally consistent row. The agent must select a value for
ipRouteKey which is not otherwise in use.
It is suggested that agents generate even values of ipRouteKey.
4.2.4 Manager Behavior
To make use of these rules, a manager station creates a new row
as follows:
1. The manager station, by its own private means, gathers
together the information to be placed in the new row.
2. The manager station chooses a value of ipRouteKey for the
new row. The best technique is to read the ipRoutingEntrys
for the proposed destination to winnow out any ipRouteKeys
which are currently in use. However, any other mechanism
may be used (including random generation).
It is suggested that managers generate odd values of
ipRouteKey.
It is suggested that manager stations include some
randomizing method within the generation of ipRouteKey
values. The purpose is to cause a "randomized backoff" to
avoid persistent collisions between two manager stations
trying to create a row. <<<***We may want to make this more
of a mandatory requirement than a mere suggestion***>>>
Karl Auerbach DRAFT [Page 12]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
The manager station must always be prepared for the
SET-REQUEST to fail due to ipRouteKey collision no matter
how the value is selected.
3. The manager station sends out a SET-REQUEST PDU containing
a collection of varBinds as described above. The value of
ipRouteKey used in the Index and proposed for ipRouteKey in
the varBinds is that selected in step #2 above.
The agent will validate the SET-REQUEST. During
validation, the agent will run the varBinds against the
previously described criteria. If the manager has
indicated row creation, but a row already exists, the agent
will reject the SET-REQUEST. Otherwise, if the SET-REQUEST
is otherwise valid, the agent will create the new row and a
good GET-RESPONSE PDU will be returned.
4. If the manager receives a clean GET-RESPONSE, the manager
will "know" that a new row has been created with the given
ipRouteKey.
Otherwise, if the error in the response PDU indicates a row
collision, the manager station should iterate this
procedure from step #2, above. The number of iterations is
theoretically unbounded, but in practice (and assuming the
manager is not simply reusing the same proposed ipRouteKey
values) the procedure should terminate very quickly. In
fact, if the manager station selects proposed ipRouteKeys
based upon those in use, collisions (and hence iterations)
should be very rare indeed.
4.2.5 General Comments on Row Creation
Note that presence of ipRouteKey within a collection of varBinds
in a SET-REQUEST enables a manager to safely differentiate
between creation of a new instance and modification of an
existing entry.
Condition #8 acts as a gate to prevent the inadvertent
overwriting of existing rows, including rows which have recently
been created and of which the manager station is unaware.
Also note that the manager is able to "know" what value of
ipRouteKey is associated with any instances which that manager
creates. The manager need only examine the success or failure of
the SET-REQUEST, a subsequent GET-REQUEST or series of
GET-NEXT-REQUESTs are not needed to ascertain the ipRouteKey of
the new row.
A single SET-REQUEST PDU may contain multiple collections of
varBinds meeting these criteria. In such cases, the agent shall
create multiple new rows. However, note that condition #2
prevents there being multiple collections which refer to the same
row.
Karl Auerbach DRAFT [Page 13]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
5. New IP Addressing Table
5.1 Contents
5.2 Adding News Rows to the new addressing table
Karl Auerbach DRAFT [Page 14]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
REFERENCES
[1] M. Rose, K. McCloghrie, Management Information Base for
Network Management of TCP/IP-based Internets: MIB-II,
Internet Working Group RFC draft, Network Information
Center, SRI International, Menlo Park, California, (Dec,
1990)
[2] M. Rose, K. McCloghrie, Management Information Base for
Network Management of TCP/IP-based Internets, Internet
Working Group RFC 1156, Network Information Center, SRI
International, Menlo Park, California, (May, 1990)
Karl Auerbach DRAFT [Page 15]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
Management Information Base for
IP Routing Table
9:51 PM March 7, 1991
Karl Auerbach
Sun Microsystems
karl@eng.sun.com
ABSTRACT
This document proposes replacements for the MIB-II IP routing and
addressing tables. The new routing table supports multiple
routes to the same destination; the new addressing table supports
multiple IP addresses for the same interface.
The new tables are derived from, but are more clearly defined
then their predecessors. In particular, specific procedures are
defined to create new instances of conceptual rows for the new
tables.
This document proposes changes to the MIB. These proposals do
not effect the operation of the SNMP protocol itself.
+--------------------------------------------+
| DRAFT |
+--------------------------------------------+
Karl Auerbach DRAFT [Page i]
RFC WXYZ draft Enhanced IP MIB Tables March 1991
For Routing and Addressing
Table of Contents
1. Status of this Memo 1
2. Introduction 1
3. Deprecation of MIB-II IP Tables 2
4. New IP Routing Table 3
4.1 Contents 3
4.2 Adding New Rows to new routing table 9
4.2.1 SET-REQUEST PDU Content Requirements 10
4.2.2 Error Conditions 11
4.2.3 Agent Behavior 12
4.2.3.1 SNMP Triggered Agent Behavior 12
4.2.3.2 Autonomous Creation of ipRouteEntry Instances 12
4.2.4 Manager Behavior 12
4.2.5 General Comments on Row Creation 13
5. New IP Addressing Table 14
5.1 Contents 14
5.2 Adding News Rows to the new addressing table 14
Karl Auerbach DRAFT [Page ii]
- Latest draft of my IP table document Karl Auerbach
- Latest draft of my IP table document Karl Auerbach