home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
acct
/
acct-minutes-91mar.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
14KB
|
403 lines
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...<sigh>
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