rfc2096.txt

RFC 的详细文档！

Network Working Group                                           F. Baker
Request for Comments: 2096                                 Cisco Systems
Obsoletes: 1354                                             January 1997
Category: Standards Track


                        IP Forwarding Table MIB

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Table of Contents

   1. Introduction ..........................................    1
   2. The SNMP Network Management Framework .................    2
   2.1 Object Definitions ...................................    2
   3. Overview ..............................................    2
   4. Definitions ...........................................    3
   5. Acknowledgements ......................................   20
   6. References ............................................   20
   7. Security Considerations ...............................   21
   8. Author's Address ......................................   21


1.  Introduction

   This memo defines an update to RFC 1354, "IP Forwarding Table MIB",
   for Classless Inter-Domain Routing (CIDR).  That document was
   developed by the Router Requirements Working Group as an update to
   RFC 1213's ipRouteTable, with the display of multiple routes as
   a primary objective.  The significant difference between this MIB and
   RFC 1354 is the recognition (explicitly discussed but by consensus
   left to future work) that CIDR routes may have the
   same network number but different network masks.  Note that this MIB
   obsoletes a number of objects from RFC 1354.  The reader should pay
   careful attention to the STATUS field.










Baker                       Standards Track                     [Page 1]

RFC 2096                IP Forwarding Table MIB             January 1997


2.  The SNMP Network Management Framework

   The SNMP Network Management Framework presently consists of three
   major components.  They are:

   o    the SMI, described in RFC 1902 [1], - the mechanisms used
        for describing and naming objects for the purpose of
        management.

   o    the MIB-II, STD 17, RFC 1213 [2], - the core set of
        managed objects for the Internet suite of protocols.

   o    the protocol, RFC 1157 [6] and/or RFC 1905 [4], - the
        protocol for accessing managed information.

   Textual conventions are defined in RFC 1903 [3], and conformance
   statements are defined in RFC 1904 [5].

   The Framework permits new objects to be defined for the purpose of
   experimentation and evaluation.

2.1.  Object Definitions

   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)
   defined in the SMI.  In particular, each object object type is named
   by an OBJECT IDENTIFIER, an administratively assigned name.  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
   descriptor, to refer to the object type.

3.  Overview

   The MIB consists of two tables and two global objects.

   (1)  The object ipForwardNumber indicates the number of
        current routes.  This is primarily to avoid having to
        read the table in order to determine this number.

   (2)  The ipForwardTable updates the RFC 1213 ipRouteTable to
        display multipath IP Routes.  This is in turn obsoleted
        by the ipCidrRouteTable.

   (3)  The ipCidrRouteTable updates the RFC 1213 ipRouteTable to
        display multipath IP Routes having the same network
        number but differing network masks.



Baker                       Standards Track                     [Page 2]

RFC 2096                IP Forwarding Table MIB             January 1997


4.  Definitions

IP-FORWARD-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, IpAddress, Integer32, Gauge32
        FROM SNMPv2-SMI
    RowStatus
        FROM SNMPv2-TC
    ip
        FROM RFC1213-MIB
    MODULE-COMPLIANCE, OBJECT-GROUP
        FROM SNMPv2-CONF;

ipForward MODULE-IDENTITY
    LAST-UPDATED "9609190000Z"     -- Thu Sep 26 16:34:47 PDT 1996
    ORGANIZATION "IETF OSPF Working Group"
    CONTACT-INFO
     "        Fred Baker
      Postal: Cisco Systems
              519 Lado Drive
              Santa Barbara, California 93111

      Phone:  [phone]
      Email:  [e-mail]
      "
    DESCRIPTION
            "The MIB module for the display of CIDR multipath IP Routes."
    REVISION      "9609190000Z"
    DESCRIPTION
            "Revisions made by the OSPF WG."
    ::= { ip 24 }

ipCidrRouteNumber OBJECT-TYPE
    SYNTAX   Gauge32
    MAX-ACCESS read-only
    STATUS   current
    DESCRIPTION
       "The number of current ipCidrRouteTable entries
       that are not invalid."
    ::= { ipForward 3 }

--  IP CIDR Route Table

--  The IP CIDR Route Table obsoletes and replaces the ipRoute
--  Table current in MIB-I and MIB-II and the IP Forwarding Table.
--  It adds knowledge of the autonomous system of the next hop,
--  multiple next hops, and policy routing, and Classless



Baker                       Standards Track                     [Page 3]

RFC 2096                IP Forwarding Table MIB             January 1997


--  Inter-Domain Routing.

