idnits 2.17.1 draft-ietf-rtfm-ruleset-language-01.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-25) 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 302 has weird spacing: '...decimal e.g. ...' == Line 305 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 (Nov 1998) is 9293 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 720 looks like a reference -- Missing reference section? '2' on line 725 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 5 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 May 1998 4 Expires Nov 1998 6 SRL: A Simple Ruleset Language 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, and 14 its Working Groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. This Internet Draft is a product of the 16 Realtime Traffic Flow Measurement Working Group of the IETF. 18 Internet Drafts are draft documents valid for a maximum of six months. 19 Internet Drafts may be updated, replaced, or obsoleted by other 20 documents at any time. It is not appropriate to use Internet Drafts as 21 reference material or to cite them other than as a "working draft" or 22 "work in progress." 24 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 27 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 28 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 This document describes a language for specifying rulesets, i.e. 33 configuration files which may be loaded into a traffic flow meter so 34 as to specify which traffic flows are measured by the meter, and the 35 information it will store for each flow. Although the language is 36 primarily intended for RTFM traffic flows, it may also be useful in 37 other areas as a general way of specifying flows to be measured or 38 collected. 40 Contents 42 1 Purpose and Scope 3 43 1.1 RTFM Meters and Traffic Flows . . . . . . . . . . . . . . . . 3 44 1.2 SRL Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 46 2 SRL Language Description 4 47 2.1 Define Directive . . . . . . . . . . . . . . . . . . . . . . . 5 49 3 Statement 5 50 3.1 IF_statement . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 3.1.1 expression . . . . . . . . . . . . . . . . . . . . . . . . 6 52 3.1.2 factor . . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 3.1.3 term . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 3.1.4 operand_list . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.1.5 operand . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 3.1.6 Test Part . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3.1.7 Action Part . . . . . . . . . . . . . . . . . . . . . . . 8 59 3.2 Imperative_statement . . . . . . . . . . . . . . . . . . . . . 9 60 3.2.1 GOTO Statement . . . . . . . . . . . . . . . . . . . . . . 9 61 3.2.2 SAVE Statement . . . . . . . . . . . . . . . . . . . . . . 9 62 3.2.3 COUNT Statement . . . . . . . . . . . . . . . . . . . . . 10 63 3.2.4 IGNORE Statement . . . . . . . . . . . . . . . . . . . . . 10 64 3.2.5 NOMATCH Statement . . . . . . . . . . . . . . . . . . . . 10 65 3.2.6 STORE Statement . . . . . . . . . . . . . . . . . . . . . 11 66 3.2.7 RETURN Statement . . . . . . . . . . . . . . . . . . . . . 11 68 3.3 Subroutine_declaration . . . . . . . . . . . . . . . . . . . . 11 70 3.4 CALL_statement . . . . . . . . . . . . . . . . . . . . . . . . 12 72 4 Example Programs 13 73 4.1 Classify IP Port Numbers . . . . . . . . . . . . . . . . . . 13 74 4.2 Classify Traffic into Groups of Networks . . . . . . . . . . 14 76 5 APPENDICES 15 77 5.1 Appendix A: SRL Syntax in BNF . . . . . . . . . . . . . . . . 15 79 6 Acknowledgments 17 81 7 References 17 83 8 Author's Addresses 17 85 1 Purpose and Scope 87 A ruleset for an RTFM Meter is a sequence of instructions to be executed 88 by the meter's Pattern Matching Engine (PME). The form of these 89 instructions is described in detail in RFCs 2063 and 2064 [1], [2], but 90 most users - at least inititially - find them confusing and difficult to 91 write, mainly because the effect of each instruction is strongly 92 dependent on the state of the meter's Packet Matching Engine at the 93 moment of its execution. 95 SRL is a procedural language for creating RTFM rulesets. It has been 96 designed to be simple for people to understand, using statements which 97 help to clarify the execution context in which they operate. SRL 98 programs will be compiled into rulesets, which can then be downloaded to 99 RTFM meters. 101 1.1 RTFM Meters and Traffic Flows 103 The RTFM Architecture [1] defines a set of 'attributes' which apply to 104 network traffic. Among the attributes are 'address attributes,' such as 105 PeerType, PeerAddress, TransType and TransAddress, which have meaning 106 for many protocols, e.g. for IP traffic (PeerType == IP) PeerAddress is 107 an IP address, TransType is TCP, UDP, ICMP, etc., and TransAddress is 108 usually an IP port number. 110 An 'RTFM Traffic Flow' is simply a stream of packets observed by a meter 111 as they pass across a network between two end points (or from a single 112 end point). Each 'end point' of a flow is determined by the set of 113 values of its address attributes. 115 An 'RTFM Meter' is a measuring device - e.g. a program running on a 116 Unix or PC host - which observes passing packets and builds 'Flow Data 117 Records' for the flows of interest. 119 RTFM traffic flows have another important property - they are 120 bi-directional. This means that each flow data record in the meter has 121 two sets of counters, one for packets travelling from source to 122 destination, the other for returning packets. Within the RTFM 123 architecture such counters appear as further attributes of the flow. 125 An RTFM meter must be configured by the user, which means creating a 126 'Ruleset' so as to specify which flows are to be measured, and how much 127 information (i.e. which attributes) should be stored for each of them. 128 A rulset is effectively a program for a minimal virtual machine, the 129 'Packet Matching Engine (PME),' which is described in detail in [1]. An 130 RTFM meter may run multiple rule sets, with every passing packet being 131 processed by each of the rulesets. The rule 'actions' in this document 132 are described as though only a single ruleset were running. 134 In the past creating a ruleset has meant writing machine code for the 135 PME, which has proved rather difficult to do. SRL provides a high-level 136 language which should enable users to create effective rulesets without 137 having to understand the details of the PME. 139 1.2 SRL Overview 141 An SRL program is executed from the beginning for each new packet 142 arriving at the meter. It has two essential goals. 144 (a) Decide whether the current packet is part of a flow which is of 145 interest and, if necessary, determine its direction (i.e. decide 146 which of its end-points is considered to be its source). Other 147 packets will be ignored. 149 (b) SAVE whatever information is required to identify the flow and 150 accumulate (COUNT) quantitative information for that flow. 152 At execution, the meter's Packet Matching Engine (PME) begins by using 153 source and destination attributes as they appear 'on the wire.' If the 154 attributes do not match those of a flow to be recorded, the PME will 155 normally execute the program again, this time with the source and 156 destination addresses interchanged. Because of this bi-directional 157 matching, an RTFM meter is able to build up tables of flows with two 158 sets of counters - one for forward packets, the other for backward 159 packets. The programmer can, if required, suppress the 160 reverse-direction matching and assign 'forward' and 'backward' 161 directions which conform to the conventions of the external context. 163 Goal (a) is achieved using IF statements which perform comparisons on 164 information from the packet or from SRL variables. Goal (b) is achieved 165 using one or more SAVE statements to store the flow's identification 166 attributes; a COUNT statement then increments the statistical data 167 accumulating for it. 169 2 SRL Language Description 171 The SRL language is explained below using 'railway diagrams' to describe 172 the syntax. Flow through a diagram is from left to right. The only 173 exception to this is that lines carrying a left arrow may only be 174 traversed right to left. In the diagrams, keywords are written in 175 capital letters; in practice an SRL compiler will be insensitive to case 176 in keywords. Lower-case identifiers are explained in the text, or they 177 refer to another diagram. 179 The tokens of an SRL program obey the following rules: 181 - Comments may appear on any line of an SRL program, following a # 182 - White space is used to separate tokens 183 - Semicolon is used as the statement terminator 184 - Identifiers (e.g. for defines and labels) must start with a letter 185 - Identifiers may contain letters, digits and underscores 186 - The case of letters is not significant 188 2.1 Define Directive 190 --- DEFINE -- defname ---- = ---- defined_text ------------------ ; 192 Simple, parameterless, defines are supported, via the syntax above. The 193 define name, defname, is an identifier made up of letters, digits and 194 underscores. The defined text starts after the equal sign, and 195 continues up to (but not including) the closing semicolon. (If a 196 semicolon is required within define text, it must be preceded by a 197 backslash). Wherever defname appears elsewhere in the program, it will 198 be replaced by the defined text. 200 For example, 202 DEFINE telnet = 23; 203 DEFINE smtp = 25; 204 DEFINE http = (80, 8080); 206 3 Statement 208 ----+-------------+-----+--- IF_statement -------------------+--- ; 209 | | | | 210 +-- label : --+ +--- Imperative_statement -----------+ 211 | | | | 212 +------<------+ +--- Subroutine_declaration ---------+ 213 | | 214 +--- CALL_statement -----------------+ 216 An SRL program is a sequence of SRL statements, each one terminated by a 217 semicolon. There are four kinds of statements, as follows. 219 Each statement may be labelled, i.e. preceded by a sequence of one or 220 more labels. A label is an identifier, which must be followed by a 221 semi-colon. Each statement is executed in sequence, unless one of them 222 performs a GOTO, in which case execution transfers to the statement 223 bearing the target label. 225 Labels have a well-defined scope, within which they must be unique. 226 Labels within a subroutine (i.e. between a SUBROUTINE and its matching 227 ENDSUB) are local to that subroutine and are not visible outside it. 228 Labels outside subroutines are part of a program's outer block. 230 3.1 IF_statement 232 Test Part Action Part 233 ............. ............... 235 --- IF --------- expression -----------+-------- GOTO label -+--- ; 236 | | 237 +- SAVE , GOTO label -+ 238 | | 239 +- SAVE --------------+ 240 | | 241 +- IGNORE ------------+ 242 | | 243 +- NOMATCH -----------+ 244 | | 245 +- RETURN --+-------+-+ 246 | | 247 +-- n --+ 249 3.1.1 expression 251 ------------+------------ factor -------------+-------------------- 252 | | 253 +-------------- || ---------------+ logical OR 255 3.1.2 factor 257 ------------+------------- term --------------+-------------------- 258 | | 259 +-------------- && ---------------+ logical AND 261 3.1.3 term 263 ------------+------- attrib == operand_list ---------+------------- 264 | | 265 +------------ ( expression ) ------------+ 267 3.1.4 operand_list 269 ------------+-------------- operand -----------------+------------- 270 | | 271 +--- ( operand--+---------------+-- ) ---+ 272 | | 273 +-- , operand --+ 274 | | 275 +-------<-------+ 277 3.1.5 operand 279 ------------- value ---------+----------------------+-------------- 280 | | 281 +------- / width ------+ 282 | | 283 +------- & mask -------+ 285 3.1.6 Test Part 287 The IF statement evaluates a logical expression. If the expression 288 value is TRUE, the action indicated by the keyword on the right of the 289 diagram is executed. If the value is FALSE, the following statement is 290 executed. 292 The simplest form of expression is a test for equality (== operator); in 293 this an RTFM attribute value (from the packet or from an SRL variable) 294 is ANDed with a mask and compared with a value. More complicated 295 expressions may be built up using parentheses and the && (logical AND) 296 and || (logical OR) operators. 298 Operand values may be specified as dotted decimal,hexadecimal or as a 299 character constant (enclosed in apostrophes). 301 Masks may be specified as numbers, 302 dotted decimal e.g. &255.255.0.0 303 or hexadecimal e.g. &FF-FF-00-00 305 or as a width in bits e.g. /16 307 If a mask is not specified, an all-ones mask is used. 309 In SRL a value is always combined with a mask; this combination is 310 referred to as an operand.For example, if we were interested in flows 311 originating from IP network 130.216, we might write: 313 IF SourcePeerAddress == 130.216.0.0 & 255.255.0.0 314 GOTO my_network; 316 or equivalently 318 IF SourcePeerAddress == 130.216/16 GOTO my_network; 320 A list of values enclosed in parentheses may also be specified; the test 321 succeeds if the masked attribute equals any of the values in the list. 322 For example 324 IF SourcePeerAddress == ( 130.216.7/24, 130.216.34/24 ) 325 GOTO special_network; 327 As this last example indicates, values are right-padded with zeroes, 328 i.e. the given numbers specify the leading bytes of masks and values. 330 The operand values and masks used in an IF statement must be consistent 331 with the attribute being tested. For example, a four-byte value is 332 acceptable as a peer address, but would not be accepted as a transport 333 address (which may not be longer than two bytes). 335 3.1.7 Action Part 337 A SAVE action saves attribute(s), mask(s) and value(s) as given in the 338 statement. If the statement's expression tests more than one attribute, 339 the masks and values are saved for all the attributes. For each 340 value_list in the statement the value saved is the one which the packet 341 actually matched. See below for further description of SAVE statements. 343 Other actions are described in detail under "Imperative statements" 344 below. Note that the RETURN action is valid only within subroutines. 346 3.2 Imperative_statement 348 --+------------------------------------------- GOTO label ----+-- ; 349 | | 350 +-- SAVE attrib --+--+-----------+--+---+----------------+--+ 351 | | | | | | | | 352 | | +- / width -+ | +- , GOTO label -+ | 353 | | | | | | 354 | | +- & mask --+ | | 355 | | | | 356 | +--- = operand ---+ | 357 | | 358 +-- COUNT --------------------------------------------------+ 359 | | 360 +-- IGNORE -------------------------------------------------+ 361 | | 362 +-- NOMATCH ------------------------------------------------+ 363 | | 364 +-- RETURN --+-------+--------------------------------------+ 365 | | | | 366 | +-- n --+ | 367 | | 368 +-- STORE variable := value ------------+----------------+--+ 369 | | 370 +- , GOTO label -+ 372 3.2.1 GOTO Statement 374 The GOTO statement (either on its own or as the last part of a larger 375 statement) specifies the label of the statement to be executed next. 377 3.2.2 SAVE Statement 379 The SAVE statement saves information which will (later) identify the 380 flow in the meter's flow table. It does not actually record anything in 381 the table; this is done when a subsequent COUNT statement executes. 383 SAVE has two possible forms: 385 SAVE attrib = operand 386 saves the attribute, mask and value as given in the statement. 387 This form of the SAVE statement is similar to that allowed 388 in an IF statement, except that - since imperative statements 389 do not perform a test - you may save an arbitrary value. 391 SAVE attrib 392 SAVE attrib / width 393 SAVE attrib & mask 394 saves the attribute and mask from the statement, and the 395 value resulting from their application to the current packet. 396 This is most useful when used to save a value with a wider 397 mask than than was used to select the packet. For example 399 IF DestPeerAddress == 130.216/16 400 NOMATCH; 401 IF SourcePeerAddress == 130.216/16 402 GOTO my_network; 403 IGNORE; # Executes only if preceding 404 # IF statements both fail. 405 my_network: SAVE SourcePeerAddress /24; 406 COUNT; 408 3.2.3 COUNT Statement 410 The COUNT statement appears after all testing and saving is complete; it 411 instructs the PME to build the flow identifier from the attributes which 412 have been SAVEd, find it in the meter's flow table (creating a new entry 413 if this is the first packet observed for the flow), and increment its 414 counters. The meter then moves on to examine the next incoming packet. 416 3.2.4 IGNORE Statement 418 The IGNORE statement terminates examination of the current packet 419 without saving any information from it; the meter moves on to examine 420 the next incoming packet, beginning again at the first statement of its 421 program. 423 3.2.5 NOMATCH Statement 425 The NOMATCH statement indicates that matching has failed for this 426 execution of the program. If it is executed when a packet is being 427 processed with its addresses in 'on the wire' order, the PME will 428 perform the program again from the beginning with source and destination 429 addresses interchanged. If it is executed following such an 430 interchange, the packet will be IGNOREd. NOMATCH is illustrated in the 431 above example, where it is used to ensure that flows having 130.216/16 432 as an end-point are counted as though 130.216 had been those flows' 433 source peer (IP) address. 435 3.2.6 STORE Statement 437 The STORE statement assigns a value to an SRL variable and SAVEs it. 438 There are six SRL variables: 440 SourceClass SourceKind 441 DestClass DestKind 442 FlowClass FlowKind 444 Their names have no particular significance; they were arbitrarily 445 chosen as likely RTFM attributes but can be used to store any integer 446 values. Their values are set to zero each time examination of a new 447 packet begins. 449 3.2.7 RETURN Statement 451 The RETURN statement is used to return from subroutines and can be used 452 only within the context of a subroutine. It is described in detail 453 below (CALL statement). 455 3.3 Subroutine_declaration 457 -- SUBROUTINE subname ( -+--+---ADDRESS ----pname---+--+- ) --> 458 | | | | 459 | +-- VARIABLE -- pname --+ | 460 | | | | 461 | +------<------- , ------+ | 462 | | 463 +-----------------------------+ 465 >------+--- Imperative_statement ---+----- ENDSUB -------- ; 466 | | 467 +----IF_statement -----------+ 468 | | 469 +----CALL_statement ---------+ 470 | | 471 +-------------<--------------+ 473 A Subroutine declaration has three parts: 475 the subname is an indentifier, used to name the subroutine. 477 the Parameter list specifies the subroutine's parameters. 478 Each parameter is preceded with a keyword indicating its 479 type - VARIABLE indicates an SRL variable (see the STORE 480 statement above), ADDRESS indicates any other RTFM attribute. 481 The parameter name (pname in the diagram) must be the name of 482 a meter 'parameter' variable, i.e. P1, P2, P3, P4 or P5. 483 The meter implements these as global variables, which means 484 that the SRL programmer must be careful to avoid conflicts 485 when calling one subroutine from another. 487 the Body specifies what processing the subroutine will perform. 488 This is simply a sequence of Imperative, IF and CALL statements, 489 terminated by the ENDSUB keyword. 491 Note that GOTOs in a subroutine may not refer to labels outside it. The 492 only way to leave a subroutine is via a RETURN statement. 494 3.4 CALL_statement 496 --- CALL subname ( -+--+-- parameter --+--+- ) --> 497 | | | | 498 | +---<---- , ----+ | 499 | | 500 +---------------------+ 502 >---+--- n: Imperative_statement ---+---- ENDCALL -------- ; 503 | | 504 +---------------<---------------+ 506 The CALL statement invokes an SRL subroutine. The parameters are SRL 507 variables or other RTFM attributes, and their types must match those in 508 the subroutine declaration. Following the parameters is a sequence of 509 statements, each preceded by an integer label. These labels will 510 normally be 1:, 2:, 3:, etc, but they do not have to be contiguous. 511 They are referred to in RETURN statements. 513 e.g. RETURN 2; would return to the statement labelled 2: 514 in the subroutine call. 516 If this statement does not execute a GOTO, execution 517 will then continue with the first statement after ENDCALL. 519 If the return statement does not specify a return label, the first 520 statement executed after RETURN will be the statement immediately 521 following ENDCALL. 523 4 Example Programs 525 4.1 Classify IP Port Numbers 527 # SRL program to classify IP port numbers 528 # 529 IF SourcePeerType == IP SAVE, GOTO IP_pkt; 530 IGNORE; # Not an IP packet 531 # 532 IP_pkt: 533 IF SourceTransType == ( tcp, udp ) SAVE, GOTO tcp_udp; 534 GOTO fin; # Not tcp or udp (probably doesn't have ports) 535 # 536 tcp_udp: 537 IF SourceTransAddress == ( www, ftp, telnet ) NOMATCH; 538 # 539 IF DestTransAddress == www GOTO c_www; 540 IF DestTransAddress == ftp GOTO c_ftp; 541 IF DestTransAddress == telnet GOTO c_telnet; 542 # 543 GOTO fin; # Count as 'unknown' 544 # 545 c_www: 546 STORE FlowKind := 'W', GOTO fin; 547 c_ftp: 548 STORE FlowKind := 'F', GOTO fin; 549 c_telnet: 550 STORE FlowKind := 'T', GOTO fin; 551 # 552 fin: 553 SAVE SourcePeerAddress /32; 554 SAVE DestPeerAddress /32; 555 COUNT; 557 This program counts only IP packets, saving SourceTransType (tcp, udp or 558 0), Source- and DestPeerAddress (32-bit IP addresses) and FlowKind ('W' 559 for www, 'F' for ftp, 'T' for telnet, 0 for inclassified). The program 560 uses NOMATCH actions to specify the packet direction - its resulting 561 flows will have the well-known ports as their destination. 563 4.2 Classify Traffic into Groups of Networks 565 # SRL program to classify traffic into network groups 566 # 567 CALL net_kind (SourcePeerAddress, SourceKind) 568 ENDCALL; 569 CALL net_kind (DestPeerAddress, DestKind) 570 ENDCALL; 571 COUNT; 572 # 573 SUBROUTINE net_kind (ADDRESS p1, VARIABLE p2) 574 IF p1 == 130.216/16 575 SAVE, GOTO nk_mysite; 576 IF p1 == ( 130.217/16, 130.123/16, 130.195/16, 577 132.181/16, 138.75/16, 139.80/16 ) 578 SAVE, GOTO nk_mynetwork; 579 SAVE p1 /24; # Not my site or my network 580 STORE p2 := 30; RETURN 3; 581 nk_mysite: 582 STORE p2 := 10; RETURN 1; 583 nk_mynetwork: 584 STORE p2 := 20; RETURN 2; 585 ENDSUB; 587 The net_kind subroutine determines whether p1 is my network (130.216), 588 one of the networks in my network (one of the networks in the list), or 589 some other network. It saves the network address from p1 (16 bits for 590 my site and my network, 24 bits for others), stores a value of 10, 20 or 591 30 in p2, and returns to 1:, 2: or 3:. 593 net_kind is called twice, saving Source- and DestPeerAddress and Source- 594 and DestKind; the COUNT statement produces flows identified by these 595 four RTFM attributes, with no particular source-dest ordering. 597 In the program no use is made of return numbers amd they could have been 598 omitted. However, we might wish to re-use the subroutine in another 599 program doing different things for different return numbers, as in the 600 version below. 602 CALL net_kind (DestPeerAddress, DestKind) 603 1: NOMATCH; 604 ENDCALL; 605 CALL net_kind (SourcePeerAddress, SourceKind) 606 1: COUNT; # site -> network or other 607 ENDCALL; 608 SAVE SourcePeerAddress /24; 609 SAVE DestPeerAddress /24; 610 COUNT; 612 This version uses a NOMATCH statement to ensure that site -> network or 613 other flows have site as their source. The NOMATCH also rejects site -> 614 site traffic. Traffic which doesn't have site as source or destination 615 saves 24 bits of its addresses (the subroutine might only have saved 16) 616 before counting such an unusual flow. 618 5 APPENDICES 620 5.1 Appendix A: SRL Syntax in BNF 622 ::= | 624 ::=