GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2214

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2214.txt · Last modified: 1997/09/30 22:17 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki