Network Working Group R. Finking
Request for Comments: 4997 Siemens/Roke Manor Research
Category: Standards Track G. Pelletier
Ericsson
July 2007
Formal Notation for RObust Header Compression (ROHC-FN)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document defines Robust Header Compression - Formal Notation (ROHC-FN), a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework. ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help to simplify future profile development work.
正式な表記（ROHC-FN）、ROHCフレームワーク内で、新しいプロファイルを定義する際に、圧縮フォーマットのフィールドのエンコーディングを指定するための正式な表記法 - この文書では、ロバストヘッダ圧縮を定義します。 ROHC-FNは、多くの場合、ROHCプロファイルに使用され、それによって将来のプロファイル開発作業を簡素化するために助けることができる符号化方式のライブラリを提供しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of ROHC-FN . . . . . . . . . . . . . . . . . . . . . 5
3.1. Scope of the Formal Notation . . . . . . . . . . . . . . . 6
3.2. Fundamentals of the Formal Notation . . . . . . . . . . . 7
3.2.1. Fields and Encodings . . . . . . . . . . . . . . . . . 7
3.2.2. Formats and Encoding Methods . . . . . . . . . . . . . 9
3.3. Example Using IPv4 . . . . . . . . . . . . . . . . . . . . 11
4. Normative Definition of ROHC-FN . . . . . . . . . . . . . . . 13
4.1. Structure of a Specification . . . . . . . . . . . . . . . 13
4.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Constant Definitions . . . . . . . . . . . . . . . . . . . 15
4.4. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.1. Attribute References . . . . . . . . . . . . . . . . . 17
4.4.2. Representation of Field Values . . . . . . . . . . . . 17
4.5. Grouping of Fields . . . . . . . . . . . . . . . . . . . . 17
4.6. "THIS" . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.7. Expressions . . . . . . . . . . . . . . . . . . . . . . . 19
4.7.1. Integer Literals . . . . . . . . . . . . . . . . . . . 20
4.7.2. Integer Operators . . . . . . . . . . . . . . . . . . 20
4.7.3. Boolean Literals . . . . . . . . . . . . . . . . . . . 20
4.7.4. Boolean Operators . . . . . . . . . . . . . . . . . . 20
4.7.5. Comparison Operators . . . . . . . . . . . . . . . . . 21
4.8. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.9. "ENFORCE" Statements . . . . . . . . . . . . . . . . . . . 22
4.10. Formal Specification of Field Lengths . . . . . . . . . . 23
4.11. Library of Encoding Methods . . . . . . . . . . . . . . . 24
4.11.1. uncompressed_value . . . . . . . . . . . . . . . . . . 24
4.11.2. compressed_value . . . . . . . . . . . . . . . . . . . 25
4.11.3. irregular . . . . . . . . . . . . . . . . . . . . . . 26
4.11.4. static . . . . . . . . . . . . . . . . . . . . . . . . 27
4.11.5. lsb . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.11.6. crc . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.12. Definition of Encoding Methods . . . . . . . . . . . . . . 29
4.12.1. Structure . . . . . . . . . . . . . . . . . . . . . . 30
4.12.2. Arguments . . . . . . . . . . . . . . . . . . . . . . 37
4.12.3. Multiple Formats . . . . . . . . . . . . . . . . . . . 38
4.13. Profile-Specific Encoding Methods . . . . . . . . . . . . 40
5. Security Considerations . . . . . . . . . . . . . . . . . . . 41
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1. Normative References . . . . . . . . . . . . . . . . . . . 42
8.2. Informative References . . . . . . . . . . . . . . . . . . 42
Appendix A. Formal Syntax of ROHC-FN . . . . . . . . . . . . . . 43
Appendix B. Bit-level Worked Example . . . . . . . . . . . . . . 45
B.1. Example Packet Format . . . . . . . . . . . . . . . . . . 45
B.2. Initial Encoding . . . . . . . . . . . . . . . . . . . . . 46
B.3. Basic Compression . . . . . . . . . . . . . . . . . . . . 47
B.4. Inter-Packet Compression . . . . . . . . . . . . . . . . . 48
B.5. Specifying Initial Values . . . . . . . . . . . . . . . . 50
B.6. Multiple Packet Formats . . . . . . . . . . . . . . . . . 51
B.7. Variable Length Discriminators . . . . . . . . . . . . . . 53
B.8. Default Encoding . . . . . . . . . . . . . . . . . . . . . 55
B.9. Control Fields . . . . . . . . . . . . . . . . . . . . . . 56
B.10. Use of "ENFORCE" Statements as Conditionals . . . . . . . 59
Robust Header Compression - Formal Notation (ROHC-FN) is a formal notation designed to help with the definition of ROHC [RFC4995] header compression profiles. Previous header compression profiles have been so far specified using a combination of English text together with ASCII Box notation. Unfortunately, this was sometimes unclear and ambiguous, revealing the limitations of defining complex structures and encodings for compressed formats this way. The primary objective of the Formal Notation is to provide a more rigorous means to define header formats -- compressed and uncompressed -- as well as the relationships between them. No other formal notation exists that meets these requirements, so ROHC-FN aims to meet them.
ロバストヘッダ圧縮 - フォーマル記法（ROHC-FN）はROHC [RFC4995]ヘッダ圧縮プロファイルの定義を支援するように設計された正式な表記法です。前のヘッダ圧縮プロファイルは、これまでのASCIIボックス記法と一緒に英語のテキストの組み合わせを使用して指定されています。残念ながら、これは、圧縮形式のため、このように複雑な構造とエンコーディングを定義するの限界を明らかにし、時には不明確で曖昧でした。圧縮と非圧縮 - - だけでなく、それらの間の関係正式表記の主な目的は、ヘッダフォーマットを定義するためのより厳格な手段を提供することです。他の正式表記はROHC - FNがそれらを満たすことを目指して、これらの要件を満たしていることを存在しません。
In addition, ROHC-FN offers a library of encoding methods that are often used in ROHC profiles, so that the specification of new profiles using the formal notation can be achieved without having to redefine this library from scratch. Informally, an encoding method defines a two-way mapping between uncompressed data and compressed data.
また、ROHC-FNは、正式な表記法を使用して、新しいプロファイルの仕様はスクラッチからこのライブラリを再定義することなく達成することができるように、多くの場合、ROHCプロファイルに使用される符号化方式のライブラリを提供します。非公式に、符号化方法は、非圧縮データと圧縮データとの間の双方向のマッピングを定義します。
o Compressed format
O圧縮フォーマット
A compressed format consists of a list of fields that provides bindings between encodings and the fields it compresses. One or more compressed formats can be combined to represent an entire compressed header format.
圧縮フォーマットは、符号化し、それが圧縮フィールド間のバインディングを提供するフィールドのリストから成ります。一つ以上の圧縮フォーマットは、全圧縮ヘッダフォーマットを表現するために組み合わせることができます。
o Context
Oコンテキスト
Context is information about the current (de)compression state of the flow. Specifically, a context for a specific field can be either uninitialised, or it can include a set of one or more values for the field's attributes defined by the compression algorithm, where a value may come from the field's attributes corresponding to a previous packet. See also a more generalized definition in Section 2.2 of [RFC4995].
コンテキストは、フローの現在の（デ）圧縮状態についての情報です。具体的には、特定のフィールドのコンテキストが初期化されていないことができるか、その値が以前のパケットに対応するフィールドの属性から来るかもしれない圧縮アルゴリズムによって定義されたフィールドの属性の1つ以上の値のセットを含むことができます。また、[RFC4995]のセクション2.2で、より一般的な定義を参照してください。
o Control field
O制御フィールド
Control fields are transmitted from a ROHC compressor to a ROHC decompressor, but are not part of the uncompressed header itself.
制御フィールドは、ROHCデコンプレッサへROHC圧縮器から送信されたが、非圧縮ヘッダ自体の一部ではありません。
o Encoding method, encodings
Oエンコーディング方法、エンコーディング
Encoding methods are two-way relations that can be applied to compress and decompress fields of a protocol header.
符号化方法は、プロトコルヘッダのフィールドを圧縮及び解凍するために適用することができる双方向の関係です。
o Field
お ふぃえｌｄ
The protocol header is divided into a set of contiguous bit patterns known as fields. Each field is defined by a collection of attributes that indicate its value and length in bits for both the compressed and uncompressed headers. The way the header is divided into fields is specific to the definition of a profile, and it is not necessary for the field divisions to be identical to the ones given by the specification(s) for the protocol header being compressed.
プロトコルヘッダがフィールドとして知られている連続したビットパターンのセットに分割されます。各フィールドは、両方の圧縮と非圧縮ヘッダのビットでその値と長さを示す属性の集合によって定義されます。ヘッダフィールドに分割されている方法は、プロファイルの定義に固有であり、フィールド区分が圧縮されるプロトコルヘッダの仕様（S）によって与えられたものと同一であることが必要ではありません。
o Library of encoding methods
符号化方式のOライブラリ
The library of encoding methods contains a number of commonly used encoding methods for compressing header fields.
符号化方法のライブラリーは、ヘッダフィールドを圧縮するための一般的に使用される符号化方式の数を含んでいます。
o Profile
Oプロファイル
A ROHC [RFC4995] profile is a description of how to compress a certain protocol stack. Each profile consists of a set of formats (for example, uncompressed and compressed formats) along with a set of rules that control compressor and decompressor behaviour.
ROHC [RFC4995]プロフィールは、特定のプロトコル・スタックを圧縮する方法について説明します。各プロファイルは、コンプレッサとデコンプレッサの動作を制御する規則のセットと一緒に（例えば、非圧縮および圧縮フォーマット）形式のセットからなります。
o ROHC-FN specification
O ROHC - FN仕様
The specification of the set of formats of a ROHC profile using ROHC-FN.
ROHC-FNを用いROHCプロファイルのフォーマットのセットの仕様。
o Uncompressed format
O非圧縮フォーマット
An uncompressed format consists of a list of fields that provides the order of the fields to be compressed for a contiguous set of bits whose bit layout corresponds to the protocol header being compressed.
非圧縮形式は、ビットレイアウト圧縮されるプロトコルヘッダに対応するビットの連続した組のために圧縮されるフィールドの順序を提供するフィールドのリストから成ります。
This section gives an overview of ROHC-FN. It also explains how ROHC-FN can be used to specify the compression of header fields as part of a ROHC profile.
このセクションでは、ROHC-FNの概要を説明します。それはまた、ROHC-FNは、ROHCプロファイルの一部としてヘッダフィールドの圧縮を指定するために使用することができる方法を説明します。
This section explains how the formal notation relates to the ROHC framework and to specifications of ROHC profiles.
このセクションでは、正式な表記はROHCフレームワークへとROHCプロファイルの仕様に関連する方法について説明します。
The ROHC framework [RFC4995] provides the general principles for performing robust header compression. It defines the concept of a profile, which makes ROHC a general platform for different compression schemes. It sets link layer requirements, and in particular negotiation requirements, for all ROHC profiles. It defines a set of common functions such as Context Identifiers (CIDs), padding, and segmentation. It also defines common formats (IR, IR-DYN, Feedback, Add-CID, etc.), and finally it defines a generic, profile independent, feedback mechanism.
ROHCフレームワーク[RFC4995]はロバストなヘッダ圧縮を行うための一般的な原理を提供します。これは、ROHC異なる圧縮方式のための一般的なプラットフォームを作るプロファイルの概念を定義します。これは、すべてのROHCプロファイルのため、および特定の交渉の要求で、リンク層の要件を設定します。そのようなコンテキスト識別子（CIDを）、パディング、及びセグメンテーションなどの一般的な機能のセットを定義します。また、一般的なフォーマット（IR、IR-DYN、フィードバック、追加-CIDなど）を定義し、最終的には、一般的な、プロファイルの独立した、フィードバックメカニズムを定義します。
A ROHC profile is a description of how to compress a certain protocol stack. For example, ROHC profiles are available for RTP/UDP/IP and many other protocol stacks.
ROHCプロファイルは、特定のプロトコル・スタックを圧縮する方法について説明します。例えば、ROHCプロファイルは、RTP / UDP / IPおよび他の多くのプロトコルスタックのために用意されています。
At a high level, each ROHC profile consists of a set of formats (defining the bits to be transmitted) along with a set of rules that control compressor and decompressor behaviour. The purpose of the formats is to define how to compress and decompress headers. The formats define one or more compressed versions of each uncompressed header, and simultaneously define the inverse: how to relate a compressed header back to the original uncompressed header.
ハイレベルで、各ROHCプロファイルは、コンプレッサとデコンプレッサの動作を制御する規則のセットと一緒に（送信すべきビットを定義する）形式のセットからなります。フォーマットの目的は、ヘッダを圧縮して解凍する方法を定義することです。フォーマットは、各非圧縮ヘッダの一つ以上の圧縮されたバージョンを定義し、同時に逆定義：元の非圧縮ヘッダの圧縮ヘッダに関連する方法を。
The set of formats will typically define compression of headers relative to a context of field values from previous headers in a flow, improving the overall compression by taking into account redundancies between headers of successive packets. Therefore, in addition to defining the formats, a profile has to:
フォーマットのセットは、典型的には、連続したパケットのヘッダとの間にアカウント冗長性を考慮することによって、全体的な圧縮を改善する、フロー内の前のヘッダからフィールド値のコンテキストに対するヘッダの圧縮を定義します。したがって、フォーマットを定義することに加えて、プロファイルがなければなりません。
o specify how to manage the context for both the compressor and the decompressor,
O、圧縮及び解凍器の両方のコンテキストを管理する方法を指定します
o define when and what to send in feedback messages, if any, from decompressor to compressor,
O際に、何があれば解凍器から圧縮機に、フィードバックメッセージで送信するために定義し、
o outline compression principles to make the profile robust against bit errors and dropped packets.
Oアウトライン圧縮の原則は、ビットエラーに対する堅牢なプロファイルを作成し、パケットをドロップします。
All this is needed to ensure that the compressor and decompressor contexts are kept consistent with each other, while still facilitating the best possible compression performance.
このすべては、まだ可能な限り最高の圧縮性能を容易にしつつ、コンプレッサーと減圧器コンテキストは、相互に一貫性が保たれていることを確認するために必要とされます。
The ROHC-FN is designed to help in the specification of compressed formats that, when put together based on the profile definition, make up the formats used in a ROHC profile. It offers a library of encoding methods for compressing fields, and a mechanism for combining these encoding methods to create compressed formats tailored to a specific protocol stack.
ROHC - FNは、プロファイルの定義に基づいてまとめ、圧縮フォーマットの仕様に役立つように設計された、ROHCプロファイルで使用されるフォーマットを構成しています。これは、フィールドを圧縮するための符号化方式のライブラリ、および特定のプロトコルスタックに合わせた圧縮フォーマットを作成するために、これらの符号化方式を組み合わせるためのメカニズムを提供しています。
The scope of ROHC-FN is limited to specifying the relationship between the compressed and uncompressed formats. To form a complete profile specification, the control logic for the profile behaviour needs to be defined by other means.
ROHC-FNの範囲は、圧縮と非圧縮フォーマット間の関係を指定する制限されています。プロフィール仕様を形成するために、プロファイル動作の制御ロジックは、他の手段によって定義される必要があります。
There are two fundamental elements to the formal notation:
正式な表記法には2つの基本的な要素があります。
1. Fields and their encodings, which define the mapping between a header's uncompressed and compressed forms.
1.フィールドおよびヘッダの非圧縮および圧縮形式の間のマッピングを定義し、その符号化、。
2. Encoding methods, which define the way headers are broken down into fields. Encoding methods define lists of uncompressed fields and the lists of compressed fields they map onto.
方法ヘッダーを定義する2符号化方法は、フィールドに分解されます。符号化方式は、圧縮されていないフィールドのリストと、彼らは上にマッピングし、圧縮フィールドのリストを定義します。
These two fundamental elements are at the core of the notation and are outlined below.
これらの二つの基本的な要素は、表記のコアであり、以下に概説されています。
Headers are made up of fields. For example, version number, header length, and sequence number are all fields used in real protocols.
ヘッダは、フィールドで構成されています。例えば、バージョン番号、ヘッダ長、シーケンス番号は、実際のプロトコルで使用されるすべてのフィールドです。
Fields have attributes. Attributes describe various things about the field. For example:
フィールドは属性を持っています。属性はフィールドに関する様々な事柄について説明します。例えば：
field.ULENGTH
field.ULENGTH
The above indicates the uncompressed length of the field. A field is said to have a value attribute, i.e., a compressed value or an uncompressed value, if the corresponding length attribute is greater than zero. See Section 4.4 for more details on field attributes.
上記フィールドの非圧縮長さを示します。フィールドは、対応する長さ属性がゼロより大きい場合、すなわち、値属性、圧縮された値又は圧縮されていない値を有すると言われています。フィールド属性の詳細については、セクション4.4を参照してください。
The relationship between the compressed and uncompressed attributes of a field are specified with encoding methods, using the following notation:
フィールドの圧縮と非圧縮の属性間の関係は、以下の表記法を使用して、符号化方法で指定されています。
field =:= encoding_method;
フィールド=：=符号化方法。
In the field definition above, the symbol "=:=" means "is encoded by". This field definition does not represent an assignment operation from the right hand side to the left side. Instead, it is a two-way mapping between the compressed and uncompressed attributes of the field. It both represents the compression and the decompression operation in a single field definition, through a process of two-way matching.
上記のフィールドの定義において、記号「= =」「で符号化される」を意味します。このフィールドの定義は、右側から左側に代入演算を表すものではありません。代わりに、フィールドの圧縮と非圧縮の属性間の双方向のマッピングがあります。その両方が、双方向マッチングの過程を通して、単一のフィールド定義の圧縮および圧縮解除演算を表します。
Two-way matching is a binary operation that attempts to make the operands (i.e., the compressed and uncompressed attributes) match. This is similar to the unification process in logic. The operands represent one unspecified data object and one specified object. Values can be matched from either operand.
双方向マッチングは、オペランド（すなわち、圧縮および非圧縮の属性）が一致するしようとする二項演算です。これは、ロジックで統一プロセスと同様です。オペランドは、一個の不特定のデータオブジェクトと指定した1つのオブジェクトを表します。値は、いずれかのオペランドから一致させることができます。
During compression, the uncompressed attributes of the field are already defined. The given encoding matches the compressed attributes against them. During decompression, the compressed attributes of the field are already defined, so the uncompressed attributes are matched to the compressed attributes using the given encoding method. Thus, both compression and decompression are defined by a single field definition.
圧縮時には、フィールドの非圧縮属性がすでに定義されています。与えられたエンコーディングは、彼らに対して圧縮属性と一致します。減圧中に、フィールドの圧縮属性が既に定義されているので、圧縮されていない属性は、所定の符号化方式を用いて圧縮された属性に一致しています。したがって、圧縮および圧縮解除の両方を単一のフィールド定義によって定義されます。
Therefore, an encoding method (including any parameters specified) creates a reversible binding between the attributes of a field. At the compressor, a format can be used if a set of bindings that is successful for all the attributes in all its fields can be found. At the decompressor, the operation is reversed using the same bindings and the attributes in each field are filled according to the specified bindings; decoding fails if the binding for an attribute fails.
したがって、（指定されたパラメータを含む）符号化方法は、フィールドの属性との間の結合を可逆的に生成します。そのすべてのフィールド内のすべての属性のために成功しているバインディングのセットを見つけることができるならば、コンプレッサでは、フォーマットが使用することができます。減圧装置で、動作は同じバインディングを使用して反転され、各フィールドの属性は、指定されたバインディングに応じて充填されます。属性のバインディングが失敗した場合、デコードが失敗します。
For example, the "static" encoding method creates a binding between the attribute corresponding to the uncompressed value of the field and the corresponding value of the field in the context.
例えば、「静的な」符号化方法は、フィールドの圧縮されていない値に対応する属性とコンテキスト内のフィールドの対応する値との間の結合を生成します。
o For the compressor, the "static" binding is successful when both the context value and the uncompressed value are the same. If the two values differ then the binding fails.
コンテキスト値と圧縮されていない値の両方が同じである場合に圧縮機のO、結合「静的」が成功しています。二つの値は、結合が失敗し、その後異なる場合。
o For the decompressor, the "static" binding succeeds only if a valid context entry containing the value of the uncompressed field exists. Otherwise, the binding will fail.
減圧装置について、O、結合「静的」は圧縮されていないフィールドの値を含む有効なコンテキスト・エントリが存在する場合にのみ成功します。そうでない場合、結合は失敗します。
Both the compressed and uncompressed forms of each field are represented as a string of bits; the most significant bit first, of the length specified by the length attribute. The bit string is the binary representation of the value attribute of the field, modulo "2^length", where "length" is the length attribute of the field. However, this is only the representation of the bits exchanged between the compressor and the decompressor, designed to allow maximum compression efficiency. The FN itself uses the full range of integers. See Section 4.4.2 for further details.
両方の各フィールドの圧縮と非圧縮形式は、ビットのストリングとして表されています。長さ属性によって指定された長さの最初の最上位ビット、。ビット列が「長さ」フィールドの長さ属性のフィールド、モジュロ「2 ^長さ」の値属性のバイナリ表現です。しかし、これは単にビットの表現は、最大の圧縮効率を可能にするように設計された、圧縮装置と解凍との間で交換されます。 FN自体は、整数の完全な範囲を使用しています。詳細は、4.4.2項を参照してください。
The ROHC-FN provides a library of commonly used encoding methods. Encoding methods can be defined using plain English, or using a formal definition consisting of, for example, a collection of expressions (Section 4.7) and "ENFORCE" statements (Section 4.9).
ROHC-FNは、一般的に使用される符号化方式のライブラリを提供します。符号化方式は、平易な英語を使用して、またはからなる正式な定義を使用して定義することができ、例えば、式の集合（セクション4.7）と「ENFORCE」文（4.9節）。
ROHC-FN also provides mechanisms for combining fields and their encoding methods into higher level encoding methods following a well-defined structure. This is similar to the definition of functions and procedures in an ordinary programming language. It allows complexity to be handled by being broken down into manageable parts. New encoding methods are defined at the top level of a profile. These can then be used in the definition of other higher level encoding methods, and so on.
ROHC-FNはまた、明確に定義された構造次のより高いレベルの符号化方式にフィールドとその符号化方法を組み合わせるためのメカニズムを提供します。これは通常のプログラミング言語の関数や手続きの定義と同様です。これは、複雑さを管理可能な部分に分割されることによって処理されることを可能にします。新たな符号化方法は、プロファイルの最上位レベルで定義されています。これらは、次にように、他のより高いレベルの符号化方式の定義に使用することができます。
new_encoding_method // This block is an encoding method
{
UNCOMPRESSED { // This block is an uncompressed format
field_1 [ 16 ];
field_2 [ 32 ];
field_3 [ 48 ];
}
CONTROL { // This block defines control fields
ctrl_field_1;
ctrl_field_2;
}
DEFAULT { // This block defines default encodings
// for specified fields
ctrl_field_2 =:= encoding_method_2;
field_1 =:= encoding_method_1;
}
COMPRESSED format_0 { // This block is a compressed format
field_1;
field_2 =:= encoding_method_2;
field_3 =:= encoding_method_3;
ctrl_field_1 =:= encoding_method_4;
ctrl_field_2;
}
COMPRESSED format_1 { // This block is a compressed format
field_1;
field_2 =:= encoding_method_3;
field_3 =:= encoding_method_4;
ctrl_field_2 =:= encoding_method_5;
ctrl_field_3 =:= encoding_method_6; // This is a control field
// with no uncompressed value
}
}
In the example above, the encoding method being defined is called "new_encoding_method". The section headed "UNCOMPRESSED" indicates the order of fields in the uncompressed header, i.e., the uncompressed header format. The number of bits in each of the fields is indicated in square brackets. After this is another section, "CONTROL", which defines two control fields. Following this is the "DEFAULT" section which defines default encoding methods for two of the fields (see below). Finally, two alternative compressed formats follow, each defined in sections headed "COMPRESSED". The fields that occur in the compressed formats are either:
上記の例では、定義されている符号化方式は、「new_encoding_method」と呼ばれています。 「UNCOMPRESSED」頭部が非圧縮ヘッダ、すなわち、非圧縮ヘッダフォーマットのフィールドの順序を示しています。各フィールド内のビットの数は、角括弧内に示されています。これは、2つの制御フィールドを定義する別のセクション、「CONTROL」、した後。これは2つのフィールドのデフォルトのエンコード方法を定義し、「DEFAULT」セクションで、次の（下記参照）。最後に、二つの別の圧縮フォーマットは、それぞれが「圧縮」始まるセクションで定義され、従ってください。圧縮されたフォーマットで発生するフィールドのいずれかです：
o fields that occur in the uncompressed format; or
非圧縮形式で発生Oフィールド;または
o control fields that have an uncompressed value and that occur in the CONTROL section; or
圧縮されていない値と、制御部で発生を有するO制御フィールド。または
o control fields that do not have an uncompressed value and thus are defined as part of the compressed format.
圧縮されていない値を持っていないので、圧縮形式の一部として定義されている入出力制御フィールド。
Central to each of these formats is a "field list", which defines the fields contained in the format and also the order that those fields appear in that format. For the "DEFAULT" and "CONTROL" sections, the field order is not significant.
これらのフォーマットのそれぞれの中心はまた、フォーマットに含まれるフィールドとそれらのフィールドは、その形式で表示される順序を定義する「フィールドリスト」です。 「DEFAULT」と「CONTROL」のセクションでは、フィールドの順序は重要ではありません。
In addition to specifying field order, the field list may also specify bindings for any or all of the fields it contains. Fields that have no bindings defined for them are bound using the default bindings specified in the "DEFAULT" section (see Section 4.12.1.5).
フィールドの順序を指定することに加えて、フィールドリストはまた、含まれているフィールドのいずれかまたは全てのバインディングを指定することもできます。彼らのために定義されたバインディングを持っていないフィールドは、「DEFAULT」のセクション（セクション4.12.1.5を参照）で指定されたデフォルトのバインディングを使用してバインドされています。
Fields from the compressed format have the same name as they do in the uncompressed format. If there are any fields that are present exclusively in the compressed format, but that do have an uncompressed value, they must be declared in the "CONTROL" section of the definition of the encoding method (see Section 4.12.1.3 for more details on defining control fields).
彼らは非圧縮形式でそうであるように圧縮されたフォーマットからのフィールドは、同じ名前を持ちます。そこに圧縮形式で独占的に存在するすべてのフィールドがありますが、それは圧縮されていない値を持っている場合は、符号化方式の定義の「CONTROL」セクションで宣言する必要があります（定義についての詳細はセクション4.12.1.3を参照してください制御フィールド）。
Fields that have no uncompressed value do not appear in an "UNCOMPRESSED" field list and do not have to appear in the "CONTROL" field list either. Instead, they are only declared in the compressed field lists where they are used.
何も圧縮されていない値を持っていないフィールドは、「UNCOMPRESSED」フィールドリストには表示されず、いずれかの「CONTROL」フィールドのリストに表示されている必要はありません。代わりに、彼らは彼らだけが使用されている圧縮されたフィールドリストの中で宣言されています。
In the example above, all the fields that appear in the compressed format are also found in the uncompressed format, or the control field list, except for ctrl_field_3; this is possible because ctrl_field_3 has no "uncompressed" value at all. Fields such as a checksum on the compressed information fall into this category.
上記の例では、圧縮された形式で表示されるすべてのフィールドもctrl_field_3を除いて、非圧縮形式、または制御フィールドリストに見出されます。 ctrl_field_3は全く「非圧縮」値を持っていないので、これは可能です。そのような圧縮された情報のチェックサムなどのフィールドは、このカテゴリに分類されます。
This section gives an overview of how the notation is used by means of an example. The example will develop the formal notation for an encoding method capable of compressing a single, well-known header: the IPv4 header [RFC791].
このセクションでは、表記は実施例により使用される方法の概要を与えます。 IPv4ヘッダ[RFC791]：例では、単一の、よく知られているヘッダを圧縮することが可能な符号化方式のための正式な表記法を開発します。
The first step is to specify the overall structure of the IPv4 header. To do this, we use an encoding method that we will call "ipv4_header". More details on definitions of encoding methods can be found in Section 4.12. This is notated as follows:
最初のステップは、IPv4ヘッダの全体的な構造を指定することです。これを行うために、我々は「ipv4_header」コールする符号化方法を使用します。符号化方式の定義についての詳細は、セクション4.12に記載されています。これは次のように表記されています。
ipv4_header {
ipv4_header {
The fragment of notation above declares the encoding method "ipv4_header", the definition follows the opening brace (see Section 4.12).
表記の断片は、上記の定義は、開口ブレース（セクション4.12を参照）、以下、「ipv4_header」符号化方法を宣言する。
Definitions within the pair of braces are local to "ipv4_header". This scoping mechanism helps to clarify which fields belong to which formats; it is also useful when compressing complex protocol stacks with several headers, often with the same field names occurring in multiple headers (see Section 4.2).
カッコの組内の定義は、「ipv4_header」に対してローカルです。このスコープメカニズムは、フォーマットするためにどの属する分野明確にすることができます。多くの場合、同じフィールド名が複数のヘッダーで発生すると、いくつかのヘッダで複雑なプロトコルスタックを圧縮する際にも有用である（4.2節を参照してください）。
The next step is to specify the fields contained in the uncompressed IPv4 header to represent the uncompressed format for which the encoding method will define one or more compressed formats. This is accomplished using ROHC-FN as follows:
次のステップでは、符号化方法は、1つのまたは複数の圧縮フォーマットを定義する対象の非圧縮形式を表現するために圧縮されていないIPv4ヘッダに含まれるフィールドを指定することです。これは次のようにROHC-FNを使用して達成されます。
UNCOMPRESSED {
version [ 4 ];
header_length [ 4 ];
dscp [ 6 ];
ecn [ 2 ];
length [ 16 ];
id [ 16 ];
reserved [ 1 ];
dont_frag [ 1 ];
more_fragments [ 1 ];
offset [ 13 ];
ttl [ 8 ];
protocol [ 8 ];
checksum [ 16 ];
src_addr [ 32 ];
dest_addr [ 32 ];
}
The width of each field is indicated in square brackets. This part of the notation is used in the example for illustration to help the reader's understanding. However, indicating the field lengths in this way is optional since the width of each field can also normally be derived from the encoding that is used to compress/decompress it for a specific format. This part of the notation is formally defined in Section 4.10.
各フィールドの幅は、角括弧内に示されています。記法のこの部分は、読者の理解を助けるために例示のための例で使用されています。各フィールドの幅はまた、通常、特定の形式のためにそれを解凍/圧縮するために使用される符号化から誘導することができるので、このようにフィールドの長さを示すことは任意です。表記のこの部分は、正式に4.10で定義されています。
The next step is to specify the compressed format. This includes the encodings for each field that map between the compressed and uncompressed forms of the field. In the example, these encoding methods are mainly taken from the ROHC-FN library (see Section 4.11). Since the intention here is to illustrate the use of the notation, rather than to describe the optimum method of compressing IPv4 headers, this example uses only three encoding methods.
次のステップは、圧縮されたフォーマットを指定することです。これは、フィールドの圧縮と非圧縮形式との間でマッピングフィールドごとに符号化を含みます。一例では、これらの符号化方式は、主にROHC-FNライブラリから取得され（セクション4.11を参照）。ここでの意図は、IPv4ヘッダを圧縮する最適な方法を記述するのではなく、表記の使用を説明することであるので、この例では、3つだけの符号化方法を使用します。
The "uncompressed_value" encoding method (defined in Section 4.11.1) can compress any field whose uncompressed length and value are fixed, or can be calculated using an expression. No compressed bits need to be sent because the uncompressed field can be reconstructed using its known size and value. The "uncompressed_value" encoding method is used to compress five fields in the IPv4 header, as described below:
（セクション4.11.1に定義された）「uncompressed_value」符号化方式は、その圧縮されていない長さと値の固定された任意のフィールドを圧縮することができ、または式を用いて算出することができます。いいえ圧縮ビットが圧縮されていないフィールドは、その既知の大きさと値を使用して再構築することができるので、送信する必要がありません。以下に説明するように「uncompressed_value」符号化方法は、IPv4ヘッダ内の5つのフィールドを圧縮するために使用されます。
COMPRESSED {
header_length =:= uncompressed_value(4, 5);
version =:= uncompressed_value(4, 4);
reserved =:= uncompressed_value(1, 0);
offset =:= uncompressed_value(13, 0);
more_fragments =:= uncompressed_value(1, 0);
The first parameter indicates the length of the uncompressed field in bits, and the second parameter gives its integer value.
最初のパラメータは、ビット単位で圧縮されていないフィールドの長さを示し、第2のパラメータは、その整数値を与えます。
Note that the order of the fields in the compressed format is independent of the order of the fields in the uncompressed format.
圧縮形式のフィールドの順序は、非圧縮形式のフィールドの順序とは無関係であることに留意されたいです。
The "irregular" encoding method (defined in Section 4.11.3) can be used to encode any field for which both uncompressed attributes (ULENGTH and UVALUE) are defined, and whose ULENGTH attribute is either fixed or can be calculated using an expression. It is a fail-safe encoding method that can be used for such fields in the case where no other encoding method applies. All of the bits in the uncompressed form of the field are present in the compressed form as well; hence this encoding does not achieve any compression.
（セクション4.11.3に定義された）「不規則な」符号化方法は、圧縮されていない属性（ULENGTHとUVALUE）の両方が定義されている任意のフィールドを符号化するために使用され、そのULENGTH属性固定されるか、または式を用いて算出することができることができます。それは、他の符号化方式が適用されない場合にはこのようなフィールドのために使用することができるフェイルセーフ符号化方法です。フィールドの非圧縮形式のビットのすべてが同様に圧縮された形で存在します。したがって、このエンコーディングは任意の圧縮を実現しません。
src_addr =:= irregular(32);
dest_addr =:= irregular(32);
length =:= irregular(16);
id =:= irregular(16);
ttl =:= irregular(8);
protocol =:= irregular(8);
dscp =:= irregular(6);
ecn =:= irregular(2);
dont_frag =:= irregular(1);
Finally, the third encoding method is specific only to the uncompressed format defined above for the IPv4 header, "inferred_ip_v4_header_checksum":
最後に、第三の符号化方法は、IPv4ヘッダ、「inferred_ip_v4_header_checksum」について上で定義した非圧縮形式に特異的です。
checksum =:= inferred_ip_v4_header_checksum [ 0 ]; } }
チェックサム=：= inferred_ip_v4_header_checksum [0]。 }}
The "inferred_ip_v4_header_checksum" encoding method is different from the other two encoding methods in that it is not defined in the ROHC-FN library of encoding methods. Its definition could be given either by using the formal notation as part of the profile definition itself (see Section 4.12) or by using plain English text (see Section 4.13).
それは符号化方式のROHC-FNライブラリで定義されていないという点で「inferred_ip_v4_header_checksum」符号化方法は、他の2つの符号化方式とは異なります。その定義は、プロファイルの定義自体の一部として正式な表記法を使用して（セクション4.12参照）のいずれか与えられたか、平易な英語のテキストを使用して（項4.13を参照）することができます。
In our example, the "inferred_ip_v4_header_checksum" is a specific encoding method that calculates the IP checksum from the rest of the header values. Like the "uncompressed_value" encoding method, no compressed bits need to be sent, since the field value can be reconstructed at the decompressor. This is notated explicitly by specifying, in square brackets, a length of 0 for the checksum field in the compressed format. Again, this notation is optional since the encoding method itself would be defined as sending zero compressed bits, however it is useful to the reader to include such notation (see Section 4.10 for details on this part of the notation).
この例では、「inferred_ip_v4_header_checksumは」ヘッダ値の残りの部分からIPチェックサムを計算し、特定の符号化方式です。フィールドの値が伸張器に再構成することができるので、「uncompressed_value」符号化方式と同様、全く圧縮ビットは、送信する必要がありません。これは圧縮形式で、角括弧で、チェックサムフィールドに0の長さを指定することによって明示的に表記されています。符号化方法自体はゼロ圧縮ビットを送信するように定義されるので、再び、この表記は（表記のこの部分の詳細については、セクション4.10を参照）しかしながら、このような表記を含むことを読者に有用である、任意です。
Finally the definition of the format is terminated with a closing brace. At this point, the above example has defined a compressed format that can be used to represent the entire compressed IPv4 header, and provides enough information to allow an implementation to construct the compressed format from an uncompressed format (compression) and vice versa (decompression).
最後に、フォーマットの定義が閉じ括弧で終了します。この時点で、上記の例では、全体圧縮IPv4ヘッダを表すために使用することができる圧縮フォーマットを定義し、実装は、非圧縮形式（圧縮）およびその逆（伸長）から圧縮フォーマットを構築することを可能にする十分な情報を提供しています。
This section gives the normative definition of ROHC-FN. ROHC-FN is a declarative language that is referentially transparent, with no side effects. This means that whenever an expression is evaluated, there are no other effects from obtaining the value of the expression; the same expression is thus guaranteed to have the same value wherever it appears in the notation, and it can always be interchanged with its value in any of the formats it appears in (subject to the scope rules of identifiers of Section 4.2).
このセクションでは、ROHC-FNの規範的な定義を与えます。 ROHC-FNは、副作用のない、参照透明で宣言型言語です。これは、式が評価されるたびに、式の値を得ることからの他の影響がないことを意味します。同じ表現は、それが表記で表示され、それは常に、それは（セクション4.2の識別子のスコープ規則に従う）に表示される形式のいずれかでその値と交換することができるところはどこでも同じ値を有することが保証されます。
The formal notation describes the structure of the formats and the relationships between their uncompressed and compressed forms, rather than describing how compression and decompression is performed.
正式な表記は、フォーマットの構造むしろ圧縮および解凍が実行される様子を説明するよりも、それらの非圧縮および圧縮形式の間の関係を記述する。
In various places within this section, text inside angle brackets has been used as a descriptive placeholder. The use of angle brackets in this way is solely for the benefit of the reader of this document. Neither the angle brackets, nor their contents form a part of the notation.
このセクション内の様々な場所で、角括弧内のテキストは、説明のプレースホルダとして使用されてきました。このように角括弧の使用は、この文書の読者の利益のためだけです。アングルブラケット、またその内容も表記の一部を形成します。
The specification of the compressed formats of a ROHC profile using ROHC-FN is called a ROHC-FN specification. ROHC-FN specifications are case sensitive and are written in the 7-bit ASCII character set (as defined in [RFC2822]) and consist of a sequence of zero or more constant definitions (Section 4.3), an optional global control field list (Section 4.12.1.3) and one or more encoding method definitions (Section 4.12).
ROHC-FNを用いROHCプロファイルの圧縮フォーマットの仕様は、ROHC-FN仕様と呼ばれています。 ROHC-FN仕様は、大文字と小文字が区別され、7ビットのASCII文字セット（[RFC2822]で定義されるように）、ゼロ以上の定数の定義（セクション4.3）の配列からなる、オプションのグローバル制御フィールドリスト（セクションで記述されています4.12.1.3）と1つ以上の符号化方式の定義（セクション4.12）。
Encoding methods can be defined using the formal notation or can be predefined encoding methods.
符号化方法は、正式な表記法を使用して定義することができるか、または事前に定義された符号化方法であってもよいです。
Encoding methods are defined using the formal notation by giving one or more uncompressed formats to represent the uncompressed header and one or more compressed formats. These formats are related to each other by "fields", each of which describes a certain part of an uncompressed and/or a compressed header. In addition to the formats, each encoding method may contain control fields, initial values, and default field encodings sections. The attributes of a field are bound by using an encoding method for it and/or by using "ENFORCE" statements (Section 4.9) within the formats. Each of these are terminated by a semi-colon.
符号化方法は、非圧縮ヘッダおよび1つのまたは複数の圧縮形式を表現するために1つの以上の非圧縮フォーマットを与えることによって正式な表記法を使用して定義されます。これらのフォーマットは、非圧縮および/または圧縮されたヘッダの特定の部分を記述するそれぞれが「フィールド」によって互いに関連しています。フォーマットに加えて、各符号化方式は、制御フィールド、初期値、およびデフォルトのフィールドのエンコーディングのセクションを含んでいてもよいです。フィールドの属性は、および/またはフォーマット内の「ENFORCE」文（セクション4.9）を使用して、それのための符号化方法を用いて結合されています。これらのそれぞれは、セミコロンで終了します。
Predefined encoding methods are not defined in the formal notation. Instead they are defined by giving a short textual reference explaining where the encoding method is defined. It is not necessary to define the library of encoding methods contained in this document in this way, their definition is implicit to the usage of the formal notation.
事前定義された符号化方法は、正式な表記法で定義されていません。代わりに、彼らは、符号化方式が定義されている場合を説明する短いテキスト参照を与えることによって定義されます。彼らの定義は、正式な表記の使用に暗黙的である、このように、この文書に含まれている符号化方式のライブラリーを定義する必要はありません。
In ROHC-FN, identifiers are used for any of the following:
ROHC - FNでは、識別子は、次のいずれかのために使用されます。
o encoding methods
O符号化方式
o formats
Oフォーマット
o fields
Oフィールド
o parameters
Oパラメータ
o constants
O定数
All identifiers may be of any length and may contain any combination of alphanumeric characters and underscores, within the restrictions defined in this section.
すべての識別子は、任意の長さであり、このセクションで定義された制限の範囲内で、英数字とアンダースコアの任意の組み合わせが含まれていてもよいです。
All identifiers must start with an alphabetic character.
すべての識別子は、英字で始まる必要があります。
It is illegal to have two or more identifiers that differ from each other only in capitalisation, in the same scope.
同じスコープ内で、大文字のみが互いに異なる2つの以上の識別子を持つことは違法です。
All letters in identifiers for constants must be upper case.
定数の識別子のすべての文字は大文字でなければなりません。
It is illegal to use any of the following as identifiers (including alternative capitalisations):
（代替capitalisations含む）識別子として次のいずれかを使用することは違法です。
o "false", "true"
「偽」、「真」
o "ENFORCE", "THIS", "VARIABLE"
O、 "THIS"、 "VARIABLE" を "ENFORCE"
o "ULENGTH", "UVALUE" o "CLENGTH", "CVALUE"
ノー "LENGTH"、 "VALUEは、" 長さ "" VALUE」です
o "UNCOMPRESSED", "COMPRESSED", "CONTROL", "INITIAL", or "DEFAULT"
O "UNCOMPRESSED"、 "圧縮"、 "CONTROL"、 "INITIAL"、または "DEFAULT"
Format names cannot be referred to in the notation, although they are considered to be identifiers. (See Section 4.12.3.1 for more details on format names.)
彼らは識別子であると考えられているが、形式名は、表記で参照することはできません。 （形式名の詳細については、セクション4.12.3.1を参照してください。）
All identifiers used in ROHC-FN have a "scope". The scope of an identifier defines the parts of the specification where that identifier applies and from which it can be referred to. If an identifier has a "global" scope, then it applies throughout the specification that contains it and can be referred to from anywhere within it. If an identifier has a "local" scope, then it only applies to the encoding method in which it is defined, it cannot be referenced from outside the local scope of that encoding method. If an identifier has a local scope, that identifier can therefore be used in multiple different local scopes to refer to different items.
ROHC - FNで使用されるすべての識別子は、「スコープ」を持っています。識別子の範囲は、その識別子が適用される仕様の部分を定義し、そこからそれを参照することができます。識別子は、「グローバル」スコープを持っている場合、それは、それが含まれており、どこでもその中から参照することができ明細書を通じて適用されます。識別子は「ローカル」範囲を有する場合、それは唯一、それが定義されている符号化方式に適用され、その符号化方式のローカルスコープ外部から参照することができません。識別子はローカルスコープを持っている場合、その識別子は、したがって、異なるアイテムを参照するために複数の異なるローカルスコープで使用することができます。
All instances of an identifier within its scope refer to the same item. It is not possible to have different items referred to by a single identifier within any given scope. For this reason, if there is an identifier that has global scope it cannot be used separately in a local scope, since a globally-scoped identifier is already applicable in all local scopes.
その範囲内の識別子のすべてのインスタンスは、同一の項目を参照します。任意の所与の範囲内の単一の識別子によって参照される異なるアイテムを持つことは不可能です。このため、グローバルスコープの識別子は、すでにすべてのローカルスコープに適用可能であることから、それはローカルスコープで別々に使用することはできませんグローバルスコープを持つ識別子がある場合。
The identifiers for each encoding method and each constant all have a global scope. Each format and field also has an identifier. The scope of format and field identifiers is local, with the exception of global control fields, which have a global scope. Therefore it is illegal for a format or field to have the same identifier as another format or field within the same scope, or as an encoding method or a constant (since they have global scope).
各符号化方式と、すべての各定数の識別子は、グローバルスコープを有します。各フォーマットとフィールドにも識別子を持っています。フォーマットおよびフィールド識別子の範囲は、グローバルスコープを有するグローバル制御フィールドを除いて、ローカルです。したがって、同じスコープ内の別の形式やフィールドと同じ識別子を持つフォーマットまたはフィールドの不正、または符号化方式または定数（これらはグローバルスコープを持っているので）の通りです。
Note that although format names (see Section 4.12.3.1) are considered to be identifiers, they are not referred to in the notation, but are primarily for the benefit of the reader.
フォーマット名は（セクション4.12.3.1参照）の識別子であると考えられているが、それらは表記で言及するが、読者の利益のために主にされていないことに注意してください。
Constant values can be defined using the "=" operator. Identifiers for constants must be all upper case. For example:
定数値は、「=」演算子を使用して定義することができます。定数の識別子はすべて大文字でなければなりません。例えば：
SOME_CONSTANT = 3;
SOME_CONSTANT = 3。
Constants are defined by an expression (see Section 4.7) on the right-hand side of the "=" operator. The expression must yield a constant value. That is, the expression must be one whose terms are all either constants or literals and must not vary depending on the header being compressed.
定数は、「=」演算子の右側に（セクション4.7を参照）式で定義されます。式は定数値を得なければなりません。すなわち、発現は、その用語のすべてのいずれかの定数またはリテラルであり、圧縮されたヘッダに依存して変化してはならないものでなければならない、です。
Constants have a global scope. Constants must be defined at the top level, outside any encoding method definition. Constants are entirely equivalent to the value they refer to, and are completely interchangeable with that value. Unlike field attributes, which may change from packet to packet, constants have the same value for all packets.
定数は、グローバルスコープを持っています。定数は、任意の符号化方式の定義の外側に、最上位レベルで定義されなければなりません。定数は、彼らが参照値に完全に相当し、その値と完全に交換可能です。パケットごとに変更されることがありフィールド属性とは異なり、定数はすべてのパケットに対して同じ値を持っています。
Fields are the basic building blocks of a ROHC-FN specification. Fields are the units into which headers are divided. Each field may have two forms: a compressed form and an uncompressed form. Both forms are represented as bits exchanged between the compressor and the decompressor in the same way, as an unsigned string of bits; the most significant bit first.
フィールドはROHC - FN仕様の基本的なビルディングブロックです。フィールドは、ヘッダが分割されているに単位です。圧縮形式と非圧縮形式：各フィールドには、二つの形式を有することができます。ビットは、ビットの符号なしの文字列として、同じようにコンプレッサとデコンプレッサとの間の交換の両方の形態が示されています。最初の最上位ビット。
The properties of the compressed form of a field are defined by an encoding method and/or "ENFORCE" statements. This entirely characterises the relationship between the uncompressed and compressed forms of that field. This is achieved by specifying the relationships between the field's attributes.
フィールドの圧縮形式の特性は、符号化方式及び/又は「ENFORCE」ステートメントによって定義されます。これは完全にそのフィールドの非圧縮と圧縮形式との間の関係を特徴づけます。これは、フィールドの属性間の関係を指定することによって達成されます。
The notation defines four field attributes, two for the uncompressed form and a corresponding two for the compressed form. The attributes available for each field are:
表記は、4つのフィールド属性、非圧縮形式及び圧縮形式のために対応する二つのための2つを定義します。各フィールドに利用可能な属性は次のとおりです。
uncompressed attributes of a field:
フィールドの非圧縮属性：
o "UVALUE" and "ULENGTH",
O "UVALUE" と "ULENGTH"、
compressed attributes of a field:
フィールドの圧縮属性：
o "CVALUE" and "CLENGTH".
O "CVALUE" と "CLENGTH"。
The two value attributes contain the respective numerical values of the field, i.e., "UVALUE" gives the numerical value of the uncompressed form of the field, and the attribute "CVALUE" gives the numerical value of the compressed form of the field. The numerical values are derived by interpreting the bit-string representations of the field as bit strings; the most significant bit first.
2つの値の属性、すなわち、「UVALUE」はフィールドの非圧縮形式の数値を与え、属性「CVALUE」はフィールドの圧縮形式の数値を与え、フィールドの各数値を含みます。数値はビット列としてフィールドのビット列表現を解釈することによって導出されます。最初の最上位ビット。
The two length attributes indicate the length in bits of the associated bit string; "ULENGTH" for the uncompressed form, and "CLENGTH" for the compressed form.
2つの長さ属性は、関連付けられたビット列のビット長を示します。非圧縮形式、圧縮形式のための「CLENGTH」の「ULENGTH」。
Attributes are undefined unless they are bound to a value, in which case they become defined. If two conflicting bindings are given for a field attribute then the bindings fail along with the (combination of) formats in which those bindings were defined.
彼らは彼らが定義になっている場合には値にバインドされていない限り、属性が定義されていません。 2つの競合バインディングがフィールド属性のために与えられている場合、バインディングは、それらのバインディングが定義されたフォーマット（の組み合わせ）と一緒に失敗します。
Uncompressed attributes do not always reflect an aspect of the uncompressed header. Some fields do not originate from the uncompressed header, but are control fields.
非圧縮属性は、常に圧縮されていないヘッダの側面を反映していません。一部のフィールドは、非圧縮ヘッダから始まるが、制御フィールドではありません。
Attributes of a particular field are formally referred to by using the field's name followed by a "." and the attribute's identifier.
特定のフィールドの属性は、正式に続いて、フィールドの名前を使用して呼ばれています「」そして、属性の識別子。
For example:
例えば：
rtp_seq_number.UVALUE
rtp_seq_number.U VALUE
The above gives the uncompressed value of the rtp_seq_number field. The primary reason for referencing attributes is for use in expressions, which are explained in Section 4.7.
上記はrtp_seq_numberフィールドの非圧縮の値を与えます。属性を参照するための主な理由は、4.7節で説明されている表現、で使用するためのものです。
Fields are represented as bit strings. The bit string is calculated using the value attribute ("val") and the length attribute ("len"). The bit string is the binary representation of "val % (2 ^ len)".
フィールドは、ビット列として表現されています。ビット列は、値属性（「ヴァル」）と長さ属性（「LEN」）を用いて計算されます。ビット列は「ヴァル％（2 ^ LEN）」のバイナリ表現です。
For example, if a field's "CLENGTH" attribute was 8, and its "CVALUE" attribute was -1, the compressed representation of the field would be "-1 % (2 ^ 8)", which equals "-1 % 256", which equals 255, 11111111 in binary.
フィールドの「CLENGTH」属性は8、その「CVALUE」であった場合、例えば、属性は-1で、フィールドの圧縮表現は次のようになり、「-1％（2 ^ 8）」、「-1％256」等しいです、バイナリで255、11111111に等しいです。
ROHC-FN supports the full range of integers for use in expressions (see Section 4.7), but the representation of the formats (i.e., the bits exchanged between the compressor and the decompressor) is in the above form.
上記形態であるROHC-FNは、式（4.7節を参照）に使用するための整数の完全な範囲をサポートしていますが、形式の表現（すなわち、ビットは、コンプレッサとデコンプレッサとの間で交換しました）。
Since the order of fields in a "COMPRESSED" field list (Section 4.12.1.2) do not have to be the same as the order of fields in an "UNCOMPRESSED" field list (Section 4.12.1.1), it is possible to group together any number of fields that are contiguous in a "COMPRESSED" format, to allow them all to be encoded using a single encoding method. The group of fields is specified immediately to the left of "=:=" in place of a single field name.
「圧縮」フィールドリスト内のフィールドの順序（セクション4.12.1.2）は「UNCOMPRESSED」フィールドリスト（セクション4.12.1.1）のフィールドの順序と同じである必要はありませんので、それは一緒にグループすることが可能です「圧縮」形式で連続しているフィールド、任意の数のそれらすべてが単一の符号化方式を用いて符号化されることを可能にします。単一のフィールド名の代わりに：フィールドのグループは、「= =」のすぐ左に指定されています。
The group is notated by giving a colon-separated list of the fields to be grouped together. For example there may be two non-contiguous fields in an uncompressed header that are two halves of what is effectively a single sequence number:
基が一緒にグループ化するフィールドのコロンで区切られたリストを与えることによって表記されます。例えば、効果的単一のシーケンス番号が何であるかの二つの部分である非圧縮ヘッダ内の2つの非隣接のフィールドがあってもよいです。
grouping_example { UNCOMPRESSED { minor_seq_num; // 12 bits other_field; // 8 bits major_seq_num; // 4 bits }
grouping_example {UNCOMPRESSED {minor_seq_num。 // 12ビットother_field。 major_seq_num // 8ビット。 // 4ビット}
COMPRESSED {
other_field =:= irregular(8);
major_seq_num
: minor_seq_num =:= lsb(3, 0);
}
}
The group of fields is presented to the encoding method as a contiguous group of bits, assembled by the concatenation of the fields in the order they are given in the group. The most significant bit of the combined field is the most significant bit of the first field in the list, and the least significant bit of the combined field is the least significant bit of the last field in the list.
フィールドのグループは、彼らがグループに与えられているために、フィールドを連結することによって組み立てられたビットの連続したグループとして符号化方式に提示されます。組み合わせフィールドの最上位ビットは、リストの最初のフィールドの最上位ビットで、合わせフィールドの最下位ビットは、リスト内の最後のフィールドの最下位ビットです。
Finally, the length attributes of the combined field are equal to the sum of the corresponding length attributes for all the fields in the group.
最後に、合成フィールドの長さ属性は、グループ内のすべてのフィールドのための対応する長さ属性の和に等しいです。
Within the definition of an encoding method, it is possible to refer to the field (i.e., the group of contiguous bits) the method is encoding, using the keyword "THIS".
符号化方式の定義に、それはフィールドを参照することが可能である（すなわち、連続したビットのグループ）の方法は、キーワード「これ」を用いて、符号化です。
This is useful for gaining access to the attributes of the field being encoded. For example it is often useful to know the total uncompressed length of the uncompressed format that is being encoded:
これは、符号化されているフィールドの属性にアクセスするために有用です。例えば、符号化されている非圧縮形式の総非圧縮長さを知ることは、しばしば有用です。
THIS.ULENGTH
THIS.ULENGTH
ROHC-FN includes the usual infix style of expressions, with parentheses "(" and ")" used for grouping. Expressions can be made up of any of the components described in the following subsections.
ROHC-FNは、グループ化のために使用される「（」と「）」括弧で、式の通常の中置スタイルが含まれています。式は以下のサブセクションで説明した構成要素のいずれかで構成することができます。
The semantics of expressions are generally similar to the expressions in the ANSI-C programming language [C90]. The definitive list of expressions in ROHC-FN follows in the next subsections; the list below provides some examples of the difference between expressions in ANSI-C and expressions in ROHC-FN:
式の意味は、一般的にANSI-Cプログラミング言語[C90]の式に類似しています。 ROHC-FNにおける表現の決定的なリストは、次のサブセクションで、以下、以下のリストは、ROHC-FNにおけるANSI-Cの式と表現との間の差のいくつかの例を提供します。
o There is no limit on the range of integers.
O整数の範囲に制限はありません。
o "x ^ y" evaluates to x raised to the power of y. This has a precedence higher than *, / and %, but lower than unary - and is right to left associative.
O「のx ^ yは、」xのy乗に評価されます。これは単項よりも優先*、/および％より高く、より低い持っています - と、左連想する権利です。
o There is no comma operator.
Oなしコンマ演算子はありません。
o There are no "modify" operators (no assignment operators and no increment or decrement).
Oない「修正」演算子（なし代入演算子なし増減）がありません。
o There are no bitwise operators.
O何ビット演算子がありません。
Expressions may refer to any of the attributes of a field (as described in Section 4.4), to any defined constant (see Section 4.3) and also to encoding method parameters, if any are in scope (see Section 4.12).
式は、任意の範囲にある場合（セクション4.12を参照）、符号化方式のパラメータにも任意の定義された定数（セクション4.3を参照）に、（セクション4.4で説明したように）フィールドの属性のいずれかを指すことができます。
If any of the attributes, constants, or parameters used in the expression are undefined, the value of the expression is undefined. Undefined expressions cause the environment (for example, the compressed format) in which they are used to fail if a defined value is required. Defined values are required for all compressed attributes of fields that appear in the compressed format. Defined values are not required for all uncompressed attributes of fields which appear in the uncompressed format. It is up to the profile creator to define what happens to the unbound field attributes in this case. It should be noted that in such a case, transparency of the compression process will be lost; i.e., it will not be possible for the decompressor to reproduce the original header.
式の中で使用される属性、定数、またはパラメータのいずれかが定義されていない場合は、式の値は未定義です。未定義の式は、それらが定義された値が必要な場合に失敗するために使用されている（例えば、圧縮形式）環境を引き起こします。定義された値は、圧縮形式で表示されるフィールドのすべての圧縮属性のために必要とされます。定義された値は、非圧縮形式で表示されるフィールドの全て圧縮されていない属性は必要ありません。これは、この場合、結合していないフィールド属性に何が起こるかを定義するには、プロファイルの作成者に任されています。このような場合には、圧縮プロセスの透明性が失われることに留意すべきです。解凍装置は、元のヘッダを再生するために、すなわち、それは可能ではないであろう。
Expressions cannot be used as encoding methods directly because they do not completely characterise a field. Expressions only specify a single value whereas a field is made up of several values: its attributes. For example, the following is illegal:
彼らは完全にフィールドを特徴づけるものではないので式は直接符号化方式として使用することはできません。その属性：フィールドは複数の値で構成され、一方、式は単一の値のみを指定します。例えば、以下は違法です。
tcp_list_length =:= (data_offset + 20) / 4;
tcp_list_length =：=（data_offset + 20）/ 4。
There is only enough information here to define a single attribute of "tcp_list_length". Although this makes no sense formally, this could intuitively be read as defining the "UVALUE" attribute. However, that would still leave the length of the uncompressed field undefined at the decompressor. Such usage is therefore prohibited.
「tcp_list_length」の単一の属性を定義するには、ここだけの十分な情報があります。これは正式には意味がありませんが、これは直感的に「UVALUE」属性を定義するものとして読み取ることができます。しかし、それはまだデコンプレッサで圧縮されていない未定義のフィールドの長さを残すでしょう。このような使用方法は、したがって、禁止されています。
Integers can be expressed as decimal values, binary values (prefixed by "0b"), or hexadecimal values (prefixed by "0x"). Negative integers are prefixed by a "-" sign. For example "10", "0b1010", and "-0x0a" are all valid integer literals, having the values 10, 10, and -10 respectively.
整数は小数点値、（「0B」で始まる）バイナリ値、または（「0X」で始まる）進数値として表すことができます。 「 - 」記号の負の整数は、接頭辞されています。例えば、「10」、「が0b1010」、および「-0x0a」値10、10を有し、すべての有効な整数リテラルであり、-10夫々。
The following "integer" operators are available, which take integer arguments and return an integer result:
以下の「整数」演算子は、整数の引数を取り、整数の結果を返すれ、用意されています。
o ^, for exponentiation. "x ^ y" returns the value of "x" to the power of "y".
O ^、累乗のため。 「X ^ yは」「Y」のパワーに「X」の値を返します。
o *, / for multiplication and division. "x * y" returns the product of "x" and "y". "x / y" returns the quotient, rounded down to the next integer (the next one towards negative infinity).
O *、/乗算と除算のため。 "のx * yは" "X" と "Y" の積を返します。 「X / Y」は、商を返し、次の整数（負の無限大に向かって、次のいずれか）に切り捨て。
o +, - for addition and subtraction. "x + y" returns the sum of "x" and "y". "x - y" returns the difference.
Oの+、 - 加算および減算のために。 "X + Y"、 "X" と "Y" の和を返します。 "X - Y" は差を返します。
o % for modulo. "x % y" returns "x" modulo "y"; x - y * (x / y).
モジュールまたは％。 「X％及び」戻る「X」モジュール「と」。 X - のy *（X / Y）。
The boolean literals are "false", and "true".
ブールリテラルは「偽」、および「真」です。
The following "boolean" operators are available, which take boolean arguments and return a boolean result:
以下の「ブール」演算子は、ブール引数を取り、ブール値の結果を返した、用意されています。
o &&, for logical "and". Returns true if both arguments are true. Returns false otherwise.
O &&、論理のため "と"。両方の引数が真である場合にtrueを返します。そうでない場合はfalseを返します。
o ||, for logical "or". Returns true if at least one argument is true. Returns false otherwise.
|| O、論理のための "か"。少なくとも一つの引数がtrueの場合にtrueを返します。そうでない場合はfalseを返します。
o !, for logical "not". Returns true if its argument is false. Returns false otherwise.
O！、論理のための "ありません"。その引数がfalseの場合にtrueを返します。そうでない場合はfalseを返します。
The following "comparison" operators are available, which take integer arguments and return a boolean result:
以下の「比較」演算子は、整数の引数を取り、ブール値の結果を返した、用意されています。
o ==, !=, for equality and its negative. "x == y" returns true if x is equal to y. Returns false otherwise. "x != y" returns true if x is not equal to y. Returns false otherwise.
O ==、！=、平等とその負のため。 「X == Y」xがyに等しい場合に真を返します。そうでない場合はfalseを返します。 xがyに等しくない場合、 "X！= yは" trueを返します。そうでない場合はfalseを返します。
o <, >, for less than and greater than. "x < y" returns true if x is less than y. Returns false otherwise. "x > y" returns true if x is greater than y. Returns false otherwise.
O <、>、より小さくよりも大きいため。 xがyよりも小さい場合、 "X <Y" がtrueを返します。そうでない場合はfalseを返します。 xがyよりも大きい場合、 "X> Y" がtrueを返します。そうでない場合はfalseを返します。
o >=, <=, for greater than or equal and less than or equal, the inverse functions of <, >. "x >= y" returns false if x is less than y. Returns true otherwise. "x <= y" returns false if x is greater than y. Returns true otherwise.
O> =、<=、<の逆関数、以上及び以下のために、>。 xがyよりも小さい場合、 "X> = yが" falseを返します。それ以外の場合はtrueを返します。 xがyよりも大きい場合、 "X <= Y" falseを返します。それ以外の場合はtrueを返します。
Free English text can be inserted into a ROHC-FN specification to explain why something has been done a particular way, to clarify the intended meaning of the notation, or to elaborate on some point.
無料の英語テキストは、何かが表記の意図する意味を明確にするために、またはいくつかの点について詳しく説明するために、特定の方法で行われている理由を説明するためにROHC - FN仕様に挿入することができます。
The FN uses an end of line comment style, which makes use of the "//" comment marker. Any text between the "//" marker and the end of the line has no formal meaning. For example:
FNは「//」コメントマーカーを利用した行コメントスタイルの終わりを使用しています。 「//」マーカー行の最後までのすべてのテキストは、正式な意味を持ちません。例えば：
//-----------------------------------------------------------------
// IR-REPLICATE header formats
//-----------------------------------------------------------------
// The following fields are included in all of the IR-REPLICATE // header formats: // UNCOMPRESSED { discriminator; // 8 bits tcp_seq_number; // 32 bits tcp_flags_ecn; // 2 bits
//次のフィールドは、IR-REPLICATE //ヘッダフォーマットの全てに含まれています：// UNCOMPRESSED {判別。 // 8ビットtcp_seq_number。 // 32ビットtcp_flags_ecn。 // 2ビット
Comments do not affect the formal meaning of what is notated, but can be used to improve readability. Their use is optional.
コメントが表記されているものの形式的な意味には影響を与えませんが、読みやすさを改善するために使用することができます。これらの使用はオプションです。
Comments may help to provide clarifications to the reader, and serve different purposes to implementers. Comments should thus not be considered of lesser importance when inserting them into a ROHC-FN specification; they should be consistent with the normative part of the specification.
コメントは、読者への明確化を提供するのに役立ち、および実装に異なる目的を果たすことができます。 ROHC-FN仕様にそれらを挿入する際のコメントは、このようにあまり重要で考えるべきではありません。彼らは、仕様の標準的な部分と一致している必要があります。
The "ENFORCE" statement provides a way to add predicates to a format, all of which must be fulfilled for the format to succeed. An "ENFORCE" statement shares some similarities with an encoding method. Specifically, whereas an encoding method binds several field attributes at once, an "ENFORCE" statement typically binds just one of them. In fact, all the bindings that encoding methods create can be expressed in terms of a collection of "ENFORCE" statements. Here is an example "ENFORCE" statement which binds the "UVALUE" attribute of a field to 5.
「ENFORCE」文は、フォーマットが成功するために満たされなければならないすべては形式に述語を追加する方法を、提供します。符号化方式との声明を共有いくつかの類似点を「ENFORCE」。符号化方式にはいくつかのフィールドをバインドするのに対し、具体的には、「ENFORCE」文は通常、ちょうどそれらの1バインドし、一度に属性。実際には、エンコード方法が作成したすべてのバインディングは「ENFORCE」文の集合で表現することができます。ここでは5に、フィールドの「UVALUE」属性をバインドする声明を「ENFORCE」の例です。
ENFORCE(field.UVALUE == 5);
（field.UVALUEの== 5）ENFORCE。
An "ENFORCE" statement must only be used inside a field list (see Section 4.12). It attempts to force the expression given to be true for the format that it belongs to.
「ENFORCE」文が唯一のフィールドリスト内で使用しなければなりません（項4.12を参照してください）。それが属するフォーマットに対して真であることが与えられた式を強制しようとします。
An abbreviated form of an "ENFORCE" statement is available for binding length attributes using "[" and "]", see Section 4.10.
「ENFORCE」文の省略形は、「[」と「]」、4.10参照使用して属性の長さを結合するために利用可能です。
Like an encoding method, an "ENFORCE" statement can only be successfully used in a format if the binding it describes is achievable. A format containing the example "ENFORCE" statement above would not be usable if the field had also been bound within that same format with "uncompressed_value" encoding, which gave it a "UVALUE" other than 5.
符号化方式と同様に、「ENFORCE」文が唯一成功し、それが説明結合は達成可能である場合のフォーマットで使用することができます。例を含むフォーマットフィールドはまた、5以外の「UVALUE」を与えた「uncompressed_value」符号化と同じフォーマット内に結合されていた場合、上記のステートメントは使用できません「ENFORCE」。
An "ENFORCE" statement takes a boolean expression as a parameter. It can be used to assert that the expression is true, in order to choose a particular format from a list of possible formats specified in an encoding method (see Section 4.12), or just to bind an expression as in the example above. The general form of an "ENFORCE" statement is therefore:
「ENFORCE」文は、パラメータとしてブール式を取ります。符号化方法で指定可能なフォーマットのリストから特定のフォーマットを選択するために、式が真であることを主張するために使用することができる（セクション4.12を参照）、または単に上記の例のように式をバインドします。文を「ENFORCE」の一般的な形式は、したがって、次のとおりです。
ENFORCE(<boolean expression>);
ENFORCE（<ブール式>）。
There are three possible conditions that the expression may be in:
式はであってもよく、三つの可能な条件があります。
1. The boolean expression evaluates to false, in which case the local scope of the format that contains the "ENFORCE" statement cannot be used.
1.ブール式は、ステートメントを使用することはできません「ENFORCE」が含まれている形式のローカルスコープ、その場合には、falseに評価されます。
2. The boolean expression evaluates to true, in which case the binding is created and successful.
2.ブール式は、バインディングが作成され、成功している場合には、trueに評価されます。
3. The value of the boolean expression is undefined. In this case, the binding is also created and successful.
3.ブール式の値は不定です。この場合、結合も作成し、成功しています。
In all three cases, any undefined term becomes bound by the expression. Generally speaking, an "ENFORCE" statement is either being used as an assignment (condition 3 above) or being used to test if a particular format is usable, as is the case with conditions 1 and 2.
すべての3つのケースでは、未定義の用語は、式で結合するようになります。一般ステートメントが割当て（上記条件3）として使用されるか、又は条件1及び2と同様に特定のフォーマットが、使用可能であるかどうかをテストするために使用される、「ENFORCE」話します。
In many of the examples each field has been followed by a comment indicating the length of the field. Indicating the length of a field like this is optional, but can be very helpful for the reader. However, whilst useful to the reader, comments have no formal meaning.
多くの例では、各フィールドは、フィールドの長さを示すコメントが続いてきました。このようなフィールドの長さを示すことはオプションですが、読者のために非常に役立ちます。しかし、読者に有益な一方で、コメントは正式な意味を持ちません。
One of the most common uses for "ENFORCE" statements (see Section 4.9) is to explicitly define the length of a field within a header. Using "ENFORCE" statements for this purpose has formal meaning but is not so easy to read. Therefore, an abbreviated form is provided for this use of "ENFORCE", which is both easy to read and has formal meaning.
「ENFORCE」文（4.9節を参照）のための最も一般的な用途の1つは、明示的にヘッダ内のフィールドの長さを定義することです。この目的のために「ENFORCE」ステートメントを使用すると、形式的な意味を持っているではなく、読みやすいようです。そのため、短縮形は読みやすいと正式な意味を持つの両方である、「ENFORCE」のこの使用のために提供されます。
An expression defining the length of a field can be specified in square brackets after the appearance of that field in a format. If the field can take several alternative lengths, then the expressions defining those lengths can be enumerated as a comma separated list within the square brackets. For example:
フィールドの長さを規定する式の形式でそのフィールドの出現後に角括弧で指定することができます。フィールドはいくつかの代替の長さを取ることができた場合は、それらの長さを定義する式は、角カッコ内のカンマ区切りリストとして列挙することができます。例えば：
field_1 [ 4 ];
field_2 [ a+b, 2 ];
field_3 =:= lsb(16, 16) [ 26 ];
The actual length attribute, which is bound by this notation, depends on whether it appears in a "COMPRESSED", "UNCOMPRESSED", or "CONTROL" field list (see Section 4.12.1 and its subsections). In a "COMPRESSED" field list, the field's "CLENGTH" attribute is bound. In "UNCOMPRESSED" and "CONTROL" field lists, the field's "ULENGTH" attribute is bound. Abbreviated "ENFORCE" statements are not allowed in "DEFAULT" sections (see Section 4.12.1.5). Therefore, the above notation would not be allowed to appear in a "DEFAULT" section. However, if the above appeared in an "UNCOMPRESSED" or "CONTROL" section, it would be equivalent to:
この表記法に拘束され、実際の長さ属性は、それが「圧縮」、「UNCOMPRESSED」、または「CONTROL」フィールドリストに表示されるかどうかに依存します（セクション4.12.1およびそのサブセクションを参照してください）。 「圧縮」フィールドリストでは、フィールドの「CLENGTH」属性がバインドされています。 「UNCOMPRESSED」と「CONTROL」フィールドリストでは、フィールドの「ULENGTH」属性がバインドされています。略称「ENFORCE」文は「DEFAULT」のセクション（セクション4.12.1.5を参照）で許可されていません。したがって、上記の表記は、「DEFAULT」セクションに表示されることは許されないであろう。上記「UNCOMPRESSED」または「CONTROL」セクションに登場した場合は、それはと同等のようになります。
field_1; ENFORCE(field_1.ULENGTH == 4);
field_2; ENFORCE((field_2.ULENGTH == 2)
|| (field_2.ULENGTH == a+b));
field_3 =:= lsb(16, 16); ENFORCE(field_3.ULENGTH == 26);
A special case exists for fields that have a variable length that the notator does not wish, or is not able to, define using an expression. The keyword "VARIABLE" can be used in the following case:
特殊なケースはnotatorが希望しないことを可変長を有するフィールドに存在する、または、式を使用して定義することができません。キーワード「VARIABLE」は、以下の場合に使用することができます。
variable_length_field [ VARIABLE ];
variable_length_field [VARIABLE]。
Formally, this provides no restrictions on the field length, but maps onto any positive integer or to a value of zero. It will therefore be necessary to define the length of the field elsewhere (see the final paragraphs of Section 4.12.1.1 and Section 4.12.1.2). This may either be in the notation or in the English text of the profile within which the FN is contained. Within the square brackets, the keyword "VARIABLE" may be used as a term in an expression, just like any other term that normally appears in an expression. For example:
正式には、このフィールドの長さに制限を提供しないが、任意の正の整数にまたはゼロの値にマッピングします。したがって、他の場所フィールドの長さを定義する（第4.12.1.1節及び4.12.1.2の最終段落を参照）することが必要であろう。これは、いずれかの表記法またはFNが含まれる内プロファイルの英語テキストであってもよいです。角括弧内では、キーワード「VARIABLEは、」ただ、通常の式に表示されます任意の他の用語と同様に、式の用語として使用されてもよいです。例えば：
field [ 8 * (5 + VARIABLE) ];
フィールド[8×（5 + VARIABLE）]。
This defines a field whose length is a whole number of octets and at least 40 bits (5 octets).
これは、その長さ全体オクテットの数と少なくとも40ビット（5つのオクテット）であるフィールドを定義します。
A number of common techniques for compressing header fields are defined as part of the ROHC-FN library so that they can be reused when creating new ROHC-FN specifications. Their notation is described below.
新しいROHC-FN仕様を作成するときに再利用できるようにヘッダフィールドを圧縮するための一般的な技術の数は、ROHC-FNライブラリーの一部として定義されます。彼らの表記は以下の通りです。
As an alternative, or a complement, to this library of encoding methods, a ROHC-FN specification can define its own set of encoding methods, using the formal notation (see Section 4.12) or using a textual definition (see Section 4.13).
代替的、又は補完するものとして、符号化方法のこのライブラリに、ROHC-FN仕様は、正式な表記法を使用して、符号化方式の独自のセットを定義する（セクション4.12を参照）または（セクション4.13を参照）テキストの定義を使用することができます。
The "uncompressed_value" encoding method is used to encode header fields for which the uncompressed value can be defined using a mathematical expression (including constant values). This encoding method is defined as follows:
「uncompressed_value」符号化方法は、圧縮されていない値（一定値を含む）数式を使用して定義することができるため、ヘッダ・フィールドを符号化するために使用されます。これは次のように符号化方式が定義されています。
uncompressed_value(len, val) {
UNCOMPRESSED {
field;
ENFORCE(field.ULENGTH == len);
ENFORCE(field.UVALUE == val);
}
COMPRESSED {
field;
ENFORCE(field.CLENGTH == 0);
}
}
To exemplify the usage of "uncompressed_value" encoding, the IPv6 header version number is a 4-bit field that always has the value 6:
「uncompressed_value」コードの使用を例示するために、IPv6ヘッダのバージョン番号は常に値6を有する4ビットのフィールドです。
version =:= uncompressed_value(4, 6);
バージョン=：=（4,6）uncompressed_value。
Here is another example of value encoding, using an expression to calculate the length:
ここで長さを計算する式を使用して、値符号化の別の例です。
padding =:= uncompressed_value(nbits - 8, 0);
パディング=：= uncompressed_value（NBITS - 8、0）;
The expression above uses an encoding method parameter, "nbits", that in this example specifies how many significant bits there are in the data to calculate how many pad bits to use. See Section 4.12.2 for more information on encoding method parameters.
この例で使用するためにどのように多くのパッド・ビットを計算するためのデータであるどのように多くの重要なビットを指定することは、上記の式の符号化方式パラメータを使用し、「NBITS」。メソッドのパラメータをコードの詳細については、セクション4.12.2を参照してください。
The "compressed_value" encoding method is used to define fields in compressed formats for which there is no counterpart in the uncompressed format (i.e., control fields). It can be used to specify compressed fields whose value can be defined using a mathematical expression (including constant values). This encoding method is defined as follows:
「compressed_value」符号化方法は、非圧縮形式（すなわち、制御フィールド）には対応がないいる圧縮形式でフィールドを定義するために使用されます。その値（一定値を含む）の数学式を用いて定義することができる圧縮されたフィールドを指定するために使用することができます。これは次のように符号化方式が定義されています。
compressed_value(len, val) {
UNCOMPRESSED {
field;
ENFORCE(field.ULENGTH == 0);
}
COMPRESSED {
field;
ENFORCE(field.CLENGTH == len);
ENFORCE(field.CVALUE == val);
}
}
One possible use of this encoding method is to define padding in a compressed format:
この符号化方法の一つの可能な使用は、圧縮形式でパディングを定義することです。
pad_to_octet_boundary =:= compressed_value(3, 0);
pad_to_octet_boundary =：= compressed_value（3、0）;
A more common use is to define a discriminator field to make it possible to differentiate between different compressed formats within an encoding method (see Section 4.12). For convenience, the notation provides syntax for specifying "compressed_value" encoding in the form of a binary string. The binary string to be encoded is simply given in single quotes; the "CLENGTH" attribute of the field binds with the number of bits in the string, while its "CVALUE" attribute binds with the value given by the string. For example:
より一般的な用途は、（セクション4.12を参照）の符号化方式内の異なる圧縮フォーマットを区別することを可能にするためにディスクリミネータ・フィールドを定義することです。便宜上、表記は、バイナリ文字列の形式で「compressed_value」エンコーディングを指定するための構文を提供します。符号化されるバイナリ列は、単に単一引用符で与えられます。その「CVALUE」属性は、文字列で与えられた値と結合しながら、フィールドの「CLENGTH」属性は、文字列のビット数と結合します。例えば：
discriminator =:= '01101';
弁別=：= '01101';
This has exactly the same meaning as:
これは、とまったく同じ意味を持っています：
discriminator =:= compressed_value(5, 13);
弁別=：= compressed_value（5、13）。
The "irregular" encoding method is used to encode a field in the compressed format with a bit pattern identical to the uncompressed field. This encoding method is defined as follows:
「不規則な」符号化方法は、圧縮されていないフィールドと同一のビットパターンに圧縮形式でフィールドを符号化するために使用されます。これは次のように符号化方式が定義されています。
irregular(len) {
UNCOMPRESSED {
field;
ENFORCE(field.ULENGTH == len);
}
COMPRESSED {
field;
ENFORCE(field.CLENGTH == len);
ENFORCE(field.CVALUE == field.UVALUE);
}
}
For example, the checksum field of the TCP header is a 16-bit field that does not follow any predictable pattern from one header to another (and so it cannot be compressed):
例えば、TCPヘッダのチェックサムフィールドは、別のヘッダからの任意の予測可能なパターンに従わない（そしてそれは圧縮できない）16ビットのフィールドです。
tcp_checksum =:= irregular(16);
TCPチェックサム=：=不規則（16）。
Note that the length does not have to be constant, for example, an expression can be used to derive the length of the field from the value of another field.
長さは、例えば、発現は、別のフィールドの値からフィールドの長さを導出するために使用することができ、一定である必要はないことに留意されたいです。
The "static" encoding method compresses a field whose length and value are the same as for a previous header in the flow, i.e., where the field completely matches an existing entry in the context:
「静的」符号化方法は、長さおよび値フィールドを完全コンテキスト内の既存のエントリと一致するフロー内の前のヘッダ、すなわち、の場合と同じであるフィールドを圧縮します。
field =:= static;
フィールド=：=静的;
The field's "UVALUE" and "ULENGTH" attributes bind with their respective values in the context and the "CLENGTH" attribute is bound to zero.
フィールドの「UVALUE」と「ULENGTH」属性がコンテキスト内のそれぞれの値と結合し、「CLENGTH」属性がゼロにバインドされています。
Since the field value is the same as a previous field value, the entire field can be reconstructed from the context, so it is compressed to zero bits and does not appear in the compressed format.
フィールドの値が以前のフィールドの値と同じであるため、フィールド全体が文脈から再構成することができるので、零ビットに圧縮され、圧縮形式で表示されません。
For example, the source port of the TCP header is a field whose value does not change from one packet to the next for a given flow:
例えば、TCPヘッダの送信元ポートは、その値が所定のフローのために次の1つのパケットから変化しないフィールドです。
src_port =:= static;
src_port =：=静的;
The least significant bits encoding method, "lsb", compresses a field whose value differs by a small amount from the value stored in the context. The least significant bits of the field value are transmitted instead of the original field value.
メソッドをコード最下位ビットは、「LSB」、その値がコンテキストに格納されている値より小さな量だけ異なるフィールドを圧縮します。フィールド値の最下位ビットが代わりに元のフィールド値を伝達されます。
field =:= lsb(<num_lsbs_param>, <offset_param>);
フィールド=：= LSB（<num_lsbs_param>、<offset_param>）。
Here, "num_lsbs_param" is the number of least significant bits to use, and "offset_param" is the interpretation interval offset as defined below.
ここで、「num_lsbs_param」が使用する最下位ビットの数、及び「offset_param」は、以下に定義されるようなオフセット解釈インターバルです。
The parameter "num_lsbs_param" binds with the "CLENGTH" attribute, the "UVALUE" attribute binds to the value within the interval whose least significant bits match the "CVALUE" attribute. The value of the "ULENGTH" can be derived from the information stored in the context.
パラメータ「num_lsbs_param」が「CLENGTH」属性と結合する、「UVALUE」属性は、その最下位ビット「CVALUE」属性と一致区間内の値に結合します。 「ULENGTH」の値は、コンテキストに格納されている情報から導き出すことができます。
For example, the TCP sequence number:
たとえば、TCPシーケンス番号：
tcp_sequence_number =:= lsb(14, 8192);
tcp_sequence_number =：= LSB（14、8192）。
This takes up 14 bits, and can communicate any value that is between 8192 lower than the value of the field stored in context and 8191 above it.
これは14ビットを占め、及び8192間のコンテキストとその上8191に格納されたフィールドの値よりも低い任意の値を通信することができます。
The interpretation interval can be described as a function of a value stored in the context, ref_value, and of num_lsbs_param:
解釈インターバルはref_value、コンテキストに格納された値の関数として記述、及びnum_lsbs_paramのことができます。
f(context_value, num_lsbs_param) = [ref_value - offset_param, ref_value + (2^num_lsbs_param - 1) - offset_param]
F（context_value、num_lsbs_param）= [ref_value - offset_param、ref_value +（2 ^ num_lsbs_param - 1） - offset_param]
where offset_param is an integer.
offset_paramは整数です。
<-- interpretation interval (size is 2^num_lsbs_param) -->
|---------------------------+----------------------------|
lower ref_value upper
bound bound
where:
どこ：
lower bound = ref_value - offset_param
upper bound = ref_value + (2^num_lsbs_param-1) - offset_param
The "lsb" encoding method can therefore compress a field whose value lies between the lower and the upper bounds, inclusively, of the interpretation interval. In particular, if offset_param = 0, then the field value can only stay the same or increase relative to the reference value ref_value. If offset_param = -1, then it can only increase, whereas if offset_param = 2^num_lsbs_param, then it can only decrease.
「LSB」符号化方法は、したがって、解釈インターバルの、包括的に、その値が上限と下限の間にあるフィールドを圧縮することができます。 offset_param = 0の場合、特に、そのフィールドの値は、同じ滞在することができ、または基準値ref_valueに対して増加します。 offset_param = -1、それが唯一のoffset_param = 2 ^ num_lsbs_param場合一方、増加させることができた場合は、それが唯一減少することができます。
The compressed field takes up the specified number of bits in the compressed format (i.e., num_lsbs_param).
圧縮されたフィールドは、圧縮形式（すなわち、num_lsbs_param）のビットの指定された数を占めます。
The compressor may not be able to determine the exact reference value stored in the decompressor context and that will be used by the decompressor, since some packets that would have updated the context may have been lost or damaged. However, from feedback received or by making assumptions, the compressor can limit the candidate set of values. The compressor can then select a format that uses "lsb" encoding, defined with suitable values for its parameters num_lsbs_param and offset_param, such that no matter which context value in the candidate set the decompressor uses, the resulting decompression is correct. If that is not possible, the "lsb" encoding method fails (which typically results in a less efficient compressed format being chosen by the compressor). How the compressor determines what reference values it stores and maintains in its set of candidate references is outside the scope of the notation.
圧縮機は、デコンプレッサのコンテキストに格納された正確な基準値を決定することができない場合があり、コンテキストを更新したであろういくつかのパケットが紛失または破損している可能性があるので、それは、減圧装置によって使用されます。しかし、フィードバックから受信又は仮定することにより、圧縮機は、値の候補セットを制限することができます。圧縮機は、候補のコンテキスト値をデコンプレッサが使用する設定に関係なく、得られた減圧が正確であるように、そのパラメータnum_lsbs_paramとoffset_paramに適した値で定義された「LSB」符号化を使用する形式を選択することができます。それが不可能な場合は、「LSB」符号化方法は、（典型的には、効率的な圧縮形式でもたらされる圧縮機によって選択されている）が失敗しました。どのように圧縮機は、それが基準値を記憶し、候補参照のセットに保持内容を決定する表記の範囲外です。
The "crc" encoding method provides a CRC calculated over a block of data. The algorithm used to calculate the CRC is the one specified in [RFC4995]. The "crc" method takes a number of parameters:
「CRC」符号化方式は、データのブロックにわたって計算されたCRCを提供します。 CRCを計算するために使用されるアルゴリズムは[RFC4995]で指定されたものです。 「CRC」の方法は、多数のパラメータを取ります。
o the number of bits for the CRC (crc_bits),
O CRC（crc_bits）のビット数、
o the bit-pattern for the polynomial (bit_pattern),
O多項式（bit_pattern）のためのビットパターン、
o the initial value for the CRC register (initial_value),
O CRCレジスタ（initial_value）の初期値、
o the value of the block of data, represented using either the "UVALUE" or "CVALUE" attribute of a field (block_data_value); and
データのブロックの値O、「UVALUE」またはフィールドの「CVALUE」属性（block_data_value）のいずれかを用いて表されます。そして
o the size in octets of the block of data (block_data_length).
データのブロックのオクテット大きさ（block_data_length）O。
That is:
あれは：
field =:= crc(<num_bits>, <bit_pattern>, <initial_value>, <block_data_value>, <block_data_length>);
フィールド=：= CRC（<num_bits>、<bit_pattern>、<initial_value>、<block_data_value>、<block_data_length>）。
When specifying the bit pattern for the polynomial, each bit represents the coefficient for the corresponding term in the polynomial. Note that the highest order term is always present (by definition) and therefore does not need specifying in the bit pattern. Therefore, a CRC polynomial with n terms in it is represented by a bit pattern with n-1 bits set.
多項式のビットパターンを指定する場合、各ビットは多項式の対応する項の係数を表します。最高次の項が（定義により）常に存在しているため、ビットパターンで指定する必要がないことに注意してください。したがって、その中にn個の用語とCRC多項式は集合N-1ビットとのビットパターンによって表されます。
The CRC is calculated in least significant bit (LSB) order.
CRCは、最下位ビット（LSB）ために計算されます。
For example:
例えば：
// 3 bit CRC, C(x) = x^0 + x^1 + x^3 crc_field =:= crc(3, 0x6, 0xF, THIS.CVALUE, THIS.CLENGTH);
// 3ビットCRC、C（X）= X ^ 0 + X ^ 1 + X ^ 3 crc_field =：= CRC（3、0x6に、0xFの、THIS.CVALUE、THIS.CLENGTH）。
Usage of the "THIS" keyword (see Section 4.6) as shown above, is typical when using "crc" encoding. For example, when used in the encoding method for an entire header, it causes the CRC to be calculated over all fields in the header.
「この」キーワードの使用は、上記のように、（セクション4.6を参照）、「CRC」符号化を使用する場合に典型的です。例えば、全体のヘッダの符号化方法で使用される場合、それは、CRCはヘッダ内のすべてのフィールドにわたって計算されるようにします。
New encoding methods can be defined in a formal specification. These compose groups of individual fields into a contiguous block.
新しい符号化方式は、正式な仕様で定義することができます。これらは、連続したブロックの中に、個々のフィールドのグループを構成しています。
Encoding methods have names and may have parameters; they can also be used in the same way as any other encoding method from the library of encoding methods. Since they can contain references to other encoding methods, complicated formats can be broken down into manageable pieces in a hierarchical fashion.
符号化方式は、名前を持ち、パラメータを有していてもよいです。彼らはまた、符号化方法のライブラリからの任意の他の符号化方式と同様に使用することができます。それらは他の符号化方法への参照を含むことができるので、複雑な形式が階層的に管理可能な断片に分解することができます。
This section describes the various features used to define new encoding methods.
このセクションでは、新しい符号化方式を定義するために使用される様々な機能について説明します。
This simplest form of defining an encoding method is to specify a single encoding. For example:
符号化方法を規定のこの最も単純な形態は、単一の符号化を指定することです。例えば：
compound_encoding_method { UNCOMPRESSED { field_1; // 4 bits field_2; // 12 bits }
compound_encoding_method {UNCOMPRESSED {FIELD_1。 // 4ビットfield_2。 // 12ビット}
COMPRESSED { field_2 =:= uncompressed_value(12, 9); // 0 bits field_1 =:= irregular(4); // 4 bits } }
COMPRESSED {field_2 =：= uncompressed_value（12、9）。 // 0ビットFIELD_1 =：=不規則（4）。 // 4ビット}}
The above begins with the new method's identifier, "compound_encoding_method". The definition of the method then follows inside curly brackets, "{" and "}". The first item in the definition is the "UNCOMPRESSED" field list, which gives the order of the fields in the uncompressed format. This is followed by the compressed format field list ("COMPRESSED"). This list gives the order of fields in the compressed format and also gives the encoding method for each field.
上記は、新しいメソッドの識別子、「compound_encoding_method」で始まります。メソッドの定義は、次に、中かっこ内の、「{」および「}」に続きます。定義の最初の項目は、非圧縮形式のフィールドの順序を与える「UNCOMPRESSED」フィールドリスト、です。これは、圧縮形式のフィールドリスト（「圧縮」）が続いています。このリストには、圧縮形式のフィールドの順序を与え、また、各フィールドの符号化方法を与えます。
In the example, both the formats list each field exactly once. However, sometimes it is necessary to specify more than one binding for a given field, which means it appears more than once in the field list. In this case, it is the first occurrence of the field in the list that indicates its position in the field order. The subsequent occurrences of the field only specify binding information, not field order information.
例では、両方のフォーマットは正確に一度、各フィールドをリストします。しかし、時にはフィールドリストで複数回出現意味与えられたフィールドのためのバインディングつ以上を指定する必要があります。この場合には、フィールドの順序におけるその位置を示すリスト内のフィールドの最初の発生です。フィールドのその後の発生が唯一のバインディング情報ではなく、フィールドの順序情報を指定します。
The different components of this example are described in more detail below. Other components that can be used in the definition of encoding methods are also defined thereafter.
この例の種々のコンポーネントは、以下でより詳細に記載されています。符号化方式の定義に使用することができる他の成分はまた、以降に定義されています。
The uncompressed field list is defined by "UNCOMPRESSED", which specifies the fields of the uncompressed format in the order that they appear in the uncompressed header. The sum of the lengths of each individual uncompressed field in the list must be equal to the length of the field being encoded. Finally, the representation of the uncompressed format described using the list of fields in the "UNCOMPRESSED" section, for which compressed formats are being defined, always consists of one single contiguous block of bits.
圧縮されていないフィールドのリストは、それらが解凍されたヘッダーに表示されるために非圧縮形式のフィールドを指定する「UNCOMPRESSED」によって定義されます。リスト内の各個々の圧縮されていないフィールドの長さの合計は、符号化されるフィールドの長さに等しくなければなりません。最後に、非圧縮形式の表現は常にビットの1つの連続したブロックで構成され、圧縮されたフォーマットが定義されている「UNCOMPRESSED」セクション内のフィールドのリストを用いて説明しました。
In the example above in Section 4.12.1, the uncompressed field list is "field_1", followed by "field_2". This means that a field being encoded by this method is divided into two subfields, "field_1" and "field_2". The total uncompressed length of these two fields therefore equals the length of the field being encoded:
セクション4.12.1に上記の例では、圧縮されていないフィールドのリストは、「field_2」、続いて「FIELD_1」です。これは、この方式で符号化されたフィールドは、2つのサブフィールド、「FIELD_1」および「field_2」に分割されていることを意味します。これら二つのフィールドの合計の非圧縮長さは、従って、符号化されるフィールドの長さに等しいです。
field_1.ULENGTH + field_2.ULENGTH == THIS.ULENGTH
field_1.ULENGTH + field_2.ULENGTH == THIS.ULENGTH
In the example, there are only two fields, but any number of fields may be used. This relationship applies to however many fields are actually used. Any arrangement of fields that efficiently describes the content of the uncompressed header may be chosen -- this need not be the same as the one described in the specifications for the protocol header being compressed.
一例では、そこにのみ2つのフィールドがあるが、フィールドの任意の数が使用されてもよいです。この関係は、多くの分野が実際に使用されているがに適用されます。効率的に圧縮されていないヘッダの内容を記述するフィールドの任意の配置を選択することができる - この必要性は、圧縮されるプロトコルヘッダの仕様に記載したのと同じではありません。
For example, there may be a protocol whose header contains a 16-bit sequence number, but whose sessions tend to be short-lived. This would mean that the high bits of the sequence number are almost always constant. The "UNCOMPRESSED" format could reflect this by splitting the original uncompressed field into two fields, one field to represent the almost-always-zero part of the sequence number, and a second field to represent the salient part.
例えば、そのヘッダ16ビットのシーケンス番号を含むが、そのセッション短命になる傾向があるプロトコルが存在してもよいです。これは、シーケンス番号の高いビットは、ほぼ常に一定であることを意味します。 「UNCOMPRESSED」フォーマットは、シーケンス番号、及び凸部を表現する第2のフィールドの殆ど常にゼロ部分を表すために2つのフィールドは、1フィールドに元の非圧縮フィールドを分割することにより、これを反映し得ます。
An "UNCOMPRESSED" field list may specify encoding methods in the same way as the "COMPRESSED" field list in the example. Encoding methods specified therein are used whenever a packet with that uncompressed format is being encoded. The encoding of a packet with a given uncompressed format can only succeed if all of its encoding methods and "ENFORCE" statements succeed (see Section 4.9).
「UNCOMPRESSED」フィールドリストは、例の「圧縮」フィールドリストと同様に、符号化方法を指定することができます。その非圧縮形式のパケットが符号化されるたびに、その中に指定された符号化方法が使用されます。与えられた非圧縮形式のパケットのエンコーディングは、その符号化方式のすべての場合には成功し、文が（4.9節を参照してください）成功「ENFORCE」することができます。
The total length of each uncompressed format must always be defined. The length of each of the fields in an uncompressed format must also be defined. This means that the bindings in the "UNCOMPRESSED", "COMPRESSED" (see Section 4.12.1.2 below), "CONTROL" (see Section 4.12.1.3 below), "INITIAL" (see Section 4.12.1.4 below), and "DEFAULT" (see Section 4.12.1.5 below) field lists must, between them, define the "ULENGTH" attribute of every field in an uncompressed format so that there is an unambiguous mapping from the bits in the uncompressed format to the fields listed in the "UNCOMPRESSED" field list.
各非圧縮形式の全長は、常に定義されなければなりません。非圧縮形式の各フィールドの長さも定義されなければなりません。これは、「UNCOMPRESSED」でバインディング、「圧縮」（以下のセクション4.12.1.2を参照）、「CONTROL」（以下のセクション4.12.1.3を参照）、「INITIAL」（以下のセクション4.12.1.4を参照）、および「DEFAULT 「に記載されているフィールドに、非圧縮形式のビットから明確なマッピングが存在するように、非圧縮形式ですべてのフィールドの属性 『ULENGTH』フィールドのリストは、それらの間で、定義する必要があります（以下のセクション4.12.1.5を参照してください）」 UNCOMPRESSED」フィールドリスト。
Similar to the uncompressed field list, the fields in the compressed header will appear in the order specified by the compressed field list given for a compressed format. Each individual field is encoded in the manner given for that field. The total length of the compressed data will be the sum of the compressed lengths of all the individual fields. In the example from Section 4.12.1, the encoding methods used for these fields indicate that they are zero and 4 bits long, making a total of 4 bits.
圧縮されていないフィールドのリストと同様、圧縮ヘッダ内のフィールドは、圧縮形式のために与えられた圧縮されたフィールドリストで指定された順番に表示されます。各個々のフィールドは、そのフィールドに対して所定の方法で符号化されます。圧縮されたデータの合計長さは、全ての個々のフィールドの圧縮された長さの和であろう。セクション4.12.1の例では、これらのフィールドのために使用される符号化方法は、4ビットの合計を作り、それらがゼロと4ビット長であることを示しています。
The order of the fields specified in a "COMPRESSED" field list does not have to match the order they appear in the "UNCOMPRESSED" field list. It may be desirable to reorder the fields in the compressed format to align the compressed header to the octet boundary, or for other reasons. In the above example, the order is in fact the opposite of that in the uncompressed format.
「圧縮」フィールドリストで指定したフィールドの順序は、「UNCOMPRESSED」フィールドリストに表示される順序と一致する必要はありません。オクテット境界に、または他の理由のために圧縮されたヘッダを整列させるために圧縮形式のフィールドの順序を変更することが望ましい場合があります。上記の例では、順序は、実際には非圧縮形式でその反対です。
The compressed field list specifies that the encoding for "field_1" is "irregular", and takes up 4 bits in both the compressed format and uncompressed format. The encoding for "field_2" is "uncompressed_value", which means that the field has a fixed value, so it can be compressed to zero bits. The value it takes is 9, and it is 12 bits wide in the uncompressed format.
圧縮されたフィールドリストは、「FIELD_1」の符号化は、「不規則」であり、圧縮形式と非圧縮形式の両方で4ビットを占有することを指定します。 「field_2」の符号化は、フィールドは固定値を有することを意味し、「uncompressed_value」であるので、ゼロビットに圧縮することができます。それが取る値は9であり、非圧縮形式の12ビット幅です。
Fields like "field_2", which compress to zero bits in length, may appear anywhere in the field list without changing the compressed format because their position in the list is not significant. In fact, if the encoding method for this field were defined elsewhere (for example, in the "UNCOMPRESSED" section), this field could be omitted from the "COMPRESSED" section altogether:
長さがゼロのビットに圧縮する「field_2」のようなフィールドは、リスト内のそれらの位置は重要ではないので、圧縮形式を変更することなく、どこでも、フィールドリストに表示されてもよいです。実際には、このフィールドの符号化方法は、他の場所で定義された場合（例えば、「UNCOMPRESSED」に）、このフィールドは完全に「圧縮」セクションから省略することができます。
compound_encoding_method { UNCOMPRESSED { field_1; // 4 bits field_2 =:= uncompressed_value(12, 9); // 12 bits }
compound_encoding_method {UNCOMPRESSED {FIELD_1。 // 4ビットfield_2 =：= uncompressed_value（12、9）。 // 12ビット}
COMPRESSED { field_1 =:= irregular(4); // 4 bits } }
COMPRESSED {FIELD_1 =：=（4）不規則。 // 4ビット}}
The total length of each compressed format must always be defined. The length of each of the fields in a compressed format must also be defined. This means that the bindings in the "UNCOMPRESSED", "COMPRESSED", "CONTROL" (see Section 4.12.1.3 below), "INITIAL" (see Section 4.12.1.4 below), and "DEFAULT" (see Section 4.12.1.5 below) field lists must between them define the "CLENGTH" attribute of every field in a compressed format so that there is an unambiguous mapping from the bits in the compressed format to the fields listed in the "COMPRESSED" field list.
各圧縮形式の全長は、常に定義されなければなりません。圧縮形式の各フィールドの長さも定義されなければなりません。これは、「UNCOMPRESSED」のバインディングは、「圧縮」、「CONTROL」（以下のセクション4.12.1.3を参照）、「INITIAL」、および「DEFAULT」（セクション4.12.1.4以下を参照してください）（以下のセクション4.12.1.5を参照してくださいことを意味します「圧縮」フィールドリストに表示されるフィールドに圧縮形式でビットから明確なマッピングが存在するように）フィールドのリストは、それらの間で圧縮された形式で、あらゆる分野の「CLENGTH」属性を定義する必要があります。
Control fields are defined using the "CONTROL" field list. The control field list specifies all fields that do not appear in the uncompressed format, but that have an uncompressed value (specifically those with an "ULENGTH" greater than zero). Such fields may be used to help compress fields from the uncompressed format more efficiently. A control field could be used to improve efficiency by representing some commonality between a number of the uncompressed fields, or by representing some information about the flow that is not explicitly contained in the protocol headers.
制御フィールドは、「CONTROL」フィールドリストを使用して定義されています。制御フィールドリストは、非圧縮形式で表示されますが、それは圧縮されていない値を持っていないすべてのフィールド（「ULENGTH」ゼロよりも大きいと特異的にそれら）を指定します。このようなフィールドは、より効率的に非圧縮形式からフィールドを圧縮助けるために使用することができます。制御フィールドは圧縮されていないフィールドの数との間のいくつかの共通性を表すことによって、または明示的にプロトコルヘッダに含まれていないフローに関するいくつかの情報を表すことにより、効率を改善するために使用することができます。
For example in IPv4, the behaviour of the IP-ID field in a flow varies depending on how the endpoints handle IP-IDs. Sometimes the behaviour is effectively random and sometimes the IP-ID follows a predictable sequence. The type of IP-ID behaviour is information that is never communicated explicitly in the uncompressed header.
IPv4では、例えば、フロー内のIP-IDフィールドの動作は、エンドポイントはIP-IDを処理する方法に応じて変化します。時には、動作が効果的にランダムであり、時にはIP-IDは、予測可能な順序に従います。 IP-IDの挙動のタイプは、非圧縮ヘッダで明示的に伝達されることはない情報です。
However, a profile can still be designed to identify the behaviour and adjust the compression strategy according to the identified behaviour, thereby improving the compression performance. To do so, the ROHC-FN specification can introduce an explicit field to communicate the IP-ID behaviour in compressed format -- this is done by introducing a control field:
しかし、プロファイルは、依然として、それによって圧縮性能を向上させること、行動を識別し、識別された行動に応じて圧縮戦略を調整するように設計することができます。そうするために、ROHC-FN仕様は、圧縮形式でIP-IDの動作を通信するために、明示的なフィールドを導入することができる - これは、制御フィールドを導入することによって行われます。
ipv4 { UNCOMPRESSED { version; // 4 bits hdr_length; // 4 bits protocol; // 8 bits dscp; // 6 bits ip_ecn_flags; // 2 bits ttl_hopl; // 8 bits df; // 1 bit mf; // 1 bit rf; // 1 bit frag_offset; // 13 bits ip_id; // 16 bits src_addr; // 32 bits dst_addr; // 32 bits checksum; // 16 bits length; // 16 bits }
IPv4の{UNCOMPRESSED {バージョン。 // 4ビットhdr_length。 // 4ビットプロトコル。 // 8ビットのDSCP。 // 6ビットip_ecn_flags。 // 2ビットttl_hopl。 // 8ビットDF。 // 1ビットのMF。 // 1ビットのRF; // 1ビットfrag_offset。 // 13ビットip_id。 // 16ビットsrc_addrを。 // 32ビットdst_addr。 // 32ビットのチェックサム。 // 16ビット長。 // 16ビット}
CONTROL { ip_id_behavior; // 1 bit : :
CONTROL {ip_id_behavior。 // 1ビット：
The "CONTROL" field list is equivalent to the "UNCOMPRESSED" field list for fields that do not appear in the uncompressed format. It defines a field that has the same properties (the same defined attributes, etc.) as fields appearing in the uncompressed format.
「CONTROL」フィールドリストは、非圧縮形式で表示されないフィールドのための「UNCOMPRESSED」フィールドリストと同じです。これは、非圧縮形式に現れるフィールドと同じ特性（同じ定義された属性、等）を有するフィールドを定義します。
Control fields are initialised by using the appropriate encoding methods and/or by using "ENFORCE" statements. This may be done inside the "CONTROL" field list.
制御フィールドは、適切な符号化方法を使用することによって、および/または「ENFORCE」ステートメントを使用して初期化されます。これは、「CONTROL」フィールドリスト内で行うことができます。
For example:
例えば：
example_encoding_method_definition { UNCOMPRESSED { field_1 =:= some_encoding; }
example_encoding_method_definition {UNCOMPRESSED {FIELD_1 =：= some_encoding。 }
CONTROL {
scaled_field;
ENFORCE(scaled_field.UVALUE == field_1.UVALUE / 8);
ENFORCE(scaled_field.ULENGTH == field_1.ULENGTH - 3);
}
COMPRESSED { scaled_field =:= lsb(4, 0); } }
COMPRESSED {scaled_field =：= LSB（4、0）; }}
This control field is used to scale down a field in the uncompressed format by a factor of 8 before encoding it with the "lsb" encoding method. Scaling it down makes the "lsb" encoding more efficient.
この制御フィールドは、「LSB」符号化方法とそれを符号化する前に8倍、非圧縮形式のフィールドを縮小するために使用されます。それをダウンスケーリング「LSB」より効率的にエンコードすることができます。
Control fields may also be used with a global scope. In this case, their declaration must be outside of any encoding method definition. They are then visible within any encoding method, thus allowing information to be shared between encoding methods directly.
制御フィールドは、グローバルスコープで使用することができます。この場合には、それらの宣言は、任意の符号化方式の定義の外側でなければなりません。彼らは、このような情報を直接符号化方式間で共有されることを可能にする、任意の符号化方式の中に、次に表示されています。
In order to allow fields in the very first usage of a specific format to be compressed with "static", "lsb", or other encoding methods that depend on the context, it is possible to specify initial bindings for such fields. This is done using "INITIAL", for example:
「静的」で圧縮される特定の形式の非常に最初の使用のフィールド、「LSB」、または文脈に依存する他の符号化方法を可能にするために、このようなフィールドの最初のバインディングを指定することが可能です。これは、例えば、「INITIAL」を使用して行われます。
INITIAL { field =:= uncompressed_value(4, 6); }
INITIAL {フィールド= = uncompressed_value（4、6）; }
This initialises the "UVALUE" of "field" to 6 and initialises its "ULENGTH" to 4. Unlike all other bindings specified in the formal notation, these bindings are applied to the context of the field, if the field's context is undefined. This is particularly useful when using encoding methods that rely on context being present, such as "static" or "lsb", with the first packet in a flow.
これは6に、「フィールド」の「UVALUE」を初期化し、正式な表記法で指定された他のすべてのバインディングとは異なり4にその「ULENGTHを」初期化フィールドのコンテキストが定義されていない場合は、これらのバインディングは、フィールドのコンテキストに適用されます。このようなフローの最初のパケットと、「静的」または「LSB」として存在している文脈に依存している符号化方法を使用する場合に特に有用です。
Because the "INITIAL" field list is used to bind the context alone, it makes no sense to specify initial bindings that themselves rely on the context, for example, "lsb". Such usage is not allowed.
「INITIAL」フィールドリストが単独でコンテキストを結合するために使用されているので、それ自体は、例えば、「LSB」文脈に依存している初期のバインディングを指定しても意味がありません。このような使用は許可されていません。
Default bindings may be specified for each field or attribute. The default encoding methods specify the encoding method to use for a field if no binding is given elsewhere for the value of that field. This is helpful to keep the definition of the formats concise, as the same encoding method need not be repeated for every format, when defining multiple formats (see Section 4.12.3).
デフォルトのバインディングは、各フィールドまたは属性に指定することができます。デフォルトの符号化方式には、結合は、そのフィールドの値を他の場所で与えられない場合、このフィールドに使用する符号化方法を指定します。複数のフォーマットを定義するときに、同じ符号化方式は、すべてのフォーマットのために繰り返される必要はないので、これは、簡潔な形式の定義を維持するために有用である、（セクション4.12.3を参照）。
Default bindings are optional and may be given for any combination of fields and attributes which are in scope.
デフォルトバインディングはオプションであり、範囲内にあるフィールドと属性の任意の組み合わせのために与えられてもよいです。
The syntax for specifying default bindings is similar to that used to specify a compressed or uncompressed format. However, the order of the fields in the field list does not affect the order of the fields in either the compressed or uncompressed format. This is because the field order is specified individually for each "COMPRESSED" format and "UNCOMPRESSED" format.
デフォルトのバインディングを指定するための構文は、圧縮または非圧縮形式を指定するために使用されるものと同様です。しかし、フィールドリスト内のフィールドの順序は、いずれかの圧縮または非圧縮形式のフィールドの順序には影響を与えません。フィールドの順序は、各「圧縮」形式と「UNCOMPRESSED」形式ごとに個別に指定されているためです。
Here is an example:
次に例を示します。
DEFAULT {
field_1 =:= uncompressed_value(4, 1);
field_2 =:= uncompressed_value(4, 2);
field_3 =:= lsb(3, -1);
ENFORCE(field_4.ULENGTH == 4);
}
｝
Here default bindings are specified for fields 1 to 3. A default binding for the "ULENGTH" attribute of field_4 is also specified.
ここではデフォルトのバインディングは1 field_4の「ULENGTH」属性のデフォルトのバインディングも指定されている3へのフィールドに指定されています。
Fields for which there is a default encoding method do not need their bindings to be specified in the field list of any format that uses the default encoding method for that field. Any format that does not use the default encoding method must explicitly specify a binding for the value of that field's attributes.
デフォルトの符号化方式があるためにフィールドには、そのフィールドのデフォルトのエンコード方式を使用して任意の形式のフィールドリストで指定するために彼らのバインディングを必要としません。デフォルトのエンコード方式を使用していない任意のフォーマットは、明示的にそのフィールドの属性の値のバインディングを指定する必要があります。
If elsewhere a binding is not specified for the attributes of a field, the default encoding method is used. If the default encoding method always compresses the field down to zero bits, the field can be omitted from the compressed format's field list. Like any other zero-bit field, its position in the field list is not significant.
他の場所でフィールドの属性に指定されていないバインディング場合は、デフォルトの符号化方式が使用されています。デフォルトのエンコード方式は、常にゼロビットにダウンフィールドを圧縮した場合、フィールドは圧縮形式のフィールドリストから省略することができます。他のゼロビットフィールドと同様に、フィールドリスト内での位置は重要ではありません。
The "DEFAULT" field list may contain default bindings for individual attributes by using "ENFORCE" statements. A default binding for an individual attribute will only be used if elsewhere there is no binding given for that attribute or the field to which it belongs. If elsewhere there is an "ENFORCE" statement binding that attribute, or an encoding method binding the field to which it belongs, the default binding for the attribute will not be used. This applies even if the specified encoding method does not bind the particular attribute given in the "DEFAULT" section. However, an "ENFORCE" statement elsewhere that only binds the length of the field still allows the default bindings to be used, except for default "ENFORCE" statements which bind nothing but the field's length.
「DEFAULT」フィールドリストは、「ENFORCE」ステートメントを使用して、個々の属性のデフォルトのバインディングが含まれていてもよいです。他の場所で何の結合、それが属するその属性またはフィールドのために与えられたが存在しない場合は、個々の属性のデフォルトバインディングにのみ使用されます。他の場所でその属性を結合ステートメント、またはそれが属するフィールドを結合符号化方法を「ENFORCE」がある場合は、属性のデフォルトのバインディングは使用されません。これは、指定された符号化方式は、「DEFAULT」のセクションに与えられた特定の属性を結合しない場合にも適用されます。しかし、唯一のフィールドの長さは、まだデフォルト以外の、デフォルトのバインディングを使用することができます結合することを他の場所で声明を「ENFORCE」フィールドの長さだけを結合していない文を「ENFORCE」。
To clarify, assuming the default bindings given in the example above, the first three of the following four compressed formats would not use the default binding for "field_4.ULENGTH":
明確にするために、デフォルトバインディング上記の例で与えられたと仮定すると、以下の4つの圧縮フォーマットの最初の3つは「field_4.ULENGTH」のデフォルトバインディングを使用しないであろう。
COMPRESSED format1 {
ENFORCE(field_4.ULENGTH == 3); // set ULENGTH to 3
ENFORCE(field_4.UVALUE == 7); // set UVALUE to 7
}
COMPRESSED format2 { field_4 =:= irregular(3); // set ULENGTH to 3 }
COMPRESSEDフォーマット2 {field_4 =：=不規則（3）。 //} 3にULENGTH設定
COMPRESSED format3 { field_4 =:= '1010'; // set ULENGTH to zero }
COMPRESSED形式3 {field_4 =：= '1010'。 //}ゼロにULENGTHを設定します
COMPRESSED format4 { ENFORCE(field_4.UVALUE == 12); // use default ULENGTH }
圧縮形式4 {ENFORCE（フィールド4.UのVALUE == 12）。 //使用するデフォルトの長さ}
The fourth format is the only one that uses the default binding for "field_4.ULENGTH".
第四の形式は「field_4.ULENGTH」のためのデフォルトのバインディングを使用する唯一のものです。
In summary, the default bindings of an encoding method are only used for formats that do not already specify a binding for the value of all of their fields. For the formats that do use default bindings, only those fields and attributes whose bindings are not specified are looked up in the "DEFAULT" field list.
要約すると、符号化方式のデフォルトのバインディングは、すでにそれぞれの分野のすべての値のバインディングを指定していないフォーマットのために使用されています。デフォルトのバインディングを使用して行う形式、そのバインディングに指定されていない「DEFAULT」フィールドリストで検索されているフィールドのみと属性のため。
Encoding methods may take arguments that control the mapping between compressed and uncompressed fields. These are specified immediately after the method's name, in parentheses, as a comma-separated list.
符号化方式は、圧縮と非圧縮のフィールド間のマッピングを制御引数を取ることがあります。これらは、カンマで区切ったリストとして、括弧で、メソッド名の直後に指定されています。
For example:
例えば：
poor_mans_lsb(variable_length)
{
UNCOMPRESSED {
constant_bits;
variable_bits;
}
COMPRESSED {
variable_bits =:= irregular(variable_length);
constant_bits =:= static;
}
}
As with any encoding method, all arguments take individual values, such as an integer literal or a field attribute, rather than entire fields. Although entire fields cannot be passed as arguments, it is possible to pass each of their attributes instead, which is equivalent.
任意の符号化方式と同様に、すべての引数ではなく全体のフィールドよりも、そのような整数リテラルまたはフィールド属性として個々の値をとります。全体のフィールドは、引数として渡すことはできませんが、等価である、代わりにその属性のそれぞれに合格することが可能です。
Recall that all bindings are two-way, so that rather than the arguments acting as "inputs" to the encoding method, the result of an encoding method may be to bind the parameters passed to it.
すべてのバインディングが双方向であることを思い出し、むしろ符号化方式を「入力」として作用引数よりように、符号化方法の結果は、それに渡されたパラメータを結合することであってもよいです。
For example:
例えば：
set_to_double(arg1, arg2) { CONTROL { ENFORCE(arg1 == 2 * arg2); } }
set_to_double（ARG1、ARG2）{CONTROL {（ARG1 == 2 * ARG2）をENFORCE。 }}
This encoding method will attempt to bind the first argument to twice the value of the second. In fact this "encoding" method is pathological. Since it defines no fields, it does not do any actual encoding at all. "CONTROL" sections are more appropriate to use for this purpose than "UNCOMPRESSED".
この符号化方式は、第二の値の2倍の最初の引数をバインドしようとします。実際には、この「コードする」方法が病的です。それはフィールドを定義していないので、それはまったくの実際のエンコードを行いません。 「CONTROL」のセクションでは、「UNCOMPRESSED」よりも、この目的のために使用することがより適切です。
Encoding methods can also define multiple formats for a given header. This allows different compression methods to be used depending on what is the most efficient way of compressing a particular header.
符号化方法は、所定のヘッダの複数のフォーマットを定義することができます。これは、異なる圧縮方法は、特定のヘッダを圧縮する最も効率的な方法が何であるかに応じて使用されることを可能にします。
For example, a field may have a fixed value most of the time, but the value may occasionally change. Using a single format for the encoding, this field would have to be encoded using "irregular" (see Section 4.11.3), even though the value only changes rarely. However, by defining multiple formats, we can provide two alternative encodings: one for when the value remains fixed and another for when the value changes.
例えば、フィールドは、ほとんどの時間を固定値があるかもしれませんが、値は時折変更されることがあります。符号化のための単一のフォーマットを使用して、このフィールドを使用して符号化されなければならない「不規則」（セクション4.11.3を参照）、値がまれにしか変化しないにもかかわらず。値の変化の値が固定されたままとき用と別：しかし、複数のフォーマットを定義することにより、我々は二つの別のエンコーディングを提供することができます。
This is the topic of the following sub-sections.
これは、次のサブセクションのトピックです。
When compressed formats are defined, they must be defined using the reserved word "COMPRESSED". Similarly, uncompressed formats must be defined using the reserved word "UNCOMPRESSED". After each of these keywords, a name may be given for the format. If no name is given to the format, the name of the format is empty.
圧縮フォーマットが定義されている場合、彼らは「圧縮」予約語を使用して定義する必要があります。同様に、非圧縮フォーマットが予約語「UNCOMPRESSED」を使用して定義されなければなりません。これらのキーワードのそれぞれの後、名前はフォーマットのために与えられてもよいです。名前が形式に指定されていない場合は、フォーマットの名前は空です。
Format names, except for the case where the name is empty, follow the syntactic rules of identifiers as described in Section 4.2.
4.2節で説明したようにフォーマット名は、名前が空の場合を除き、識別子の構文規則に従ってください。
Format names must be unique within the scope of the encoding method to which they belong, except for the empty name, which may be used for one "COMPRESSED" and one "UNCOMPRESSED" format.
形式名は、彼らが1「圧縮」と一つの「UNCOMPRESSED」形式のために使用することができる空の名前を除き、所属する符号化方法の範囲内で一意である必要があります。
Each of the compressed formats has its own field list. A compressor may pick any of these alternative formats to compress a header, as long as the field bindings it employs can be used with the uncompressed format. For example, the compressor could not choose to use a compressed format that had a "static" encoding for a field whose "UVALUE" attribute differs from its corresponding value in the context.
圧縮された形式のそれぞれが独自のフィールドリストを持っています。圧縮機は、それが使用するフィールドバインディングは非圧縮形式で使用することができるように、ヘッダを圧縮するために、これらの代替フォーマットのいずれかを選択してもよいです。例えば、圧縮機は、その「UVALUE」属性コンテキスト内の対応する値とは異なるフィールドは、「静的な」符号化を有していた圧縮フォーマットを使用するように選択することができませんでした。
More formally, the compressor can choose any combination of an uncompressed format and a compressed format for which no binding for any of the field's attributes "fail", i.e., the encoding methods and "ENFORCE" statements (see Section 4.9) that bind their compressed attributes succeed. If there are multiple successful combinations, the compressor can choose any one. Otherwise if there are no successful combinations, the encoding method "fails". A format will never fail due to it not defining the "UVALUE" attribute of a field. A format only fails if it fails to define one of the compressed attributes of one of the fields in the compressed format, or leaves the length of the uncompressed format undefined.
より正式には、圧縮機は、非圧縮形式となしフィールドの属性のいずれにも結合「失敗」のための圧縮形式の任意の組み合わせを選択することができ、すなわち、符号化方式とその圧縮をバインド文（セクション4.9を参照）「ENFORCE」属性は成功します。複数の成功の組み合わせがある場合は、コンプレッサーはいずれかを選択することができます。何の成功の組み合わせが存在しない場合はそれ以外の場合は、符号化方式は、「失敗しました」。フォーマットは、フィールドの「UVALUE」属性を定義していないため、それに失敗することはありません。フォーマットは、それが圧縮形式のフィールドのいずれかの圧縮された属性のいずれかを定義するために失敗した場合、失敗、または未定義の非圧縮形式の長さを残します。
Because the compressor has a choice, it must be possible for the decompressor to discriminate between the different compressed formats that the compressor could have chosen. A simple approach to this problem is for each compressed format to include a "discriminator" that uniquely identifies that particular "COMPRESSED" format. A discriminator is a control field; it is not derived from any of the uncompressed field values (see Section 4.11.2).
コンプレッサーは選択肢を持っているので解凍器は、コンプレッサーが選ばれている可能性が異なる圧縮形式を区別することが可能でなければなりません。各圧縮形式が一意にその特定の「圧縮」形式を識別する「識別器」を含むように、この問題に対する単純なアプローチです。弁別器は制御フィールドです。それは圧縮されていないフィールド値のいずれかから誘導されていません（4.11.2を参照してください）。
Putting this all together, here is a complete example of the definition of an encoding method with multiple compressed formats:
すべて一緒にこれを置くこと、ここで複数の圧縮フォーマットと符号化方式の定義の完全な例です。
example_multiple_formats { UNCOMPRESSED { field_1; // 4 bits field_2; // 4 bits field_3; // 24 bits }
example_multiple_formats {UNCOMPRESSED {FIELD_1。 // 4ビットfield_2。 // 4ビットfield_3。 // 24ビット}
DEFAULT {
field_1 =:= static;
field_2 =:= uncompressed_value(4, 2);
field_3 =:= lsb(4, 0);
}
COMPRESSED format0 { discriminator =:= '0'; // 1 bit field_3; // 4 bits }
COMPRESSED format0 {弁別=：= '0'; // 1ビットfield_3。 // 4ビット}
COMPRESSED format1 { discriminator =:= '1'; // 1 bit field_1 =:= irregular(4); // 4 bits field_3 =:= irregular(24); // 24 bits } }
COMPRESSED形式1 {弁別=：= '1'; // 1ビットFIELD_1 =：=不規則（4）。 // 4ビットfield_3 =：=不規則（24）。 // 24ビット}}
Note the following:
次の点に注意してください。
o "field_1" and "field_3" both have default encoding methods specified for them, which are used in "format0", but are overridden in "format1"; the default encoding method of "field_2" however, is not overridden.
○「FIELD_1」および「field_3」両方「がformat0」で使用されているそれらのために指定されたデフォルトの符号化方式を有するが、「フォーマット1」に上書きされます。しかし「field_2」、のデフォルトのエンコード方式は、上書きされません。
o "field_1" and "field_2" have default encoding methods that compress to zero bits. When these are used in "format0", the field names do not appear in the field list.
○「FIELD_1」および「field_2」ゼロビットに圧縮するデフォルトの符号化方法を有しています。これらは「format0」で使用されている場合は、フィールド名は、フィールドリストには表示されません。
o "field_3" has an encoding method that does not compress to zero bits, so whilst "field_3" has no encoding specified for it in the field list of "format0", it still needs to appear in the field list to specify where it goes in the compressed format.
O「field_3は」「field_3は」「format0」のフィールドリストで指定されていませんエンコーディングを持っていない一方で、それはまだそれがどこに行くかを指定するフィールドリストに表示される必要があるので、ゼロビットに圧縮していない符号化方式があります圧縮形式になっています。
o In the example, all the fields in the uncompressed format have default encoding methods specified for them, but this is not a requirement. Default encodings can be specified for only some or even none of the fields of the uncompressed format.
Oの例では、非圧縮形式のすべてのフィールドには、彼らのために指定されたデフォルトの符号化方法を持っているが、これは必須ではありません。デフォルトのエンコーディングは、非圧縮形式のフィールドの一部だけ、あるいは全くのために指定することができます。
o In the example, all the default encoding methods are on fields from the uncompressed format, but this is not a requirement. Default encoding methods can be specified for control fields.
Oの例では、すべてのデフォルトの符号化方式は、非圧縮形式のフィールドにあるが、これは必要条件ではありません。デフォルトの符号化方式は、制御フィールドに指定することができます。
The library of encoding methods defined by ROHC-FN in Section 4.11 provides a basic and generic set of field encoding methods. When using a ROHC-FN specification in a ROHC profile, some additional encodings specific to the particular protocol header being compressed may, however, be needed, such as methods that infer the value of a field from other values.
4.11項にROHC - FNで定義された符号化方式のライブラリーは、フィールド符号化方式の基本と一般的なセットを提供します。 ROHCプロファイルのROHC-FN仕様を使用する場合、圧縮されている特定のプロトコル・ヘッダに固有のいくつかの追加の符号化は、しかし、そのような他の値からフィールドの値を推定する方法として、必要とされるかもしれません。
These methods are specific to the properties of the protocol being compressed and will thus have to be defined within the profile specification itself. Such profile-specific encoding methods, defined either in ROHC-FN syntax or rigorously in plain text, can be referred to in the ROHC-FN specification of the profile's formats in the same way as any method in the ROHC-FN library.
これらの方法は、圧縮されたプロトコルの性質に特有であり、したがって、プロファイル仕様自体の中で定義されなければなりません。 ROHC-FN構文または厳密プレーンテキストのいずれかで定義されたようなプロファイル固有の符号化方法は、ROHC-FNライブラリ内の任意の方法と同様の方法でプロファイルの形式のROHC-FN仕様で参照することができます。
Encoding methods that are not defined in the formal notation are specified by giving their name, followed by a short description of where they are defined, in double quotes, and a semi-colon.
正式な表記法で定義されていない符号化方式は、自分の名前を与えることによって、指定されたそれらが定義されている場所の短い説明に続いて、二重引用符で、かつセミコロンされています。
For example:
例えば：
inferred_ip_v4_header_checksum "defined in RFCxxxx Section 6.4.1";
「RFCxxxxの6.4.1項で定義された」inferred_ip_v4_header_checksum。
This document describes a formal notation similar to ABNF [RFC4234], and hence is not believed to raise any security issues (note that ABNF has a completely separate purpose to the ROHC formal notation).
この文書では、ABNF [RFC4234]と同様の正式な表記法を説明し、したがって任意のセキュリティ問題は、（ABNFがROHC正式な表記と完全に別個の目的を持っていることに注意）上昇させるとは考えられません。
Richard Price did much of the foundational work on the formal notation. He authored the initial document describing a formal notation on which this document is based.
リチャード価格は、正式な表記法上の基礎作業の多くをしました。彼は、この文書が基づいている正式な表記法を記述した最初の文書を執筆しました。
Kristofer Sandlund contributed to this work by applying new ideas to the ROHC-TCP profile, by providing feedback, and by helping resolve different issues during the entire development of the notation.
クリストファーSandlundは、フィードバックを提供することにより、表記の全体の開発中に解決さまざまな問題を支援することにより、ROHC-TCPプロファイルに新しいアイデアを適用することによって、この作品に貢献しました。
Carsten Bormann provided the translation of the formal notation syntax using ABNF in Appendix A, and also contributed with feedback and reviews to validate the completeness and correctness of the notation.
カルステンボルマンは、付録AでABNFを使用して正式な表記構文の翻訳を提供し、また、表記の正確性、完全性、正確性を検証するためのフィードバックとレビューに貢献しました。
A number of important concepts and ideas have been borrowed from ROHC [RFC3095].
重要な概念やアイデアの数はROHC [RFC3095]から借りてきました。
Thanks to Mark West, Eilert Brinkmann, Alan Ford, and Lars-Erik Jonsson for their contributions, reviews, and feedback that led to significant improvements to the readability, completeness, and overall quality of the notation.
読みやすさ、完全性、および表記法の全体的な品質への大幅な改善につながった彼らの貢献のためのマーク・西、Eilertブリンクマン、アラン・フォード、そしてラース・エリックジョンソンのおかげで、レビュー、およびフィードバック。
Thanks to Stewart Sadler, Caroline Daniels, Alan Finney, and David Findlay for their reviews and comments. Thanks to Rob Hancock and Stephen McCann for their early work on the formal notation. The authors would also like to thank Christian Schmidt, Qian Zhang, Hongbin Liao, and Max Riegel for their comments and valuable input.
彼らのレビューとコメントのためのスチュワート・サドラー、キャロライン・ダニエルズ、アラン・フィニー、デビッドフィンドレーに感謝します。正式な表記上の彼らの初期の作品のためのロブ・ハンコックとスティーブン・マッキャンに感謝します。著者はまた、彼らのコメントと貴重な入力のためのクリスチャン・シュミット、銭張、Hongbinは遼、およびマックスリーゲルに感謝したいと思います。
Additional thanks: this document was reviewed during working group last-call by committed reviewers Mark West, Carsten Bormann, and Joe Touch, as well as by Sally Floyd who provided a review at the request of the Transport Area Directors. Thanks also to Magnus Westerlund for his feedback in preparation for the IESG review.
追加の感謝：この文書は、交通エリアの取締役の要求に応じて見直しを提供し、コミットのレビューマーク・西、カルステンボルマン、そしてジョー・タッチで、だけでなく、サリー・フロイドワーキンググループラストコール中に検討しました。 IESGレビューの準備のための彼のフィードバックのためにもマグヌスウェスターに感謝します。
[C90] ISO/IEC, "ISO/IEC 9899:1990 Information technology -- Programming Language C", ISO 9899:1990, April 1990.
[C90] ISO / IEC、 "ISO / IEC 9899：1990情報技術 - 言語Cプログラミング"、ISO 9899：1990、1990年4月。
[RFC2822] Resnick, P., Ed., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", RFC 2822, April 2001.
[RFC2822]レズニック、P.、エド。、 "アルパインターネットテキストメッセージの形式のための標準的な"、RFC 2822、2001年4月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust Header Compression (ROHC) Framework", RFC 4995, July 2007.
[RFC4995]ジョンソン、L-E。、ペルティエ、G.、及びK. Sandlund、 "ロバストヘッダ圧縮（ROHC）フレームワーク"、RFC 4995、2007年7月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、 ESP、および非圧縮」、RFC 3095、2001年7月。
[RFC791] University of Southern California, "DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", RFC 791, September 1981.
[RFC791]南カリフォルニア大学、 "DARPAインターネットプログラムプロトコル仕様"、RFC 791、1981年9月。
Appendix A. Formal Syntax of ROHC-FN
ROHC - FNの付録A.正式な構文
This section gives a definition of the syntax of ROHC-FN in ABNF [RFC4234], using "fnspec" as the start rule.
このセクションでは、開始規則として「fnspec」を使用して、ABNF [RFC4234]でROHC - FNの構文の定義を与えます。
; overall structure fnspec = S *(constdef S) [globctl S] 1*(methdef S) constdef = constname S "=" S expn S ";" globctl = CONTROL S formbody methdef = id S [parmlist S] "{" S 1*(formatdef S) "}" / id S [parmlist S] STRQ *STRCHAR STRQ S ";" parmlist = "(" S id S *( "," S id S ) ")" formatdef = formhead S formbody formhead = UNCOMPRESSED [ 1*WS id ] / COMPRESSED [ 1*WS id ] / CONTROL / INITIAL / DEFAULT formbody = "{" S *((fielddef/enforcer) S) "}" fielddef = fieldgroup S ["=:=" S encspec S] [lenspec S] ";" fieldgroup = fieldname *( S ":" S fieldname ) fieldname = id encspec = "'" *("0"/"1") "'" / id [ S "(" S expn S *( "," S expn S ) ")"] lenspec = "[" S expn S *("," S expn S) "]" enforcer = ENFORCE S "(" S expn S ")" S ";"
;全体的な構造fnspec = S *（constdefのS）globctlのS] 1 *（methdefのS）constdef = constname形式S "=" S EXPN S ";" globctl = CONTROL S formbody methdef = ID S [PARMLISTのS] "{" S 1 *（S formatdef） "}" / ID S [PARMLISTのS] STRQ * STRCHAR STRQ S ";" PARMLIST = COMPRESSED "（" S IDがS×（ "" S識別S） "）" formatdef = formhead S formbody formhead = UNCOMPRESSED [1 * WS ID] / [1 * WS ID] / CONTROL / INITIAL / DEFAULT formbody = "{" S *（（fielddef /エンフォーサ）S） "}" fielddef = FIELDGROUP S [ "= =" S encspec S] [lenspec S] ";" FIELDGROUP =フィールド名*（S "：" Sのフィールド名）フィールド名= IDのencspec = " '" *（ "0" / "1"） "'" / ID [S "（" SのEXPNのS×（ "、" S EXPN S） "）"] lenspec = "[" S EXPN S *（ "" SのEXPNのS） "" エンフォーサが= S "（" S EXPN Sを強制 "）" S ""
; expressions expn = *(expnb S "||" S) expnb expnb = *(expna S "&&" S) expna expna = *(expn7 S ("=="/"!=") S) expn7 expn7 = *(expn6 S ("<"/"<="/">"/">=") S) expn6 expn6 = *(expn4 S ("+"/"-") S) expn4 expn4 = *(expn3 S ("*"/"/"/"%") S) expn3 expn3 = expn2 [S "^" S expn3] expn2 = ["!" S] expn1 expn1 = expn0 / attref / constname / litval / id expn0 = "(" S expn S ")" / VARIABLE attref = fieldnameref "." attname fieldnameref = fieldname / THIS attname = ( U / C ) ( LENGTH / VALUE ) litval = ["-"] "0b" 1*("0"/"1") / ["-"] "0x" 1*(DIGIT/"a"/"b"/"c"/"d"/"e"/"f") / ["-"] 1*DIGIT / false / true
;式は、（expn7 expn7 = * = *（expnb S "||" S）expnb expnb = *（expna S "&&" S）expna expna = *（expn7 S（ "==" / "！="）S）をEXPN expn6 S（ "<" / "<=" / ">" / "> ="）S）expn6 expn6 = *（expn4 S（ "+" / " - "）S）expn4 expn4 = *（expn3のS（」 * "/" / "/" ％ "）S）expn3 expn3 = expn2 [S "^" S expn3] expn2 = ["！」 S] expn1 expn1 = expn0 / attref / constname形式/ litval / ID expn0 = "（" S EXPN S "）" / VARIABLE attref = fieldnameref "" attname fieldnameref =フィールド名/ THIS attname =（U / C）（長さ/値）litval = [ " - "] "0B" 1 *（ "0" / "1"）/ [ " - "] "0X" 1 * （DIGIT / "" / "B" / "C" / "D" / "E" / "F"）/ " - "] 1 * DIGIT /真/偽
; lexical categories constname = UPCASE *(UPCASE / DIGIT / "_") id = ALPHA *(ALPHA / DIGIT / "_") ALPHA = %x41-5A / %x61-7A UPCASE = %x41-5A DIGIT = %x30-39 COMMENT = "//" *(SP / HTAB / VCHAR) CRLF SP = %x20 HTAB = %x09 VCHAR = %x21-7E CRLF = %x0A / %x0D.0A NL = COMMENT / CRLF WS = SP / HTAB / NL S = *WS STRCHAR = SP / HTAB / %x21 / %x23-7E STRQ = %x22
;字句カテゴリconstname形式= UPCASE *（UPCASE / DIGIT / "_"）ID = ALPHA×（ALPHA / DIGIT / "_"）ALPHA =％x41-5A /％x61-7A UPCASE =％x41-5A DIGIT =％x30- 39 COMMENT = "//" *（SP / HTAB / VCHAR）CRLF SP =％X20 HTAB =％X09 VCHAR =％x21-7E CRLF =％X0A /％x0D.0A NL = COMMENT / CRLF WS = SP / HTAB / NL S = * WS STRCHAR = SP / HTAB /％X21 /％x23-7E STRQ =％X22
; case-sensitive literals C = %d67 COMPRESSED = %d67.79.77.80.82.69.83.83.69.68 CONTROL = %d67.79.78.84.82.79.76 DEFAULT = %d68.69.70.65.85.76.84 ENFORCE = %d69.78.70.79.82.67.69 INITIAL = %d73.78.73.84.73.65.76 LENGTH = %d76.69.78.71.84.72 THIS = %d84.72.73.83 U = %d85 UNCOMPRESSED = %d85.78.67.79.77.80.82.69.83.83.69.68 VALUE = %d86.65.76.85.69 VARIABLE = %d86.65.82.73.65.66.76.69 false = %d102.97.108.115.101 true = %d116.114.117.101
;大文字と小文字を区別リテラルC =％のD67 COMPRESSED =％のd67.79.77.80.82.69.83.83.69.68のCONTROL =％d67.79.78.84.82.79.76 DEFAULT =％d68.69.70.65.85.76.84 ENFORCE =％d69.78.70.79.82 .67.69 INITIAL =％のd73.78.73.84.73.65.76長=％のd76.69.78.71.84.72 THIS =％d84.72.73.83 U =％D85 UNCOMPRESSED =％d85.78.67.79.77.80.82.69.83.83.69.68 VALUE =％のd86.65.76.85.69のVARIABLE =％のd86.65.82.73.65.66.76.69偽=％のd102.97.108.115.101真=％のd116.114.117.101
Appendix B. Bit-level Worked Example
付録B.ビットレベルは、実施例従事します
This section gives a worked example at the bit level, showing how a simple ROHC-FN specification describes the compression of real data from an imaginary protocol header. The example used has been kept fairly simple, whilst still aiming to illustrate some of the intricacies that arise in use of the notation. In particular, fields have been kept short to make it possible to read the binary representation of the headers without too much difficulty.
このセクションでは、単純なROHC-FN仕様は、仮想プロトコル・ヘッダからの実データの圧縮を記述する方法を示し、ビットレベルで働いていた例を示します。使用された例はまだ表記の使用で発生する複雑さのいくつかを説明することを目指しながら、かなりシンプルに保たれています。具体的には、フィールドがあまりにも多くの困難もなく、ヘッダーのバイナリ表現を読むことを可能にするために短くしてきました。
B.1. Example Packet Format
B.1。例パケットフォーマット
Our imaginary header is just 16 bits long, and consists of the following fields:
我々の仮想ヘッダはわずか16ビット長であり、以下のフィールドから構成されています。
So for example 0101000100010000 indicates a header with a version number of one, a type of one, a flow id of one, a sequence number of one, and all flag bits set to zero.
そう例えば0101000100010000ための一つのバージョン番号、一方のタイプ、一方のフローID、一つの配列番号、ゼロに設定されたすべてのフラグビットを有するヘッダを示しています。
Here is an ASCII box notation diagram of the imaginary header:
ここで仮想ヘッダのASCIIボックス表記図です。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|version| type | flow_id |
+---+---+---+---+---+---+---+---+
| sequence_no | flag_bits |
+---+---+---+---+---+---+---+---+
B.2. Initial Encoding
B.2。初期エンコーディング
An initial definition based solely on the above information is as follows:
次のように上記の情報のみに基づいて最初の定義は次のとおりです。
eg_header
{
UNCOMPRESSED {
version_no [ 2 ];
type [ 2 ];
flow_id [ 4 ];
sequence_no [ 4 ];
flag_bits [ 4 ];
}
COMPRESSED initial_definition {
version_no =:= irregular(2);
type =:= irregular(2);
flow_id =:= irregular(4);
sequence_no =:= irregular(4);
flag_bits =:= irregular(4);
}
}
This defines the format nicely, but doesn't actually offer any compression. If we use it to encode the above header, we get:
これがうまくフォーマットを定義しますが、実際には任意の圧縮を提供していません。我々は上記のヘッダをエンコードするためにそれを使用している場合は、我々が得ます：
Uncompressed header: 0101000100010000 Compressed header: 0101000100010000
非圧縮ヘッダ：0101000100010000圧縮ヘッダ：0101000100010000
This is because we have stated that all fields are "irregular" -- i.e., we haven't specified anything about their behaviour.
つまり、私たちは彼らの行動については何も指定していない - 私たちはすべてのフィールドが「不規則」であることを表明しているためです。
Note that since we have only one compressed format and one uncompressed format, it makes no difference whether the encoding methods for each field are specified in the compressed or uncompressed format. It would make no difference at all if we wrote the following instead:
我々は唯一の圧縮形式と一つ非圧縮形式を持っているので、それは各フィールドの符号化方法は、圧縮または非圧縮形式で指定されているかどうか違いはないことに留意されたいです。我々は代わりに以下のことを書いた場合、それはまったく違いはありませんでしょう。
eg_header
{
UNCOMPRESSED {
version_no =:= irregular(2);
type =:= irregular(2);
flow_id =:= irregular(4);
sequence_no =:= irregular(4);
flag_bits =:= irregular(4);
}
COMPRESSED initial_definition {
version_no [ 2 ];
type [ 2 ];
flow_id [ 4 ];
sequence_no [ 4 ];
flag_bits [ 4 ];
}
}
B.3. Basic Compression
B.3。基本的な圧縮
In order to achieve any compression we need to notate more knowledge about the header and its behaviour in a flow. For example, we may know the following facts about the header:
任意の圧縮を達成するために、我々は、ヘッダーとフローのその行動についてのより多くの知識を記譜する必要があります。たとえば、私たちは、ヘッダについて、以下の事実を知っている可能性があります。
1. version number -- indicates which version of the protocol this is: always one for this version of the protocol.
プロトコルのこのバージョンのために常に1： - 1.バージョン番号は、これはあるプロトコルのバージョンを示しています。
5. flag bits -- contains three flags, a, b, and c, each of which may be set or clear, and a reserved flag bit, which is always clear (i.e., zero).
前記フラグビットは、 - 3つのフラグ設定またはクリアすることができるこれらの各々は、B、およびC、常に明らかである予約フラグ・ビット（すなわち、ゼロ）を含みます。
We could notate this knowledge as follows:
次のように私たちは、この知識を記譜できます。
eg_header
{
UNCOMPRESSED {
version_no [ 2 ];
type [ 2 ];
flow_id [ 4 ];
sequence_no [ 4 ];
abc_flag_bits [ 3 ];
reserved_flag [ 1 ];
}
COMPRESSED basic {
version_no =:= uncompressed_value(2, 1) [ 0 ];
type =:= irregular(2) [ 2 ];
flow_id =:= irregular(4) [ 4 ];
sequence_no =:= irregular(4) [ 4 ];
abc_flag_bits =:= irregular(3) [ 3 ];
reserved_flag =:= uncompressed_value(1, 0) [ 0 ];
} }
｝ ｝
Using this simple scheme, we have successfully encoded the fact that one of the fields has a permanently fixed value of one, and therefore contains no useful information. We have also encoded the fact that the final flag bit is always zero, which again contains no useful information. Both of these facts have been notated using the "uncompressed_value" encoding method (see Section 4.11.1).
このシンプルなスキームを使用して、我々は成功したフィールドのいずれかが1の永久固定値を有しているので、有用な情報が含まれていないという事実をコード化しています。我々はまた、最終的なフラグビットが再び有用な情報が含まれていないゼロは、常にあるという事実をコード化しています。 「uncompressed_value」符号化方式を使用して表記されているこれらの事実の両方（セクション4.11.1を参照してください）。
Using this new encoding on the above header, we get:
上記のヘッダにこの新しいエンコーディングを使用して、我々が得ます：
Uncompressed header: 0101000100010000 Compressed header: 0100010001000
非圧縮ヘッダ：0101000100010000圧縮ヘッダ：0100010001000
This reduces the amount of data we need to transmit by roughly 20%. However, this encoding fails to take advantage of relationships between values of a field in one packet and its value in subsequent packets. For example, every header in the following sequence is compressed by the same amount despite the similarities between them:
これは、我々はおよそ20％で送信する必要があるデータの量を減少させます。しかし、このエンコーディングは1つのパケット以降のパケットで、その値のフィールドの値の関係を活用するために失敗しました。例えば、次の順序ですべてのヘッダは、それらの間の類似性にもかかわらず、同じ量だけ圧縮されます。
Uncompressed header: 0101000100010000 Compressed header: 0100010001000
非圧縮ヘッダ：0101000100010000圧縮ヘッダ：0100010001000
Uncompressed header: 0101000101000000 Compressed header: 0100010100000
非圧縮ヘッダ：0101000101000000圧縮ヘッダ：0100010100000
Uncompressed header: 0110000101110000 Compressed header: 1000010111000
非圧縮ヘッダ：0110000101110000圧縮ヘッダ：1000010111000
B.4. Inter-Packet Compression
B.4。インターパケット圧縮
The profile we have defined so far has not compressed the sequence number or flow ID fields at all, since they can take any value. However the value of each of these fields in one header has a very simple relationship to their values in previous headers:
彼らは任意の値を取ることができますので、我々はこれまでに定義したプロファイルは、全くのシーケンス番号やフローIDのフィールドを圧縮していません。しかしつのヘッダでこれらのフィールドのそれぞれの値は、前のヘッダにおけるそれらの値に非常に単純な関係を有します。
o the sequence number is unusual -- it increases by three each time,
シーケンス番号は珍しいはO - これは3つずつ増加し、
o the flow_id stays the same -- it always has the same value that it did in the previous header in the flow,
O flow_idは同じままです - それは常に、それは流れの中で、前のヘッダーでやったのと同じ値を持ち、
o the abc_flag_bits stay the same most of the time -- they usually have the same value that they did in the previous header in the flow.
O abc_flag_bitsは時間の同じほとんどを滞在 - 彼らは通常、彼らは流れの前のヘッダーにいた同じ値を持っています。
An obvious way of notating this is as follows:
次のように記譜本の明白な方法は次のとおりです。
// This obvious encoding will not work (correct encoding below)
eg_header
{
UNCOMPRESSED {
version_no [ 2 ];
type [ 2 ];
flow_id [ 4 ];
sequence_no [ 4 ];
abc_flag_bits [ 3 ];
reserved_flag [ 1 ];
}
COMPRESSED obvious {
version_no =:= uncompressed_value(2, 1);
type =:= irregular(2);
flow_id =:= static;
sequence_no =:= lsb(0, -3);
abc_flag_bits =:= irregular(3);
reserved_flag =:= uncompressed_value(1, 0);
}
}
The dependency on previous packets is notated using the "static" and "lsb" encoding methods (see Section 4.11.4 and Section 4.11.5 respectively). However there are a few problems with the above notation.
前のパケットへの依存は、「静的」および「LSB」の符号化方法を用いて表記されている（それぞれ、セクション4.11.4および4.11.5節を参照のこと）。しかし、上記の表記法にはいくつかの問題があります。
Firstly, and most importantly, the "flow_id" field is notated as "static", which means that it doesn't change from packet to packet. However, the notation does not indicate how to communicate the value of the field initially. There is no point saying "it's the same value as last time" if there has not been a first time where we define what that value is, so that it can be referred back to. The above notation provides no way of communicating that. Similarly with the sequence number -- there needs to be a way of communicating its initial value. In fact, except for the explicit notation indicating their lengths, even the lengths of these two fields would be left undefined. This problem will be solved below, in Appendix B.5.
まず、最も重要なのは、「flow_id」フィールドは、それがパケットごとに変化しないことを意味し、「静的」と表記されます。しかし、表記法は、最初のフィールドの値を通信する方法を示すものではありません。我々は、それが戻って参照することができるように、その値が、あるものを定義する最初の時間がなかった場合は、「それは前回と同じ値だ」と言っても意味がありません。上記表記法はそれを通信する方法を提供していません。同様にシーケンス番号 - 初期値を通信する方法が必要です。実際には、それらの長さを示す明示的な表記を除いて、これら二つのフィールドの偶数長さが未定義のままであろう。この問題は、付録B.5に、以下に解決されます。
Secondly, the sequence number field is communicated very efficiently in zero bits, but it is not at all robust against packet loss. If a packet is lost then there is no way to handle the missing sequence number. When communicating sequence numbers, or any other field encoded with "lsb" encoding, a very important consideration for the notator is how robust against packet loss the compressed protocol should be. This will vary a lot from protocol stack to protocol stack. For the example protocol we'll assume short, low overhead flows and say we need to be robust to the loss of just one packet, which we can achieve with two bits of "lsb" encoding (one bit isn't enough since the sequence number increases by three each time -- see Section 4.11.5). This will be addressed below in Appendix B.5.
次に、シーケンス番号フィールドは、ゼロビットで非常に効率的に伝達されるが、それは、すべてのパケット損失に対するロバストではありません。パケットが失われた場合、欠落しているシーケンス番号を処理する方法はありません。で符号化されたシーケンス番号、または他の任意のフィールドを通信する場合、「LSB」符号化は、notatorにとって非常に重要な考慮事項は、圧縮プロトコルがどうあるべきか堅牢パケット損失に対するあります。これは、プロトコルスタックからプロトコルスタックに多くのことを異なります。例えば、プロトコルのために我々は、我々が「LSB」エンコーディング（1ビットシーケンスから十分ではありませんの2ビットで達成することができた、短い、低オーバーヘッドの流れを仮定し、私たちはただ一つのパケットの損失に対してロバストである必要が言いますよ数は3ずつ増加 - セクション4.11.5を参照のこと）。これは、付録B.5に、以下の対処されます。
Finally, although the flag bits are usually the same as in the previous header in the flow, the profile doesn't make any use of this fact; since they are sometimes not the same as those in the previous header, it is not safe to say that they are always the same, so "static" encoding can't be used exclusively. This problem will be solved later through the use of multiple formats in Appendix B.6.
フラグビットは通常フローの前のヘッダーと同じであるが、最終的に、プロファイルは、この事実のいずれかを利用しません。彼らは時々、前のヘッダと同じではないので、彼らが常に同じであると言うことは安全ではないので、「静的な」エンコーディングが独占的に使用することはできません。この問題は、付録B.6で複数のフォーマットを使用して、後に解決されます。
B.5. Specifying Initial Values
B.5。初期値の指定
To communicate initial values for fields compressed with a context dependent encoding such as "static" or "lsb" we use an "INITIAL" field list. This can help with fields whose start value is fixed and known. For example, if we knew that at the start of the flow that "flow_id" would always be 1 and "sequence_no" would always be 0, we could notate that like this:
そのような「LSB」「静的」または文脈依存の符号化で圧縮されたフィールドの初期値を通信するために、我々は、「INITIAL」フィールドのリストを使用します。これは、その開始値に固定して知られている分野を支援することができます。私たちは知っていた場合例えば、フローの開始時に常に1であることと「sequence_noを」常に0になるでしょう「flow_id」ということを、我々はこのようにそれを記譜できます。
// This encoding will not work either (correct encoding below)
eg_header
{
UNCOMPRESSED {
version_no [ 2 ];
type [ 2 ];
flow_id [ 4 ];
sequence_no [ 4 ];
abc_flag_bits [ 3 ];
reserved_flag [ 1 ];
}
INITIAL {
// set initial values of fields before flow starts
flow_id =:= uncompressed_value(4, 1);
sequence_no =:= uncompressed_value(4, 0);
}
COMPRESSED obvious {
version_no =:= uncompressed_value(2, 1);
type =:= irregular(2);
flow_id =:= static;
sequence_no =:= lsb(2, -3);
abc_flag_bits =:= irregular(3);
reserved_flag =:= uncompressed_value(1, 0);
}
}
｝
However, this use of "INITIAL" is no good since the initial values of both "flow_id" and "sequence_no" vary from flow to flow. "INITIAL" is only applicable where the initial value of a field is fixed, as is often the case with control fields.
「flow_id」と「sequence_noを」の両方の初期値が流れるように、フローごとに異なるので、「INITIAL」のこの使用は良くありません。多くの場合、制御フィールドと同様に「INITIAL」、フィールドの初期値は固定されている場合にのみ適用可能です。
B.6. Multiple Packet Formats
B.6。複数のパケットフォーマット
To communicate initial values for the sequence number and flow ID fields correctly, and to take advantage of the fact that the flag bits are usually the same as in the previous header, we need to depart from the single format encoding we are currently using and instead use multiple formats. Here, we have expressed the encodings for two of the fields in the uncompressed format, since they will always be true for uncompressed headers of that format. The remaining fields, whose encoding method may depend on exactly how the header is being compressed, have their encodings specified in the compressed formats.
シーケンス番号の初期値を通信し、正しくIDフィールドを流れ、及びフラグビットは、通常、前のヘッダーと同じであるという事実を活用するために、我々は、代わりに、我々が現在使用している単一フォーマットのエンコーディングから逸脱とする必要があります複数のフォーマットを使用します。彼らは常にそのフォーマットの非圧縮ヘッダの真となりますので、ここでは、我々は、非圧縮形式のフィールドの2のためのエンコーディングを表明しています。その符号化方式のヘッダが圧縮されている正確にどのように依存し得る残りのフィールドは、その符号化は、圧縮された形式で指定しました。
eg_header
{
UNCOMPRESSED {
version_no =:= uncompressed_value(2, 1) [ 2 ];
type [ 2 ];
flow_id [ 4 ];
sequence_no [ 4 ];
abc_flag_bits [ 3 ];
reserved_flag =:= uncompressed_value(1, 0) [ 1 ];
}
COMPRESSED irregular_format {
discriminator =:= '0' [ 1 ];
version_no [ 0 ];
type =:= irregular(2) [ 2 ];
flow_id =:= irregular(4) [ 4 ];
sequence_no =:= irregular(4) [ 4 ];
abc_flag_bits =:= irregular(3) [ 3 ];
reserved_flag [ 0 ];
}
COMPRESSED compressed_format {
discriminator =:= '1' [ 1 ];
version_no [ 0 ];
type =:= irregular(2) [ 2 ];
flow_id =:= static [ 0 ];
sequence_no =:= lsb(2, -3) [ 2 ];
abc_flag_bits =:= static [ 0 ];
reserved_flag [ 0 ];
}
}
Note that we have added a discriminator field, so that the decompressor can tell which format has been used by the compressor. The format with a "static" flow ID and "lsb" encoded sequence number is now 5 bits long. Note that despite having to add the discriminator field, this format is still the same size as the original incorrect "obvious" format because it takes advantage of the fact that the abc flag bits rarely change.
デコンプレッサは、コンプレッサにより使用されているフォーマット伝えることができるように、我々は弁別フィールドが追加されていることに注意してください。 「静的」フローIDとフォーマットと「LSB」符号化シーケンス番号は、現在5ビット長です。それはABCのフラグビットはほとんど変化していないという事実を利用するため、弁別フィールドを追加することにもかかわらず、このフォーマットはまだ元の間違った「明白な」フォーマットと同じサイズであることに注意してください。
However, the original "basic" format has also grown by one bit due to the addition of the discriminator ("irregular_format"). An important consideration when creating multiple formats is whether each format occurs frequently enough that the average compressed header length is shorter as a result of its usage. For example, if in fact the flag bits always changed between packets, the "compressed_format" encoding could never be used; all we would have achieved is lengthening the "basic" format by one bit.
しかし、元の「基本的な」フォーマットは、弁別器（「irregular_format」）の添加による1ビットによって成長させました。複数のフォーマットを作成する重要な考慮事項は、各フォーマットは、平均圧縮ヘッダの長さがその使用の結果として短くなることが頻繁に発生するかどうかです。実際にフラグビットが常にパケット間で変更された場合、例えば、「compressed_format」エンコーディングが使用されることはありませんでした。すべての私たちは、1ビットで「基本」形式を長くされて達成しているだろう。
Using the above notation, we now get:
上記の表記法を使用して、我々は今、取得します：
Uncompressed header: 0101000100010000 Compressed header: 00100010001000
非圧縮ヘッダ：0101000100010000圧縮ヘッダ：00100010001000
Uncompressed header: 0101000101000000 Compressed header: 10100 ; 00100010100000
非圧縮ヘッダ：0101000101000000圧縮ヘッダ：10100。 00100010100000
Uncompressed header: 0110000101110000 Compressed header: 11011 ; 01000010111000
非圧縮ヘッダ：0110000101110000圧縮ヘッダ：11011。 01000010111000
The first header in the stream is compressed the same way as before, except that it now has the extra 1-bit discriminator at the start (0). When a second header arrives with the same flow ID as the first and its sequence number three higher, it can be compressed in two possible ways: either by using "compressed_format" or, in the same way as previously, by using "irregular_format".
ストリームの最初のヘッダは、それが今開始（0）での余分な1ビットの識別器を有することを除いて、前と同じように圧縮されます。第二のヘッダは第一及びそのシーケンス番号上位3と同じフローIDと到着すると、それは2つの可能な方法で圧縮することができる：「compressed_format」を使用するか、以前と同じように、「irregular_format」を用いてのいずれか。
Note that we show all theoretically possible encodings of a header as defined by the ROHC-FN specification, separated by semi-colons. Either of the above encodings for each header could be produced by a valid implementation, although a good implementation would always aim to pick the encoding that leads to the best compression. A good implementation would also take robustness into account and therefore probably wouldn't assume on the second packet that the decompressor had available the context necessary to decompress the shorter "compressed_format" form.
ROHC-FN仕様によって定義されるように、我々はセミコロンで区切られた、ヘッダの全ての理論的に可能なエンコーディングを示すことに留意されたいです。良い実装は、常に最高の圧縮につながるエンコーディングを選ぶことを目指しますが、各ヘッダーのための上記のエンコーディングのいずれかが、有効な実装によって生成することができます。良い実装も考慮に堅牢性を取るため、おそらく解凍器は短い「compressed_format」形式を解凍するために必要なコンテキストを入手できなかった第2のパケットに想定していないでしょう。
Finally, note that the fields whose encoding methods are specified in the uncompressed format have zero length when compressed. This means their position in the compressed format is not significant. In this case, there is no need to notate them when defining the compressed formats. In the next part of the example we will see that they have been removed from the compressed formats altogether.
最後に、圧縮されたとき、その符号化方法、非圧縮形式で指定されたフィールドがゼロの長さを有していることに注意してください。これは、圧縮された形式で自分の位置は重要ではないことを意味します。この場合、圧縮されたフォーマットを定義するときにそれらを記譜する必要はありません。例の次の部分では、我々は、彼らが完全に圧縮されたフォーマットから削除されていることがわかります。
B.7. Variable Length Discriminators
B.7。可変長ディスクリミネータ
Suppose we do some analysis on flows of our example protocol and discover that whilst it is usual for successive packets to have the same flags, on the occasions when they don't, the packet is almost always a "flags set" packet in which all three of the abc flags are set. To encode the flow more efficiently a format needs to be written to reflect this.
私たちは私たちの例プロトコルの流れにいくつかの分析を行うと、そうでないとき連続するパケットを機会に、同じフラグを持つことが普通である一方で、パケットはすべてここでほとんど常に「設定フラグ」のパケットであることを発見したとABCフラグの3つが設定されています。流れをエンコードするには、より効率的なフォーマットは、これを反映するために書き込む必要があります。
This now gives a total of three formats, which means we need three discriminators to differentiate between them. The obvious solution here is to increase the number of bits in the discriminator from one to two and use discriminators 00, 01, and 10 for example. However we can do slightly better than this.
これは、今、私たちはそれらを区別するために、3つの弁別を必要とすることを意味する、3つのフォーマットの合計を提供します。ここで明らかな溶液を1から2つに弁別器内のビットの数を増加させ、識別器00を使用して、01、例えば10です。しかし、我々はこれよりもわずかに良い行うことができます。
Any uniquely identifiable discriminator will suffice, so we can use 00, 01, and 1. If the discriminator starts with 1, that's the whole thing. If it starts with 0, the decompressor knows it has to check one more bit to determine the kind of format.
それが全部だ、任意の一意に識別可能な弁別は十分ですので、弁別が1で始まる場合、私たちは00、01、および1を使用することができます。それが0で始まる場合、デコンプレッサは、フォーマットの種類を決定するために1つの以上のビットをチェックする必要があります知っています。
Note that care must be taken when using variable length discriminators. For example, it would be erroneous to use 0, 01, and 10 as discriminators since after reading an initial 0, the decompressor would have no way of knowing if the next bit was a second bit of discriminator, or the first bit of the next field in the format. However, 0, 10, and 11 would be correct, as the first bit again indicates whether or not there are further discriminator bits to follow.
可変長弁別を使用する際には注意しなければならないことに注意してください。次のビットは、弁別器の第2ビット、あるいは次の最初のビットであった場合は初期0を読んだ後に、減圧装置が知る方法がないことになるので、例えば、識別器として0、01、および10を使用することは、誤ったであろう形式のフィールド。最初のビットが再び追従するためのさらなる弁別ビットが存在するか否かを示すただし、0、10、及び11は、正しいであろう。
This gives us the following:
これは、私たちに次のようになります：
eg_header
{
UNCOMPRESSED {
version_no =:= uncompressed_value(2, 1) [ 2 ];
type [ 2 ];
flow_id [ 4 ];
sequence_no [ 4 ];
abc_flag_bits [ 3 ];
reserved_flag =:= uncompressed_value(1, 0) [ 1 ];
}
COMPRESSED irregular_format {
discriminator =:= '00' [ 2 ];
type =:= irregular(2) [ 2 ];
flow_id =:= irregular(4) [ 4 ];
sequence_no =:= irregular(4) [ 4 ];
abc_flag_bits =:= irregular(3) [ 3 ];
}
COMPRESSED flags_set {
discriminator =:= '01' [ 2 ];
type =:= irregular(2) [ 2 ];
flow_id =:= static [ 0 ];
sequence_no =:= lsb(2, -3) [ 2 ];
abc_flag_bits =:= uncompressed_value(3, 7) [ 0 ];
}
COMPRESSED flags_static {
discriminator =:= '1' [ 1 ];
type =:= irregular(2) [ 2 ];
flow_id =:= static [ 0 ];
sequence_no =:= lsb(2, -3) [ 2 ];
abc_flag_bits =:= static [ 0 ];
}
}
Here is some example output:
ここではいくつかの例の出力は次のようになります。
Uncompressed header: 0101000100010000 Compressed header: 000100010001000
非圧縮ヘッダ：0101000100010000圧縮ヘッダ：000100010001000
Uncompressed header: 0101000101000000 Compressed header: 10100 ; 000100010100000
非圧縮ヘッダ：0101000101000000圧縮ヘッダ：10100。 000100010100000
Uncompressed header: 0110000101110000 Compressed header: 11011 ; 001000010111000
非圧縮ヘッダ：0110000101110000圧縮ヘッダ：11011。 001000010111000
Uncompressed header: 0111000110101110 Compressed header: 011110 ; 001100011010111
非圧縮ヘッダ：0111000110101110圧縮ヘッダ：011110。 001100011010111
Here we have a very similar sequence to last time, except that there is now an extra message on the end that has the flag bits set. The encoding for the first message in the stream is now one bit larger, the encoding for the next two messages is the same as before, since that format has not grown; thanks to the use of variable length discriminators. Finally, the packet that comes through with all the flag bits set can be encoded in just six bits, only one bit more than the most common format. Without the extra format, this last packet would have to be encoded using the longest format and would have taken up 14 bits.
ここでは、設定されたフラグビットを持って最後に余分なメッセージは、今があることを除いて、最後の時に非常に類似した配列を持っています。ストリーム内の最初のメッセージの符号化は、現在、1ビット大きくなる形式が成長していないので、次の二つのメッセージの符号化は、前と同じです。可変長弁別器の使用のおかげ。最後に、全てのフラグビットセットを介してくるパケットは、最も一般的な形式よりも1ビットのみよりわずか6ビット、に符号化することができます。余分なフォーマットがなければ、この最後のパケットは、最長の形式を使用してエンコードしなければならないであろうと14ビットを取り上げているだろう。
B.8. Default Encoding
B.8。デフォルトエンコーディング
Some of the common encoding methods used so far have been "factored out" into the definition of the uncompressed format, meaning that they don't need to be defined for every compressed format. However, there is still some redundancy in the notation. For a number of fields, the same encoding method is used several times in different formats (though not necessarily in all of them), but the field encoding is redefined explicitly each time. If the encoding for any of these fields changed in the future, then every format that uses that encoding would have to be modified to reflect this change.
これまでに使用される一般的なエンコード方法のいくつかは、彼らがすべての圧縮形式のために定義する必要がないことを意味し、非圧縮形式の定義に「因数分解」されています。ただし、表記の一部の冗長性が依然として存在しています。フィールドの数のために、同じ符号化方法は、（必ずしもそれらのすべてにかかわらず）の異なるフォーマットで複数回使用されるが、フィールド符号化は、明示的に毎回再定義されます。これらのフィールドのいずれかに対する符号化は、将来的に変更された場合、そのエンコーディングを使用するすべての形式は、この変更を反映するように変更しなければならないであろう。
This problem can be avoided by specifying default encoding methods for these fields. Doing so can also lead to a more concisely notated profile:
この問題は、これらのフィールドのデフォルトの符号化方式を指定することで回避することができます。また、より簡潔に表記プロファイルにつながることができそう。
eg_header
{
UNCOMPRESSED {
version_no =:= uncompressed_value(2, 1) [ 2 ];
type [ 2 ];
flow_id [ 4 ];
sequence_no [ 4 ];
abc_flag_bits [ 3 ];
reserved_flag =:= uncompressed_value(1, 0) [ 1 ];
}
DEFAULT {
type =:= irregular(2);
flow_id =:= static;
sequence_no =:= lsb(2, -3); }
sequence_noを=：= LSB（2、-3）。 }
COMPRESSED irregular_format {
discriminator =:= '00' [ 2 ];
type [ 2 ]; // Uses default
flow_id =:= irregular(4) [ 4 ]; // Overrides default
sequence_no =:= irregular(4) [ 4 ]; // Overrides default
abc_flag_bits =:= irregular(3) [ 3 ];
}
COMPRESSED flags_set {
discriminator =:= '01' [ 2 ];
type [ 2 ]; // Uses default
sequence_no [ 2 ]; // Uses default
abc_flag_bits =:= uncompressed_value(3, 7);
}
COMPRESSED flags_static {
discriminator =:= '1' [ 1 ];
type [ 2 ]; // Uses default
sequence_no [ 2 ]; // Uses default
abc_flag_bits =:= static;
}
}
The above profile behaves in exactly the same way as the one notated previously, since it has the same meaning. Note that the purpose behind the different formats becomes clearer with the default encoding methods factored out: all that remains are the encodings that are specific to each format. Note also that default encoding methods that compress down to zero bits have become completely implicit. For example the compressed formats using the default encoding for "flow_id" don't mention it (the default is "static" encoding that compresses to zero bits).
それは同じ意味を持っているので、上記のプロファイルは、以前に表記1とまったく同じように動作します。すべての遺骨が各形式に固有のエンコーディングは以下のとおりです。異なるフォーマットの背後にある目的は、因数分解、デフォルトの符号化方式で明確になることに注意してください。メモはまた、ゼロ・ビットまで圧縮することデフォルトの符号化方法は、完全に暗黙的になってきています。それは言及しない「flow_id」のデフォルトのエンコーディングを使用して、例えば圧縮されたフォーマット（デフォルトはゼロビットに圧縮する「静的」符号化です）。
B.9. Control Fields
B.9。制御フィールド
One inefficiency in the compression scheme we have produced thus far is that it uses two bits to provide the "lsb" encoded sequence number with robustness for the loss of just one packet. In theory, only one bit should be needed. The root of the problem is the unusual sequence number that the protocol uses -- it counts up in increments of three. In order to encode it at maximum efficiency we need to translate this into a field that increments by one each time. We do this using a control field.
我々はこれまでに生産した圧縮方式で一つの非効率性はそれだけで一つのパケットの損失のための堅牢で「LSB」符号化されたシーケンス番号を提供するために2ビットを使用することです。理論的には、1ビットだけが必要とされなければなりません。問題の根本は、プロトコルが使用する異例のシーケンス番号である - それは3単位でカウントアップ。最大効率でそれをコード化するために、我々は1ずつインクリメントフィールドにこれを翻訳する必要があります。私たちは、この制御フィールドを使用してください。
A control field is extra data that is communicated in the compressed format, but which is not a direct encoding of part of the uncompressed header. Control fields can be used to communicate extra information in the compressed format, that allows other fields to be compressed more efficiently.
制御フィールドは、圧縮形式で通信される余分なデータが、非圧縮ヘッダの一部の直接符号化されていません。制御フィールドは、他のフィールドは、より効率的に圧縮することを可能にする圧縮形式で追加情報を通信するために使用することができます。
The control field that we introduce scales the sequence number down by a factor of three. Instead of encoding the original sequence number in the compressed packet, we encode the scaled sequence number, allowing us to have robustness to the loss of one packet by using just one bit of "lsb" encoding:
我々は3倍にシーケンス番号スケールダウン紹介する制御フィールド。代わりに圧縮されたパケットに元のシーケンス番号を符号化する、私たちは私たちが「LSB」エンコーディングのただ1つのビットを使用することにより、1つのパケットの損失に対するロバスト性を持つことができるように、スケールされたシーケンス番号をエンコードします：
eg_header
{
UNCOMPRESSED {
version_no =:= uncompressed_value(2, 1) [ 2 ];
type [ 2 ];
flow_id [ 4 ];
sequence_no [ 4 ];
abc_flag_bits [ 3 ];
reserved_flag =:= uncompressed_value(1, 0) [ 1 ];
}
CONTROL {
// need modulo maths to calculate scaling correctly,
// due to 4 bit wrap around
scaled_seq_no [ 4 ];
ENFORCE(sequence_no.UVALUE
== (scaled_seq_no.UVALUE * 3) % 16);
}
DEFAULT {
type =:= irregular(2);
flow_id =:= static;
scaled_seq_no =:= lsb(1, -1);
}
COMPRESSED irregular_format {
discriminator =:= '00' [ 2 ];
type [ 2 ];
flow_id =:= irregular(4) [ 4 ];
scaled_seq_no =:= irregular(4) [ 4 ]; // Overrides default
abc_flag_bits =:= irregular(3) [ 3 ];
}
COMPRESSED flags_set {
discriminator =:= '01' [ 2 ];
type [ 2 ];
scaled_seq_no [ 1 ]; // Uses default abc_flag_bits =:= uncompressed_value(3, 7); }
scaled_seq_no [1]。 //使用するデフォルトabc_flag_bits =：= uncompressed_value（3、7）; }
COMPRESSED flags_static {
discriminator =:= '1' [ 1 ];
type [ 2 ];
scaled_seq_no [ 1 ]; // Uses default
abc_flag_bits =:= static;
}
}
Normally, the encoding method(s) used to encode a field specifies the length of the field. In the above notation, since there is no encoding method using "sequence_no" directly, its length needs to be defined explicitly using an "ENFORCE" statement. This is done using the abbreviated syntax, both for consistency and also for ease of readability. Note that this is unusual: whereas the majority of field length indications are redundant (and thus optional), this one isn't. If it was removed from the above notation, the length of the "sequence_no" field would be undefined.
通常、符号化方法（複数可）は、フィールドの長さを指定するフィールドを符号化するために使用されます。 「sequence_noを」を使用しない符号化方法がないので、上記の表記では、直接、その長さは「ENFORCE」ステートメントを使用して明示的に定義する必要があります。これは、一貫性のために、また、読みやすさを容易にするために、両方の、省略構文を使用して行われます。これは珍しいことに注意：フィールドの長さの指標の大半は、冗長（従って任意）であるのに対し、これはありません。それは上記の表記法から削除された場合、「sequence_noを」フィールドの長さは不定であろう。
Here is some example output:
ここではいくつかの例の出力は次のようになります。
Uncompressed header: 0101000100010000 Compressed header: 000100011011000
非圧縮ヘッダ：0101000100010000圧縮ヘッダ：000100011011000
Uncompressed header: 0101000101000000 Compressed header: 1010 ; 000100011100000
非圧縮ヘッダ：0101000101000000圧縮ヘッダ：1010。 000100011100000
Uncompressed header: 0110000101110000 Compressed header: 1101 ; 001000011101000
非圧縮ヘッダ：0110000101110000圧縮ヘッダ：1101; 001000011101000
Uncompressed header: 0111000110101110 Compressed header: 01110 ; 001100011110111
非圧縮ヘッダ：0111000110101110圧縮ヘッダ：01110。 001100011110111
In this form, we see that this gives us a saving of a further bit in most packets. Assuming the bulk of a flow is made up of "flags_static" headers, the mean size of the headers in a compressed flow is now just over a quarter of their size in an uncompressed flow.
この形式では、我々は、これは私たちに最もパケットのさらなるビットの節約を与えることがわかります。流れのバルクと仮定すると、「flags_static」のヘッダーで構成され、圧縮されたフローのヘッダの平均サイズは、ちょうど、非圧縮流れの中、その大きさの四分の一の上に今あります。
B.10. Use of "ENFORCE" Statements as Conditionals
B.10。条件文として「ENFORCE」ステートメントの使用
Earlier, we created a new format "flags_set" to handle packets with all three of the flag bits set. As it happens, these three flags are always all set for "type 3" packets, and are never all set for other packet types (a "type 3" packet is one where the type field is set to three).
以前、我々は、設定されたフラグビットの3つのすべてのパケットを処理する新しいフォーマット「flags_set」を作成しました。偶然にも、これらの3つのフラグは常に「タイプ3」のパケットのためのすべての設定され、他のパケットタイプのためのすべてのセット（「タイプ3」のパケットは、タイプフィールドが3に設定されているものである）ことはありません。
This allows extra efficiency in encoding such packets. We know the type is three, so we don't need to encode the type field in the compressed header. The type field was previously encoded as "irregular(2)", which is two bits long. Removing this reduces the size of the "flags_set" format from five bits to three, making it the smallest format in the encoding method definition.
これは、このようなパケットを符号化する際に、余分な効率化を可能にします。私たちは、タイプが3である知っているので、我々は、圧縮ヘッダタイプフィールドをエンコードする必要はありません。タイプフィールドは、以前のように符号化された「不定形（2）」は、2つのビット長です。除去これは、符号化方式の定義における最小フォーマット作り、3〜5ビットから「flags_set」フォーマットのサイズを減少させます。
In order to notate that the "flags_set" format should only be used for "type 3" headers, and the "flags_static" format only when the type isn't three, it is necessary to state these conditions inside each format. This can be done with an "ENFORCE" statement:
ために「flags_set」形式のみ「タイプ3」ヘッダーに使用されるべきであることを記譜、および「flags_static」フォーマットは、タイプがない3である場合にのみ、各フォーマット内のこれらの条件を述べることが必要であることができます。これは、「ENFORCE」文で行うことができます。
eg_header
{
UNCOMPRESSED {
version_no =:= uncompressed_value(2, 1) [ 2 ];
type [ 2 ];
flow_id [ 4 ];
sequence_no [ 4 ];
abc_flag_bits [ 3 ];
reserved_flag =:= uncompressed_value(1, 0) [ 1 ];
}
CONTROL {
// need modulo maths to calculate scaling correctly,
// due to 4 bit wrap around
scaled_seq_no [ 4 ];
ENFORCE(sequence_no.UVALUE
== (scaled_seq_no.UVALUE * 3) % 16);
}
DEFAULT {
type =:= irregular(2);
scaled_seq_no =:= lsb(1, -1);
flow_id =:= static;
}
COMPRESSED irregular_format {
discriminator =:= '00' [ 2 ];
type [ 2 ];
flow_id =:= irregular(4) [ 4 ];
scaled_seq_no =:= irregular(4) [ 4 ];
abc_flag_bits =:= irregular(3) [ 3 ];
}
COMPRESSED flags_set {
ENFORCE(type.UVALUE == 3); // redundant condition
discriminator =:= '01' [ 2 ];
type =:= uncompressed_value(2, 3) [ 0 ];
scaled_seq_no [ 1 ];
abc_flag_bits =:= uncompressed_value(3, 7) [ 0 ];
}
COMPRESSED flags_static {
ENFORCE(type.UVALUE != 3);
discriminator =:= '1' [ 1 ];
type [ 2 ];
scaled_seq_no [ 1 ];
abc_flag_bits =:= static [ 0 ];
}
}
The two "ENFORCE" statements in the last two formats act as "guards". Guards prevent formats from being used under the wrong circumstances. In fact, the "ENFORCE" statement in "flags_set" is redundant. The condition it guards for is already enforced by the new encoding method used for the "type" field. The encoding method "uncompressed_value(2,3)" binds the "UVALUE" attribute to three. This is exactly what the "ENFORCE" statement does, so it can be removed without any change in meaning. The "uncompressed_value" encoding method on the other hand is not redundant. It specifies other bindings on the type field in addition to the one that the "ENFORCE" statement specifies. Therefore it would not be possible to remove the encoding method and leave just the "ENFORCE" statement.
最後の2つの形式で2「ENFORCE」文は「警備員」としての役割を果たす。警備員は、間違った状況下で使用されてからフォーマットを防ぎます。実際には、「flags_set」の「ENFORCE」文は冗長です。それがためにガード条件は、すでに「タイプ」フィールドのために使用される新しい符号化方式によって強制されます。 「（2,3）uncompressed_value」符号化方法は3つに「UVALUE」属性を結合します。これは、意味に変化することなく除去することができるので、文は、ありません「ENFORCE」正確に何です。一方、「uncompressed_value」符号化方法は、冗長ではありません。これは、文の指定を「ENFORCE」1に加えて、タイプフィールド上の他のバインディングを指定します。従って、符号化方式を削除し、ちょうど「ENFORCE」文を残すことが可能ではないでしょう。
Note that a guard is solely preventative. A guard can never force a format to be chosen by the compressor. A format can only be guaranteed to be chosen in a given situation if there are no other formats that can be used instead. This is demonstrated in the example output below. The compressor can still choose the "irregular" format if it wishes:
ガードが単独で予防であることに注意してください。ガードは、コンプレッサによって選ばれるためにフォーマットを強制することはできません。フォーマットのみを代わりに使用することができる他のフォーマットが存在しない場合、所与の状況において選択されることを保証することができます。これは以下の出力例で実証されています。それが希望する場合、コンプレッサは、まだ「不規則な」形式を選択することができます。
Uncompressed header: 0101000100010000 Compressed header: 000100011011000
非圧縮ヘッダ：0101000100010000圧縮ヘッダ：000100011011000
Uncompressed header: 0101000101000000 Compressed header: 1010 ; 000100011100000
非圧縮ヘッダ：0101000101000000圧縮ヘッダ：1010。 000100011100000
Uncompressed header: 0110000101110000 Compressed header: 1101 ; 001000011101000
非圧縮ヘッダ：0110000101110000圧縮ヘッダ：1101; 001000011101000
Uncompressed header: 0111000110101110 Compressed header: 010 ; 001100011110111
非圧縮ヘッダ：0111000110101110圧縮ヘッダ：010。 001100011110111
This saves just two extra bits (a 7% saving) in the example flow.
これは、例えばフローのちょうど2つの余分なビット（7％節約）を保存します。
Authors' Addresses
著者のアドレス
Robert Finking Siemens/Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK
ロバートFinkingシーメンス/ Rokeマナー研究オールド・ソールズベリーレーンロムジー、ハンプシャーSO51 0ZN英国
Phone: +44 (0)1794 833189 EMail: robert.finking@roke.co.uk URI: http://www.roke.co.uk
電話：+44（0）1794 833189 Eメール：robert.finking@roke.co.uk URI：http://www.roke.co.uk
Ghyslain Pelletier Ericsson Box 920 Lulea SE-971 28 Sweden
Ghyslainペルティエエリクソンボックス920 SE-971 28ルレオスウェーデン
Phone: +46 (0) 8 404 29 43 EMail: ghyslain.pelletier@ericsson.com
電話：+46（0）8 404 29 43 Eメール：ghyslain.pelletier@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。