INTEGRATED-SERVICES-GUARANTEED-MIB.mib object view, vendor RFC

Introduction

Most network devices and programs ship with so-called MIB files to describe the parameters and meanings (i.e.: friendly names) which are available for monitoring via SNMP.
ActiveXperts Network Monitor 2024 can import vendor-specific MIB files, so it can be used to monitor specific OID's (Object Identifiers). This way, you can monitor your devices, computers, etc. by selecting your relevant OID's by name.

ActiveXperts Network Monitor 2024 can import MIB file INTEGRATED-SERVICES-GUARANTEED-MIB and use it to monitor vendor specific OID's.

INTEGRATED-SERVICES-GUARANTEED-MIB file content

Object view of INTEGRATED-SERVICES-GUARANTEED-MIB:

Scalar Object
intSrvGuaranteedIfEntry	.1.3.6.1.2.1.52.5.1.1.1
The reservable attributes of a given inter- face.
Tabular Object
intSrvGuaranteedIfBacklog	.1.3.6.1.2.1.52.5.1.1.1.1
The Backlog parameter is the data backlog resulting from the vagaries of how a specific implementation deviates from a strict bit-by- bit service. So, for instance, for packetized weighted fair queueing, Backlog is set to the Maximum Packet Size. The Backlog term is measured in units of bytes. An individual element can advertise a Backlog value between 1 and 2**28 (a little over 250 megabytes) and the total added over all ele- ments can range as high as (2**32)-1. Should the sum of the different elements delay exceed (2**32)-1, the end-to-end error term should be (2**32)-1.
intSrvGuaranteedIfDelay	.1.3.6.1.2.1.52.5.1.1.1.2
The Delay parameter at each service element should be set to the maximum packet transfer delay (independent of bucket size) through the service element. For instance, in a simple router, one might compute the worst case amount of time it make take for a datagram to get through the input interface to the processor, and how long it would take to get from the pro- cessor to the outbound interface (assuming the queueing schemes work correctly). For an Eth- ernet, it might represent the worst case delay if the maximum number of collisions is experi- enced. The Delay term is measured in units of one mi- crosecond. An individual element can advertise a delay value between 1 and 2**28 (somewhat over two minutes) and the total delay added all elements can range as high as (2**32)-1. Should the sum of the different elements delay exceed (2**32)-1, the end-to-end delay should be (2**32)-1.
intSrvGuaranteedIfSlack	.1.3.6.1.2.1.52.5.1.1.1.3
If a network element uses a certain amount of slack, Si, to reduce the amount of resources that it has reserved for a particular flow, i, the value Si should be stored at the network element. Subsequently, if reservation re- freshes are received for flow i, the network element must use the same slack Si without any further computation. This guarantees consisten- cy in the reservation process. As an example for the use of the slack term, consider the case where the required end-to-end delay, Dreq, is larger than the maximum delay of the fluid flow system. In this, Ctot is the sum of the Backlog terms end to end, and Dtot is the sum of the delay terms end to end. Dreq is obtained by setting R=r in the fluid delay formula, and is given by b/r + Ctot/r + Dtot. In this case the slack term is S = Dreq - (b/r + Ctot/r + Dtot). The slack term may be used by the network ele- ments to adjust their local reservations, so that they can admit flows that would otherwise have been rejected. A service element at an in- termediate network element that can internally differentiate between delay and rate guarantees can now take advantage of this information to lower the amount of resources allocated to this flow. For example, by taking an amount of slack s <= S, an RCSD scheduler [5] can increase the local delay bound, d, assigned to the flow, to d+s. Given an RSpec, (Rin, Sin), it would do so by setting Rout = Rin and Sout = Sin - s. Similarly, a network element using a WFQ scheduler can decrease its local reservation from Rin to Rout by using some of the slack in the RSpec. This can be accomplished by using the transformation rules given in the previous section, that ensure that the reduced reserva- tion level will not increase the overall end- to-end delay.
intSrvGuaranteedIfStatus	.1.3.6.1.2.1.52.5.1.1.1.4
'valid' on interfaces that are configured for the Guaranteed Service.
Table
intSrvGuaranteedIfTable	.1.3.6.1.2.1.52.5.1.1
The attributes of the system's interfaces ex- ported by the Guaranteed Service.
Object Identifier
intSrvGuaranteed	.1.3.6.1.2.1.52.5
The MIB module to describe the Guaranteed Service of the Integrated Services Protocol
intSrvGuaranteedObjects	.1.3.6.1.2.1.52.5.1
intSrvGuaranteedNotifications	.1.3.6.1.2.1.52.5.2
intSrvGuaranteedConformance	.1.3.6.1.2.1.52.5.3
intSrvGuaranteedGroups	.1.3.6.1.2.1.52.5.3.1
intSrvGuaranteedCompliances	.1.3.6.1.2.1.52.5.3.2
Group
intSrvGuaranteedIfAttribGroup	.1.3.6.1.2.1.52.5.3.1.2
These objects are required for Systems sup- porting the Guaranteed Service of the Integrat- ed Services Architecture.