idnits 2.17.1 draft-ietf-rtfm-ruleset-language-03.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-23) 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 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 325 has weird spacing: '...decimal e.g. ...' == Line 327 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 (March 1999) is 9171 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 848 looks like a reference -- Missing reference section? '2' on line 853 looks like a reference -- Missing reference section? '3' on line 856 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Nevil Brownlee 3 INTERNET-DRAFT The University of Auckland 4 September 1998 5 Expires March 1999 7 SRL: A Language for Describing Traffic Flows 8 and Specifying Actions for Flow Groups 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, and 16 its Working Groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. This Internet Draft is a product of the 18 Realtime Traffic Flow Measurement Working Group of the IETF. 20 Internet Drafts are draft documents valid for a maximum of six months. 21 Internet Drafts may be updated, replaced, or obsoleted by other 22 documents at any time. It is not appropriate to use Internet Drafts as 23 reference material or to cite them other than as a "working draft" or 24 "work in progress." 26 To view the entire list of current Internet-Drafts, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 29 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 30 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 32 Abstract 34 This document describes a language for specifying rulesets, i.e. 35 configuration files which may be loaded into a traffic flow meter so as 36 to specify which traffic flows are measured by the meter, and the 37 information it will store for each flow. Although the language is 38 primarily intended for RTFM traffic flows, it should also be useful in 39 other areas as a general way of specifying flows to be measured or 40 collected. 42 Contents 44 1 Purpose and Scope 3 45 1.1 RTFM Meters and Traffic Flows . . . . . . . . . . . . . . . . 3 46 1.2 SRL Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 2 SRL Language Description 5 49 2.1 Define Directive . . . . . . . . . . . . . . . . . . . . . . . 5 50 2.2 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 2.3 Declaration . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 3 Statement 6 54 3.1 IF_statement . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.1.1expression . . . . . . . . . . . . . . . . . . . . . . . . 7 56 3.1.2term . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1.3factor . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.1.4operand_list . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.1.5operand . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1.6Test Part . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1.7Action Part . . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.1.8ELSE Clause . . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.2 Compound_statement . . . . . . . . . . . . . . . . . . . . . . 9 64 3.3 Imperative_statement . . . . . . . . . . . . . . . . . . . . . 10 65 3.3.1SAVE Statement . . . . . . . . . . . . . . . . . . . . . . 10 66 3.3.2COUNT Statement . . . . . . . . . . . . . . . . . . . . . . 11 67 3.3.3EXIT Statement . . . . . . . . . . . . . . . . . . . . . . 11 68 3.3.4IGNORE Statement . . . . . . . . . . . . . . . . . . . . . 11 69 3.3.5NOMATCH Statement . . . . . . . . . . . . . . . . . . . . . 12 70 3.3.6STORE Statement . . . . . . . . . . . . . . . . . . . . . . 12 71 3.3.7RETURN Statement . . . . . . . . . . . . . . . . . . . . . 12 72 3.4 Subroutine_declaration . . . . . . . . . . . . . . . . . . . . 12 73 3.5 CALL_statement . . . . . . . . . . . . . . . . . . . . . . . . 13 75 4 Example Programs 14 76 4.1 Classify IP Port Numbers . . . . . . . . . . . . . . . . . . . 14 77 4.2 Classify Traffic into Groups of Networks . . . . . . . . . . . 15 79 5 APPENDICES 16 80 5.1 Appendix A: SRL Syntax in BNF . . . . . . . . . . . . . . . . 16 81 5.2 Appendix B: Syntax for Values and Masks . . . . . . . . . . . 18 82 5.3 Appendix C: RTFM Attribute Information . . . . . . . . . . . . 19 84 6 Acknowledgments 20 86 7 References 20 88 8 Author's Address 20 90 1 Purpose and Scope 92 A ruleset for an RTFM Meter is a sequence of instructions to be executed 93 by the meter's Pattern Matching Engine (PME). The form of these 94 instructions is described in detail in the 'RTFM Architecture' and 'RTFM 95 Meter MIB' documents [1], [2], but most users - at least inititially - 96 find them confusing and difficult to write, mainly because the effect of 97 each instruction is strongly dependent on the state of the meter's 98 Packet Matching Engine at the moment of its execution. 100 SRL is a procedural language for creating RTFM rulesets. It has been 101 designed to be simple for people to understand, using statements which 102 help to clarify the execution context in which they operate. SRL 103 programs will be compiled into rulesets which can then be downloaded to 104 RTFM meters. 106 An SRL compiler is available as part of NeTraMet (a free-software 107 implementation of the RTFM meter and manager), version 4.2 [3]. 109 1.1 RTFM Meters and Traffic Flows 111 The RTFM Architecture [1] defines a set of 'attributes' which apply to 112 network traffic. Among the attributes are 'address attributes,' such as 113 PeerType, PeerAddress, TransType and TransAddress, which have meaning 114 for many protocols, e.g. for IP traffic (PeerType == IP) PeerAddress is 115 an IP address, TransType is TCP, UDP, ICMP, etc., and TransAddress is 116 usually an IP port number. 118 An 'RTFM Traffic Flow' is simply a stream of packets observed by a meter 119 as they pass across a network between two end points (or to/from a 120 single end point). Each 'end point' of a flow is specified by the set 121 of values of its address attributes. 123 An 'RTFM Meter' is a measuring device - e.g. a program running on a 124 Unix or PC host - which observes passing packets and builds 'Flow Data 125 Records' for the flows of interest. 127 RTFM traffic flows have another important property - they are 128 bi-directional. This means that each flow data record in the meter has 129 two sets of counters, one for packets travelling from source to 130 destination, the other for returning packets. Within the RTFM 131 architecture such counters appear as further attributes of the flow. 133 An RTFM meter must be configured by the user, which means creating a 134 'Ruleset' so as to specify which flows are to be measured, and how much 135 information (i.e. which attributes) should be stored for each of them. 136 A ruleset is effectively a program for a minimal virtual machine, the 137 'Packet Matching Engine (PME),' which is described in detail in [1]. An 138 RTFM meter may run multiple rule sets, with every passing packet being 139 processed by each of the rulesets. The rule 'actions' in this document 140 are described as though only a single ruleset were running. 142 In the past creating a ruleset has meant writing machine code for the 143 PME, which has proved rather difficult to do. SRL provides a high-level 144 language which should enable users to create effective rulesets without 145 having to understand the details of the PME. 147 The language could easily be adapted to other uses, being suitable for 148 any application area which involves selecting traffic flows from a 149 stream of packets. 151 1.2 SRL Overview 153 An SRL program is executed from the beginning for each new packet 154 arriving at the meter. It has two essential goals. 156 (a) Decide whether the current packet is part of a flow which is of 157 interest and, if necessary, determine its direction (i.e. decide 158 which of its end-points is considered to be its source). Other 159 packets will be ignored. 161 (b) SAVE whatever information is required to identify the flow and 162 accumulate (COUNT) quantitative information for that flow. 164 At execution, the meter's Packet Matching Engine (PME) begins by using 165 source and destination attributes as they appear 'on the wire.' If the 166 attributes do not match those of a flow to be recorded, the PME will 167 normally execute the program again, this time with the source and 168 destination addresses interchanged. Because of this bi-directional 169 matching, an RTFM meter is able to build up tables of flows with two 170 sets of counters - one for forward packets, the other for backward 171 packets. The programmer can, if required, suppress the 172 reverse-direction matching and assign 'forward' and 'backward' 173 directions which conform to the conventions of the external context. 175 Goal (a) is achieved using IF statements which perform comparisons on 176 information from the packet or from SRL variables. Goal (b) is achieved 177 using one or more SAVE statements to store the flow's identification 178 attributes; a COUNT statement then increments the statistical data 179 accumulating for it. 181 2 SRL Language Description 183 The SRL language is explained below using 'railway diagrams' to describe 184 the syntax. Flow through a diagram is from left to right. The only 185 exception to this is that lines carrying a left arrow may only be 186 traversed right to left. In the diagrams, keywords are written in 187 capital letters; in practice an SRL compiler will be insensitive to 188 case. Lower-case identifiers are explained in the text, or they refer 189 to another diagram. 191 The tokens of an SRL program obey the following rules: 193 - Comments may appear on any line of an SRL program, following a # 194 - White space is used to separate tokens 195 - Semicolon is used as the terminator for most statements 196 - Identifiers (e.g. for defines and labels) must start with a letter 197 - Identifiers may contain letters, digits and underscores 198 - The case of letters is not significant 199 - Reserved words (shown in upper case in this documents) 200 may not be used as identifiers 202 2.1 Define Directive 204 --- DEFINE -- defname ---- = ---- defined_text ------------------ ; 206 Simple parameterless defines are supported via the syntax above. The 207 define name, defname, is an identifier. The defined text starts after 208 the equal sign, and continues up to (but not including) the closing 209 semicolon. If a semicolon is required within the defined text it must 210 be preceded by a backslash, i.e. \; in an SRL define produces ; in the 211 text. 213 Wherever defname appears elsewhere in the program, it will be replaced 214 by the defined text. 216 For example, 218 DEFINE ftp = (20, 21); 219 DEFINE telnet = 23; 220 DEFINE www = 80; 222 2.2 Program 224 ------------+-------+-------- Statement -------+-------+----------- 225 | | | | 226 | +------- Declaration ------+ | 227 | | 228 +---------------------<--------------------+ 230 An SRL program is a sequence of statements or declarations. It does not 231 have any special enclosing symbols. Statements and declarations 232 terminate with a semicolon, except for compound statements, which 233 terminate with a right brace. 235 2.3 Declaration 237 ---------------------- Subroutine_declaration --------------------- 239 SRL's only explicit declaration is the subroutine declaration. Other 240 implicit declarations are labels (declared where they appear in front of 241 a statement) and subroutine parameters (declared in the subroutine 242 header). 244 3 Statement 246 ----------------+---- IF_statement ----------------+--------------- 247 | | 248 +---- Compound_statement ----------+ 249 | | 250 +---- Imperative_statement --------+ 251 | | 252 +---- CALL_statement --------------+ 254 An SRL program is a sequence of SRL statements. There are four kinds of 255 statements, as follows. 257 3.1 IF_statement 259 Test Part Action Part 260 ............. ............... 262 --- IF --- expression ---+------------+---- Statement ----+---> 263 | | | 264 +-- SAVE , --+ | 265 | | 266 +-- SAVE ; ----------------------+ 268 >-----------+-----------------------------+----------------- 269 | | 270 +-----ELSE --- Statement -----+ 272 3.1.1 expression 274 -------- term --------+------------------------+------------------- 275 | | 276 +--<-- term ----- || ----+ logical OR 278 3.1.2 term 280 ------- factor -------+------------------------+------------------- 281 | | 282 +--<-- factor --- && ----+ logical AND 284 3.1.3 factor 286 ------------+-------- attrib == operand_list --------+----------- 287 | | 288 +------------ ( expression ) --------------+ 290 3.1.4 operand_list 292 ----------+------------------ operand -----------------+----------- 293 | | 294 +-- ( operand ---+-------------------+-- ) --+ 295 | | 296 +-<-- operand , ---+ 298 3.1.5 operand 300 ------------- value ---------+----------------------+-------------- 301 | | 302 +------- / width ------+ 303 | | 304 +------- & mask -------+ 306 3.1.6 Test Part 308 The IF statement evaluates a logical expression. If the expression 309 value is TRUE, the action indicated in the 'Action Part' of the diagram 310 is executed. If the value is FALSE and the IF has an ELSE clause, that 311 ELSE clause is executed (see below). 313 The simplest form of expression is a test for equality (== operator); in 314 this an RTFM attribute value (from the packet or from an SRL variable) 315 is ANDed with a mask and compared with a value. A list of RTFM 316 attributes is given in Appendix C. More complicated expressions may be 317 built up using parentheses and the && (logical AND) and || (logical OR) 318 operators. 320 Operand values may be specified as dotted decimal, hexadecimal or as a 321 character constant (enclosed in apostrophes). The syntax for operand 322 values is given in Appendix B. 324 Masks may be specified as numbers, 325 dotted decimal e.g. &255.255 326 or hexadecimal e.g. &FF-FF 327 or as a width in bits e.g. /16 329 If a mask is not specified, an all-ones mask is used. 331 In SRL a value is always combined with a mask; this combination is 332 referred to as an operand. For example, if we were interested in flows 333 originating from IP network 130.216, we might write: 335 IF SourcePeerAddress == 130.216.0.0 & 255.255.0.0 SAVE; 337 or equivalently 339 IF SourcePeerAddress == 130.216/16 SAVE; 341 A list of values enclosed in parentheses may also be specified; the test 342 succeeds if the masked attribute equals any of the values in the list. 343 For example 345 IF SourcePeerAddress == ( 130.216.7/24, 130.216.34/24 ) SAVE; 347 As this last example indicates, values are right-padded with zeroes, 348 i.e. the given numbers specify the leading bytes of masks and values. 350 The operand values and masks used in an IF statement must be consistent 351 with the attribute being tested. For example, a four-byte value is 352 acceptable as a peer address, but would not be accepted as a transport 353 address (which may not be longer than two bytes). 355 3.1.7 Action Part 357 A SAVE action (i.e. SAVE , or SAVE ;) saves attribute(s), mask(s) and 358 value(s) as given in the statement. If the IF expression tests more 359 than one attribute, the masks and values are saved for all the matched 360 attributes. For each value_list in the statement the value saved is the 361 one which the packet actually matched. See below for further 362 description of SAVE statements. 364 Other actions are described in detail under "Imperative statements" 365 below. Note that the RETURN action is valid only within subroutines. 367 3.1.8 ELSE Clause 369 An Else Clause provides a statement which will be executed if the IF's 370 test fails. The statement following ELSE will often be another IF 371 statement, providing SRL's version of a 'select' statement. Note that 372 an ELSE clause always matches the immediately preceding IF. 374 3.2 Compound_statement 376 -------+-------------+----- { ---+---- Statement ----+--- } ------- 377 | | | | 378 +-- label : --+ +--------<----------+ 380 A compound statement is a sequence of statements enclosed in braces. 381 Each statement will terminate with a semicolon, unless it is another 382 compound statement (which terminates with a right brace). 384 A compound statement may be labelled, i.e. preceded by an identifier 385 followed by a semi-colon. Each statement inside the braces is executed 386 in sequence unless an EXIT statement is performed, as explained below. 388 Labels have a well-defined scope, within which they must be unique. 389 Labels within a subroutine (i.e. between a SUBROUTINE and its matching 390 ENDSUB) are local to that subroutine and are not visible outside it. 391 Labels outside subroutines are part of a program's outer block. 393 3.3 Imperative_statement 395 ------+---------------------------------------------------+------ ; 396 | | 397 +-- SAVE attrib --+--+-----------+--+---------------+ 398 | | | | | | 399 | | +- / width -+ | | 400 | | | | | | 401 | | +- & mask --+ | | 402 | | | | 403 | +--- = operand ---+ | 404 | | 405 +-- COUNT ------------------------------------------+ 406 | | 407 +-- EXIT label ------------------------------------+ 408 | | 409 +-- IGNORE -----------------------------------------+ 410 | | 411 +-- NOMATCH ----------------------------------------+ 412 | | 413 +-- RETURN --+-------+------------------------------+ 414 | | | | 415 | +-- n --+ | 416 | | 417 +-- STORE variable := value ------------------------+ 419 3.3.1 SAVE Statement 421 The SAVE statement saves information which will (later) identify the 422 flow in the meter's flow table. It does not actually record anything in 423 the table; this is done when a subsequent COUNT statement executes. 425 SAVE has two possible forms: 427 SAVE attrib = operand ; 428 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 then moves on to 469 examine the next incoming packet, beginning again at the first statement 470 of its 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 ( --+-----------------------------+-- ) --> 507 | | 508 +--+-- ADDRESS --- pname --+--+ 509 | | 510 +-- VARIABLE -- pname --+ 511 | | 512 +------<------- , ------+ 514 >------+-------- Statement ---------+----- ENDSUB -------- ; 515 | | 516 +-------------<--------------+ 518 A Subroutine declaration has three parts: 520 the subname is an indentifier, used to name the subroutine. 522 the parameter list specifies the subroutine's parameters. 523 Each parameter is preceded with a keyword indicating its 524 type - VARIABLE indicates an SRL variable (see the STORE 525 statement above), ADDRESS indicates any other RTFM attribute. 526 A parameter name may be any identifier, and its scope is 527 limited to the subroutine's body. 529 the body specifies what processing the subroutine will perform. 530 This is simply a sequence of Statements, terminated by the 531 ENDSUB keyword. 533 Note that EXITs in a subroutine may not refer to labels outside it. The 534 only way to leave a subroutine is via a RETURN statement. 536 3.5 CALL_statement 538 ---- CALL subname ( --+---------------------+-- ) ----> 539 | | 540 +--+-- parameter --+--+ 541 | | 542 +----<--- , ----+ 544 >---+-------------------------------------+--- ENDCALL ---- ; 545 | | 546 +---+--+-- n : --+--- Statement --+---+ 547 | | | | 548 | +----<----+ | 549 | | 550 +--------------<--------------+ 552 The CALL statement invokes an SRL subroutine. The parameters are SRL 553 variables or other RTFM attributes, and their types must match those in 554 the subroutine declaration. Following the parameters is a sequence of 555 statements, each preceded by an integer label. These labels will 556 normally be 1:, 2:, 3:, etc, but they do not have to be contiguous, nor 557 in any particular order. They are referred to in RETURN statements 558 within the subroutine body. 560 e.g. RETURN 2; would return to the statement labelled 2: 561 within in the CALL statement. 563 Execution of the labelled statement completes the CALL. 565 If the return statement does not specify a return label, the first 566 statement executed after RETURN will be the statement immediately 567 following ENDCALL. 569 4 Example Programs 571 4.1 Classify IP Port Numbers 573 # 574 # Classify IP port numbers 575 # 576 if SourcePeerType == IP save; 577 else ignore; # Not an IP packet 578 # 579 if SourceTransAddress == (www, ftp, telnet) nomatch; 580 # We want the well-known port as Dest 581 # 582 if DestTransAddress == telnet 583 save, store FlowKind := 'T'; 584 else if DestTransAddress == www 585 save, store FlowKind := 'W'; 586 else if DestTransAddress == ftp 587 save, store FlowKind := 'F'; 588 else { 589 save DestTransAddress; 590 store FlowKind := '?'; 591 } 592 save SourcePeerAddress /32; 593 save DestPeerAddress /32; 594 count; 595 # 596 This program counts only IP packets, saving SourceTransType (tcp, udp or 597 0), Source- and DestPeerAddress (32-bit IP addresses) and FlowKind ('W' 598 for www, 'F' for ftp, 'T' for telnet, '?' for unclassified). The 599 program uses a NOMATCH action to specify the packet direction - its 600 resulting flows will have the well-known ports as their destination. 602 4.2 Classify Traffic into Groups of Networks 604 # 605 # SRL program to classify traffic into network groups 606 # 607 define my_net = 130.216/16; 608 define k_nets = ( 130.217/16, 130.123/16, 130.195/16, 609 132.181/16, 138.75/16, 139.80/16 ); 610 # 611 call net_kind (SourcePeerAddress, SourceKind) 612 endcall; 613 call net_kind (DestPeerAddress, DestKind) 614 endcall; 615 count; 616 # 617 subroutine net_kind (address addr, variable net) 618 if addr == my_net save, { 619 store net := 10; return 1; 620 } 621 else if addr == k_nets save, { 622 store net := 20; return 2; 623 } 624 save addr/24; # Not my_net or in k_nets 625 store net := 30; return 3; 626 endsub; 627 # 629 The net_kind subroutine determines whether addr is my network (130.216), 630 one of the Kawaihiko networks (in the k_nets list), or some other 631 network. It saves the network address from addr (16 bits for my_net and 632 the k_net networks, 24 bits for others), stores a value of 10, 20 or 30 633 in net, and returns to 1:, 2: or 3:. Note that the network numbers 634 used are contained within the two DEFINEs, making them easy to change. 636 net_kind is called twice, saving Source- and DestPeerAddress and Source- 637 and DestKind; the COUNT statement produces flows identified by these 638 four RTFM attributes, with no particular source-dest ordering. 640 In the program no use is made of return numbers amd they could have been 641 omitted. However, we might wish to re-use the subroutine in another 642 program doing different things for different return numbers, as in the 643 version below. 645 call net_kind (DestPeerAddress, DestKind) 646 1: nomatch; # We want my_net as source 647 endcall; 648 call net_kind (SourcePeerAddress, SourceKind) 649 1: count; # my_net -> other networks 650 endcall; 651 save SourcePeerAddress /24; 652 save DestPeerAddress /24; 653 count; 655 This version uses a NOMATCH statement to ensure that its resulting flows 656 have my_net as their source. The NOMATCH also rejects my_net -> my_net 657 traffic. Traffic which doesn't have my_net as source or destination 658 saves 24 bits of its peer addresses (the subroutine might only have 659 saved 16) before counting such an unusual flow. 661 5 APPENDICES 663 5.1 Appendix A: SRL Syntax in BNF 665 ::= | 667 ::= | 669 ::= 671 ::= | 672 | 673 | 674 676 ::= IF 678 ::= SAVE ; | 679 SAVE , | 680 682 ::= | 683 ELSE 685 ::= | || 686 ::= | && 688 ::= == | ( ) 690 ::= | ( ) 692 ::= | 693 , 695 ::= | 696 / | 697 & 699 ::= { } 701 ::= | 702 : 704 ::= | 706 ::= ; | 707 SAVE ; | 708 COUNT ; | 709 EXIT