draft-ietf-rtfm-ruleset-language-06.txt   draft-ietf-rtfm-ruleset-language-07.txt 
Internet Engineering Task Force Nevil Brownlee Internet Engineering Task Force Nevil Brownlee
INTERNET-DRAFT The University of Auckland INTERNET-DRAFT The University of Auckland
Expires December 1999
SRL: A Language for Describing Traffic Flows August 1999
and Specifying Actions for Flow Groups Expires February 2000
<draft-ietf-rtfm-ruleset-language-06.txt> SRL: A Language for Describing Traffic Flows and
Specifying Actions for Flow Groups
<draft-ietf-rtfm-ruleset-language-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet Draft is a product of the Realtime Traffic Flow This Internet Draft is a product of the Realtime Traffic Flow
Measurement Working Group of the IETF. Measurement Working Group of the IETF.
Abstract Abstract
This document describes a language for specifying rulesets, i.e. This document describes a language for specifying rulesets, i.e.
configuration files which may be loaded into a traffic flow meter so as configuration files which may be loaded into a traffic flow meter so
to specify which traffic flows are measured by the meter, and the as to specify which traffic flows are measured by the meter, and the
information it will store for each flow. information it will store for each flow.
Contents Contents
1 Purpose and Scope 2 1 Purpose and Scope 3
1.1 RTFM Meters and Traffic Flows . . . . . . . . . . . . . . . . 2 1.1 RTFM Meters and Traffic Flows . . . . . . . . . . . . . . . . 3
1.2 SRL Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 SRL Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2 SRL Language Description 4 2 SRL Language Description 5
2.1 Define Directive . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Define Directive . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Declaration . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Declaration . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Statement 5 3 Statement 6
3.1 IF_statement . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 IF_statement . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1 expression . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1 expression . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2 term . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2 term . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3 factor . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3 factor . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.4 operand_list . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.4 operand_list . . . . . . . . . . . . . . . . . . . . . 8
3.1.5 operand . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.5 operand . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.6 Test Part . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.6 Test Part . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.7 Action Part . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.7 Action Part . . . . . . . . . . . . . . . . . . . . . . 9
3.1.8 ELSE Clause . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.8 ELSE Clause . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Compound_statement . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Compound_statement . . . . . . . . . . . . . . . . . . . . . 10
3.3 Imperative_statement . . . . . . . . . . . . . . . . . . . . . 9 3.3 Imperative_statement . . . . . . . . . . . . . . . . . . . . 10
3.3.1 SAVE Statement . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1 SAVE Statement . . . . . . . . . . . . . . . . . . . . 11
3.3.2 COUNT Statement . . . . . . . . . . . . . . . . . . . . . 10 3.3.2 COUNT Statement . . . . . . . . . . . . . . . . . . . . 11
3.3.3 EXIT Statement . . . . . . . . . . . . . . . . . . . . . . 10 3.3.3 EXIT Statement . . . . . . . . . . . . . . . . . . . . 11
3.3.4 IGNORE Statement . . . . . . . . . . . . . . . . . . . . . 11 3.3.4 IGNORE Statement . . . . . . . . . . . . . . . . . . . 12
3.3.5 NOMATCH Statement . . . . . . . . . . . . . . . . . . . . 11 3.3.5 NOMATCH Statement . . . . . . . . . . . . . . . . . . . 12
3.3.6 STORE Statement . . . . . . . . . . . . . . . . . . . . . 11 3.3.6 STORE Statement . . . . . . . . . . . . . . . . . . . . 12
3.3.7 RETURN Statement . . . . . . . . . . . . . . . . . . . . . 11 3.3.7 RETURN Statement . . . . . . . . . . . . . . . . . . . 13
3.4 Subroutine_declaration . . . . . . . . . . . . . . . . . . . . 12 3.4 Subroutine_declaration . . . . . . . . . . . . . . . . . . . 13
3.5 CALL_statement . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5 CALL_statement . . . . . . . . . . . . . . . . . . . . . . . 14
4 Example Programs 13 4 Example Programs 15
4.1 Classify IP Port Numbers . . . . . . . . . . . . . . . . . . . 13 4.1 Classify IP Port Numbers . . . . . . . . . . . . . . . . . . 15
4.2 Classify Traffic into Groups of Networks . . . . . . . . . . . 14 4.2 Classify Traffic into Groups of Networks . . . . . . . . . . 16
5 Security Considerations 16 5 Security Considerations 17
6 IANA Considerations 16 6 IANA Considerations 17
7 APPENDICES 16 7 APPENDICES 18
7.1 Appendix A: SRL Syntax in BNF . . . . . . . . . . . . . . . . 16 7.1 Appendix A: SRL Syntax in BNF . . . . . . . . . . . . . . . . 18
7.2 Appendix B: Syntax for Values and Masks . . . . . . . . . . . 18 7.2 Appendix B: Syntax for Values and Masks . . . . . . . . . . . 20
7.3 Appendix C: RTFM Attribute Information . . . . . . . . . . . . 19 7.3 Appendix C: RTFM Attribute Information . . . . . . . . . . . 21
8 Acknowledgments 21 8 Acknowledgments 22
9 References 21 9 References 22
10 Author's Address 21 10 Author's Address 23
1 Purpose and Scope 1 Purpose and Scope
A ruleset for an RTFM Meter is a sequence of instructions to be executed A ruleset for an RTFM Meter is a sequence of instructions to be executed
by the meter's Pattern Matching Engine (PME). The form of these by the meter's Pattern Matching Engine (PME). The form of these
instructions is described in detail in the 'RTFM Architecture' and 'RTFM instructions is described in detail in the 'RTFM Architecture' and 'RTFM
Meter MIB' documents [1], [2], but most users - at least initially - Meter MIB' documents [RTFM-ARC, RTFM-MIB], but most users - at least
find them confusing and difficult to write, mainly because the effect of initially - find them confusing and difficult to write, mainly because
each instruction is strongly dependent on the state of the meter's the effect of each instruction is strongly dependent on the state of the
Packet Matching Engine at the moment of its execution. meter's Packet Matching Engine at the moment of its execution.
SRL (the Simple Ruleset Language) is a procedural language for creating SRL (the Simple Ruleset Language) is a procedural language for creating
RTFM rulesets. It has been designed to be simple for people to RTFM rulesets. It has been designed to be simple for people to
understand, using statements which help to clarify the execution context understand, using statements which help to clarify the execution context
in which they operate. SRL programs will be compiled into rulesets in which they operate. SRL programs will be compiled into rulesets
which can then be downloaded to RTFM meters. which can then be downloaded to RTFM meters.
An SRL compiler is available as part of NeTraMet (a free-software An SRL compiler is available as part of NeTraMet (a free-software
implementation of the RTFM meter and manager), version 4.2 [3]. implementation of the RTFM meter and manager), version 4.2 [NETRAMET].
1.1 RTFM Meters and Traffic Flows 1.1 RTFM Meters and Traffic Flows
The RTFM Architecture [1] defines a set of 'attributes' which apply to The RTFM Architecture [RTFM-ARC] defines a set of 'attributes' which
network traffic. Among the attributes are 'address attributes,' such as apply to network traffic. Among the attributes are 'address
PeerType, PeerAddress, TransType and TransAddress, which have meaning attributes,' such as PeerType, PeerAddress, TransType and TransAddress,
for many protocols, e.g. for IPv4 traffic (PeerType == 1) PeerAddress which have meaning for many protocols, e.g. for IPv4 traffic (PeerType
is an IP address, TransType is TCP(6), UDP(17), ICMP(1), etc., and == 1) PeerAddress is an IP address, TransType is TCP(6), UDP(17),
TransAddress is usually an IP port number. ICMP(1), etc., and TransAddress is usually an IP port number.
An 'RTFM Traffic Flow' is simply a stream of packets observed by a meter An 'RTFM Traffic Flow' is simply a stream of packets observed by a meter
as they pass across a network between two end points (or to/from a as they pass across a network between two end points (or to/from a
single end point). Each 'end point' of a flow is specified by the set single end point). Each 'end point' of a flow is specified by the set
of values of its address attributes. of values of its address attributes.
An 'RTFM Meter' is a measuring device - e.g. a program running on a An 'RTFM Meter' is a measuring device - e.g. a program running on a Unix
Unix or PC host - which observes passing packets and builds 'Flow Data or PC host - which observes passing packets and builds 'Flow Data
Records' for the flows of interest. Records' for the flows of interest.
RTFM traffic flows have another important property - they are RTFM traffic flows have another important property - they are
bi-directional. This means that each flow data record in the meter has bi-directional. This means that each flow data record in the meter has
two sets of counters, one for packets travelling from source to two sets of counters, one for packets travelling from source to
destination, the other for returning packets. Within the RTFM destination, the other for returning packets. Within the RTFM
architecture such counters appear as further attributes of the flow. architecture such counters appear as further attributes of the flow.
An RTFM meter must be configured by the user, which means creating a An RTFM meter must be configured by the user, which means creating a
'Ruleset' so as to specify which flows are to be measured, and how much 'Ruleset' so as to specify which flows are to be measured, and how much
information (i.e. which attributes) should be stored for each of them. information (i.e. which attributes) should be stored for each of them.
A ruleset is effectively a program for a minimal virtual machine, the A ruleset is effectively a program for a minimal virtual machine, the
'Packet Matching Engine (PME),' which is described in detail in [1]. An
RTFM meter may run multiple rule sets, with every passing packet being 'Packet Matching Engine (PME),' which is described in detail in
processed by each of the rulesets. The rule 'actions' in this document [RTFM-ARC]. An RTFM meter may run multiple rule sets, with every passing
are described as though only a single ruleset were running. packet being processed by each of the rulesets. The rule 'actions' in
this document are described as though only a single ruleset were
running.
In the past creating a ruleset has meant writing machine code for the In the past creating a ruleset has meant writing machine code for the
PME, which has proved rather difficult to do. SRL provides a high-level PME, which has proved rather difficult to do. SRL provides a high-level
language which should enable users to create effective rulesets without language which should enable users to create effective rulesets without
having to understand the details of the PME. having to understand the details of the PME.
The language may be useful in other applications, being suitable for any The language may be useful in other applications, being suitable for any
application area which involves selecting traffic flows from a stream of application area which involves selecting traffic flows from a stream of
packets. packets.
skipping to change at page 5, line 40 skipping to change at page 5, line 34
may not be used as identifiers may not be used as identifiers
2.1 Define Directive 2.1 Define Directive
--- DEFINE -- defname ---- = ---- defined_text ------------------ ; --- DEFINE -- defname ---- = ---- defined_text ------------------ ;
Simple parameterless defines are supported via the syntax above. The Simple parameterless defines are supported via the syntax above. The
define name, defname, is an identifier. The defined text starts after define name, defname, is an identifier. The defined text starts after
the equal sign, and continues up to (but not including) the closing the equal sign, and continues up to (but not including) the closing
semicolon. If a semicolon is required within the defined text it must semicolon. If a semicolon is required within the defined text it must
be preceded by a backslash, i.e. \; in an SRL define produces ; in the be preceded by a backslash, i.e. \x; in an SRL define produces ; in the
text. text.
Wherever defname appears elsewhere in the program, it will be replaced Wherever defname appears elsewhere in the program, it will be replaced
by the defined text. by the defined text.
For example, For example,
DEFINE ftp = (20, 21); # Well-known Port numbers from [4] DEFINE ftp = (20, 21); # Well-known Port numbers from [ASG-NBR]
DEFINE telnet = 23; DEFINE telnet = 23;
DEFINE www = 80; DEFINE www = 80;
2.2 Program 2.2 Program
------------+-------+-------- Statement -------+-------+----------- ------------+-------+-------- Statement -------+-------+-----------
| | | | | | | |
| +------- Declaration ------+ | | +------- Declaration ------+ |
| | | |
+---------------------<--------------------+ +---------------------<--------------------+
skipping to change at page 14, line 36 skipping to change at page 15, line 12
statement executed after RETURN will be the statement immediately statement executed after RETURN will be the statement immediately
following ENDCALL. following ENDCALL.
4 Example Programs 4 Example Programs
4.1 Classify IP Port Numbers 4.1 Classify IP Port Numbers
# #
# Classify IP port numbers # Classify IP port numbers
# #
define IPv4 = 1; # Address Family number from [4] define IPv4 = 1; # Address Family number from [ASG-NBR]
# #
define ftp = (20, 21); # Well-Known Port numbers from [4] define ftp = (20, 21); # Well-Known Port numbers from [ASG-NBR]
define telnet = 23; define telnet = 23;
define www = 80; define www = 80;
# #
define tcp = 6; # Protocol numbers from [4] define tcp = 6; # Protocol numbers from [ASG-NBR]
define udp = 17; define udp = 17;
# #
if SourcePeerType == IPv4 save; if SourcePeerType == IPv4 save;
else ignore; # Not an IPv4 packet else ignore; # Not an IPv4 packet
# #
if (SourceTransType == tcp __ SourceTransType == udp) save, { if (SourceTransType == tcp || SourceTransType == udp) save, {
if SourceTransAddress == (www, ftp, telnet) nomatch; if SourceTransAddress == (www, ftp, telnet) nomatch;
# We want the well-known port as Dest # We want the well-known port as Dest
# #
if DestTransAddress == telnet if DestTransAddress == telnet
save, store FlowKind := 'T'; save, store FlowKind := 'T';
else if DestTransAddress == www else if DestTransAddress == www
save, store FlowKind := 'W'; save, store FlowKind := 'W';
else if DestTransAddress == ftp else if DestTransAddress == ftp
save, store FlowKind := 'F'; save, store FlowKind := 'F';
else { else {
skipping to change at page 17, line 14 skipping to change at page 17, line 30
5 Security Considerations 5 Security Considerations
SRL is a language for creating rulesets (i.e. configuration files) for SRL is a language for creating rulesets (i.e. configuration files) for
RTFM Traffic Meters - it does not present any security issues in itself. RTFM Traffic Meters - it does not present any security issues in itself.
On the other hand, flow data gathered using such rulesets may well be On the other hand, flow data gathered using such rulesets may well be
valuable. It is therefore important to take proper precautions to valuable. It is therefore important to take proper precautions to
ensure that access to the meter and its data is secure. Ways to achieve ensure that access to the meter and its data is secure. Ways to achieve
this are discussed in detail in the Architecture and Meter MIB documents this are discussed in detail in the Architecture and Meter MIB documents
[1,2]. [RTFM-ARC, RTFM-MIB].
6 IANA Considerations 6 IANA Considerations
Appendix C below lists the RTFM attributes by name. Since SRL only Appendix C below lists the RTFM attributes by name. Since SRL only
refers to attributes by name, SRL users do not have to know the refers to attributes by name, SRL users do not have to know the
attribute numbers. attribute numbers.
The size (in bytes) of the various attribute values is also listed in The size (in bytes) of the various attribute values is also listed in
Appendix C. These sizes reflect the object sizes for the attribute Appendix C. These sizes reflect the object sizes for the attribute
values as they are stored in the RTFM Meter MIB [2]. values as they are stored in the RTFM Meter MIB [RTFM-MIB].
IANA considerations for allocating new attributes are discussed in IANA considerations for allocating new attributes are discussed in
detail in the RTFM Architecture document [1]. detail in the RTFM Architecture document [RTFM-ARC].
7 APPENDICES 7 APPENDICES
7.1 Appendix A: SRL Syntax in BNF 7.1 Appendix A: SRL Syntax in BNF
<SRL program> ::= <S or D> | <SRL program> <S or D> <SRL program> ::= <S or D> | <SRL program> <S or D>
<S or D> ::= <statement> | <declaration> <S or D> ::= <statement> | <declaration>
<declaration> ::= <Subroutine declaration> <declaration> ::= <Subroutine declaration>
skipping to change at page 19, line 37 skipping to change at page 20, line 12
<int label seq> ::= <integer> : | <int label seq> <integer> : <int label seq> ::= <integer> : | <int label seq> <integer> :
The following are terminals, recognised by the scanner: The following are terminals, recognised by the scanner:
<identifier> Described in section 2 <identifier> Described in section 2
<integer> A decimal integer <integer> A decimal integer
<attribute> Attribute name, as listed in Appendix C <attribute> Attribute name, as listed in Appendix C
<value>, <mask> Described in Appendix B <value>, <mask> Described in section 5.2
<width> ::= <integer> <width> ::= <integer>
<label> ::= <identifier> <label> ::= <identifier>
<variable> ::= SourceClass | DestClass | FlowClass | <variable> ::= SourceClass | DestClass | FlowClass |
SourceKind | DestKind | FlowKind SourceKind | DestKind | FlowKind
7.2 Appendix B: Syntax for Values and Masks 7.2 Appendix B: Syntax for Values and Masks
Values and masks consist of sequences of numeric fields, each of one or Values and masks consist of sequences of numeric fields, each of one or
skipping to change at page 20, line 25 skipping to change at page 20, line 47
Unspecified fields (at the right-hand side of a value or mask) are set Unspecified fields (at the right-hand side of a value or mask) are set
to zero, i.e. 130.216 is the same as 130.216.0.0. to zero, i.e. 130.216 is the same as 130.216.0.0.
If only a single field is specified (no field width character), the If only a single field is specified (no field width character), the
value given fills the whole field. For example, 23 and 0.23 specify the value given fills the whole field. For example, 23 and 0.23 specify the
same value for a SourceTransAddress operand. For variables (which have same value for a SourceTransAddress operand. For variables (which have
one-byte values) a C-style character constant may also be used. one-byte values) a C-style character constant may also be used.
IPv6 addresses and masks may also be used, following the conventions set IPv6 addresses and masks may also be used, following the conventions set
out in the IP Version 6 Addressing Architecture RFC [5]. out in the IP Version 6 Addressing Architecture RFC [V6-ADR].
7.3 Appendix C: RTFM Attribute Information 7.3 Appendix C: RTFM Attribute Information
The following attributes may be tested in an IF statement, and their The following attributes may be tested in an IF statement, and their
values may be SAVEd (except for MatchingStoD). Their maximum size (in values may be SAVEd (except for MatchingStoD). Their maximum size (in
bytes) is shown to the left, and a brief description is given for each. bytes) is shown to the left, and a brief description is given for each.
The names given here are reserved words in SRL (they are <attribute> The names given here are reserved words in SRL (they are <attribute>
terminals in the grammar given in Appendix A). terminals in the grammar given in Appendix A).
Note that this table gives only a very brief summary. The Meter MIB Note that this table gives only a very brief summary. The Meter MIB
[2] provides the definitive specification of attributes and their [RTFM-MIB] provides the definitive specification of attributes and their
allowed values. The MIB variables which represent flow attributes allowed values. The MIB variables which represent flow attributes have
have 'flowData' prepended to their names to indicate that they belong 'flowData' prepended to their names to indicate that they belong to the
to the MIB's flowData table. MIB's flowData table.
1 SourceInterface, DestInterface 1 SourceInterface, DestInterface
Interface(s) on which the flow was observed Interface(s) on which the flow was observed
1 SourceAdjacentType, DestAdjacentType 1 SourceAdjacentType, DestAdjacentType
Indicates the interface type(s), i.e. an ifType from [4], or Indicates the interface type(s), i.e. an ifType from [ASG-NBR],
an Address Family Number (if metering within a tunnel) or an Address Family Number (if metering within a tunnel)
20 SourceAdjacentAddress, DestAdjacentAddress 20 SourceAdjacentAddress, DestAdjacentAddress
For IEEE 802.x interfaces, the MAC addresses for the flow For IEEE 802.x interfaces, the MAC addresses for the flow
1 SourcePeerType, DestPeerType 1 SourcePeerType, DestPeerType
Peer protocol types, i.e. Address Family Number from [4], Peer protocol types, i.e. Address Family Number from [ASG-NBR],
such as IPv4, Novell, Ethertalk, .. such as IPv4, Novell, Ethertalk, ..
20 SourcePeerAddress, DestPeerAddress 20 SourcePeerAddress, DestPeerAddress
Peer Addresses (size varies, e.g. 4 for IPv4, 3 for Ethertalk)) Peer Addresses (size varies, e.g. 4 for IPv4, 3 for Ethertalk))
1 SourceTransType, DestTransType 1 SourceTransType, DestTransType
Transport layer type, i.e.. Protocol Number from [4] Transport layer type, i.e. Protocol Number from [ASG-NBR]
such as tcp(6), udp(17), ospf(89), .. such as tcp(6), udp(17), ospf(89), ..
2 SourceTransAddress, DestTransAddress 2 SourceTransAddress, DestTransAddress
Transport layer addresses (e.g. port numbers for TCP and UDP) Transport layer addresses (e.g. port numbers for TCP and UDP)
1 FlowRuleset 1 FlowRuleset
Rule set number for the flow Rule set number for the flow
1 MatchingStoD 1 MatchingStoD
Indicates whether the packet is being matched with its Indicates whether the packet is being matched with its
addresses in 'wire order.' See reference [1] for details. addresses in 'wire order.' See [RTFM-ARC] for details.
The following variables may be tested in an IF, and their values may be The following variables may be tested in an IF, and their values may be
set by a STORE. They all have one-byte values. set by a STORE. They all have one-byte values.
SourceClass, DestClass, FlowClass, SourceClass, DestClass, FlowClass,
SourceKind, DestKind, FlowKind SourceKind, DestKind, FlowKind
The following RTFM attributes are not address attributes - they are The following RTFM attributes are not address attributes - they are
measured attributes of a flow. Their values may be read from an RTFM measured attributes of a flow. Their values may be read from an RTFM
meter. (For example, NeTraMet uses a FORMAT statement to specify which meter. (For example, NeTraMet uses a FORMAT statement to specify which
skipping to change at page 22, line 16 skipping to change at page 23, line 7
The SRL language is part of the RTFM Working Group's efforts to make the The SRL language is part of the RTFM Working Group's efforts to make the
RTFM traffic measurement system easier to use. Initial work on the RTFM traffic measurement system easier to use. Initial work on the
language was done by Cyndi Mills and Brad Frazee in Boston. SRL was language was done by Cyndi Mills and Brad Frazee in Boston. SRL was
developed in Auckland; it was greatly assisted by detailed discussion developed in Auckland; it was greatly assisted by detailed discussion
with John White and Russell Fulton. Discussion has continued on the with John White and Russell Fulton. Discussion has continued on the
RTFM and NeTraMet mailing lists. RTFM and NeTraMet mailing lists.
9 References 9 References
[1] Brownlee, N., Mills, C., and Ruth, G., "Traffic Flow [ASG-NBR] Reynolds, J., Postel, J., "Assigned Numbers,"
Measurement: Architecture", RFC 2063, The University of RFC 1700, ISI, October 1994.
Auckland, GTE Laboratories, Inc, January 1997.
[2] Brownlee, N., "Traffic Flow Measurement: Meter MIB",
RFC 2064, The University of Auckland, January 1997.
[3] Brownlee, N., NeTraMet home page, [NETRAMET] Brownlee, N., NeTraMet home page,
http://www.auckland.ac.nz/net/NeTraMet http://www.auckland.ac.nz/net/NeTraMet
[4] Reynolds, J., Postel, J., "Assigned Numbers," RFC 1700, [RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
ISI, October 1994. Measurement: Architecture", RFC 2063, January 1997.
[5] Hinden, R., and Deering, S., "IP Version 6 Addressing [RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB",
Architecture", RFC 2373, Nokia, Cisco Systems, July 1998. RFC 2064, January 1997.
[V6-ADDR] Hinden, R.and Deering, S., "IP Version 6 Addressing
Architecture," RFC 2373, July 1998.
10 Author's Address 10 Author's Address
Nevil Brownlee Nevil Brownlee
Information Technology Systems & Services Information Technology Systems & Services
The University of Auckland The University of Auckland
Private Bag 92-019
Auckland, New Zealand
Phone: +64 9 373 7599 x8941 Phone: +64 9 373 7599 x8941
E-mail: n.brownlee@auckland.ac.nz E-mail: n.brownlee@auckland.ac.nz
Expires December 1999 Expires February 2000
 End of changes. 42 change blocks. 
94 lines changed or deleted 100 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/