home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc2214.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  15.6 KB  |  508 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       F. Baker
  8. Request for Comments: 2214                             Cisco Systems
  9. Category: Standards Track                                J. Krawczyk
  10.                                            ArrowPoint Communications
  11.                                                            A. Sastry
  12.                                                        Cisco Systems
  13.                                                       September 1997
  14.  
  15.  
  16.             Integrated Services Management Information Base
  17.                Guaranteed Service Extensions using SMIv2
  18.  
  19.  
  20. Status of this Memo
  21.  
  22.    This document specifies an Internet standards track protocol for the
  23.    Internet community, and requests discussion and suggestions for
  24.    improvements.  Please refer to the current edition of the "Internet
  25.    Official Protocol Standards" (STD 1) for the standardization state
  26.    and status of this protocol.  Distribution of this memo is unlimited.
  27.  
  28. Abstract
  29.  
  30.    This memo defines a portion of the Management Information Base (MIB)
  31.    for use with network management protocols in TCP/IP-based internets.
  32.    In particular, it defines objects for managing the the interface
  33.    attributes defined in the Guaranteed Service of the Integrated
  34.    Services Model.  Comments should be made to the Integrated Services
  35.    Working Group, intserv@isi.edu.
  36.  
  37. Table of Contents
  38.  
  39.    1 The SNMPv2 Network Management Framework ...............    2
  40.    1.1 Object Definitions ..................................    2
  41.    2 Overview ..............................................    2
  42.    2.1 Textual Conventions .................................    2
  43.    3 Definitions ...........................................    3
  44.    3.1 Interface Attributes Database .......................    3
  45.    3.2 Notifications .......................................    6
  46.    4 Security Considerations ...............................    7
  47.    5 Authors' Addresses ....................................    8
  48.    6 Acknowledgements ......................................    8
  49.    7 References ............................................    8
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Baker, et. al.              Standards Track                     [Page 1]
  59.  
  60. RFC 2214         IS Guaranteed Service MIB using SMIv2    September 1997
  61.  
  62.  
  63. 1.  The SNMPv2 Network Management Framework
  64.  
  65.    The SNMPv2 Network Management Framework consists of four major
  66.    components.  They are:
  67.  
  68.    o    RFC 1441 which defines the SMI, the mechanisms used for
  69.         describing and naming objects for the purpose of
  70.         management.
  71.  
  72.    o    STD 17, RFC 1213 defines MIB-II, the core set of managed objects
  73.         for the Internet suite of protocols.
  74.  
  75.    o    RFC 1445 which defines the administrative and other
  76.         architectural aspects of the framework.
  77.  
  78.    o    RFC 1448 which defines the protocol used for network
  79.         access to managed objects.
  80.  
  81.    The Framework permits new objects to be defined for the purpose of
  82.    experimentation and evaluation.
  83.  
  84. 1.1.  Object Definitions
  85.  
  86.    Managed objects are accessed via a virtual information store, termed
  87.    the Management Information Base or MIB.  Objects in the MIB are
  88.    defined using the subset of Abstract Syntax Notation One (ASN.1)
  89.    defined in the SMI.  In particular, each object type is named by an
  90.    OBJECT IDENTIFIER, an administratively assigned name.  The object
  91.    type together with an object instance serves to uniquely identify a
  92.    specific instantiation of the object.  For human convenience, we
  93.    often use a textual string, termed the descriptor, to refer to the
  94.    object type.
  95.  
  96. 2.  Overview
  97.  
  98. 2.1.  Textual Conventions
  99.  
  100.    Several new data types are introduced as a textual convention in this
  101.    MIB document.  These textual conventions enhance the readability of
  102.    the specification and can ease comparison with other specifications
  103.    if appropriate.  It should be noted that the introduction of the
  104.    these textual conventions has no effect on either the syntax nor the
  105.    semantics of any managed objects.  The use of these is merely an
  106.    artifact of the explanatory method used.  Objects defined in terms of
  107.    one of these methods are always encoded by means of the rules that
  108.    define the primitive type.  Hence, no changes to the SMI or the SNMP
  109.    are necessary to accommodate these textual conventions which are
  110.    adopted merely for the convenience of readers and writers in pursuit
  111.  
  112.  
  113.  
  114. Baker, et. al.              Standards Track                     [Page 2]
  115.  
  116. RFC 2214         IS Guaranteed Service MIB using SMIv2    September 1997
  117.  
  118.  
  119.    of the elusive goal of clear, concise, and unambiguous MIB documents.
  120.  
  121. 3.  Definitions
  122.  
  123. INTEGRATED-SERVICES-GUARANTEED-MIB DEFINITIONS ::= BEGIN
  124.  
  125.     IMPORTS
  126.             MODULE-IDENTITY, OBJECT-TYPE             FROM SNMPv2-SMI
  127.             RowStatus                                FROM SNMPv2-TC
  128.             MODULE-COMPLIANCE, OBJECT-GROUP          FROM SNMPv2-CONF
  129.             intSrv                        FROM INTEGRATED-SERVICES-MIB
  130.             ifIndex                                  FROM IF-MIB;
  131.  
  132. --  This MIB module uses the extended OBJECT-TYPE macro as
  133. --  defined in [9].
  134.  
  135. intSrvGuaranteed MODULE-IDENTITY
  136.         LAST-UPDATED "9511030500Z" -- Thu Aug 28 09:04:22 PDT 1997
  137.         ORGANIZATION "IETF Integrated Services Working Group"
  138.         CONTACT-INFO
  139.        "       Fred Baker
  140.        Postal: Cisco Systems
  141.                519 Lado Drive
  142.                Santa Barbara, California 93111
  143.        Tel:    +1 805 681 0115
  144.        E-Mail: fred@cisco.com"
  145.     DESCRIPTION
  146.        "The MIB module to describe the Guaranteed Service of
  147.        the Integrated Services Protocol"
  148.     ::= { intSrv 5 }
  149.  
  150. intSrvGuaranteedObjects          OBJECT IDENTIFIER
  151.                                  ::= { intSrvGuaranteed 1 }
  152. intSrvGuaranteedNotifications    OBJECT IDENTIFIER
  153.                                  ::= { intSrvGuaranteed 2 }
  154. intSrvGuaranteedConformance      OBJECT IDENTIFIER
  155.                                  ::= { intSrvGuaranteed 3 }
  156.  
  157.  
  158. --      The Integrated Services Interface Attributes Database
  159. --      contains information that is shared with other reservation
  160. --      procedures such as ST-II.
  161.  
  162.  
  163.     intSrvGuaranteedIfTable OBJECT-TYPE
  164.         SYNTAX      SEQUENCE OF IntSrvGuaranteedIfEntry
  165.         MAX-ACCESS  not-accessible
  166.         STATUS      current
  167.  
  168.  
  169.  
  170. Baker, et. al.              Standards Track                     [Page 3]
  171.  
  172. RFC 2214         IS Guaranteed Service MIB using SMIv2    September 1997
  173.  
  174.  
  175.         DESCRIPTION
  176.            "The attributes of the system's interfaces  ex-
  177.            ported by the Guaranteed Service."
  178.        ::= { intSrvGuaranteedObjects 1 }
  179.  
  180.  
  181.     intSrvGuaranteedIfEntry OBJECT-TYPE
  182.         SYNTAX      IntSrvGuaranteedIfEntry
  183.         MAX-ACCESS  not-accessible
  184.         STATUS      current
  185.         DESCRIPTION
  186.            "The reservable attributes of  a  given  inter-
  187.            face."
  188.        INDEX { ifIndex }
  189.        ::= { intSrvGuaranteedIfTable 1 }
  190.  
  191. IntSrvGuaranteedIfEntry ::=
  192.     SEQUENCE {
  193.         intSrvGuaranteedIfBacklog INTEGER,
  194.         intSrvGuaranteedIfDelay   INTEGER,
  195.         intSrvGuaranteedIfSlack   INTEGER,
  196.         intSrvGuaranteedIfStatus  RowStatus
  197.     }
  198.  
  199.     intSrvGuaranteedIfBacklog OBJECT-TYPE
  200.         SYNTAX      INTEGER (0..'0FFFFFFF'h)
  201.         UNITS       "bytes"
  202.         MAX-ACCESS  read-create
  203.         STATUS      current
  204.         DESCRIPTION
  205.            "The Backlog  parameter  is  the  data  backlog
  206.            resulting  from  the vagaries of how a specific
  207.            implementation deviates from a  strict  bit-by-
  208.            bit  service.  So, for instance, for packetized
  209.            weighted fair queueing, Backlog is set  to  the
  210.            Maximum Packet Size.
  211.  
  212.            The Backlog term is measured in units of bytes.
  213.            An  individual  element can advertise a Backlog
  214.            value between 1 and 2**28 (a  little  over  250
  215.            megabytes)  and  the  total added over all ele-
  216.            ments can range as high as  (2**32)-1.   Should
  217.            the  sum of the different elements delay exceed
  218.            (2**32)-1, the end-to-end error term should  be
  219.            (2**32)-1."
  220.        ::= { intSrvGuaranteedIfEntry 1 }
  221.  
  222.     intSrvGuaranteedIfDelay OBJECT-TYPE
  223.  
  224.  
  225.  
  226. Baker, et. al.              Standards Track                     [Page 4]
  227.  
  228. RFC 2214         IS Guaranteed Service MIB using SMIv2    September 1997
  229.  
  230.  
  231.         SYNTAX      INTEGER (0..'0FFFFFFF'h)
  232.         UNITS       "microseconds"
  233.         MAX-ACCESS  read-create
  234.         STATUS      current
  235.         DESCRIPTION
  236.            "The Delay parameter at  each  service  element
  237.            should  be  set  to the maximum packet transfer
  238.            delay (independent of bucket size) through  the
  239.            service  element.   For  instance,  in a simple
  240.            router, one might compute the worst case amount
  241.            of  time  it  make  take  for a datagram to get
  242.            through the input interface to  the  processor,
  243.            and how long it would take to get from the pro-
  244.            cessor to the outbound interface (assuming  the
  245.            queueing  schemes work correctly).  For an Eth-
  246.            ernet, it might represent the worst case  delay
  247.            if  the maximum number of collisions is experi-
  248.            enced.
  249.  
  250.            The Delay term is measured in units of one  mi-
  251.            crosecond.  An individual element can advertise
  252.            a delay value between  1  and  2**28  (somewhat
  253.            over two minutes) and the total delay added all
  254.            elements  can  range  as  high  as   (2**32)-1.
  255.            Should  the sum of the different elements delay
  256.            exceed (2**32)-1, the end-to-end  delay  should
  257.            be (2**32)-1."
  258.        ::= { intSrvGuaranteedIfEntry 2 }
  259.  
  260.     intSrvGuaranteedIfSlack OBJECT-TYPE
  261.         SYNTAX      INTEGER (0..'0FFFFFFF'h)
  262.         MAX-ACCESS  read-create
  263.         STATUS      current
  264.         DESCRIPTION
  265.            "If a network element uses a certain amount  of
  266.            slack,  Si,  to  reduce the amount of resources
  267.            that it has reserved for a particular flow,  i,
  268.            the  value  Si  should be stored at the network
  269.            element.   Subsequently,  if  reservation   re-
  270.            freshes  are  received  for flow i, the network
  271.            element must use the same slack Si without  any
  272.            further computation. This guarantees consisten-
  273.            cy in the reservation process.
  274.  
  275.            As an example for the use of  the  slack  term,
  276.            consider the case where the required end-to-end
  277.            delay, Dreq, is larger than the  maximum  delay
  278.            of the fluid flow system.  In this, Ctot is the
  279.  
  280.  
  281.  
  282. Baker, et. al.              Standards Track                     [Page 5]
  283.  
  284. RFC 2214         IS Guaranteed Service MIB using SMIv2    September 1997
  285.  
  286.  
  287.            sum of the Backlog terms end to end,  and  Dtot
  288.            is the sum of the delay terms end to end.  Dreq
  289.            is obtained by setting R=r in the  fluid  delay
  290.            formula, and is given by
  291.  
  292.                         b/r + Ctot/r + Dtot.
  293.  
  294.            In this case the slack term is
  295.  
  296.                   S = Dreq - (b/r + Ctot/r + Dtot).
  297.  
  298.            The slack term may be used by the network  ele-
  299.            ments  to  adjust  their local reservations, so
  300.            that they can admit flows that would  otherwise
  301.            have been rejected. A service element at an in-
  302.            termediate network element that can  internally
  303.            differentiate between delay and rate guarantees
  304.            can now take advantage of this  information  to
  305.            lower the amount of resources allocated to this
  306.            flow. For example, by taking an amount of slack
  307.            s  <= S, an RCSD scheduler [5] can increase the
  308.            local delay bound, d, assigned to the flow,  to
  309.            d+s. Given an RSpec, (Rin, Sin), it would do so
  310.            by setting Rout = Rin and Sout = Sin - s.
  311.  
  312.            Similarly,  a  network  element  using  a   WFQ
  313.            scheduler  can  decrease  its local reservation
  314.            from Rin to Rout by using some of the slack  in
  315.            the  RSpec.  This  can be accomplished by using
  316.            the transformation rules given in the  previous
  317.            section,  that ensure that the reduced reserva-
  318.            tion level will not increase the  overall  end-
  319.            to-end delay."
  320.        ::= { intSrvGuaranteedIfEntry 3 }
  321.  
  322.  
  323.     intSrvGuaranteedIfStatus OBJECT-TYPE
  324.         SYNTAX      RowStatus
  325.         MAX-ACCESS  read-create
  326.         STATUS      current
  327.         DESCRIPTION
  328.            "'valid' on interfaces that are configured  for
  329.            the Guaranteed Service."
  330.        ::= { intSrvGuaranteedIfEntry 4 }
  331.  
  332. --      No notifications are currently defined
  333.  
  334. -- conformance information
  335.  
  336.  
  337.  
  338. Baker, et. al.              Standards Track                     [Page 6]
  339.  
  340. RFC 2214         IS Guaranteed Service MIB using SMIv2    September 1997
  341.  
  342.  
  343. intSrvGuaranteedGroups      OBJECT IDENTIFIER
  344.                             ::= { intSrvGuaranteedConformance 1 }
  345. intSrvGuaranteedCompliances OBJECT IDENTIFIER
  346.                             ::= { intSrvGuaranteedConformance 2 }
  347.  
  348. -- compliance statements
  349.  
  350.     intSrvGuaranteedCompliance MODULE-COMPLIANCE
  351.         STATUS  current
  352.         DESCRIPTION
  353.            "The compliance statement "
  354.        MODULE  -- this module
  355.        MANDATORY-GROUPS {
  356.            intSrvGuaranteedIfAttribGroup
  357.            }
  358.        ::= { intSrvGuaranteedCompliances 1 }
  359.  
  360.  
  361.     intSrvGuaranteedIfAttribGroup OBJECT-GROUP
  362.          OBJECTS {
  363.             intSrvGuaranteedIfBacklog,
  364.             intSrvGuaranteedIfDelay,
  365.             intSrvGuaranteedIfSlack,
  366.             intSrvGuaranteedIfStatus
  367.         }
  368.         STATUS  current
  369.         DESCRIPTION
  370.            "These objects are required  for  Systems  sup-
  371.            porting the Guaranteed Service of the Integrat-
  372.            ed Services Architecture."
  373.        ::= { intSrvGuaranteedGroups 2 }
  374.  
  375. END
  376.  
  377. 4.  Security Considerations
  378.  
  379.    The use of an SNMP SET results in an RSVP or Integrated Services
  380.    reservation under rules that are different compared to if the
  381.    reservation was negotiated using RSVP. However, no other security
  382.    considerations exist other than those imposed by SNMP itself.
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Baker, et. al.              Standards Track                     [Page 7]
  395.  
  396. RFC 2214         IS Guaranteed Service MIB using SMIv2    September 1997
  397.  
  398.  
  399. 5.  Authors' Addresses
  400.  
  401.          Fred Baker
  402.  Postal: Cisco Systems
  403.          519 Lado Drive
  404.          Santa Barbara, California 93111
  405.  
  406.  Phone:  +1 805 681 0115
  407.  EMail:  fred@cisco.com
  408.  
  409.  
  410.          John Krawczyk
  411.  Postal: ArrowPoint Communications
  412.          235 Littleton Road
  413.          Westford, Massachusetts 01886
  414.  
  415.  Phone:  +1 508 692 5875
  416.  EMail:  jjk@tiac.net
  417.  
  418.  
  419.          Arun Sastry
  420.  Postal: Cisco Systems
  421.          210 W. Tasman Drive
  422.          San Jose, California 95314
  423.  
  424.  Phone:  +1 408 526 7685
  425.  EMail:  arun@cisco.com
  426.  
  427. 6.  Acknowledgements
  428.  
  429.    This document was produced by the Integrated Services Working Group.
  430.  
  431. 7.  References
  432.  
  433.    [1]  Rose, M., Editor, "Management Information Base for
  434.         Network Management of TCP/IP-based internets", STD 17, RFC 1213,
  435.         May 1990.
  436.  
  437.    [2]  Information processing systems - Open Systems
  438.         Interconnection - Specification of Abstract Syntax Notation One
  439.         (ASN.1), International Organization for Standardization.
  440.         International Standard 8824, (December, 1987).
  441.  
  442.    [3]  Information processing systems - Open Systems
  443.         Interconnection - Specification of Basic Encoding Rules for
  444.         Abstract Notation One (ASN.1), International Organization for
  445.         Standardization.  International Standard 8825, (December, 1987).
  446.  
  447.  
  448.  
  449.  
  450. Baker, et. al.              Standards Track                     [Page 8]
  451.  
  452. RFC 2214         IS Guaranteed Service MIB using SMIv2    September 1997
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Baker, et. al.              Standards Track                     [Page 9]
  507.  
  508.