idnits 2.17.1 draft-ietf-rtfm-ruleset-language-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (October 1999) is 8922 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) ** Obsolete normative reference: RFC 2063 (ref. '1') (Obsoleted by RFC 2722) ** Obsolete normative reference: RFC 2064 (ref. '2') (Obsoleted by RFC 2720) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2373 (ref. '4') (Obsoleted by RFC 3513) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 April 1999 4 Expires October 1999 6 SRL: A Language for Describing Traffic Flows 7 and Specifying Actions forFlow Groups 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet Draft is a product of the Realtime Traffic Flow 32 Measurement Working Group of the IETF. 34 Abstract 36 This document describes a language for specifying rulesets, i.e. 37 configuration files which may be loaded into a traffic flow meter so as 38 to specify which traffic flows are measured by the meter, and the 39 information it will store for each flow. 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 . . . . . . . . . . . . . . . . . . . . . . . 7 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 62 3.2 Compound_statement . . . . . . . . . . . . . . . . . . . . . . 9 63 3.3 Imperative_statement . . . . . . . . . . . . . . . . . . . . . 10 64 3.3.1 SAVE Statement . . . . . . . . . . . . . . . . . . . . . . 10 65 3.3.2 COUNT Statement . . . . . . . . . . . . . . . . . . . . . 11 66 3.3.3 EXIT Statement . . . . . . . . . . . . . . . . . . . . . . 11 67 3.3.4 IGNORE Statement . . . . . . . . . . . . . . . . . . . . . 12 68 3.3.5 NOMATCH Statement . . . . . . . . . . . . . . . . . . . . 12 69 3.3.6 STORE Statement . . . . . . . . . . . . . . . . . . . . . 12 70 3.3.7 RETURN Statement . . . . . . . . . . . . . . . . . . . . . 12 71 3.4 Subroutine_declaration . . . . . . . . . . . . . . . . . . . . 13 72 3.5 CALL_statement . . . . . . . . . . . . . . . . . . . . . . . . 13 74 4 Example Programs 14 75 4.1 Classify IP Port Numbers . . . . . . . . . . . . . . . . . . . 14 76 4.2 Classify Traffic into Groups of Networks . . . . . . . . . . . 15 78 5 IANA Considerations 16 80 6 APPENDICES 17 81 6.1 Appendix A: SRL Syntax in BNF . . . . . . . . . . . . . . . . 17 82 6.2 Appendix B: Syntax for Values and Masks . . . . . . . . . . . 19 83 6.3 Appendix C: RTFM Attribute Information . . . . . . . . . . . . 19 85 7 Acknowledgments 21 87 8 References 21 89 9 Author's Address 21 91 1 Purpose and Scope 93 A ruleset for an RTFM Meter is a sequence of instructions to be executed 94 by the meter's Pattern Matching Engine (PME). The form of these 95 instructions is described in detail in the 'RTFM Architecture' and 'RTFM 96 Meter MIB' documents [1], [2], but most users - at least initially - 97 find them confusing and difficult to write, mainly because the effect of 98 each instruction is strongly dependent on the state of the meter's 99 Packet Matching Engine at the moment of its execution. 101 SRL (the Simple Ruleset Language) is a procedural language for creating 102 RTFM rulesets. It has been designed to be simple for people to 103 understand, using statements which help to clarify the execution context 104 in which they operate. SRL programs will be compiled into rulesets 105 which can then be downloaded to RTFM meters. 107 An SRL compiler is available as part of NeTraMet (a free-software 108 implementation of the RTFM meter and manager), version 4.2 [3]. 110 1.1 RTFM Meters and Traffic Flows 112 The RTFM Architecture [1] defines a set of 'attributes' which apply to 113 network traffic. Among the attributes are 'address attributes,' such as 114 PeerType, PeerAddress, TransType and TransAddress, which have meaning 115 for many protocols, e.g. for IP traffic (PeerType == IP) PeerAddress is 116 an IP address, TransType is TCP, UDP, ICMP, etc., and TransAddress is 117 usually an IP port number. 119 An 'RTFM Traffic Flow' is simply a stream of packets observed by a meter 120 as they pass across a network between two end points (or to/from a 121 single end point). Each 'end point' of a flow is specified by the set 122 of values of its address attributes. 124 An 'RTFM Meter' is a measuring device - e.g. a program running on a 125 Unix or PC host - which observes passing packets and builds 'Flow Data 126 Records' for the flows of interest. 128 RTFM traffic flows have another important property - they are 129 bi-directional. This means that each flow data record in the meter has 130 two sets of counters, one for packets travelling from source to 131 destination, the other for returning packets. Within the RTFM 132 architecture such counters appear as further attributes of the flow. 134 An RTFM meter must be configured by the user, which means creating a 135 'Ruleset' so as to specify which flows are to be measured, and how much 136 information (i.e. which attributes) should be stored for each of them. 137 A ruleset is effectively a program for a minimal virtual machine, the 138 'Packet Matching Engine (PME),' which is described in detail in [1]. An 139 RTFM meter may run multiple rule sets, with every passing packet being 140 processed by each of the rulesets. The rule 'actions' in this document 141 are described as though only a single ruleset were running. 143 In the past creating a ruleset has meant writing machine code for the 144 PME, which has proved rather difficult to do. SRL provides a high-level 145 language which should enable users to create effective rulesets without 146 having to understand the details of the PME. 148 The language may be useful in other applications, being suitable for any 149 application area which involves selecting traffic flows from a stream of 150 packets. 152 1.2 SRL Overview 154 An SRL program is executed from the beginning for each new packet 155 arriving at the meter. It has two essential goals. 157 (a) Decide whether the current packet is part of a flow which is of 158 interest and, if necessary, determine its direction (i.e. decide 159 which of its end-points is considered to be its source). Other 160 packets will be ignored. 162 (b) SAVE whatever information is required to identify the flow and 163 accumulate (COUNT) quantitative information for that flow. 165 At execution, the meter's Packet Matching Engine (PME) begins by using 166 source and destination attributes as they appear 'on the wire.' If the 167 attributes do not match those of a flow to be recorded, the PME will 168 normally execute the program again, this time with the source and 169 destination addresses interchanged. Because of this bi-directional 170 matching, an RTFM meter is able to build up tables of flows with two 171 sets of counters - one for forward packets, the other for backward 172 packets. The programmer can, if required, suppress the 173 reverse-direction matching and assign 'forward' and 'backward' 174 directions which conform to the conventions of the external context. 176 Goal (a) is achieved using IF statements which perform comparisons on 177 information from the packet or from SRL variables. Goal (b) is achieved 178 using one or more SAVE statements to store the flow's identification 179 attributes; a COUNT statement then increments the statistical data 180 accumulating for it. 182 2 SRL Language Description 184 The SRL language is explained below using 'railway diagrams' to describe 185 the syntax. Flow through a diagram is from left to right. The only 186 exception to this is that lines carrying a left arrow may only be 187 traversed right to left. In the diagrams, keywords are written in 188 capital letters; in practice an SRL compiler must be insensitive to 189 case. Lower-case identifiers are explained in the text, or they refer 190 to another diagram. 192 The tokens of an SRL program obey the following rules: 194 - Comments may appear on any line of an SRL program, following a # 195 - White space is used to separate tokens 196 - Semicolon is used as the terminator for most statements 197 - Identifiers (e.g. for defines and labels) must start with a letter 198 - Identifiers may contain letters, digits and underscores 199 - The case of letters is not significant 200 - Reserved words (shown in upper case in this documents) 201 may not be used as identifiers 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. The defined text starts after 209 the equal sign, and continues up to (but not including) the closing 210 semicolon. If a semicolon is required within the defined text it must 211 be preceded by a backslash, i.e. \; in an SRL define produces ; in the 212 text. 214 Wherever defname appears elsewhere in the program, it will be replaced 215 by the defined text. 217 For example, 219 DEFINE ftp = (20, 21); 220 DEFINE telnet = 23; 221 DEFINE www = 80; 223 2.2 Program 225 ------------+-------+-------- Statement -------+-------+----------- 226 | | | | 227 | +------- Declaration ------+ | 228 | | 229 +---------------------<--------------------+ 231 An SRL program is a sequence of statements or declarations. It does not 232 have any special enclosing symbols. Statements and declarations 233 terminate with a semicolon, except for compound statements, which 234 terminate with a right brace. 236 2.3 Declaration 238 ---------------------- Subroutine_declaration --------------------- 240 SRL's only explicit declaration is the subroutine declaration. Other 241 implicit declarations are labels (declared where they appear in front of 242 a statement) and subroutine parameters (declared in the subroutine 243 header). 245 3 Statement 247 ----------------+---- IF_statement ----------------+--------------- 248 | | 249 +---- Compound_statement ----------+ 250 | | 251 +---- Imperative_statement --------+ 252 | | 253 +---- CALL_statement --------------+ 255 An SRL program is a sequence of SRL statements. There are four kinds of 256 statements, as follows. 258 3.1 IF_statement 260 Test Part Action Part 261 ............. ............... 263 --- IF --- expression ---+------------+---- Statement ----+---> 264 | | | 265 +-- SAVE , --+ | 266 | | 267 +-- SAVE ; ----------------------+ 269 >-----------+-----------------------------+----------------- 270 | | 271 +-----ELSE --- Statement -----+ 273 3.1.1 expression 275 -------- term --------+------------------------+------------------- 276 | | 277 +--<-- term ----- || ----+ logical OR 279 3.1.2 term 281 ------- factor -------+------------------------+------------------- 282 | | 283 +--<-- factor --- && ----+ logical AND 285 3.1.3 factor 287 ------------+-------- attrib == operand_list --------+----------- 288 | | 289 +------------ ( expression ) --------------+ 291 3.1.4 operand_list 293 ----------+------------------ operand -----------------+----------- 294 | | 295 +-- ( operand ---+-------------------+-- ) --+ 296 | | 297 +-<-- operand , ---+ 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 and the IF has an ELSE clause, that 312 ELSE clause is executed (see below). 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 SAVE; 338 or equivalently 340 IF SourcePeerAddress == 130.216/16 SAVE; 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 matched 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. For example 465 outer: { 466 ... 467 if SourcePeerAddress == 192.168/16 468 exit outer; # exits the statement labelled 'outer' 469 ... 470 } 471 # execution resumes here 473 In practice the language provides sufficient logical structure that one 474 seldom - if ever - needs to use the EXIT statement. 476 3.3.4 IGNORE Statement 478 The IGNORE statement terminates examination of the current packet 479 without saving any information from it. The meter then moves on to 480 examine the next incoming packet, beginning again at the first statement 481 of its program. 483 3.3.5 NOMATCH Statement 485 The NOMATCH statement indicates that matching has failed for this 486 execution of the program. If it is executed when a packet is being 487 processed with its addresses in 'on the wire' order, the PME will 488 perform the program again from the beginning with source and destination 489 addresses interchanged. If it is executed following such an 490 interchange, the packet will be IGNOREd. 492 NOMATCH is illustrated in the SAVE example (section 3.3.1), where it is 493 used to ensure that flows having 130.216/16 as an end-point are counted 494 as though 130.216 had been those flows' source peer (IP) address. 496 3.3.6 STORE Statement 498 The STORE statement assigns a value to an SRL variable and SAVEs it. 499 There are six SRL variables: 501 SourceClass SourceKind 502 DestClass DestKind 503 FlowClass FlowKind 505 Their names have no particular significance; they were arbitrarily 506 chosen as likely RTFM attributes but can be used to store any 507 single-byte integer values. Their values are set to zero each time 508 examination of a new packet begins. For example 510 STORE SourceClass := 3; 511 STORE FlowKind := 'W' 513 3.3.7 RETURN Statement 515 The RETURN statement is used to return from subroutines and can be used 516 only within the context of a subroutine. It is described in detail 517 below (CALL statement). 519 3.4 Subroutine_declaration 521 -- SUBROUTINE subname ( --+-----------------------------+-- ) --> 522 | | 523 +--+-- ADDRESS --- pname --+--+ 524 | | 525 +-- VARIABLE -- pname --+ 526 | | 527 +------<------- , ------+ 529 >------+-------- Statement ---------+----- ENDSUB -------- ; 530 | | 531 +-------------<--------------+ 533 A Subroutine declaration has three parts: 535 the subname is an identifier, used to name the subroutine. 537 the parameter list specifies the subroutine's parameters. 538 Each parameter is preceded with a keyword indicating its 539 type - VARIABLE indicates an SRL variable (see the STORE 540 statement above), ADDRESS indicates any other RTFM attribute. 541 A parameter name may be any identifier, and its scope is 542 limited to the subroutine's body. 544 the body specifies what processing the subroutine will perform. 545 This is simply a sequence of Statements, terminated by the 546 ENDSUB keyword. 548 Note that EXITs in a subroutine may not refer to labels outside it. The 549 only way to leave a subroutine is via a RETURN statement. 551 3.5 CALL_statement 553 ---- CALL subname ( --+---------------------+-- ) ----> 554 | | 555 +--+-- parameter --+--+ 556 | | 557 +----<--- , ----+ 559 >---+-------------------------------------+--- ENDCALL ---- ; 560 | | 561 +---+--+-- n : --+--- Statement --+---+ 562 | | | | 563 | +----<----+ | 564 | | 565 +--------------<--------------+ 567 The CALL statement invokes an SRL subroutine. The parameters are SRL 568 variables or other RTFM attributes, and their types must match those in 569 the subroutine declaration. Following the parameters is a sequence of 570 statements, each preceded by an integer label. These labels will 571 normally be 1:, 2:, 3:, etc, but they do not have to be contiguous, nor 572 in any particular order. They are referred to in RETURN statements 573 within the subroutine body. 575 e.g. RETURN 2; would return to the statement labelled 2: 576 within in the CALL statement. 578 Execution of the labelled statement completes the CALL. 580 If the return statement does not specify a return label, the first 581 statement executed after RETURN will be the statement immediately 582 following ENDCALL. 584 4 Example Programs 586 4.1 Classify IP Port Numbers 588 # 589 # Classify IP port numbers 590 # 591 if SourcePeerType == IP save; 592 else ignore; # Not an IP packet 593 # 594 if SourceTransAddress == (www, ftp, telnet) nomatch; 595 # We want the well-known port as Dest 596 # 597 if DestTransAddress == telnet 598 save, store FlowKind := 'T'; 599 else if DestTransAddress == www 600 save, store FlowKind := 'W'; 602 else if DestTransAddress == ftp 603 save, store FlowKind := 'F'; 604 else { 605 save DestTransAddress; 606 store FlowKind := '?'; 607 } 608 save SourcePeerAddress /32; 609 save DestPeerAddress /32; 610 count; 611 # 613 This program counts only IP packets, saving SourceTransType (tcp, udp or 614 0), Source- and DestPeerAddress (32-bit IP addresses) and FlowKind ('W' 615 for www, 'F' for ftp, 'T' for telnet, '?' for unclassified). The 616 program uses a NOMATCH action to specify the packet direction - its 617 resulting flows will have the well-known ports as their destination. 619 4.2 Classify Traffic into Groups of Networks 621 # 622 # SRL program to classify traffic into network groups 623 # 624 define my_net = 130.216/16; 625 define k_nets = ( 130.217/16, 130.123/16, 130.195/16, 626 132.181/16, 138.75/16, 139.80/16 ); 627 # 628 call net_kind (SourcePeerAddress, SourceKind) 629 endcall; 630 call net_kind (DestPeerAddress, DestKind) 631 endcall; 632 count; 633 # 634 subroutine net_kind (address addr, variable net) 635 if addr == my_net save, { 636 store net := 10; return 1; 637 } 638 else if addr == k_nets save, { 639 store net := 20; return 2; 640 } 641 save addr/24; # Not my_net or in k_nets 642 store net := 30; return 3; 643 endsub; 644 # 646 The net_kind subroutine determines whether addr is my network (130.216), 647 one of the Kawaihiko networks (in the k_nets list), or some other 648 network. It saves the network address from addr (16 bits for my_net and 649 the k_net networks, 24 bits for others), stores a value of 10, 20 or 30 650 in net, and returns to 1:, 2: or 3:. Note that the network numbers 651 used are contained within the two DEFINEs, making them easy to change. 653 net_kind is called twice, saving Source- and DestPeerAddress and Source- 654 and DestKind; the COUNT statement produces flows identified by these 655 four RTFM attributes, with no particular source-dest ordering. 657 In the program no use is made of return numbers and they could have been 658 omitted. However, we might wish to re-use the subroutine in another 659 program doing different things for different return numbers, as in the 660 version below. 662 call net_kind (DestPeerAddress, DestKind) 663 1: nomatch; # We want my_net as source 664 endcall; 665 call net_kind (SourcePeerAddress, SourceKind) 666 1: count; # my_net -> other networks 667 endcall; 668 save SourcePeerAddress /24; 669 save DestPeerAddress /24; 670 count; 672 This version uses a NOMATCH statement to ensure that its resulting flows 673 have my_net as their source. The NOMATCH also rejects my_net -> my_net 674 traffic. Traffic which doesn't have my_net as source or destination 675 saves 24 bits of its peer addresses (the subroutine might only have 676 saved 16) before counting such an unusual flow. 678 5 IANA Considerations 680 Appendix C below lists the RTFM attributes by name. Since SRL only 681 refers to attributes by name, SRL users do not have to know the 682 attribute numbers. 684 The size (in bytes) of the various attribute values is also listed in 685 Appendix C. These sizes reflect the object sizes for the attribute 686 values as they are stored in the RTFM Meter MIB [2]. 688 IANA considerations for allocating new attributes are discussed in 689 detail in the RTFM Architecture document [1]. 691 6 APPENDICES 693 6.1 Appendix A: SRL Syntax in BNF 695 ::= | 697 ::= | 699 ::= 701 ::= | 702 | 703 | 704 706 ::= IF 708 ::= SAVE ; | 709 SAVE , | 710 712 ::= | 713 ELSE 715 ::= | || 717 ::= | && 719 ::= == | 720 ( ) 722 ::= | ( ) 724 ::= | 725 , 727 ::= | 728 / | 729 & 731 ::= { } 733 ::= | 734 : 736 ::= | 737 ::= ; | 738 SAVE ; | 739 COUNT ; | 740 EXIT