Your comments please
Karl Auerbach <karl@eng.sun.com> Sat, 02 March 1991 01:57 UTC
Received: from nisc.psi.net by NRI.NRI.Reston.VA.US id aa18791; 1 Mar 91 20:57 EST
Received: by nisc.psi.net (5.61/2.1-PSINet Operations ) id AA10453; Fri, 1 Mar 91 20:12:51 -0500
Received: from nisc.nyser.net by nisc.psi.net (5.61/2.1-PSINet Operations ) id AA10449; Fri, 1 Mar 91 20:12:45 -0500
Received: from Sun.COM by nisc.nyser.net (5.61/2.1-) id AA03259; Fri, 1 Mar 91 20:11:09 -0500
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA05444; Fri, 1 Mar 91 17:14:40 PST
Received: from lvs.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA22469; Fri, 1 Mar 91 17:21:09 PST
Received: by lvs.Eng.Sun.COM (4.1/SMI-4.1) id AA00681; Fri, 1 Mar 91 17:15:53 PST
Date: Fri, 01 Mar 1991 17:15:53 -0800
From: Karl Auerbach <karl@eng.sun.com>
Message-Id: <9103020115.AA00681@lvs.Eng.Sun.COM>
To: snmp-wg@nisc.nyser.net
Subject: Your comments please
Status: O
I've taken a crack at the ipRouting table problem in the MIBs.
You know... the problem about multiple routes to the same destination.
Anyway, I'd really appreciate some feedback before I invest much more
effort.
(If anyone is interested there is also a Postscript version.)
Thanks,
--karl--
---------cut here----------
RFC WXYZ draft IP Routing Table MIB Feb 1991
Management Information Base for
IP Routing Table
5:19 PM February 28, 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>.
+--------------------------------------------+
| DRAFT |
+--------------------------------------------+
Karl Auerbach [Page 1]
RFC WXYZ draft IP Routing Table MIB Feb 1991
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.
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.
3. Deprecation of MIB-II ipRouteTable
The status of the existing ipRouteTable and all variables
contained within that table are changed to "deprecated".
Karl Auerbach [Page 2]
RFC WXYZ draft IP Routing Table MIB Feb 1991
In other words, the definition of ipRouteTable in MIB-II is
modified as follows:
ipRouteTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpRouteEntry
ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"This entity's IP Routing table."
::= { ip 21 }
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.
Karl Auerbach [Page 3]
RFC WXYZ draft IP Routing Table MIB Feb 1991
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.
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 }
Karl Auerbach [Page 4]
RFC WXYZ draft IP Routing Table MIB Feb 1991
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 }
ipRouteMetric1 OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
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
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
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 }
Karl Auerbach [Page 5]
RFC WXYZ draft IP Routing Table MIB Feb 1991
ipRouteMetric4 OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
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 }
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 }
Karl Auerbach [Page 6]
RFC WXYZ draft IP Routing Table MIB Feb 1991
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.
}
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 [Page 7]
RFC WXYZ draft IP Routing Table MIB Feb 1991
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
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
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 [Page 8]
RFC WXYZ draft IP Routing Table MIB Feb 1991
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
55.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."
::= { ipRouteEntry 11 }
ipRouteMetric5 OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
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 }
ipRouteInfo OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-write
STATUS mandatory
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 }
Karl Auerbach [Page 9]
RFC WXYZ draft IP Routing Table MIB Feb 1991
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
An SNMP agent shall create a new instance of IpRouteEntry for
each contiguous block of varBinds contained in an otherwise valid
a SET-REQUEST PDU meeting the following criteria:
1. The contiguous block of varBinds contains entries for each
of:
VARIABLE VALUE
ipRouteDest Equal to that in the index.
ipRouteIfIndex In range (1..ifNumber)
ipRouteMetric1 An appropriate value
ipRouteMetric2 An appropriate value
ipRouteMetric3 An appropriate value
ipRouteMetric4 An appropriate value
ipRouteNextHop An appropriate value
ipRouteType other(1), direct(3), or indirect(4)
ipRouteProto Local(2)
ipRouteAge Zero
ipRouteMask An appropriate value
ipRouteMetric5 An appropriate value
ipRouteInfo { 0 0 }
ipRouteKey. Equal to that in the index.
2. These entries must appear in the order shown, with no gaps
and with no intervening entries.
3. The ipRouteDest portion of the index of all such entries
must be identical.
4. The ipRouteKey portion of the index of all such entries
must be identical. The value if the ipRouteKey portion of
the index identifies the ipRouteKey to be assigned to the
row to be created.
Karl Auerbach [Page 10]
RFC WXYZ draft IP Routing Table MIB Feb 1991
5. The index of all such entries must refer to an nonexistent
instance of IpRouteEntry or one in which ipRouteType is
"invalid (2)".
If any of conditions #1, #2, #3, or #4 are violated the block of
varBinds is considered a collection of unrelated varBinds which
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 #4 are met but condition #5 fails (due
the existence of a valid row), then the SET-REQUEST shall be
rejected with a badValue error with the error index referencing
the first varBind of the block.
(Note that a route which is marked as "invalid" is considered as
nonexistent for the purposes of condition #5. Thus a block of
varBinds which meets all of the above conditions with respect to
an existing, but "invalid" row has the effect of resurrecting
that row.)
Note that presence of ipRouteKey at the end of a block 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 #5 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 contiguous blocks
of varBinds meeting these criteria. In such cases, the agent
shall create multiple new rows.
In the situation where a single SET-REQUEST PDU contains multiple
contiguous blocks bearing the same instance, the agent shall
create only one new row for that instance.
It would have been feasible to relax the conditions #1 and #2 so
that the set of necessary variables could be scattered throughout
a PDU and occur in any order. But to do so would add unnecessary
complexity to the agent.
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.
Karl Auerbach [Page 11]
RFC WXYZ draft IP Routing Table MIB Feb 1991
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).
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 with a
block 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.3 Practical Matters
It is suggested that agents generate even values of ipRouteKey
and managers generate odd values.
It is suggested that manager stations include some randomizing
method within the generation of ipRouteKey values. The purpose
is to perform a "randomized backoff" to avoid persistent
collisions between two manager stations trying to create a row.
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.
Karl Auerbach [Page 12]
RFC WXYZ draft IP Routing Table MIB Feb 1991
5. New IP Addressing Table
5.1 Contents
5.2 Adding News Rows to the new addressing table
5.3 Practical Matters
Karl Auerbach [Page 13]
RFC WXYZ draft IP Routing Table MIB Feb 1991
[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 [Page 14]
- Your comments please Karl Auerbach
- Your comments please Jeremy Greene