home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rmonmib / rmonmib-minutes-94dec.txt < prev    next >
Text File  |  1995-02-28  |  14KB  |  420 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Russell Dietz/Technically Elite Concepts
  5.  
  6. Minutes of the Remote LAN Monitoring Working Group (RMONMIB)
  7.  
  8.  
  9. TUESDAY, 6 DECEMBER 1994 - FIRST SESSION
  10.  
  11. Agenda (for both meetings):
  12.  
  13.  
  14.    o Summary of interim meeting progress
  15.    o Bashing of interim meeting progress
  16.    o Network-layer host/matrix tables
  17.    o New presentation
  18.      Packet filtering
  19.      Packet generation
  20.  
  21.  
  22. The chair presented a summary of results from the interim meeting that
  23. was held in Santa Clara on 21 November and 22 November 1994.  The
  24. results took the form of the following listed items.
  25.  
  26.  
  27.    o Items to be included for RMON-II
  28.       -  Statistical sampling
  29.       -  Network layer host/matrix
  30.       -  Connectivity tests
  31.       -  User-defined history collection
  32.       -  Rule-based packet filtering
  33.       -  Probe configuration
  34.  
  35.    o Items still to be considered for RMON-II
  36.       -  Duplicate address detection (50%)
  37.       -  Address change detection (50%)
  38.  
  39.    o Items excluded for consideration from RMON-II
  40.       -  Connection monitoring
  41.       -  Transaction response timing
  42.       -  Per-host protocol distribution
  43.       -  Raw packet generation
  44.       -  Long term capacity planning
  45.       -  Packet grep
  46.       -  Channel logic
  47.       -  Accounting group Meter MIB
  48.  
  49.  
  50. The following features were included instead of dropped (and one feature
  51. missed):
  52.  
  53.  
  54.   1. Per host protocol distribution
  55.   2. RMON agent configuration
  56.   3. Port to physical address mapping
  57.   4. Consideration for hardware implementation on high-speed networks
  58.  
  59.  
  60. The floor was then opened for general ``bashing'' of the interim meeting
  61. lists.
  62.  
  63.  
  64.  
  65. Probe Configuration
  66.  
  67. There was some discussion on the need for the RMONMIB Working Group to
  68. address the issue of Probe/Agent Configuration.  The general consensus
  69. was that there may be a need for this, however the working group must
  70. make sure that the configuration sections of the RMON MIB do not
  71. duplicate the efforts of other working groups in the Network Management
  72. Area.
  73.  
  74. The working group will continue discussion of this problem.  The
  75. proposed solution is to create an optional group from objects in the
  76. Hewlett-Packard/AXON Aspen MIB. Hewlett-Packard, AXON and Technically
  77. Elite have implemented the Aspen MIB for agent configuration.
  78.  
  79.  
  80.  
  81. Per-interface Protocol Distribution
  82.  
  83. The group decided to add Protocol Distribution tables in both the
  84. dataSource and host/matrix table style.  Many agreed that while the
  85. number of rows in these tables could grow very fast, that this would be
  86. no different than the current resource usage of the host and matrix
  87. tables on a large feed or backbone in any network connected to the
  88. Internet.
  89.  
  90. The consensus was that RMON-II should consider both per dataSource
  91. Protocol Tables and host/matrix protocol tables.  The working group will
  92. need to make sure that these protocol tables are interoperable.
  93.  
  94. It was also agreed that the ``soft'' counters outlined in the AXON ECAM
  95. MIB should be removed because of the inability to develop a MIB that
  96. would be able to interoperate and provide the data in the counters.  The
  97. ECAM MIB was presented in detail in the second meeting.
  98.  
  99.  
  100.  
  101. Port Mapping
  102.  
  103. A proposal from Lannet for mapping physical connections (ports) to
  104. physical addresses (MAC). A presentation and further discussion was
  105. deferred to the second meeting.
  106.  
  107.  
  108.  
  109. RMON-II Compatibility With RFC 1271
  110.  
  111. During the interim meeting, the general consensus was that the new
  112. RMON-II MIB will not break the existing tables, and that the working
  113. group will not depreciate any existing tables.
  114.  
  115. The consensus in the working group meeting also wanted to prevent the
  116. ``breakage'' of existing RMON client applications.  However, the working
  117. group decided to agree that ``every effort will be made not to break the
  118. existing MIB.'' This was due to some concern over hardware
  119. implementation considerations.  It was agreed that no changes are locked
  120. out at this time, but specific proposals need to be made before this
  121. issue can be addressed.
  122.  
  123. The working group also agreed that existing tables will continue to use
  124. EntryStatus, and new tables will use the RowStatus TC. This will keep
  125. existing applications working, while assisting in the migration to SNMP
  126. V2 SMI incorporation.
  127.  
  128. There was then some discussion on adding a timestamp to the host and
  129. matrix tables.  This timestamp would tell the manager application that
  130. the table had ``changed state.''  It was then suggested that the same
  131. timestamp be included in every table.  The working group decided that
  132. there was enough interest to look into this further as part of RMON-II.
  133.  
  134.  
  135.  
  136. Statistical Sampling
  137.  
  138. The working group then discussed the statistical sampling item.  The
  139. general consensus, at first, was that this could should not be
  140. implemented since it is only a ``sampled'' view of the network traffic.
  141. However, Steve Britt of Hewlett-Packard, stated that the data has proven
  142. useful to the Hewlett-Packard EASE product in long term trend analysis.
  143. In addition, the working group discussed the usefulness of the
  144. technology in faster (100Mb) networks.
  145.  
  146. The working group discussed the issue of the Hewlett-Packard patent on
  147. this analysis.  Steve stated that Hewlett-Packard would be willing to
  148. release the patent on the areas which the new RMON-II MIB would cover
  149. for statistical sampling.
  150.  
  151.  
  152.  
  153. Connectivity Tests
  154.  
  155. The working group discussed the usefulness of connectivity tests.  This
  156. is similar to a ``ping'' MIB. It was presented that during the interim
  157. meeting the consensus was the these tests would be better than a simple
  158. packet generation engine.  Limited to the number of basic protocols
  159. on-line.
  160.  
  161.  
  162.  
  163. User-Defined History Collection
  164.  
  165. The chair had posted a MIB that allows manager-defined counters from
  166. within a MIB-view, in a similar fashion to the current history table.
  167. Some concerns were raised as to if RMON-II should be able to collect
  168. this data.  A consensus was reached that the current alarm table allowed
  169. for this feature on a single OID basis, therefore the working group
  170. should consider this ``collection'' of counters an extension of that
  171. functionality.
  172.  
  173.  
  174.  
  175. Duplicate Address Detection
  176.  
  177. There were concerns over the rules for adding an entry to a
  178. DuplicateAddressTable (i.e., some false triggers can occur) Mapping of
  179. physical to network address via ``Protocol'' may help detect this
  180. condition.
  181.  
  182.  
  183.  
  184. Mapping of Physical to Network Address
  185.  
  186. Several members of the working group expressed a need for mapping of the
  187. physical and network layer addresses.  The need for a separate table
  188. from the network layer host table was discussed.  No general consensus
  189. was made during the meeting, other than this feature would be provided
  190. as part of the network layer tables.
  191.  
  192.  
  193.  
  194. Channel Logic
  195.  
  196. This feature (extended logic for the filter-set) would be required if we
  197. are going to enable the both the ``old'' filter tables and the ``new''
  198. rule-based filters.  Changes to the channelTable will be considered as
  199. part of the new filtering framework.
  200.  
  201.  
  202.  
  203. Raw-Packet Generation
  204.  
  205. The working group discussed the issues behind the removal of packet
  206. generation from the consideration list for RMON-II. Several members of
  207. the working group protested the removal of this feature stating that
  208. ``this is a desired tool for troubleshooting network problems.''
  209.  
  210. The feeling at the interim meeting was that users would have serious
  211. security concerns with a device that could generate any packet to anyone
  212. on the network, if someone were to ``break into'' the RMON-II agent.
  213.  
  214.  
  215.  
  216. Hardware Statistics
  217.  
  218.  
  219. There was great concern expressed over the fact that there had was no
  220. mention of a need for changes to the current RMON framework that would
  221. enable more cost effective hardware-based RMON solutions.
  222.  
  223. It was noted that there had not been any recent proposals as to what
  224. areas of the RMON MIB, with the exception the channelAcceptType, that
  225. required changes for hardware-based RMON. It was agreed that the working
  226. group would add this item to the ``In'' list and await proposals for
  227. change requirements.
  228.  
  229.  
  230.  
  231. TUESDAY, 6 DECEMBER 1994 - SECOND SESSION
  232.  
  233.  
  234. Agenda:
  235.  
  236.  
  237.    o Straw Poll on proposed feature set
  238.    o Presentations--specific feature proposals
  239.  
  240.  
  241.  
  242. Feature Set Straw Poll
  243.  
  244.  
  245. A strawpoll regarding the RMON-II feature list was taken:  (Percentage
  246. that agreed with the status.)
  247.  
  248.  
  249.    o In
  250.       -  Statistical sampling (50%)
  251.       -  Network layer host/matrix (95%)
  252.       -  Protocol distribution host/matrix (95%)
  253.       -  Connectivity tests (50%)
  254.       -  User-defined history collection (80%)
  255.       -  Rule-based packet filtering (50%)
  256.       -  Probe configuration (50%)
  257.       -  SNMP V2 SMI (90%)
  258.       -  Hardware friendly RMON (50%)
  259.    o Possible
  260.       -  Duplicate address detection (25%)
  261.       -  Address change detection (25%)
  262.  
  263.  
  264. There was no strong objection to changing the status of any item on the
  265. `removed' or motion to do so.
  266.  
  267.  
  268. RMON-II Framework
  269.  
  270. A motion to discuss RMON-II framework was made, but was deferred to the
  271. mailing list by the chair, because of time limitations.  (several people
  272. had prepared presentations of specific features.)  The working group has
  273. to address this issue as soon as the feature set is stabilized.
  274.  
  275.  
  276. PREPARED PRESENTATIONS
  277.  
  278. Port Mapping - Dan Romascanu
  279.  
  280. Dan presented a MIB fragment that was posted to the mailing list for
  281. review.
  282.  
  283. This MIB would extend the current hostTable and provide linkage between
  284. physical port and MAC address for each host.  The proposal was optimized
  285. by using a single OID in which the object portion identified the
  286. physical port type, and the instance portion (N components) represented
  287. the specific port value.  The working group reached a consensus that
  288. this should be reviewed for inclusion in RMON-II.
  289.  
  290.  
  291. NETscout - Anil Singhal
  292.  
  293. Anil presented an application model for logical filters (higher layer)
  294. and HostDetail (added host stats).  The features included:
  295.  
  296.  
  297.    o Physical probe - RMON
  298.  
  299.    o Virtual probe - (DomainView - a domain or collection of probes)
  300.  
  301.    o Logical filters - protocol family - enumerated type - single filter
  302.      for SAP, Etype SNAP and others
  303.  
  304.    o TransportID - octet string - just after the family in the frame.
  305.      Host address.  Address direction.
  306.  
  307.    o Host Detail - DeviceType, MacAddress, AddressChangeCount,
  308.      FirstPacketTime, LastPacketTime InRemote, OutRemote
  309.  
  310.  
  311. There was no motion to add any specific MIB objects or problem
  312. statements to the RMON-II feature list.
  313.  
  314.  
  315. Hewlett-Packard Statistical Sampling - EASE - Steve Britt
  316.  
  317. Sampling provides measurement for looking at network traffic.  EASE
  318. Application feature summary:
  319.  
  320.  
  321.    o Cost, timeliness, accuracy, salability, security
  322.    o Random sample count - every so many packets
  323.    o 1,000,000 random of .25% (2500)
  324.    o 1,000 from node M
  325.    o Random samples that can handle higher speed networks
  326.  
  327.  
  328. A proposal was made to provide a flag in RMON tables to know that this
  329. is sampled.  Another idea was to use dataSource to designate a `sampled
  330. interface.'  No consensus for either.
  331.  
  332. There was no consensus reached on how statistical sampling should be
  333. implemented in RMON-II. This will be considered just one of (possibly)
  334. several ideas to reduce the cost of RMON on high-speed networks.
  335.  
  336.  
  337. ECAM - Robin Iddon
  338.  
  339. The ECAM MIB provides statistics for an arbitrary number of
  340. user-specified protocols in a consistent table format.
  341.  
  342. There are two ways a protocol can be specified by the user and data
  343. collected for that protocol:
  344.  
  345.  
  346.    o Protocol directory -- a globally enumerated (hard-wired) list of
  347.      well-known protocols identifiers is created.  A control table
  348.      configures which protocols should be collected by the probe on each
  349.      interface.  A specific identifier is used in the data table index.
  350.      Data tables such as those in the statistics, host, and matrix
  351.      groups can be created with this additional index.
  352.  
  353.    o User defined protocols -- a channel could be used as the data
  354.      source for statistics collection.  Existing RMON tables (hostTable,
  355.      matrixSD/DS) could use a channel by setting the dataSource top
  356.      channelIndex.N
  357.  
  358.  
  359. The framework for higher-layer statistics is of primary concern for the
  360. working group at this time.  There was general consensus to pursue both
  361. models.  It was agreed that only basic counters could be provided in an
  362. interoperable way--it would be too difficult to generically identify
  363. ``interesting things to count'' in each protocol.
  364.  
  365.  
  366. ARGUS 1.3 - Chas DiFatta
  367.  
  368. ARGUS provides logging of transactions for connections in a TCP network.
  369. Agent would create a table of history-based TCP connections and
  370. implement the TCP connection state machine to determine the true status
  371. of each TCP connection.  State tracking is a problem--it was suggested
  372. that the probe just report the TCP events that are observed.  There was
  373. also concern about the size of log tables on embedded probes without
  374. disk storage.
  375.  
  376. There was no consensus to add this feature to RMON at this time or
  377. specific suggestions on how to integrate this application into the RMON
  378. MIB.
  379.  
  380. For information about freely-available ARGUS software contact:
  381. argus@sei.cmu.edu.
  382.  
  383.  
  384. TCP/IP Connection Monitoring
  385.  
  386. After the Argues presentation, there was a great deal of discussion on
  387. the usefulness of this type of network monitoring in general on RMON
  388. probes.
  389.  
  390. There was no consensus reached on inclusion of this feature in RMON-II.
  391.  
  392.  
  393. Interim Meetings
  394.  
  395. (Not Discussed)
  396.  
  397. The working group needs to finalize any interim meetings at least 30
  398. days before a meeting is to be held.  A city easily accessible by
  399. air-travel (i.e., major hub) should be chosen, which is not anywhere
  400. near the last or next IETF (i.e., either US coast).
  401.  
  402. This issue needs further discussion on the mailing list.
  403.  
  404.  
  405. RMON Schedules
  406.  
  407. (Not Discussed)
  408.  
  409. The working group needs to identify some milestones not specified in the
  410. charter.  A date of 1 January 1995 has been set as the cutoff for new
  411. problems to solve.  There has not been a cutoff date set for new
  412. solution proposals.
  413.  
  414. Before solution proposals can be considered in detail, a framework for
  415. the new features must be designed.  New groups, rules for dataSource,
  416. filtering framework, `hardware friendliness,' and RMON-1 integration
  417. must be considered before we start churning out MIB objects.  A target
  418. date for framework completion has not been set.
  419.  
  420.