CURRENT_MEETING_REPORT_ Reported by Cyndi Mills/BBN ACCT Minutes The Internet Accounting Working Group met on Tuesday, Wednesday, and Thursday to: o Review the results of the February meeting in Boston. - SNMP security and performance issues. SNMP seems a reasonable approach for transporting data, given a diskless meter, although FTP or other bulk file transfer mechanisms should also be allowed for meters which store accounting data on local disks. Other transport mechanisms may be discussed later. - Background Document. The background document can be released for general comment as an Internet Draft after the addition of PICTURES and explanations which illustrate how the accounting mechanism addresses a variety of scenarios. It is anticipated that the Background Document will be expanded again later. - Architecture Document. The existing architecture document can be released for general comment after revision and the addition of control parameters. Before it is released to the Internet Drafts area it will be posted to the Working Group mailing list for review. - Meter Services and MIB. The February discussion of control parameters and reporting formats was summarized for continuation. o Discuss control parameters and reporting formats. - A modified reporting format resulted for further discussion. - A set of control functions was developed for further discussion. - The notion of being able to account differently on different interfaces and make finer distinctions resulted in the further 1 development of a rule tree similar to those discussed in February. - The ability to set the granularity of reporting in great detail through the use of a rule table was developed for further discussion. The current scheme seems too complex to be readily implemented, but serves as a starting point for further work. One solution to bounding the problem is defining a short list of standard (static) rule tables, without allowing the more general case. A rough outline of the reporting format, control functions, rule tree, and rule table culled from the meeting notes and slides follows these minutes. o Additional notes about lengthy discussions. - It was noted that the ADDRESS_ID described in the reporting format might be expanded to transport level and beyond (e.g., application level), allowing for a more generalized accounting for any protocol stack, but that is beyond the charter of this Working Group. - It was also noted that attributes might be included in the ADDRESS_ID rather than as a separate field of the FLOW_ID. - Each packet shall be counted in ONE and ONLY ONE accounting record to avoid duplicate counts. Accounting records may be combined by the collection host for additional aggregate traffic information. This is a tentative response to the question Can a single packet be counted in multiple buckets of a single meter? - Meters in routers have special properties, since they are privy to the routing decision. Meters may be modelled as (a) one meter per interface (as a passive listener to the interface, not privy to the routing decision) or (b) one meter per router, aware of the both input and output interfaces for the packet. Passive listening devices must have a network address and possibly a separate connection to the network in order to be managed. Should routers be modelled as having a single meter to avoid complicating management? Action Items Background Add pictures to Internet Background and revise. 2 If changes are not too substantial, post directly to Internet Drafts. Architecture Revise Architecture Document to reflect control requirements and reporting changes. Post to Working Group mailing list for (time-limited) review before posting to Internet Drafts. Meter Services Make a stab at reducing the granularity control (rule table) problem to a manageable level. Further specify control parameters with the goal of creating a MIB. Co-ordinate Coordinate with Remote LAN MIB and Operational Statistics Working Goups since they may be tackling similar problems of granularity control. REPORTING FORMAT (notes from discussion, not a precision representation): Accounting Record ::=[ Meter ID and Unique Address provided by SNMP ] Start Time TIMESTAMP, [ optional ? ] End Time TIMESTAMP, [ should be current time ? ] Rule_Table ID? [ something might be needed here ...] SEQUENCE OF FLOW_RECORD. [ number of records, followed by records ] FLOW_RECORD::= Flow FLOW_ID, Values VALUES. FLOW_ID::= [0] Source ADDRESS_ID [ must have source or destination ] [1] Destination ADDRESS_ID or both ] [2] Subscriber_ID ADDRESS_ID [ optional ] [ Attributes not defined yet ] VALUES::= [ rolling counters ] Fragments_Sent COUNT, Fragments_Rcvd COUNT, [ packets in the reverse direction are counted here to avoid maintaining two accounting records for a communicating pair - should'nt this be optional for source or destination only flow ids? ] Bytes_Sent COUNT, Bytes_Rcvd COUNT, [ byte count of reverse flow ] First_Time TIMESTAMP, [ time first packet in flow seen if different from meter start time ] Last_Time TIMESTAMP. [ time last packet in flow seen if different from meter stop time ] 3 ADDRESS_ID::= [ some fields may be null, i.e., don't care ] [1] INTERFACE_INDEX INTEGER, [ as defined by SNMP ] [2] LINK LEVEL ADDRESS NETWORK_ADDRESS, [3] INTERNET ADDRESS NETWORK_ADDRESS, [0] STRING OF OCTETS. [ anything else used as unique ID ]. NETWORK_ADDRESS ::= Choice of { [1] IP ADDRESS. (TCP/IP) [2] NSAP ADDRESS. (OSI) variable length. [n] X.25 Address (CCITT) [m] MAC (LLC) [x] STRING OF OCTETS. (any other arbitrary address) } COUNT::= Extensible_Integer SEQUENCE OF OCTETS. TIMESTAMP ::= [ defined by SNMP already, either absolute time or ticks/seconds/since meter boot time ] CONTROL PARAMETERS (notes under discussion): Meter to Management: (traps) DECLARE DATA LOSS Trap to let manager know that accounting data is being lost. DECLARE HIGH WATER Trap to request that manager increase polling interval. (Used when number of flows increases.) DECLARE FLOOD/FLUSH Trap dumping the flow records currently being monitored by the meter. (Lower priority first?) Management to meter: (polls and control) SET HIGH WATER MARK A the meter when to send a trap indicating that the management station should increase the polling interval. SET FLOOD MARK A how full the table SHOULD be before the meter considers panicking and dumping the contents of the meter to the management station in raw (SNMP OPAQUE) form. SET FLOW TERMINATION PARAMETERS The meter should have the good sense in situations where lack of resources may cause data loss to purge flow 4 records from its tables which (a) have already been reported and show no activity since the last report (b) oldest flows or (c) flows with the smallest number of unreported packets - TIMEOUT The time in seconds since last packet seen (and last report) after which the flow may be terminated. - MAX LIFETIME Guidelines for the maximum lifetime of a flow. (Not mandatory, but the meter should make an effort at reporting time to purge flows that have had a lifetime greater than this value, even if it results in the instantaneous creation of a new flow with identical parameters. SET FLOW PRIORITY [ REPORTING MASK] (mask is an 8-bit quantity) Tell meter which flows are considered ``critical'' - i.e., in a crisis situations which flows can least afford to lose data. Reporting mask is set by the RULES TABLE in the SET GRANULARITY operation. REPORT [ REPORTING MASK (0 or default indicates report ALL)] Poll to meter indicating that a normal report of indicated flows should be made (i.e., any flow whose rule has indicated that it has a bit set which is set in the mask. SET GRANULARITY [ RULE TABLE ] see RULE TABLE RULE TABLE: (Editorial comment from the Chair: This is all a very large pie in the sky and not to be sliced seriously yet.) SEQUENCE OF NUMBERED RULES. RULE::= Field FIELD_DESCRIPTOR. [ Operator OPERATOR_DESCRIPTOR. ] Mask. MASK_DESCRIPTOR. LIST OF ACTION_PAIRS. FIELD_DESCRIPTOR ::= Length INTEGER. (0 is permitted to indicate lack of interest.) CHOICE OF: NETWORK ADDRESS. (including arbitrary strings) RESULT (VALUE) OF PREVIOUS MASKING OPERATION>. OPERATOR_DESCRIPTOR ::= The source of much discussion on overhead, 5 complexity, and feasibility. Is anding and testing for equality to the mask good enough or do we need to define a set of allowed operations? MASK_DESCRIPTOR: A MASK of a length less than or equal to the field. (Otherwise there is no match. 1's set in the mask indicate bits which are of interest. Actually, is is defined to be other identical to the field_descriptor. (LENGTH followed by RESULT or NETWORKADDRESS.) ACTION_PAIR. VALUE or RANGE OF VALUES. If the results of the masking operation fit this value or range of values, perform the following actions. Choice of: CONDENSE (FLAGS, FIELD_DESCRIPTOR, [SUBSCRIBER_ID]) EXPAND (FLAGS, FIELD_DESCRIPTOR, {SUBSCRIBER_ID]) IGNORE. GO TO RULE NUMBER X. CONDENSE indicates that the flow-record should use the designated FIELD as the source or destination address (or attribute) in the FLOW-ID, along with the designated SUBSCRIBER_ID (also a FIELD_DESCRIPTOR). (Condense implies that all packets parsing to this point will be counted in a single bucket.) EXPAND is just like condense, except the the FIELD_DESCRIPTOR indicates that the packets which parse to this point should be placed in multiple flows with source or destination address (or attribute) as designated by the the FIELD_DESCRIPTOR. IGNORE indicates that we don't count this type of packet at all. USE RULE NUMBER N indicates (theoretically) that the RESULT OF PREVIOUS MASKING OPERATION is set to the result of the FIELD VALUE & (anded with) the mask value, and the nth rule of the RULE TABLE is invoked next. This concept is disturbing because it allows for spaghetti tables that dont make sense. At this point a rule compiler front end becomes necessary... NETWORK_ADDRESS ::= [this should follow reporting format] Choice of { [0] IP ADDRESS. (TCP/IP) [1] NSAP ADDRESS. (OSI) variable length. [n] X.25 Address (CCITT) 6 [m] MAC (LLC) [x] STRING OF OCTETS. (any other arbitrary identifier)} Notes on Rules Note that each packet can only by counted within ONE FLOW, so that if all possible flows are added, the number should equal the total number of packets processed. If there are multiple ways a packet should be processed, the rules should deposit enough information in the flow record (i.e. flow-id) so that the packet can be POST-PROCESSED to be counted in multiple billing categories. The RESULT field preceding the root of the tree is considered to be a zero length field. All rule tables must in fact map into non-looping binary trees, or we won't be responsible for the result (To save space sub-trees may be shared by different branches and recursion may be used, as long as it can be shown that no infinite loops can occur Caveat emptor and all that.). When address tests are used (field = address type), recommend performing tests on the interface number first, the link level address second, the network address third, and the attributes (if any are defined later) last. Within an address type, test the source address first and the destination address last. Attendees Sean Donelan sean@dra.com Martin Dubetz dubetz@wugate.wustl.edu Gary Ellis garye@hpspd.spd.hp.com Charles Fineberg fineberg@wums2.wustl.edu Dave Geurs dgeurs@mot.com Keith Hacke hacke@informatics.wustl.edu Donald Hirsh hirsh@meridian.uucp Cyndi Mills cmills@bbn.com Agnes Moran Chris Myers chris@wugate.wustl.edu Kary Robertson kr@concord.com.kr Gregory Ruth gruth@bbn.com George Sanderson sanderson@mdc.com Jonathan Saperia saperia@decwrl.enet.dec.com Anil Singhal Kaj Tesink kaj@nvuxr.cc.bellcore.com Paul Tsuchiya tsuchiya@bellcore.com 7 Sudhanshu Verma verma@hpindbu.cup.hp.com Steve Witten 8