Internet DRAFT - draft-sims-dtnrg-bpmib
draft-sims-dtnrg-bpmib
Delay Tolerat Networking Research Group Z. Sims
Internet-Draft H. Kruse
Intended status: Experimental Ohio University
Expires: January 16, 2014 July 15, 2013
Bundle Protocol MIB
draft-sims-dtnrg-bpmib-03
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols. In particular it defines
objects for managing information about a Bundle Node - or simply a
'Node' within the scope of this document. More specifically, the
managed objects for such a Node include: Node-specific information,
registered Endpoint-Specific information, and generic CLA-Specific
(Convergence Layer Adapter) information.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Sims & Kruse Expires January 16, 2014 [Page 1]
Internet-Draft Bundle Protocol MIB July 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. The Internet-Standard Management Framework . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Structure of the MIB Module . . . . . . . . . . . . . . . 3
4.1.1. Node-Specific Definitions . . . . . . . . . . . . . . 3
4.1.2. Endpoint-Specific Definitions . . . . . . . . . . . . 4
4.1.3. CLA-Specific Definitions . . . . . . . . . . . . . . 5
4.2. Design Decisions . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Node and Endpoint Representation . . . . . . . . . . 5
4.2.2. Extension Blocks . . . . . . . . . . . . . . . . . . 6
4.2.3. Convergence Layer Adapters . . . . . . . . . . . . . 6
4.2.4. Conformance Groups . . . . . . . . . . . . . . . . . 6
4.2.5. Managing the Protocol Stack . . . . . . . . . . . . . 7
4.2.6. Reason for bpClaDirection . . . . . . . . . . . . . . 8
4.2.7. Notifications . . . . . . . . . . . . . . . . . . . . 8
4.2.8. Statistical and Trended Data . . . . . . . . . . . . 8
5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
8. Security Considerations . . . . . . . . . . . . . . . . . . . 48
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
9.1. Normative References . . . . . . . . . . . . . . . . . . 49
9.2. Informative References . . . . . . . . . . . . . . . . . 49
1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
2. Introduction
Sims & Kruse Expires January 16, 2014 [Page 2]
Internet-Draft Bundle Protocol MIB July 2013
This memo is submitted for consideration in, and possible adoption
by, the Delay Tolerant Networking Research Group (DTNRG). It defines
a portion of the Management Information Base (MIB) for use with
network management protocols. In particular it defines objects for
managing information about a Bundle Node [RFC5050] - or simply a
'Node' within the scope of this document. More specifically, the
manageable objects for such a Node include: Node- Specific
information, registered Endpoint-Specific information, and generic
CLA-Specific (Convergence Layer Adapter) information.
3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
4. Overview
The Bundle Protocol (BP) [RFC5050] was designed as part of the
solution to issues encountered in Delay Tolerant Networking (DTN)
environments [RFC4838], which are otherwise unsatisfied by the
connection-oriented scheme used in today's Internet. This memo
contains the definitions for a Bundle Protocol MIB as well as
rationale for certain implementation decisions. Also contained in
this memo is a section dedicated to considerations for future
designers of DTN-related MIBs. The MIB module defined in this memo
contains object definitions for a single Node, for each Endpoint of
which that Node is a member, and for the CLAs which that Node has
access to use.
4.1. Structure of the MIB Module
Objects within the BP-MIB have been derived from definitions found in
RFC 5050 [RFC5050]. The version of the MIB in this document was
further informed by lessons learned during the implementation of
network management instrumentation in the NASA ION implementation of
DTN. These objects are broken down into three main groups:
o Node-Specific Definitions
o Endpoint-Specific Definitions
o CLA-Specific Definitions
4.1.1. Node-Specific Definitions
Sims & Kruse Expires January 16, 2014 [Page 3]
Internet-Draft Bundle Protocol MIB July 2013
Within this document, objects that are referred to as 'Node-Specific'
are those objects which relate only to the Node being managed. In
other words, these objects do not relate to a Node's relationship
with any other entity (i.e. Endpoints and CLAs). Each of the
objects are detailed in the MIB definition's description fields.
One item in this category requires further discussion: the object
"bpNodeID" is defined as a string that uniquely identifies the node
to the network management application. RFC 5050 does not define such
a unique node identifier. At this time, each implementation will
need to find a way to create a node id. This draft recommends that
any node that needs to be managed continuously over time adhere to
the following:
o The node SHOULD register in a singleton endpoint created for the
purpose of managing the node, with the endpoint id of this network
management endpoint serving as the node id.
o The implementation SHOULD take steps to prevent the node from un-
registering from the network management endpoint.
o The implementation SHOULD ensure that the id of the network
management endpoint does not change across node re-initialization
or restarts.
o The implementation SHOULD ensure that the node registers into the
network management endpoint as part of the node initialization or
restart.
4.1.2. Endpoint-Specific Definitions
Within this document, objects that are referred to as 'Endpoint-
Specific' are those objects which relate to a specific Endpoint in
respect to the managed Node. In other words, the information managed
by these objects are subject only to the Node's view of the Endpoint
(e.g. the current state of the Endpoint is "active" according to this
Node OR the number of Bundles this Node has received for this
Endpoint is 42). Endpoint-Specific objects are maintained within a
conceptual table (with the exception of bpRegCount).
Each of the objects are detailed in the MIB definition's description
fields.
Sims & Kruse Expires January 16, 2014 [Page 4]
Internet-Draft Bundle Protocol MIB July 2013
4.1.3. CLA-Specific Definitions
Within this document, objects that are referred to as 'CLA-Specific'
are those objects which relate to a specific CLA in respect to the
managed Node. CLA-Specific objects are maintained within a
conceptual table (with the exception of bpClaCount).
Each of the objects are detailed in the MIB definition's description
fields. Two items need to be expanded on:
o bpClType: denotes of the CL type (e.g. UDP, TCP, LTP, etc). This
document suggests an initial set of (integer) values for currently
used CL types. However, some for of registry will be required in
the future.
o bpClID: a unique identifier (an octet string) for a specific CLA's
MIB instance. The creation of this string is implementation
specific. A network management implementation MUST treat this
string as opaque and use it only in "is equal to" operations.
4.2. Design Decisions
This section contains information regarding certain design choices
made during the creation of the BP-MIB module. Each decision was
made keeping in mind certain assumptions regarding the circumstances
under which a DTN might commonly operate. These assumptions include:
o Low-powered equipment is likely to be used
o Limitations on long-term and (possibly) short-term storage are
likely to exist and
o Delayed communication might require dissimilar management
techniques from those used in timely environments
4.2.1. Node and Endpoint Representation
The first design decision involved the overall representation of
Nodes and their respective attributes. According to section 3.1 of
RFC 5050 [RFC5050], Nodes have a M:N relationship with Endpoints.
That is to say, a Node can be a member of multiple Endpoints and (as
long as it is not a Singleton Endpoint) an Endpoint can have multiple
Nodes register it. Since SMIv2 [RFC2578] does not allow for the
creation of three-dimensional conceptual tables, a normalized view of
this relationship would be required; leading to the use of mediating
tables. The method used here, as exhibited in the formal MIB of this
document, was to emulate a three-dimensional conceptual table by
having each instance of the BP-MIB contain managed information for a
Sims & Kruse Expires January 16, 2014 [Page 5]
Internet-Draft Bundle Protocol MIB July 2013
single Node - with each instance having a conceptual table containing
managed information for each Endpoint of which it is a member.
4.2.2. Extension Blocks
Bundle Protocol Extension Blocks are mentioned in RFC 5050 [RFC5050],
but are not defined there. The BP-MIB contains a set of Node-
Specific objects that act as the list of Extensions Blocks that are
available to the managed Node. These objects are arranged as a
conceptual table that is indexed by the IANA defined Extension Block
number (represented by bpExtBlockType). Also contained within the
table is an OCTET STRING that acts as a human readable description of
the table entry.
4.2.3. Convergence Layer Adapters
With the Node/Endpoint decision made, the next decision involved the
representation of CLAs. Since multiple Nodes can share the use of
CLAs, and since the characteristics of a CLA are implementation
dependent, few objects were placed within the bpClaTable. Since it
is likely that a CLA's managed objects (those stored in a MIB
designed specifically for the management of the given CLA type) will
maintain more specific information than that contained in the
bpClaTable, two objects were created as a way to reference a CLA's
MIB instance. These two objects are:
o bpClType - Identifies the type of Convergence Layer (CL) being
used by the CLA (e.g. UDP, TCP, LTP, or otherwise)
o bpClID - Uniquely identifies the instance of managed information
for the underlying CL whose type is defined by bpClType
The bpClType and bpClID objects are also used as a solution to a
specific design goal. This goal involves the ability to trace
managed information down the protocol stack and is discussed in more
detail in another section of this document.
4.2.4. Conformance Groups
We recognize that the network management needs of different DTN
implementations will vary widely. The design of a MIB must balance
between capturing all relevant, and potentially useful data, while
also being mindful of the processing, memory, and storage
requirements created by the need to collect, store, and report values
for the objects defined in the MIB. For DTN, no one such balanced
approach will cover all needs.
Sims & Kruse Expires January 16, 2014 [Page 6]
Internet-Draft Bundle Protocol MIB July 2013
The MIB defined here uses the concept of Conformance Groups to allow
different implementation to select the collection of objects to
instrument for, in a standardized way. Two groups are mandatory:
o bpNodeInfoGroup: this group contains basic information identifying
the node and its current state (such as available storage, and
counts of queued bundles).
o bpNodeActivityGroup: this group contains counters that allow
tracking of the number of bundles processed by the node.
All objects not in the two groups above are optional. These
remaining objects are, however, grouped in (marked as optional)
conformance groups to give network management applications more
predictability as to the data that is available in a node
implementation.
4.2.5. Managing the Protocol Stack
One of this MIB's primary goals is to enable managed information to
be traceable throughout the protocol stack. Ultimately, this goal is
achieved by creating either a direct or indirect reference to an
entry in the ifTable [RFC2863]. To make this possible, the BP-MIB
MUST have identifier(s) that can be used to reference the MIB
instance of the layer beneath itself. The BP-MIB is designed in such
a way that both direct and indirect references to an ifTable entry
can be achieved. This was done by placing two objects within the
bpClaTable: one that uniquely identifies the CL type (bpClType) and
one that uniquely identifies an instance of managed information for
the given type (bpClID). Direct references to an ifTable entry are
achieved by setting bpClType = 1 (which means it is referring to an
interface). Indirect references are achieved when referencing a CLA
MIB which, in turn, references the layer beneath itself.
bpClType SHOULD be a standardized numeric value that identifies the
type of Convergence Layer being used by the Convergence Layer
Adapter.
bpClID, alternatively, is an arbitrary value chosen by the agent that
uniquely identifies an instance of the MIB whose type is given by
bpClType. The NMS responsible for the managed information can use
this value to determine the OID of the desired CLA.
There are two objects in the bpClaTable that represent the number of
Bundles passed into the BPA and out through the underlying CL
(bpClInBndls and bpClOutBndls). Likewise, two additional objects
exist to represent the amount of data passed between layers
(bpClInBytes and bpClOutBytes). Though these values are not used for
Sims & Kruse Expires January 16, 2014 [Page 7]
Internet-Draft Bundle Protocol MIB July 2013
stack traversal, they are maintained as a way of offering a view of
Bundle activity to/from each CLA from the perspective of a node.
4.2.6. Reason for bpClaDirection
The value in knowing the direction of data flow can be found in the
use of certain equipment types. Spacecraft, for instance, are prone
to utilizing an up-link that is different from the down-link.
Scenarios similar to this are likely to result in the creation of two
separate CLA MIB instances - one for each link. In these cases, a
manager might desire knowing whether the underlying CL is capable of
transmitting unidirectional traffic or bidirectional traffic. To
represent this, the bpClaTable has been given the bpClaDirection
object. The possible settings are inBound, outBound or
biDirectional.
4.2.7. Notifications
In an attempt to keep things modular, TRAP and INFORM objects have
been left out of the BP-MIB. These objects SHOULD be designed in a
separate MIB module which, if used, MUST be implemented in
conjunction with the BP-MIB. Since the requirements of network
management within a DTN are distinct from those in a timely
environment, use of notifications may vary between DTN environments
and timely environments.
4.2.8. Statistical and Trended Data
Certain MIBs, such as those that manage high performance equipment,
might contain mechanisms to store local data trends, simple
statistical analysis, and bulk data counters (to avoid losing data
when a counter resets to 0). The need for such mechanisms is likely
to arise in certain DTN environments as well - but for different
reasons. MIBs for high-performance equipment are likely to
experience incredibly high counter iteration (essentially causing the
counters to rollover before an NMS can retrieve the stored values)
whereas a DTN is likely to accrue large amounts of data between NMS
requests due to the constraints imposed by delay and disruption.
However, in an attempt to keep things modular, statistic-based
objects and trending objects have been considered beyond the scope of
the BP-MIB. These objects, if any such objects are designed, SHOULD
be put in a separate MIB module which MAY be implemented in
conjunction with the BP-MIB, but can function independent of the BP-
MIB.
5. Definitions
BP-MIB DEFINITIONS ::= BEGIN
Sims & Kruse Expires January 16, 2014 [Page 8]
Internet-Draft Bundle Protocol MIB July 2013
IMPORTS
enterprises, MODULE-IDENTITY, OBJECT-TYPE, Integer32,
Gauge32,
Counter64, TimeTicks
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF;
bpMIB MODULE-IDENTITY
LAST-UPDATED "201304301530Z"
ORGANIZATION "Ohio University IRG"
CONTACT-INFO
" Zack Sims
Phone: +1 (740)285-1895
Email: zack.sims@gmail.com
Hans Kruse
Phone: +1 (740) 593-4891
Email: kruse@ohio.edu
Alt: hkruse1@mac.com"
DESCRIPTION
"This MIB module was designed for the management of Bundle
Protocol (BP) Nodes, for the Endpoints they are members of,
and for Node <===> CLA relationships. This MIB is structured
in a way that Node-Specific objects are arranged separately
from Endpoint and CLA -Specific objects. Objects which are
Endpoint or CLA -Specific are arranged in Conceptual Rows
within their own, respective, Conceptual Tables. Further,
each instance of this module's objects represents a single
managed Node. This means that a separate instantiation of
the BP-MIB's objects will be forged for each Node being
managed by the system. The layout of the MIB is arranged in
the following order:
* Node-Specific Definitions
* Endpoint-Specific Definitions
* CLA-Specific Definitions
* Conformance Requirements for the BP-MIB"
REVISION "201204191530Z"
DESCRIPTION
"201103130330Z
The first public announcement of this MIB's creation on the
DTNRG (Delay Tolerant Networking Research Group) mailing
list.
201105191930Z
The second release of the BP-MIB I-D (draft number 01).
Sims & Kruse Expires January 16, 2014 [Page 9]
Internet-Draft Bundle Protocol MIB July 2013
Changes include:
* Adding CCSDS related objects (such as vrs#, Byte
counts,and Extension Block tracking
* Slight object renaming
* Addition of temporary textual conventions for IANA
requirements.
201204191530Z
The third release of the BP-MIB I-D (draft number 02).
Changes include:
* Clarity and consistency of description fields
* Object identity and purpose <===> sanity check
* Cross-standard compatibility check <===> CCSDS
BP managed objects"
-- These values are temporary until a DTN-MIB can get an IANA
-- sanctioned value of its own :)
::= { dtn 3 }
dtn OBJECT IDENTIFIER ::= { collegeOfComm 3 }
collegeOfComm OBJECT IDENTIFIER ::= { ohioUniv 42 }
ohioUniv OBJECT IDENTIFIER ::= { enterprises 32396 }
-- Node-Specific definitions
bpNodeObjects OBJECT IDENTIFIER ::= { bpMIB 1 }
--Needs discussion. Draft will specify that the managed node must maintain
--a permanent registration in one singleton endpoint, which will serve as the node id.
bpNodeID OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An arbitrary value used to uniquely identify instances
of the BP-MIB. This value can be used by other MIB
definitions to reference instances of Bundle Node objects."
::= { bpNodeObjects 1 }
--OK as written.
bpBundleVersion OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
Sims & Kruse Expires January 16, 2014 [Page 10]
Internet-Draft Bundle Protocol MIB July 2013
DESCRIPTION
"This value denotes which version number of the Bundle
Protocol is being used by this Node."
::= { bpNodeObjects 2 }
--OK as written.
bpLastUpTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Is a representation of the last time this Node was
restarted and should be set by the system appropriately.
Some implementations of the Bundle Protocol might choose
to reset certain values when a Node is shutdown and brought
back up. This value is NOT a mirror of sysUpTime. Since
multiple Nodes can be running on a single system, this
value represents the last time this Node was reset."
::= { bpNodeObjects 3 }
--OK as written.
bpAvailStorage OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value represents the number of Kilo-Bytes currently
available to this Node for the storage of bundles. The value
ranges between 0 and (2^32) -1"
::= { bpNodeObjects 4 }
--OK as written.
bpBulkPriorGenBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bundles generated on this
Node with a priority value of -bulk-
Note: the sum of bpNormPriorGenBndls, bpBulkPriorGenBndls,
and bpExpPriorGenBndls can be used to find the total of
Bundles generated at the local Node.
Bundle priority settings are mentioned in section 4.2 of RFC
5050"
::= { bpNodeObjects 5 }
Sims & Kruse Expires January 16, 2014 [Page 11]
Internet-Draft Bundle Protocol MIB July 2013
--Move to optional group.
bpBulkPriorGenBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bytes generated on this
Node with a priority value of -bulk-
Note: the sum of bpNormPriorGenBytes, bpBulkPriorGenBytes,
and bpExpPriorGenBytes can be used to find the total of
Bytes generated at the local Node.
Bundle priority settings are mentioned in section 4.2 of RFC
5050"
::= { bpNodeObjects 6 }
--OK as written.
bpNormPriorGenBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bundles generated on this
Node with the priority value -normal-
Note: the sum of bpNormPriorGenBndls, bpBulkPriorGenBndls,
and bpExpPriorGenBndls can be used to find the total of
Bundles generated at the local Node.
Bundle priority settings are mentioned in Section 4.2 of RFC
5050"
::= { bpNodeObjects 7 }
--Move to optional group.
bpNormPriorGenBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bytes generated on this
Node with the priority value -normal-
Note: the sum of bpNormPriorGenBytes, bpBulkPriorGenBytes,
and bpExpPriorGenBytes can be used to find the total of
Bytes generated at the local Node.
Bundle priority settings are mentioned in Section 4.2 of RFC
Sims & Kruse Expires January 16, 2014 [Page 12]
Internet-Draft Bundle Protocol MIB July 2013
5050"
::= { bpNodeObjects 8 }
--OK as written.
bpExpPriorGenBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bundles generated on this
Node with the priority value -expedited-
Note: the sum of bpNormPriorGenBndls, bpBulkPriorGenBndls,
and bpExpPriorGenBndls can be used to find the total of
Bundles generated at the local Node.
Bundle priority settings are mentioned in Section 4.2 of RFC
5050"
::= { bpNodeObjects 9 }
--Move to optional group.
bpExpPriorGenBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bytes generated on this
Node with the priority value -expedited-
Note: the sum of bpNormPriorGenBytes, bpBulkPriorGenBytes,
and bpExpPriorGenBytes can be used to find the total of
Bytes generated at the local Node.
Bundle priority settings are mentioned in Section 4.2 of RFC
5050"
::= { bpNodeObjects 10 }
--OK as written.
bpBulkPriorQueuedBndls OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bundles currently queued
on this Node with the priority value -bulk-
Note: the sum of bpNormPriorGenBndls, bpBulkPriorGenBndls,
and bpExpPriorGenBndls can be used to find the total of
Sims & Kruse Expires January 16, 2014 [Page 13]
Internet-Draft Bundle Protocol MIB July 2013
Bundles queued at the local Node.
Bundle priority settings are mentioned in Section 4.2 of RFC
5050"
::= { bpNodeObjects 11 }
--Move to optional group.
bpBulkPriorQueuedBytes OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bytes currently queued
on this Node with the priority value -bulk-
Note: the sum of bpNormPriorGenBytes, bpBulkPriorGenBytes,
and bpExpPriorGenBytes can be used to find the total of
Bytes queued at the local Node.
Bundle priority settings are mentioned in Section 4.2 of RFC
5050"
::= { bpNodeObjects 12 }
--OK as written.
bpNormPriorQueuedBndls OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bundles currently queued
on this Node with the priority value -normal-
Note: the sum of bpNormPriorGenBndls, bpBulkPriorGenBndls,
and bpExpPriorGenBndls can be used to find the total of
Bundles queued at the local Node.
Bundle priority settings are mentioned in Section 4.2 of RFC
5050"
::= { bpNodeObjects 13 }
--Move to optional group.
bpNormPriorQueuedBytes OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bytes currently queued
on this Node with the priority value -normal-
Sims & Kruse Expires January 16, 2014 [Page 14]
Internet-Draft Bundle Protocol MIB July 2013
Note: the sum of bpNormPriorGenBytes, bpBulkPriorGenBytes,
and bpExpPriorGenBytes can be used to find the total of
Bytes queued at the local Node.
Bundle priority settings are mentioned in Section 4.2 of RFC
5050"
::= { bpNodeObjects 14 }
--OK as written.
bpExpPriorQueuedBndls OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bundles currently queued
on this Node with the priority value -expedited-
Note: the sum of bpNormPriorGenBndls, bpBulkPriorGenBndls,
and bpExpPriorGenBndls can be used to find the total of
Bundles queued at the local Node.
Bundle priority settings are mentioned in Section 4.2 of RFC
5050"
::= { bpNodeObjects 15 }
--Move to optional group.
bpExpPriorQueuedBytes OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bytes currently queued
on this Node with the priority value -expedited-
Note: the sum of bpNormPriorGenBytes, bpBulkPriorGenBytes,
and bpExpPriorGenBytes can be used to find the total of
Bytes queued at the local Node.
Bundle priority settings are mentioned in Section 4.2 of RFC
5050"
::= { bpNodeObjects 16 }
--OK as written.
bpReassemblyPendingBndls OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Sims & Kruse Expires January 16, 2014 [Page 15]
Internet-Draft Bundle Protocol MIB July 2013
"This value represents the current number of Bundles queued
on this Node that have the retention constraint -Reassembly
Pending-
RFC 5050 mentions the Reassembly Pending retention
constraint in Sections 5.7 and 5.9. A retention constraint
is any reason why a Bundle should not continue to be
processed (whether it is waiting to reassemble fragments,
dispatch, forward, or pass custody."
::= { bpNodeObjects 17 }
--Move to optional group.
bpReassemblyPendingBytes OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value represents the current number of Bytes queued
on this Node that have the retention constraint -Reassembly
Pending-
RFC 5050 mentions the Reassembly Pending retention
constraint in Sections 5.7 and 5.9. A retention constraint
is any reason why a Bundle should not continue to be
processed (whether it is waiting to reassemble fragments,
dispatch, forward, or pass custody."
::= { bpNodeObjects 18 }
--OK as written.
bpDispatchPendingBndls OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value represents the current number of Bundles queued
on this Node that have the retention constraint -Dispatch
Pending-
RFC 5050 mentions the Dispatch Pending retention constraint
in Sections 5.2, 5.4 and 5.6. A retention constraint
is any reason why a Bundle should not continue to be
processed (whether it is waiting to reassemble fragments, dispatch,
forward, or pass custody."
::= { bpNodeObjects 19 }
--Move to optional group.
bpDispatchPendingBytes OBJECT-TYPE
SYNTAX Gauge32
Sims & Kruse Expires January 16, 2014 [Page 16]
Internet-Draft Bundle Protocol MIB July 2013
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value represents the current number of Bytes queued
on this Node that have the retention constraint -Dispatch
Pending-
RFC 5050 mentions the Dispatch Pending retention constraint
in Sections 5.2, 5.4 and 5.6. A retention constraint
is any reason why a Bundle should not continue to be
processed (whether it is waiting to reassemble fragments, dispatch,
forward, or pass custody."
::= { bpNodeObjects 20 }
--OK as written.
bpForwardPendingBndls OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value represents the current number of Bundles queued
on this Node that have the retention constraint -Forward
Pending-
RFC 5050 mentions the Forward Pending retention constraint
in Sections 5.4 and 5.4.2. A retention constraint
is any reason why a Bundle should not continue to be
processed (whether it is waiting to reassemble fragments, dispatch,
forward, or pass custody."
::= { bpNodeObjects 21 }
--Move to optional group.
bpForwardPendingBytes OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value represents the current number of Bytes queued
on this Node that have the retention constraint -Forward
Pending-
RFC 5050 mentions the Forward Pending retention constraint
in Sections 5.4 and 5.4.2. A retention constraint
is any reason why a Bundle should not continue to be
processed (whether it is waiting to reassemble fragments, dispatch,
forward, or pass custody."
::= { bpNodeObjects 22 }
Sims & Kruse Expires January 16, 2014 [Page 17]
Internet-Draft Bundle Protocol MIB July 2013
--OK as written.
bpCustodyAcceptedBndls OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value represents the current number of Bundles queued
on this Node that have the retention constraint -Custody
Accepted-
RFC 5050 mentions the Custody Accepted retention constraint
in Sections 5.7 and 5.9. A retention constraint
is any reason why a Bundle should not continue to be
processed (whether it is waiting to reassemble fragments, dispatch,
forward, or pass custody."
::= { bpNodeObjects 23 }
--Move to optional group.
bpCustodyAcceptedBytes OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value represents the current number of Bytes queued
on this Node that have the retention constraint -Custody
Accepted-
RFC 5050 mentions the Custody Accepted retention constraint
in Sections 5.7 and 5.9. A retention constraint
is any reason why a Bundle should not continue to be
processed (whether it is waiting to reassemble fragments, dispatch,
forward, or pass custody."
::= { bpNodeObjects 24 }
--OK as written.
bpCustodyFailureBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times this Node has failed to accept custody
of incoming Bundles.
RFC 5050 defines custody transfer failures in Sections
5.10.1 and 5.12"
::= { bpNodeObjects 25 }
Sims & Kruse Expires January 16, 2014 [Page 18]
Internet-Draft Bundle Protocol MIB July 2013
--Move to optional group.
bpCustodyFailureBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of bytes this Node has failed to accept
under its custody.
RFC 5050 defines custody transfer failures in Sections
5.10.1 and 5.12"
::= { bpNodeObjects 26 }
--OK as written.
bpForwardFailureBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of bundles for which this Node has experienced a
forwarding failure.
RFC 5050 defines forwarding failures in Sections 5.4.1 and
5.4.2"
::= { bpNodeObjects 27 }
--Move to optional group.
bpForwardFailureBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of bytes for which this Node has experienced a
forwarding failure.
RFC 5050 defines forwarding failures in Sections 5.4.1 and
5.4.2"
::= { bpNodeObjects 28 }
--OK as written.
bpAbandonedDeliveryBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of bundles for which this Node has abandoned
delivery.
Sims & Kruse Expires January 16, 2014 [Page 19]
Internet-Draft Bundle Protocol MIB July 2013
RFC 5050 defines abandonment in Section 3.1"
::= { bpNodeObjects 29 }
--Move to optional group.
bpAbandonedDeliveryBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of bytes for which this Node has abandoned
delivery.
RFC 5050 defines abandonment in Section 3.1"
::= { bpNodeObjects 30 }
--OK as written.
bpDiscardedBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Bundles this Node has discarded.
RFC 5050 defines Bundle discarding in Section 3.1"
::= { bpNodeObjects 31 }
--Move to optional group.
bpDiscardedBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Bytes this Node has discarded.
RFC 5050 defines Bundle discarding in Section 3.1"
::= { bpNodeObjects 32 }
--OK as written.
bpFragmentedLocally OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Bundles that this Node has fragmented.
RFC 5050 defines fragments in Section 3.1 and the
fragmentation process in Section 5.8"
::= { bpNodeObjects 33 }
Sims & Kruse Expires January 16, 2014 [Page 20]
Internet-Draft Bundle Protocol MIB July 2013
--OK as written.
bpFragmentsCreated OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Bundle Fragments that this Node has created
locally.
RFC 5050 defines fragments in Section 3.1 and the
fragmentation process in Section 5.8"
::= { bpNodeObjects 34 }
--OK as written.
bpDelExpired OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Bundles that this Node has deleted based on
-Lifetime Expired-
RFC 5050 defines the Bundle deletion process in Section 5.13
and the deletion status report flags in Section 6.1.1"
::= { bpNodeObjects 35 }
--OK as written.
bpDelTransCancelled OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Bundles that this Node has deleted based on
-Transmission Canceled-
RFC 5050 defines the Bundle deletion process in Section 5.13
and the deletion status report flags in Section 6.1.1"
::= { bpNodeObjects 36 }
--OK as written.
bpDelDepStorage OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Bundles that this Node has deleted based on
-Depleted Storage-
Sims & Kruse Expires January 16, 2014 [Page 21]
Internet-Draft Bundle Protocol MIB July 2013
RFC 5050 defines the Bundle deletion process in Section 5.13
and the deletion status report flags in Section 6.1.1"
::= { bpNodeObjects 37 }
--OK as written.
bpDelDestUnintel OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Bundles that this Node has deleted based on
-Destination Endpoint ID Unintelligible-
RFC 5050 defines the Bundle deletion process in Section 5.13
and the deletion status report flags in Section 6.1.1"
::= { bpNodeObjects 38 }
--OK as written.
bpDelNoRoute OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Bundles that this Node has deleted based on
-No Known Route to Destination From Here-
RFC 5050 defines the Bundle deletion process in Section 5.13
and the deletion status report flags in Section 6.1.1"
::= { bpNodeObjects 39 }
--OK as written.
bpDelUntimelyContact OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Bundles that this Node has deleted based on
-No Timely Contact With Next Node on Route-
RFC 5050 defines the Bundle deletion process in Section 5.13
and the deletion status report flags in Section 6.1.1"
::= { bpNodeObjects 40 }
--OK as written.
bpDelBlockUnintel OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
Sims & Kruse Expires January 16, 2014 [Page 22]
Internet-Draft Bundle Protocol MIB July 2013
DESCRIPTION
"The number of Bundles that this Node has deleted based on
-Block Unintelligible-
RFC 5050 defines the Bundle deletion process in Section 5.13
and the deletion status report flags in Section 6.1.1"
::= { bpNodeObjects 42 }
--OK as written.
bpDelNoAdditionalInfo OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of Bundles that this Node has deleted based on
-No additional information-
Note, certain software implementations might include
extensions to the Bundle Protocol. Since extensions are
prone to errors other than those specified by RFC 5050, this
value may or may not increment upon extension-related errors
(a counter of these errors may be contained in the
extension's MIB). It depends on the extension's MIB design
and the instrumentation of that MIB.
RFC 5050 defines the Bundle deletion process in Section 5.13
and the deletion status report flags in Section 6.1.1"
::= { bpNodeObjects 42 }
--
bpDelBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of bytes deleted by this Node
RFC 5050 defines the Bundle deletion process in Section 5.13
and the deletion status report flags in Section 6.1.1"
::= { bpNodeObjects 43 }
--
--The objects below were moved from endpoint to node level
--
bpBundlesSentBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Sims & Kruse Expires January 16, 2014 [Page 23]
Internet-Draft Bundle Protocol MIB July 2013
"A cumulative count of all the Bundles that have been sent
from this node.
Bundle reception and the steps to handling these Bundles are
discussed in RFC 5050, Section 5.6"
::= { bpNodeObjects 44 }
--Move to optional group.
bpBundlesSentBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A cumulative count of all the Bytes that have been sent
from this node.
Bundle reception and the steps to handling these Bundles are
discussed in RFC 5050, Section 5.6"
::= { bpNodeObjects 45 }
bpBundlesForwardedBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A cumulative count of all the Bundles that have been
forwarded to a Node, from this Node.
The steps to handling Bundle forwarding are discussed in RFC
5050, Section 5.4"
::= { bpNodeObjects 46 }
--Move to optional group.
bpBundlesForwardedBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A cumulative count of all the Bytes that have been
forwarded to a Node, from this Node.
The steps to handling Bundle forwarding are discussed in RFC
5050, Section 5.4"
::= { bpNodeObjects 47 }
bpBundleDuplicatesBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
Sims & Kruse Expires January 16, 2014 [Page 24]
Internet-Draft Bundle Protocol MIB July 2013
STATUS current
DESCRIPTION
"A cumulative count of all the duplicate Bundles that have
been received by this Node. NOTE: duplicate
bundles are any bundle that arrives at a Node, but is
already within that Node's storage."
::= { bpNodeObjects 48 }
--Move to optional group.
bpBundleDuplicatesBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A cumulative count of Bytes that were received as
duplicate Bundles by this Node.
NOTE: duplicate bundles are any bundle that arrives at a
Node, but is already within that Node's storage."
::= { bpNodeObjects 49 }
--
--End moved items
--
--Nodes can request reports for bundle reception, custody acceptance,
--bundle forwarding, bundle delivery, and bundle deletion.
--MIB has been refactored to group these. They will be in non-mandatory conformance group.
bpNodeAdminReports OBJECT IDENTIFIER ::= { bpNodeObjects 50 }
bpBundleReceptions OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A cumulative count of all the -Bundle Reception- reports
that this Node has received.
The Bundle status report request fields are listed in
Section 4.2 of RFC 5050. Each of the Bundle Status Reports
are defined in RFC 5050, Section 5.1 and are described in
greater detail in Section 6.1.1"
::= { bpNodeAdminReports 1 }
bpCustodyAcceptance OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Sims & Kruse Expires January 16, 2014 [Page 25]
Internet-Draft Bundle Protocol MIB July 2013
"A cumulative count of all the -Custody Acceptance- reports
that this Node has received.
The Bundle status report request fields are listed in
Section 4.2 of RFC 5050. Each of the Bundle Status Reports
are defined in RFC 5050, Section 5.1 and are described in
greater detail in Section 6.1.1"
::= { bpNodeAdminReports 2 }
bpBundleForwarding OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A cumulative count of all the -Bundle Forwarding- reports
that this Node has received.
The Bundle status report request fields are listed in
Section 4.2 of RFC 5050. Each of the Bundle Status Reports
are defined in RFC 5050, Section 5.1 and are described in
greater detail in Section 6.1.1"
::= { bpNodeAdminReports 3 }
bpBundleDelivery OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A cumulative count of all the -Bundle Delivery- reports
that this Node has received.
The Bundle status report request fields are listed in
Section 4.2 of RFC 5050. Each of the Bundle Status Reports
are defined in RFC 5050, Section 5.1 and are described in
greater detail in Section 6.1.1"
::= { bpNodeAdminReports 4 }
--The bundle deletion report counters were moved from end-point to node level
bpDelExpiredReports OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of deletion reports received by this Node
with the reason -Lifetime Expired-
The Bundle status report request fields are listed in
Section 4.2 of RFC 5050. Each of the Bundle Status Reports
Sims & Kruse Expires January 16, 2014 [Page 26]
Internet-Draft Bundle Protocol MIB July 2013
are defined in RFC 5050, Section 5.1 and are described in
greater detail in Section 6.1.1"
::= { bpNodeAdminReports 5 }
bpDelTransCancelledReports OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of deletion reports received by this Node
with the reason -Transmission Canceled-
The Bundle status report request fields are listed in
Section 4.2 of RFC 5050. Each of the Bundle Status Reports
are defined in RFC 5050, Section 5.1 and are described in
greater detail in Section 6.1.1"
::= { bpNodeAdminReports 6 }
bpDelDepStorageReports OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of deletion reports received by this Node
with the reason -Depleted Storage-
The Bundle status report request fields are listed in
Section 4.2 of RFC 5050. Each of the Bundle Status Reports
are defined in RFC 5050, Section 5.1 and are described in
greater detail in Section 6.1.1"
::= { bpNodeAdminReports 7 }
bpDelDestUnintelReports OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of deletion reports received by this Node
with the reason -Destination Endpoint ID Unintelligible-
The Bundle status report request fields are listed in
Section 4.2 of RFC 5050. Each of the Bundle Status Reports
are defined in RFC 5050, Section 5.1 and are described in
greater detail in Section 6.1.1"
::= { bpNodeAdminReports 8 }
bpDelNoRouteReports OBJECT-TYPE
SYNTAX Counter64
Sims & Kruse Expires January 16, 2014 [Page 27]
Internet-Draft Bundle Protocol MIB July 2013
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of deletion reports received by this Node
with the reason -No Known Route to Destination From Here-
The Bundle status report request fields are listed in
Section 4.2 of RFC 5050. Each of the Bundle Status Reports
are defined in RFC 5050, Section 5.1 and are described in
greater detail in Section 6.1.1"
::= { bpNodeAdminReports 9 }
bpDelUntimelyContactReports OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of deletion reports received by this Node
with the reason -No Timely Contact With Next Node on Route-
The Bundle status report request fields are listed in
Section 4.2 of RFC 5050. Each of the Bundle Status Reports
are defined in RFC 5050, Section 5.1 and are described in
greater detail in Section 6.1.1"
::= { bpNodeAdminReports 10 }
bpDelBlockUnintelReports OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of deletion reports received by this Node
with the reason -Block Unintelligible-
The Bundle status report request fields are listed in
Section 4.2 of RFC 5050. Each of the Bundle Status Reports
are defined in RFC 5050, Section 5.1 and are described in
greater detail in Section 6.1.1"
::= { bpNodeAdminReports 11 }
bpDelNoAdditionalInfoReports OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of deletion reports received by this Node
this Endpoint for the reason -No Additional Information-
Sims & Kruse Expires January 16, 2014 [Page 28]
Internet-Draft Bundle Protocol MIB July 2013
Note, certain software implementations might include
extensions to the Bundle Protocol. Since extensions are
capable of creating new status report types, this value may
or may not increment from errors outside the scope of RFC
5050. (another MIB might manage this information). It
depends on the extension's MIB design and the
instrumentation of that MIB.
The Bundle status report request fields are listed in
Section 4.2 of RFC 5050. Each of the Bundle Status Reports
are defined in RFC 5050, Section 5.1 and are described in
greater detail in Section 6.1.1"
::= { bpNodeAdminReports 12 }
--This object has been reworked (it incorrectly refered to a report)
bpCustodySuccess OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A cumulative count of all the "Succeeded" custody signals
that this Node has received. Custody signals requirements
are described in sections 5.11 and 5.12.
The custody signal format is described in 6.1.2"
::= { bpNodeAdminReports 13 }
--This object has been added, paired with the object above.
bpCustodyTranFail OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A cumulative count of all the "Failed" custody signals
that this Node has received. Custody signals requirements
are described in sections 5.11 and 5.12.
The custody signal format is described in 6.1.2"
::= { bpNodeAdminReports 14 }
--
--End Administrative Report counters................................................
--
--
--
--Extension Block Table Start ....................................................
--
--OK as written.
Sims & Kruse Expires January 16, 2014 [Page 29]
Internet-Draft Bundle Protocol MIB July 2013
bpExtBlockTable OBJECT-TYPE
SYNTAX SEQUENCE OF BPExtBlockEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table whose rows identify the Bundle Protocol Extension
Blocks available to this Node."
::= { bpNodeObjects 49 }
--OK as written.
bpExtBlockEntry OBJECT-TYPE
SYNTAX BPExtBlockEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object represents a single entry in bpExtBlockTable.
Each entry denotes the extension block's type and offers a
human readable description field."
INDEX
{ bpExtBlockType }
::= { bpExtBlockTable 1 }
BPExtBlockEntry ::= SEQUENCE
{
bpExtBlockType Integer32,
bpExtBlockDisplayName OCTET STRING
}
--OK as written.
bpExtBlockType OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of this object uniquely identifies the type of
extension block being represented by this table entry. Each
extension block type is uniquely represented by a positive
integer.
Note, this object is currently in need of IANA
consideration and would most likely be better suited as a
textual-convention."
::= { bpExtBlockEntry 1 }
--OK as written.
bpExtBlockDisplayName OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
Sims & Kruse Expires January 16, 2014 [Page 30]
Internet-Draft Bundle Protocol MIB July 2013
STATUS current
DESCRIPTION
"This is a human readable string value that stores either a
block name or short description of this this table entry."
::= { bpExtBlockEntry 2 }
--
--Extension Block Table End ....................................................
--
--
-- Endpoint-Specific Definitions ............................................................
--
bpRegObjects OBJECT IDENTIFIER ::= { bpMIB 2 }
--OK as written.
bpRegCount OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value does NOT keep track of the number of Endpoints
of which this Node is a member. Rather, it is directly
related to the number of rows in the bpRegTable. Because
Endpoints can be unregistered, this value may stay the same
while the number of Endpoint registrations decreases. This
value should never be set to 0 because every Node must be a
member of at least one Singleton Endpoint; see RFC 5050,
Section 3.1"
::= { bpRegObjects 1 }
--OK as written.
bpRegTable OBJECT-TYPE
SYNTAX SEQUENCE OF BPRegEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Is a sequence of Endpoint registrations and exists as a
conceptual table for storing each registration entry and its
managed objects. Each registration is uniquely identifiable
by its EID (Endpoint ID). Each Node should be a member of at
least one Singleton Endpoint, so this table should always
have a minimum of 1 entry; see RFC 5050, Section 3.1"
::= { bpRegObjects 2 }
--OK as written.
bpRegEntry OBJECT-TYPE
SYNTAX BPRegEntry
MAX-ACCESS not-accessible
Sims & Kruse Expires January 16, 2014 [Page 31]
Internet-Draft Bundle Protocol MIB July 2013
STATUS current
DESCRIPTION
"A conceptual row of bpRegTable that contains the
Endpoint-Specific objects for Endpoints of which this Node
is a member. Each entry can be uniquely identified by its
bpEndpointID. There should be at least one bpRegEntry in the
bpRegTable at all times whose bpIsSingleton value is set to
true; see RFC 5050, Section 3.1"
INDEX
{ bpRegIndex }
::= { bpRegTable 1 }
--Updated sequence after refactoring
BPRegEntry ::= SEQUENCE
{
bpRegIndex Integer32,
bpEndpointID OCTET STRING,
bpCurState BITS,
bpIsSingleton BITS,
bpDeliveryFailureAction BITS,
bpBundlesDeliveredBndls Counter64,
bpBundlesDeliveredBytes Counter64,
bpBulkPriorRecvdBndls Counter64,
bpBulkPriorRecvdBytes Counter64,
bpNormPriorRecvdBndls Counter64,
bpNormPriorRecvdBytes Counter64,
bpExpPriorRecvdBndls Counter64,
bpExpPriorRecvdBytes Counter64
}
--OK as written.
bpRegIndex OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An index value that uniquely denotes a conceptual row of
the bpRegTable."
::= { bpRegEntry 1 }
--OK as written.
bpEndpointID OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A string value representing the Endpoint ID of this
Sims & Kruse Expires January 16, 2014 [Page 32]
Internet-Draft Bundle Protocol MIB July 2013
registered Endpoint.
Bundle Endpoints and Endpoint IDs are discussed in RFC 5050,
Section 3.1"
::= { bpRegEntry 2 }
--OK as written.
bpCurState OBJECT-TYPE
SYNTAX BITS { passive(0), active(1) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current state of the BP (Bundle Protocol) on this
Endpoint.
Possible Values:
* passive - 0
* active - 1
The active and passive states of a registered Endpoint are
discussed in RFC 5050, Section 3.1"
::= { bpRegEntry 3 }
--OK as written.
bpIsSingleton OBJECT-TYPE
SYNTAX BITS { false(0), true(1) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value represents whether or not this registered
Endpoint is a Singleton.
Possible Values:
* false - 0 - Is not a Singleton Endpoint
* true - 1 - Is a Singleton Endpoint
Singleton Endpoints are discussed in RFC 5050, Section 3.1"
::= { bpRegEntry 4 }
--OK as written.
bpDeliveryFailureAction OBJECT-TYPE
SYNTAX BITS { abandonDelivery(0), deferDelivery(1) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value represents whether the registered Endpoint's
Delivery Failure Action is set to defer or abandon.
Sims & Kruse Expires January 16, 2014 [Page 33]
Internet-Draft Bundle Protocol MIB July 2013
Possible Values:
* abandonDelivery - 0 - Abandon the Bundle's delivery
* deferDelivery - 1 - Defer the Bundle's Delivery
Bundle Delivery Failure Actions are discussed in RFC 5050,
Section 3.1"
::= { bpRegEntry 5 }
--OK as written.
bpBundlesDeliveredBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A cumulative count of all the Bundles that have been
delivered on this Node for this Endpoint
Bundle delivery steps are discussed in RFC 5050, Section
5.7"
::= { bpRegEntry 6 }
--Needs discussion?
bpBundlesDeliveredBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A cumulative count of all the Bytes that have been
delivered on this Node to this Endpoint
Bundle delivery steps are discussed in RFC 5050, Section
5.7"
::= { bpRegEntry 7 }
--
--Sent, Forwarded, and Duplicates moved to node level
--
bpBulkPriorRecvdBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bundles sourced on this
Node from this Endpoint with the priority value -bulk-
Note: the sum of bpNormPriorRecvdBndls,
bpBulkPriorRecvdBndls, and bpExpPriorRecvdBndls can be used
to find the total of Bundles that have been received by this
Node, from this Endpoint.
Sims & Kruse Expires January 16, 2014 [Page 34]
Internet-Draft Bundle Protocol MIB July 2013
Bundle priority settings are mentioned in Section 4.2 of RFC
5050"
::= { bpRegEntry 8 }
--Move to optional group.
bpBulkPriorRecvdBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bytes sourced on this
Node from this Endpoint with the priority value -bulk-
Note: the sum of bpNormPriorRecvdBytes,
bpBulkPriorRecvdBytes, and bpExpPriorRecvdBytes can be used
to find the total of Bundles that have been received by this
Node, from this Endpoint.
Bundle priority settings are mentioned in Section 4.2 of RFC
5050"
::= { bpRegEntry 9 }
bpNormPriorRecvdBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bundles sourced on this
Node from this Endpoint with the priority value -normal-
Note: the sum of bpNormPriorRecvdBndls,
bpBulkPriorRecvdBndls, and bpExpPriorRecvdBndls can be used
to find the total of Bundles that have been received by this
Node, from this Endpoint.
Bundle priority settings are mentioned in Section 4.2 of RFC
5050"
::= { bpRegEntry 10 }
--Move to optional group.
bpNormPriorRecvdBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bytes sourced on this
Node from this Endpoint with the priority value -normal-
Sims & Kruse Expires January 16, 2014 [Page 35]
Internet-Draft Bundle Protocol MIB July 2013
Note: the sum of bpNormPriorRecvdBytes,
bpBulkPriorRecvdBytes, and bpExpPriorRecvdBytes can be used
to find the total of Bundles that have been received by this
Node, from this Endpoint.
Bundle priority settings are mentioned in Section 4.2 of RFC
5050"
::= { bpRegEntry 11 }
bpExpPriorRecvdBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bundles sourced on this
Node from this Endpoint with the priority value -expedited-
Note: the sum of bpNormPriorRecvdBndls,
bpBulkPriorRecvdBndls, and bpExpPriorRecvdBndls can be used
to find the total of Bundles that have been received by this
Node, from this Endpoint.
Bundle priority settings are mentioned in Section 4.2 of RFC
5050"
::= { bpRegEntry 12 }
--Move to optional group.
bpExpPriorRecvdBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This keeps track of the number of Bytes sourced on this
Node from this Endpoint with the priority value -expedited-
Note: the sum of bpNormPriorRecvdBytes,
bpBulkPriorRecvdBytes, and bpExpPriorRecvdBytes can be used
to find the total of Bundles that have been received by this
Node, from this Endpoint.
Bundle priority settings are mentioned in Section 4.2 of RFC
5050"
::= { bpRegEntry 13 }
--
--end end-point level administrative report counters have been moved to node level
--
-- CLA-Specific Definitions
Sims & Kruse Expires January 16, 2014 [Page 36]
Internet-Draft Bundle Protocol MIB July 2013
bpClaObjects OBJECT IDENTIFIER ::= { bpMIB 3 }
--OK as written.
bpClaCount OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is a value that keeps track of how many rows are
currently in the bpClaTable. This value does NOT necessarily
reflect the current number of CLAs (Convergence Layer
Adapters) available to this Node. Since CLAs are
implementation dependent, there are few qualifiers for a
generic set of CLA-related manageable objects. A single Node
can have 0 or more CLAs available, so this value can be set
to 0.
CLAs are described in RFC 5050 in Section 3.1 and CLs are
discussed in Section 7"
::= {bpClaObjects 1 }
--OK as written.
bpClaTable OBJECT-TYPE
SYNTAX SEQUENCE OF BPClaEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This Conceptual table contains the set of CLAs (Convergence
Layer Adapters) that are available to this Node. A CLA is an
interface between the BPA (Bundle Protocol Agent) and an
internetwork protocol suite. CLAs and their functions are
implementation specific, so this set of managed information
doesn't contain much in the way of detail.
The items in this table are similar to the ifStackTable in
RFC 2863, albeit different in that it only tracks the layer
below the BPA (because the Bundle Protocol rests at the
application layer and anything above itself would be done
as a tunnel). Each row represents a single CLA; what
Convergence Layer it's using, and layer traversal
information.
CLAs are described in RFC 5050 in Section 3.1 and CLs are
discussed in Section 7"
::= {bpClaObjects 2 }
--OK as written.
bpClaEntry OBJECT-TYPE
Sims & Kruse Expires January 16, 2014 [Page 37]
Internet-Draft Bundle Protocol MIB July 2013
SYNTAX BPClaEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry represents a single CLA (Convergence Layer
Adapter) of this Node. A CLA, as defined in RFC 5050, is an
interface between the Bundle Protocol Agent and an
inter-network protocol suite. Each bpClaEntry contains a
reference to the layer beneath the BPA or, worded
differently, to its CL (Convergence Layer). It's the job of
the bpClType object in each row to denote what type of
protocol the CL is. If the underlying layer is not an
inter-networking protocol, the bpClType is set to 1 (which
signifies that it's an interface).
CLAs are described in RFC 5050 in Section 3.1 and CLs are
discussed in Section 7"
INDEX
{ bpClaIndex }
::= { bpClaTable 1 }
--OK as written.
BPClaEntry ::= SEQUENCE
{
bpClaIndex Integer32,
bpClType Integer32,
bpClaDisplayName OCTET STRING,
bpClID OCTET STRING,
bpClOutBndls Counter64,
bpClOutBytes Counter64,
bpClInBndls Counter64,
bpClInBytes Counter64,
bpClaDirection BITS
}
--OK as written.
bpClaIndex OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An index value that is used to uniquely represent each
conceptual row of the bpClaTable."
::= { bpClaEntry 1 }
--OK as written.
bpClType OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
Sims & Kruse Expires January 16, 2014 [Page 38]
Internet-Draft Bundle Protocol MIB July 2013
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"With the desire to avoid dependence on any specific
underlying protocols or protocol-suite, this value exists to
specify the underlying CL (Convergence Layer) type being
used by this CLA (Convergence Layer Adapter). Each known CL
type will be associated to a unique integer value greater
than 0. Doing this will help to avoid implementation
inconsistencies.
Each value herein uniquely represents a Convergence Layer
type and, likewise, can be used in conjunction with the
bpClID value to find managed information regarding an
instance of the appropriate CLA's MIB.
Convergence Layer Values:
Interface 1
LTP 2
UDP 3
TCP 4
IP 5
DCCP 6
NOTE: if this convention becomes accepted, these values
should probably make their way into a textual-convention
rather than being loosely defined in a description block!
CLAs are described in RFC 5050 in Section 3.1 and CLs are
discussed in Section 7"
::= { bpClaEntry 2 }
--OK as written.
bpClaDisplayName OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A string value that represents a locally assigned,
human-readable name given to this CLA (Convergence Layer
Adapter) by the BPA (Bundle Protocol Agent); assuming the
BPA implementation has this capability.
CLAs are described in RFC 5050 in Section 3.1 and CLs are
discussed in Section 7"
::= { bpClaEntry 3 }
--OK as written.
Sims & Kruse Expires January 16, 2014 [Page 39]
Internet-Draft Bundle Protocol MIB July 2013
bpClID OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An arbitrary value that uniquely identifies an instance of
managed information for the CLA (Convergence Layer Adapter)
which is associated to this entry.
Interpretation of this value is opaque to a user, but can be
used by the management agent to determine which instance of
a CLA's MIB is referenced by this table entry. The format of
this UID ought to be determined by implementors of BPA
(Bundle Protocol Agent) software and it should be noted that
no two conceptual rows in the bpClaTable (for a given Node)
should have the same bpClID value.
CLAs are described in RFC 5050 in Section 3.1 and CLs are
discussed in Section 7"
::= { bpClaEntry 4 }
--OK as written.
bpClOutBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A counter that keeps track of the number of Bundles passed
from the BPA (Bundle Protocol Agent) to the CL (Convergence
Layer) through this CLA (Convergence Layer Adapter).
Note: CLA implementation compliance is limited in definition
(see RFC 5050), and may result in many styles of CLA MIB
implementation. Some may use a single CLA to handle inbound
and outbound traffic. Other implementations may use one CLA
for inbound traffic and a separate CLA for outbound. To know
if this CLA is uni-directional or bidirectional, look at
bpClaDirection.
CLAs are described in RFC 5050 in Section 3.1 and CLs are
discussed in Section 7"
::= { bpClaEntry 5 }
--Needs discussion... ok
bpClOutBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
Sims & Kruse Expires January 16, 2014 [Page 40]
Internet-Draft Bundle Protocol MIB July 2013
DESCRIPTION
"A counter that keeps track of the number of Bytes passed
from the BPA (Bundle Protocol Agent) to the CL (Convergence
Layer) through this CLA (Convergence Layer Adapter).
Note: CLA implementation compliance is limited in definition
(see RFC 5050), and may result in many styles of CLA MIB
implementation. Some may use a single CLA to handle inbound
and outbound traffic. Other implementations may use one CLA
for inbound traffic and a separate CLA for outbound. To know
if this CLA is uni-directional or bidirectional, look at
bpClaDirection.
CLAs are described in RFC 5050 in Section 3.1 and CLs are
discussed in Section 7"
::= { bpClaEntry 6 }
--OK as written.
bpClInBndls OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A counter that keeps track of the number of Bundles passed
to the BPA (Bundle Protocol Agent) from the CL (Convergence
Layer) through this CLA (Convergence Layer Adapter).
Note: CLA implementation compliance is limited in definition
(see RFC 5050), and may result in many styles of CLA MIB
implementation. Some may use a single CLA to handle inbound
and outbound traffic. Other implementations may use one CLA
for inbound traffic and a separate CLA for outbound. To know
if this CLA is uni-directional or bidirectional, look at
bpClaDirection.
CLAs are described in RFC 5050 in Section 3.1 and CLs are
discussed in Section 7"
::= { bpClaEntry 7 }
--Needs discussion?
bpClInBytes OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A counter that keeps track of the number of Bytes passed to
the BPA (Bundle Protocol Agent) from the CL (Convergence
Layer) through this CLA (Convergence Layer Adapter).
Sims & Kruse Expires January 16, 2014 [Page 41]
Internet-Draft Bundle Protocol MIB July 2013
Note: CLA implementation compliance is limited in definition
(see RFC 5050), and may result in many styles of CLA MIB
implementation. Some may use a single CLA to handle inbound
and outbound traffic. Other implementations may use one CLA
for inbound traffic and a separate CLA for outbound. To know
if this CLA is uni-directional or bidirectional, look at
bpClaDirection.
CLAs are described in RFC 5050 in Section 3.1 and CLs are
discussed in Section 7"
::= { bpClaEntry 8 }
--OK as written.
bpClaDirection OBJECT-TYPE
SYNTAX BITS { inBound(0), outBound(1), biDirectional(2) }
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A value representing the nature of the CLA (Convergence
Layer Adapter) and whether the BPA (Bundle Protocol Agent)
can send/receive to/from the CL through the CLA. Some
implementations of BP software, such as satellite software,
may find it preferable to have uni-directional traffic while
others may prefer to have a single entry resolve all traffic
(bi-directional).
Possible Values:
* inBound - 0 - inbound traffic only
* outBound - 1 - outbound traffic only
* biDirectional - 2 - bi-directional traffic
CLAs are described in RFC 5050 in Section 3.1 and CLs are
discussed in Section 7"
::= { bpClaEntry 9 }
-- Conformance Requirements for the BP-MIB
bpConformance OBJECT IDENTIFIER ::= { bpMIB 4 }
bpMIBCompliance OBJECT IDENTIFIER ::= { bpConformance 1 }
bpCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance for Network Elements that are running a
Bundle Protocol Implementation."
MODULE
--
--List of mandatory groups
Sims & Kruse Expires January 16, 2014 [Page 42]
Internet-Draft Bundle Protocol MIB July 2013
--
MANDATORY-GROUPS {bpNodeInfoGroup,bpNodeActivityGroup}
--
--All groups below are optional
--
GROUP bpNodeDelGroup
DESCRIPTION
"Node-Specific information that keeps counters for the
different reasons a Bundle has been deleted on this Node.
It also tracks a cumulative count of Bytes that have been
on this Node."
GROUP bpNodeStatisticsGroup
DESCRIPTION
"Objects in this group tracks cumulative counts of
Bundles handled by this node."
GROUP bpAdminReportGroup
DESCRIPTION
"Node-Specific information that keeps counters of
administrative reports and custody signals received
by the node. Nodes with sufficient resources may wish
to track these counters for network diagnostics."
GROUP bpRegInfoGroup
DESCRIPTION
"Endpoint-Specific information directly regarding the Node's
Endpoint registrations. Things like: EID, state, and Singleton
status."
GROUP bpRegActivityGroup
DESCRIPTION
"Endpoint-Specific information that keeps counters for the
amount of Bundles/Bytes sourced from and delivered to
each endpoint."
-- GROUP bpRegDelStatusGroup has been removed
GROUP bpClaGroup
DESCRIPTION
"CLA-Specific Information that relates to a Bundle Node's
Convergence Layer Adapters and the corresponding Convergence
Layers themselves. Most nodes, especially those with multiple
CLAs, should provide this information."
GROUP bpNodeBndlVolGroup
DESCRIPTION
"This group is optional. Nodes with sufficient computing resources
Sims & Kruse Expires January 16, 2014 [Page 43]
Internet-Draft Bundle Protocol MIB July 2013
should track these object, while resource-restricted nodes can
likely not perform this tracking"
::= { bpMIBCompliance 1 }
-- BP MIB Group Definitions
bpMIBGroups OBJECT IDENTIFIER ::= { bpConformance 2 }
bpNodeInfoGroup OBJECT-GROUP
OBJECTS
{
bpNodeID,
bpBundleVersion,
bpLastUpTime,
bpAvailStorage,
bpBulkPriorQueuedBndls,
bpNormPriorQueuedBndls,
bpExpPriorQueuedBndls,
bpReassemblyPendingBndls,
bpDispatchPendingBndls,
bpForwardPendingBndls,
bpCustodyAcceptedBndls,
bpExtBlockDisplayName
}
STATUS current
DESCRIPTION
"Node-Specific information regarding the Node itself and the
counts of Bundles which are currently queued by it."
::= { bpMIBGroups 1 }
bpNodeActivityGroup OBJECT-GROUP
OBJECTS
{
bpBulkPriorGenBndls,
bpNormPriorGenBndls,
bpExpPriorGenBndls,
bpCustodyFailureBndls,
bpForwardFailureBndls,
bpAbandonedDeliveryBndls,
bpDiscardedBndls,
bpFragmentedLocally,
bpFragmentsCreated,
}
STATUS current
DESCRIPTION
"Node-Specific objects that offer a view of what a Node
has done locally and what sorts of actions or events the
Node may have undergone."
Sims & Kruse Expires January 16, 2014 [Page 44]
Internet-Draft Bundle Protocol MIB July 2013
::= { bpMIBGroups 2 }
bpNodeDelGroup OBJECT-GROUP
OBJECTS
{
bpDelExpired,
bpDelTransCancelled,
bpDelDepStorage,
bpDelDestUnintel,
bpDelNoRoute,
bpDelUntimelyContact,
bpDelBlockUnintel,
bpDelNoAdditionalInfo,
bpDelBytes
}
STATUS current
DESCRIPTION
"Node-Specific information that keeps counters for the
different reasons a Bundle has been deleted on this Node.
It also tracks a cumulative count of Bytes that have been
on this Node."
::= { bpMIBGroups 3 }
bpNodeStatisticsGroup OBJECT-GROUP
OBJECTS
{
bpBundlesSentBndls,
bpBundlesSentBytes,
bpBundlesForwardedBndls,
bpBundlesForwardedBytes,
bpBundleDuplicatesBndls,
bpBundleDuplicatesBytes
}
STATUS current
DESCRIPTION
"Statistics on bundle handling by this node"
::= { bpMIBGroups 4 }
bpAdminReportGroup OBJECT-GROUP
OBJECTS
{
bpBundleReceptions,
bpCustodyAcceptance,
bpBundleForwarding,
bpBundleDelivery,
bpDelExpiredReports,
bpDelTransCancelledReports,
Sims & Kruse Expires January 16, 2014 [Page 45]
Internet-Draft Bundle Protocol MIB July 2013
bpDelDepStorageReports,
bpDelDestUnintelReports,
bpDelNoRouteReports,
bpDelUntimelyContactReports,
bpDelBlockUnintelReports,
bpDelNoAdditionalInfoReports,
bpCustodySuccess,
bpCustodyTranFail
}
STATUS current
DESCRIPTION
"Endpoint-Specific information that keeps counters for the
number of status reports and custody signals received on this
Node."
::= { bpMIBGroups 5 }
bpRegInfoGroup OBJECT-GROUP
OBJECTS
{
bpRegCount,
bpEndpointID,
bpCurState,
bpIsSingleton,
bpDeliveryFailureAction
}
STATUS current
DESCRIPTION
"Endpoint-Specific information directly regarding the Node's
Endpoint registrations. Things like: EID, state, Singleton
status, and delivery failure action."
::= { bpMIBGroups 6 }
bpRegActivityGroup OBJECT-GROUP
OBJECTS
{
bpBundlesDeliveredBndls,
bpBundlesDeliveredBytes,
bpBulkPriorRecvdBndls,
bpBulkPriorRecvdBytes,
bpNormPriorRecvdBndls,
bpNormPriorRecvdBytes,
bpExpPriorRecvdBndls,
bpExpPriorRecvdBytes
}
STATUS current
DESCRIPTION
"Endpoint-Specific information that keeps counters for the
Sims & Kruse Expires January 16, 2014 [Page 46]
Internet-Draft Bundle Protocol MIB July 2013
amount of Bundles/Bytes sourced from and delivered to
each endpoint."
::= { bpMIBGroups 7 }
bpClaGroup OBJECT-GROUP
OBJECTS
{
bpClaCount,
bpClType,
bpClaDisplayName,
bpClID,
bpClOutBndls,
bpClOutBytes,
bpClInBndls,
bpClInBytes,
bpClaDirection
}
STATUS current
DESCRIPTION
"CLA-Specific Information that relates to a Bundle Node's
Convergence Layer Adapters and the corresponding Convergence
Layers themselves"
::= { bpMIBGroups 8 }
bpNodeBndlVolGroup OBJECT-GROUP
OBJECTS
{
bpBulkPriorQueuedBytes,
bpNormPriorQueuedBytes,
bpExpPriorQueuedBytes,
bpReassemblyPendingBytes,
bpDispatchPendingBytes,
bpForwardPendingBytes,
bpCustodyAcceptedBytes,
bpBulkPriorGenBytes,
bpNormPriorGenBytes,
bpExpPriorGenBytes,
bpCustodyFailureBytes,
bpForwardFailureBytes,
bpAbandonedDeliveryBytes,
bpDiscardedBytes
}
STATUS current
DESCRIPTION
"Node-Specific information the volume (bytes) of data
which are currently queued by it.
Bundle counts are in the bpNodeInfoGroup."
::= { bpMIBGroups 9 }
Sims & Kruse Expires January 16, 2014 [Page 47]
Internet-Draft Bundle Protocol MIB July 2013
END
6. Acknowledgments
Extensive thanks is given to Dovel Myers, Gilbert Clark, Josh
Schendel, and the family of Ohio University's Internetworking
Research Group Laboratory for their contributions on the MIB's design
and how it might inter-relate with other DTN-related MIBs. Many of
the more recent design changes in the MIB are based on input from
Scott Burleigh at JPL and Ed Birraine at APL.
7. IANA Considerations
This section has work to be done. IANA considerations do include:
the standardization of numbers to uniquely identify Convergence Layer
types; creation of a Textual-Convention for bpClType; and creation of
a Textual-Convention for bpExtBlockType.
8. Security Considerations
Though SNMPv3 is the current de facto standard of network management
protocols, there is no guarantee that this will hold true in the DTN
architecture. With this in mind, any protocols used SHOULD consider,
to the fullest feasible extent, the security measures used in SNMPv3.
Design of such protocols SHOULD consider the lessons learned in the
terrestrial Internet. The following paragraphs address issues
specific to SNMP, but may still hold relevance for DTN network
management mechanisms.
There are no management objects defined in this MIB module that have
a MAX-ACCESS clause of read-write and/or read-create. So, if this
MIB module is implemented correctly, then there is no risk that an
intruder can alter or create any management objects of this MIB
module via direct SNMP SET operations.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Sims & Kruse Expires January 16, 2014 [Page 48]
Internet-Draft Bundle Protocol MIB July 2013
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD
58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, April 2007.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
9.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
Sims & Kruse Expires January 16, 2014 [Page 49]
Internet-Draft Bundle Protocol MIB July 2013
Authors' Addresses
Zack Sims
Ohio University
United States
Phone: +1 740 285 1895
EMail: zack.sims@gmail.com
Dr. Hans Kruse
Ohio University
Rm 150, 31 S. Court, Ohio University
Athens, OH 45701
United States
Phone: +1 740 593 4891
EMail: kruse@ohio.edu
Sims & Kruse Expires January 16, 2014 [Page 50]
