idnits 2.17.1 draft-ietf-rtfm-ruleset-language-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 94 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 326 has weird spacing: '...decimal e.g. ...' == Line 328 has weird spacing: '...in bits e.g....' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 1999) is 9233 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 834 looks like a reference -- Missing reference section? '2' on line 839 looks like a reference -- Missing reference section? '3' on line 842 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Nevil Brownlee 2 INTERNET-DRAFT The University of Auckland 3 July 1998 4 Expires January 1999 6 SRL: A Language for Describing Traffic Flows 7 and Specifying Actions for Flow Groups 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, and 15 its Working Groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. This Internet Draft is a product of the 17 Realtime Traffic Flow Measurement Working Group of the IETF. 19 Internet Drafts are draft documents valid for a maximum of six months. 20 Internet Drafts may be updated, replaced, or obsoleted by other 21 documents at any time. It is not appropriate to use Internet Drafts as 22 reference material or to cite them other than as a "working draft" or 23 "work in progress." 25 To view the entire list of current Internet-Drafts, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 28 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 29 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 Abstract 33 This document describes a language for specifying rulesets, i.e. 34 configuration files which may be loaded into a traffic flow meter so as 35 to specify which traffic flows are measured by the meter, and the 36 information it will store for each flow. Although the language is 37 primarily intended for RTFM traffic flows, it should also be useful in 38 other areas as a general way of specifying flows to be measured or 39 collected. 41 Contents 43 1 Purpose and Scope 3 44 1.1 RTFM Meters and Traffic Flows . . . . . . . . . . . . . . . . 3 45 1.2 SRL Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 2 SRL Language Description 5 48 2.1 Define Directive . . . . . . . . . . . . . . . . . . . . . . . 5 49 2.2 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 50 2.3 Declaration . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 3 Statement 6 53 3.1 IF_statement . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 3.1.1 expression . . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.1.2 term . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 3.1.3 factor . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1.4 operand_list . . . . . . . . . . . . . . . . . . . . . . . 8 58 3.1.5 operand . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 3.1.6 Test Part . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1.7 Action Part . . . . . . . . . . . . . . . . . . . . . . . 9 61 3.1.8 Else Clause . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.2 Compound_statement . . . . . . . . . . . . . . . . . . . . . . 10 65 3.3 Imperative_statement . . . . . . . . . . . . . . . . . . . . . 10 66 3.3.1 SAVE Statement . . . . . . . . . . . . . . . . . . . . . . 11 67 3.3.2 COUNT Statement . . . . . . . . . . . . . . . . . . . . . 11 68 3.3.3 EXIT Statement . . . . . . . . . . . . . . . . . . . . . . 11 69 3.3.4 IGNORE Statement . . . . . . . . . . . . . . . . . . . . . 12 70 3.3.5 NOMATCH Statement . . . . . . . . . . . . . . . . . . . . 12 71 3.3.6 STORE Statement . . . . . . . . . . . . . . . . . . . . . 12 72 3.3.7 RETURN Statement . . . . . . . . . . . . . . . . . . . . . 12 74 3.4 Subroutine_declaration . . . . . . . . . . . . . . . . . . . . 13 75 3.5 CALL_statement . . . . . . . . . . . . . . . . . . . . . . . . 13 77 4 Example Programs 14 78 4.1 Classify IP Port Numbers . . . . . . . . . . . . . . . . . . . 14 79 4.2 Classify Traffic into Groups of Networks . . . . . . . . . . . 15 81 5 APPENDICES 16 82 5.1 Appendix A: SRL Syntax in BNF . . . . . . . . . . . . . . . . 16 83 5.2 Appendix B: Syntax for Values and Masks . . . . . . . . . . . 18 84 5.3 Appendix C: RTFM Attribute Information . . . . . . . . . . . . 18 86 6 Acknowledgments 20 88 7 References 20 90 8 Author's Addresses 20 92 1 Purpose and Scope 94 A ruleset for an RTFM Meter is a sequence of instructions to be executed 95 by the meter's Pattern Matching Engine (PME). The form of these 96 instructions is described in detail in RFCs 2063 and 2064 [1], [2], but 97 most users - at least inititially - find them confusing and difficult to 98 write, mainly because the effect of each instruction is strongly 99 dependent on the state of the meter's Packet Matching Engine at the 100 moment of its execution. 102 SRL is a procedural language for creating RTFM rulesets. It has been 103 designed to be simple for people to understand, using statements which 104 help to clarify the execution context in which they operate. SRL 105 programs will be compiled into rulesets, which can then be downloaded to 106 RTFM meters. 108 An SRL compiler is available as part of NeTraMet (a free-software 109 implementation of the RTFM meter and manager), version 4.2 [3]. 111 1.1 RTFM Meters and Traffic Flows 113 The RTFM Architecture [1] defines a set of 'attributes' which apply to 114 network traffic. Among the attributes are 'address attributes,' such as 115 PeerType, PeerAddress, TransType and TransAddress, which have meaning 116 for many protocols, e.g. for IP traffic (PeerType == IP) PeerAddress is 117 an IP address, TransType is TCP, UDP, ICMP, etc., and TransAddress is 118 usually an IP port number. 120 An 'RTFM Traffic Flow' is simply a stream of packets observed by a meter 121 as they pass across a network between two end points (or from a single 122 end point). Each 'end point' of a flow is determined by the set of 123 values of its address attributes. 125 An 'RTFM Meter' is a measuring device - e.g. a program running on a 126 Unix or PC host - which observes passing packets and builds 'Flow Data 127 Records' for the flows of interest. 129 RTFM traffic flows have another important property - they are 130 bi-directional. This means that each flow data record in the meter has 131 two sets of counters, one for packets travelling from source to 132 destination, the other for returning packets. Within the RTFM 133 architecture such counters appear as further attributes of the flow. 135 An RTFM meter must be configured by the user, which means creating a 136 'Ruleset' so as to specify which flows are to be measured, and how much 137 information (i.e. which attributes) should be stored for each of them. 139 A ruleset is effectively a program for a minimal virtual machine, the 140 'Packet Matching Engine (PME),' which is described in detail in [1]. An 141 RTFM meter may run multiple rule sets, with every passing packet being 142 processed by each of the rulesets. The rule 'actions' in this document 143 are described as though only a single ruleset were running. 145 In the past creating a ruleset has meant writing machine code for the 146 PME, which has proved rather difficult to do. SRL provides a high-level 147 language which should enable users to create effective rulesets without 148 having to understand the details of the PME. 150 The language could easily be adapted to other uses, being suitable for 151 any application area which involves selecting traffic flows from a 152 stream of packets. 154 1.2 SRL Overview 156 An SRL program is executed from the beginning for each new packet 157 arriving at the meter. It has two essential goals. 159 (a) Decide whether the current packet is part of a flow which is of 160 interest and, if necessary, determine its direction (i.e. decide 161 which of its end-points is considered to be its source). Other 162 packets will be ignored. 164 (b) SAVE whatever information is required to identify the flow and 165 accumulate (COUNT) quantitative information for that flow. 167 At execution, the meter's Packet Matching Engine (PME) begins by using 168 source and destination attributes as they appear 'on the wire.' If the 169 attributes do not match those of a flow to be recorded, the PME will 170 normally execute the program again, this time with the source and 171 destination addresses interchanged. Because of this bi-directional 172 matching, an RTFM meter is able to build up tables of flows with two 173 sets of counters - one for forward packets, the other for backward 174 packets. The programmer can, if required, suppress the 175 reverse-direction matching and assign 'forward' and 'backward' 176 directions which conform to the conventions of the external context. 178 Goal (a) is achieved using IF statements which perform comparisons on 179 information from the packet or from SRL variables. Goal (b) is achieved 180 using one or more SAVE statements to store the flow's identification 181 attributes; a COUNT statement then increments the statistical data 182 accumulating for it. 184 2 SRL Language Description 186 The SRL language is explained below using 'railway diagrams' to describe 187 the syntax. Flow through a diagram is from left to right. The only 188 exception to this is that lines carrying a left arrow may only be 189 traversed right to left. In the diagrams, keywords are written in 190 capital letters; in practice an SRL compiler will be insensitive to 191 case. Lower-case identifiers are explained in the text, or they refer 192 to another diagram. 194 The tokens of an SRL program obey the following rules: 196 - Comments may appear on any line of an SRL program, following a # 197 - White space is used to separate tokens 198 - Semicolon is used as the terminator for most statements 199 - Identifiers (e.g. for defines and labels) must start with a letter 200 - Identifiers may contain letters, digits and underscores 201 - The case of letters is not significant 203 2.1 Define Directive 205 --- DEFINE -- defname ---- = ---- defined_text ------------------ ; 207 Simple parameterless defines are supported via the syntax above. The 208 define name, defname, is an identifier made up of letters, digits and 209 underscores. The defined text starts after the equal sign, and 210 continues up to (but not including) the closing semicolon. (If a 211 semicolon is required within define text, it must be preceded by a 212 backslash). Wherever defname appears elsewhere in the program, it will 213 be replaced by the defined text. 215 For example, 217 DEFINE telnet = 23; 218 DEFINE smtp = 25; 219 DEFINE http = (80, 8080); 221 2.2 Program 223 ------------+-------+-------- Statement -------+-------+----------- 224 | | | | 225 | +------- Declaration ------+ | 226 | | 227 +---------------------<--------------------+ 229 An SRL program is a sequence of statements or declarations. It does not 230 have any special enclosing symbols. Statements and declarations 231 terminate with a semicolon, except for Compound statements, which 232 terminate with a right brace. 234 2.3 Declaration 236 ---------------------- Subroutine_declaration --------------------- 238 SRL's only explicit declaration is the subroutine declaration. Other 239 implicit declarations are labels (declared where they appear in front of 240 a statement) and subroutine parameters (declared in the subroutine 241 header). 243 3 Statement 245 ----------------+---- IF_statement ----------------+--------------- 246 | | 247 +---- Compound_statement ----------+ 248 | | 249 +---- Imperative_statement --------+ 250 | | 251 +---- CALL_statement --------------+ 253 An SRL program is a sequence of SRL statements, generally terminated by 254 a semicolon. There are four kinds of statements, as follows. 256 3.1 IF_statement 258 Test Part Action Part 259 ............. ............... 261 --- IF --- expression ---+------------+---- Statement ----+---> 262 | | | 263 +-- SAVE , --+ | 264 | | 265 +-- SAVE ; ----------------------+ 267 >-----------+-----------------------------+----------------- 268 | | 269 +-----ELSE --- Statement -----+ 271 3.1.1 expression 273 -------- term --------+------------------------+------------------- 274 | | 275 +--<-- term ----- || ----+ logical OR 277 3.1.2 term 279 ------- factor -------+------------------------+------------------- 280 | | 281 +--<-- factor --- && ----+ logical AND 283 3.1.3 factor 285 ------------+-------- attrib == operand_list --------+----------- 286 | | 287 +------------ ( expression ) --------------+ 289 3.1.4 operand_list 291 ------------+-------------- operand -----------------+------------- 292 | | 293 +--- ( operand--+---------------+-- ) ---+ 294 | | 295 +-- , operand --+ 296 | | 297 +-------<-------+ 299 3.1.5 operand 301 ------------- value ---------+----------------------+-------------- 302 | | 303 +------- / width ------+ 304 | | 305 +------- & mask -------+ 307 3.1.6 Test Part 309 The IF statement evaluates a logical expression. If the expression 310 value is TRUE, the action indicated in the 'Action Part' of the diagram 311 is executed. If the value is FALSE, the statement after the IF is 312 executed. 314 The simplest form of expression is a test for equality (== operator); in 315 this an RTFM attribute value (from the packet or from an SRL variable) 316 is ANDed with a mask and compared with a value. A list of RTFM 317 attributes is given in Appendix C. More complicated expressions may be 318 built up using parentheses and the && (logical AND) and || (logical OR) 319 operators. 321 Operand values may be specified as dotted decimal,hexadecimal or as a 322 character constant (enclosed in apostrophes). The syntax for operand 323 values is given in Appendix B. 325 Masks may be specified as numbers, 326 dotted decimal e.g. &255.255 327 or hexadecimal e.g. &FF-FF 328 or as a width in bits e.g. /16 330 If a mask is not specified, an all-ones mask is used. 332 In SRL a value is always combined with a mask; this combination is 333 referred to as an operand. For example, if we were interested in flows 334 originating from IP network 130.216, we might write: 336 IF SourcePeerAddress == 130.216.0.0 & 255.255.0.0 IGNORE; 338 or equivalently 340 IF SourcePeerAddress == 130.216/16 IGNORE; 342 A list of values enclosed in parentheses may also be specified; the test 343 succeeds if the masked attribute equals any of the values in the list. 344 For example 346 IF SourcePeerAddress == ( 130.216.7/24, 130.216.34/24 ) SAVE; 348 As this last example indicates, values are right-padded with zeroes, 349 i.e. the given numbers specify the leading bytes of masks and values. 351 The operand values and masks used in an IF statement must be consistent 352 with the attribute being tested. For example, a four-byte value is 353 acceptable as a peer address, but would not be accepted as a transport 354 address (which may not be longer than two bytes). 356 3.1.7 Action Part 358 A SAVE action (i.e. SAVE , or SAVE ;) saves attribute(s), mask(s) and 359 value(s) as given in the statement. If the IF expression tests more 360 than one attribute, the masks and values are saved for all the 361 attributes. For each value_list in the statement the value saved is the 362 one which the packet actually matched. See below for further 363 description of SAVE statements. 365 Other actions are described in detail under "Imperative statements" 366 below. Note that the RETURN action is valid only within subroutines. 368 3.1.8 Else Clause 370 An Else Clause provides a statement which will be executed if the IF's 371 test fails. The statement following ELSE will often be another IF 372 statement, providing SRL's version of a 'select' statement. Note that 373 an ELSE clause always matches the immediately preceding IF. 375 3.2 Compound_statement 377 -------+-------------+----- { ---+---- Statement ----+--- } ------- 378 | | | | 379 +-- label : --+ +--------<----------+ 381 A compound statement is a sequence of statements enclosed in braces. 382 Each statement will terminate with a semicolon, unless it is another 383 compound statement (which terminates with a right brace). 385 A compound statement may be labelled, i.e. preceded by an identifier 386 followed by a semi-colon. Each statement inside the braces is executed 387 in sequence unless an EXIT statement is performed, as explained below. 389 Labels have a well-defined scope, within which they must be unique. 390 Labels within a subroutine (i.e. between a SUBROUTINE and its matching 391 ENDSUB) are local to that subroutine and are not visible outside it. 392 Labels outside subroutines are part of a program's outer block. 394 3.3 Imperative_statement 396 ------+---------------------------------------------------+------ ; 397 | | 398 +-- SAVE attrib --+--+-----------+--+---------------+ 399 | | | | | | 400 | | +- / width -+ | | 401 | | | | | | 402 | | +- & mask --+ | | 403 | | | | 404 | +--- = operand ---+ | 405 | | 406 +-- COUNT ------------------------------------------+ 407 | | 408 +-- EXIT label ------------------------------------+ 409 | | 410 +-- IGNORE -----------------------------------------+ 411 | | 412 +-- NOMATCH ----------------------------------------+ 413 | | 414 +-- RETURN --+-------+------------------------------+ 415 | | | | 416 | +-- n --+ | 417 | | 418 +-- STORE variable := value ------------------------+ 420 3.3.1 SAVE Statement 422 The SAVE statement saves information which will (later) identify the 423 flow in the meter's flow table. It does not actually record anything in 424 the table; this is done when a subsequent COUNT statement executes. 426 SAVE has two possible forms: 428 SAVE attrib = operand ; 429 saves the attribute, mask and value as given in the statement. 430 This form of the SAVE statement is similar to that allowed 431 in an IF statement, except that - since imperative statements 432 do not perform a test - you may save an arbitrary value. 434 SAVE attrib ; 435 SAVE attrib / width ; 436 SAVE attrib & mask ; 437 saves the attribute and mask from the statement, and the 438 value resulting from their application to the current packet. 439 This is most useful when used to save a value with a wider 440 mask than than was used to select the packet. For example 442 IF DestPeerAddress == 130.216/16 443 NOMATCH; 444 ELSE IF SourcePeerAddress == 130.216/16 { 445 SAVE SourcePeerAddress /24; 446 COUNT; 447 } 448 ELSE IGNORE; 450 3.3.2 COUNT Statement 452 The COUNT statement appears after all testing and saving is complete; it 453 instructs the PME to build the flow identifier from the attributes which 454 have been SAVEd, find it in the meter's flow table (creating a new entry 455 if this is the first packet observed for the flow), and increment its 456 counters. The meter then moves on to examine the next incoming packet. 458 3.3.3 EXIT Statement 460 The EXIT statement exits a labelled compound statement. The next 461 statement to be executed will be the one following that compound 462 statement. This provides a well-defined way to jump to a clearly 463 identified point in a program. 465 3.3.4 IGNORE Statement 467 The IGNORE statement terminates examination of the current packet 468 without saving any information from it; the meter moves on to examine 469 the next incoming packet, beginning again at the first statement of its 470 program. 472 3.3.5 NOMATCH Statement 474 The NOMATCH statement indicates that matching has failed for this 475 execution of the program. If it is executed when a packet is being 476 processed with its addresses in 'on the wire' order, the PME will 477 perform the program again from the beginning with source and destination 478 addresses interchanged. If it is executed following such an 479 interchange, the packet will be IGNOREd. NOMATCH is illustrated in the 480 above example, where it is used to ensure that flows having 130.216/16 481 as an end-point are counted as though 130.216 had been those flows' 482 source peer (IP) address. 484 3.3.6 STORE Statement 486 The STORE statement assigns a value to an SRL variable and SAVEs it. 487 There are six SRL variables: 489 SourceClass SourceKind 490 DestClass DestKind 491 FlowClass FlowKind 493 Their names have no particular significance; they were arbitrarily 494 chosen as likely RTFM attributes but can be used to store any 495 single-byte integer values. Their values are set to zero each time 496 examination of a new packet begins. 498 3.3.7 RETURN Statement 500 The RETURN statement is used to return from subroutines and can be used 501 only within the context of a subroutine. It is described in detail 502 below (CALL statement). 504 3.4 Subroutine_declaration 506 --- SUBROUTINE subname ( ---+---ADDRESS ----pname---+--- ) ---> 507 | | 508 +-- VARIABLE -- pname --+ 509 | | 510 +------<------- , ------+ 512 >------+-------- Statement ---------+----- ENDSUB -------- ; 513 | | 514 +-------------<--------------+ 516 A Subroutine declaration has three parts: 518 the subname is an indentifier, used to name the subroutine. 520 the parameter list specifies the subroutine's parameters. 521 Each parameter is preceded with a keyword indicating its 522 type - VARIABLE indicates an SRL variable (see the STORE 523 statement above), ADDRESS indicates any other RTFM attribute. 524 A parameter name may be any identifier, and its scope is 525 limited to the subroutine's body. 527 the body specifies what processing the subroutine will perform. 528 This is simply a sequence of Statements, terminated by the 529 ENDSUB keyword. 531 Note that EXITs in a subroutine may not refer to labels outside it. The 532 only way to leave a subroutine is via a RETURN statement. 534 3.5 CALL_statement 536 ---- CALL subname ( ---+-- parameter --+--- ) ----> 537 | | 538 +---<---- , ----+ 540 >-----+---+-- n : --+---- Statement ----+---- ENDCALL ----- ; 541 | | | | 542 | +----<----+ | 543 | | 544 +----------------<----------------+ 546 The CALL statement invokes an SRL subroutine. The parameters are SRL 547 variables or other RTFM attributes, and their types must match those in 548 the subroutine declaration. Following the parameters is a sequence of 549 statements, each preceded by an integer label. These labels will 550 normally be 1:, 2:, 3:, etc, but they do not have to be contiguous, nor 551 in any particular order. They are referred to in RETURN statements. 553 e.g. RETURN 2; would return to the statement labelled 2: 554 in the subroutine call. 556 If the return statement does not specify a return label, the first 557 statement executed after RETURN will be the statement immediately 558 following ENDCALL. 560 4 Example Programs 562 4.1 Classify IP Port Numbers 564 # 565 # Classify IP port numbers 566 # 567 if SourcePeerType == IP save; 568 else ignore; # Not an IP packet 569 # 570 if SourceTransAddress == (www, ftp, telnet) nomatch; 571 # We want the well-known port as Dest 572 # 573 if DestTransAddress == telnet 574 save, store FlowKind := 'T'; 575 else if DestTransAddress == www 576 save, store FlowKind := 'W'; 577 else if DestTransAddress == ftp 578 save, store FlowKind := 'F'; 579 else { 580 save DestTransAddress; 581 store FlowKind := '?'; 582 } 583 save SourcePeerAddress /32; 584 save DestPeerAddress /32; 585 count; 586 # 587 This program counts only IP packets, saving SourceTransType (tcp, udp or 588 0), Source- and DestPeerAddress (32-bit IP addresses) and FlowKind ('W' 589 for www, 'F' for ftp, 'T' for telnet, '?' for unclassified). The 590 program uses a NOMATCH action to specify the packet direction - its 591 resulting flows will have the well-known ports as their destination. 593 4.2 Classify Traffic into Groups of Networks 595 # 596 # SRL program to classify traffic into network groups 597 # 598 define my_net = 130.216/16; 599 define k_nets = ( 130.217/16, 130.123/16, 130.195/16, 600 132.181/16, 138.75/16, 139.80/16 ); 601 # 602 call net_kind (SourcePeerAddress, SourceKind) 603 endcall; 604 call net_kind (DestPeerAddress, DestKind) 605 endcall; 606 count; 607 # 608 subroutine net_kind (address addr, variable net) 609 if addr == my_net save, { 610 store net := 10; return 1; 611 } 612 else if addr == k_nets save, { 613 store net := 20; return 2; 614 } 615 save addr/24; # Not my_net or in k_nets 616 store net := 30; return 3; 617 endsub; 618 # 620 The net_kind subroutine determines whether addr is my network (130.216), 621 one of the Kawaihiko networks (in the k_nets list), or some other 622 network. It saves the network address from addr (16 bits for my_net and 623 the k_net networks, 24 bits for others), stores a value of 10, 20 or 30 624 in net, and returns to 1:, 2: or 3:. Note that the network numbers 625 used are contained within the two DEFINEs, making them easy to change. 627 net_kind is called twice, saving Source- and DestPeerAddress and Source- 628 and DestKind; the COUNT statement produces flows identified by these 629 four RTFM attributes, with no particular source-dest ordering. 631 In the program no use is made of return numbers amd they could have been 632 omitted. However, we might wish to re-use the subroutine in another 633 program doing different things for different return numbers, as in the 634 version below. 636 call net_kind (DestPeerAddress, DestKind) 637 1: nomatch; # We want my_net as source 638 endcall; 639 call net_kind (SourcePeerAddress, SourceKind) 640 1: count; # my_net -> other networks 641 endcall; 642 save SourcePeerAddress /24; # 643 save DestPeerAddress /24; 644 count; 646 This version uses a NOMATCH statement to ensure that its resulting flows 647 have my_net as their source. The NOMATCH also rejects my_net -> my_ 648 traffic. Traffic which doesn't have my_net as source or destination 649 saves 24 bits of its peer addresses (the subroutine might only have 650 saved 16) before counting such an unusual flow. 652 5 APPENDICES 654 5.1 Appendix A: SRL Syntax in BNF 656 ::= | 658 ::= | 660 ::= 662 ::= | 663 | 664 | 665 667 ::= IF 669 ::= SAVE ; | 670 SAVE , | 671 673 ::= | 674 ELSE 676 ::= | || 677 ::= | && 679 ::= == | ( ) 681 ::= | ( ) 683 ::= | 684 , 686 ::= | 687 / | 688 & 690 ::= { } 692 ::= | 693 : 695 ::= | 697 ::= ; | 698 SAVE ; | 699 COUNT ; | 700 EXIT