Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rmonmib / rmonmib-minutes-95may.txt < prev next >

Wrap

Text File | 1995-10-18 | 26.1 KB | 698 lines

INTERIM_MEETING_REPORT_ Reported by Robin Iddon/AXON Networks and Jeanne Haney/Bay Networks Minutes of the Remote LAN Monitoring Working Group (RMONMIB) An interim meeting of the RMONMIB Working Group was held in Santa Clara, CA on 15-17 May. The meeting was sponsored by cisco Systems. Agenda o Protocol directory o Protocol distribution o Address mapping o Network layer host/matrix o Seven-layer host/matrix o Relative offset filtering o Time filter o Probe capabilities o Generic control table issues - dropped packet counter - lastActivationTime - lastDeleteTime elimination - tableSizeRequested/Granted o Seven-layer topN/history o RMON1 additions o User history o Probe config MIB o Dynamic protocol discovery o Channel as dataSource The following notes are intended to provide a overview of the issues discussed at the meeting. Refer to the upcoming draft for detailed changes. Protocol Directory Issues involving the protocol identifier format were discussed. Concerns over OID tree data explosion led to a new ID format using an OID to represent the protocol layering and an octet string to represent the attributes or parameters associated with each protocol layer. OID tree data explosion issues: (1) Reference document explodes. (2) protocolDirectoryTable grows by same factor. (3) Agent code grows potentially. (4a) The number of stats/host/matrix rows may grow also. (4b) The number of filter entries grows also. Agreed to add some kind of protocolDirType to indicate whether or not this node could be (user) extended. Adopted proposal: protocolDirEntry protocolDirID -- OID { ip.udp.tftp } protocolDirOptions -- OCTET STRING, 8-bit per sub ID INDEX { protocolDirID, protocolDirOptions } There must be exactly one 8-bit option per sub ID in protocolDirID. The intent is that all protocol defs have exactly one option -- those that need none use zero; those that need one or more must define how to combine their values into a single 8-bit. For WANs in particular, there is real concern that there is no way to handle the multitude of link layer encapsulations. Previously we hoped to allow vendors to insert their own subtrees; we can still do the same thing provided we identify the places where it will occur in advance and provide for vendor-extension bit. Agreed to remove protocolDirParentID pending further discussion. Agreed to add an ``unknown network layer protocol enumeration'' which handles all cases where absolutely nothing could be determined about a packet (except, its mac addresses and length.) Protocol Distribution A proposal came up to add size distribution to this table. Discussion over the granularity of the buckets led to a proposal to use three buckets: < media-min, >= media-min, and > media-max. Agreement could not be reached and size distribution was dropped from consideration. Proposal to use protocolDirIndex (aka local integer) in the protocolDistTable INDEX { protocolDistControlIndex, protocolDirIndex }. Agreed that if there was no other use for the protocolDirIndex then this table will revert to its original use of protocolDirID. Discussion of fragmentation and whether we are interested in monitoring higher layer fragmentation (i.e., whether we want to try and provide counters which instrument fragmentation at all layers) -- generally the group appears not to be interested in directly counting fragmentation at any layer. Address Mapping Much discussion was made of whether to include the addressMapIfIndex in the INDEX (and hence to differentiate rows on different interfaces that are otherwise the same). There was discussion on how much effort it is for the NMS to utilize this table. Possible problems include: o How the NMS maps RMON1 host addresses through this table without totally uploading the table? o Whether the NMS uses the random access capability. o Should ifIndex be replaced by an OID to allow it to point to a repeater port? Data source still tells you which network the data came from. Include controlIndex instead of ifIndex as (a) ifIndex is being replaced and (b) do not want to keep port histories (which would happen if a device moved from one port to another and the OID was part of the INDEX). Agreed to INDEX { protocol, address, controlIndex } Agreed to incorporate portOID into addressMapEntry -- intent to point at point of origin of this device (best guess of agent). After much discussion about NMS control of agent resource utilization it was agreed that the protocolDirectory should contain a set of flags to control usage of this protocol. At a minimum this should control whether or not a protocol is used in maintaining the address mapping (hence it appears in this section of the agenda). Ideally we would also have a few more flags to enable usage in the protocolDistribution and the host/matrix tables. Network Layer Host/Matrix Discussion of using an enumerated value vs. protocol dir index led to further discussion of protocol directory `counting' issues and the need to control which protocols are counted in which tables: o One idea is to turn on/off a protocol via the protocol dir table. This means you collect the same protocols for all interfaces and all application tables. This seems very restrictive. o The second idea is to define the protocol channel which defines a set of protocols that a control entry points to, to determine which protocols it is collecting. The control tables would still have a separated data source value (i.e. not tie with protocol channel, so protocol channel can be shared across several control tables). This serves two purposes. It allows the NMS to give the agent help in conserving its resources. It also makes the tables smaller to retrieve so it helps the NMS. o The final choice was to turn the protocol on/off on a per application (Net Map, Matrix, Host, etc.). You cannot control it on a per interface basis. You cannot control it on a per control table basis. This is the one that most people voted for. The counters within the nlHostTable were discussed: o nlHostOutErrors discussion -- agreed object removed. o nlHostOutMACNUCastPkts agreed to replace nlHostOutBroadcastPkts, nlHostOutMulticastPkts. o nlHostOutFragmentPkts agreed not to implement this class of counter. nlHostEntry creation was discussed. Certainly do not insert on MAC error packets; do insert on new source address. There was some discussion on whether or not to insert on destination address. It was finally agreed to insert on good source and destination addresses but that the agent may need to use an improved aging technique to eliminate the host destination addresses generated by programs which ping sequential addresses in an attempt to discover which hosts exist. Agreed to drop hlMatrix[SDjDS]Errors. Agreed to keep both DS and SD tables (despite their being good reasons not to). It was deemed (a) too complex to dismiss the NMS's inability to easily know of some classes of uni-directional conversations and (b) the overheads on the agent are not severe enough to make the pain of pushing this through worth doing). Agreed to not do subnet aggregation because there was no standardizable proposal and no one volunteered to do one. Seven-Layer Host/Matrix Three models were discussed based on nl/sl host tables: 1. Merge them 2. Keep them separate but closely related so that the agent can be efficient 3. Keep them totally independent Long discussion over the product class<->mib group mapping followed. Eventually the group came to a vote on: 1. Single control table causing a nlHostTable and slHostTable to be constructed (related solution 1' recognizes that within the single control table entry will be parameters specific to the nl and sl tables, e.g., rm2HostControlNlMaxDesired and rm2HostControlSlMaxDesired). 2. Merge both tables (voted out 1 for merge, 16 against). 3. Split control tables but slHostControlTable depends on an instance of nlHostControlTable. Notice that this is also the same functions as 1'. 4. No sharing of data, hence duplicate memory requirements! (Deleted.) Proposal 1' was accepted over 3. Steve will add a straw proposal for the combined sl/nlHostControlTable in the next draft. slHostEntry will contain only inPkts/outPkts and inOctets/outOctets. slHostEntry will not contain slHostAddress, instead INDEX will reference nlHostAddress, and words will be added to ensure that for each slHostEntry there must be an nlHostEntry with the same address and hence deleting an nlHostEntry will cause deletion of the associated slHostEntries. Misconfiguring the protocolDirectory such that slHost function is enabled for a protocol but nlHost function is not enabled for its network layer protocol causes no data to be collected in either table for this protocol (because there are no nlHostEntries to relate slHostEntries to). Proposal adopted: INDEX { controlIndex, protDirIndex(addrType), nlHostAddress, protDirIndex(protocolType) } and that the slHostTable contain neither an address nor a MACNUCastPkts counter. A proposal was adopted to include a bit/enum in the protocolDirectory to indicate whether or not a network layer address is available for this protocolDirectoryEntry (it would not make sense to set this bit for ip.udp, for instance, but it could be set for both the ip entry and the ip.udp.appleTalk entry; an agent would set the bit if it supports the protocol as a network layer protocol and not if it supports it only as an application protocol). Ideally we would incorporate this into the nodeType object. This is not something to be placed in the parameters object because it can only relate to the final protocol of the OID, not all of them). Proposal for slMatrix is: INDEX { controlIndex, protDirIndex(addrType), sa, da, protDir(protType) } Agreed to let Steve apply results of the nl/sl host table discussions to the matrix and so avoid long discussions over basically the same subject. Agreed to move forward to the topN/history on host/matrix tables out of order because we want to discuss it in the context of the host/matrix tables. Discussion of data table columns: o Issue of error counters. What does it include? Why count L2 errors by protocol. Errors can propagate up to this table. It is too hard to make it meaningful to count network layer errors. Therefore we will leave it out. o Bcast and mcast? Could there be permutation of bcast/mcast at the L2 level and bcast/mcast at the L3 level. Is a broadcast to MAC addresses with a multicast IP address counted as bcast or mcast. Robin believes that the impact on the net is the fact that it is bcast, i.e., everyone received and processed it. We decided that we are merging the bcast and mcast counts into one counter. We are still counting L2 counters with an NLHostOutNUcastPkts (not unicast). Get rid of Broadcast, Multicast, and Errors. o Robin proposes an OutFragment counter that only bumps up when fragments are detected from a particular SA. Most people abstained, so it is a closed issue. Fragments are not counted. o We discussed not adding entries to the Host Table based on DA, so that the table does not get filled up with erroneous addresses from MIB sweeps, etc. On the other hand there are L3 broadcast addresses in video multicast addresses that will never appear in the source. Maybe we can use a different aging algorithm so entries without out pkts, get deleted sooner. But then would you be deleting these interesting mcast and bcast pkt as frequently as these bogus sweep addresses. o Good packets for this table is defined as good MAC packets. o Drop the Matrix error counters, do not add the bcast counter, they can get them from the host table. Remove nlMatrixSDAddressType. Discussion of encapsulated network layers (e.g., IP in IP): o The problem of NL layer protocols being wrapped on other NL protocols, causes some problem in the how to count the pkt and what the NL address is. How do you record both NL address. Do you consider the encapsulated protocol to be application? There is no place to save the encapsulated NL address. o Steve proposes an address structure that encode what the protocol is so that we can model both NL protocols and NL protocols encapsulated in other NL protocols. Should we try to solve this problem? (Vote: 8-2-5.) Now the NL tables could have entries that count a pkt twice, since the NL table accounts for all NL protocols, not just the NL usage at this particular probe in the network. Not all probes need to implement this, but all NMSs need to be aware of this anomaly. I.e., if you take all the entries for a particular NL Host, they could total up to more than 100% of the Net utilization for that Host. How does this affect the protocol distribution table. There would be a protocol directory entry for AppleTalk with IP and it would be counted in the prot distribution. o The upshot of the vote to handle protocols that may be encapsulated within other protocols, how you might represent the addressing. Can we change the network address mapping table to record this information that we have learned from encapsulated NL protocols. Add pDir Index as last index to the slHostTable (and slMatrix) NL -- address object nonUnicasts, SL -- pDirIndex on end Add a bit/boolean to pDirTable that defines whether addresses are recognized for that protocol. Relative Offset Filtering There was a lot of discussion of various filtering related topics. In the end it was agreed to treat the channels as data source issue elsewhere. Agreed to pursue filterLogicTable and mod to filterChannelIndex 0..65535. Robin to write up proposal (15 for, 0 against, 2 abstain). Time Filter After an example and some discussion it was agreed to implement time filter as proposed (15 for, 0 against, 1 abstain). It was also agreed that the timeMark goes in between the control index and the rest of the index. Probe Capabilities We discussed probe classes and the nl/sl split. We finally closed with nl/sl remain different tables (7 for, 3 against, 3 abstain). Next we voted on whether or not any kind of capabilities object was needed; in favour (11 for, 1 against, 2 abstain). Next we discussed per-interface vs. per-device capabilities. First vote on scalar only (per-device) (7 for, 2 against, 4 abstain). Scalar adopted. Generic Control Table Issues A) Dropped Packet Counter There was a lot of discussion about how the counters work and what they are (and are not) intended to do. In the end it was agreed that these counters are not intended to enable the agent to do statistical sampling/scaling. Indeed the notion of scaled data in the RMON2 tables is explicitly precluded (the group cannot define a scaling algorithm that is universally appropriate). Finally there was debate over whether statistical sampling and scaling were really the only solution to the 10x media speed increases, and while there was no agreement the discussion polarized between those that felt that the current agent technology would enable 100MBit and those that did not. It was agreed that there would be one droppedFrame counter per control entry by default but that for some groups/functions we may decide to use a scalar should that prove more appropriate. It was agreed that the [etherjtokenRingP]StatsDropEvents would continue to exist in RMON2 agents and that its semantics would be unchanged. The following rules define how the fooDropFrame counter (from the fooControlEntry) relates to the [etherjtokenRingP]StatsDropEvents counter and [etherjtokenRingP]StatsPkts counter for the same interface: 1. For each time the agent recognizes that one or more packets have been missed without it knowing exactly how many were missed it must increment the dropEvents counter for that interface. This is the only time that the dropEvents counter is incremented. 2. Whenever the agent chooses not to update a table/data collection function based on the contents of a packet which it knows was present on the network it must increment the droppedFrames counter for that table/function. 3. For all packets which are not lost in (1) above or dropped in (2) above the agent must update tables/data collection functions accurately. Two results of applying these rules are: 1. The sum of all packet counters in a table or data collection function (e.g., the hostOutPkt counter) plus the associated droppedFrame counter should be exactly equal to the sum of the [etherjtokenRingP]StatsPkts and [etherjtokenRingP]DroppedFrames counters for the same data source. Of course this assumes that the there are enough resources in the agent such that the table is not being LRU'd. 2. For all agents where the dropEvent counter is zero the sum of the droppedFrame and Pkt counters in a given table or function on the same interface should be exactly equal to the number of packets that there were on the network. It was agreed that there should be strong recommendations for RMON2 agents to utilize the droppedFrame counters as a means of accurately reporting the number of frames missed and that if at all possible the dropEvents counters should never be incremented -- in this way an NMS can use the data with much higher confidence. B) lastActivationTime Proposal to have this object set to sysUpTime at the point in time this control row's status transitioned from not active to active. This lets the NMS notice that another NMS restarted data collection (without picking a new control index) and so deltas will be invalid. It also gives an indication of the age of the table (but may not be used to rate the first ever poll -- the data counters still do not have to start from zero and so you do not know the delta over the interval). Agreed to adopt proposal (13 for, 3 abstain, 0 against). Notice that we will decide later which tables and functions to apply this to. C) lastDeleteTime Elimination Discussion -- it was agreed that lastDeleteTime was easy to implement, but it is also agreed that it was designed specifically for creationOrder which no longer exists. Proposal is to replace tableSize and lastDeleteTime with insertCount and deleteCount (where insertCount - deleteCount == tableSize). Agreed unanimously to adopt. D) tableSizeRequested/Granted Proposal to implement a maxDesired (i.e., a ceiling) per controlEntry. 0 implies consume as much memory as is required/available. > 0 instructs the agent to create at most this many data table entries associated with this control entry -- once this ceiling is reached the agent should delete old resources (associated with this control entry) in order to create new rows. Agreed to adopt proposal (16 for, 0 against, 1 abstain). Notice that we later had a discussion which suggested a valid use of zero would be for the new hostTable where the control entry creates both nlHostTable and slHostTable; a user who did not want an slHostTable on an interface might use 0 to indicate that. Perhaps we should use -1 to imply unlimited rather than zero. Seven-Layer topN/history Agreed to do any kind of topN in addition to the RMON1 stuff (8 for, 0 against, 7 abstain). Agreed to do slMatrixTopN (7 for, 0 against, 0 abstain) Marginally agreed to do nlMatrixTopN (5 for, 1 against, 5 abstain) Agreed to not do slHostTopN and nlHostTopN (1 for, 5 against, 7 abstain and 0 for, 4 against, 7 abstain respectively). Agreed not to support TopN by protocol (1 for, 10 against, 4 abstain). A real proposal bringing together all the best ideas of how to do TopN on the nl/sl matrix tables is needed -- Steve, Matt and Shay to get together on producing this proposal. RMON1 Additions 1. netUtilization Etherstats gives you the number of octets seen. Robin proposes that we provide a count of the number of bits and include interpkt gap and the preamble. This gives you a better approximation of utilization. Bytes seems like a better unit to use, then the counter will not wrap as readily. It still is the same way another analyzer would calculate utilization. We still run the risk that RMON gets compared with these analyzers and is not identical. So the question is, is the esterStatsOctets value a good enough approximation to get utilization or do we want to provide a new object that counts more of the overhead. People seem to favor just sticking with the original counter and obtaining an approximation to utilization for thresholding via Alarms. The group voted to use the octets approximation and not add any new bandwidth utilization indicators. 2. filterDescr Proposal withdrawn without opposition. 3. [filter changes] Robin to make proposal on the list based on what was discussed at the meeting (i.e. the filterLogicTable with m:1 relation reversed). 4. Control table additions The group considered four additions and how they applied to each control table: (a) insert, delete counters (b) maxDesired (c) activationTime (d) droppedFrames EtherStatsTable+TokenRingPStats+TokenRingMLStats activationTime, droppedFrames HistoryControlTable Nothing EtherHistoryTable+TokenRingPHistoryTable+TokenRingMLHistoryTable droppedFrames AlarmTable Nothing HostControlTable maxDesired, activationTime and droppedFrames (maxDesired needs note in implementors guide, apparently) HostTable/HostTimeTable Nothing HostTopNControlTable Nothing HostTopNTable Nothing MatrixControlTable Same as hostControlTable MatrixSD/DSTable Nothing FilterTable/ChannelTable/BufferTable Nothing EventControlEntry + LogTable Nothing RingStationControlTable activationTime, droppedFrames SourceRoutingStatsControlTable activationTime, droppedFrames 5. Storage type Steve to propose an object which is per-control row and indicates what NVRAM processing an agent has performed on that row (ROM, will-write, wont-write, written). (7 for, 0 against, 4 abstain). 6. Alarms enhancements Make it robust when monitored OID disappears. It was agreed that Steve would produce a draft based on an alarmValueStatus object which defines whether the agent managed to get the value last interval, an alarmValueUnavailable event/trap, an alarmUnavailableEventPollThreshold (i.e. the number of unavailable intervals before generating the event). 7. WAN status bits It was agreed that bit6 will be supported in the pktStatus bitmask as the packet direction bit. Further study of bit7 (other physical errors) will be done, but this bit needs to be more clearly defined before it can be adopted. User History Get rid of objectsGranted. BucketsRequested cannot be changed after row goes valid. Otherwise it stands as is. Probe Config MIB In this section OK means that we accepted to do it -- there were no votes as such, just a call for objections. o probeID, probeFirmwareRev, probeHardwareRev OK. Discussion on converting probeDateAndTime from ASCII into v2 DateAndTime TC (except we will do our own TC which is length 0 or 8 or 11 to allow optionality) OK. o probeResetControl OK. o probeDownloadFile, etc. (5 for, 0 against, 7 abstain) OK. o serialConfigTable: Agreed to keep serialIP and serialSubnet. o The agent might need to implement the two tables that contain line speed and flow control objects, but we will try to get away without doing it; should it be rejected elsewhere we will have to adopt usage of the appropriate serial MIBs instead (charPortTable and portTable). o Modify serialConfigProtocol slip(1), ppp(2), other(3). o Take all modem string DEFVALs and make them comments instead. o Rename serialTrapTimeout to serialDialoutTimeout OK. o netConfigIpAddress/netConfigSubnetMask OK. Remove netConfigIfSpeed and netConfigIfRingNumber. o trapDestIndex, trapDestCommunity, trapDestIpAddress, trapDestOwner, trapDestStatus OK (8 for, 0 against, 2 abstain). o serialConnect: index, dest ip, connection type (direct, modem, switch, switch-and-modem), dial/connect strings, owner, status. OK. Dynamic Protocol Discovery Populate the prot directory that is sensible at startup. Then the agent could add some protocols that it discovers existing on the net. The assumption is that the agent was capable to decode those protocols all along, but there is such large set of them and they may never appear on the net. It is OK that these added protocols grow more than a single level, as originally thought. It is up to the probe whether to turn it on or not for collection. How do we document these in the protocol document and provide options for these fields? Further discussion on the mailing list is needed. Channel as dataSource There was a vote on how many people violently object to using channel as data source (2). Those that wanted the standard to be changed to mandate that an agent must allow channel as data source (3). Those that want to leave the standard as is (and accept that there will continue to be proprietary extensions) and that the behaviour of any other kind of data source value is undefined (11). We voted to modify the text that states ifIndex is the only recognized dataSource that all should support, but that other values are not illegal -- just considered out of scope.