summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2214.txt
blob: 90d83c66456aad6a6eb515c9d36194aff5651a45 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
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
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
RFC 2214         IS Guaranteed Service MIB using SMIv2    September 1997





















































Baker, et. al.              Standards Track                     [Page 9]
^L