ipCidrRouteTable OBJECT-TYPE
    SYNTAX   SEQUENCE OF IpCidrRouteEntry
    MAX-ACCESS not-accessible
    STATUS   current
    DESCRIPTION
       "This entity's IP Routing table."
    REFERENCE
       "RFC 1213 Section 6.6, The IP Group"
    ::= { ipForward 4 }

ipCidrRouteEntry OBJECT-TYPE
    SYNTAX   IpCidrRouteEntry
    MAX-ACCESS not-accessible
    STATUS   current
    DESCRIPTION
       "A particular route to  a  particular  destina-
       tion, under a particular policy."
    INDEX {
        ipCidrRouteDest,
        ipCidrRouteMask,
        ipCidrRouteTos,
        ipCidrRouteNextHop
        }
    ::= { ipCidrRouteTable 1 }

IpCidrRouteEntry ::=
    SEQUENCE {
        ipCidrRouteDest
            IpAddress,
        ipCidrRouteMask
            IpAddress,
        ipCidrRouteTos
             Integer32,
        ipCidrRouteNextHop
            IpAddress,
        ipCidrRouteIfIndex
            Integer32,
        ipCidrRouteType
            INTEGER,
        ipCidrRouteProto
            INTEGER,
        ipCidrRouteAge
            Integer32,
        ipCidrRouteInfo
            OBJECT IDENTIFIER,
        ipCidrRouteNextHopAS



Baker                       Standards Track                     [Page 4]

RFC 2096                IP Forwarding Table MIB             January 1997


            Integer32,
        ipCidrRouteMetric1
            Integer32,
        ipCidrRouteMetric2
            Integer32,
        ipCidrRouteMetric3
            Integer32,
        ipCidrRouteMetric4
            Integer32,
        ipCidrRouteMetric5
            Integer32,
        ipCidrRouteStatus
            RowStatus
    }

ipCidrRouteDest OBJECT-TYPE
    SYNTAX   IpAddress
    MAX-ACCESS read-only
    STATUS   current
    DESCRIPTION
       "The destination IP address of this 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
       ipCidrRouteMask object is not equal to x."
    ::= { ipCidrRouteEntry 1 }

ipCidrRouteMask OBJECT-TYPE
    SYNTAX   IpAddress
    MAX-ACCESS read-only
    STATUS   current
    DESCRIPTION
       "Indicate the mask to be logical-ANDed with the
       destination  address  before  being compared to
       the value  in  the  ipCidrRouteDest  field.   For
       those  systems  that  do  not support arbitrary
       subnet masks, an agent constructs the value  of
       the  ipCidrRouteMask  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



Baker                       Standards Track                     [Page 5]

RFC 2096                IP Forwarding Table MIB             January 1997


       the  value of the corresponding instance of the
       ipCidrRouteDest object is not equal to ipCidrRoute-
       Dest."
    ::= { ipCidrRouteEntry 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.

ipCidrRouteTos OBJECT-TYPE
    SYNTAX   Integer32
    MAX-ACCESS read-only
    STATUS   current
    DESCRIPTION
       "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"
    ::= { ipCidrRouteEntry 3 }

ipCidrRouteNextHop OBJECT-TYPE
    SYNTAX   IpAddress
    MAX-ACCESS read-only
    STATUS   current
    DESCRIPTION
       "On remote routes, the address of the next sys-
       tem en route; Otherwise, 0.0.0.0."



Baker                       Standards Track                     [Page 6]

RFC 2096                IP Forwarding Table MIB             January 1997


    ::= { ipCidrRouteEntry 4 }

ipCidrRouteIfIndex OBJECT-TYPE
    SYNTAX   Integer32
    MAX-ACCESS read-create
    STATUS   current
    DESCRIPTION
       "The ifIndex value which identifies  the  local
       interface  through  which  the next hop of this
       route should be reached."
    DEFVAL { 0 }
    ::= { ipCidrRouteEntry 5 }

ipCidrRouteType OBJECT-TYPE
    SYNTAX   INTEGER {
                other    (1), -- not specified by this MIB
                reject   (2), -- route which discards traffic
                local    (3), -- local interface
                remote   (4)  -- remote destination
             }
    MAX-ACCESS read-create
    STATUS   current
    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.

       Routes which do not result in traffic forwarding or
       rejection should not be displayed even if the
       implementation keeps them stored internally.


       reject (2) refers to a route which, if matched, discards
       the message as unreachable. This is used in some
       protocols as a means of correctly aggregating routes."
    ::= { ipCidrRouteEntry 6 }

ipCidrRouteProto 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



Baker                       Standards Track                     [Page 7]