NHRP MIB Draft 00
"Michael W. Patrick" <mpatrick@dev.cdx.mot.com> Fri, 17 March 1995 15:15 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02750;
17 Mar 95 10:15 EST
Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US
id aa02738; 17 Mar 95 10:15 EST
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by
maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id KAA09355
for <rolc@maelstrom.timeplex.com>; Fri, 17 Mar 1995 10:00:17 -0500
Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by
motgate.mot.com (8.6.10/8.6.10/MOT-3.5) with ESMTP id JAA00731;
Fri, 17 Mar 1995 09:00:44 -0600
Received: from prospero.dev.cdx.mot.com by pobox.mot.com
(8.6.10/8.6.10/MOT-3.5) with ESMTP id JAA14230;
Fri, 17 Mar 1995 09:00:41 -0600
Received: from dev.cdx.mot.com (hale.dev.cdx.mot.com [150.20.33.27]) by
prospero.dev.cdx.mot.com (8.6.11/8.6.11) with ESMTP id KAA01069;
Fri, 17 Mar 1995 10:00:36 -0500
Message-Id: <199503171500.KAA01069@prospero.dev.cdx.mot.com>
To: rolc@maelstrom.timeplex.com
cc: RFC-Editor@isi.edu
Subject: NHRP MIB Draft 00
Date: Fri, 17 Mar 1995 10:00:35 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Michael W. Patrick" <mpatrick@dev.cdx.mot.com>
RFC Editor, please submit the following as a new internet-draft
<draft-ietf-rolc-nhrp-mib-00.txt>.
Rolc list: please review for Danvers.
Regards,
mike
----- Cut Here -----
ROLC Working Grop Michael Patrick
<draft-ietf-rolc-nhrp-mib-00.txt> Motorola ISG
March 17, 1995
NHRP Management Information Base
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any Internet
Draft. Distribution of this document is unlimited.
Table of Contents
<??? tbd>
1 Introduction
This document provides the Management Information Base (MIB) for the
Next Hop Routing Protocol (NHRP). The NHRP protocol is a protocol
for allowing IP source stations on a switched Non Broadcast Multiple
Access (NBMA) network such as ATM or X.25 to determine the NBMA
switched circuit (i.e. "physical") address of other stations attached
to the same NBMA network. Protocols such as ARP provide this
function only for IP destinations in the same Logical IP Subnet (LIS)
as the source. NHRP permits this resolution for destinations on a
different LIS. NHRP is described in [NHRP].
2 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
Expires Sept. 1995 [Page 1]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
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.
The SNMPv2 Network Management Framework consists of four major
components. They are:
0 RFC 1442 which defines the SMI, the mechanisms used
for describing and naming objects for the purpose of
management.
0 STD 17, RFC 1213 defines MIB-II, the core set of
managed objects for the Internet suite of protocols.
0 RFC 1445 which defines the administrative and other
architectural aspects of the framework.
0 RFC 1448 which defines the protocol used for network
access to managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
3 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)
[ASN] 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
Expires Sept. 1995 [Page 2]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
this purpose. However, the SMI [RFC1155] 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 [BER]
subject to the additional requirements imposed by the SNMP.
3.1. Format of Definitions
Section 5 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 [RFC1212]
4. Overview
4.1. Textual Conventions
Several new data types are introduced as a textual convention in this
MIB document. These textual conventions enhance the readability of
the specification and can ease comparison with other specifications
if appropriate. It should be noted that the introduction of the
these textual conventions has no effect on either the syntax nor the
semantics of any managed objects. The use of these is merely an
artifact of the explanatory method used. Objects defined in terms of
one of these methods are always encoded by means of the rules that
define the primitive type. Hence, no changes to the SMI or the SNMP
are necessary to accommodate these textual conventions which are
adopted merely for the convenience of readers and writers in pursuit
of the elusive goal of clear, concise, and unambiguous MIB documents.
4.2 Structure of MIB
The MIB is composed of the following sections:
NHRP Interface Table
NHRP Server Table
NHRP Address Table
NHRP Stats Table
There are no "general" variables for NHRP operation.
The NHRP Interface table defines the NHRP "entities" which generate
Expires Sept. 1995 [Page 3]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
and receive NHRP packets on an NBMA network. In general, an NHRP
entity is defined for each Logical IP Subnet (LIS) to which the
station belongs. The LIS entity is defined by an IP address and an
Interface Index. NHRP operation is separately controlled for each
LIS.
The NHRP Server Table defines the other NHRP Next Hop Servers (NHSs)
that are known to the local station. Each entry provides a mapping
of a served IP network address range and an NHS which can resolve
NBMA link level addresses for IP hosts in that range. If the local
station is an NHS itself, entries in the Server Table define the
range of IP network addresses served by the local station.
The NHRP Address Table is the "ARP cache" for NHRP, holding mappings
of IP host addresses to NBMA link level addresses.
The NHRP Stats Table keeps counts of events for each NHRP entity,
i.e. each LIS to which the station belongs.
4.2.1 IP numbering models with virtual circuits
How virtual circuits over a physical interface are represented in a
MIB, especially the ifTable and ipAddrTable, is somewhat complex.
There are three principal models, which can be characterized by the
type of IP address that is associated with each virtual circuit. The
three models are:
1) "Net-numbered" circuits
2) "Host-numbered" circuits
3) "Unnumbered" circuits
A net-numbered circuit is assigned its own unique IP network number,
and each end of the link is assigned different host addresses on that
net number. Such net numbers are frequently subnets with a mask
255.255.255.252, i.e. with only the two host numbers ending in 01 or
10 bits (00 and 11 host numbers are reserved). With net-numbered
circuits, a device has an ifIndex value for each circuit, and an
ipAddrTable entry for each circuit. Net-numbered models are useful
in partial-mesh configurations. If a switched virtual circuit is
configured as a net-numbered link, it forms its own (small) LIS.
A host-numbered circuit approach is frequently used in star or full-
mesh configurations, where the root which terminates all of the
circuits has a single IP host address, and the far endpoints are
assigned host numbers on the same IP network as the root host
address. From the root's point of view, each circuit corresponds to
Expires Sept. 1995 [Page 4]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
a host number. This is the Non Broadcast Multiple Access (NBMA)
approach, i.e. where there are multiple possible destination on the
same LIS, but broadcast to them is not possible. This model is also
principally used for switched networks such as ATM or X25, where
any-to-any communication is potentially possible. In the host-
numbered or NBMA model, a station may or may not have ifIndex entries
for each circuit, but it certainly has only a single ipAddrTable
entry for the LIS attachment.
Finally, unnumbered circuits are used between routers, and avoid the
complexities and administrative burden of circuit host or net
numbering. Each router must broadcast reachable network information
using a routing protocol. In this case, ifIndex entries may or may
not exist for the circuit, and an ipAddrTable entry certainly does
not. Routing protocols associate some other IP address of the router
as the "Router ID" for identification purposes on the unnumbered
circuit. Unnumbered links typically use static routing or OSPF
routing with "unnumbered point to point" type interfaces. RIP cannot
be used because there is no network mask with which to interpret the
IP Network addresses on received advertisemetns.
As for ifIndex values in the Interfaces table, a managed device at a
minimum will have an ifIndex value for each physical port connected
to an ATM, X25 or other switched network. Stations may or may not
implement the recommendations of RFC1573, which calls for "logical"
ifIndex values when multiple logical circuits are multiplexed over a
physical circuit. These "logical" ifIndex values are especially
useful when the net-numbered model is used. Note that a unique
logical ifIndex value is required if the "unnumbered" circuit model
is used; the ipRouteTable indicates routes to the other router by
using an ifIndex value rather than a ipRouteNextHop IP host address.
4.2.2 NHRP's circuit model
The NHRP protocol can be defined to operate on each of the above
circuit numbering models. The basic idea is that NHRP can be managed
based on LIS, and that tuple of { nhrpIpAddr, nhrpIfIndex} uniquely
identifies an LIS for management purposes.
For net-numbered circuits, each circuit forms its own Logical IP
Subnet (LIS). The nhrpIpAddr value is the IP address assigned to the
local end of the circuit. If RFC1573 is not implemented,
nhrpIfIndex is the ifIndex value assigned to the physical
ATM/X25/FR/SMDS port. If RFC1573 is implemented, the nhrpIfIndex
value is the ifIndex assinged to the virtual circuit.
Expires Sept. 1995 [Page 5]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
For host-numbered circuits, i.e. the usual NBMA model, the set of
circuits belonging to a given administered IP subnetwork number form
the LIS. The station is assigned an IP host address in that
subnetwork to establish its identity on the LIS, and this forms
nhrpIpAddr. In this model, each virtual circuit is recommended in
RFC1573 to NOT be assigned its own ifIndex value, so the nhrpIfIndex
value is the physical port ifIndex. Different sets of circuits may be
assigned to different subnets, in which case each set forms its own
LIS. The station will have a local IP host address on each LIS. So
there may be many combinations of { nhrpIpAddr, nhrpIfIndex } with
the same physical nhrpIfIndex value.
Unnumbered links between routers may be established, typically with
permanent virtual circuits. Routers originating messages on these
unnubered links use as their source address a "Router ID" (per
Router Requirements), which is the router's IP address on some
-other- interface. The destination IP address of originated messages
is usually either a multicast or broadcast, e.g. a RIP advertisement.
NHRP messages may also be originated and received on such links
between routers. Since the source IP address (Router ID) of NHRP
messages received on such a link will be on a net otherwise routed to
some -other- interface of the originating router, the -receiver- of
such messages must associate -both- the source IP address and its
incoming interface (ifIndex) with the received message in order to
respond correctly. For this reason, unnumbered links must have their
own ifIndex value, and NHRP associates both an IP Address (our local
Router ID) and an incoming ifIndex value with NHRP messages exchanged
on the unnumbered link.
It is asserted that the { IpAddr, IfIndex } tuple can uniquely
identify any virtual circuit over which IP packets can be received or
transmitted. For this reason, the { nhrpIpAddr, nhrpIfIndex } tuple
is used to distinguish an nhrp "interface", which is the basic unit
of NHRP management.
4.2.2 Cut-through circuits
The principal purpose of NHRP is to enable "cut-through" circuits in
an NBMA network, but NHRP does not specify how those circuits are
established, how and when they are torn down, the packets exchanged
on the new circuit, or the routing decisions for forwarding packets
on that new circuit.
NHRP is NOT a routing protocol, and the establishment of such a cut-
through circuit should NOT necessarily be considered a new link-level
connection between routers, across which the routers may forward
properly addressed IP packets. If a new link is established between
routers, so that IP packets are to be routed across the new link,
Expires Sept. 1995 [Page 6]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
then the new link must be properly handled by the IP inter-domain or
intra-domain protocols in use at each router. In the absence of
proper routing protocol knowledge of the new link, a "cut through"
circuit can form stable router loops and routing black holes.
Router-to-router cut-throughs must be avoided unless proper routing
protocols are followed.
Cut-through circuits, however, may be appropriate and safe for host-
to-host and host-to-router connections. Hosts must support the
concept of initiating NHRP requests for "foreign" IP host addresses,
and for storing the returned link level address in its ipNetToMedia
(ARP) table. Routers receiving a new circuit request from a host may
establish a "host route" to that host. Again, details of the new
circuit establishment between a host and a remote router are not
specified in NHRP. There may even be a PPP negotiation between the
host and router on the new circuit. From the router's point of view,
such host routes are not necessarily advertised, (due to routing
overhead), but they are used by the router when looking up the next
hop for packets directly addressed to that host.
4.3. Conceptual Row Creation
There are numerous read-write objects in this MIB, as it is designed
for SNMP management of the protocol, not just SNMP monitoring of its
state. However, in the absence of a standard SNMP Security
architecture, it is acceptable for implementations to implement these
as read-only with an alternative interface for their modification.
Rows are created by writing to the EntryStatus object a value of
"invalid". Such created rows are intended to be non-volatile; the
managed object shall retain the row through reset and power on/off
events. Acknowledgement of the SNMP SET command shall constitute
acceptance for non-volatile operation.
For the benefit of row-creation in "conceptual" (see [RFC1212])
tables, DEFVAL (Default Value) clauses are included in the
definitions, suggesting values which an agent should use for
instances of variables which need to be created due to a Set-Request,
but which are not specified in the Set- Request. DEFVAL clauses have
not been specified for some objects which are read-only, implying
that they are zeroed upon row creation. These objects are of the
SYNTAX Counter or Gauge.
For those objects not having a DEFVAL clause, both management
stations and agents should heed the Robustness Principle of the
Internet (see RFC-791):
Expires Sept. 1995 [Page 7]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
"be liberal in what you accept, conservative in what
you send"
That is, management stations should include as many of these columnar
objects as possible (e.g., all read-write objects) in a Set-Request
when creating a conceptual row; agents should accept a Set-Request
with as few of these as they need (e.g., the minimum contents of a
row creating SET consists of those objects for which, as they cannot
be intuited, no default is specified.).
4.4. Default Configuration
<??? TBD>
5. Definitions
NHRP-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
Counter32, Integer32, IpAddress
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, DisplayString,
TimeStamp, RowStatus
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
ifIndex, mib-2
FROM RFC1213-MIB;
nhrpMIB MODULE-IDENTITY
LAST-UPDATED "950310"
ORGANIZATION "IETF ROLC Working Group"
CONTACT-INFO
"Michael Patrick
Postal: Motorola ISG
20 Cabot Blvd., MS M4-30
Mansfield, MA 02048
Tel: +1 508 763 3674
Fax: +1 508 337 7172
E-mail: mpatrick@prospero.dev.cdx.mot.com
"
DESCRIPTION
"This is the MIB Module for the Next Hop Resolution Protocol."
::= { mib-2 ???TBD }
Expires Sept. 1995 [Page 8]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
nhrpMIBObjects OBJECT IDENTIFIER ::= {nhrpMIB 1}
AddressType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The Address Type field of an NHRP packet, which
is an IANA-assigned 8-bit integer to identify the encoding
conventions for switched network addresses.
Different values are required for ATM, X.25, Frame Relay
SVC, POTS, etc."
SYNTAX INTEGER (0..255)
LinkAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The NBMA network address for a virtual circuit capable of
receiving IP datagrams."
SYNTAX OCTET STRING
EnableStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Indicates whether a feature or option is enabled."
SYNTAX INTEGER ( enabled (1), disabled (2) )
IfIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The value of this object identifies the interface
for which the entry contains management
information. The value of this object for a
particular interface has the same value as the
ifIndex object, defined in RFC 1213, for the same
interface."
SYNTAX Integer32
HoldTime ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The number of seconds remaining for which a row entry is valid.
A value of zero indicates that the row entry has expired."
SYNTAX INTEGER (0..'FFFF'h)
NhrpForwardMode ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
Expires Sept. 1995 [Page 9]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
"
SYNTAX INTEGER ( server(1), fabric(2) )
QOSInfo::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Quality of Service information reported by an NHRP server.
Internal syntax and semantics are TBD."
SYNTAX OCTET STRING
NhrpAuthType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Authentication Type code for NHRP traffic."
SYNTAX Integer32 ( none(0), clearTextPassword(1), keyedMD5(2) )
-- NHRP Interface Table
-- An NHRP Interface is an interface which can receive or transmit
-- NHRP packets.
--
nhrpIfTable OBJECT-TYPE
SYNTAX SEQUENCE OF NhrpIfEntry
ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry corresponds to a Logical IP Subnet (LIS) to which
the station attaches on a NBMA network.
NHRP operation is separately managed for each LIS. All
received NHRP packets are associated with an entry in this
table according to the following algorithm:
1) Packets directly addressed to this station are associated
with the row for which nhrpIfIpAddr matches the destination
IP address and the nhrpIfIfIndex matches the incoming
interface.
2) IP broadcast or multicast destination packets received from
host-numbered or net-numbered circuits are associated with
an LIS based on the packet's IP source address and incoming
ifIndex. An entry in the ipAddrTable must be found for
which the packet's incoming ifIndex matches the table's
ipAdEntIfIndex value, and the interface's subnet
(ipAdEntAddr ANDed with ipAdEntNetMask) matches the source's
presumed subnet (source IP Address ANDed with
Expires Sept. 1995 [Page 10]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
ipAdEntNetMask).
The (ipAdEntAddr, ipAdEntIfIndex) of a matching ipAddrTable
row must match an nhrpIfTable row. If more than
one matching ipAddrTable row and nhrpIfTable row exists, the
lowest-numbered nhrpIfAddr value is considered the matched
row.
3) IP multicast or IP broadcast addresses received from
unnumbered interfaces shall be associated with the
nhrpIfTable entryindexed by (Router ID, incoming ifIndex).
(Note that unnumbered router-router interfaces are required
to have a unique ifIndex value for proper representation of
ipRouteTable).
4) IP-forwarded NHRP Replies not addressed to this station are
associated with the LIS of their next-hop IP address,
which is either a host on an attached LIS or another router
on the LIS.
Any incoming NHRP packet discarded because no nhrpIfTable row
could be associated with it shall be silently discarded and
ipInAddrErrors shall be incremented.
"
::= { nhrpMIBObjects 1 }
nhrpIfEntry OBJECT-TYPE
SYNTAX NhrpIfEntry
ACCESS read-write
STATUS current
DESCRIPTION
"The information for a single NHRP Interface.
"
INDEX {
nhrpIfIpAddr
nhrpIfIndex
}
::= { nhrpIfTable 1 }
NhrpIfEntry ::=
SEQUENCE {
nhrpIfIpAddr
IpAddress,
nhrpIfIndex
IfIndex,
nhrpIfAdminStat
EnableStatus,
nhrpIfLinkAddrType
AddressType,
Expires Sept. 1995 [Page 11]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
nhrpIfNetworkID
IpAddress,
nhrpIfForwardMode
NhrpForwardMode,
nhrpIfCacheForwardedReplies
Status,
nhrpIfDirectReplies
Status,
nhrpIfAuthType
INTEGER,
nhrpIfAuthKey
OCTET STRING,
nhrpIfRowStatus
RowStatus
}
nhrpIfIpAddr OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS current
DESCRIPTION
"This object's value identifies a Logical IP Subnet (LIS) to
which the device belongs on an NBMA network. This value
must be a nonmulticast, nonzero IP host address.
An entry in ipAddrTable must exist for this IP address.
Unumbered point-to-point circuits to another router are
considered separate LIS's, and each such circuit shall have
a separate row in this table. For these entries, the
nhrpIfIpAddr value shall be the Router ID assigned to the local
device. The nhrpIfIndex value shall distinguish the particular
unnumbered link.
This value forms the IP source address of all NHRP messages
originated by the device for the LIS corresponding to this row."
::= { nhrpIfEntry 1 }
nhrpIfIndex OBJECT-TYPE
SYNTAX IfIndex
ACCESS read-write
STATUS current
DESCRIPTION
"The ifIndex value for an interface considered to send/receive
NHRP IP packets. The (nhrpIfAddr, nhrpIfIndex) tuple identifies
an LIS to which the device attaches.
Expires Sept. 1995 [Page 12]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
For numbered interfaces, this value must match the value of
ifAdEntIfIndex for a row in ipAddrTable corresponding to the
device's local IP address on the LIS. For unnumbered
interfaces, this must be the unique ifIndex value associated
with the interface.
If multiple levels of logical interfaces
are implemented (RFC1573), this value should be the highest
logical interface considered to receive IP packets. For
example, on ATM devices implementing the ATM MIB (RFC1595),
this shall be the ifIndex value corresponding to the AAL5
entity, with ifType 49.
"
::= { nhrpIfEntry 2 }
nhrpIfAdminStat OBJECT-TYPE
SYNTAX EnableStatus
ACCESS read-write
STATUS current
DESCRIPTION
"This object controls whether NHRP operation is enabled for
the LIS corresponding to the row.
When NHRP is disabled, incoming packets shall increment
nhrpStatsInDisabled. No outgoing packets shall be generated
in response to incoming NHRP packets associated with the LIS."
DEFVAL { enabled(1) }
::= { nhrpIfEntry 3 }
nhrpIfLinkAddrType OBJECT-TYPE
SYNTAX AddressType
ACCESS read-write
STATUS current
DESCRIPTION
"This object identifies the IANA-specified link address type
code
for the NBMA network on which the LIS is implemented.
???TBD Example values for ATM? X25? SMDS?
All nhrpAddrTable entries associated with this nhrpIfTable row
are considered to have nhrpAddrDestLinkAddr values of this type.
"
DEFVAL { ???TBD }
::= { nhrpIfEntry 4 }
nhrpIfNetworkID OBJECT-TYPE
SYNTAX AddressType
Expires Sept. 1995 [Page 13]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
ACCESS read-write
STATUS current
DESCRIPTION
"The NHRP Network ID assigned to the NBMA network to which the
device attaches for this LIS. LISs are not permitted to
span different Network IDs.
"
DEFVAL { 0 }
::= { nhrpIfEntry 5 }
nhrpIfForwardMode OBJECT-TYPE
SYNTAX NhrpForwardMode
ACCESS read-write
STATUS current
DESCRIPTION
"Controls how NHRP Requests associated with this LIS entry
are forwarded. In server(1) mode, the destination IP address
of the NHRP Request is set to the nhrpServerNextHop
from the best matching nhrpServerTable row. In fabric(2) mode,
the destination IP address is set to the next hop router from
normal IP forwarding procedures.
This control applies to the LIS of the next hop router to
which the forwarded Request is sent.
"
DEFVAL { server(1) }
::= { nhrpIfEntry 6 }
nhrpIfCacheForwardedReplies OBJECT-TYPE
SYNTAX EnableStatus
ACCESS read-write
STATUS current
DESCRIPTION
"Controls whether forwarded NHRP Reply packets cause the NHRP
Address Table to be updated with the learned information.
This control applies to the LIS of the next hop router
of the forwarded packet.
"
DEFVAL { enabled(1) }
::= { nhrpIfEntry 7 }
nhrpIfDirectReplies OBJECT-TYPE
SYNTAX EnableStatus
ACCESS read-write
STATUS current
DESCRIPTION
"Controls whether forwarded NHRP Reply packets are sent
directly to the requestor. If enabled(1), this device
Expires Sept. 1995 [Page 14]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
will attempt to establish an NBMA circuit directly to the
requester and forward the NHRP reply on the new circuit.
If disabled(2), the device will reply by normal IP forwarding
mechanisms.
"
DEFVAL { disabled(1) }
::= { nhrpIfEntry 8 }
nhrpIfAuthType OBJECT-TYPE
SYNTAX NhrpAuthType
ACCESS read-write
STATUS current
DESCRIPTION
"The Authentication Type of all packets associated with this
LIS.
Authentication is enabled on a per-LIS basis.
Incoming NHRP packets associated with the LIS for this entry
must have an Authentication Option that properly authenticates.
An incoming NHRP packet failing
authentication is discarded, incrementing nhrpStatsInAuthFails.
The LIS of a transmitted NHRP packet is determined by either its
Destination IP Address (for a directly-attached interface),
or the IP address of the next hop router (for foreign
destinations).
If this value is zero, authentication is not performed on
NHRP packets on this LIS.
"
DEFVAL { 0 }
::= { nhrpIfEntry 9 }
nhrpIfAuthKey OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS write-only
STATUS current
DESCRIPTION
"The key value associated with the authentication type for this
LIS.
This value may be written only; reading this value shall return
a zero-length string.
"
DEFVAL { null }
::= { nhrpIfEntry 10 }
nhrpIfRowStatus OBJECT-TYPE
Expires Sept. 1995 [Page 15]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
SYNTAX RowStatus
ACCESS read-write
STATUS current
DESCRIPTION
"This object is used to create a new row in the table or
to delete an existing row.
"
DEFVAL { null }
::= { nhrpIfEntry 10 }
--
-- NHRP Server Table
--
-- This table indicates the device's knowledge of LIS or network
-- aggregates
-- and the NHRP Next Hop Servers (NHSs) that accept NHRP packets
-- destined for those networks. On NHRP servers, it also indicates
-- the range of network addresses served by the server.
--
nhrpServerTable OBJECT-TYPE
SYNTAX SEQUENCE OF NhrpServerEntry
ACCESS not-accessible
STATUS current
DESCRIPTION
"A table of {Net, Mask, Server} associatiations indicating that
the network aggregate defined by {Net,Mask} is served by Server.
Clients use this table to determine where to send NHRP
registration and request packets. Servers use this in Server
mode to select the next hop for forwarded NHRP requests.
Servers themselves have entries with nhrpServerNetAddr equal to
their own nhrpIfIpAddr value to define the LIS's served by the
server itself.
"
::= { nhrpMIBObjects 2 }
nhrpServerEntry OBJECT-TYPE
SYNTAX Nhrp
ACCESS read-write
STATUS current
DESCRIPTION
"An association of a single LIS/aggregate to a Server which
accepts NHRP requests to destinations on the LIS/aggretate".
"
INDEX {
nhrpServerNextHop
Expires Sept. 1995 [Page 16]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
nhrpServerDstNetAddr
nrhpServerDstNetMask
}
::= { nhrpServerTable 1 }
NhrpServEntry ::=
SEQUENCE {
nhrpServerNextHop
IpAddress,
nhrpServerDestNetAddr
IpAddress,
nhrpServerDestNetMask
IpAddress,
nrhpServerEntryStatus
Validation
}
nhrpServerNextHop OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS current
DESCRIPTION
"The IP address of an NHRP server. This must be a non-multicast
host addresss. This is the next hop destination IP address
for forwarded NHRP requests for a destination matching this
entry.
"
::= { nhrpServerEntry 1 }
nhrpServerDestNet OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS current
DESCRIPTION
"An IP network address for a logical IP subnet, the hosts
in which are capable of having their NBMA addresses resolved
by the NHRP server in nhrpServerNextHop.
"
::= { nhrpServerEntry 2 }
nhrpServerDestNet OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS current
DESCRIPTION
"An IP network address for a logical IP subnet, the hosts
in which are capable of having their NBMA addresses resolved
Expires Sept. 1995 [Page 17]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
by the NHRP server in nhrpServerNextHop.
"
::= { nhrpServerEntry 2 }
nhrpServerDestMask OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS current
DESCRIPTION
"An IP mask which is ANDed with nhrpServerDestNet to form the
the IP (sub)network number served by the NHRP server in
nhrpServerNextHop.
"
::= { nhrpServerEntry 3 }
nhrpServerRowStatus OBJECT-TYPE
SYNTAX RowStatus
ACCESS read-write
STATUS current
DESCRIPTION
"This object is used to create a new row in the table or
to delete an existing row.
"
DEFVAL { null }
::= { nhrpServerEntry 4 }
--
-- NHRP Address Table
-- This table contains the results of all NHRP registration and reply
-- packets processed. It is analagous to the ipNetToMedia table,
-- in that it contains { IP Address, NBMA Address } tuples.
-- Note that the NHRP Address table does not replace the
-- ipNettoMedia table, because other mechanism (e.g. RFC1577 ARP)
-- may also determine IP to Link Address mappings. For this reason,
-- Any entry added to this table must also cause a new entry to
-- be added into ipNetToMedia.
--
nhrpAddrTable OBJECT-TYPE
SYNTAX SEEQUENCE OF NhrpAddrEntry
ACCESS not-accessible
STATUS current
DESCRIPTION
"A table holding the results of NHRP registration and
reply messages received by this station. It provides
a mapping between Destination IP Addresses and
Destination Link Level addresses."
Expires Sept. 1995 [Page 18]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
::= { nhrpMIBObjects 3 }
nhrpAddrEntry OBJECT-TYPE
SYNTAX NhrpAddrEntry
ACCESS not-accessible
STATUS current
DESCRIPTION
"A particular mapping between a Destination IP address
and a Destination Link Level Address, as learned from
NHRP or static configuration."
INDEX {
nhrpAddrDestNetAddr,
nhrpAddrDestNetMask
}
::= { nhrpAddrTable 1 }
NhrpAddrEntry ::=
SEQUENCE {
nhrpAddrDestNetAddr
IpAddress,
nhrpAddrDestNetMask
IpAddress,
nhrpAddrDestLinkAddr
PhysAddress,
nhrpAddrHoldTime
HoldTime,
nhrpAddrEntryType
INTEGER, -- registered, replied, static
nhrpAddrQOS
QOSInfo,
nhrpAddrEntryStatus
Validation
}
nhrpAddrDestNetAddr OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS current
DESCRIPTION
"Destination IP host or network address, the NBMA
address
to which is given by this entry. "
::= { nhrpAddrEntry 1 }
nhrpAddrDestNetMask OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS current
Expires Sept. 1995 [Page 19]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
DESCRIPTION
"The mask which selects which bits of nhrpAddrDestNetAddr
are significant. This object holds the value of the Destination
Mask option in NHRP Replies and Registrations.
Host addresses, which are reported with no Destination Mask
option, have a mask value of 255.255.255.255."
DEFVAL { 0xFFFFFFFF }
::= { nhrpAddrEntry 2 }
nhrpAddrDestLinkAddr OBJECT-TYPE
SYNTAX LinkAddress
ACCESS read-write
STATUS current
DESCRIPTION
"The NBMA address reported for the destination IP address of
this
entry.
The value of this object shall be exactly as reported in
the NHRP Reply or Registration packet. Any link level address
modifications required to actually originate a switched
circuit to the destination shall not be reflected in this
object value."
::= { nhrpAddrEntry 3 }
nhrpAddrHoldTime OBJECT-TYPE
SYNTAX HoldTime
ACCESS read-write
STATUS current
DESCRIPTION
"The remaining time, in seconds, that this entry is considered
valid.
An expired entry may be deleted from the table at the
discretion of the agent."
::= { nhrpAddrEntry 4 }
nhrpAddrEntryType OBJECT-TYPE
SYNTAX INTEGER (
registered(1), -- From NHRP Registration packet
replied(2), -- From NHRP Reply packet addr'd to
us
forwarded(3), -- From forwarded NHRP Reply packet
static(4), -- From static non-volatile config'n
operator(5), -- From operator (volatile) config
snmp(6)) -- From snmp row creation
ACCESS read-write
Expires Sept. 1995 [Page 20]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
STATUS current
DESCRIPTION
"This object value indicates the event which caused this
entry to be created."
DEFVAL { snmp(4) }
::= { nhrpAddrEntry 4 }
nhrpAddrQOS OBJECT-TYPE
SYNTAX QOSInfo
ACCESS read-write
STATUS current
DESCRIPTION
"The value of the NHRP QOS option, if any, for entries created
from NHRP packets. The octet string reported for this object
shall be as received or transmitted in network byte order.
If no QOS option appeared in the packet, this object value
shall be a zero length string."
DEFVAL { snmp(4) }
::= { nhrpAddrEntry 5 }
nhrpAddrRowStatus OBJECT-TYPE
SYNTAX RowStatus
ACCESS read-write
STATUS current
DESCRIPTION
"This object is used to create a new row in the table or
to delete an existing row.
"
DEFVAL { null }
::= { nhrpAddrEntry }
-- -- NHRP Stats Table -- Statistics relating to NHRP Operation --
nhrpStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF NhrpStatsEntry
ACCESS not-accessible
STATUS current
DESCRIPTION
"A table holding the statistic count of relevant
events in NHRP. Statistics are maintained for each
LIS served by the station/router.
Each row of nhrpIfTable shall have a corresponding
row in this table."
::= { nhrpMIBObjects 4 }
nhrpStatsEntry OBJECT-TYPE
SYNTAX NhrpStatsEntry
ACCESS not-accessible
Expires Sept. 1995 [Page 21]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
STATUS current
DESCRIPTION
"A set of event counts for a particular NHRP
interface"
INDEX {
nhrpStatsIpAddr
nhrpStatsIfIndex
}
::= { nhrpStatsTable 1 }
NhrpStatsEntry ::=
SEQUENCE {
nhrpStatsIpAddr
IpAddress,
nhrpStatsIfIndex
IfIndex,
nhrpStatsInRequests
Counter32,
nhrpStatsOutRequests
Counter32,
nhrpStatsInReplies
Counter32,
nhrpStatsOutReplies
Counter32,
nhrpStatsInRegisters,
Counter32,
nhrpStatsOutRegisters,
Counter32,
nhrpStatsInErrors,
Counter32,
nhrpStatsOutErrors
Counter32,
nhrpStatsReplyForwards
Counter32,
nhrpStatsUnrecognizedOptions
Counter32,
nhrpStatsNetIDMismatches
Counter32,
nhrpStatsLoopDetecteds,
Counter32,
nhrpStatsCantServes
Counter32,
nhrpStatsRegistrationOverflows
Counter32,
nhrpStatsServerUnreachables
Counter32,
nhrpStatsProtocolErrors
Counter32,
Expires Sept. 1995 [Page 22]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
nhrpStatsFragmentationErrors
Counter32
nhrpStatsInDisabled
Counter32,
nhrpStatsInAuthFails
Counter32,
}
nhrpStatsIpAddr OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS current
DESCRIPTION
"An IP address for the local device which defines a Logical
IP subnet to which it belongs. This object value must equal
the nhrpIfIpAddr of at least one row in the nhrpIfTable."
::= { nhrpStatsEntry 1 }
nhrpStatsIfIndex OBJECT-TYPE
SYNTAX IfIndex
ACCESS read-only
STATUS current
DESCRIPTION
"The IP interface which, along with nhrpStatsIpAddr, defines
a logical IP subnet to which the device belongs."
::= { nhrpStatsEntry 2 }
nhrpStatsInRequests OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of NHRP Request packets received addressed to the
IpAddr for this entry.
???TBD-- how to report requests addressed to multicasts?"
::= { nhrpStatsEntry 3 }
nhrpStatsOutRequests OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of NHRP Request packets transmitted with a source
address of nhrpStatsIpAddr onto the interface nhrpStatsIfIndex."
::= { nhrpStatsEntry 4 }
Expires Sept. 1995 [Page 23]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
nhrpStatsInReplies OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of NHRP Reply packets received addressed to the
nhrpStatsIpAddr for this entry."
::= { nhrpStatsEntry 5 }
nhrpStatsOutReplies OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of NHRP Request packets transmitted with a source
address of nhrpStatsIpAddr onto the interface nhrpStatsIfIndex."
::= { nhrpStatsEntry 6 }
nhrpStatsInRegisters OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of NHRP Registration packets received addressed to
the nhrpStatsIpAddr for this entry."
::= { nhrpStatsEntry 7 }
nhrpStatsOutRegisters OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of NHRP Registration packets transmitted with a
source address of nhrpStatsIpAddr onto the interface
nhrpStatsIfIndex."
::= { nhrpStatsEntry 8 }
nhrpStatsInErrors OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of NHRP Error packets received addressed to the
nhrpStatsIpAddr for this entry."
::= { nhrpStatsEntry 9 }
nhrpStatsOutErrors OBJECT-TYPE
Expires Sept. 1995 [Page 24]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of NHRP Error packets transmitted with a source
address of nhrpStatsIpAddr onto the interface nhrpStatsIfIndex."
::= { nhrpStatsEntry 10 }
nhrpStatsReplyForwards OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of NHRP Reply packets processed by NHRP because of
the Router Attention option in the forwarded packet.
Packets are counted regardless of whether an nhrpAddrTable
entry is updated or not.
The table entry incremented is the lowest-numbered
nhrpStatsIpAddr on the nhrpStatsIfIndex interface on which the
packet was forwarded."
::= { nhrpStatsEntry 11 }
nhrpStatsUnrecognizedOptions OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets received addressed to nhrpStatsIpAddr
from interface nhrpStatsIfIndex which contained an unrecognized
option."
::= { nhrpStatsEntry 12 }
nhrpStatsNetIDMismatches OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets received addressed to nhrpStatsIpAddr
from interface nhrpStatsIfIndex which contained an NBMA Network
ID option which did not match the (nonzero) nhrpIfNetworkID
configured for this logical IP subnet."
::= { nhrpStatsEntry 13 }
nhrpStatsLoopDetecteds OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
Expires Sept. 1995 [Page 25]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
STATUS current
DESCRIPTION
"The number of times a loop in the configuration of NHRP
Next Hop Servers was detected. This was caused by
an attempt to forward an NHRP request onto the LIS
associated with this entry.
???TBD How do we do this without a hop count in the NHRP
header?"
::= { nhrpStatsEntry 14 }
nhrpStatsCantServes OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of times an NHRP Request packet was received with
a requested Destination IP address for which no entry in the
nhrpAddrTable or nhrpServerTable matched the destination.
This unfilled request was received addressed to nhrpStatsIpAddr
from interface nhrpStatsIfIndex."
::= { nhrpStatsEntry 15 }
nhrpStatsRegistrationOverflows OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of times an attempt was made add an entry to the
nhrpAddrTable that exceeded the size of the table supported
by the agent. Directly-addressed Registration and Reply
packets are counted in the entry corresponding to the addressed
LIS entity. Forwarded replies unabled to be cached are
counted against the LIS of the next hop of the reply.
???TBD Ok to not count failed operator dynamic and snmp row
additions to nhrpAddrTable?
::= { nhrpStatsEntry 16 }
nhrpStatsServerUnreachables OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of times an NHRP request was to be forwarded to an
NHS but the route to that NHS was unavailable.
This event is counted in the entry of the LIS receiving the
NHRP Request."
Expires Sept. 1995 [Page 26]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
::= { nhrpStatsEntry 17 }
nhrpStatsProtocolErrors OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of times a protocol error (e.g. a header format
error) was detected in a received NHRP packet. This event is
counted in the entry corresponding to the LIS which received
the NHRP packet."
::= { nhrpStatsEntry 18 }
nhrpStatsFragmentationErrors OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"???TBD How do we get this?"
::= { nhrpStatsEntry 19 }
nhrpStatsInDisabled OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of incoming NHRP packets addressed to this LIS
which were ignored becaue NHRP operation is disabled on the
LIS."
::= { nhrpStatsEntry 20 }
nhrpStatsAuthFails OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS current
DESCRIPTION
"The number of incoming NHRP packets addressed to this LIS
which were ignored due to an authentication failure.
???TBD Should these deliberately NOT be counted?"
::= { nhrpStatsEntry 21 }
END
Expires Sept. 1995 [Page 27]
<draft-ietf-rolc-nhrp-mib-00.txt> March 17, 1995
6.0 References
[ASN] Information processing systems - Open Systems Interconnection
-
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization, International
Standard 8824, December 1987.
[BER] 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.
[NHRP] Katz, Dave, Internet Draft "Next Hop Resolution Protocol"
ftp://ds.internic.net/internet-drafts/draft-ietf-rolc-nhrp-
03.txt.
[RFC1155] 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.
[RFC1212] Rose, M., and K. McCloghrie, Editors, "Concise MIB
Definitions", RFC 1212, Performance Systems International,
Hughes LAN Systems, March 1991.
[RFC1213] Rose M., Editor, "Management Information Base for Network
Management of TCP/IP-based internets: MIB-II", RFC 1213,
Performance Systems International, March 1991.
[RFC1573] K. McCloghrie, F. Kastenholz, "Evolution of the
Interfaces Group of MIB-II", RFC1573, 01/20/1994.
Expires Sept. 1995 [Page 28]
- NHRP MIB Draft 00 Michael W. Patrick
- Re: NHRP MIB Draft 00 Jon Postel