Network Working Group N. Brownlee Request for Comments: 2064 The University of Auckland Category: Experimental January 1997
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for obtaining traffic flow information from network traffic meters.
1 The Network Management Framework
2 Objects
2.1 Format of Definitions
3 Overview
3.1 Scope of Definitions, Textual Conventions
3.2 Usage of the MIB variables
4 Definitions
5 Acknowledgements
6 References
7 Security Considerations
8 Author's Address
The Internet-standard Network Management Framework consists of three components. They are:
RFC 1155 defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. STD 16, RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI.
RFC 1156 defines MIB-I, the core set of managed objects for the Internet suite of protocols. STD 17, RFC 1213 [1] defines MIB-II, an evolution of MIB-I based on implementation experience and new operational requirements.
STD 15, RFC 1157 defines the SNMP, the protocol used for network access to managed objects.
RFC 1442 [2] defines the SMI for version 2 of the Simple Network Management Protocol.
RFCs 1443 and 1444 [3,4] define Textual Conventions and Conformance Statements for version 2 of the Simple Network Management Protocol.
RFC 1452 [5] describes how versions 1 and 2 of the Simple Network Management Protocol should coexist.
The Framework permits new objects to be defined for the purpose of experimentation and evaluation.
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1) [6]
defined in the SMI. In particular, each object has a name, a syntax,
and an encoding. The name is an object identifier, an
administratively assigned name, which specifies an object type. The
object type together with an object instance serves to uniquely
identify a specific instantiation of the object. For human
convenience, we often use a textual string, termed the OBJECT
DESCRIPTOR, to also refer to the object type.
The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [2] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity.
The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network.
The SMI specifies the use of the basic encoding rules of ASN.1 [7], subject to the additional requirements imposed by the SNMP.
Section 4 contains contains the specification of all object types contained in this MIB module. These object types are defined using the conventions defined in [2] and [3].
Traffic Flow Measurement seeks to provide a well-defined method for gathering traffic flow information from networks and internetworks. The background for this is given in "Traffic Flow Measurement: Background" [8]. The Realtime Traffic Flow Measurement (rtfm) Working Group has produced a measurement architecture to achieve it; this is documented in "Traffic Flow Measurement: Architecture" [9]. The architecture defines three entities:
- METERS, which observe network traffic flows and build up a
table of flow data records for them,
- METER REAERS, which collect traffic flow data from meters, and
- MANAGERS, which oversee the operation of meters and meter readers.
This memo defines the SNMP management information for a Traffic Flow Meter (TFM). It documents the earlier work of the Internet Accounting Working Group, and is intended to provide a starting point for the Realtime Traffic Flow Measurement Working Group.
All objects defined in this memo are registered in a single subtree within the mib-2 namespace [1,2], and are for use in network devices which may perform a PDU forwarding or monitoring function. For these devices, the value of the ifSpecific variable in the MIB-II [1] has the OBJECT IDENTIFIER value:
flowMIB OBJECT IDENTIFIER ::= mib-2 40
as defined below.
The RTFM Meter MIB was first produced and tested using SNMPv1. It has been converted into SNMPv2 following the guidelines in RFC 1452 [5].
The MIB breaks into four parts - control, flows, rules and conformance statements.
The rules implement the minumum set of packet-matching actions, as set out in the "Traffic Flow Measurment: Architecture" document [9]. In addition they provide for BASIC-style subroutines, allowing a network manager to dramatically reduce the number of rules required to monitor a big network.
Traffic flows are identified by a set of attributes for each of its end-points. Attributes include network addresses for each layer of the network protocol stack, and 'subscriber ids,' which may be used to identify an accountable entity for the flow.
The conformance statements are set out as defined in [4]. They explain what must be implemented in a meter which claims to conform to this MIB.
To retrieve flow data one could simply do a linear scan of the flow table. This would certainly work, but would require a lot of protocol exchanges. To reduce the overhead in retrieving flow data the flow table uses a TimeFilter variable, defined as a Textual Convention in the RMON2 MIB [10]. This, when used together with SNMPv2's GetBulk request, allows a meter reader to scan the flow table and upload a specified set of flow attributes for those rows which have changed since the last reading.
As an alternative method of reading flow data, the MIB provides an index into the flow table called flowColumnActivityTable. This is (logically) a three-dimensional array, subscripted by flow attribute, activity time and starting flow number. This allows a meter reader to retrieve (in an opaque object) data for a column of the flow table with a minimum of SNMP overhead. An attempt has been made to include a full ASN.1 definition of the flowColumnActivityData object.
One aspect of data collection which needs emphasis is that all the
MIB variables are set up to allow multiple independent colletors to
work properly, i.e. the flow table indexes are stateless. An
alternative approach would have been to 'snapshot' the flow table,
which would mean that the meter readers would have to be
synchronized. The stateless approach does mean that two meter
readers will never return exactly the same set of traffic counts, but
over long periods (e.g. 15-minute collections over a day) the
discrepancies are acceptable. If one really needs a snapshot, this
can be achieved by switching to an identical rule set with a
different RuleSet number, hence asynchronous collections may be
regarded as a useful generalisation of synchronised ones.
The control variables are the minimum set required for a meter reader. Their number has been whittled down as experience has been gained with the MIB implementation. A few of them are 'general,' i.e. they control the overall behaviour of the meter. These are set by a single 'master' manager, and no other manager should attempt to change their values. The decision as to which manager is the 'master' must be made by the network operations personnel responsible; this MIB does not attempt to provide any support for interaction between managers.
There are three other groups of control groups, arranged into tables in the same way as in the RMON MIB [10]. They are used as follows:
- RULE SET INFO: Before attempting to download a rule table a manager
must create a row in the flowRuleSetInfo with flowRuleInfoStatus
set to 'createAndWait.' When the rule set is ready the manager
must set RuleSetInfo to 'active,' indicating that the rule set is
ready for use.
- METER READER INFO: Any meter reader wishing to collect data
reliably for all flows should first create a row in the
flowReaderInfoTable with flowReaderStatus set to 'active.' It
should write that row's flowReaderLastTime object each time it
starts a collection pass through the flow table. The meter will
not recover a flow's memory until every meter reader holding a row
in this table has collected that flow's data.
- MANAGER INFO: Any manager wishing to download rule sets to the
meter must create a row in the flowManagerInfo table with
flowManagerStatus set to 'active.'. Once it has a table row, the
manager may set the control variables in its row so as to cause the
meter to run any valid rule set held by the meter.
::= { mib-2 40 }
More details on TimeFilter variables, their implementation
and use can be found in the RMON2 MIB [10]."
SYNTAX TimeTicks
Ethernet: ethernet(7)
6-octet 802.3 MAC address in 'canonical' order
FDDI: fddi(15)
FddiMACLongAddress, i.e. a 6-octet MAC address
in 'canonical' order (defined in the FDDI MIB [12])
Token Ring: tokenring(9)
6-octet 802.5 MAC address in 'canonical' order
PeerAddress: other(1)
If traffic is being metered inside a tunnel, its
adjacent addresses will be the peer addresses of hosts
at the ends of the tunnel
"
SYNTAX OCTET STRING (SIZE (6..20))
protocols. Address format depends on the actual protocol, as follows:
IP: ip(1)
4-octet IpAddress (defined in the SNMPv2 SMI [2])
CLNS: nsap(3)
NsapAddress (defined in the SNMPv2 SMI [2])
Novell: ipx(11)
4-octet Network number,
6-octet Host number (MAC address)
AppleTalk: appletalk(12)
2-octet Network number (sixteen bits),
1-octet Host number (eight bits)
DECnet: decnet(13)
1-octet Area number (in low-order six bits),
2-octet Host number (in low-order ten bits)
"
SYNTAX OCTET STRING (SIZE (3..20))
IP:
2-octet UDP or TCP port number
Other protocols:
2-octet port number
"
SYNTAX OCTET STRING (SIZE (2))
SYNTAX INTEGER {
flowIndex(1),
flowStatus(2),
flowTimeMark(3),
sourceInterface(4),
sourceAdjacentType(5),
sourceAdjacentAddress(6),
sourceAdjacentMask(7),
sourcePeerType(8),
sourcePeerAddress(9),
sourcePeerMask(10),
sourceTransType(11),
sourceTransAddress(12),
sourceTransMask(13),
destInterface(14),
destAdjacentType(15),
destAdjacentAddress(16),
destAdjacentMask(17),
destPeerType(18),
destPeerAddress(19),
destPeerMask(20),
destTransType(21),
destTransAddress(22),
destTransMask(23),
pduScale(234),
octetScale(25),
ruleSet(26),
toOctets(27), -- Source-to-Dest
toPDUs(28),
fromOctets(29), -- Dest-to-Source
fromPDUs(30),
firstTime(31), -- Activity times
lastActiveTime(32),
sourceSubscriberID(33), -- Subscriber ID
destSubscriberID(34),
sessionID(35),
sourceClass(36), -- Computed attributes
destClass(37),
flowClass(38),
sourceKind(39),
destKind(40),
flowKind(41) }
sourceInterface(4), -- Source Address
sourceAdjacentType(5),
sourceAdjacentAddress(6),
sourcePeerType(8),
sourcePeerAddress(9),
sourceTransType(11),
sourceTransAddress(12),
destInterface(14), -- Dest Address
destAdjacentType(15),
destAdjacentAddress(16),
destPeerType(18),
destPeerAddress(19),
destTransType(21),
destTransAddress(22),
sourceSubscriberID(33), -- Subscriber ID
destSubscriberID(34),
sessionID(35),
v1(51), -- Meter variables
v2(52),
v3(53),
v4(54),
v5(55) }
assign(8),
assignAct(9),
goto(10),
gotoAct(11),
pushRuleTo(12),
pushRuleToAct(13),
pushPktTo(14),
pushPktToAct(15) }
::= { flowControl 1 }
::= { flowRuleSetInfoTable 1 }
flowRuleInfoIndex Integer32,
flowRuleInfoSize Integer32,
flowRuleInfoOwner OwnerString,
flowRuleInfoTimeStamp TimeStamp,
flowRuleInfoStatus RowStatus
}
Each such entry contains control information for a particular rule set which the meter may run."
::= { flowRuleSetInfoEntry 1 }
::= { flowRuleSetInfoEntry 2 }
::= { flowRuleSetInfoEntry 3 }
::= { flowRuleSetInfoEntry 4 }
::= { flowRuleSetInfoEntry 5 }
"An array of information specific to each meter interface."
::= { flowControl 2 }
INDEX { ifIndex }
::= { flowInterfaceTable 1 }
flowInterfaceRate Integer32,
flowInterfaceLostPackets Counter32
}
::= { flowInterfaceEntry 1 }
::= { flowInterfaceEntry 2 }
::= { flowControl 3 }
::= { flowReaderInfoTable 1 }
flowReaderIndex Integer32,
flowReaderTimeout Integer32,
flowReaderOwner OwnerString,
flowReaderLastTime TimeStamp,
flowReaderPreviousTime TimeStamp,
flowReaderStatus RowStatus
}
::= { flowReaderInfoEntry 1 }
STATUS current
DESCRIPTION
"Specifies the maximum time (in seconds) between flow data
collections for this meter reader. If this time elapses
without a collection, the meter should assume that this meter
reader has stopped collecting, and delete this row from the
table."
::= { flowReaderInfoEntry 2 }
::= { flowReaderInfoEntry 3 }
This variable should be written by a meter reader as the first step in reading flow data. The meter will set this LastTime value to sysUptime and set its PreviousTime value (below) to the old LastTime. This allows the meter to recover flows which have been inactive since PreviousTime, for these have been collected at least once.
If the meter fails to write flowLastReadTime, e.g. by failing authentication in the meter's SNMP write community, collection may still proceed but the meter may not be able to recover inactive flows."
::= { flowReaderInfoEntry 4 }
::= { flowReaderInfoEntry 5 }
STATUS current
DESCRIPTION
"The status of this meter reader."
::= { flowReaderInfoEntry 6 }
::= { flowControl 4 }
::= { flowManagerInfoTable 1 }
flowManagerIndex Integer32,
flowManagerCurrentRuleSet Integer32,
flowManagerStandbyRuleSet Integer32,
flowManagerHighWaterMark INTEGER,
flowManagerCounterWrap INTEGER,
flowManagerOwner OwnerString,
flowManagerTimeStamp TimeStamp,
flowManagerStatus RowStatus
}
"Selects an entry from the array of manager info entries."
::= { flowManagerInfoEntry 1 }
::= { flowManagerInfoEntry 2 }
::= { flowManagerInfoEntry 3 }
::= { flowManagerInfoEntry 4 }
DESCRIPTION
"Specifies whether PDU and octet counters should wrap when
they reach the top of their range (normal behaviour for
Counter32 objects), or whether their scale factors should
be used instead. The combination of counter and scale
factor allows counts to be returned as binary floating
point numbers, with 32-bit mantissas and 8-bit exponents."
DEFVAL { wrap }
::= { flowManagerInfoEntry 5 }
::= { flowManagerInfoEntry 6 }
::= { flowManagerInfoEntry 7 }
::= { flowManagerInfoEntry 8 }
DESCRIPTION
"A value expressed as a percentage, interpreted by the meter
as an indication of how full the flow table should be before
it should take some action to avoid running out of resources
to handle new flows. Values of 0% or 100% disable the
checking represented by this variable."
::= { flowControl 5 }
::= { flowControl 6 }
::= { flowControl 7 }
::= { flowControl 8 }
::= { flowData 1 }
::= { flowDataTable 1 }
flowDataIndex Integer32,
flowDataTimeMark TimeFilter,
flowDataStatus INTEGER,
flowDataSourceInterface Integer32,
flowDataSourceAdjacentType AddressType,
flowDataSourceAdjacentAddress AdjacentAddress,
flowDataSourceAdjacentMask AdjacentAddress,
flowDataSourcePeerType AddressType,
flowDataSourcePeerAddress PeerAddress,
flowDataSourcePeerMask PeerAddress,
flowDataSourceTransType INTEGER,
flowDataSourceTransAddress TransportAddress,
flowDataSourceTransMask TransportAddress,
flowDataDestInterface Integer32,
flowDataDestAdjacentType AddressType,
flowDataDestAdjacentAddress AdjacentAddress,
flowDataDestAdjacentMask AdjacentAddress,
flowDataDestPeerType AddressType,
flowDataDestPeerAddress PeerAddress,
flowDataDestPeerMask PeerAddress,
flowDataDestTransType INTEGER,
flowDataDestTransAddress TransportAddress,
flowDataDestTransMask TransportAddress,
flowDataPDUScale INTEGER,
flowDataOctetScale INTEGER,
flowDataRuleSet INTEGER,
flowDataToOctets Counter32, -- Source->Dest
flowDataToPDUs Counter32,
flowDataFromOctets Counter32, -- Dest->Source
flowDataFromPDUs Counter32,
flowDataFirstTime TimeTicks, -- Activity times
flowDataLastActiveTime TimeTicks,
flowDataSourceSubscriberID OCTET STRING,
flowDataDestSubscriberID OCTET STRING,
flowDataSessionID OCTET STRING,
flowDataSourceClass INTEGER,
flowDataDestClass INTEGER,
flowDataClass INTEGER,
flowDataSourceKind INTEGER,
flowDataDestKind INTEGER,
flowDataKind INTEGER
}
::= { flowDataEntry 1 }
::= { flowDataEntry 2 }
::= { flowDataEntry 3 }
::= { flowDataEntry 4 }
::= { flowDataEntry 5 }
::= { flowDataEntry 6 }
::= { flowDataEntry 7 }
::= { flowDataEntry 8 }
::= { flowDataEntry 9 }
::= { flowDataEntry 10 }
::= { flowDataEntry 11 }
::= { flowDataEntry 12 }
comparing the transport source address for this flow."
::= { flowDataEntry 13 }
::= { flowDataEntry 14 }
::= { flowDataEntry 15 }
::= { flowDataEntry 16 }
::= { flowDataEntry 17 }
::= { flowDataEntry 18 }
SYNTAX PeerAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Address of the peer device for the destination of this flow."
::= { flowDataEntry 19 }
::= { flowDataEntry 20 }
::= { flowDataEntry 21 }
::= { flowDataEntry 22 }
::= { flowDataEntry 23 }
the number of bits the PDU counter values should be moved left to obtain the actual values."
::= { flowDataEntry 24 }
::= { flowDataEntry 25 }
::= { flowDataEntry 26 }
::= { flowDataEntry 27 }
::= { flowDataEntry 28 }
DESCRIPTION
"The count of octets flowing from dest to source address and
being delivered to the protocol level being metered."
::= { flowDataEntry 29 }
::= { flowDataEntry 30 }
::= { flowDataEntry 31 }
::= { flowDataEntry 32 }
::= { flowDataEntry 33 }
flow."
::= { flowDataEntry 34 }
::= { flowDataEntry 35 }
::= { flowDataEntry 36 }
::= { flowDataEntry 37 }
::= { flowDataEntry 38 }
::= { flowDataEntry 39 }
::= { flowDataEntry 40 }
::= { flowDataEntry 41 }
STATUS current
DESCRIPTION
"Index into the Flow Table. Allows a meter reader to retrieve
a list containing the flow table indeces of flows which were
last active at or after a given time, together with the values
of a specified attribute for each such flow."
::= { flowData 2 }
::= { flowColumnActivityTable 1 }
flowColumnActivityAttribute FlowAttributeNumber,
flowColumnActivityTime TimeFilter,
flowColumnActivityIndex Integer32,
flowColumnActivityData OCTET STRING
}
::= { flowColumnActivityEntry 1 }
::= { flowColumnActivityEntry 2 }
::= { flowColumnActivityEntry 3 }
The format of objects inside flowColumnFlowData is as follows. All numbers are unsigned. Numbers and strings appear with
their high-order bytes leading. Numbers are fixed size, as specified by their SYNTAX in the flow table (above), i.e. one octet for flowAddressType and small constants, and four octets for Counter and Timeticks. Strings are variable-length, with the length given in a single leading octet.
The following is an attempt at an ASN.1 definition of flowColumnActivityData:
flowColumnActivityData ::= SEQUENCE flowRowItemEntry
flowRowItemEntry ::= SEQUENCE {
flowRowNumber INTEGER (1..65535),
-- 0 indicates the end of this column
flowDataValue flowDataType -- Choice depends on attribute
}
flowDataType ::= CHOICE {
flowByteValue INTEGER (1..255),
flowShortValue INTEGER (1..65535),
flowLongValue Integer32,
flowStringValue OCTET STRING -- Length (n) in first byte,
-- n+1 bytes total length, trailing zeroes truncated
}"
::= { flowColumnActivityEntry 4 }
STATUS current
DESCRIPTION
"Contains all the rule sets which may be used by the meter."
::= { flowRules 1 }
STATUS current
DESCRIPTION
"The rule record itself."
INDEX { flowRuleSet, flowRuleIndex }
::= { flowRuleTable 1 }
flowRuleSet INTEGER,
flowRuleIndex INTEGER,
flowRuleSelector RuleAttributeNumber,
flowRuleMask RuleAddress,
flowRuleMatchedValue RuleAddress,
flowRuleAction ActionNumber,
flowRuleParameter Integer32
}
::= { flowRuleEntry 1 }
::= { flowRuleEntry 2 }
null(0) is a special case; null rules always succeed.
v1(51), v2(52), v3(53), v4(54) and v5(55) select meter variables, each of which can hold the name (i.e. selector
value) of an address attribute. When one of these is used as a selector, its value specifies the attribute to be tested. Variable values are set by an Assign action."
::= { flowRuleEntry 3 }
::= { flowRuleEntry 4 }
::= { flowRuleEntry 5 }
::= { flowRuleEntry 6 }
::= { flowRuleEntry 7 }
OBJECT IDENTIFIER ::= { flowMIBConformance 1 }
OBJECT IDENTIFIER ::= { flowMIBConformance 2 }
::= {flowMIBGroups 1 }
flowDataDestPeerAddress, flowDataDestPeerMask,
flowDataDestTransType,
flowDataDestTransAddress, flowDataDestTransMask,
flowDataRuleSet,
flowDataToOctets, flowDataToPDUs,
flowDataFromOctets, flowDataFromPDUs,
flowDataFirstTime, flowDataLastActiveTime,
flowDataSourceClass, flowDataDestClass, flowDataClass,
flowDataSourceKind, flowDataDestKind, flowDataKind
}
STATUS current
DESCRIPTION
"The flow table group defines objects which provide the
structure for the rule table, including the creation time
and activity time indexes into it. In addition it defines
objects which provide a base set of flow attributes for the
adjacent, peer and transport layers, together with a flow's
counters and times. Finally it defines a flow's class and
kind attributes, which are set by rule actions."
::= {flowMIBGroups 2 }
::= {flowMIBGroups 3 }
::= {flowMIBGroups 4 }
flowColumnActivityData
}
STATUS current
DESCRIPTION
"The flow column table group defines objects which can be used
to collect part of a column of attribute values from the flow
table."
::= {flowMIBGroups 5 }
::= {flowMIBGroups 6 }
::= { flowMIBCompliances 1 }
This document was initially produced under the auspices of the IETF's Accounting Working Group with assistance from SNMP and SAAG working groups. Particular thanks are due to Jim Barnes, Sig Handelman and Stephen Stibler for their support and their assistance with checking the MIB.
[1] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets," STD 17, RFC 1213, Performance Systems International, March 1991.
[2] Case J., McCloghrie K., Rose M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Managemenet Protocol," RFC 1902, SNMP Research Inc., Hughes LAN Systems, Dover Beach Consulting, Carnegie Mellon University, April 1993.
[3] Case J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Managemenet Protocol SNMPv2", RFC 1903, SNMP Research Inc., Hughes LAN Systems, Dover Beach Consulting, Carnegie Mellon University, April 1993.
[4] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for version 2 of the Simple Network Managemenet Protocol (SNMPv2)," RFC 1904, SNMP Research Inc., Hughes LAN Systems, Dover Beach Consulting, Carnegie Mellon University, April 1993.
[5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework," RFC 1908, SNMP Research Inc., Hughes LAN Systems, Dover Beach Consulting, Carnegie Mellon University, April 1993.
[6] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987.
[7] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Notation One
(ASN.1), International Organization for Standardization,
International Standard 8825, December 1987.
[8] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting Background," RFC 1272, Bolt Beranek and Newman Inc., Meridian Technology Corporation, November 1991.
[9] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2063, The University of Auckland, Bolt Beranek and Newman Inc., GTE Laboratories, Inc, January 1997.
[10] Waldbusser, S., "Remote Network Monitoring Management Information Base, Version 2," Work in Progress.
[11] Reynolds, J., and J, Postel, "Assigned Numbers," STD 2, RFC 1700, ISI, October 1994.
[12] Case, J., "FDDI Management Information Base," RFC 1285, SNMP Research Incorporated, January 1992.
Security issues are not discussed in this document.
Nevil Brownlee
Information Technology Systems & Services
The University of Auckland
Phone: +64 9 373 7599 x8941
EMail: n.brownlee @auckland.ac.nz