rfc1857.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,516 行 · 第 1/4 页

   Using a query language, the client should be able to define the
   network object, the interface, the metrics and the time period to be
   provided.  Using a TCP-based protocol, the server will transmit the
   requested data.  Once these data are received by the client, they
   could be processed and presented by a variety of tools. One
   possibility is to have an X-Window based tool that displays defined
   diagrams from data, supporting such diagrams being fed into the X-
   Window tool directly from the statistical server. Another
   complementary method would be to generate PostScript output to print
   the diagrams. In all cases it should be possible to store the
   retrieved data locally for later processing.

   The client/server approach is discussed further by Henry Clark in
   RFC 1856.

8.2.  Inclusion of Variables not in the Internet Standard MIB

   As has been pointed out above in the categorization of metrics, there
   are metrics which certainly could have been recommended if they were
   available in the Internet Standard MIB. To facilitate the inclusion
   of such metrics in the set of recommended metrics, it will be
   necessary to specify a subtree in the Internet Standard MIB
   containing variables judged necessary in the scope of performing
   operational statistics.

8.3.  Detailed Resource Utilization Statistics

   One area of interest not covered in the above description of metrics
   and presentation formats is to present statistics on detailed views
   of the traffic flows. Such views could include statistics on a per
   application basis and on a per protocol basis. Today such metrics are
   not part of the Internet Standard MIB. Tools like the NSF NNStat are
   being used to gather information of this kind. A possible way to
   achieve such data could be to define an NNStat MIB or to include such
   variables in the above suggested operational statistics MIB subtree.





Lambert                      Informational                     [Page 21]

RFC 1857                 Operational Statistics             October 1995


APPENDIX A

Some formulas for statistical aggregation

   The following naming conventions are used:

   For poll values poll(n)_j

           n = Polling or aggregation period
           j = Entry number

   poll(900)_j is thus the 15 minute total value.

   For peak values peak(n,m)_j

           n = Period over which the peak is calculated
           m = The peak period length
           j = Entry number

   peak(3600,900)_j is thus the maximum 15 minute period calculated over
   1 hour.


   Assume a polling over 24 hour period giving 1440 logged entries.

       =========================

       Without any aggregation we have

           poll(60)_1
           ......
           poll(60)_1440

       ========================

       15 minute aggregation will give 96 entries of total values

           poll(900)_1
           ....
           poll(900)_96


                         j=(n+14)
           poll(900)_k = SUM  poll(60)_j  n=1,16,31,...1426
                         j=n              k=1,2,....,96


          There will also be 96 one-minute peak values.



Lambert                      Informational                     [Page 22]

RFC 1857                 Operational Statistics             October 1995


                           j=(n+14)
          peak(900,60)_k = MAX poll(60)_j  n=1,16,31,....,1426
                           j=n                k=1,2,....,96


       =======================

   The next aggregation step is from 15 minutes to 1 hour.  This gives
   24 totals.

                              j=(n+3)
          poll(3600)_k = SUM  poll(900)_j  n=1,5,9,.....,93
                              j=n          k=1,2,....,24

   and 24 one-minute peaks calculated over each hour.

                             j=(n+3)
          peak (3600,60)_k = MAX  peak(900,60)_j  n=1,5,9,.....,93
                             j=n                  k=1,2,....24

   and finally 24 15-minute peaks calculated over each hour:

                            j=(n+3)
          peak (3600,900) = MAX poll(900)_j  n=1,5,9,.....,93
                            j=n

       ===================

   The next aggregation step is from 1 hour to 24 hours.  For each day
   with 1440 entries as above this will give

                           j=(n+23)
           poll(86400)_k = SUM  poll(3600)_j  n=1,25,51,.......
                           j=n                k=1,2............

                                j=(n+23)
           peak(86400,60)_k   = MAX peak(3600,60)_j  n=1,25,51,....
                                j=n                  k=1,2.........

   which gives the busiest 1 minute period over 24 hours.

                                j=(n+23)
           peak(86400,900)_k  = MAX peak(3600,900)_j  n=1,25,51,....
                                j=n                   k=1,2,........

   which gives the busiest 15 minute period over 24 hours.

                                j=(n+23)



Lambert                      Informational                     [Page 23]

