home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / acct / acct-minutes-92mar.txt < prev    next >
Text File  |  1993-02-17  |  3KB  |  89 lines
  1. This is only a rough draft - Megan 04/08/92
  2.  
  3.      Internet Accounting Working Group Meeting Minutes
  4.               17-Mar-92 to 18-Mar-92
  5.  
  6.  
  7. Internet Accounting Architecture
  8.  
  9. The Tuesday session began with a presentation by Jim Alfieri of
  10. Bellcore.  Jim spoke on Bellcore' plans for SMDS (Switched Multi-megabit
  11. Data Service) usage accounting.  He mentioned that packet counting was
  12. done upon egress from the switch (in our last session, the issue of
  13. where to count was raised and the WG agreed that the architecture should
  14. support both counting on entrance and counting on exit). 
  15.  
  16. Jim explained that the SMDS accounting service does not use the Meter
  17. -> collector -> application model, where the collector aggregates
  18. frequent meter reports into a usage file.  In the SMDS case, the meter
  19. (inside the SMDS node) itself does the aggregation of usage data to a
  20. file.  This file, in AMA TPS (Automatic Message Accounting
  21. TeleProcessing System) format, is periodically transferred directly to
  22. the billing system application via FTP.  A drawback of this architecture
  23. is that FTP service provides no security.  Further details can be found
  24. in Bellcore Technical Advisory TA-TSV-001062, "Generic Requirements for
  25. SMDS Customer Network Management Service".
  26.  
  27. The rest of the session focussed on the most recent version of the
  28. Internet Accounting Architecture document.  Working group participants
  29. offered comments, criticisms and suggestions that will be incorporated
  30. into the next draft.  In particular the following modifications will be
  31. made.
  32.  
  33.     o Explain that it is the collector's responsibility to manage
  34.       time and determine/interpret the meaning of meter ticks.
  35.  
  36.     o Discuss space reclamation strategies for dealing with memory
  37.       exhaustion in the meter.
  38.  
  39.     o Discuss the problem of trap storms that may occur when the
  40.       meter is trying to avoid losing data due to memory exhaustion.
  41.  
  42.     o Discuss the possibility of trapping to other/multiple managers.
  43.  
  44.     o Discuss the (in)applicability of the RMON MIB.
  45.  
  46. We believe that when the WG input has been incorporated in the document
  47. and it has been reviewed by the mailing list it will be ready to become
  48. an Internet Draft.
  49.  
  50. Internet Accounting MIB
  51.  
  52. On Wednesday the WG discussed the first real draft of the IA MIB.  
  53. Many detailed (but important) changes were suggested and will be
  54. incorporated into the next version of the architecture document.  Among
  55. them:
  56.  
  57.     o Put a general explanatory section up front.
  58.  
  59.     o Add/improve the descriptions of special values for
  60.       parameters.  As a special case, zero values should be used in
  61.       certain cases (e.g. high water mark or flood mark) to disable
  62.       a feature.
  63.  
  64.     o We need to add text explaining flows.
  65.  
  66.     o The MIB's "address type" should be expanded to include (a)
  67.       layer number and (b) type (e.g. if layer = 2, allow all
  68.       interface designations from the standard MIB).
  69.  
  70.     o Use standard SNMP timeticks (1/100 second).
  71.  
  72.     o Explain what max lifetime is good for.
  73.  
  74.     o Recommend UDP checksums.
  75.  
  76.  
  77. The WG will conduct a discussion of these changes and review this
  78. document over the Internet in the next couple of months with a view of
  79. advancing it to the status of Internet Draft by the next IETF
  80. conference.
  81.  
  82. General
  83.  
  84. The WG discussed what should be done when the architecture and MIB
  85. documents are completed.  It was generally felt that implementation of a
  86. prototype accounting system was next.  This could be done either through
  87. a revision/extension of the WG's charter, or by forming a new,
  88. successor WG.
  89.