[要約] RFC 4997は、ROHC-FN（RObust Header Compressionの形式的表記）に関する規格であり、ROHCプロトコルのヘッダ圧縮を形式的に表現するためのものです。その目的は、ROHCの実装と相互運用性を向上させることです。
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)
堅牢なヘッダー圧縮の正式な表記（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）The IETF Trust（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フレームワーク内で新しいプロファイルを定義するときに圧縮形式のフィールドエンコーディングを指定する正式な表記である、堅牢なヘッダー圧縮 - 正式な表記（ROHC -FN）を定義します。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.
圧縮形式は、エンコーディングと圧縮するフィールドの間にバインディングを提供するフィールドのリストで構成されています。1つ以上の圧縮形式を組み合わせて、圧縮ヘッダー形式全体を表すことができます。
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].
コンテキストとは、流れの電流（de）圧縮状態に関する情報です。具体的には、特定のフィールドのコンテキストは、単位化されていない場合、または以前のパケットに対応するフィールドの属性から値が生じる可能性のある圧縮アルゴリズムによって定義されるフィールドの属性の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
o 分野
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.
プロトコルヘッダーは、フィールドと呼ばれる一連の連続したビットパターンに分割されます。各フィールドは、圧縮ヘッダーと非圧縮ヘッダーの両方のビットの値と長さを示す属性のコレクションによって定義されます。ヘッダーがフィールドに分割される方法は、プロファイルの定義に固有のものであり、圧縮されるプロトコルヘッダーの仕様によって与えられたものとフィールド分割を同一にする必要はありません。
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プロファイルは、コンプレッサーと減圧剤の動作を制御する一連のルールとともに、一連のフォーマット（ビットを定義する）で構成されています。フォーマットの目的は、ヘッダーを圧縮および解凍する方法を定義することです。この形式は、各非圧縮ヘッダーの1つまたは複数の圧縮バージョンを定義し、同時に逆を定義します。圧縮ヘッダーを元の非圧縮ヘッダーに関連付ける方法。
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.
これらの2つの基本的な要素は、表記の中核にあり、以下に概説します。
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
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つの不特定のデータオブジェクトと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 コンプレッサーの場合、コンテキスト値と非圧縮値の両方が同じ場合、「静的」バインディングが成功します。2つの値が異なる場合、バインディングは失敗します。
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^長さ」で、「長さ」はフィールドの長さ属性です。ただし、これは、圧縮効率を可能にするように設計されたコンプレッサーと減圧器の間で交換されるBITの表現のみです。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）および「施行」ステートメント（セクション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; }
制御{//このブロックは、制御フィールド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」と呼ばれます。「圧縮されていない」というセクションは、非圧縮ヘッダーのフィールドの順序、つまり非圧縮ヘッダー形式を示します。各フィールドのビット数は、正方形の括弧で示されています。この後、別のセクション「コントロール」があり、2つの制御フィールドを定義します。これに続くのは、2つのフィールドのデフォルトエンコードメソッドを定義する「デフォルト」セクションです（以下を参照）。最後に、2つの代替圧縮形式が続き、それぞれが「圧縮」という見出しにあるセクションで定義されています。圧縮形式で発生するフィールドは次のとおりです。
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.
o 圧縮されていない値がないため、圧縮形式の一部として定義される制御フィールド。
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.
これらの各形式の中心は「フィールドリスト」です。これは、形式に含まれるフィールドと、それらのフィールドがその形式に表示される順序を定義します。「デフォルト」および「制御」セクションの場合、フィールド順序は重要ではありません。
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).
フィールドの順序の指定に加えて、フィールドリストには、含まれるフィールドのいずれかまたはすべてのバインディングを指定することもできます。それらのために定義されたバインディングのないフィールドは、「デフォルト」セクションで指定されたデフォルトのバインディングを使用してバインドされています（セクション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).
圧縮形式のフィールドは、非圧縮形式で行うのと同じ名前です。圧縮形式のみで存在するが、非圧縮値を持っているフィールドがある場合、エンコーディング方法の定義の「制御」セクションで宣言する必要があります（セクション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.
非圧縮値のないフィールドは、「圧縮されていない」フィールドリストには表示されず、「コントロール」フィールドリストにも表示される必要はありません。代わりに、それらが使用されている場所に圧縮フィールドリストでのみ宣言されます。
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).
上記の表記の断片は、エンコードメソッド「IPv4_header」を宣言し、定義はオープニングブレースに従います（セクション4.12を参照）。
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:
次のステップは、非圧縮IPv4ヘッダーに含まれるフィールドを指定して、エンコードメソッドが1つ以上の圧縮形式を定義する非圧縮形式を表すことです。これは、次のように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:
「非圧縮_Value」エンコードメソッド（セクション4.11.1で定義）は、圧縮されていない長さと値が固定されているか、式を使用して計算できるフィールドを圧縮できます。非圧縮フィールドをその既知のサイズと値を使用して再構築できるため、圧縮ビットを送信する必要はありません。以下に説明するように、「圧縮されていない」エンコードメソッドを使用して、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":
最後に、3番目のエンコードメソッドは、IPv4ヘッダーの上記で定義された非圧縮形式にのみ固有です。
checksum =:= 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).
「amed_ip_ip_v4_header_checum」エンコードメソッドは、エンコードメソッドのROHC-FNライブラリで定義されていないという点で、他の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).
この例では、「bedred_ip_4_header_checksum」は、ヘッダー値の残りの部分からIPチェックサムを計算する特定のエンコードメソッドです。「非圧縮_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.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つ以上の非圧縮形式を提供することにより、正式な表記を使用して定義されます。これらの形式は、「フィールド」によって互いに関連しており、それぞれが非圧縮ヘッダーおよび/または圧縮ヘッダーの特定の部分を説明しています。形式に加えて、各エンコーディング方法には、制御フィールド、初期値、およびデフォルトのフィールドエンコーディングセクションが含まれる場合があります。フィールドの属性は、そのためのエンコード方法を使用して、および/または形式内の「施行」ステートメント（セクション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):
以下のいずれかを識別子（代替資本を含む）として使用することは違法です。
o "false", "true"
o "真偽"
o "ENFORCE", "THIS", "VARIABLE"
o 「施行」、「これ」、「変数」
o "ULENGTH", "UVALUE" o "CLENGTH", "CVALUE"
o 「ulength」、 "uvalue" o "clength"、 "cvalue"
o "UNCOMPRESSED", "COMPRESSED", "CONTROL", "INITIAL", or "DEFAULT"
o 「圧縮されていない」、「圧縮」、「コントロール」、「初期」、または「デフォルト」
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仕様の基本的な構成要素です。フィールドは、ヘッダーが分割されるユニットです。各フィールドには、圧縮フォームと非圧縮フォームの2つのフォームがあります。どちらの形式も、コンプレッサーと減圧器の間で署名されていないビットの文字列として交換されるビットとして表されます。最初に最も重要なビット。
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.
フィールドの圧縮形式のプロパティは、エンコード方法および/または「施行」ステートメントによって定義されます。これは、そのフィールドの非圧縮形式と圧縮形式の関係を完全に特徴付けます。これは、フィールドの属性間の関係を指定することによって達成されます。
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:
uncompressed attributes of a field:
フィールドの非圧縮属性：
o "UVALUE" and "ULENGTH",
o 「uvalue」と「ulength」、
compressed attributes of a field:
フィールドの圧縮属性：
o "CVALUE" and "CLENGTH".
o 「値」と「長さ」。
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つの長さの属性は、関連するビット文字列のビットの長さを示します。非圧縮フォームの「ulength」、圧縮形式の「clength」。
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値
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)".
フィールドはビット文字列として表されます。ビット文字列は、値属性（ "val"）と長さ属性（ "len"）を使用して計算されます。ビット文字列は、「val％（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）のフィールドの順序は、「圧縮されていない」フィールドリスト（セクション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つの半分である2つの非連続フィールドがある場合があります。
grouping_example
{
UNCOMPRESSED {
minor_seq_num; // 12 bits
other_field; // 8 bits
major_seq_num; // 4 bits
}
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」を使用して、フィールド（つまり、隣接するビットのグループ）を参照することができます（つまり、隣接するビットのグループ）。
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には、グループ化に使用される括弧 "（" and "）"を備えた通常のInfixスタイルの表現スタイルが含まれています。式は、以下のサブセクションで説明されているコンポーネントのいずれかで構成できます。
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の式の決定的なリストは、次のサブセクションで続きます。以下のリストは、ANSI-Cの式とROHC-FNの式の式の違いの例をいくつか示しています。
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」は、yの力に上げられたxを評価します。これには、 *、 /、および％よりも高い優先順位がありますが、unaryよりも低く、左から左の連想です。
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.4で説明されているように）、定義された定数（セクション4.3を参照）、および範囲内の場合（セクション4.12を参照）、メソッドパラメーターをエンコードすることも指します。
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.
式で使用される属性、定数、またはパラメーターのいずれかが定義されていない場合、式の値は未定義です。未定義の式は、定義された値が必要な場合に故障するために使用される環境（たとえば、圧縮形式）を引き起こします。定義された値は、圧縮形式に表示されるフィールドのすべての圧縮属性に対して必要です。非圧縮形式に表示されるフィールドのすべての非圧縮属性には、定義された値は必要ありません。この場合、Unboundフィールド属性に何が起こるかを定義するのは、プロファイル作成者次第です。そのような場合、圧縮プロセスの透明性が失われることに注意する必要があります。つまり、減圧装置が元のヘッダーを再現することはできません。
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;
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」でプレフィックス）、または16進値（「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」は「x」の値を「y」の力に返します。
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).
o Moduloの％。「x％y」は「x "modulo" y "を返します。x -y *（x / y）。
The boolean literals are "false", and "true".
ブールのリテラルは「false」と「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 &&、論理 "および" and "。両方の引数がtrueである場合、trueを返します。それ以外の場合はfalseを返します。
o ||, for logical "or". Returns true if at least one argument is true. Returns false otherwise.
o ||、論理的な "または"の場合。少なくとも1つの引数が真である場合、trueを返します。それ以外の場合はfalseを返します。
o !, for logical "not". Returns true if its argument is false. Returns false otherwise.
o ！、論理的な「NOT」の場合。その議論が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に等しい場合、trueを返します。それ以外の場合は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
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」ステートメントは、エンコード方法といくつかの類似点を共有しています。具体的には、エンコーディング方法はいくつかのフィールド属性に一度に結合しますが、「施行」ステートメントは通常、その1つだけにバインドされます。実際、メソッドをエンコードするすべてのバインディングは、「施行」ステートメントのコレクションで表現できます。以下は、フィールドの「uvalue」属性を5に拘束する「執行」ステートメントの例です。
ENFORCE(field.UVALUE == 5);
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.
「施行」ステートメントは、フィールドリスト内でのみ使用する必要があります（セクション4.12を参照）。それは、与えられた表現を、それが属する形式に真であるように強制しようとします。
An abbreviated form of an "ENFORCE" statement is available for binding length attributes using "[" and "]", see Section 4.10.
「["" "" "" "および" "を使用して、「施行」ステートメントの略語形式は、セクション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.
エンコーディング方法と同様に、「強制」ステートメントは、説明するバインディングが達成可能である場合にのみ、形式で正常に使用できます。上記の「執行」ステートメントの例を含む形式は、フィールドが「非圧縮_Value」エンコードで同じ形式内にバインドされていた場合、5以外の「UValue」を与えた場合、使用できません。
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」ステートメントは、パラメーターとしてブール式を使用します。エンコード方法で指定された可能な形式のリストから特定の形式を選択するために、または上記の例のように式を結合するためだけに、式が真であると主張することができます。したがって、「執行」ステートメントの一般的な形式は次のとおりです。
ENFORCE(<boolean expression>);
There are three possible conditions that the expression may be in:
式がある可能性のある3つの条件があります。
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. ブール式はfalseに評価されます。その場合、「施行」ステートメントを含む形式のローカル範囲は使用できません。
2. The boolean expression evaluates to true, in which case the binding is created and successful.
2. ブールの発現は真のものに評価されます。その場合、結合が作成され成功します。
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つのケースすべてで、未定義の用語は式に拘束されます。一般的に言えば、「施行」ステートメントは、条件1と2の場合のように、割り当てとして使用されるか（上記の条件3）、特定の形式が使用可能かどうかをテストするために使用されます。
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.
「強制」ステートメント（セクション4.9を参照）の最も一般的な用途の1つは、ヘッダー内のフィールドの長さを明示的に定義することです。この目的のために「施行」ステートメントを使用するには、正式な意味がありますが、読みやすいものではありません。したがって、この「施行」の使用のために、略語されたフォームが提供されます。これは、読みやすく、正式な意味を持つ両方です。
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:
この表記に拘束される実際の長さの属性は、「圧縮」、「圧縮されていない」、または「制御」フィールドリストに表示されるかどうかに依存します（セクション4.12.1およびそのサブセクションを参照）。「圧縮」フィールドリストでは、フィールドの「clength」属性がバインドされています。「圧縮されていない」および「制御」フィールドリストでは、フィールドの「ulength」属性がバインドされています。「デフォルト」セクションでは、「執行」ステートメントが省略されていることは許可されていません（セクション4.12.1.5を参照）。したがって、上記の表記は「デフォルト」セクションに表示されません。ただし、上記が「圧縮されていない」または「制御」セクションに表示された場合、次のものと同等です。
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:
通知者が式を使用して定義することを望んでいない、またはできないさまざまな長さを持つフィールドに特別なケースが存在します。キーワード「変数」は、次の場合に使用できます。
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が含まれているプロファイルの表記または英語のテキストのいずれかにあります。正方形の括弧内で、キーワード「変数」は、式に通常表示される他の用語と同様に、式の用語として使用できます。例えば：
field [ 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:
「非圧縮_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:
「非圧縮_Value」エンコーディングの使用法を例示するために、IPv6ヘッダーバージョン番号は、常に値6を持つ4ビットフィールドです。
version =:= uncompressed_value(4, 6);
Here is another example of value encoding, using an expression to calculate the length:
式を使用して長さを計算する値エンコーディングの別の例を次に示します。
padding =:= 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:
このエンコーディング方法の使用可能な1つの使用は、圧縮形式でパディングを定義することです。
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」エンコードを指定するための構文を提供します。エンコードされるバイナリ文字列は、単一の引用符で簡単に示されます。フィールドの「clength」属性は、文字列内のビット数に結合し、その「cValue」属性は文字列によって与えられた値に結合します。例えば：
discriminator =:= '01101';
This has exactly the same meaning as:
これは、次の意味とまったく同じ意味です。
discriminator =:= 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);
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;
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.
最も有意なBITSエンコーディング方法「LSB」は、コンテキストに保存されている値と少量によって値が異なるフィールドを圧縮します。フィールド値の最も重要なビットは、元のフィールド値の代わりに送信されます。
field =:= 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);
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ビットがかかり、コンテキストに保存されているフィールドの値とその上の8191の値よりも8192低い値を通知できます。
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]
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 データのブロックの値は、フィールド（block_data_value）の「uvalue」または「cvalue」属性のいずれかを使用して表されます。と
o the size in octets of the block of data (block_data_length).
o データブロックのオクテットのサイズ（block_data_length）。
That is:
あれは：
field =:= 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);
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
}
COMPRESSED {
field_2 =:= uncompressed_value(12, 9); // 0 bits
field_1 =:= irregular(4); // 4 bits
}
}
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.
上記は、新しいメソッドの識別子である「Compleam_Encoding_Method」から始まります。メソッドの定義は、巻き毛の括弧内の「{"および"}」内に続きます。定義の最初の項目は「圧縮されていない」フィールドリストで、非圧縮形式でフィールドの順序を示します。これに続いて、圧縮形式のフィールドリスト（「圧縮」）が続きます。このリストは、圧縮形式のフィールドの順序を提供し、各フィールドのエンコード方法も提供します。
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.
この例では、両方の形式が各フィールドを1回正確にリストします。ただし、特定のフィールドに複数のバインディングを指定する必要がある場合があります。つまり、フィールドリストに複数回表示されます。この場合、フィールド順序での位置を示すのは、リスト内のフィールドの最初の発生です。その後のフィールドの発生は、フィールド順序情報ではなく、バインディング情報のみを指定します。
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.
非圧縮フィールドリストは、非圧縮形式のフィールドを非圧縮ヘッダーに表示する順に指定する「非圧縮」で定義されます。リスト内の個々の個々の非圧縮フィールドの長さの合計は、エンコードされているフィールドの長さに等しくなければなりません。最後に、圧縮形式が定義されている「圧縮されていない」セクションのフィールドのリストを使用して説明されている非圧縮形式の表現は、常に1つの隣接するビットブロックで構成されています。
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_1」で、「Field_2」が続きます。これは、この方法でエンコードされているフィールドが、「Field_1」と「Field_2」という2つのサブフィールドに分割されることを意味します。したがって、これら2つのフィールドの総非圧縮長さは、エンコードされているフィールドの長さに等しくなります。
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ビットシーケンス番号が含まれているが、セッションが短命になる傾向があるプロトコルがある場合があります。これは、シーケンス数の高いビットがほとんど常に一定であることを意味します。「圧縮されていない」形式は、元の非圧縮フィールドを2つのフィールドに分割することでこれを反映できます。1つのフィールドは、シーケンス番号のほぼゼロの部分を表し、顕著な部分を表す2番目のフィールドです。
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).
「圧縮されていない」フィールドリストは、例の「圧縮」フィールドリストと同じ方法でエンコードメソッドを指定する場合があります。その中で指定されたエンコードメソッドは、その非圧縮形式のパケットがエンコードされているときはいつでも使用されます。特定の非圧縮形式を使用したパケットのエンコードは、すべてのエンコードメソッドと「施行」ステートメントが成功した場合にのみ成功できます（セクション4.9を参照）。
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.
非圧縮形式の合計長さは常に定義する必要があります。非圧縮形式の各フィールドの長さも定義する必要があります。これは、「圧縮されていない」、「圧縮」（以下のセクション4.12.1.2を参照）、「コントロール」（以下のセクション4.12.1.3を参照）、「初期」（以下のセクション4.12.1.4を参照）、および「デフォルトを参照）のバインディングを意味します。「（以下のセクション4.12.1.5を参照）フィールドリストは、それらの間で、非圧縮形式のすべてのフィールドの「ULength」属性を定義する必要があります。そうすることで、非圧縮形式のビットからのビットからのマッピングが明確にマッピングされます。」非圧縮 "フィールドリスト。
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.
「圧縮された」フィールドリストで指定されたフィールドの順序は、「圧縮されていない」フィールドリストに表示される順序を一致させる必要はありません。圧縮された形式でフィールドを再注文して、圧縮されたヘッダーをOctet境界に整列させることが望ましい場合があります。上記の例では、順序は実際には、非圧縮形式でそれの反対です。
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」のエンコードは「非圧縮_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」のようなフィールドは、リスト内の位置が重要ではないため、圧縮形式を変更せずにフィールドリストのどこにでも表示される場合があります。実際、このフィールドのエンコーディング方法が他の場所（たとえば、「圧縮されていない」セクション）で定義されている場合、このフィールドは「圧縮」セクションから完全に省略できます。
compound_encoding_method
{
UNCOMPRESSED {
field_1; // 4 bits
field_2 =:= uncompressed_value(12, 9); // 12 bits
}
COMPRESSED {
field_1 =:= irregular(4); // 4 bits
}
}
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.
各圧縮形式の合計長さは常に定義する必要があります。圧縮形式の各フィールドの長さも定義する必要があります。これは、「圧縮されていない」、「圧縮」、「コントロール」（以下のセクション4.12.1.3を参照）、「初期」（以下のセクション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.
制御フィールドは、「コントロール」フィールドリストを使用して定義されます。制御フィールドリストは、非圧縮形式に表示されないが、圧縮されていない値（具体的にはゼロを超える「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
}
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 fields are initialised by using the appropriate encoding methods and/or by using "ENFORCE" statements. This may be done inside the "CONTROL" field list.
制御フィールドは、適切なエンコーディング方法を使用して、および/または「施行」ステートメントを使用して初期化されます。これは、「コントロール」フィールドリスト内で実行できます。
For example:
例えば：
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);
}
}
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」をエンコードする「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 {
field =:= 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.
これは、「フィールド」の「uvalue」を6に初期化し、「ulength」に「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.
「初期」フィールドリストはコンテキストのみをバインドするために使用されるため、たとえば「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.
デフォルトのバインディングを指定するための構文は、圧縮または非圧縮形式を指定するために使用される構文と類似しています。ただし、フィールドリストのフィールドの順序は、圧縮形式または非圧縮形式のいずれのフィールドの順序に影響しません。これは、フィールド順序が各「圧縮」形式および「圧縮されていない」形式ごとに個別に指定されているためです。
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〜3にデフォルトのバインディングが指定されています。Field_4の「ULength」属性のデフォルトのバインディングも指定されています。
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.
「デフォルト」フィールドリストには、「施行」ステートメントを使用して、個々の属性のデフォルトバインディングを含めることができます。個々の属性のデフォルトのバインディングは、その属性またはそれが属するフィールドに対して与えられたバインディングが与えられていない場合にのみ使用されます。他の場所に、その属性のバインディングバインディングの「施行」ステートメントがある場合、またはそれが属するフィールドをバインドするエンコードメソッドがある場合、属性のデフォルトのバインディングは使用されません。これは、指定されたエンコードメソッドが「デフォルト」セクションに与えられた特定の属性にバインドされていない場合でも適用されます。ただし、フィールドの長さのみにバインドする「施行」ステートメントは、フィールドの長さ以外の何もバインドしていないデフォルトの「施行」ステートメントを除き、デフォルトのバインディングを使用することを可能にします。
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 format3 {
field_4 =:= '1010'; // set ULENGTH to zero
}
COMPRESSED format4 {
ENFORCE(field_4.UVALUE == 12); // use default ULENGTH
}
The fourth format is the only one that uses the default binding for "field_4.ULENGTH".
4番目の形式は、「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.
要約すると、エンコードメソッドのデフォルトのバインディングは、すべてのフィールドの値のバインディングをまだ指定していないフォーマットにのみ使用されます。デフォルトのバインディングを使用する形式の場合、バインディングが指定されていないフィールドと属性のみが「デフォルト」フィールドリストで調べられます。
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);
}
}
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番目の値の2倍に結合しようとします。実際、この「エンコーディング」方法は病的です。フィールドは定義されていないため、実際のエンコードはまったく行われません。「制御」セクションは、「非圧縮」よりもこの目的のために使用する方が適切です。
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を参照）。ただし、複数の形式を定義することにより、2つの代替エンコーディングを提供できます。1つは固定されたままで、もう1つは値が変更されるときです。
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.
圧縮形式が定義されている場合、予約された単語「圧縮」を使用して定義する必要があります。同様に、非圧縮形式は、予約された単語「非圧縮」を使用して定義する必要があります。これらの各キーワードの後、フォーマットに名前が付けられる場合があります。形式に名前が付けられていない場合、形式の名前は空です。
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つの「圧縮」と1つの「圧縮されていない」形式に使用できる空の名前を除き、属するエンコード方法の範囲内で一意でなければなりません。
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を参照」（セクション4.9を参照）を選択できます。属性は成功します。複数の成功した組み合わせがある場合、コンプレッサーは任意の組み合わせを選択できます。それ以外の場合、組み合わせが成功していない場合、エンコードメソッドは「失敗」します。フィールドの「UValue」属性を定義していないため、フォーマットは決して失敗しません。形式は、圧縮形式のフィールドの1つの圧縮属性の1つを定義できない場合、または非圧縮形式の長さを未定義のままにしない場合にのみ失敗します。
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
}
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 format1 {
discriminator =:= '1'; // 1 bit
field_1 =:= irregular(4); // 4 bits
field_3 =:= irregular(24); // 24 bits
}
}
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.
o 「Field_1」と「Field_3」はどちらも、「Format0」で使用されているが、「Format1」でオーバーライドされているデフォルトのエンコードメソッドが指定されています。ただし、「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.
o 「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"にはゼロビットに圧縮されないエンコードメソッドがあるため、「format0」のフィールドリストに「field_3」が指定されているエンコードはありませんが、フィールドリストに表示するには、入力する場所を指定する必要があります。圧縮形式。
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";
vedred_ip_v4_header_checksum "rfcxxxxセクション6.4.1"で定義されています。
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.
Kristofer 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.
Carsten Bormannは、付録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.
Mark West、Eilert Brinkmann、Alan Ford、およびLars-Erik Jonssonの貢献、レビュー、フィードバックに感謝し、表記の読みやすさ、完全性、全体的な品質の大幅な改善につながったことに感謝します。
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.
スチュワート・サドラー、キャロライン・ダニエルズ、アラン・フィニー、デビッド・フィンドレーのレビューとコメントに感謝します。ロブ・ハンコックとスティーブン・マッキャンが正式な表記法の初期の作業に感謝します。著者はまた、Christian Schmidt、Qian Zhang、Hongbin Liao、Max Riegelのコメントと貴重な意見に感謝したいと思います。
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レビューに備えてフィードバックをしてくれたMagnus Westerlundにも感謝します。
[C90] ISO/IEC, "ISO/IEC 9899:1990 Information technology -- Programming Language C", ISO 9899:1990, April 1990.
[RFC2822] Resnick, P., Ed., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", RFC 2822, April 2001.
[RFC2822] Resnick、P.、ed。、「ARPAインターネットテキストメッセージの形式の標準」、RFC 2822、2001年4月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、D.、ed。および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] Jonsson、L-E。、Pelletier、G。、およびK. Sandlund、「The Robust Header Compression（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] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH. Zheng、 "堅牢なヘッダー圧縮（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月。
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 ";"
; 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
; 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
; 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
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仕様が、虚数プロトコルヘッダーからの実際のデータの圧縮をどのように記述しているかを示しています。使用された例はかなり単純に保たれていますが、表記法の使用で生じる複雑さのいくつかを説明することを目指しています。特に、フィールドは、あまり困難なく、ヘッダーのバイナリ表現を読むことができるようにするために不足しています。
Our imaginary header is just 16 bits long, and consists of the following fields:
私たちの想像上のヘッダーは長さがわずか16ビットで、次のフィールドで構成されています。
1. version number -- 2 bits
1. バージョン番号-2ビット
2. type -- 2 bits
2. タイプ-2ビット
3. flow id -- 4 bits
3. フローID -4ビット
4. sequence number -- 4 bits
4. シーケンス番号-4ビット
5. flag bits -- 4 bits
5. フラグビット-4ビット
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は、バージョン番号のヘッダー、1つのタイプ、1つのフローID、1つのシーケンス番号、およびすべてのフラグビットがゼロに設定されたヘッダーを示します。
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 |
+---+---+---+---+---+---+---+---+
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:
圧縮形式は1つだけで、1つの非圧縮形式のみであるため、各フィールドのエンコードメソッドが圧縮形式または非圧縮形式で指定されているかどうかは違いはありません。代わりに以下を書いた場合、それはまったく違いを生みません。
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 ];
}
}
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. バージョン番号 - これが次のプロトコルのバージョンを示します。このバージョンのプロトコル用。
2. type -- may take any value.
2. タイプ - 任意の価値を取ることができます。
3. flow id -- may take any value.
3. フローID-任意の価値を取ることができます。
4. sequence number -- make take any value.
4. シーケンス番号 - 任意の値を取得します。
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).
5. フラグビット - 3つのフラグ、a、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つが永続的に固定された値を持っているため、有用な情報が含まれていないという事実を正常にエンコードしました。また、最終フラグビットが常にゼロであるという事実もエンコードしました。これには、有用な情報が含まれていません。これらの両方の事実は、「非圧縮_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
非圧縮ヘッダー：01100001011110000圧縮ヘッダー：1000010111000
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フィールドをまったく圧縮していません。ただし、1つのヘッダーにあるこれらの各フィールドの値は、以前のヘッダーの値と非常に単純な関係を持っています。
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」フィールドは「静的」として記録されます。つまり、パケットからパケットに変更されません。ただし、表記は、最初にフィールドの価値を伝える方法を示していません。その値を参照できるように、その価値を定義する初めてのことがなかった場合、「前回と同じ値だ」と言う意味はありません。上記の表記は、それを伝える方法を提供しません。同様に、シーケンス番号と同様に、初期値を伝える方法が必要です。実際、長さを示す明示的な表記を除いて、これら2つのフィールドの長さでさえ未定義のままになります。この問題は、付録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」エンコーディングでエンコードされたその他のフィールドを通信する場合、ノーテーターにとって非常に重要な考慮事項は、圧縮プロトコルがパケット損失に対してどれほど堅牢であるかです。これは、プロトコルスタックからプロトコルスタックまで大きく異なります。例のプロトコルでは、短くて低いオーバーヘッドフローを想定し、1つのパケットの損失に堅牢である必要があると言います。数は毎回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の複数の形式を使用することにより、後で解決されます。
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」などのコンテキスト依存エンコードで圧縮されたフィールドの初期値を通信するには、「初期」フィールドリストを使用します。これは、開始値が固定され、既知のフィールドに役立ちます。たとえば、フローの開始時に「flow_id」が常に1であり、「Sequence_no」が常に0になることを知っていた場合、次のように記録できました。
// 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」の両方の初期値がフローによって異なるため、良くありません。「初期」は、フィールドの初期値が固定されている場合にのみ適用されます。これは、制御フィールドの場合の場合と同様です。
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.
ただし、元の「基本的な」形式も、識別子（「不規則な_FORMAT」）の追加により、少し増加しています。複数の形式を作成する際の重要な考慮事項は、各形式が使用された結果として平均圧縮ヘッダー長が短くなるほど頻繁に発生するかどうかです。たとえば、実際にフラグビットが常にパケット間で変更された場合、「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
非圧縮ヘッダー：01100001011110000圧縮ヘッダー：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".
ストリーム内の最初のヘッダーは、以前と同じように圧縮されますが、開始時に追加の1ビットの識別子があることを除いて、現在と同じように圧縮されます。2番目のヘッダーが最初のフローIDと同じフローIDで到着すると、2つの可能な方法で圧縮できます。「Compressed_Format」を使用するか、以前と同じ方法で「不規則な_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.
Semi-Colonsで区切られたROHC-FN仕様で定義されているヘッダーの理論的に可能なすべてのエンコーディングを示していることに注意してください。各ヘッダーの上記のエンコーディングのいずれかは、有効な実装によって生成される可能性がありますが、適切な実装は常に最高の圧縮につながるエンコードを選択することを目的としています。また、優れた実装では堅牢性を考慮しているため、2番目のパケットでは、短い「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.
最後に、非圧縮形式でエンコードメソッドが指定されているフィールドは、圧縮時にゼロの長さであることに注意してください。これは、圧縮形式での位置が重要ではないことを意味します。この場合、圧縮形式を定義するときにそれらを表記する必要はありません。この例の次の部分では、圧縮形式から完全に削除されたことがわかります。
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.
一意に識別可能な識別器は十分であるため、00、01、および1を使用できます。差別器が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.
可変長さの判別器を使用する場合は、注意を払う必要があることに注意してください。たとえば、最初の0を読んだ後、分解器は次のビットが2番目の識別因子であるか、次のビットの最初のビットであるかを知る方法がないため、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
Uncompressed header: 0110000101110000
Compressed header: 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つ少し大きくなり、次の2つのメッセージのエンコードは、その形式が成長していないため、以前と同じです。可変長さの判別器の使用のおかげです。最後に、すべてのフラグビットセットで届くパケットは、わずか6ビットでエンコードできます。これは、最も一般的な形式よりも1つだけです。追加の形式がなければ、この最後のパケットは最長の形式を使用してエンコードする必要があり、14ビットを取り上げていました。
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);
}
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).
上記のプロファイルは、同じ意味を持っているため、前述したものとまったく同じように動作します。異なる形式の背後にある目的は、デフォルトのエンコードメソッドが考慮されていることでより明確になることに注意してください。残っているのは、各形式に固有のエンコーディングだけです。また、ゼロビットに圧縮するデフォルトのエンコードメソッドが完全に暗黙的になっていることに注意してください。たとえば、「flow_id」のデフォルトエンコードを使用した圧縮形式は、それを言及していません（デフォルトはゼロビットに圧縮する「静的」エンコードです）。
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.
これまでに生成された圧縮スキームの1つの非効率性は、2つのビットを使用して「LSB」エンコードされたシーケンス番号を1つのパケットを失うために堅牢性を提供することです。理論的には、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倍に縮小します。圧縮パケットで元のシーケンス番号をエンコードする代わりに、スケーリングされたシーケンス番号をエンコードして、1つの「LSB」エンコードを使用して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);
}
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」を直接使用するエンコードメソッドがないため、その長さは「施行」ステートメントを使用して明示的に定義する必要があります。これは、一貫性と読みやすさを容易にするために、短縮構文を使用して行われます。これは珍しいことであることに注意してください。フィールドの長さの適応症の大部分は冗長（したがってオプション）であるのに対し、これはそうではありません。上記の表記から削除された場合、「sequence_no」フィールドの長さは未定義になります。
Here is some example output:
これが出力の例です。
Uncompressed header: 0101000100010000 Compressed header: 000100011011000
Uncompressed header: 0101000101000000 Compressed header: 1010 ; 000100011100000
非圧縮ヘッダー：0101000101000000圧縮ヘッダー：1010;000100011100000
Uncompressed header: 0110000101110000 Compressed header: 1101 ; 001000011101000
非圧縮ヘッダー：01100001011110000圧縮ヘッダー：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」ヘッダーで構成されていると仮定すると、圧縮フローのヘッダーの平均サイズは、圧縮されていないフローのサイズの4分の1をわずかに超えています。
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ビットの長さです。これを削除すると、「flags_set」形式のサイズが5ビットから3つに縮小され、エンコードメソッド定義の最小形式になります。
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でない場合にのみ使用する必要があることを記録するには、各形式内にこれらの条件を述べる必要があります。これは、「強制」ステートメントで実行できます。
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つの「施行」ステートメントは、「ガード」として機能します。警備員は、間違った状況下でフォーマットが使用されないようにします。実際、「flags_set」の「執行」ステートメントは冗長です。それが訴える条件は、「タイプ」フィールドに使用される新しいエンコード方法によってすでに施行されています。エンコードメソッド「非圧縮_Value（2,3）」は、「uvalue」属性を3に結合します。これはまさに「執行」ステートメントが行うことであるため、意味を変えることなく削除できます。一方、「非圧縮_Value」エンコードメソッドは冗長ではありません。「執行」ステートメントが指定しているものに加えて、タイプフィールドの他のバインディングを指定します。したがって、エンコードメソッドを削除して、「施行」ステートメントのみを残すことはできません。
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
Uncompressed header: 0110000101110000
Compressed header: 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
ロバートフィンキングシーメンス/ロークマナーリサーチオールドソールズベリーレーンロムシー、ハンプシャーSO51 0ZN UK
Phone: +44 (0)1794 833189
EMail: robert.finking@roke.co.uk
URI: http://www.roke.co.uk
Ghyslain Pelletier Ericsson Box 920 Lulea SE-971 28 Sweden
Ghyslain Pelletier Ericsson Box 920 Lulea SE-971 28スウェーデン
Phone: +46 (0) 8 404 29 43
EMail: ghyslain.pelletier@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。