IntServ Guaranteed MIB: Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2
SNMP objects that let a manager read and set the Guaranteed Service attributes of each interface.
Baker, F., Krawczyk, J., and A. Sastry, "Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2", RFC 2214, DOI 10.17487/RFC2214, September 1997, <https://www.rfc-editor.org/info/rfc2214>.
@misc{rfc2214,
series = {Request for Comments},
number = 2214,
howpublished = {RFC 2214},
publisher = {RFC Editor},
doi = {10.17487/RFC2214},
url = {https://www.rfc-editor.org/info/rfc2214},
author = {F. Baker and J. Krawczyk and A. Sastry},
title = {{Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2}},
pagetotal = 9,
year = 1997,
month = sep,
} RFC text
Contents
Network Working Group F. Baker
Request for Comments: 2214 Cisco Systems
Category: Standards Track J. Krawczyk
ArrowPoint Communications
A. Sastry
Cisco Systems
September 1997
Integrated Services Management Information Base
Guaranteed Service Extensions using SMIv2
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing the the interface
attributes defined in the Guaranteed Service of the Integrated
Services Model. Comments should be made to the Integrated Services
Working Group, intserv@isi.edu.
Table of Contents
1 The SNMPv2 Network Management Framework ............... 2
1.1 Object Definitions .................................. 2
2 Overview .............................................. 2
2.1 Textual Conventions ................................. 2
3 Definitions ........................................... 3
3.1 Interface Attributes Database ....................... 3
3.2 Notifications ....................................... 6
4 Security Considerations ............................... 7
5 Authors' Addresses .................................... 8
6 Acknowledgements ...................................... 8
7 References ............................................ 8
1. The SNMPv2 Network Management Framework
The SNMPv2 Network Management Framework consists of four major
components. They are:
o RFC 1441 which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of
management.
o STD 17, RFC 1213 defines MIB-II, the core set of managed objects
for the Internet suite of protocols.
o RFC 1445 which defines the administrative and other
architectural aspects of the framework.
o 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.
1.1. Object Definitions
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1)
defined in the SMI. In particular, each object type is named by an
OBJECT IDENTIFIER, an administratively assigned name. The object
type together with an object instance serves to uniquely identify a
specific instantiation of the object. For human convenience, we
often use a textual string, termed the descriptor, to refer to the
object type.
2. Overview
2.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.
3. Definitions
INTEGRATED-SERVICES-GUARANTEED-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI
RowStatus FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
intSrv FROM INTEGRATED-SERVICES-MIB
ifIndex FROM IF-MIB;
-- This MIB module uses the extended OBJECT-TYPE macro as
-- defined in [9].
intSrvGuaranteed MODULE-IDENTITY
LAST-UPDATED "9511030500Z" -- Thu Aug 28 09:04:22 PDT 1997
ORGANIZATION "IETF Integrated Services Working Group"
CONTACT-INFO
" Fred Baker
Postal: Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
Tel: +1 805 681 0115
E-Mail: fred@cisco.com"
DESCRIPTION
"The MIB module to describe the Guaranteed Service of
the Integrated Services Protocol"
::= { intSrv 5 }
intSrvGuaranteedObjects OBJECT IDENTIFIER
::= { intSrvGuaranteed 1 }
intSrvGuaranteedNotifications OBJECT IDENTIFIER
::= { intSrvGuaranteed 2 }
intSrvGuaranteedConformance OBJECT IDENTIFIER
::= { intSrvGuaranteed 3 }
-- The Integrated Services Interface Attributes Database
-- contains information that is shared with other reservation
-- procedures such as ST-II.
intSrvGuaranteedIfTable OBJECT-TYPE
SYNTAX SEQUENCE OF IntSrvGuaranteedIfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The attributes of the system's interfaces ex-
ported by the Guaranteed Service."
::= { intSrvGuaranteedObjects 1 }
intSrvGuaranteedIfEntry OBJECT-TYPE
SYNTAX IntSrvGuaranteedIfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The reservable attributes of a given inter-
face."
INDEX { ifIndex }
::= { intSrvGuaranteedIfTable 1 }
IntSrvGuaranteedIfEntry ::=
SEQUENCE {
intSrvGuaranteedIfBacklog INTEGER,
intSrvGuaranteedIfDelay INTEGER,
intSrvGuaranteedIfSlack INTEGER,
intSrvGuaranteedIfStatus RowStatus
}
intSrvGuaranteedIfBacklog OBJECT-TYPE
SYNTAX INTEGER (0..'0FFFFFFF'h)
UNITS "bytes"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"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."
::= { intSrvGuaranteedIfEntry 1 }
intSrvGuaranteedIfDelay OBJECT-TYPE
SYNTAX INTEGER (0..'0FFFFFFF'h)
UNITS "microseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"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."
::= { intSrvGuaranteedIfEntry 2 }
intSrvGuaranteedIfSlack OBJECT-TYPE
SYNTAX INTEGER (0..'0FFFFFFF'h)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"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."
::= { intSrvGuaranteedIfEntry 3 }
intSrvGuaranteedIfStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"'valid' on interfaces that are configured for
the Guaranteed Service."
::= { intSrvGuaranteedIfEntry 4 }
-- No notifications are currently defined
-- conformance information
intSrvGuaranteedGroups OBJECT IDENTIFIER
::= { intSrvGuaranteedConformance 1 }
intSrvGuaranteedCompliances OBJECT IDENTIFIER
::= { intSrvGuaranteedConformance 2 }
-- compliance statements
intSrvGuaranteedCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement "
MODULE -- this module
MANDATORY-GROUPS {
intSrvGuaranteedIfAttribGroup
}
::= { intSrvGuaranteedCompliances 1 }
intSrvGuaranteedIfAttribGroup OBJECT-GROUP
OBJECTS {
intSrvGuaranteedIfBacklog,
intSrvGuaranteedIfDelay,
intSrvGuaranteedIfSlack,
intSrvGuaranteedIfStatus
}
STATUS current
DESCRIPTION
"These objects are required for Systems sup-
porting the Guaranteed Service of the Integrat-
ed Services Architecture."
::= { intSrvGuaranteedGroups 2 }
END
4. Security Considerations
The use of an SNMP SET results in an RSVP or Integrated Services
reservation under rules that are different compared to if the
reservation was negotiated using RSVP. However, no other security
considerations exist other than those imposed by SNMP itself.
5. Authors' Addresses
Fred Baker
Postal: Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
Phone: +1 805 681 0115
EMail: fred@cisco.com
John Krawczyk
Postal: ArrowPoint Communications
235 Littleton Road
Westford, Massachusetts 01886
Phone: +1 508 692 5875
EMail: jjk@tiac.net
Arun Sastry
Postal: Cisco Systems
210 W. Tasman Drive
San Jose, California 95314
Phone: +1 408 526 7685
EMail: arun@cisco.com
6. Acknowledgements
This document was produced by the Integrated Services Working Group.
7. References
[1] Rose, M., Editor, "Management Information Base for
Network Management of TCP/IP-based internets", STD 17, RFC 1213,
May 1990.
[2] Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax Notation One
(ASN.1), International Organization for Standardization.
International Standard 8824, (December, 1987).
[3] 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).
AI ELI5
On this page
§1Where This MIB Fits
RFC 2214 defines a portion of the Management Information Base (MIB) for TCP/IP networks. It covers the interface attributes defined by the Guaranteed Service of the Integrated Services model.
The document follows the SNMPv2 Network Management Framework. That framework has four parts: the SMI (RFC 1441) for describing and naming objects, MIB-II (RFC 1213) as the core set of objects, the administrative architecture (RFC 1445) and the protocol for network access to managed objects (RFC 1448).
Network equipment has a standard way to be asked questions from afar. This document adds a new set of questions just for the guaranteed-delivery option.
§2Objects and Textual Conventions
Managed objects are reached through a virtual information store, the MIB. Each object type is named by an OBJECT IDENTIFIER, and the object type together with an instance identifies one specific value.
The MIB also introduces textual conventions. The RFC says these only improve readability: they change neither the syntax nor the meaning of any object, and objects using them are encoded with the rules of the primitive type.
Every setting gets a unique name tag, like a label on a drawer. Nicknames make the list easier to read but do not change what is in the drawers.
§3.1The Interface Attributes Table
The module is called intSrvGuaranteed and sits under intSrv as node 5. It has three branches: objects, notifications and conformance. The attributes live in the Integrated Services Interface Attributes Database, which the RFC says holds information shared with other reservation procedures such as ST-II.
The single table, intSrvGuaranteedIfTable, has one row per interface, indexed by ifIndex. Each row has four columns: intSrvGuaranteedIfBacklog, intSrvGuaranteedIfDelay, intSrvGuaranteedIfSlack and intSrvGuaranteedIfStatus. All four are read-create, so a manager can both read and set them.
It is a spreadsheet with one row for each network plug on the device. Each row has four boxes to fill in.
- intSrvGuaranteed intSrv 5
- intSrvGuaranteedObjects
- intSrvGuaranteedIfTable
- Backlog, Delay, Slack, Status
- intSrvGuaranteedIfTable
- intSrvGuaranteedNotifications none defined
- intSrvGuaranteedConformance
- intSrvGuaranteedObjects
§3.1.1Backlog, Delay and Slack
Backlog is the data backlog that arises because a real implementation deviates from strict bit-by-bit service. For packetized weighted fair queueing it is set to the Maximum Packet Size. It is measured in bytes. An element can advertise a value between 1 and 228, and the total over all elements can reach (232)-1, which is also the cap on the end-to-end value.
Delay is the maximum packet transfer delay through the element, independent of bucket size. It is measured in microseconds, with the same bounds as Backlog: 1 to 228 for one element and a cap of (232)-1 end to end.
Slack is for an element that uses some slack, Si, to reduce the resources reserved for flow i. It must store Si and reuse it, without recomputing, when reservation refreshes arrive. The RFC gives the required end-to-end delay as b/r + Ctot/r + Dtot, where Ctot and Dtot are the summed Backlog and Delay terms, and the slack as S = Dreq - (b/r + Ctot/r + Dtot). An element can use slack to admit flows that would otherwise be rejected.
Backlog is how much stuff can pile up, Delay is the longest a packet might wait, and Slack is spare time that the router can use to ask for less of its resources.
§3.2Status, Notifications and Conformance
intSrvGuaranteedIfStatus is a RowStatus column. It is valid on interfaces that are configured for the Guaranteed Service.
No notifications are defined. For conformance, the module has one compliance statement that makes the group intSrvGuaranteedIfAttribGroup mandatory. That group contains all four table columns and is required for systems supporting the Guaranteed Service of the Integrated Services Architecture.
A switch tells whether each plug is set up for the guaranteed option. Anything that claims to support the option must have all four boxes.
§4Security Considerations
The RFC notes one specific point: an SNMP SET results in an RSVP or Integrated Services reservation under rules that differ from those applied when the reservation is negotiated using RSVP. Beyond that, no security considerations exist other than those imposed by SNMP itself.
Changing a setting by remote control makes a booking in a different way than asking nicely through the normal route. Otherwise it is as safe as the remote control itself.