RFC 2723
SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups
SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups 🎀
Okay bestie, this is RFC 2723 💖 It was published in October 1999 under the Network Working Group, and it's written by N. Brownlee from The University of Auckland. Its category is Informational, which means it's sharing info with the Internet community and is not a standard. The header doesn't list anything it obsoletes or updates, so it's a solo act 🦋
Status of this Memo ✨
This memo just provides information for the Internet community. It doesn't specify an Internet standard of any kind, and distribution of it is unlimited 🌸
Copyright Notice 🌈
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract 💜
Okay so this doc describes a language for writing rulesets. A ruleset is a config file that gets loaded into a traffic flow meter, and it decides which traffic flows the meter measures and what info it stores for each flow 🧚
Table of Contents 📋
1 Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 2
1.1 RTFM Meters and Traffic Flows . . . . . . . . . . . . . . 2
1.2 SRL Overview . . . . . . . . . . . . . . . . . . . . . . 3
2 SRL Language Description . . . . . . . . . . . . . . . . . . 4
2.1 Define Directive . . . . . . . . . . . . . . . . . . . . 4
2.2 Program . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Declaration . . . . . . . . . . . . . . . . . . . . . . . 5
3 Statement . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 IF_statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1 expression . . . . . . . . . . . . . . . . . . . . 6
3.1.2 term . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3 factor . . . . . . . . . . . . . . . . . . . . . . 6
3.1.4 operand_list . . . . . . . . . . . . . . . . . . . 6
3.1.5 operand . . . . . . . . . . . . . . . . . . . . . . 6
3.1.6 Test Part . . . . . . . . . . . . . . . . . . . . . 7
3.1.7 Action Part . . . . . . . . . . . . . . . . . . . . 8
3.1.8 ELSE Clause . . . . . . . . . . . . . . . . . . . . 8
3.2 Compound_statement . . . . . . . . . . . . . . . . . . . 8
3.3 Imperative_statement . . . . . . . . . . . . . . . . . . 9
3.3.1 SAVE Statement . . . . . . . . . . . . . . . . . . 9
3.3.2 COUNT Statement . . . . . . . . . . . . . . . . . . 10
3.3.3 EXIT Statement . . . . . . . . . . . . . . . . . . 10
3.3.4 IGNORE Statement . . . . . . . . . . . . . . . . . 10
3.3.5 NOMATCH Statement . . . . . . . . . . . . . . . . . 10
3.3.6 STORE Statement . . . . . . . . . . . . . . . . . . 11
3.3.7 RETURN Statement . . . . . . . . . . . . . . . . . 11
3.4 Subroutine_declaration . . . . . . . . . . . . . . . . . 11
3.5 CALL_statement . . . . . . . . . . . . . . . . . . . . . 12
4 Example Programs . . . . . . . . . . . . . . . . . . . . . . 13
4.1 Classify IP Port Numbers . . . . . . . . . . . . . . . . 13
4.2 Classify Traffic into Groups of Networks . . . . . . . . 14
5 Security Considerations . . . . . . . . . . . . . . . . . . . 15
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7 APPENDICES . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1 Appendix A: SRL Syntax in BNF . . . . . . . . . . . . . . 16
7.2 Appendix B: Syntax for Values and Masks . . . . . . . . . 18
7.3 Appendix C: RTFM Attribute Information . . . . . . . . . 19
8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
9 References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10 Author's Address . . . . . . . . . . . . . . . . . . . . . . 21
11 Full Copyright Statement . . . . . . . . . . . . . . . . . . 221. Purpose and Scope 🦋
Okay so a ruleset for an RTFM Meter is basically a list of instructions that the meter's Pattern Matching Engine (PME) runs. The form of these instructions is explained in detail in the 'RTFM Architecture' and 'RTFM Meter MIB' documents [RTFM-ARC, RTFM-MIB]. But honestly? Most users, at least at first, find them super confusing and hard to write 😭 The main reason is that what each instruction does depends heavily on the state of the meter's Packet Matching Engine at the exact moment it runs.
So SRL (the Simple Ruleset Language) is a procedural language for making RTFM rulesets, and it's giving clarity ✨ It was designed to be easy for people to understand, using statements that help make the execution context make sense. SRL programs get compiled into rulesets, and those rulesets can then be downloaded to RTFM meters 💅
An SRL compiler is available as part of NeTraMet (a free-software implementation of the RTFM meter and manager), version 4.2 [NETRAMET].
1.1. RTFM Meters and Traffic Flows 🌸
The RTFM Architecture [RTFM-ARC] defines a set of 'attributes' that apply to network traffic. Some of these are 'address attributes,' like PeerType, PeerAddress, TransType and TransAddress, which mean something for lots of protocols. For example, with IPv4 traffic (PeerType == 1), PeerAddress is an IP address, TransType is TCP(6), UDP(17), ICMP(1), etc., and TransAddress is usually an IP port number 🧚
An 'RTFM Traffic Flow' is basically a stream of packets that a meter sees 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 of values of its address attributes 🎀
An 'RTFM Meter' is a measuring device, like a program running on a Unix or PC host. It watches packets go by and builds 'Flow Data Records' for the flows it cares about 👑
RTFM traffic flows have another really important property: they're bi-directional. That means each flow data record in the meter has two sets of counters, one for packets going from source to destination and one for packets coming back. Inside the RTFM architecture, those counters show up as more attributes of the flow 💜
An RTFM meter has to be configured by the user. That means creating a 'Ruleset' to specify which flows get measured and how much info (i.e. which attributes) gets stored for each of them. A ruleset is effectively a program for a minimal virtual machine, the 'Packet Matching Engine (PME),' which is described in detail in [RTFM-ARC]. An RTFM meter can run multiple rule sets, and every passing packet gets processed by each of the rulesets. The rule 'actions' in this document are described as though only a single ruleset were running 🌈
Writing a ruleset used to mean writing machine code for the PME, which was pretty painful 😩 SRL gives you a high-level language so you can make effective rulesets without having to understand all the PME details 🫶
The language may also be useful in other applications, since it's suitable for any application area that involves selecting traffic flows from a stream of packets 🍓
1.2. SRL Overview ⭐
An SRL program is run from the beginning for each new packet that arrives at the meter. It has two essential goals:
(a) Decide whether the current packet is part of a flow that's of interest and, if necessary, determine its direction (i.e. decide which of its end-points is considered to be its source). Other packets get ignored.
(b) SAVE whatever information is required to identify the flow and accumulate (COUNT) quantitative information for that flow.
When it runs, the meter's Packet Matching Engine (PME) starts by using source and destination attributes as they appear 'on the wire.' If the attributes don't match those of a flow to be recorded, the PME will normally run the program again, this time with the source and destination addresses swapped. Because of this bi-directional matching, an RTFM meter can build up tables of flows with two sets of counters: one for forward packets and one for backward packets. If the programmer wants, they can suppress the reverse-direction matching and assign 'forward' and 'backward' directions that match the conventions of the external context 🦋
Goal (a) is achieved with IF statements that do comparisons on information from the packet or from SRL variables. Goal (b) is achieved with one or more SAVE statements that store the flow's identification attributes, and then a COUNT statement increments the statistical data building up for it 💅
2. SRL Language Description 💖
The SRL language is explained below using 'railway diagrams' to describe the syntax. Flow through a diagram goes from left to right. The only exception is that lines carrying a left arrow can only be traversed right to left. In the diagrams, keywords are written in capital letters, but in practice an SRL compiler must be insensitive to case. Lower-case identifiers are explained in the text, or they refer to another diagram 🌸
The tokens of an SRL program follow these rules:
- Comments may appear on any line of an SRL program, following a #
- White space is used to separate tokens
- Semicolon is used as the terminator for most statements
- Identifiers (e.g. for defines and labels) must start with a letter
- Identifiers may contain letters, digits and underscores
- The case of letters is not significant
- Reserved words (shown in upper case in this document) may not be used as identifiers
2.1. Define Directive 🧚
--- DEFINE -- defname ---- = ---- defined_text ------------------ ;Simple parameterless defines are supported through the syntax above. The define name, defname, is an identifier. The defined text starts after the equal sign and goes up to (but not including) the closing semicolon. If you need a semicolon inside the defined text, put a backslash before it, i.e. \; in an SRL define produces ; in the text ✨
Wherever defname shows up elsewhere in the program, it gets replaced by the defined text 💜
For example:
DEFINE ftp = (20, 21); # Well-known Port numbers from [ASG-NBR]
DEFINE telnet = 23;
DEFINE www = 80;2.2. Program 🎀
------------+-------+-------- Statement -------+-------+-----------
| | | |
| +------- Declaration ------+ |
| |
+---------------------<--------------------+An SRL program is a sequence of statements or declarations. It doesn't have any special enclosing symbols. Statements and declarations end with a semicolon, except for compound statements, which end with a right brace 👑
2.3. Declaration 🌈
---------------------- Subroutine_declaration ---------------------SRL's only explicit declaration is the subroutine declaration. The other implicit declarations are labels (declared wherever they appear in front of a statement) and subroutine parameters (declared in the subroutine header) 🫶
3. Statement 🍓
----------------+---- IF_statement ----------------+---------------
| |
+---- Compound_statement ----------+
| |
+---- Imperative_statement --------+
| |
+---- CALL_statement --------------+Okay so an SRL program is a sequence of SRL statements. There are four kinds of statements, as follows. 🔥
3.1 IF_statement ✨
Test Part Action Part
............. ...............
--- IF --- expression ---+------------+---- Statement ----+--->
| | |
+-- SAVE , --+ |
| |
+-- SAVE ; ----------------------+
>-----------+-----------------------------+-----------------
| |
+-----ELSE --- Statement -----+Okay so the IF statement is the main event 💅 It has a Test Part (the question it asks) and an Action Part (what happens next), and the diagram above shows how they fit together. Bestie, this one is a whole vibe 🦋
3.1.1 expression
-------- term --------+------------------------+-------------------
| |
+--<-- term ----- || ----+ logical ORAn expression is one or more terms stitched together with ||, which is the logical OR 🌸 Literally just "either side is good enough" energy.
3.1.2 term
------- factor -------+------------------------+-------------------
| |
+--<-- factor --- && ----+ logical ANDA term is one or more factors joined with &&, the logical AND 💖 This is the "both things have to be true" move.
3.1.3 factor
------------+-------- attrib == operand_list --------+-----------
| |
+------------ ( expression ) --------------+A factor is either an attribute compared with == against an operand list, or a whole expression wrapped in parentheses 🎀 Parentheses are how you build the more complicated stuff.
3.1.4 operand_list
----------+------------------ operand -----------------+-----------
| |
+-- ( operand ---+-------------------+-- ) --+
| |
+-<-- operand , ---+An operand list is either a single operand or a parenthesised, comma-separated list of them 🧚
3.1.5 operand
------------- value ---------+----------------------+--------------
| |
+------- / width ------+
| |
+------- & mask -------+An operand is a value, optionally followed by either a / width or a & mask 🍓
3.1.6 Test Part
The IF statement evaluates a logical expression 🔥 If that expression comes out TRUE, the action in the 'Action Part' of the diagram gets run. If it comes out FALSE and the IF has an ELSE clause, then that ELSE clause runs instead (more on that below).
The simplest expression is an equality test using the == operator 💅 In that case, an RTFM attribute value (taken from the packet or from an SRL variable) gets ANDed with a mask and then compared against a value. You'll find the list of RTFM attributes in Appendix C. Anything fancier can be built up with parentheses and the && (logical AND) and || (logical OR) operators 👑
Operand values can be written as dotted decimal, as hexadecimal, or as a character constant (wrapped in apostrophes). The syntax for those is in Appendix B 🌈
Masks can be given as numbers, like:
dotted decimal e.g. &255.255
or hexadecimal e.g. &FF-FF
or as a width in bits e.g. /16If you don't specify a mask, an all-ones mask gets used ✨
In SRL, a value is always paired with a mask, and that pairing is called an operand 🦋 For example, if we wanted flows coming from IP network 130.216, we could write:
IF SourcePeerAddress == 130.216.0.0 & 255.255.0.0 SAVE;or, equivalently:
IF SourcePeerAddress == 130.216/16 SAVE;You can also put a list of values in parentheses, and the test succeeds if the masked attribute equals any one of them 🌸 For example:
IF SourcePeerAddress == ( 130.216.7/24, 130.216.34/24 ) SAVE;As that last example shows, values get right-padded with zeroes 💜 In other words, the numbers you write are the leading bytes of the masks and values.
The operand values and masks in an IF statement must be consistent with the attribute being tested 🙈 For instance, a four-byte value is fine as a peer address, but it would NOT be accepted as a transport address, which can't be longer than two bytes.
Heads up 🚨 Attribute and operand sizes have to match up. A four-byte value that works for a peer address will get rejected for a transport address.
3.1.7 Action Part
A SAVE action (that's SAVE , or SAVE ;) saves the attribute(s), mask(s) and value(s) exactly as written in the statement 💖 If the IF expression tests more than one attribute, the masks and values get saved for every matched attribute. For each value_list in the statement, the saved value is whichever one the packet actually matched. There's more about SAVE statements further down 🫶
Other actions are covered in detail under "Imperative statements" below. Also note that the RETURN action only works inside subroutines 🔥
3.1.8 ELSE Clause
An ELSE clause gives you a statement that runs when the IF's test fails 🎀 The statement after ELSE is often another IF statement, which is basically SRL's version of a 'select' statement 💅 Also, an ELSE clause always pairs with the IF right before it ✨
3.2 Compound_statement
-------+-------------+----- { ---+---- Statement ----+--- } -------
| | | |
+-- label : --+ +--------<----------+A compound statement is a bunch of statements wrapped in braces 🌈 Each statement ends with a semicolon, unless it's another compound statement, in which case it ends with a right brace instead 🍓
A compound statement can be labelled, which means it's preceded by an identifier and then a semi-colon 🧚 Every statement inside the braces runs in order, unless an EXIT statement gets performed (more on that in a sec) 💜
Labels have a well-defined scope, and inside that scope they must be unique 🔥 Labels inside a subroutine (anything between a SUBROUTINE and its matching ENDSUB) are local to that subroutine and aren't visible outside of it. Labels outside of subroutines belong to the program's outer block 👑
3.3 Imperative_statement
------+---------------------------------------------------+------ ;
| |
+-- SAVE attrib --+--+-----------+--+---------------+
| | | | | |
| | +- / width -+ | |
| | | | | |
| | +- & mask --+ | |
| | | |
| +--- = operand ---+ |
| |
+-- COUNT ------------------------------------------+
| |
+-- EXIT label ------------------------------------+
| |
+-- IGNORE -----------------------------------------+
| |
+-- NOMATCH ----------------------------------------+
| |
+-- RETURN --+-------+------------------------------+
| | | |
| +-- n --+ |
| |
+-- STORE variable := value ------------------------+Imperative statements are the "do this" commands in SRL 💪 Here's the lineup: SAVE, COUNT, EXIT, IGNORE, NOMATCH, RETURN, and STORE ✨
3.3.1 SAVE Statement
The SAVE statement stashes away information that will (later) identify the flow in the meter's flow table 🦋 It doesn't actually write anything into the table, though. That happens when a later COUNT statement runs 🌸
SAVE comes in two possible forms:
SAVE attrib = operand ; saves the attribute, mask and value exactly as they appear in the statement 💖 This is similar to what's allowed in an IF statement, except that imperative statements don't do any testing, so you can save an arbitrary value 🧚
SAVE attrib ;, SAVE attrib / width ;, and SAVE attrib & mask ; save the attribute and mask from the statement, along with the value you get by applying them to the current packet 💅 This is most useful when you want to save a value with a wider mask than the one used to pick the packet. For example:
IF DestPeerAddress == 130.216/16
NOMATCH;
ELSE IF SourcePeerAddress == 130.216/16 {
SAVE SourcePeerAddress /24;
COUNT;
}
ELSE IGNORE;3.3.2 COUNT Statement
The COUNT statement shows up after all the testing and saving is done 🎀 It tells the PME to build the flow identifier from the SAVEd attributes, look it up in the meter's flow table (creating a new entry if this is the first packet seen for that flow), and bump its counters 💜 After that, the meter moves on to the next incoming packet 🌈
3.3.3 EXIT Statement
The EXIT statement leaves a labelled compound statement 🦋 The next statement to run is the one right after that compound statement. It's a clean, clearly marked way to jump to a specific spot in a program ✨ For example:
outer: {
...
if SourcePeerAddress == 192.168/16
exit outer; # exits the statement labelled 'outer'
...
}
# execution resumes hereHonestly? The language is structured enough that you'll seldom, if ever, need EXIT 🙈
3.3.4 IGNORE Statement
The IGNORE statement ends the examination of the current packet without saving anything from it 🚫 The meter then moves on to the next incoming packet and starts again from the first statement of its program 🌸
3.3.5 NOMATCH Statement
The NOMATCH statement says that matching has failed for this run of the program 💀 If it runs while a packet is being processed with its addresses in 'on the wire' order, the PME runs the program again from the beginning, this time with source and destination addresses swapped. If it runs after such a swap has already happened, the packet gets IGNOREd 🔥
NOMATCH shows up in the SAVE example (section 3.3.1), where it makes sure that flows with 130.216/16 as an end-point get counted as though 130.216 was those flows' source peer (IP) address 👑
3.3.6 STORE Statement
The STORE statement assigns a value to an SRL variable and SAVEs it 💖 There are six SRL variables:
SourceClass SourceKind
DestClass DestKind
FlowClass FlowKindTheir names don't mean anything in particular. They were picked arbitrarily because they look like likely RTFM attributes, but they can hold any single-byte integer value 🧚 Their values get reset to zero every time examination of a new packet begins 🎀 For example:
STORE SourceClass := 3;
STORE FlowKind := 'W'3.3.7 RETURN Statement
The RETURN statement is how you get back out of a subroutine 🦋 It can only be used inside a subroutine's context. The full details are below, in the CALL statement section 🌈
3.4 Subroutine_declaration ✨
okay so this is how you declare a subroutine 💅
-- SUBROUTINE subname ( --+-----------------------------+-- ) -->
| |
+--+-- ADDRESS --- pname --+--+
| |
+-- VARIABLE -- pname --+
| |
+------<------- , ------+
>------+-------- Statement ---------+----- ENDSUB -------- ;
| |
+-------------<--------------+A Subroutine declaration has three parts, and each one is giving main character energy 🎀
- the subname is an identifier, used to name the subroutine.
- the parameter list specifies the subroutine's parameters. Each parameter starts with a keyword that tells you its type. VARIABLE means an SRL variable (see the STORE statement above), and ADDRESS means any other RTFM attribute. A parameter name can be any identifier, and its scope is limited to the subroutine's body.
- the body specifies what processing the subroutine will perform. It's just a sequence of Statements, wrapped up with the ENDSUB keyword.
🚨 Heads up: EXITs in a subroutine may not refer to labels outside it. The only way to leave a subroutine is via a RETURN statement.
3.5 CALL_statement 📞
---- CALL subname ( --+---------------------+-- ) ---->
| |
+--+-- parameter --+--+
| |
+----<--- , ----+
>---+-------------------------------------+--- ENDCALL ---- ;
| |
+---+--+-- n : --+--- Statement --+---+
| | | |
| +----<----+ |
| |
+--------------<--------------+the CALL statement invokes an SRL subroutine 🚀 The parameters are SRL variables or other RTFM attributes, and their types have to match the ones in the subroutine declaration. After the parameters comes a sequence of statements, each one kicked off by an integer label. These labels will normally be 1:, 2:, 3:, etc, but they don't have to be contiguous, and they don't have to be in any particular order. RETURN statements inside the subroutine body refer to them.
e.g.
RETURN 2; would return to the statement labelled 2:
within in the CALL statement.Running the labelled statement finishes off the CALL ✨
If the return statement doesn't name a return label, the first statement that runs after RETURN is the one right after ENDCALL 🧚
4 Example Programs 🎀
4.1 Classify IP Port Numbers 🌸
Let's look at a real program 🍓
#
# Classify IP port numbers
#
define IPv4 = 1; # Address Family number from [ASG-NBR]
#
define ftp = (20, 21); # Well-Known Port numbers from [ASG-NBR]
define telnet = 23;
define www = 80;
#
define tcp = 6; # Protocol numbers from [ASG-NBR]
define udp = 17;
#
if SourcePeerType == IPv4 save;
else ignore; # Not an IPv4 packet
#
if (SourceTransType == tcp || SourceTransType == udp) save, {
if SourceTransAddress == (www, ftp, telnet) nomatch;
# We want the well-known port as Dest
#
if DestTransAddress == telnet
save, store FlowKind := 'T';
else if DestTransAddress == www
save, store FlowKind := 'W';
else if DestTransAddress == ftp
save, store FlowKind := 'F';
else {
save DestTransAddress;
store FlowKind := '?';
}
}
else save SourceTransType = 0;
#
save SourcePeerAddress /32;
save DestPeerAddress /32;
count;
#this program only counts IP packets 🧠 It saves SourceTransType (tcp, udp or 0), Source- and DestPeerAddress (32-bit IP addresses) and FlowKind ('W' for www, 'F' for ftp, 'T' for telnet, '?' for unclassified). It uses a NOMATCH action to pin down the packet direction, so its flows end up with the well-known ports as their destination 💅
4.2 Classify Traffic into Groups of Networks 🦋
this one sorts traffic into network groups and it's so iconic 😭
#
# SRL program to classify traffic into network groups
#
define my_net = 130.216/16;
define k_nets = ( 130.217/16, 130.123/16, 130.195/16,
132.181/16, 138.75/16, 139.80/16 );
#
call net_kind (SourcePeerAddress, SourceKind)
endcall;
call net_kind (DestPeerAddress, DestKind)
endcall;
count;
#
subroutine net_kind (address addr, variable net)
if addr == my_net save, {
store net := 10; return 1;
}
else if addr == k_nets save, {
store net := 20; return 2;
}
save addr/24; # Not my_net or in k_nets
store net := 30; return 3;
endsub;
#the net_kind subroutine checks whether addr is my network (130.216), one of the Kawaihiko networks (in the k_nets list), or some other network 🌈 It saves the network address from addr (16 bits for my_net and the k_net networks, 24 bits for everything else), stores a value of 10, 20 or 30 in net, and returns to 1:, 2: or 3:. Also, the network numbers live inside the two DEFINEs, so they're super easy to change 🫶
net_kind gets called twice, saving Source- and DestPeerAddress and Source- and DestKind. The COUNT statement makes flows identified by those four RTFM attributes, with no particular source-dest ordering ✨
In this program nobody uses the return numbers, so they could've been left out. But we might want to reuse the subroutine in another program that does different things for different return numbers, like this version 👑
call net_kind (DestPeerAddress, DestKind)
1: nomatch; # We want my_net as source
endcall;
call net_kind (SourcePeerAddress, SourceKind)
1: count; # my_net -> other networks
endcall;
save SourcePeerAddress /24;
save DestPeerAddress /24;
count;this version uses a NOMATCH statement to make sure its flows have my_net as their source. The NOMATCH also rejects my_net -> my_net traffic 💀 Traffic that doesn't have my_net as source or destination saves 24 bits of its peer addresses (the subroutine might only have saved 16) before counting that unusual flow 🙈
5 Security Considerations 🔐
okay bestie, this part is SERIOUS 😭 SRL is a language for writing rulesets (basically configuration files) for RTFM Traffic Meters, and on its own it doesn't present any security issues.
BUT the flow data gathered using those rulesets can be super valuable 💎 So it's really important to take proper precautions to make sure access to the meter and its data is secure. The ways to do that are covered in detail in the Architecture and Meter MIB documents [RTFM-ARC, RTFM-MIB] 🛡️
6 IANA Considerations 📚
Appendix C below lists the RTFM attributes by name. SRL only refers to attributes by name, so SRL users never have to know the attribute numbers 🥰
The size (in bytes) of each attribute value is listed in Appendix C too. Those sizes match the object sizes for the attribute values as they're stored in the RTFM Meter MIB [RTFM-MIB] 💜
IANA considerations for allocating new attributes are discussed in detail in the RTFM Architecture document [RTFM-ARC] ✨
7 APPENDICES 🧚
7.1 Appendix A: SRL Syntax in BNF 💖
the whole SRL grammar, in BNF, is right here 🤓
<SRL program> ::= <S or D> | <SRL program> <S or D>
<S or D> ::= <statement> | <declaration>
<declaration> ::= <Subroutine declaration>
<statement> ::= <IF statement> |
<Compound statement> |
<Imperative statement> |
<CALL statement>
<IF statement> ::= IF <expression> <if action> <opt else>
<if action> ::= SAVE ; |
SAVE , <statement> |
<statement>
<opt else> ::= <null> |
ELSE <statement>
<expression> ::= <term> | <term> || <term>
<term> ::= <factor> | <factor> && <factor>
<factor> ::= <attribute> == <operand list> |
( <expression> )
<operand list> ::= <operand> | ( <actual operand list> )
<actual operand list> ::= <operand> |
<actual operand list> , <operand>
<operand> ::= <value> |
<value> / <width> |
<value> & <mask>
<Compound statement> ::= <opt label> { <statement seq> }
<opt label> ::= <null> |
<identifier> :
<statement seq> ::= <statement> | <statement seq> <statement>
<Imperative statement> ::= ; |
SAVE <attribute> <opt operand> ; |
COUNT ; |
EXIT <label> ; |
IGNORE ; |
NOMATCH ; |
RETURN <integer> ; |
RETURN ; |
STORE <variable> := <value> ;
<opt operand> ::= <null> |
<width or mask> |
= <operand>
<width or mask> ::= / <width> | & <mask>
<Subroutine declaration> ::=
SUBROUTINE <sub header> <sub body> ENDSUB ;
<sub header> ::= <subname> ( ) |
<subname> ( <sub param list> )
<sub param list> ::= <sub param> | <sub param list> , <sub param>
<sub param> ::= ADDRESS <pname> | VARIABLE <pname>
<pname> ::= <identifier>
<sub body> ::= <statement sequence>
<CALL statement> ::= CALL <call header> <opt call body> ENDCALL ;
<call header> ::= <subname> ( ) |
<subname> ( <call param list> )
<call param list> ::= <call param> |
<call param list> , <call param>
<call param> ::= <attribute> | <variable>
<opt call body> ::= <null> |
<actual call body>
<actual call body> ::= <numbered statement> |
<actual call body> <numbered statement>
<numbered statement> ::= <int label seq> <statement>
<int label seq> ::= <integer> : | <int label seq> <integer> :the following are the terminals, which the scanner recognises 🔍
<identifier> Described in section 2
<integer> A decimal integer
<attribute> Attribute name, as listed in Appendix C
<value>, <mask> Described in section 5.2
<width> ::= <integer>
<label> ::= <identifier>
<variable> ::= SourceClass | DestClass | FlowClass |
SourceKind | DestKind | FlowKind7.2. Appendix B: Syntax for Values and Masks ✨
Okay bestie, values and masks are built out of numeric fields, and each field is one or more bytes 🧚. The non-blank character right after a field tells you two things: how wide the field is, and whether the number is decimal or hex. These "field type" characters are:
. period decimal, single byte
- minus hex, single byte
! exclaim decimal, two bytesSo 130.216.0.0 is an IP address in dotted decimal 🌸, and FF-FF-00-00 is an IP address in hex 💅.
The last field doesn't get a field width character. It just takes the same width as the field before it 🎀. That's why 1.3.10!50 and 1.3.0.10.0.50 are two totally different ways of writing the same value 👑.
Unspecified fields (the ones on the right-hand side of a value or mask) are set to zero, so 130.216 is the same as 130.216.0.0 🫶.
If you only give one field and no width character, the value fills the whole field. That means 23 and 0.23 give you the same value for a SourceTransAddress operand 💖. For variables (which have one-byte values), a C-style character constant can also be used ✨.
IPv6 addresses and masks work too, following the conventions from the IP Version 6 Addressing Architecture RFC [V6-ADR] 🦋.
7.3. Appendix C: RTFM Attribute Information 💜
Okay this part is basically the cheat sheet 📋. These attributes can be tested in an IF statement, and their values can be SAVEd (except for MatchingStoD). The max size of each one (in bytes) is the number on the left, with a quick description next to it. The names here are reserved words in SRL, and they're the <attribute> terminals in the grammar from Appendix A 🔥.
Heads up, this table is only a super brief summary 🙈. The Meter MIB [RTFM-MIB] is the real source of truth for attributes and their allowed values. The MIB variables for flow attributes get flowData stuck on the front of their names, so you know they live in the MIB's flowData table.
1 SourceInterface, DestInterface
Interface(s) on which the flow was observed
1 SourceAdjacentType, DestAdjacentType
Indicates the interface type(s), i.e. an ifType from [ASG-NBR],
or an Address Family Number (if metering within a tunnel)
0 SourceAdjacentAddress, DestAdjacentAddress
For IEEE 802.x interfaces, the MAC addresses for the flow
1 SourcePeerType, DestPeerType
Peer protocol types, i.e. Address Family Number from [ASG-NBR],
such as IPv4, Novell, Ethertalk, ..
0 SourcePeerAddress, DestPeerAddress
Peer Addresses (size varies, e.g. 4 for IPv4, 3 for Ethertalk))
1 SourceTransType, DestTransType
Transport layer type, i.e. Protocol Number from [ASG-NBR]
such as tcp(6), udp(17), ospf(89), ..
2 SourceTransAddress, DestTransAddress
Transport layer addresses (e.g. port numbers for TCP and UDP)
1 FlowRuleset
Rule set number for the flow
1 MatchingStoD
Indicates whether the packet is being matched with its
addresses in 'wire order.' See [RTFM-ARC] for details.Next up, the variables you can test in an IF, and whose values can be set by a STORE. They all have one-byte values 🍓:
SourceClass, DestClass, FlowClass,
SourceKind, DestKind, FlowKindThese RTFM attributes aren't address attributes, they're measured attributes of a flow 📈. You read their values from an RTFM meter. (For example, NeTraMet uses a FORMAT statement to pick which attribute values get read from the meter 🧁.)
8 ToOctets, FromOctets
Total number of octets seen for each direction of the flow
8 ToPDUs, FromPDUs
Total number of PDUs seen for each direction of the flow
4 FirstTime, LastActiveTime
Time (in centiseconds) that first and last PDUs were seen
for the flowOther attributes will be defined by the RTFM working group from time to time 🌷.
8. Acknowledgments 🫶
The SRL language is part of the RTFM Working Group's efforts to make the RTFM traffic measurement system easier to use 🦋. Cyndi Mills and Brad Frazee in Boston did the initial work on the language 💜. SRL was developed in Auckland, and it got a lot of help from detailed discussions with John White and Russell Fulton 👑. The conversation kept going on the RTFM and NeTraMet mailing lists 💖.
9. References 📚
[ASG-NBR] Reynolds, J. and J. Postel, "Assigned Numbers",
STD 2, RFC 1700, October 1994.
[NETRAMET] Brownlee, N., NeTraMet home page,
http://www.auckland.ac.nz/net/NeTraMet
[RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
Measurement: Architecture", RFC 2722, October 1999.
[RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB",
RFC 2720, October 1999.
[V6-ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture," RFC 2373, July 1998.10. Author's Address 🖊️
Nevil Brownlee
Information Technology Systems & Services
The University of Auckland
Private Bag 92-019
Auckland, New Zealand
Phone: +64 9 373 7599 x8941
EMail: n.brownlee@auckland.ac.nz11. Full Copyright Statement 🌈
Okay, the legal bit. Copyright stuff is serious, so here it is in full 💅.
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society 💜.
📦 where this page comes from
- ietf: rfc2723 1999-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms