ACC
July 1992
IP Forwarding Table MIB
Status of this Memo
-
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Abstract
-
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing routes in the IP Internet.
It is proposed that the ipRouteTable defined by MIB-II (RFC 1213) be deprecated and replaced with this table. This adds the ability to set or display multi-path routes, and varying routes by network management policy.
Table of Contents
-
1. The Network Management Framework ............................ 1 2. Objects ..................................................... 2 2.1 Format of Definitions ...................................... 2 3. Overview .................................................... 3 3.1 Structure of MIB ........................................... 3 4. Definitions ................................................. 4 4.1 IP Forwarding Table ........................................ 4 5. Acknowledgements ............................................ 11 6. References .................................................. 11 7. Security Considerations........................................ 12 8. Author's Address............................................... 12
1. The Network Management Framework
-
The Internet-standard Network Management Framework consists of three components. They are:
RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI.
RFC 1156 which defines MIB-I, the core set of managed objects for the Internet suite of protocols. RFC 1213 defines MIB-II, an evolution of MIB-I based on implementation experience and new operational requirements.
RFC 1157 which defines the SNMP, the protocol used for network access to managed objects.
The Framework permits new objects to be defined for the purpose of experimentation and evaluation.
2. Objects
-
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) [7] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the OBJECT DESCRIPTOR, to also refer to the object type.
The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [3] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity.
The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network.
The SMI specifies the use of the basic encoding rules of ASN.1 [8], subject to the additional requirements imposed by the SNMP.
2.1. Format of Definitions
-
Section 4 contains contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [9].
3. Overview
3.1. Structure of MIB
-
The IP Forwarding Table is quite analogous to the older ipRoute Table. The principal differences are:
-
(1) It is somewhat re-organized, for aesthetic reasons,
(2) It has the Next Hop Autonomous System Number, useful
-
primarily to the administrators of regional networks,
-
-
(3) It is instanced by Policy and Next Hop as well as by
-
ultimate destination. Thus, multiple multipath routes can be managed, not just a single route, along with the circumstances under which the any given route might be chosen.
-
4. Definitions
-
-
RFC1354-MIB DEFINITIONS ::= BEGIN
IMPORTS
Gauge, IpAddress FROM RFC1155-SMI mib-2, ip FROM RFC1213-MIB OBJECT-TYPE FROM RFC-1212; -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [9]. ipForward OBJECT IDENTIFIER ::= { ip 24 }-
-
ipForwardNumber OBJECT-TYPE
-
SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "The number of current ipForwardTable entries that are not invalid." ::= { ipForward 1 }-
-- IP Forwarding Table
-- The IP Forwarding Table obsoletes and replaces the ipRoute -- Table current in MIB-I and MIB-II. It adds knowledge of
-- the autonomous system of the next hop, multiple next hop -- support, and policy routing support.
-
ipForwardTable OBJECT-TYPE
-
SYNTAX SEQUENCE OF IpForwardEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This entity's IP Routing table." REFERENCE "RFC 1213 Section 6.6, The IP Group" ::= { ipForward 2 }-
-
ipForwardEntry OBJECT-TYPE
-
SYNTAX IpForwardEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A particular route to a particular destina- tion, under a particular policy." INDEX { ipForwardDest, ipForwardProto, ipForwardPolicy, ipForwardNextHop } ::= { ipForwardTable 1 }-
-
IpForwardEntry ::=
-
SEQUENCE {
-
ipForwardDest IpAddress, ipForwardMask IpAddress, ipForwardPolicy INTEGER, ipForwardNextHop IpAddress, ipForwardIfIndex INTEGER, ipForwardType INTEGER, ipForwardProto INTEGER, ipForwardAge INTEGER, ipForwardInfo OBJECT IDENTIFIER, ipForwardNextHopAS INTEGER, ipForwardMetric1 INTEGER, ipForwardMetric2 INTEGER, ipForwardMetric3 INTEGER, ipForwardMetric4 INTEGER, ipForwardMetric5 INTEGER }-
-
ipForwardDest OBJECT-TYPE
-
SYNTAX IpAddress ACCESS read-only 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. This object may not take a Multicast (Class D) address value. Any assignment (implicit or otherwise) of an instance of this object to a value x must be rejected if the bitwise logical-AND of x with the value of the corresponding instance of the ipForwardMask object is not equal to x." ::= { ipForwardEntry 1 }-
-
ipForwardMask 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 ipForwardDest field. For those systems that do not support arbitrary subnet masks, an agent constructs the value of the ipForwardMask by reference to the IP Ad--
-
-
dress Class.
-
-
Any assignment (implicit or otherwise) of an instance of this object to a value x must be rejected if the bitwise logical-AND of x with the value of the corresponding instance of the ipForwardDest object is not equal to ipForward- Dest." DEFVAL { '00000000'h } -- 0.0.0.0 ::= { ipForwardEntry 2 }-
-
-- The following convention is included for specification -- of TOS Field contents. At this time, the Host Requirements -- and the Router Requirements documents disagree on the width -- of the TOS field. This mapping describes the Router -- Requirements mapping, and leaves room to widen the TOS field -- without impact to fielded systems.
ipForwardPolicy OBJECT-TYPE
-
SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The general set of conditions that would cause the selection of one multipath route (set of next hops for a given destination) is referred to as 'policy'. Unless the mechanism indicated by ipForwardPro- to specifies otherwise, the policy specifier is the IP TOS Field. The encoding of IP TOS is as specified by the following convention. Zero indicates the default path if no more specific policy applies. +-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | PRECEDENCE | TYPE OF SERVICE | 0 | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+ IP TOS IP TOS Field Policy Field Policy Contents Code Contents Code 0 0 0 0 ==> 0 0 0 0 1 ==> 2 0 0 1 0 ==> 4 0 0 1 1 ==> 6 0 1 0 0 ==> 8 0 1 0 1 ==> 10 0 1 1 0 ==> 12 0 1 1 1 ==> 14 1 0 0 0 ==> 16 1 0 0 1 ==> 18 1 0 1 0 ==> 20 1 0 1 1 ==> 22 1 1 0 0 ==> 24 1 1 0 1 ==> 26 1 1 1 0 ==> 28 1 1 1 1 ==> 30 Protocols defining 'policy' otherwise must ei- ther define a set of values which are valid for this object or must implement an integer- instanced policy table for which this object's value acts as an index." ::= { ipForwardEntry 3 }-
-
ipForwardNextHop OBJECT-TYPE
-
SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "On remote routes, the address of the next sys- tem en route; Otherwise, 0.0.0.0." ::= { ipForwardEntry 4 }-
-
ipForwardIfIndex OBJECT-TYPE
-
SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The ifIndex value which identifies the local interface through which the next hop of this route should be reached." DEFVAL { 0 } ::= { ipForwardEntry 5 }-
-
ipForwardType OBJECT-TYPE
-
SYNTAX INTEGER { other (1), -- not specified by this MIB invalid (2), -- logically deleted local (3), -- local interface remote (4) -- remote destination } ACCESS read-write STATUS mandatory DESCRIPTION "The type of route. Note that local(3) refers to a route for which the next hop is the final destination; remote(4) refers to a route for which the next hop is not the final destina- tion. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the ipForwardTable object. That is, it effectively disassociates the destination identified with said entry from the route iden- tified 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 current- ly in use. Proper interpretation of such en- tries requires examination of the relevant ip- ForwardType object." DEFVAL { invalid } ::= { ipForwardEntry 6 }-
-
ipForwardProto OBJECT-TYPE
-
SYNTAX INTEGER { other (1), -- not specified local (2), -- local interface netmgmt (3), -- static route icmp (4), -- result of ICMP Redirect -- the following are all dynamic -- routing protocols egp (5), -- Exterior Gateway Protocol ggp (6), -- Gateway-Gateway Protocol hello (7), -- FuzzBall HelloSpeak rip (8), -- Berkeley RIP or RIP-II is-is (9), -- Dual IS-IS es-is (10), -- ISO 9542 ciscoIgrp (11), -- Cisco IGRP bbnSpfIgp (12), -- BBN SPF IGP ospf (13), -- Open Shortest Path First bgp (14), -- Border Gateway Protocol idpr (15) -- InterDomain Policy Routing } ACCESS read-only STATUS mandatory DESCRIPTION "The routing mechanism via which this route was learned. Inclusion of values for gateway rout- ing protocols is not intended to imply that hosts should support those protocols." ::= { ipForwardEntry 7 }-
-
ipForwardAge OBJECT-TYPE
-
SYNTAX INTEGER ACCESS read-only 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." DEFVAL { 0 } ::= { ipForwardEntry 8 }-
-
ipForwardInfo OBJECT-TYPE
-
SYNTAX OBJECT IDENTIFIER ACCESS read-write STATUS mandatory DESCRIPTION "A reference to MIB definitions specific to the particular routing protocol which is responsi- ble for this route, as determined by the value specified in the route's ipForwardProto value. If this information is not present, its value should be set to the OBJECT IDENTIFIER { 0 0 }, which is a syntactically valid object identif- ier, and any implementation conforming to ASN.1 and the Basic Encoding Rules must be able to generate and recognize this value." DEFVAL { { 0 0 } } -- 0.0 ::= { ipForwardEntry 9 }-
-
ipForwardNextHopAS OBJECT-TYPE
-
SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The Autonomous System Number of the Next Hop. When this is unknown or not relevant to the protocol indicated by ipForwardProto, zero." DEFVAL { 0 } ::= { ipForwardEntry 10 }-
-
ipForwardMetric1 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 ipForwardProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { ipForwardEntry 11 }-
-
ipForwardMetric2 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 ipForwardProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { ipForwardEntry 12 }-
-
ipForwardMetric3 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 ipForwardProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { ipForwardEntry 13 }-
-
ipForwardMetric4 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 ipForwardProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { ipForwardEntry 14 }-
-
ipForwardMetric5 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 ipForwardProto value. If this metric is not used, its value should be set to -1." DEFVAL { -1 } ::= { ipForwardEntry 15 } END -
5. Acknowledgements
-
This document was produced by the Router Requirements Working Group, of which Phil Almquist is the chair.
Chris Gunner (DEC) and Keith McCloghrie (Hughes LAN Systems) made significant comments on it, and it is better for their input.
6. References
-
[1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, NRI, April 1988. [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, NRI, August 1989. [3] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [4] McCloghrie K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1156, Hughes LAN Systems, Performance Systems International, May 1990. [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [6] McCloghrie K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1213, Performance Systems International, March 1991. [7] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. [8] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. [9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [10] McCloghrie K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1213, Performance Systems International, March 1991. [11] Baker, F., and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1253, ACC, Computer Science Center, August 1991.
7. Security Considerations
-
Security issues are not discussed in this memo.
8. Author's Address
-
Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, CA 93117-6014
Phone:
(805) 685-4455
EMail:
fbaker@acc.com