RFC 1857                 Operational Statistics             October 1995


           peak(86400,3600)_k = MAX poll(3600)_j  n=1,25,51,....
                                j=n               k=1,2,........

   which gives the busiest 1 hour period over 24 hours.

       ===================

   There will probably be a difference between the three peak values in
   the final 24 hour aggregation. A smaller peak period will give higher
   values than a longer one, i.e., if adjusted to be numerically
   comparable.

       poll(86400)/3600 < peak(86400,3600) < peak(86400,900)*4
              < peak(86400,60)*60

APPENDIX B

   An example


   Assuming below data storage:

   BEGIN_DEVICE:
      ...
   {
      UNI-1,total: [ifInOctet,  60, 60,ifOutOctet,      60, 60];
      BRD-1,total: [ifInNUcastPkts,300,300,ifOutNUcastPkts,300,300]
   }
      ...

   which gives

   BEGIN_DATA:
      19920730000000,UNI-1,60:(val1-1,val2-1);
      19920730000060,UNI-1,60:(val1-2,val2-2);
      19920730000120,UNI-1,60:(val1-3,val2-3);
      19920730000180,UNI-1,60:(val1-4,val2-4);
      19920730000240,UNI-1,60:(val1-5,val2-5);
      19920730000300,UNI-1,60:(val1-6,val2-6);
      19920730000300,BRD-1,300:(val1-7,val2-7);
      19920730000360,UNI-1,60:(val1-8,val2-8);
      ...


   Aggregation to 15 minutes gives

   BEGIN_DEVICE:
       ...



Lambert                      Informational                     [Page 24]

RFC 1857                 Operational Statistics             October 1995


   {
       UNI-1,total:     [ifInOctet,      60,900,ifOutOctet,      60,900];
       BRD-1,total:     [ifInNUcastPkts,300,900,ifOutNUcastPkts,300,900];
       UNI-2,peak:      [ifInOctet,      60,900,ifOutOctet,      60,900];
       BRD-2,peak:      [ifInNUcastPkts,300,900,ifOutNUcastPkts,300,900]
   }
       ...

   where UNI-1 is the 15 minute total
         BRD-1 is the 15 minute total
         UNI-2 is the 1 minute peak     over 15 minute (peak = peak(1))
         BRD-2 is the 5 minute peak     over 15 minute (peak = peak(1))

   which gives

   BEGIN_DATA:
      19920730000900,UNI-1,900:(tot-val1,tot-val2);
      19920730000900,BRD-1,900:(tot-val1,tot-val2);
      19920730000900,UNI-2,900:(peak(1)-val1,peak(1)-val2);
      19920730000900,BRD-2,900:(peak(1)-val1,peak(1)-val2);
      19920730001800,UNI-1,900:(tot-val1,tot-val2);
      19920730001800,BRD-1,900:(tot-val1,tot-val2);
      19920730001800,UNI-2,900:(peak(1)-val1,peak(1)-val2);
      19920730001800,BRD-2,900:(peak(1)-val1,peak(1)-val2);
      ...


   Next aggregation step to 1 hour generates:

   BEGIN_DEVICE:
       ...
   {
      UNI-1,total: [ifInOctet,  60,3600,ifOutOctet,      60,3600];
      BRD-1,total: [ifInNUcastPkts,300,3600,ifOutNUcastPkts,300,3600];
      UNI-2,peak:  [ifInOctet,  60,3600,ifOutOctet,      60,3600];
      BRD-2,peak:  [ifInNUcastPkts,300, 900,ifOutNUcastPkts,300, 900];
      UNI-3,peak:  [ifInOctet,     900,3600,ifOutOctet, 900,3600];
      BRD-3,peak:  [ifInNUcastPkts,900,3600,ifOutNUcastPkts,900,3600]
   }

   where
   UNI-1 is the one hour total
   BRD-1 is the one hour total
   UNI-2 is the  1 minute peak over 1 hour (peak of peak = peak(2))
   BRD-2 is the  5 minute peak over 1 hour (peak of peak = peak(2))
   UNI-3 is the 15 minute peak over 1 hour (peak = peak(1))
   BRD-3 is the 15 minute peak over 1 hour (peak = peak(1))




Lambert                      Informational                     [Page 25]

