GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1354

Network Working Group F. Baker Request For Comments: 1354 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

Baker [Page 1] RFC 1354 IP Forwarding Table MIB July 1992

 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].

Baker [Page 2] RFC 1354 IP Forwarding Table MIB July 1992

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;
  1. - This MIB module uses the extended OBJECT-TYPE macro as
  2. - 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 }
  1. - IP Forwarding Table
  1. - The IP Forwarding Table obsoletes and replaces the ipRoute
  2. - Table current in MIB-I and MIB-II. It adds knowledge of

Baker [Page 3] RFC 1354 IP Forwarding Table MIB July 1992

  1. - the autonomous system of the next hop, multiple next hop
  2. - 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

Baker [Page 4] RFC 1354 IP Forwarding Table MIB July 1992

                   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-

Baker [Page 5] RFC 1354 IP Forwarding Table MIB July 1992

              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 }
  1. - The following convention is included for specification
  2. - of TOS Field contents. At this time, the Host Requirements
  3. - and the Router Requirements documents disagree on the width
  4. - of the TOS field. This mapping describes the Router
  5. - Requirements mapping, and leaves room to widen the TOS field
  6. - 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

Baker [Page 6] RFC 1354 IP Forwarding Table MIB July 1992

                  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

Baker [Page 7] RFC 1354 IP Forwarding Table MIB July 1992

              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
  1. - the following are all dynamic
  2. - 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

Baker [Page 8] RFC 1354 IP Forwarding Table MIB July 1992

              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 }

Baker [Page 9] RFC 1354 IP Forwarding Table MIB July 1992

       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.

Baker [Page 10] RFC 1354 IP Forwarding Table MIB July 1992

              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.

Baker [Page 11] RFC 1354 IP Forwarding Table MIB July 1992

 [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

Baker [Page 12]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1354.txt · Last modified: 1992/07/02 21:56 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki