RFC2723 日本語訳
2723 SRL: A Language for Describing Traffic Flows and SpecifyingActions for Flow Groups. N. Brownlee. October 1999. (Format: TXT=44406 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group N. Brownlee Request for Comments: 2723 The University of Auckland Category: Informational October 1999
コメントを求めるワーキンググループN.ブラウンリーの要求をネットワークでつないでください: 2723 オークランド大学カテゴリ: 情報の1999年10月
SRL: A Language for Describing Traffic Flows and
Specifying Actions for Flow Groups
SRL: 交通の流れについて説明して、流れグループに動作を指定するための言語
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow.
このドキュメントはrulesetsを指定するために言語を説明します、すなわち、どの交通が流れるかを指定するために交通流量計にロードされるかもしれない構成ファイルがそれが各流れのために収納するメーター、および情報によって測定されます。
Table of Contents
目次
1 Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 2
1.1 RTFM Meters and Traffic Flows . . . . . . . . . . . . . . 2
1.2 SRL Overview . . . . . . . . . . . . . . . . . . . . . . 3
2 SRL Language Description . . . . . . . . . . . . . . . . . . 4
2.1 Define Directive . . . . . . . . . . . . . . . . . . . . 4
2.2 Program . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Declaration . . . . . . . . . . . . . . . . . . . . . . . 5
3 Statement . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 IF_statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1 expression . . . . . . . . . . . . . . . . . . . . 6
3.1.2 term . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3 factor . . . . . . . . . . . . . . . . . . . . . . 6
3.1.4 operand_list . . . . . . . . . . . . . . . . . . . 6
3.1.5 operand . . . . . . . . . . . . . . . . . . . . . . 6
3.1.6 Test Part . . . . . . . . . . . . . . . . . . . . . 7
3.1.7 Action Part . . . . . . . . . . . . . . . . . . . . 8
3.1.8 ELSE Clause . . . . . . . . . . . . . . . . . . . . 8
3.2 Compound_statement . . . . . . . . . . . . . . . . . . . 8
3.3 Imperative_statement . . . . . . . . . . . . . . . . . . 9
3.3.1 SAVE Statement . . . . . . . . . . . . . . . . . . 9
3.3.2 COUNT Statement . . . . . . . . . . . . . . . . . . 10
1 目的、.21.1範囲RTFMメーター、および交通の流れ. . . . . . . . . . . . . . 2 1.2SRL概観. . . . . . . . . . . . . . . . . . . . . . 3 2SRLの言語記述. . . . . . . . . . . . . . . . . . 4 2.1は指向性の.42.2プログラム. . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3宣言. . . . . . . . . . . . . . . . . . . . . . . 5 3声明を定義します…; .53.1 _声明.63.1.1表現.63.1.2用語. . . . . . . . . . . . . . . . . . . . . . . 6 3.1.3が.63.1.4オペランド_リスト.63.1.5オペランド. . . . . . . . . . . . . . . . . . . . . . 6 3.1.6Test Part. . . . . . . . . . . . . . . . . . . . . 7 3.1.7Action Part. . . . . . . . . . . . . . . . . . . . 8 3.1.8ELSE Clauseを因数分解するなら…. . . . . . . . . . . . . . . 8 3.2の化合物_声明の.83.3の必須の_声明. . . . . . . . . . . . . . . . . . 9 3.3.1は.2カウント声明. . . . . . . . . . . . . . . . . . 10を声明. . . . . . . . . . . . . . . . . . 9 3.3に保存します。
Brownlee Informational [Page 1] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[1ページ]のRFC2723SRL: 交通の流れ言語1999年10月
3.3.3 EXIT Statement . . . . . . . . . . . . . . . . . . 10
3.3.4 IGNORE Statement . . . . . . . . . . . . . . . . . 10
3.3.5 NOMATCH Statement . . . . . . . . . . . . . . . . . 10
3.3.6 STORE Statement . . . . . . . . . . . . . . . . . . 11
3.3.7 RETURN Statement . . . . . . . . . . . . . . . . . 11
3.4 Subroutine_declaration . . . . . . . . . . . . . . . . . 11
3.5 CALL_statement . . . . . . . . . . . . . . . . . . . . . 12
4 Example Programs . . . . . . . . . . . . . . . . . . . . . . 13
4.1 Classify IP Port Numbers . . . . . . . . . . . . . . . . 13
4.2 Classify Traffic into Groups of Networks . . . . . . . . 14
5 Security Considerations . . . . . . . . . . . . . . . . . . . 15
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7 APPENDICES . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1 Appendix A: SRL Syntax in BNF . . . . . . . . . . . . . . 16
7.2 Appendix B: Syntax for Values and Masks . . . . . . . . . 18
7.3 Appendix C: RTFM Attribute Information . . . . . . . . . 19
8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
9 References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10 Author's Address . . . . . . . . . . . . . . . . . . . . . . 21
11 Full Copyright Statement . . . . . . . . . . . . . . . . . . 22
3.3.3 声明を出てください、.103.3、.4、声明. . . . . . . . . . . . . . . . . 10 3.3.5NOMATCH声明. . . . . . . . . . . . . . . . . 10 3.3.6店声明. . . . . . . . . . . . . . . . . . 11 3.3.7リターン声明. . . . . . . . . . . . . . . . . 11 3.4サブルーチン_宣言. . . . . . . . . . . . . . . . . 11 3.5呼び出し_声明を無視してください…; .124のプログラム例. . . . . . . . . . . . . . . . . . . . . . 13 4.1が分類する、.134.2が分類するIPポートナンバーはセキュリティ問題. . . . . . . . . . . . . . . . . . . 15 6IANA問題. . . . . . . . . . . . . . . . . . . . . 15 7付録. . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1付録A:をネットワーク. . . . . . . . 14 5グループに取引します。 BNF. . . . . . . . . . . . . . 16 7.2付録BのSRL構文: 値のための構文と仮面. . . . . . . . . 18 7.3付録C: RTFM属性情報. . . . . . . . . 19 8承認. . . . . . . . . . . . . . . . . . . . . . . 20 9参照. . . . . . . . . . . . . . . . . . . . . . . . . 20 10作者のアドレスの.21 11の完全な著作権宣言文. . . . . . . . . . . . . . . . . . 22
1 Purpose and Scope
1 目的と範囲
A ruleset for an RTFM Meter is a sequence of instructions to be executed by the meter's Pattern Matching Engine (PME). The form of these instructions is described in detail in the 'RTFM Architecture' and 'RTFM Meter MIB' documents [RTFM-ARC, RTFM-MIB], but most users - at least initially - find them confusing and difficult to write, mainly because the effect of each instruction is strongly dependent on the state of the meter's Packet Matching Engine at the moment of its execution.
RTFM Meterのためのrulesetは計器Pattern Matching Engine(PME)によって実行されるべき指示の系列です。 これらの指示のフォームは'RTFM Architecture'と'RTFM Meter MIB'というドキュメント[RTFM-ARC、RTFM-MIB]で詳細に説明されますが、ほとんどのユーザが、少なくとも初めは彼らが紛らわしくて、難しいのが書くわかります、主にそれぞれの指示の効果が実行の瞬間に強く計器Packet Matching Engineの州に依存しているので。
SRL (the Simple Ruleset Language) is a procedural language for creating RTFM rulesets. It has been designed to be simple for people to understand, using statements which help to clarify the execution context in which they operate. SRL programs will be compiled into rulesets which can then be downloaded to RTFM meters.
SRL(Simple Ruleset Language)は、RTFM rulesetsを作成するための手続き型言語です。 それは人々が理解しているのが、簡単であるように設計されています、それらが作動する実行文脈をはっきりさせるのを助ける声明を使用して。 SRLプログラムは次にRTFMメーターにダウンロードできるrulesetsにコンパイルされるでしょう。
An SRL compiler is available as part of NeTraMet (a free-software implementation of the RTFM meter and manager), version 4.2 [NETRAMET].
SRLコンパイラはNeTraMet(RTFMメーターとマネージャのフリーソフトウェア実現)バージョン4.2[NETRAMET]の一部として利用可能です。
1.1 RTFM Meters and Traffic Flows
1.1 RTFMメーターと交通の流れ
The RTFM Architecture [RTFM-ARC] defines a set of 'attributes' which apply to network traffic. Among the attributes are 'address attributes,' such as PeerType, PeerAddress, TransType and TransAddress, which have meaning for many protocols, e.g. for IPv4
RTFM Architecture[RTFM-ARC]はネットワークトラフィックに適用される1セットの'属性'を定義します。 属性の中に、'アドレス属性'があります、PeerTypeや、PeerAddressや、TransTypeやTransAddressなどのように、例えば、IPv4のために。(TransAddressは多くのプロトコルのための意味を持っています)。
Brownlee Informational [Page 2] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[2ページ]のRFC2723SRL: 交通の流れ言語1999年10月
traffic (PeerType == 1) PeerAddress is an IP address, TransType is TCP(6), UDP(17), ICMP(1), etc., and TransAddress is usually an IP port number.
交通(PeerType=1)PeerAddressはIPアドレスです、そして、TransTypeはTCP(6)、UDP(17)、ICMP(1)ですなど、そして、通常、TransAddressはIPポートナンバーです。
An 'RTFM Traffic Flow' is simply a stream of packets observed by a meter as they pass across a network between two end points (or to/from a single end point). Each 'end point' of a flow is specified by the set of values of its address attributes.
'RTFM Traffic Flow'は単にそれらが2つのエンドポイント(またはシングルエンドのポイントからの/に)の間をネットワークの向こう側に通るので1メーターによって観察されたパケットの流れです。 流れの各'エンドポイント'はアドレス属性の値のセットによって指定されます。
An 'RTFM Meter' is a measuring device - e.g. a program running on a Unix or PC host - which observes passing packets and builds 'Flow Data Records' for the flows of interest.
'RTFM Meter'は興味がある流れのために一時的なパケットを観察して、'流れData Records'を建てる測定装置(例えば、UnixかPCホストの上で作業するプログラム)です。
RTFM traffic flows have another important property - they are bi- directional. This means that each flow data record in the meter has two sets of counters, one for packets travelling from source to destination, the other for returning packets. Within the RTFM architecture such counters appear as further attributes of the flow.
RTFM交通の流れには、別の重要な特性があります--それらは2方向上です。 これは、メーターのそれぞれの流れデータレコードには2セットのカウンタがあることを意味します、ソースから目的地まで移動するパケットのためのもの、戻っているパケットのためのもう片方。 RTFM構造の中では、そのようなカウンタは流れのさらなる属性として現れます。
An RTFM meter must be configured by the user, which means creating a 'Ruleset' so as to specify which flows are to be measured, and how much information (i.e. which attributes) should be stored for each of them. A ruleset is effectively a program for a minimal virtual machine, the 'Packet Matching Engine (PME),' which is described in detail in [RTFM-ARC]. An RTFM meter may run multiple rule sets, with every passing packet being processed by each of the rulesets. The rule 'actions' in this document are described as though only a single ruleset were running.
ユーザはRTFMメーターを構成しなければなりません。(そのユーザは、どの流れが測定されることであるか、そして、どのくらいの情報(すなわち、どの属性)がそれぞれのそれらのために格納されるべきであるかを指定するために'Ruleset'を作成すると言っています)。 rulesetは最小量の仮想計算機のための事実上プログラム、[RTFM-ARC]で詳細に説明される'パケットMatching Engine(PME)'です。 あらゆる一時的なパケットがそれぞれのrulesetsによって処理されている状態で、RTFMメーターは複数の規則セットを経営しているかもしれません。 まるで単一のrulesetだけが走っているかのように規則'動作'は本書では説明されます。
In the past creating a ruleset has meant writing machine code for the PME, which has proved rather difficult to do. SRL provides a high- level language which should enable users to create effective rulesets without having to understand the details of the PME.
過去の作成では、rulesetは、PMEのために機械コードを書くことを意味しました。(PMEはするのがかなり難しいと判明しました)。 SRLはユーザがPMEの細部を理解する必要はなくて有効なrulesetsを作成するのを可能にするべきである高値レベル言語を提供します。
The language may be useful in other applications, being suitable for any application area which involves selecting traffic flows from a stream of packets.
言語は他のアプリケーションで役に立つかもしれません、パケットの流れからの交通の流れを選択することを伴うどんなアプリケーション部にも適していて。
1.2 SRL Overview
1.2 SRL概観
An SRL program is executed from the beginning for each new packet arriving at the meter. It has two essential goals.
SRLプログラムはメーターに達するそれぞれの新しいパケットのために始めから実行されます。 それには、2つの不可欠の目標があります。
(a) Decide whether the current packet is part of a flow which is of
interest and, if necessary, determine its direction (i.e. decide
which of its end-points is considered to be its source). Other
packets will be ignored.
(a) 現在のパケットが興味がある流れの一部であるかどうか決めてください、そして、必要なら、指示を決定してください(すなわち、終わりポイントのどれがソースであると考えられるか決めてください)。 他のパケットは無視されるでしょう。
Brownlee Informational [Page 3] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[3ページ]のRFC2723SRL: 交通の流れ言語1999年10月
(b) SAVE whatever information is required to identify the flow and
accumulate (COUNT) quantitative information for that flow.
(b) SAVEはその流れのために流れを特定して、情報が何であっても(COUNT)量的な情報を蓄積しなければなりません。
At execution, the meter's Packet Matching Engine (PME) begins by using source and destination attributes as they appear 'on the wire.' If the attributes do not match those of a flow to be recorded, the PME will normally execute the program again, this time with the source and destination addresses interchanged. Because of this bi- directional matching, an RTFM meter is able to build up tables of flows with two sets of counters - one for forward packets, the other for backward packets. The programmer can, if required, suppress the reverse-direction matching and assign 'forward' and 'backward' directions which conform to the conventions of the external context.
実行では、計器Packet Matching Engine(PME)は、'ワイヤ'に現れるようにソースと目的地属性を使用することによって、始まります。ソースと送付先アドレスが交換されている状態で、属性がするIfは記録されるために流れのものに合わないで、通常、PMEは再び、今回、プログラムを実行するでしょう。 両性愛者の方向のマッチング、これによるRTFMメーターは2セットのカウンタで流れのテーブルを確立できます--前進のパケット(後方のパケットのためのもう片方)のためのもの。 プログラマは、必要なら、逆指示マッチングを抑圧して、'前方'に'後方に'外部の関係のコンベンションに従う指示を割り当てることができます。
Goal (a) is achieved using IF statements which perform comparisons on information from the packet or from SRL variables. Goal (b) is achieved using one or more SAVE statements to store the flow's identification attributes; a COUNT statement then increments the statistical data accumulating for it.
パケットかSRL変数からの情報に比較を実行する声明であるなら、目標(a)は達成された使用です。 目標(b)は流れの識別属性を格納するのに1つ以上のSAVE声明を使用することで達成されます。 そして、COUNT声明はそれのために蓄積する統計データを増加します。
2 SRL Language Description
2 SRLの言語記述
The SRL language is explained below using 'railway diagrams' to describe the syntax. Flow through a diagram is from left to right. The only exception to this is that lines carrying a left arrow may only be traversed right to left. In the diagrams, keywords are written in capital letters; in practice an SRL compiler must be insensitive to case. Lower-case identifiers are explained in the text, or they refer to another diagram.
構文について説明するのに'鉄道ダイヤグラム'を使用する下でSRL言語は説明されます。 左から右までダイヤグラムによる流れがあります。 これへの唯一の例外は左向きの矢を運ぶ線がまさしく左に横断されるだけであるかもしれないということです。 ダイヤグラムで、キーワードは大文字で書かれています。 実際には、SRLコンパイラは、ケースに入れるために神経が鈍くなければなりません。 小文字の識別子がテキストで説明されるか、または彼らは別のダイヤグラムを示します。
The tokens of an SRL program obey the following rules:
SRLプログラムの象徴は以下の規則に従います:
- Comments may appear on any line of an SRL program, following a #
- White space is used to separate tokens
- Semicolon is used as the terminator for most statements
- Identifiers (e.g. for defines and labels) must start with a letter
- Identifiers may contain letters, digits and underscores
- The case of letters is not significant
- Reserved words (shown in upper case in this document) may not be
used as identifiers
- コメントはSRLプログラムのどんな線の上にも現れるかもしれません、#、に続いて--余白は象徴を切り離すのに使用されます--セミコロンはほとんどの声明にターミネータとして使用されます--、識別子、(例えば、定義、ラベル) 必須は手紙から始まります--識別子は手紙、ケタ、および強調を含むかもしれません--手紙のケースは重要ではありません--リザーブドワード(大文字で、本書では目立つ)は識別子として使用されないかもしれません。
2.1 Define Directive
2.1は指示を定義します。
--- DEFINE -- defname ---- = ---- defined_text ------------------ ;
--- DEFINE--defname---- = ---- 定義された_テキスト------------------ ;
Simple parameterless defines are supported via the syntax above. The define name, defname, is an identifier. The defined text starts after the equal sign, and continues up to (but not including) the
簡単なparameterlessが定義する、上の構文で、支持されます。 名前を定義してください、そして、defnameは識別子です。 定義されたテキストは、等号の後に始まって、(包含だけでない)まで続きます。
Brownlee Informational [Page 4] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[4ページ]のRFC2723SRL: 交通の流れ言語1999年10月
closing semicolon. If a semicolon is required within the defined text it must be preceded by a backslash, i.e. \; in an SRL define produces ; in the text.
セミコロンを閉じます。 セミコロンが定義されたテキストの中で必要であるなら、それにすなわち、バックスラッシュ、\先行しなければなりません。 SRLでは、生産物を定義してください。 テキストで。
Wherever defname appears elsewhere in the program, it will be replaced by the defined text.
defnameがどこにプログラムのほかの場所に現れても、それを定義されたテキストに取り替えるでしょう。
For example,
例えば
DEFINE ftp = (20, 21); # Well-known Port numbers from [ASG-NBR] DEFINE telnet = 23; DEFINE www = 80;
DEFINE ftp=(20、21)。 # [ASG-NBR]DEFINE telnet=23からの周知のPort番号。 DEFINE www=80。
2.2 Program
2.2 プログラム
------------+-------+-------- Statement -------+-------+-----------
| | | |
| +------- Declaration ------+ |
| |
+---------------------<--------------------+
------------+-------+-------- 声明-------+-------+----------- | | | | | +------- 宣言------+ | | | +---------------------<、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+
An SRL program is a sequence of statements or declarations. It does not have any special enclosing symbols. Statements and declarations terminate with a semicolon, except for compound statements, which terminate with a right brace.
SRLプログラムは声明か宣言の系列です。 それには、どんな特別な同封シンボルもありません。 声明と宣言は複合文以外のセミコロンで終わります。複合文は正しい支柱で終わります。
2.3 Declaration
2.3 宣言
---------------------- Subroutine_declaration ---------------------
---------------------- サブルーチン_宣言---------------------
SRL's only explicit declaration is the subroutine declaration. Other implicit declarations are labels (declared where they appear in front of a statement) and subroutine parameters (declared in the subroutine header).
SRLの唯一の明示宣言がサブルーチン宣言です。 他の暗黙宣言は、ラベル(それらが声明の正面で見えるところで宣言される)とサブルーチンパラメタ(サブルーチンヘッダーでは、宣言される)です。
3 Statement
3 声明
----------------+---- IF_statement ----------------+---------------
| |
+---- Compound_statement ----------+
| |
+---- Imperative_statement --------+
| |
+---- CALL_statement --------------+
----------------+---- _声明です。----------------+--------------- | | +---- 化合物_声明----------+ | | +---- 必須の_声明--------+ | | +---- _を声明と呼んでください。--------------+
An SRL program is a sequence of SRL statements. There are four kinds of statements, as follows.
SRLプログラムはSRLの声明の系列です。 以下の4種類の声明があります。
Brownlee Informational [Page 5] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[5ページ]のRFC2723SRL: 交通の流れ言語1999年10月
3.1 IF_statement
3.1、_声明です。
Test Part Action Part
............. ...............
部分の動作一部をテストしてください… ...............
--- IF --- expression ---+------------+---- Statement ----+--->
| | |
+-- SAVE , --+ |
| |
+-- SAVE ; ----------------------+
--- IF--- 表現---+------------+---- 声明----+--->|、|、| +--セーブ--+| | | +--節約してください。 ----------------------+
>-----------+-----------------------------+-----------------
| |
+-----ELSE --- Statement -----+
>。-----------+-----------------------------+----------------- | | +-----ほか--- 声明-----+
3.1.1 expression
3.1.1 表現
-------- term --------+------------------------+-------------------
| |
+--<-- term ----- || ----+ logical OR
-------- 用語--------+------------------------+------------------- | | +--<--用語----- || ----+ 論理的なOR
3.1.2 term
3.1.2 用語
------- factor -------+------------------------+-------------------
| |
+--<-- factor --- && ----+ logical AND
------- 要素-------+------------------------+------------------- | | +--<--要素--- && ----+ 論理的なAND
3.1.3 factor
3.1.3 要素
------------+-------- attrib == operand_list --------+-----------
| |
+------------ ( expression ) --------------+
------------+-------- attrib=オペランド_リスト--------+----------- | | +------------ (表現) --------------+
3.1.4 operand_list
3.1.4 オペランド_リスト
----------+------------------ operand -----------------+-----------
| |
+-- ( operand ---+-------------------+-- ) --+
| |
+-<-- operand , ---+
----------+------------------ オペランド-----------------+----------- | | +--、(オペランド、-、--、+、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+--)、--、+| | +-<--オペランド---+
3.1.5 operand
3.1.5 オペランド
------------- value ---------+----------------------+--------------
| |
+------- / width ------+
| |
+------- & mask -------+
------------- 値---------+----------------------+-------------- | | +------- /幅------+ | | +------- マスク-------+
Brownlee Informational [Page 6] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[6ページ]のRFC2723SRL: 交通の流れ言語1999年10月
3.1.6 Test Part
3.1.6 テスト部分
The IF statement evaluates a logical expression. If the expression value is TRUE, the action indicated in the 'Action Part' of the diagram is executed. If the value is FALSE and the IF has an ELSE clause, that ELSE clause is executed (see below).
声明が論理式を評価するなら。 表現値がTRUEであるなら、ダイヤグラムの'動作Part'で示された動作は実行されます。 そして、値がFALSEである、ELSE節、そのELSE節は実行されましたか?(下を見てください)
The simplest form of expression is a test for equality (== operator); in this an RTFM attribute value (from the packet or from an SRL variable) is ANDed with a mask and compared with a value. A list of RTFM attributes is given in Appendix C. More complicated expressions may be built up using parentheses and the && (logical AND) and || (logical OR) operators.
最も簡単な表現形式は平等(=オペレータ)のためのテストです。 これのRTFM属性値(パケットかSRL変数からの)はマスクと値と比べたANDedです。 そしてそして、Moreの複雑な表現が組立しているかもしれないAppendix C.で括弧を使用することでRTFM属性のリストを与える、(論理的なAND)。|| (論理的なOR) オペレータ。
Operand values may be specified as dotted decimal, hexadecimal or as a character constant (enclosed in apostrophes). The syntax for operand values is given in Appendix B.
オペランド値はドット付き10進法として、または、16進か文字定数(アポストロフィでは、同封される)として指定されるかもしれません。 Appendix Bでオペランド値のための構文を与えます。
Masks may be specified as numbers,
dotted decimal e.g. &255.255
or hexadecimal e.g. &FF-FF
or as a width in bits e.g. /16
仮面は数として指定されるかもしれません、ドット付き10進法、例えば、例えば、そして、FF-FFかビット幅とした255.255か16進、例えば、/16
If a mask is not specified, an all-ones mask is used.
マスクが指定されないなら、オールものマスクが使用されています。
In SRL a value is always combined with a mask; this combination is referred to as an operand. For example, if we were interested in flows originating from IP network 130.216, we might write:
SRLでは、値はマスクにいつも結合されます。 この組み合わせはオペランドと呼ばれます。 例えば、私たちはIPネットワーク130.216から発する流れに関心があるなら、書くでしょうに:
IF SourcePeerAddress == 130.216.0.0 & 255.255.0.0 SAVE;
SourcePeerAddress=130.216.0.0と255.255.0であるなら、.0は節約されます。
or equivalently
同等に
IF SourcePeerAddress == 130.216/16 SAVE;
SourcePeerAddress=130.216/16が節約されるなら。
A list of values enclosed in parentheses may also be specified; the test succeeds if the masked attribute equals any of the values in the list. For example:
また、括弧に同封された値のリストは指定されるかもしれません。 仮面の属性がリストの値のどれかと等しいなら、テストは成功します。 例えば:
IF SourcePeerAddress == ( 130.216.7/24, 130.216.34/24 ) SAVE;
SourcePeerAddress=(130.216 24、.7/130.216.34/24)が節約するなら。
As this last example indicates, values are right-padded with zeroes, i.e. the given numbers specify the leading bytes of masks and values.
この最後の例が示すように値がゼロでまさしくそっと歩いている、すなわち、与えられた数は主なバイトのマスクと値を指定します。
The operand values and masks used in an IF statement must be consistent with the attribute being tested. For example, a four-byte value is acceptable as a peer address, but would not be accepted as a transport address (which may not be longer than two bytes).
オペランド値とマスクが中で使用した、声明がテストされる属性と一致しているに違いないなら。 例えば、4バイトの値は、同輩アドレスとして許容できますが、輸送アドレスとして認められないでしょう(2バイトほど長くないかもしれません)。
Brownlee Informational [Page 7] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[7ページ]のRFC2723SRL: 交通の流れ言語1999年10月
3.1.7 Action Part
3.1.7 動作部分
A SAVE action (i.e. SAVE , or SAVE ;) saves attribute(s), mask(s) and value(s) as given in the statement. If the IF expression tests more than one attribute, the masks and values are saved for all the matched attributes. For each value_list in the statement the value saved is the one which the packet actually matched. See below for further description of SAVE statements.
SAVE動作(すなわち、SAVE、またはSAVE;)は声明で与えるように属性、マスク、および値を節約します。 表現が1つ以上の属性をテストするなら、マスクと値はすべての取り組んでいる属性のために節約されます。 声明の各値_リストに関しては、節約された値はパケットが実際に合っていたものです。 SAVE声明のさらなる記述に関して以下を見てください。
Other actions are described in detail under "Imperative statements" below. Note that the RETURN action is valid only within subroutines.
他の動作は以下の「無条件命令」の下で詳細に説明されます。 RETURN動作がサブルーチンだけの中で有効であることに注意してください。
3.1.8 ELSE Clause
3.1.8 節ほかの
An ELSE Clause provides a statement which will be executed if the IF's test fails. The statement following ELSE will often be another IF statement, providing SRL's version of a 'select' statement. Note that an ELSE clause always matches the immediately preceding IF.
ELSE Clauseが作成される声明を提供する、テストやり損ないはそうです。 SRLの'選んだ'声明のバージョンを提供して、ELSEに続く声明は声明であるならしばしば別、になるでしょう。 ELSE節がいつもすぐに前に合っていることに注意してください。
3.2 Compound_statement
3.2 化合物_声明
-------+-------------+----- { ---+---- Statement ----+--- } -------
| | | |
+-- label : --+ +--------<----------+
-------+-------------+----- -、--、+、-、-、--声明----+--------- | | | | +--以下をラベルしてください。 --+ +--------<、-、-、-、-、-、-、-、-、--+
A compound statement is a sequence of statements enclosed in braces. Each statement will terminate with a semicolon, unless it is another compound statement (which terminates with a right brace).
複合文は支柱に同封された声明の系列です。 各声明はそれが別の複合文(正しい支柱で終わる)でないならセミコロンで終わるでしょう。
A compound statement may be labelled, i.e. preceded by an identifier followed by a semi-colon. Each statement inside the braces is executed in sequence unless an EXIT statement is performed, as explained below.
セミコロンがあとに続いた識別子が先行して、複合文はすなわち、ラベルされるかもしれません。 連続してEXIT声明が実行されない場合、支柱における各声明は以下で説明されるように作成されます。
Labels have a well-defined scope, within which they must be unique. Labels within a subroutine (i.e. between a SUBROUTINE and its matching ENDSUB) are local to that subroutine and are not visible outside it. Labels outside subroutines are part of a program's outer block.
ラベルには明確な範囲があります。そこでは、彼らがユニークであるに違いありません。 サブルーチン(すなわち、SUBROUTINEとその合っているENDSUBの間の)の中のラベルは、そのサブルーチンに地方であり、それの外で目に見えません。 サブルーチンの外におけるラベルはプログラムの外側のブロックの一部です。
Brownlee Informational [Page 8] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[8ページ]のRFC2723SRL: 交通の流れ言語1999年10月
3.3 Imperative_statement
3.3 必須の_声明
------+---------------------------------------------------+------ ;
| |
+-- SAVE attrib --+--+-----------+--+---------------+
| | | | | |
| | +- / width -+ | |
| | | | | |
| | +- & mask --+ | |
| | | |
| +--- = operand ---+ |
| |
+-- COUNT ------------------------------------------+
| |
+-- EXIT label ------------------------------------+
| |
+-- IGNORE -----------------------------------------+
| |
+-- NOMATCH ----------------------------------------+
| |
+-- RETURN --+-------+------------------------------+
| | | |
| +-- n --+ |
| |
+-- STORE variable := value ------------------------+
------+---------------------------------------------------+------ ; | | +--SAVE attrib--+--+-----------+--+---------------+ | | | | | | | | +/幅の-+| | | | | | | | | | +とマスク--+| | | | | | | +--- = オペランド---+ | | | +--数えてください。------------------------------------------+ | | +--EXITラベル------------------------------------+ | | +--、無視-----------------------------------------+ | | +--NOMATCH----------------------------------------+ | | +--リターン--+-------+------------------------------+ | | | | | +--n--+| | | +--ストアの可変:=価値------------------------+
3.3.1 SAVE Statement
3.3.1 声明を保存してください。
The SAVE statement saves information which will (later) identify the flow in the meter's flow table. It does not actually record anything in the table; this is done when a subsequent COUNT statement executes.
SAVE声明は(後で)計器フロー・テーブルの流れを特定する情報を保存します。 それは実際に何もテーブルに記録しません。 これにいつをするか。その後のCOUNT声明は実行します。
SAVE has two possible forms:
SAVEには、2つの可能なフォームがあります:
SAVE attrib = operand ; saves the attribute, mask and value as given
in the statement. This form of the SAVE statement is similar to
that allowed in an IF statement, except that - since imperative
statements do not perform a test - you may save an arbitrary
value.
SAVE attribはオペランドと等しいです。 声明で与えるように属性、マスク、および値を節約します。 SAVE声明のこのフォームが中に許容されたそれと同様である、声明であるなら、無条件命令がテストを実行しないのでそれを除いて、あなたは任意の値を節約できます。
SAVE attrib ;
SAVE attrib / width ;
SAVE attrib & mask ; saves the attribute and mask from the statement,
and the value resulting from their application to the current
packet. This is most useful when used to save a value with a
wider mask than than was used to select the packet. For
example:
SAVE attrib。 SAVE attrib/幅。 SAVE attribとマスク。 声明、および彼らのアプリケーションから生じる値から現在のパケットまで属性とマスクを節約します。 より広いマスクで値を節約するのに使用されるとこれが最も役に立つ、パケットを選択するのに使用されたより。 例えば:
Brownlee Informational [Page 9] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[9ページ]のRFC2723SRL: 交通の流れ言語1999年10月
IF DestPeerAddress == 130.216/16
NOMATCH;
ELSE IF SourcePeerAddress == 130.216/16 {
SAVE SourcePeerAddress /24;
COUNT;
}
ELSE IGNORE;
130.216/16DestPeerAddress=NOMATCHであるなら。 ほか、ほかのセーブSourcePeerAddress /24(カウント)が無視するSourcePeerAddress=130.216/16。
3.3.2 COUNT Statement
3.3.2 声明を数えてください。
The COUNT statement appears after all testing and saving is complete; it instructs the PME to build the flow identifier from the attributes which have been SAVEd, find it in the meter's flow table (creating a new entry if this is the first packet observed for the flow), and increment its counters. The meter then moves on to examine the next incoming packet.
COUNT声明は結局テストしながら、現れます、そして、節約は完全です。 それはSAVEdである属性から流れ識別子を築き上げて、計器フロー・テーブル(これが流れに関して観察された最初のパケットであるなら新しいエントリーを作成する)でそれを見つけて、カウンタを増加するようPMEに命令します。 そして、メーターは、次の入って来るパケットを調べるために移動します。
3.3.3 EXIT Statement
3.3.3 出口声明
The EXIT statement exits a labelled compound statement. The next statement to be executed will be the one following that compound statement. This provides a well-defined way to jump to a clearly identified point in a program. For example:
EXIT声明は標識化合物声明を出ます。 次の実行されるべき声明はその複合文に従うものになるでしょう。 これはプログラムで明確に特定されたポイントとび移る明確な方法を提供します。 例えば:
outer: {
...
if SourcePeerAddress == 192.168/16
exit outer; # exits the statement labelled 'outer'
...
}
# execution resumes here
外側: … SourcePeerAddress=192.168/16であるなら、外側で; 声明が'外側である'とラベルした#出口…出てください。 # 実行はここで再開します。
In practice the language provides sufficient logical structure that one seldom - if ever - needs to use the EXIT statement.
実際には、かつてなら、言語はめったに十分な論理構造にそれを提供しません--EXIT声明を使用するのが必要です。
3.3.4 IGNORE Statement
3.3.4 声明を無視してください。
The IGNORE statement terminates examination of the current packet without saving any information from it. The meter then moves on to examine the next incoming packet, beginning again at the first statement of its program.
それからのどんな情報も保存しないで、IGNORE声明は現在のパケットの試験を終えます。 そして、プログラムの最初の声明でやり直して、メーターは、次の入って来るパケットを調べるために移動します。
3.3.5 NOMATCH Statement
3.3.5 NOMATCH声明
The NOMATCH statement indicates that matching has failed for this execution of the program. If it is executed when a packet is being processed with its addresses in 'on the wire' order, the PME will
合っていて、プログラムのこの実行のために失敗した声明が示すNOMATCH。 パケットが'ワイヤ'でアドレスで処理されているとき、それが実行されると、注文、PMEはそうするでしょう。
Brownlee Informational [Page 10] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[10ページ]のRFC2723SRL: 交通の流れ言語1999年10月
perform the program again from the beginning with source and destination addresses interchanged. If it is executed following such an interchange, the packet will be IGNOREd.
ソースと送付先アドレスが交換されている状態で、始めからプログラムをもう一度実行してください。 そのような置き換えに続いて、それが実行されると、パケットはIGNOREdになるでしょう。
NOMATCH is illustrated in the SAVE example (section 3.3.1), where it is used to ensure that flows having 130.216/16 as an end-point are counted as though 130.216 had been those flows' source peer (IP) address.
NOMATCHはSAVEの例(セクション3.3.1)で例証されます。そこでは、それが、エンドポイントとして130.216/16を持っている流れがまるで130.216がそれらの流れのソース同輩(IP)アドレスであったかのように数えられるのを保証するのに使用されます。
3.3.6 STORE Statement
3.3.6 声明を格納してください。
The STORE statement assigns a value to an SRL variable and SAVEs it. There are six SRL variables:
声明がaを割り当てるストアはSRL変数とSAVEsにそれを評価します。 6つのSRL変数があります:
SourceClass SourceKind
DestClass DestKind
FlowClass FlowKind
SourceClass SourceKind DestClass DestKind FlowClass FlowKind
Their names have no particular significance; they were arbitrarily chosen as likely RTFM attributes but can be used to store any single-byte integer values. Their values are set to zero each time examination of a new packet begins. For example:
それらの名前には、どんな特定の意味もありません。 それらをありそうなRTFM属性として任意に選ばれましたが、どんな単一のバイト整数値も格納するのに使用できます。 それらの値が新しいパケットの試験が始まる各回のゼロに合うように設定されます。 例えば:
STORE SourceClass := 3; STORE FlowKind := 'W'
SourceClass:=3を格納してください。 FlowKind:='W'を格納してください。
3.3.7 RETURN Statement
3.3.7 リターン声明
The RETURN statement is used to return from subroutines and can be used only within the context of a subroutine. It is described in detail below (CALL statement).
RETURN声明をサブルーチンから戻るのに使用して、サブルーチンの文脈だけの中で使用できます。 それは(CALL声明)の下で詳細に説明されます。
3.4 Subroutine_declaration
3.4サブルーチン_宣言
-- SUBROUTINE subname ( --+-----------------------------+-- ) -->
| |
+--+-- ADDRESS --- pname --+--+
| |
+-- VARIABLE -- pname --+
| |
+------<------- , ------+
-- SUBROUTINE subname ( --+-----------------------------+-- ) --> | | +--+--アドレス--- pname--+--+| | +--VARIABLE--pname--+| | +------<、-、-、-、-、-、-- , ------+
>------+-------- Statement ---------+----- ENDSUB -------- ;
| |
+-------------<--------------+
>。------+-------- 声明---------+----- ENDSUB-------- ; | | +-------------<、-、-、-、-、-、-、-、-、-、-、-、-、--+
Brownlee Informational [Page 11] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[11ページ]のRFC2723SRL: 交通の流れ言語1999年10月
A Subroutine declaration has three parts:
Subroutine宣言には、3つの部品があります:
the subname is an identifier, used to name the subroutine.
「副-名前」はサブルーチンを命名するのに使用される識別子です。
the parameter list specifies the subroutine's parameters. Each
parameter is preceded with a keyword indicating its type -
VARIABLE indicates an SRL variable (see the STORE statement
above), ADDRESS indicates any other RTFM attribute. A
parameter name may be any identifier, and its scope is limited
to the subroutine's body.
パラメータ・リストはサブルーチンのパラメタを指定します。 キーワードがタイプを示していて、各パラメタは先行されています--VARIABLEはSRL変数を示して(ストア声明が上であることを見てください)、ADDRESSはいかなる他のRTFM属性も示します。 パラメタ名はどんな識別子であるかもしれません、そして、範囲はサブルーチンのボディーに制限されます。
the body specifies what processing the subroutine will perform.
This is simply a sequence of Statements, terminated by the
ENDSUB keyword.
ボディーは、サブルーチンがどんな処理を実行するかを指定します。 これは単にENDSUBキーワードによって終えられたStatementsの系列です。
Note that EXITs in a subroutine may not refer to labels outside it. The only way to leave a subroutine is via a RETURN statement.
サブルーチンのEXITsがそれの外のラベルについて言及しないかもしれないことに注意してください。 サブルーチンを残す唯一の方法はRETURN声明を使用します。
3.5 CALL_statement
3.5 呼び出し_声明
---- CALL subname ( --+---------------------+-- ) ---->
| |
+--+-- parameter --+--+
| |
+----<--- , ----+
---- CALL subname、(--、+、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+--)---->|、| +--+--パラメタ--+--+| | +----<-- , ----+
>---+-------------------------------------+--- ENDCALL ---- ;
| |
+---+--+-- n : --+--- Statement --+---+
| | | |
| +----<----+ |
| |
+--------------<--------------+
>。---+-------------------------------------+--- ENDCALL---- ; | | +---+--+--n: --+--- 声明--+---+ | | | | | +----<、-、-、--+ | | | +--------------<、-、-、-、-、-、-、-、-、-、-、-、-、--+
The CALL statement invokes an SRL subroutine. The parameters are SRL variables or other RTFM attributes, and their types must match those in the subroutine declaration. Following the parameters is a sequence of statements, each preceded by an integer label. These labels will normally be 1:, 2:, 3:, etc, but they do not have to be contiguous, nor in any particular order. They are referred to in RETURN statements within the subroutine body.
CALL声明はSRLサブルーチンを呼び出します。 パラメタは、SRL変数か他のRTFM属性です、そして、彼らのタイプはサブルーチン宣言におけるそれらに合わなければなりません。 パラメタに従うのは、声明の系列、整数ラベルが先行したそれぞれです。 通常、これらのラベルがあるでしょう。1: 2: 3: など、それらだけが、隣接であり、どんな特定のオーダーでもそうする必要はありません。 それらはサブルーチン本体の中のRETURN声明で言及されます。
e.g. RETURN 2; would return to the statement labelled 2:
within in the CALL statement.
例えば、RETURN2。 2に分類された声明に戻るでしょう: コネの中でCALL声明。
Execution of the labelled statement completes the CALL.
ラベルされた声明の実行はCALLを完成します。
Brownlee Informational [Page 12] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[12ページ]のRFC2723SRL: 交通の流れ言語1999年10月
If the return statement does not specify a return label, the first statement executed after RETURN will be the statement immediately following ENDCALL.
リターン声明がリターンラベルを指定しないと、RETURNの後に作成された最初の声明はすぐにENDCALLに続く声明になるでしょう。
4 Example Programs
4 例のプログラム
4.1 Classify IP Port Numbers
4.1はIPポートナンバーを分類します。
#
# Classify IP port numbers
#
define IPv4 = 1; # Address Family number from [ASG-NBR]
#
define ftp = (20, 21); # Well-Known Port numbers from [ASG-NBR]
define telnet = 23;
define www = 80;
#
define tcp = 6; # Protocol numbers from [ASG-NBR]
define udp = 17;
#
if SourcePeerType == IPv4 save;
else ignore; # Not an IPv4 packet
#
if (SourceTransType == tcp || SourceTransType == udp) save, {
if SourceTransAddress == (www, ftp, telnet) nomatch;
# We want the well-known port as Dest
#
if DestTransAddress == telnet
save, store FlowKind := 'T';
else if DestTransAddress == www
save, store FlowKind := 'W';
else if DestTransAddress == ftp
save, store FlowKind := 'F';
else {
save DestTransAddress;
store FlowKind := '?';
}
}
else save SourceTransType = 0;
#
save SourcePeerAddress /32;
save DestPeerAddress /32;
count;
#
# # IPポートナンバーを分類してください。#IPv4=1を定義してください。 # [ASG-NBR]#からのアドレスFamily番号はftp=(20、21)を定義します。 # [ASG-NBR]からのよく知られているPort番号はtelnet=23を定義します。 www=80を定義してください。 # tcp=6を定義してください。 # [ASG-NBR]からのプロトコル番号はudp=17を定義します。 # SourcePeerType=IPv4が節約するなら。 ほか、無視します。 # どんなIPv4パケットも#ほかに(SourceTransType=は|tcpします| DestTransAddress(店FlowKind:='?')を除いた= udp) セーブ、{#Destが#DestTransAddress=telnetであるなら節約して、nomatchに、WeはSourceTransAddress=である(ftpに、telnetをwwwします)ならウェルノウンポートが欲しいです、店FlowKind:='T'; DestTransAddress=wwwなほかにもかかわらず、セーブ、店FlowKind:='というほかのSourceTransType W'(ほかの、しかし、DestTransAddress=ftpなセーブ、店FlowKind:='F')}ならSourceTransType=0を救いません。 # SourcePeerAddress /32を取っておいてください。 DestPeerAddress /32を取っておいてください。 数えてください。 #
Brownlee Informational [Page 13] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[13ページ]のRFC2723SRL: 交通の流れ言語1999年10月
This program counts only IP packets, saving SourceTransType (tcp, udp
or 0), Source- and DestPeerAddress (32-bit IP addresses) and FlowKind
('W' for www, 'F' for ftp, 'T' for telnet, '?' for unclassified).
The program uses a NOMATCH action to specify the packet direction -
its resulting flows will have the well-known ports as their
destination.
このプログラムはIPパケットだけを数えます、SourceTransType(tcp、udpまたは0)、Source、DestPeerAddress(32ビットのIPアドレス)、およびFlowKindを取っておいて(wwwのための'W'、ftpのための'F'、telnet、'?'のための'T'、非分類、) プログラムはパケット指示を指定するのにNOMATCH動作を使用します--結果として起こる流れには、それらの目的地としてウェルノウンポートがあるでしょう。
4.2 Classify Traffic into Groups of Networks
4.2は交通をネットワークグループに分類します。
#
# SRL program to classify traffic into network groups
#
define my_net = 130.216/16;
define k_nets = ( 130.217/16, 130.123/16, 130.195/16,
132.181/16, 138.75/16, 139.80/16 );
#
call net_kind (SourcePeerAddress, SourceKind)
endcall;
call net_kind (DestPeerAddress, DestKind)
endcall;
count;
#
subroutine net_kind (address addr, variable net)
if addr == my_net save, {
store net := 10; return 1;
}
else if addr == k_nets save, {
store net := 20; return 2;
}
save addr/24; # Not my_net or in k_nets
store net := 30; return 3;
endsub;
#
# # 交通をグループ#が私の_ネット=130.216/16に定義するネットワークに分類するSRLプログラム。 k_ネット=(130.217/16、130.123/16、130.195/16、132.181/16、138.75/16、139.80/16)を定義してください。 # ネットの_種類(SourcePeerAddress、SourceKind)のendcallに電話をしてください。 ネットの_種類(DestPeerAddress、DestKind)のendcallに電話をしてください。 数えてください。 # 私の_addr=ネットであるならサブルーチンのネットの_種類(addrを記述してください、可変ネット)を節約して、addr=k_ネットが保存されるなら、ほかに、ネットの:=10(リターン1)を格納してください、そして、ネットの:=20を格納してください; 返上2、addr/24を取っておいてください。 # _が店ネットの:=30を網で覆う私の_ネットでないコネkでない。 リターン3。 endsub。 #
The net_kind subroutine determines whether addr is my network (130.216), one of the Kawaihiko networks (in the k_nets list), or some other network. It saves the network address from addr (16 bits for my_net and the k_net networks, 24 bits for others), stores a value of 10, 20 or 30 in net, and returns to 1:, 2: or 3:. Note that the network numbers used are contained within the two DEFINEs, making them easy to change.
_のネットの種類のサブルーチンは、addrが私のネットワーク(130.216)、Kawaihikoネットワーク(k_ネットでは、記載する)の1つ、またはある他のネットワークであるかを決定します。 それがaddr(私の_ネットとk_のネットのネットワークのための16ビット、他のもののための24ビット)からのネットワーク・アドレスを保存して、ネットに10、20または30の値を格納して、以下を1に返す、2: または、3: . 彼らを変えるのを簡単にして、使用されるネットワーク・ナンバーが2DEFINEsの中に含まれていることに注意してください。
net_kind is called twice, saving Source- and DestPeerAddress and Source- and DestKind; the COUNT statement produces flows identified by these four RTFM attributes, with no particular source-dest ordering.
Source、DestPeerAddress、Source、およびDestKindを取っておいて、ネットの_種類は二度呼ばれます。 COUNT声明は特定のソース-destが注文されないでこれらの4つのRTFM属性によって特定された流れを発生させます。
Brownlee Informational [Page 14] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[14ページ]のRFC2723SRL: 交通の流れ言語1999年10月
In the program no use is made of return numbers and they could have been omitted. However, we might wish to re-use the subroutine in another program doing different things for different return numbers, as in the version below.
プログラムでは、リターン番号で無駄をします、そして、それらを省略したかもしれません。 しかしながら、異なったリターン番号のために別物をしながら、別のプログラムでサブルーチンを再使用するかもしれなくたいと思います、以下のバージョンのように。
call net_kind (DestPeerAddress, DestKind)
1: nomatch; # We want my_net as source
endcall;
call net_kind (SourcePeerAddress, SourceKind)
1: count; # my_net -> other networks
endcall;
save SourcePeerAddress /24;
save DestPeerAddress /24;
count;
ネットの_種類(DestPeerAddress、DestKind)の1に電話をしてください: nomatch。 # 私たちは、ソースendcallとして私の_ネットが欲しいと思います。 ネットの_種類(SourcePeerAddress、SourceKind)の1に電話をしてください: 数えてください。 # ->他の私の_ネットネットワークendcall。 SourcePeerAddress /24を取っておいてください。 DestPeerAddress /24を取っておいてください。 数えてください。
This version uses a NOMATCH statement to ensure that its resulting flows have my_net as their source. The NOMATCH also rejects my_net -> my_net traffic. Traffic which doesn't have my_net as source or destination saves 24 bits of its peer addresses (the subroutine might only have saved 16) before counting such an unusual flow.
このバージョンは、結果として起こる流れには彼らのソースとして私の_ネットがあるのを保証するのにNOMATCH声明を使用します。 また、NOMATCHは私の_が交通を網で覆う私の_ネット->を拒絶します。 そのようなものを数える前に、ソースか目的地が同輩の24ビットを節約するとき私の_ネットを持っていない交通が珍しい流れを記述します(サブルーチンは16しか救わなかったかもしれません)。
5 Security Considerations
5 セキュリティ問題
SRL is a language for creating rulesets (i.e. configuration files) for RTFM Traffic Meters - it does not present any security issues in itself.
SRLはRTFM Traffic Metersのために、rulesets(すなわち、構成ファイル)を作成するための言語です--それは本来少しの安全保障問題も提示しません。
On the other hand, flow data gathered using such rulesets may well be valuable. It is therefore important to take proper precautions to ensure that access to the meter and its data is secure. Ways to achieve this are discussed in detail in the Architecture and Meter MIB documents [RTFM-ARC, RTFM-MIB].
他方では、そのようなrulesetsを使用することで集められたフロー・データはたぶん貴重でしょう。 したがって、メーターへのアクセスとそのデータが確実に安全になるようにするために適当な用心するのは重要です。 ArchitectureとMeter MIBドキュメント[RTFM-ARC、RTFM-MIB]で詳細にこれを達成する方法について議論します。
6 IANA Considerations
6 IANA問題
Appendix C below lists the RTFM attributes by name. Since SRL only refers to attributes by name, SRL users do not have to know the attribute numbers.
以下の付録Cは名前のRTFM属性を記載します。 SRLが名前の属性について言及するだけであるので、SRLのユーザは属性番号を知る必要はありません。
The size (in bytes) of the various attribute values is also listed in Appendix C. These sizes reflect the object sizes for the attribute values as they are stored in the RTFM Meter MIB [RTFM-MIB].
また、様々な属性値のサイズ(バイトによる)はAppendix C.に記載されています。それらがRTFM Meter MIB[RTFM-MIB]に格納されるとき、Theseサイズは属性値のために物のサイズを反映します。
IANA considerations for allocating new attributes are discussed in detail in the RTFM Architecture document [RTFM-ARC].
RTFM Architectureドキュメント[RTFM-ARC]で詳細に新しい属性を割り当てるためのIANA問題について議論します。
Brownlee Informational [Page 15] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[15ページ]のRFC2723SRL: 交通の流れ言語1999年10月
7 APPENDICES
7個の付録
7.1 Appendix A: SRL Syntax in BNF
7.1 付録A: BNFのSRL構文
<SRL program> ::= <S or D> | <SRL program> <S or D>
<SRLプログラム>:、:= <SかD>。| <SRLのプログラム><SかD>。
<S or D> ::= <statement> | <declaration>
<SかD>:、:= <声明>。| <宣言>。
<declaration> ::= <Subroutine declaration>
<宣言>:、:= <サブルーチン宣言>。
<statement> ::= <IF statement> |
<Compound statement> |
<Imperative statement> |
<CALL statement>
<声明>:、:= <、声明>です。| <複合文>。| <無条件命令>。| <CALL声明>。
<IF statement> ::= IF <expression> <if action> <opt else>
<、以下のこと、声明>であるなら:= <表現><であるなら、動作><であるならほかの>を選んでください。
<if action> ::= SAVE ; |
SAVE , <statement> |
<statement>
<、以下のこと、動作>であるなら:= 節約してください。 | セーブ、<声明>。| <声明>。
<opt else> ::= <null> |
ELSE <statement>
<はほかの>を選びます:、:= <のヌル>。| ほかの<声明>。
<expression> ::= <term> | <term> || <term>
<表現>:、:= <用語>。| <用語>。|| <用語>。
<term> ::= <factor> | <factor> && <factor>
<用語>:、:= <要素>。| <要素>、<要素>。
<factor> ::= <attribute> == <operand list> |
( <expression> )
<要素>:、:= <<属性>=オペランド・リスト>。| (<表現>)
<operand list> ::= <operand> | ( <actual operand list> )
<オペランド・リスト>:、:= <オペランド>。| (<の実際のオペランド・リスト>)
<actual operand list> ::= <operand> |
<actual operand list> , <operand>
<の実際のオペランド・リスト>:、:= <オペランド>。| <の実際のオペランド・リスト>、<オペランド>。
<operand> ::= <value> |
<value> / <width> |
<value> & <mask>
<オペランド>:、:= <値の>。| <値の>/<幅の>。| <値の>と<マスク>。
<Compound statement> ::= <opt label> { <statement seq> }
<複合文>:、:= <はラベル>を選びます。<声明seq>。
<opt label> ::= <null> |
<identifier> :
<はラベル>を選びます:、:= <のヌル>。| <識別子>:
<statement seq> ::= <statement> | <statement seq> <statement>
<声明seq>:、:= <声明>。| <声明seq><声明>。
<Imperative statement> ::= ; |
<無条件命令>:、:= ; |
Brownlee Informational [Page 16] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[16ページ]のRFC2723SRL: 交通の流れ言語1999年10月
SAVE <attribute> <opt operand> ; |
COUNT ; |
EXIT <label> ; |
IGNORE ; |
NOMATCH ; |
RETURN <integer> ; |
RETURN ; |
STORE <variable> := <value> ;
SAVE<属性><はオペランド>を選びます。 | 数えてください。 | <ラベル>を出てください。 | 無視します。 | NOMATCH。 | <整数>を返してください。 | 戻ってください。 | <の可変>:=<値の>を格納してください。
<opt operand> ::= <null> |
<width or mask> |
= <operand>
<はオペランド>を選びます:、:= <のヌル>。| <幅かマスク>。| = <オペランド>。
<width or mask> ::= / <width> | & <mask>
<幅かマスク>:、:= /<幅の>。| <マスク>。
<Subroutine declaration> ::=
SUBROUTINE <sub header> <sub body> ENDSUB ;
<サブルーチン宣言>:、:= SUBROUTINE<潜水艦ヘッダー><潜水艦ボディー>ENDSUB。
<sub header> ::= <subname> ( ) |
<subname> ( <sub param list> )
<潜水艦ヘッダー>:、:= <「副-名前」>( )| <「副-名前」>。(<潜水艦paramリスト>)
<sub param list> ::= <sub param> | <sub param list> , <sub param>
<潜水艦paramリスト>:、:= <潜水艦param>。| <潜水艦paramリスト>、<潜水艦param>。
<sub param> ::= ADDRESS <pname> | VARIABLE <pname>
<潜水艦param>:、:= アドレス<pname>。| 可変<pname>。
<pname> ::= <identifier>
<pname>:、:= <識別子>。
<sub body> ::= <statement sequence>
<潜水艦ボディー>:、:= <声明系列>。
<CALL statement> ::= CALL <call header> <opt call body> ENDCALL ;
<CALL声明>:、:= CALL<呼び出しヘッダー><は呼び出し本体>ENDCALLを選びます。
<call header> ::= <subname> ( ) |
<subname> ( <call param list> )
<呼び出しヘッダー>:、:= <「副-名前」>( )| <「副-名前」>。(<呼び出しparamリスト>)
<call param list> ::= <call param> |
<call param list> , <call param>
<呼び出しparamリスト>:、:= <呼び出しparam>。| <呼び出しparamリスト>、<呼び出しparam>。
<call param> ::= <attribute> | <variable>
<呼び出しparam>:、:= <属性>。| <の可変>。
<opt call body> ::= <null> |
<actual call body>
<は呼び出し本体>を選びます:、:= <のヌル>。| <の実際の呼び出しボディー>。
<actual call body> ::= <numbered statement> |
<actual call body> <numbered statement>
<の実際の呼び出しボディー>:、:= <は声明>に付番しました。| <の実際の呼び出しボディー><は声明>に付番しました。
<numbered statement> ::= <int label seq> <statement>
<は声明>に付番しました:、:= <intラベルseq><声明>。
<int label seq> ::= <integer> : | <int label seq> <integer> :
<intラベルseq>:、:= <整数>: | <intラベルseq><整数>:
Brownlee Informational [Page 17] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[17ページ]のRFC2723SRL: 交通の流れ言語1999年10月
The following are terminals, recognised by the scanner:
↓これはスキャナによって認識された端末です:
<identifier> Described in section 2
<integer> A decimal integer
セクション2<整数>A小数整数における<識別子>Described
<attribute> Attribute name, as listed in Appendix C
AttributeがAppendix Cに記載されているように命名する<属性>。
<value>, <mask> Described in section 5.2
<値の>、セクション5.2の<マスク>Described
<width> ::= <integer>
<label> ::= <identifier>
<幅の>:、:= <整数><ラベル>:、:= <識別子>。
<variable> ::= SourceClass | DestClass | FlowClass |
SourceKind | DestKind | FlowKind
<の可変>:、:= SourceClass| DestClass| FlowClass| SourceKind| DestKind| FlowKind
7.2 Appendix B: Syntax for Values and Masks
7.2 付録B: 値と仮面のための構文
Values and masks consist of sequences of numeric fields, each of one or more bytes. The non-blank character following a field indicates the field width, and whether the number is decimal or hexadecimal. These 'field type' characters may be:
値とマスクは数字フィールドの系列、それぞれ1バイト以上から成ります。 野原に続く非ブランクは欄の幅と、数が10進であるか、そして、16進を示します。 これらの'フィールド・タイプ'キャラクタは以下の通りです。
. period decimal, single byte
- minus hex, single byte
! exclaim decimal, two bytes
. 期間の10進の、そして、単一のバイト--マイナス十六進法、単一のバイト!、小数、2バイトを主張してください。
For example, 130.216.0.0 is an IP address (in dotted decimal), and FF-FF-00-00 is an IP address in hexadecimal.
例えば、130.216 .0 .0はIPアドレス(ドット付き10進法における)であり、FF-FF-00-00は16進のIPアドレスです。
The last field of a value or mask has no field width character. Instead it takes the same width as the preceding field. For example, 1.3.10!50 and 1.3.0.10.0.50 are two different ways to specify the same value.
値かマスクの最後の分野には、欄の幅キャラクタが全くありません。 代わりに、それは前の分野と同じ幅を取ります。 そして、例えば、1.3 .10、!50、1.3 .0 .10 .0 .50は同じ値を指定する2つの異なった方法です。
Unspecified fields (at the right-hand side of a value or mask) are set to zero, i.e. 130.216 is the same as 130.216.0.0.
不特定の分野(値かマスクの右側の)はゼロに設定されます、すなわち、130.216が130.216と同じです。.0 .0。
If only a single field is specified (no field width character), the value given fills the whole field. For example, 23 and 0.23 specify the same value for a SourceTransAddress operand. For variables (which have one-byte values) a C-style character constant may also be used.
ただ一つの分野だけが指定されるなら(欄の幅キャラクタがありません)、与えられた値は全体の分野をいっぱいにしています。 例えば、23と0.23はSourceTransAddressオペランドに同じ値を指定します。 また、変数(1バイトの値を持っている)のために、C-スタイル文字定数は使用されるかもしれません。
IPv6 addresses and masks may also be used, following the conventions set out in the IP Version 6 Addressing Architecture RFC [V6-ADR].
また、IPv6アドレスとマスクは使用されるかもしれません、IPバージョン6Addressing Architecture RFC[V6-ADR]でコンベンションセットを最期までやり通して。
Brownlee Informational [Page 18] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[18ページ]のRFC2723SRL: 交通の流れ言語1999年10月
7.3 Appendix C: RTFM Attribute Information
7.3 付録C: RTFM属性情報
The following attributes may be tested in an IF statement, and their values may be SAVEd (except for MatchingStoD). Their maximum size (in bytes) is shown to the left, and a brief description is given for each. The names given here are reserved words in SRL (they are <attribute> terminals in the grammar given in Appendix A).
以下の属性がテストされるかもしれない、声明、およびそれらの値がそうするかもしれないなら、SAVEd(MatchingStoDを除いた)になってください。 それらの最大サイズ(バイトによる)を左に示します、そして、それぞれのために簡単な説明を与えます。 ここに与えられた名前はSRLのリザーブドワード(それらはAppendix Aで与えられた文法の<属性>端末である)です。
Note that this table gives only a very brief summary. The Meter MIB [RTFM-MIB] provides the definitive specification of attributes and their allowed values. The MIB variables which represent flow attributes have 'flowData' prepended to their names to indicate that they belong to the MIB's flowData table.
このテーブルが非常に簡潔な概要だけをすることに注意してください。 Meter MIB[RTFM-MIB]は属性の決定的な仕様とそれらの許容値を提供します。 流れ属性を表すMIB変数で、MIBのflowDataテーブルに属すのを示すために'flowData'をそれらの名前にprependedします。
1 SourceInterface, DestInterface
Interface(s) on which the flow was observed
1 SourceInterface、流れが観測されたDestInterface Interface(s)
1 SourceAdjacentType, DestAdjacentType
Indicates the interface type(s), i.e. an ifType from [ASG-NBR],
or an Address Family Number (if metering within a tunnel)
1 すなわち、SourceAdjacentType、インターフェース型のDestAdjacentType Indicates、[ASG-NBR]、またはAddress Family NumberからのifType(トンネルの中で計量するなら)
0 SourceAdjacentAddress, DestAdjacentAddress
For IEEE 802.x interfaces, the MAC addresses for the flow
0SourceAdjacentAddress、MACが流れのために記述するDestAdjacentAddress For IEEE 802.xインタフェース
1 SourcePeerType, DestPeerType
Peer protocol types, i.e. Address Family Number from [ASG-NBR],
such as IPv4, Novell, Ethertalk, ..
1 SourcePeerType、DestPeerType Peerは[ASG-NBR]からのタイプ、すなわち、IPv4、ノベル、EthertalkなどのAddress Family Numberについて議定書の中で述べます。
0 SourcePeerAddress, DestPeerAddress
Peer Addresses (size varies, e.g. 4 for IPv4, 3 for Ethertalk))
0SourcePeerAddress、DestPeerAddress Peer Addresses、(サイズが異なる、例えば、IPv4、Ethertalkのための3のための4)
1 SourceTransType, DestTransType
Transport layer type, i.e. Protocol Number from [ASG-NBR]
such as tcp(6), udp(17), ospf(89), ..
1 SourceTransType、DestTransType Transportはtcp(6)、udp(17)、ospf(89)などの[ASG-NBR]からタイプ、すなわち、プロトコルNumberを層にします。
2 SourceTransAddress, DestTransAddress
Transport layer addresses (e.g. port numbers for TCP and UDP)
2SourceTransAddress、DestTransAddress Transport層のアドレス(例えば、TCPとUDPのためのポートナンバー)
1 FlowRuleset
Rule set number for the flow
1 FlowRuleset Ruleは流れの数を設定します。
1 MatchingStoD
Indicates whether the packet is being matched with its
addresses in 'wire order.' See [RTFM-ARC] for details.
1MatchingStoD Indicatesがパケットが存在であるか否かに関係なく、詳細のための'ワイヤオーダー'See[RTFM-ARC]のアドレスに合わせました。
The following variables may be tested in an IF, and their values may be set by a STORE. They all have one-byte values.
以下の変数がテストされるかもしれない、それらの値はストアによって設定されるかもしれません。 彼らには皆、1バイトの値があります。
Brownlee Informational [Page 19] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[19ページ]のRFC2723SRL: 交通の流れ言語1999年10月
SourceClass, DestClass, FlowClass,
SourceKind, DestKind, FlowKind
SourceClass、DestClass、FlowClass、SourceKind、DestKind、FlowKind
The following RTFM attributes are not address attributes - they are measured attributes of a flow. Their values may be read from an RTFM meter. (For example, NeTraMet uses a FORMAT statement to specify which attribute values are to be read from the meter.)
以下のRTFM属性はアドレス属性ではありません--それらは流れの測定属性です。 それらの値はRTFMメーターから読まれるかもしれません。 (例えば、NeTraMetはメーターから読まれるために属性値がどれであるかを指定するのにFORMAT声明を使用します。)
8 ToOctets, FromOctets
Total number of octets seen for each direction of the flow
8ToOctets、流れの各方向に関して見られた八重奏のFromOctets Total番号
8 ToPDUs, FromPDUs
Total number of PDUs seen for each direction of the flow
8ToPDUs、流れの各方向に関して見られたPDUsのFromPDUs Total番号
4 FirstTime, LastActiveTime
Time (in centiseconds) that first and last PDUs were seen
for the flow
4FirstTime、1番目と最後のPDUsが見られたLastActiveTime Time(センチセカンドにおける)、流れ
Other attributes will be defined by the RTFM working group from time to time.
他の属性は時々RTFMワーキンググループによって定義されるでしょう。
8 Acknowledgments
8つの承認
The SRL language is part of the RTFM Working Group's efforts to make the RTFM traffic measurement system easier to use. Initial work on the language was done by Cyndi Mills and Brad Frazee in Boston. SRL was developed in Auckland; it was greatly assisted by detailed discussion with John White and Russell Fulton. Discussion has continued on the RTFM and NeTraMet mailing lists.
SRL言語はRTFMトラフィック測定システムを使用するのをより簡単にするためのRTFM作業部会の努力の一部です。 言語に対する初期の仕事がボストンでシンディ・ミルズとブラッド・フラジーによって行われました。 SRLはオークランドで発展しました。 それはジョン・ホワイトとラッセル・フルトンとの詳細な論議で大いに補助されました。 議論はRTFMとNeTraMetメーリングリストで続きました。
9 References
9つの参照箇所
[ASG-NBR] Reynolds, J. and J. Postel, "Assigned Numbers",
STD 2, RFC 1700, October 1994.
[ASG-NBR] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[NETRAMET] Brownlee, N., NeTraMet home page,
http://www.auckland.ac.nz/net/NeTraMet
[NETRAMET] ブラウンリー、N.、NeTraMetホームページ、 http://www.auckland.ac.nz/net/NeTraMet
[RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
Measurement: Architecture", RFC 2722, October 1999.
[RTFM-アーク] ブラウンリー、N.、工場、C.、およびG.ルース、「流量測定を取引してください」 「構造」、RFC2722、1999年10月。
[RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB",
RFC 2720, October 1999.
[RTFM-MIB]ブラウンリー、N.、「流量測定を取引してください」 「メーターMIB」、1999年10月のRFC2720。
[V6-ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture," RFC 2373, July 1998.
[V6-ADDR] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
Brownlee Informational [Page 20] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[20ページ]のRFC2723SRL: 交通の流れ言語1999年10月
10 Author's Address
10作者のアドレス
Nevil Brownlee Information Technology Systems & Services The University of Auckland Private Bag 92-019 Auckland, New Zealand
ネヴィルブラウンリー情報技術システムとServicesオークランド大学の個人的なBag92-019オークランド(ニュージーランド)
Phone: +64 9 373 7599 x8941 EMail: n.brownlee@auckland.ac.nz
以下に電話をしてください。 +64 9 373 7599x8941 EMail: n.brownlee@auckland.ac.nz
Brownlee Informational [Page 21] RFC 2723 SRL: A Traffic Flow Language October 1999
ブラウンリー情報[21ページ]のRFC2723SRL: 交通の流れ言語1999年10月
11 Full Copyright Statement
11 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Brownlee Informational [Page 22]
ブラウンリーInformationalです。[22ページ]
一覧
スポンサーリンク