RFC 1857                 Operational Statistics             October 1995


   which gives

   BEGIN_DATA:
      19920730003600,UNI-1,3600:(tot-val1,tot-val2);
      19920730003600,BRD-1,3600:(tot-val1,tot-val2);
      19920730003600,UNI-2,3600:(peak(2)-val1,peak(2)-val2);
      19920730003600,BRD-2,3600:(peak(2)-val1,peak(2)-val2);
      19920730003600,UNI-3,3600:(peak(1)-val1,peak(1)-val2);
      19920730003600,BRD-3,3600:(peak(1)-val1,peak(1)-val2);
      19920730007200,UNI-1,3600:(tot-val1,tot-val2);
      19920730007200,BRD-1,3600:(tot-val1,tot-val2);
      19920730007200,UNI-2,3600:(peak(2)-val1,peak(2)-val2);
      19920730007200,BRD-2,3600:(peak(2)-val1,peak(2)-val2);
      19920730007200,UNI-3,3600:(peak(1)-val1,peak(1)-val2);
      19920730007200,BRD-3,3600:(peak(1)-val1,peak(1)-val2);
      ...


   Finally aggregation step to 1 day generates:

   BEGIN_DEVICE:
      ...
   {
   UNI-1,total: [ifInOctet,      60,86400,ifOutOctet, 60,86400];
   BRD-1,total: [ifInNUcastPkts, 300,86400,ifOutNUcastPkts, 300,86400];
   UNI-2,peak:  [ifInOctet,      60,86400,ifOutOctet, 60,86400];
   BRD-2,peak:  [ifInNUcastPkts, 300,  900,ifOutNUcastPkts, 300, 900];
   UNI-3,peak:  [ifInOctet,      900,86400,ifOutOctet,  900,86400];
   BRD-3,peak:  [ifInNUcastPkts, 900,86400,ifOutNUcastPkts, 900,86400];
   UNI-4,peak:  [ifInOctet,      3600,86400,ifOutOctet, 3600,86400];
   BRD-4,peak:  [ifInNUcastPkts,3600,86400,ifOutNUcastPkts,3600,86400]
   }
      ...

   where
   UNI-1 is the 24 hour total
   BRD-1 is the 24 hour total
   UNI-2 is the  1 minute peak over 24 hour
       (peak of peak of peak = peak(3))
   UNI-3 is the 15 minute peak over 24 hour (peak of peak = peak(2))
   UNI-4 is the  1 hour peak over 24 hour (peak = peak(1))
   BRD-2 is the  5 minute peak over 24 hour
       (peak of peak of peak = peak(3))
   BRD-3 is the 15 minute peak over 24 hour (peak of peak = peak(2))
   BRD-4 is the  1 hour peak over 24 hour (peak = peak(1))

   which gives




Lambert                      Informational                     [Page 26]

RFC 1857                 Operational Statistics             October 1995


   BEGIN_DATA:
      19920730086400,UNI-1,86400:(tot-val1,tot-val2);
      19920730086400,BRD-1,86400:(tot-val1,tot-val2);
      19920730086400,UNI-2,86400:(peak(3)-val1,peak(3)-val2);
      19920730086400,BRD-2,86400:(peak(3)-val1,peak(3)-val2);
      19920730086400,UNI-3,86400:(peak(2)-val1,peak(2)-val2);
      19920730086400,BRD-3,86400:(peak(2)-val1,peak(2)-val2);
      19920730086400,UNI-4,86400:(peak(1)-val1,peak(1)-val2);
      19920730086400,BRD-4,86400:(peak(1)-val1,peak(1)-val2);
      19920730172800,UNI-1,86400:(tot-val1,tot-val2);
      19920730172800,BRD-1,86400:(tot-val1,tot-val2);
      19920730172800,UNI-2,86400:(peak(3)-val1,peak(3)-val2);
      19920730172800,BRD-2,86400:(peak(3)-val1,peak(3)-val2);
      19920730172800,UNI-3,86400:(peak(2)-val1,peak(2)-val2);
      19920730172800,UNI-3,86400:(peak(2)-val1,peak(2)-val2);
      19920730172800,UNI-4,86400:(peak(1)-val1,peak(1)-val2);
      19920730172800,BRD-4,86400:(peak(1)-val1,peak(1)-val2);
      ...


Security Considerations

   Security issues are discussed in Section 2.4.

Author's Address

   Michael H. Lambert
   Pittsburgh Supercomputing Center
   4400 Fifth Avenue
   Pittsburgh, PA  15213
   USA

   Phone: [phone]
   Fax:  [phone]
   EMail: [e-mail]
















Lambert                      Informational                     [Page 27]