summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2214.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2214.txt')
-rw-r--r--doc/rfc/rfc2214.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc2214.txt b/doc/rfc/rfc2214.txt
new file mode 100644
index 0000000..90d83c6
--- /dev/null
+++ b/doc/rfc/rfc2214.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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
+
+
+
+
+
+
+
+
+Baker, et. al. Standards Track [Page 1]
+
+RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997
+
+
+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
+
+
+
+Baker, et. al. Standards Track [Page 2]
+
+RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997
+
+
+ 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
+
+
+
+Baker, et. al. Standards Track [Page 3]
+
+RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997
+
+
+ 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
+
+
+
+Baker, et. al. Standards Track [Page 4]
+
+RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997
+
+
+ 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
+
+
+
+Baker, et. al. Standards Track [Page 5]
+
+RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997
+
+
+ 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
+
+
+
+Baker, et. al. Standards Track [Page 6]
+
+RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Baker, et. al. Standards Track [Page 7]
+
+RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997
+
+
+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).
+
+
+
+
+Baker, et. al. Standards Track [Page 8]
+
+RFC 2214 IS Guaranteed Service MIB using SMIv2 September 1997
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baker, et. al. Standards Track [Page 9]
+