Network Working Group R. Finking
Request for Comments: 4997 Siemens/Roke Manor Research
Category: Standards Track G. Pelletier
Ericsson
July 2007
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）IETF信托基金（2007年）。
Abstract
摘要
This document defines Robust Header Compression - Formal Notation (ROHC-FN), a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework. ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help to simplify future profile development work.
本文档定义了健壮的头压缩-形式表示法（ROHC-FN），这是一种在ROHC框架内定义新概要文件时为压缩格式指定字段编码的形式表示法。ROHC-FN提供了一个编码方法库，这些方法通常用于ROHC概要文件中，因此可以帮助简化未来概要文件的开发工作。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of ROHC-FN . . . . . . . . . . . . . . . . . . . . . 5
3.1. Scope of the Formal Notation . . . . . . . . . . . . . . . 6
3.2. Fundamentals of the Formal Notation . . . . . . . . . . . 7
3.2.1. Fields and Encodings . . . . . . . . . . . . . . . . . 7
3.2.2. Formats and Encoding Methods . . . . . . . . . . . . . 9
3.3. Example Using IPv4 . . . . . . . . . . . . . . . . . . . . 11
4. Normative Definition of ROHC-FN . . . . . . . . . . . . . . . 13
4.1. Structure of a Specification . . . . . . . . . . . . . . . 13
4.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Constant Definitions . . . . . . . . . . . . . . . . . . . 15
4.4. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4.1. Attribute References . . . . . . . . . . . . . . . . . 17
4.4.2. Representation of Field Values . . . . . . . . . . . . 17
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
4.5. Grouping of Fields . . . . . . . . . . . . . . . . . . . . 17
4.6. "THIS" . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.7. Expressions . . . . . . . . . . . . . . . . . . . . . . . 19
4.7.1. Integer Literals . . . . . . . . . . . . . . . . . . . 20
4.7.2. Integer Operators . . . . . . . . . . . . . . . . . . 20
4.7.3. Boolean Literals . . . . . . . . . . . . . . . . . . . 20
4.7.4. Boolean Operators . . . . . . . . . . . . . . . . . . 20
4.7.5. Comparison Operators . . . . . . . . . . . . . . . . . 21
4.8. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.9. "ENFORCE" Statements . . . . . . . . . . . . . . . . . . . 22
4.10. Formal Specification of Field Lengths . . . . . . . . . . 23
4.11. Library of Encoding Methods . . . . . . . . . . . . . . . 24
4.11.1. uncompressed_value . . . . . . . . . . . . . . . . . . 24
4.11.2. compressed_value . . . . . . . . . . . . . . . . . . . 25
4.11.3. irregular . . . . . . . . . . . . . . . . . . . . . . 26
4.11.4. static . . . . . . . . . . . . . . . . . . . . . . . . 27
4.11.5. lsb . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.11.6. crc . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.12. Definition of Encoding Methods . . . . . . . . . . . . . . 29
4.12.1. Structure . . . . . . . . . . . . . . . . . . . . . . 30
4.12.2. Arguments . . . . . . . . . . . . . . . . . . . . . . 37
4.12.3. Multiple Formats . . . . . . . . . . . . . . . . . . . 38
4.13. Profile-Specific Encoding Methods . . . . . . . . . . . . 40
5. Security Considerations . . . . . . . . . . . . . . . . . . . 41
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1. Normative References . . . . . . . . . . . . . . . . . . . 42
8.2. Informative References . . . . . . . . . . . . . . . . . . 42
Appendix A. Formal Syntax of ROHC-FN . . . . . . . . . . . . . . 43
Appendix B. Bit-level Worked Example . . . . . . . . . . . . . . 45
B.1. Example Packet Format . . . . . . . . . . . . . . . . . . 45
B.2. Initial Encoding . . . . . . . . . . . . . . . . . . . . . 46
B.3. Basic Compression . . . . . . . . . . . . . . . . . . . . 47
B.4. Inter-Packet Compression . . . . . . . . . . . . . . . . . 48
B.5. Specifying Initial Values . . . . . . . . . . . . . . . . 50
B.6. Multiple Packet Formats . . . . . . . . . . . . . . . . . 51
B.7. Variable Length Discriminators . . . . . . . . . . . . . . 53
B.8. Default Encoding . . . . . . . . . . . . . . . . . . . . . 55
B.9. Control Fields . . . . . . . . . . . . . . . . . . . . . . 56
B.10. Use of "ENFORCE" Statements as Conditionals . . . . . . . 59
Robust Header Compression - Formal Notation (ROHC-FN) is a formal notation designed to help with the definition of ROHC [RFC4995] header compression profiles. Previous header compression profiles have been so far specified using a combination of English text together with ASCII Box notation. Unfortunately, this was sometimes unclear and ambiguous, revealing the limitations of defining complex structures and encodings for compressed formats this way. The primary objective of the Formal Notation is to provide a more rigorous means to define header formats -- compressed and uncompressed -- as well as the relationships between them. No other formal notation exists that meets these requirements, so ROHC-FN aims to meet them.
鲁棒头压缩-形式表示法（ROHC-FN）是一种形式表示法，旨在帮助定义ROHC[RFC4995]头压缩配置文件。到目前为止，以前的标题压缩配置文件是使用英文文本和ASCII框符号的组合指定的。不幸的是，这有时是不清楚和不明确的，这暴露了以这种方式定义复杂结构和压缩格式编码的局限性。形式表示法的主要目标是提供更严格的方法来定义头格式（压缩和未压缩）以及它们之间的关系。没有其他形式的符号满足这些要求，因此ROHC-FN旨在满足这些要求。
In addition, ROHC-FN offers a library of encoding methods that are often used in ROHC profiles, so that the specification of new profiles using the formal notation can be achieved without having to redefine this library from scratch. Informally, an encoding method defines a two-way mapping between uncompressed data and compressed data.
此外，ROHC-FN还提供了一个编码方法库，这些编码方法通常用于ROHC概要文件中，因此可以实现使用形式表示法的新概要文件的规范，而无需从头定义该库。非正式地说，编码方法定义了未压缩数据和压缩数据之间的双向映射。
o Compressed format
o 压缩格式
A compressed format consists of a list of fields that provides bindings between encodings and the fields it compresses. One or more compressed formats can be combined to represent an entire compressed header format.
压缩格式由字段列表组成，这些字段提供编码与其压缩的字段之间的绑定。可以组合一种或多种压缩格式来表示整个压缩头格式。
o Context
o 上下文
Context is information about the current (de)compression state of the flow. Specifically, a context for a specific field can be either uninitialised, or it can include a set of one or more values for the field's attributes defined by the compression algorithm, where a value may come from the field's attributes corresponding to a previous packet. See also a more generalized definition in Section 2.2 of [RFC4995].
上下文是关于流的当前（反）压缩状态的信息。具体地说，特定字段的上下文可以是未初始化的，或者它可以包括由压缩算法定义的字段属性的一个或多个值的集合，其中值可以来自对应于先前分组的字段属性。另请参见[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配置文件由一组格式（定义要传输的位）以及一组控制压缩器和解压缩器行为的规则组成。这些格式的目的是定义如何压缩和解压缩标题。这些格式定义了每个未压缩头的一个或多个压缩版本，同时定义了相反的内容：如何将压缩头与原始未压缩头关联起来。
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
ROHC-FN旨在帮助规范压缩格式，当根据概要文件定义组合在一起时，使
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配置文件中使用的格式。它提供了一个用于压缩字段的编码方法库，以及一种用于组合这些编码方法以创建适合特定协议栈的压缩格式的机制。
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:
形式符号有两个基本要素：
1. Fields and their encodings, which define the mapping between a header's uncompressed and compressed forms.
1. 字段及其编码，定义头的未压缩表单和压缩表单之间的映射。
2. Encoding methods, which define the way headers are broken down into fields. Encoding methods define lists of uncompressed fields and the lists of compressed fields they map onto.
2. 编码方法，用于定义头分解为字段的方式。编码方法定义未压缩字段的列表以及它们映射到的压缩字段的列表。
These two fundamental elements are at the core of the notation and are outlined below.
这两个基本元素是符号的核心，概述如下。
Headers are made up of fields. For example, version number, header length, and sequence number are all fields used in real protocols.
标题由字段组成。例如，版本号、头长度和序列号都是实际协议中使用的字段。
Fields have attributes. Attributes describe various things about the field. For example:
字段具有属性。属性描述有关字段的各种内容。例如：
field.ULENGTH
场长
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;
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.
双向匹配是一种二进制操作，它试图使操作数（即压缩属性和未压缩属性）匹配。这在逻辑上类似于统一过程。操作数表示一个未指定的数据对象和一个指定的对象。可以从任一操作数匹配值。
During compression, the uncompressed attributes of the field are already defined. The given encoding matches the compressed attributes against them. During decompression, the compressed attributes of the field are already defined, so the uncompressed attributes are matched to the compressed attributes using the given encoding method. Thus, both compression and decompression are defined by a single field definition.
在压缩期间，已定义字段的未压缩属性。给定的编码将压缩属性与它们匹配。在解压缩过程中，字段的压缩属性已经定义，因此使用给定的编码方法将未压缩属性与压缩属性匹配。因此，压缩和解压缩都由单个字段定义。
Therefore, an encoding method (including any parameters specified) creates a reversible binding between the attributes of a field. At the compressor, a format can be used if a set of bindings that is successful for all the attributes in all its fields can be found. At the decompressor, the operation is reversed using the same bindings and the attributes in each field are filled according to the specified bindings; decoding fails if the binding for an attribute fails.
因此，编码方法（包括指定的任何参数）在字段的属性之间创建可逆绑定。在压缩器中，如果可以找到一组对其所有字段中的所有属性都成功的绑定，则可以使用一种格式。在解压缩程序中，使用相同的绑定反转操作，并根据指定的绑定填充每个字段中的属性；如果属性绑定失败，则解码失败。
For example, the "static" encoding method creates a binding between the attribute corresponding to the uncompressed value of the field and the corresponding value of the field in the context.
例如，“静态”编码方法在字段的未压缩值对应的属性和上下文中字段的对应值之间创建绑定。
o For the compressor, the "static" binding is successful when both the context value and the uncompressed value are the same. If the two values differ then the binding fails.
o 对于压缩器，“静态”绑定在上下文值和未压缩值相同时成功。如果两个值不同，则绑定失败。
o For the decompressor, the "static" binding succeeds only if a valid context entry containing the value of the uncompressed field exists. Otherwise, the binding will fail.
o 对于解压缩程序，“静态”绑定仅在包含未压缩字段值的有效上下文条目存在时成功。否则，绑定将失败。
Both the compressed and uncompressed forms of each field are represented as a string of bits; the most significant bit first, of the length specified by the length attribute. The bit string is the binary representation of the value attribute of the field, modulo "2^length", where "length" is the length attribute of the field. However, this is only the representation of the bits exchanged between the compressor and the decompressor, designed to allow
每个字段的压缩和未压缩形式都表示为一个位串；由length属性指定的长度的最高有效位。位字符串是字段值属性的二进制表示形式，模为“2^length”，其中“length”是字段的长度属性。然而，这只是压缩机和减压器之间交换的位的表示，旨在允许
maximum compression efficiency. The FN itself uses the full range of integers. See Section 4.4.2 for further details.
最大压缩效率。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 ];
}
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;
}
CONTROL { // This block defines control fields
ctrl_field_1;
ctrl_field_2;
}
DEFAULT { // This block defines default encodings
// for specified fields
ctrl_field_2 =:= encoding_method_2;
field_1 =:= encoding_method_1;
}
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_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
}
}
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:
在上面的示例中，定义的编码方法称为“新编码方法”。标题为“UNCOMPRESSED”的部分表示未压缩标头中字段的顺序，即未压缩标头格式。每个字段中的位数用方括号表示。在这之后是另一节“控制”，它定义了两个控制字段。下面是“默认”部分，它定义了两个字段的默认编码方法（见下文）。最后，下面是两种可选的压缩格式，每种格式在标题为“compressed”的部分中定义。以压缩格式出现的字段有：
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_字段_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\u头”。有关编码方法定义的更多详细信息，请参见第4.12节。这表示如下：
ipv4_header {
ipv4\u头{
The fragment of notation above declares the encoding method "ipv4_header", the definition follows the opening brace (see Section 4.12).
上面的符号片段声明了编码方法“ipv4_头”，定义遵循大括号开头（参见第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_头”的本地定义。这种范围界定机制有助于澄清哪些字段属于哪些格式；当压缩具有多个标头的复杂协议堆栈时，它也很有用，通常在多个标头中出现相同的字段名（参见第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标头中包含的字段，以表示编码方法将为其定义一个或多个压缩格式的未压缩格式。这是使用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 ];
}
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头的最佳方法，因此本示例仅使用三种编码方法。
The "uncompressed_value" encoding method (defined in Section 4.11.1) can compress any field whose uncompressed length and value are fixed, or can be calculated using an expression. No compressed bits need to be sent because the uncompressed field can be reconstructed using its known size and value. The "uncompressed_value" encoding method is used to compress five fields in the IPv4 header, as described below:
“未压缩_值”编码方法（定义见第4.11.1节）可以压缩未压缩长度和值固定的任何字段，或者可以使用表达式计算。无需发送压缩位，因为未压缩字段可以使用其已知大小和值进行重构。“uncompressed_value”编码方法用于压缩IPv4标头中的五个字段，如下所述：
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);
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.
第一个参数以位表示未压缩字段的长度，第二个参数给出其整数值。
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);
src_addr =:= irregular(32);
dest_addr =:= irregular(32);
length =:= irregular(16);
id =:= irregular(16);
ttl =:= irregular(8);
protocol =:= irregular(8);
dscp =:= irregular(6);
ecn =:= irregular(2);
dont_frag =:= irregular(1);
Finally, the third encoding method is specific only to the uncompressed format defined above for the IPv4 header, "inferred_ip_v4_header_checksum":
最后，第三种编码方法仅适用于上面为IPv4标头定义的未压缩格式，“推断的\u ip\u v4\u标头\u校验和”：
checksum =:= inferred_ip_v4_header_checksum [ 0 ];
}
}
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).
“推断的_ip_v4_头_校验和”编码方法不同于其他两种编码方法，因为它未在ROHC-FN编码方法库中定义。其定义可以通过使用正式符号作为概要定义本身的一部分（见第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
在我们的示例中，“推断的\u ip\u v4\u报头\u校验和”是一种特定的编码方法，它根据其余报头值计算ip校验和。与“uncompressed_value”编码方法一样，不需要发送压缩位，因为字段值可以在解压器处重建。这通过在方括号中为压缩格式的校验和字段指定长度0来明确表示。同样，这种表示法是可选的，因为编码方法本身将被定义为发送零压缩
bits, however it is useful to the reader to include such notation (see Section 4.10 for details on this part of the notation).
但是，对于读者来说，包含这种符号是有用的（关于符号这一部分的详细信息，请参见第4.10节）。
Finally the definition of the format is terminated with a closing brace. At this point, the above example has defined a compressed format that can be used to represent the entire compressed IPv4 header, and provides enough information to allow an implementation to construct the compressed format from an uncompressed format (compression) and vice versa (decompression).
最后，格式的定义以右大括号终止。此时，上面的示例定义了可用于表示整个压缩IPv4报头的压缩格式，并提供了足够的信息以允许实现从未压缩格式（压缩）构造压缩格式，反之亦然（解压缩）。
This section gives the normative definition of ROHC-FN. ROHC-FN is a declarative language that is referentially transparent, with no side effects. This means that whenever an expression is evaluated, there are no other effects from obtaining the value of the expression; the same expression is thus guaranteed to have the same value wherever it appears in the notation, and it can always be interchanged with its value in any of the formats it appears in (subject to the scope rules of identifiers of Section 4.2).
本节给出了ROHC-FN的规范性定义。ROHC-FN是一种声明性语言，引用透明，没有副作用。这意味着，无论何时对表达式求值，获取表达式的值都不会产生其他影响；因此，保证同一表达式在符号中出现的任何地方都具有相同的值，并且始终可以以其出现的任何格式与其值交换（根据第4.2节标识符的范围规则）。
The formal notation describes the structure of the formats and the relationships between their uncompressed and compressed forms, rather than describing how compression and decompression is performed.
形式表示法描述格式的结构及其未压缩和压缩形式之间的关系，而不是描述如何执行压缩和解压缩。
In various places within this section, text inside angle brackets has been used as a descriptive placeholder. The use of angle brackets in this way is solely for the benefit of the reader of this document. Neither the angle brackets, nor their contents form a part of the notation.
在本节的各个地方，尖括号内的文本被用作描述性占位符。以这种方式使用尖括号完全是为了本文件读者的利益。尖括号及其内容均不构成符号的一部分。
The specification of the compressed formats of a ROHC profile using ROHC-FN is called a ROHC-FN specification. ROHC-FN specifications are case sensitive and are written in the 7-bit ASCII character set (as defined in [RFC2822]) and consist of a sequence of zero or more constant definitions (Section 4.3), an optional global control field list (Section 4.12.1.3) and one or more encoding method definitions (Section 4.12).
使用ROHC-FN的ROHC配置文件的压缩格式规范称为ROHC-FN规范。ROHC-FN规范区分大小写，以7位ASCII字符集（如[RFC2822]中所定义）编写，由零或多个常量定义序列（第4.3节）、可选全局控制字段列表（第4.12.1.3节）和一个或多个编码方法定义（第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.
未压缩和/或压缩的标头。除了格式之外，每个编码方法还可以包含控制字段、初始值和默认字段编码部分。字段的属性通过使用其编码方法和/或在格式中使用“强制”语句（第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.
在同一范围内，两个或多个标识符仅在资本化方面不同是非法的。
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 “ULENGTH”、“UVALUE”
o "CLENGTH", "CVALUE"
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).
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).translate error, please retry
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;
某些_常数=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
常量由“=”运算符右侧的表达式（见第4.7节）定义。表达式必须产生一个常量值。也就是说，表达式必须是其术语为
all either constants or literals and must not vary depending on the header being compressed.
所有常量或文字，并且不得因要压缩的标头而异。
Constants have a global scope. Constants must be defined at the top level, outside any encoding method definition. Constants are entirely equivalent to the value they refer to, and are completely interchangeable with that value. Unlike field attributes, which may change from packet to packet, constants have the same value for all packets.
常量具有全局作用域。常量必须在顶层定义，在任何编码方法定义之外。常数完全等同于它们所引用的值，并且可以与该值完全互换。与字段属性不同，字段属性可能因数据包而异，常量对于所有数据包具有相同的值。
Fields are the basic building blocks of a ROHC-FN specification. Fields are the units into which headers are divided. Each field may have two forms: a compressed form and an uncompressed form. Both forms are represented as bits exchanged between the compressor and the decompressor in the same way, as an unsigned string of bits; the most significant bit first.
字段是ROHC-FN规范的基本构建块。字段是头被划分成的单位。每个字段可以有两种形式：压缩形式和未压缩形式。这两种形式都表示为在压缩器和解压缩器之间以相同方式交换的位，表示为无符号位串；首先是最高有效位。
The properties of the compressed form of a field are defined by an encoding method and/or "ENFORCE" statements. This entirely characterises the relationship between the uncompressed and compressed forms of that field. This is achieved by specifying the relationships between the field's attributes.
字段压缩形式的属性由编码方法和/或“强制”语句定义。这完全体现了该字段的未压缩和压缩形式之间的关系。这是通过指定字段属性之间的关系来实现的。
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 “CVALUE”和“CLENGTH”。
The two value attributes contain the respective numerical values of the field, i.e., "UVALUE" gives the numerical value of the uncompressed form of the field, and the attribute "CVALUE" gives the numerical value of the compressed form of the field. The numerical values are derived by interpreting the bit-string representations of the field as bit strings; the most significant bit first.
这两个值属性分别包含字段的数值，即，“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.
两个长度属性表示相关位字符串的长度（以位为单位）；“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.
属性是未定义的，除非它们绑定到一个值，在这种情况下，它们将被定义。如果为一个字段属性提供了两个冲突的绑定，那么这些绑定将与定义这些绑定的（组合）格式一起失败。
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”，在二进制中等于255111111。
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:
通过给出要分组在一起的字段的冒号分隔列表来表示组。例如，未压缩标头中可能有两个非连续字段，这两个字段实际上是单个序列号的两部分：
grouping_example
{
UNCOMPRESSED {
minor_seq_num; // 12 bits
other_field; // 8 bits
major_seq_num; // 4 bits
}
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);
}
}
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
这是我的名字
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”）”。表达式可以由以下小节中描述的任何组件组成。
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”的计算结果是x提升到y的幂。它的优先级高于*、/和%，但低于一元-并且是从右向左关联的。
o There is no comma operator.
o 没有逗号运算符。
o There are no "modify" operators (no assignment operators and no increment or decrement).
o 没有“修改”运算符（没有赋值运算符，也没有增量或减量）。
o There are no bitwise operators.
o 没有按位运算符。
Expressions may refer to any of the attributes of a field (as described in Section 4.4), to any defined constant (see Section 4.3) and also to encoding method parameters, if any are in scope (see Section 4.12).
表达式可以引用字段的任何属性（如第4.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.
如果表达式中使用的任何属性、常量或参数未定义，则表达式的值未定义。如果需要定义的值，未定义的表达式会导致使用它们的环境（例如，压缩格式）失败。以压缩格式显示的字段的所有压缩属性都需要定义的值。以未压缩格式显示的字段的所有未压缩属性不需要定义的值。在这种情况下，由概要文件创建者定义未绑定字段属性的情况。应注意的是，在这种情况下，压缩过程的透明度将丢失；i、 例如，解压器将无法复制原始标头。
Expressions cannot be used as encoding methods directly because they do not completely characterise a field. Expressions only specify a single value whereas a field is made up of several values: its attributes. For example, the following is illegal:
表达式不能直接用作编码方法，因为它们不能完全表示字段的特征。表达式只指定一个值，而字段由多个值组成：其属性。例如，以下行为是非法的：
tcp_list_length =:= (data_offset + 20) / 4;
tcp_list_length =:= (data_offset + 20) / 4;
There is only enough information here to define a single attribute of "tcp_list_length". Although this makes no sense formally, this could intuitively be read as defining the "UVALUE" attribute. However, that would still leave the length of the uncompressed field undefined at the decompressor. Such usage is therefore prohibited.
这里只有足够的信息来定义“tcp_列表_长度”的单个属性。虽然这在形式上没有意义，但可以直观地理解为定义了“UVALUE”属性。但是，这仍然会使解压缩程序未定义未压缩字段的长度。因此，禁止此类使用。
Integers can be expressed as decimal values, binary values (prefixed by "0b"), or hexadecimal values (prefixed by "0x"). Negative integers are prefixed by a "-" sign. For example "10", "0b1010", and "-0x0a" are all valid integer literals, having the values 10, 10, and -10 respectively.
整数可以表示为十进制值、二进制值（前缀为“0b”）或十六进制值（前缀为“0x”）。负整数的前缀是“-”号。例如，“10”、“0b1010”和“-0x0a”都是有效的整数文本，分别具有值10、10和-10。
The following "integer" operators are available, which take integer arguments and return an integer result:
以下“整数”运算符可用，它们接受整数参数并返回整数结果：
o ^, for exponentiation. "x ^ y" returns the value of "x" to the power of "y".
o ^，表示求幂。“x^y”将“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 %对于模。“x%y”返回模为“y”的“x”；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 ||，表示逻辑“或”。如果至少有一个参数为true，则返回true。否则返回false。
o !, for logical "not". Returns true if its argument is false. Returns false otherwise.
o !, 逻辑上的“不”。如果其参数为false，则返回true。否则返回false。
The following "comparison" operators are available, which take integer arguments and return a boolean result:
以下“比较”运算符可用，它们接受整数参数并返回布尔结果：
o ==, !=, for equality and its negative. "x == y" returns true if x is equal to y. Returns false otherwise. "x != y" returns true if x is not equal to y. Returns false otherwise.
o ==, !=, 对于平等及其负面影响。如果x等于y，“x==y”返回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
//-----------------------------------------------------------------
//-----------------------------------------------------------------
// 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
// 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”语句提供了一种向格式添加谓词的方法，所有这些谓词都必须满足，格式才能成功。“强制”语句与编码方法有一些相似之处。具体来说，编码方法一次绑定多个字段属性，而“强制”语句通常只绑定其中一个。事实上，编码方法创建的所有绑定都可以用一组“强制”语句表示。下面是一个示例“强制”语句，它将字段的“UVALUE”属性绑定到5。
ENFORCE(field.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节）。它试图强制给定的表达式对于它所属的格式为true。
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.
与编码方法一样，“强制”语句只有在其所描述的绑定可以实现的情况下才能成功地在格式中使用。如果包含上述示例“强制”语句的格式也使用“未压缩的_值”编码绑定在同一格式中，则该格式将不可用，该编码为“UVALUE”，而不是5。
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:
“强制”语句将布尔表达式作为参数。它可用于断言表达式为真，以便从编码方法中指定的可能格式列表中选择特定格式（参见第4.12节），或仅绑定上面示例中的表达式。因此，“强制执行”声明的一般形式为：
ENFORCE(<boolean expression>);
ENFORCE(<boolean expression>);
There are three possible conditions that the expression may be in:
表达式有三种可能的条件：
1. The boolean expression evaluates to false, in which case the local scope of the format that contains the "ENFORCE" statement cannot be used.
1. 布尔表达式的计算结果为false，在这种情况下，无法使用包含“强制”语句的格式的局部范围。
2. The boolean expression evaluates to true, in which case the binding is created and successful.
2. 布尔表达式的计算结果为true，在这种情况下，绑定被创建并成功。
3. The value of the boolean expression is undefined. In this case, the binding is also created and successful.
3. 布尔表达式的值未定义。在这种情况下，绑定也会创建并成功。
In all three cases, any undefined term becomes bound by the expression. Generally speaking, an "ENFORCE" statement is either being used as an assignment (condition 3 above) or being used to test if a particular format is usable, as is the case with conditions 1 and 2.
在这三种情况下，任何未定义的术语都会受到表达式的约束。一般来说，“强制”语句要么用作赋值（上面的条件3），要么用于测试特定格式是否可用，就像条件1和2一样。
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节）是显式定义标题中字段的长度。为此目的使用“强制”语句具有正式意义，但并不容易阅读。因此，为“ENFORCE”的这种用法提供了一种缩写形式，它既易于阅读，又具有正式意义。
An expression defining the length of a field can be specified in square brackets after the appearance of that field in a format. If the field can take several alternative lengths, then the expressions defining those lengths can be enumerated as a comma separated list within the square brackets. For example:
定义字段长度的表达式可以在该字段以某种格式出现后的方括号中指定。如果字段可以采用多个可选长度，则定义这些长度的表达式可以在方括号内以逗号分隔的列表形式枚举。例如：
field_1 [ 4 ];
field_2 [ a+b, 2 ];
field_3 =:= lsb(16, 16) [ 26 ];
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节及其小节）。在“压缩”字段列表中，字段的“长度”属性被绑定。在“未压缩”和“控制”字段列表中，字段的“ULENGHT”属性被绑定。“默认”章节中不允许使用缩写的“强制”语句（见第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);
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”可用于以下情况：
variable_length_field [ VARIABLE ];
变量_长度_字段[变量]；
Formally, this provides no restrictions on the field length, but maps onto any positive integer or to a value of zero. It will therefore be necessary to define the length of the field elsewhere (see the final paragraphs of Section 4.12.1.1 and Section 4.12.1.2). This may either be in the notation or in the English text of the profile within which the FN is contained. Within the square brackets, the keyword "VARIABLE" may be used as a term in an expression, just like any other term that normally appears in an expression. For example:
形式上，这对字段长度没有限制，但映射到任何正整数或零值。因此，有必要在其他地方定义字段的长度（见第4.12.1.1节和第4.12.1.2节的最后段落）。这可以是包含FN的概要文件的符号或英文文本。在方括号内，关键字“VARIABLE”可以用作表达式中的一个术语，就像表达式中通常出现的任何其他术语一样。例如：
field [ 8 * (5 + VARIABLE) ];
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:
“uncompressed_value”编码方法用于对头字段进行编码，可使用数学表达式（包括常量值）为其定义未压缩值。此编码方法定义如下：
uncompressed_value(len, val) {
UNCOMPRESSED {
field;
ENFORCE(field.ULENGTH == len);
ENFORCE(field.UVALUE == val);
}
COMPRESSED {
field;
ENFORCE(field.CLENGTH == 0);
}
}
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:
为了举例说明“未压缩_值”编码的用法，IPv6标头版本号是一个4位字段，其值始终为6：
version =:= uncompressed_value(4, 6);
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);
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(len, val) {
UNCOMPRESSED {
field;
ENFORCE(field.ULENGTH == 0);
}
COMPRESSED {
field;
ENFORCE(field.CLENGTH == len);
ENFORCE(field.CVALUE == val);
}
}
compressed_value(len, val) {
UNCOMPRESSED {
field;
ENFORCE(field.ULENGTH == 0);
}
COMPRESSED {
field;
ENFORCE(field.CLENGTH == len);
ENFORCE(field.CVALUE == val);
}
}
One possible use of this encoding method is to define padding in a compressed format:
此编码方法的一个可能用途是以压缩格式定义填充：
pad_to_octet_boundary =:= compressed_value(3, 0);
pad_to_octet_boundary =:= compressed_value(3, 0);
A more common use is to define a discriminator field to make it possible to differentiate between different compressed formats within an encoding method (see Section 4.12). For convenience, the notation provides syntax for specifying "compressed_value" encoding in the form of a binary string. The binary string to be encoded is simply given in single quotes; the "CLENGTH" attribute of the field binds with the number of bits in the string, while its "CVALUE" attribute binds with the value given by the string. For example:
更常见的用途是定义一个鉴别器字段，以便能够在编码方法中区分不同的压缩格式（参见第4.12节）。为方便起见，该符号提供了以二进制字符串形式指定“压缩值”编码的语法。要编码的二进制字符串仅用单引号表示；字段的“CLENGTH”属性与字符串中的位数绑定，而其“CVALUE”属性与字符串给定的值绑定。例如：
discriminator =:= '01101';
discriminator =:= '01101';
This has exactly the same meaning as:
这与以下含义完全相同：
discriminator =:= compressed_value(5, 13);
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);
}
}
irregular(len) {
UNCOMPRESSED {
field;
ENFORCE(field.ULENGTH == len);
}
COMPRESSED {
field;
ENFORCE(field.CLENGTH == len);
ENFORCE(field.CVALUE == field.UVALUE);
}
}
For example, the checksum field of the TCP header is a 16-bit field that does not follow any predictable pattern from one header to another (and so it cannot be compressed):
例如，TCP报头的校验和字段是一个16位字段，不遵循从一个报头到另一个报头的任何可预测模式（因此无法压缩）：
tcp_checksum =:= irregular(16);
tcp_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;
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”和“ULENGHT”属性与上下文中各自的值绑定，“CLENGHT”属性绑定为零。
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报头的源端口是一个字段，对于给定流，其值不会从一个数据包更改为下一个数据包：
src_port =:= static;
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.
最低有效位编码方法“lsb”压缩其值与存储在上下文中的值相差很小的字段。传输字段值的最低有效位，而不是原始字段值。
field =:= lsb(<num_lsbs_param>, <offset_param>);
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);
tcp_sequence_number =:= lsb(14, 8192);
This takes up 14 bits, and can communicate any value that is between 8192 lower than the value of the field stored in context and 8191 above it.
这占用14位，并且可以传递低于上下文中存储的字段值的8192和高于该字段值的8191之间的任何值。
The interpretation interval can be described as a function of a value stored in the context, ref_value, and of num_lsbs_param:
解释间隔可以描述为存储在上下文中的值ref_value和num_lsbs_param的函数：
f(context_value, num_lsbs_param) = [ref_value - offset_param,
ref_value + (2^num_lsbs_param - 1) - offset_param]
f(context_value, num_lsbs_param) = [ref_value - offset_param,
ref_value + (2^num_lsbs_param - 1) - offset_param]
where offset_param is an integer.
其中offset_param是一个整数。
<-- interpretation interval (size is 2^num_lsbs_param) -->
|---------------------------+----------------------------|
lower ref_value upper
bound bound
<-- 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
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_值增加。如果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.
压缩器可能无法确定存储在解压器上下文中且将由解压器使用的确切参考值，因为一些本来会更新上下文的数据包可能已经丢失或损坏。然而，根据收到的反馈或作出假设，压缩器可以限制候选值集。然后，压缩器可以选择使用“lsb”编码的格式，该格式使用其参数num_lsbs_param和offset_param的合适值定义，这样，无论解压器使用候选集中的哪个上下文值，结果解压都是正确的。如果不可能，则“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_位），
o the bit-pattern for the polynomial (bit_pattern),
o 多项式的位模式（位_模式），
o the initial value for the CRC register (initial_value),
o CRC寄存器的初始值（初始值），
o the value of the block of data, represented using either the "UVALUE" or "CVALUE" attribute of a field (block_data_value); and
o 数据块的值，使用字段的“UVALUE”或“CVALUE”属性表示（块数据值）；和
o the size in octets of the block of data (block_data_length).
o 数据块的大小（数据块长度），以八位字节为单位。
That is:
即:
field =:= crc(<num_bits>, <bit_pattern>, <initial_value>,
<block_data_value>, <block_data_length>);
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);
// 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.
如上所示，“THIS”关键字（见第4.6节）的使用在使用“crc”编码时是典型的。例如，当在整个报头的编码方法中使用时，它会导致在报头中的所有字段上计算CRC。
New encoding methods can be defined in a formal specification. These compose groups of individual fields into a contiguous block.
新的编码方法可以在正式规范中定义。这些字段将单个字段组组成一个连续的块。
Encoding methods have names and may have parameters; they can also be used in the same way as any other encoding method from the library of
编码方法有名称，也可能有参数；它们也可以与数据库中的任何其他编码方法相同的方式使用
encoding methods. Since they can contain references to other encoding methods, complicated formats can be broken down into manageable pieces in a hierarchical fashion.
编码方法。因为它们可以包含对其他编码方法的引用，所以复杂的格式可以以分层的方式分解为可管理的部分。
This section describes the various features used to define new encoding methods.
本节介绍用于定义新编码方法的各种功能。
This simplest form of defining an encoding method is to specify a single encoding. For example:
定义编码方法的最简单形式是指定单个编码。例如：
compound_encoding_method
{
UNCOMPRESSED {
field_1; // 4 bits
field_2; // 12 bits
}
compound_encoding_method
{
UNCOMPRESSED {
field_1; // 4 bits
field_2; // 12 bits
}
COMPRESSED {
field_2 =:= uncompressed_value(12, 9); // 0 bits
field_1 =:= irregular(4); // 4 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.
以上内容从新方法的标识符“复合编码方法”开始。然后，该方法的定义在花括号内“{”和“}”。定义中的第一项是“未压缩”字段列表，它以未压缩格式给出字段的顺序。然后是压缩格式字段列表（“压缩”）。此列表给出了压缩格式字段的顺序，并给出了每个字段的编码方法。
In the example, both the formats list each field exactly once. However, sometimes it is necessary to specify more than one binding for a given field, which means it appears more than once in the field list. In this case, it is the first occurrence of the field in the list that indicates its position in the field order. The subsequent occurrences of the field only specify binding information, not field order information.
在本例中，两种格式只列出每个字段一次。但是，有时需要为给定字段指定多个绑定，这意味着它在字段列表中出现多次。在这种情况下，字段在列表中的第一次出现表示其在字段顺序中的位置。字段的后续出现仅指定绑定信息，而不是字段顺序信息。
The different components of this example are described in more detail below. Other components that can be used in the definition of encoding methods are also defined thereafter.
下面将更详细地描述该示例的不同组件。此后还定义了可用于编码方法定义的其他组件。
The uncompressed field list is defined by "UNCOMPRESSED", which specifies the fields of the uncompressed format in the order that they appear in the uncompressed header. The sum of the lengths of each individual uncompressed field in the list must be equal to the length of the field being encoded. Finally, the representation of the uncompressed format described using the list of fields in the "UNCOMPRESSED" section, for which compressed formats are being defined, always consists of one single contiguous block of bits.
未压缩字段列表由“uncompressed”定义，它按照未压缩标题中显示的顺序指定未压缩格式的字段。列表中每个未压缩字段的长度之和必须等于正在编码的字段的长度。最后，使用正在定义压缩格式的“未压缩”部分中的字段列表描述的未压缩格式的表示始终由一个连续的位块组成。
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节中的示例中，未压缩字段列表为“字段_1”，后跟“字段_2”。这意味着通过该方法编码的字段被分为两个子字段，“字段_1”和“字段_2”。因此，这两个字段的未压缩总长度等于被编码字段的长度：
field_1.ULENGTH + field_2.ULENGTH == THIS.ULENGTH
field_1.ULENGTH + field_2.ULENGTH == THIS.ULENGTH
In the example, there are only two fields, but any number of fields may be used. This relationship applies to however many fields are actually used. Any arrangement of fields that efficiently describes the content of the uncompressed header may be chosen -- this need not be the same as the one described in the specifications for the protocol header being compressed.
在本例中，只有两个字段，但可以使用任意数量的字段。此关系适用于实际使用的任何字段。可以选择有效地描述未压缩报头内容的任何字段排列——这不需要与规范中描述的压缩协议报头相同。
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位序列号，但其会话往往是短期的。这意味着序列号的高位几乎总是恒定的。“未压缩”格式可以通过将原始未压缩字段拆分为两个字段来反映这一点，一个字段表示序列号几乎总是零的部分，另一个字段表示突出部分。
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
必须始终定义每个未压缩格式的总长度。还必须定义未压缩格式的每个字段的长度。这意味着“未压缩”、“压缩”（见下文第4.12.1.2节）、“控制”（见下文第4.12.1.3节）、“初始”（见下文第4.12.1.4节）和“默认”（见下文第4.12.1.5节）字段列表中的绑定必须在它们之间定义
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.
未压缩格式，以便将未压缩格式中的位明确映射到“未压缩”字段列表中列出的字段。
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.
“压缩”字段列表中指定的字段顺序不必与“未压缩”字段列表中显示的顺序匹配。可能需要以压缩格式对字段进行重新排序，以便将压缩头与八位字节边界对齐，或者出于其他原因。在上面的示例中，顺序实际上与未压缩格式中的顺序相反。
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.
压缩字段列表指定“字段_1”的编码为“不规则”，并在压缩格式和未压缩格式中占用4位。“field_2”的编码是“uncompressed_value”，这意味着该字段有一个固定的值，因此可以将其压缩到零位。它的值为9，在未压缩格式中为12位宽。
Fields like "field_2", which compress to zero bits in length, may appear anywhere in the field list without changing the compressed format because their position in the list is not significant. In fact, if the encoding method for this field were defined elsewhere (for example, in the "UNCOMPRESSED" section), this field could be omitted from the "COMPRESSED" section altogether:
像“field_2”这样的字段，其长度压缩为零位，可以出现在字段列表中的任何位置，而不改变压缩格式，因为它们在列表中的位置并不重要。事实上，如果该字段的编码方法是在其他地方定义的（例如，在“未压缩”部分中），则可以从“压缩”部分中完全忽略该字段：
compound_encoding_method
{
UNCOMPRESSED {
field_1; // 4 bits
field_2 =:= uncompressed_value(12, 9); // 12 bits
}
compound_encoding_method
{
UNCOMPRESSED {
field_1; // 4 bits
field_2 =:= uncompressed_value(12, 9); // 12 bits
}
COMPRESSED {
field_1 =:= irregular(4); // 4 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节）字段列表中的绑定必须在它们之间定义“长度”压缩格式中每个字段的属性，以便从压缩格式中的位到“压缩”字段列表中列出的字段有明确的映射。
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.
使用“控制”字段列表定义控制字段。“控制字段”列表指定未以未压缩格式显示但具有未压缩值的所有字段（特别是“ULENGHT”大于零的字段）。此类字段可用于帮助更有效地压缩未压缩格式的字段。控制字段可用于通过表示多个未压缩字段之间的一些公共性，或通过表示协议头中未显式包含的关于流的一些信息来提高效率。
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
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
}
ip_id; // 16 bits
src_addr; // 32 bits
dst_addr; // 32 bits
checksum; // 16 bits
length; // 16 bits
}
CONTROL { ip_id_behavior; // 1 bit : :
控件{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;
}
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);
}
CONTROL {
scaled_field;
ENFORCE(scaled_field.UVALUE == field_1.UVALUE / 8);
ENFORCE(scaled_field.ULENGTH == field_1.ULENGTH - 3);
}
COMPRESSED {
scaled_field =:= lsb(4, 0);
}
}
COMPRESSED {
scaled_field =:= lsb(4, 0);
}
}
This control field is used to scale down a field in the uncompressed format by a factor of 8 before encoding it with the "lsb" encoding method. Scaling it down makes the "lsb" encoding more efficient.
此控制字段用于在使用“lsb”编码方法对未压缩格式的字段进行编码之前，将其缩小8倍。缩小它可以使“lsb”编码更有效。
Control fields may also be used with a global scope. In this case, their declaration must be outside of any encoding method definition. They are then visible within any encoding method, thus allowing information to be shared between encoding methods directly.
控制字段也可以与全局范围一起使用。在这种情况下，它们的声明必须在任何编码方法定义之外。然后，它们在任何编码方法中都可见，从而允许在编码方法之间直接共享信息。
In order to allow fields in the very first usage of a specific format to be compressed with "static", "lsb", or other encoding methods that depend on the context, it is possible to specify initial bindings for such fields. This is done using "INITIAL", for example:
为了允许使用“静态”、“lsb”或其他依赖于上下文的编码方法对第一次使用特定格式的字段进行压缩，可以为此类字段指定初始绑定。这是使用“初始值”完成的，例如：
INITIAL {
field =:= uncompressed_value(4, 6);
}
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.
这将“字段”的“U值”初始化为6，并将其“U长度”初始化为4。与形式表示法中指定的所有其他绑定不同，如果字段的上下文未定义，则这些绑定将应用于字段的上下文。这在使用依赖于上下文存在的编码方法时特别有用，例如流中的第一个数据包的“静态”或“lsb”。
Because the "INITIAL" field list is used to bind the context alone, it makes no sense to specify initial bindings that themselves rely on the context, for example, "lsb". Such usage is not allowed.
由于“INITIAL”字段列表仅用于绑定上下文，因此指定其本身依赖于上下文的初始绑定（例如“lsb”）毫无意义。这种用法是不允许的。
Default bindings may be specified for each field or attribute. The default encoding methods specify the encoding method to use for a field if no binding is given elsewhere for the value of that field. This is helpful to keep the definition of the formats concise, as the same encoding method need not be repeated for every format, when defining multiple formats (see Section 4.12.3).
可以为每个字段或属性指定默认绑定。默认编码方法指定在其他地方未为字段的值提供绑定时用于该字段的编码方法。这有助于保持格式定义的简洁，因为在定义多种格式时，不需要对每种格式重复相同的编码方法（见第4.12.3节）。
Default bindings are optional and may be given for any combination of fields and attributes which are in scope.
默认绑定是可选的，可以为范围内的任何字段和属性组合提供。
The syntax for specifying default bindings is similar to that used to specify a compressed or uncompressed format. However, the order of the fields in the field list does not affect the order of the fields in either the compressed or uncompressed format. This is because the field order is specified individually for each "COMPRESSED" format and "UNCOMPRESSED" format.
用于指定默认绑定的语法与用于指定压缩或未压缩格式的语法类似。但是，字段列表中字段的顺序不影响压缩或未压缩格式中字段的顺序。这是因为为每个“压缩”格式和“未压缩”格式分别指定了字段顺序。
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);
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指定了默认绑定。还指定了字段_4的“ULENGHT”属性的默认绑定。
Fields for which there is a default encoding method do not need their bindings to be specified in the field list of any format that uses the default encoding method for that field. Any format that does not use the default encoding method must explicitly specify a binding for the value of that field's attributes.
具有默认编码方法的字段不需要在使用该字段的默认编码方法的任何格式的字段列表中指定其绑定。任何不使用默认编码方法的格式都必须显式指定该字段属性值的绑定。
If elsewhere a binding is not specified for the attributes of a field, the default encoding method is used. If the default encoding method always compresses the field down to zero bits, the field can be omitted from the compressed format's field list. Like any other zero-bit field, its position in the field list is not significant.
如果在其他地方没有为字段的属性指定绑定，则使用默认编码方法。如果默认编码方法总是将字段压缩到零位，则可以从压缩格式的字段列表中省略该字段。与任何其他零位字段一样，其在字段列表中的位置并不重要。
The "DEFAULT" field list may contain default bindings for individual attributes by using "ENFORCE" statements. A default binding for an individual attribute will only be used if elsewhere there is no binding given for that attribute or the field to which it belongs. If elsewhere there is an "ENFORCE" statement binding that attribute, or an encoding method binding the field to which it belongs, the default binding for the attribute will not be used. This applies even if the specified encoding method does not bind the particular attribute given in the "DEFAULT" section. However, an "ENFORCE" statement elsewhere that only binds the length of the field still allows the default bindings to be used, except for default "ENFORCE" statements which bind nothing but the field's length.
“DEFAULT”字段列表可以通过使用“ENFORCE”语句包含单个属性的默认绑定。只有在其他地方没有为单个属性或其所属字段提供绑定时，才会使用该属性的默认绑定。如果在其他地方存在绑定该属性的“强制”语句，或者存在绑定该属性所属字段的编码方法，则不会使用该属性的默认绑定。即使指定的编码方法没有绑定“DEFAULT”部分中给定的特定属性，这也适用。但是，其他地方仅绑定字段长度的“ENFORCE”语句仍然允许使用默认绑定，除了绑定字段长度的默认“ENFORCE”语句之外。
To clarify, assuming the default bindings given in the example above, the first three of the following four compressed formats would not use the default binding for "field_4.ULENGTH":
为了澄清，假设上面的示例中给出了默认绑定，以下四种压缩格式中的前三种不会使用“field_4.ulelength”的默认绑定：
COMPRESSED format1 {
ENFORCE(field_4.ULENGTH == 3); // set ULENGTH to 3
ENFORCE(field_4.UVALUE == 7); // set UVALUE to 7
}
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 format2 {
field_4 =:= irregular(3); // set ULENGTH to 3
}
COMPRESSED format3 {
field_4 =:= '1010'; // set ULENGTH to zero
}
COMPRESSED format3 {
field_4 =:= '1010'; // set ULENGTH to zero
}
COMPRESSED format4 {
ENFORCE(field_4.UVALUE == 12); // use default ULENGTH
}
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".
第四种格式是唯一使用“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;
}
poor_mans_lsb(variable_length)
{
UNCOMPRESSED {
constant_bits;
variable_bits;
}
COMPRESSED {
variable_bits =:= irregular(variable_length);
constant_bits =:= static;
}
}
COMPRESSED {
variable_bits =:= irregular(variable_length);
constant_bits =:= static;
}
}
As with any encoding method, all arguments take individual values, such as an integer literal or a field attribute, rather than entire fields. Although entire fields cannot be passed as arguments, it is possible to pass each of their attributes instead, which is equivalent.
与任何编码方法一样，所有参数都采用单个值，例如整型文字或字段属性，而不是整个字段。虽然不能将整个字段作为参数传递，但可以传递它们的每个属性，这是等效的。
Recall that all bindings are two-way, so that rather than the arguments acting as "inputs" to the encoding method, the result of an encoding method may be to bind the parameters passed to it.
回想一下，所有绑定都是双向的，因此编码方法的结果可能是绑定传递给它的参数，而不是充当编码方法“输入”的参数。
For example:
例如：
set_to_double(arg1, arg2)
{
CONTROL {
ENFORCE(arg1 == 2 * arg2);
}
}
set_to_double(arg1, arg2)
{
CONTROL {
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".
此编码方法将尝试将第一个参数绑定到第二个参数值的两倍。事实上，这种“编码”方法是病态的。因为它没有定义字段，所以根本不进行任何实际编码。“控制”部分比“未压缩”部分更适合用于此目的。
Encoding methods can also define multiple formats for a given header. This allows different compression methods to be used depending on what is the most efficient way of compressing a particular header.
编码方法还可以为给定的头定义多种格式。这允许根据压缩特定头的最有效方式使用不同的压缩方法。
For example, a field may have a fixed value most of the time, but the value may occasionally change. Using a single format for the encoding, this field would have to be encoded using "irregular" (see Section 4.11.3), even though the value only changes rarely. However, by defining multiple formats, we can provide two alternative encodings: one for when the value remains fixed and another for when the value changes.
例如，一个字段在大多数时间可能有一个固定值，但该值可能偶尔会更改。使用单一格式进行编码时，该字段必须使用“不规则”（见第4.11.3节）进行编码，即使该值很少变化。但是，通过定义多种格式，我们可以提供两种可选编码：一种用于值保持固定时，另一种用于值更改时。
This is the topic of the following sub-sections.
这是以下小节的主题。
When compressed formats are defined, they must be defined using the reserved word "COMPRESSED". Similarly, uncompressed formats must be defined using the reserved word "UNCOMPRESSED". After each of these keywords, a name may be given for the format. If no name is given to the format, the name of the format is empty.
定义压缩格式时，必须使用保留字“compressed”来定义。类似地，必须使用保留字“uncompressed”定义未压缩格式。在每个关键字之后，可能会为格式指定一个名称。如果没有为格式指定名称，则格式的名称为空。
Format names, except for the case where the name is empty, follow the syntactic rules of identifiers as described in Section 4.2.
格式名称（名称为空的情况除外）遵循第4.2节中描述的标识符语法规则。
Format names must be unique within the scope of the encoding method to which they belong, except for the empty name, which may be used for one "COMPRESSED" and one "UNCOMPRESSED" format.
格式名称在其所属的编码方法范围内必须唯一，空名称除外，空名称可用于一种“压缩”格式和一种“未压缩”格式。
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节）成功。如果有多个成功的组合，压缩机可以选择任何一个。否则，如果没有成功的组合，则编码方法“失败”。格式永远不会因为没有定义字段的“UVALUE”属性而失败。仅当格式未能定义压缩格式中某个字段的一个压缩属性，或未定义未压缩格式的长度时，格式才会失败。
Because the compressor has a choice, it must be possible for the decompressor to discriminate between the different compressed formats that the compressor could have chosen. A simple approach to this problem is for each compressed format to include a "discriminator" that uniquely identifies that particular "COMPRESSED" format. A discriminator is a control field; it is not derived from any of the uncompressed field values (see Section 4.11.2).
因为压缩器可以选择，所以解压器必须能够区分压缩器可以选择的不同压缩格式。解决此问题的一个简单方法是，每个压缩格式都包含一个“鉴别器”，该鉴别器唯一地标识特定的“压缩”格式。鉴别器是控制场；它不是从任何未压缩的字段值导出的（见第4.11.2节）。
Putting this all together, here is a complete example of the definition of an encoding method with multiple compressed formats:
综上所述，下面是一个使用多种压缩格式定义编码方法的完整示例：
example_multiple_formats
{
UNCOMPRESSED {
field_1; // 4 bits
field_2; // 4 bits
field_3; // 24 bits
}
example_multiple_formats
{
UNCOMPRESSED {
field_1; // 4 bits
field_2; // 4 bits
field_3; // 24 bits
}
DEFAULT {
field_1 =:= static;
field_2 =:= uncompressed_value(4, 2);
field_3 =:= lsb(4, 0);
}
DEFAULT {
field_1 =:= static;
field_2 =:= uncompressed_value(4, 2);
field_3 =:= lsb(4, 0);
}
COMPRESSED format0 {
discriminator =:= '0'; // 1 bit
field_3; // 4 bits
}
COMPRESSED format0 {
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
}
}
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”的编码方法不会压缩到零位，因此，虽然“field_3”在“format0”的字段列表中没有为其指定编码，但它仍然需要出现在字段列表中，以指定压缩格式的位置。
o In the example, all the fields in the uncompressed format have default encoding methods specified for them, but this is not a requirement. Default encodings can be specified for only some or even none of the fields of the uncompressed format.
o 在本例中，未压缩格式的所有字段都有为其指定的默认编码方法，但这不是必需的。只能为未压缩格式的部分字段指定默认编码，甚至不能为任何字段指定默认编码。
o In the example, all the default encoding methods are on fields from the uncompressed format, but this is not a requirement. Default encoding methods can be specified for control fields.
o 在本例中，所有默认编码方法都在未压缩格式的字段上，但这不是必需的。可以为控制字段指定默认编码方法。
The library of encoding methods defined by ROHC-FN in Section 4.11 provides a basic and generic set of field encoding methods. When using a ROHC-FN specification in a ROHC profile, some additional encodings specific to the particular protocol header being compressed may, however, be needed, such as methods that infer the value of a field from other values.
ROHC-FN在第4.11节中定义的编码方法库提供了一组基本的通用字段编码方法。然而，当在ROHC简档中使用ROHC-FN规范时，可能需要特定于被压缩的特定协议报头的一些附加编码，例如从其他值推断字段值的方法。
These methods are specific to the properties of the protocol being compressed and will thus have to be defined within the profile
这些方法特定于被压缩协议的属性，因此必须在概要文件中定义
specification itself. Such profile-specific encoding methods, defined either in ROHC-FN syntax or rigorously in plain text, can be referred to in the ROHC-FN specification of the profile's formats in the same way as any method in the ROHC-FN library.
规范本身。在ROHC-FN规范中，可以以与ROHC-FN库中任何方法相同的方式引用这些以ROHC-FN语法定义或严格以纯文本定义的特定于概要文件的编码方法。
Encoding methods that are not defined in the formal notation are specified by giving their name, followed by a short description of where they are defined, in double quotes, and a semi-colon.
未在形式表示法中定义的编码方法是通过给出它们的名称来指定的，后面是定义它们的位置的简短描述（用双引号和分号）。
For example:
例如：
inferred_ip_v4_header_checksum "defined in RFCxxxx Section 6.4.1";
RFCxxxx第6.4.1节中定义的“推断ip\U v4\U标头\U校验和”；
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.
Richard Price在形式符号方面做了很多基础工作。他编写了最初的文档，描述了本文档所基于的正式符号。
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
感谢Stewart Sadler、Caroline Daniels、Alan Finney和David Findlay的评论和评论。感谢Rob Hancock和Stephen McCann在形式符号方面的早期工作。这个
authors would also like to thank Christian Schmidt, Qian Zhang, Hongbin Liao, and Max Riegel for their comments and valuable input.
作者还要感谢Christian Schmidt、钱张、廖宏斌和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.
额外感谢：在工作组最后一次电话会议期间，本文件由尽职尽责的审查员马克·韦斯特、卡斯滕·鲍曼和乔·图奇以及应交通区域主管要求提供审查的萨利·弗洛伊德审查。还要感谢Magnus Westerlund在准备IESG审查时提供的反馈。
[C90] ISO/IEC, "ISO/IEC 9899:1990 Information technology -- Programming Language C", ISO 9899:1990, April 1990.
[C90]ISO/IEC，“ISO/IEC 9899:1990信息技术——编程语言C”，ISO 9899:1990，1990年4月。
[RFC2822] Resnick, P., Ed., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", RFC 2822, April 2001.
[RFC2822]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，“鲁棒头压缩（ROHC）框架”，RFC 49952007年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，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：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.
本节给出了ABNF[RFC4234]中ROHC-FN语法的定义，使用“fnspec”作为开始规则。
; 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 ";"
; 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
; 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
; 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
; 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.
例如，010100010000表示版本号为1、类型为1、流id为1、序列号为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 |
+---+---+---+---+---+---+---+---+
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 ];
}
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);
}
}
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
未压缩标题：010100010000压缩标题：010100010000
This is because we have stated that all fields are "irregular" -- i.e., we haven't specified anything about their behaviour.
这是因为我们已经声明所有字段都是“不规则的”——也就是说，我们没有具体说明它们的行为。
Note that since we have only one compressed format and one uncompressed format, it makes no difference whether the encoding methods for each field are specified in the compressed or uncompressed format. It would make no difference at all if we wrote the following instead:
请注意，因为我们只有一种压缩格式和一种未压缩格式，所以每个字段的编码方法是以压缩格式还是未压缩格式指定都没有区别。如果我们写下以下内容，那就没有什么区别了：
eg_header
{
UNCOMPRESSED {
version_no =:= irregular(2);
type =:= irregular(2);
flow_id =:= irregular(4);
sequence_no =:= irregular(4);
flag_bits =:= irregular(4);
}
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 ];
}
}
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. 标志位——包含三个标志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 ];
}
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 ];
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，因此不包含任何有用的信息。我们还对最后的标志位始终为零这一事实进行了编码，这同样不包含任何有用的信息。使用“未压缩_值”编码方法（见第4.11.1节）对这两个事实进行了标注。
Using this new encoding on the above header, we get:
在上述标题上使用此新编码，我们得到：
Uncompressed header: 0101000100010000 Compressed header: 0100010001000
未压缩标题：010100010000压缩标题：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%。然而，这种编码无法利用一个数据包中字段的值与其在后续数据包中的值之间的关系。例如，以下序列中的每个标头都被压缩相同的量，尽管它们之间存在相似性：
Uncompressed header: 0101000100010000 Compressed header: 0100010001000
未压缩标题：010100010000压缩标题：0100010001000
Uncompressed header: 0101000101000000 Compressed header: 0100010100000
未压缩标题：0101000101000000压缩标题：0100010100000
Uncompressed header: 0110000101110000 Compressed header: 1000010111000
未压缩标题：01100010110000压缩标题：100000111000
The profile we have defined so far has not compressed the sequence number or flow ID fields at all, since they can take any value. However the value of each of these fields in one header has a very simple relationship to their values in previous headers:
到目前为止，我们定义的概要文件根本没有压缩序列号或流ID字段，因为它们可以接受任何值。但是，一个标题中每个字段的值与以前标题中的值有一个非常简单的关系：
o the sequence number is unusual -- it increases by three each time,
o 序列号很不寻常，每次增加三个，
o the flow_id stays the same -- it always has the same value that it did in the previous header in the flow,
o 流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_标志_位大部分时间保持不变——它们的值通常与流中上一个标头中的值相同。
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 ];
}
// 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);
}
}
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”字段被表示为“static”，这意味着它不会随着数据包的变化而变化。但是，该符号并不表示最初如何传递字段的值。如果我们没有第一次定义该值是什么，那么说“它与上次的值相同”是没有意义的，这样就可以引用它。上面的符号没有提供传达这种信息的方式。与序列号类似，需要有一种方法来传递其初始值。事实上，除了表示其长度的显式符号外，即使这两个字段的长度也没有定义。该问题将在下面的附录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
其次，序列号字段在零位中进行了非常有效的通信，但它对分组丢失根本不具有鲁棒性。如果数据包丢失，则无法处理丢失的序列号。当通信序列号或使用“lsb”编码编码的任何其他字段时，对于注释器来说，一个非常重要的考虑因素是压缩协议应具有多大的抗丢包能力。这在不同的协议栈中会有很大的不同
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”编码实现这一点（一位是不够的，因为序列号每次增加三位——见第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 ];
}
// 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);
}
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);
}
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字段的初始值，并利用标志位通常与前一个报头中相同的事实，我们需要脱离当前使用的单一格式编码，而是使用多种格式。这里，我们以未压缩格式表示了其中两个字段的编码，因为对于该格式的未压缩头，它们始终为真。其余字段的编码方法可能完全取决于头的压缩方式，它们的编码以压缩格式指定。
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 ];
}
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 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 ];
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 ];
}
}
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.
然而，由于增加了鉴别器（“不规则_格式”），原始的“基本”格式也增加了一位。在创建多个格式时，一个重要的考虑因素是每种格式的出现频率是否足以使平均压缩头长度因其使用而缩短。例如，如果事实上标志位在数据包之间总是改变，则“压缩的_格式”编码永远不能使用；我们所能做到的就是将“基本”格式延长一位。
Using the above notation, we now get:
使用上述符号，我们现在得到：
Uncompressed header: 0101000100010000 Compressed header: 00100010001000
未压缩标题：010100010000压缩标题：00100010001000
Uncompressed header: 0101000101000000 Compressed header: 10100 ; 00100010100000
未压缩头：010100001000000压缩头：10100；00100010100000
Uncompressed header: 0110000101110000 Compressed header: 11011 ; 01000010111000
未压缩头：01100001110000压缩头：11011；01000010111000
The first header in the stream is compressed the same way as before, except that it now has the extra 1-bit discriminator at the start (0). When a second header arrives with the same flow ID as the first and its sequence number three higher, it can be compressed in two possible ways: either by using "compressed_format" or, in the same way as previously, by using "irregular_format".
流中的第一个头以与之前相同的方式压缩，只是它现在在开始（0）处有额外的1位鉴别器。当第二个报头以与第一个报头相同的流ID到达并且其序列号高出3时，可以通过两种可能的方式对其进行压缩：使用“压缩的_格式”或与前面相同的方式使用“不规则的_格式”。
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
注意，我们展示了ROHC-FN规范定义的所有理论上可能的头编码，用分号分隔。每个报头的上述任一编码都可以由一个有效的实现生成，尽管一个好的实现总是以选择导致最佳压缩的编码为目标。一个好的实现还将考虑健壮性，因此
probably wouldn't assume on the second packet that the decompressor had available the context necessary to decompress the shorter "compressed_format" form.
可能不会在第二个数据包上假设解压器具有解压较短的“compressed_format”表单所需的上下文。
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标志。为了更有效地编码流，需要编写一种格式来反映这一点。
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.
现在总共有三种格式，这意味着我们需要三个鉴别器来区分它们。这里显而易见的解决方案是将鉴别器中的比特数从一个增加到两个，并且例如使用鉴别器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开头，则解压缩程序知道它必须再检查一位以确定格式的类型。
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、01和10作为鉴别器是错误的，因为在读取初始0之后，解压缩器将无法知道下一位是鉴别器的第二位还是格式中下一字段的第一位。然而，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 ];
}
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 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_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 ];
}
}
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
未压缩标题：010100010000压缩标题：00010001000
Uncompressed header: 0101000101000000 Compressed header: 10100 ; 000100010100000
未压缩头：010100001000000压缩头：10100；000100010100000
Uncompressed header: 0110000101110000 Compressed header: 11011 ; 001000010111000
未压缩头：01100001110000压缩头：11011；001000010111000
Uncompressed header: 0111000110101110 Compressed header: 011110 ; 001100011010111
未压缩头：01110010101110压缩头：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.
这里我们有一个与上次非常相似的序列，除了现在在末尾有一个额外的消息，它设置了标志位。流中第一条消息的编码现在大了一位，接下来两条消息的编码与以前相同，因为格式没有增长；由于使用了可变长度鉴别器。最后，带有所有标志位集的数据包可以用六位编码，只比最常见的格式多一位。如果没有额外的格式，最后的数据包将不得不使用最长的格式进行编码，并且将占用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 ];
}
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;
DEFAULT {
type =:= irregular(2);
flow_id =:= static;
sequence_no =:= lsb(2, -3);
}
sequence_no =:= lsb(2, -3);
}
COMPRESSED irregular_format {
discriminator =:= '00' [ 2 ];
type [ 2 ]; // Uses default
flow_id =:= irregular(4) [ 4 ]; // Overrides default
sequence_no =:= irregular(4) [ 4 ]; // Overrides default
abc_flag_bits =:= irregular(3) [ 3 ];
}
COMPRESSED 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_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;
}
}
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.
到目前为止，我们产生的压缩方案中的一个低效之处是，它使用两个比特来提供“lsb”编码的序列号，对于仅丢失一个数据包具有鲁棒性。理论上，只需要一个比特。问题的根源是协议使用的不寻常的序列号——它以三的增量递增。为了以最高效率对其进行编码，我们需要将其转换为一个每次递增一的字段。我们使用一个控制字段来实现这一点。
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:
我们引入的控制字段将序列号向下缩放三倍。我们不对压缩数据包中的原始序列号进行编码，而是对缩放序列号进行编码，从而使我们能够通过仅使用一位“lsb”编码对一个数据包的丢失具有鲁棒性：
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 ];
}
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);
}
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);
}
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 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 ];
COMPRESSED flags_set {
discriminator =:= '01' [ 2 ];
type [ 2 ];
scaled_seq_no [ 1 ]; // Uses default
abc_flag_bits =:= uncompressed_value(3, 7);
}
scaled_seq_no [ 1 ]; // 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;
}
}
COMPRESSED flags_static {
discriminator =:= '1' [ 1 ];
type [ 2 ];
scaled_seq_no [ 1 ]; // Uses default
abc_flag_bits =:= static;
}
}
Normally, the encoding method(s) used to encode a field specifies the length of the field. In the above notation, since there is no encoding method using "sequence_no" directly, its length needs to be defined explicitly using an "ENFORCE" statement. This is done using the abbreviated syntax, both for consistency and also for ease of readability. Note that this is unusual: whereas the majority of field length indications are redundant (and thus optional), this one isn't. If it was removed from the above notation, the length of the "sequence_no" field would be undefined.
通常，用于编码字段的编码方法指定字段的长度。在上述表示法中，由于没有直接使用“sequence_no”的编码方法，因此需要使用“ENFORCE”语句显式定义其长度。这是使用缩写语法完成的，既为了一致性，也为了易于阅读。请注意，这是不寻常的：虽然大多数场长指示是冗余的（因此是可选的），但这一个不是。如果将其从上述符号中删除，“sequence_no”字段的长度将未定义。
Here is some example output:
以下是一些示例输出：
Uncompressed header: 0101000100010000 Compressed header: 000100011011000
未压缩标题：010100010000压缩标题：00010001011000
Uncompressed header: 0101000101000000 Compressed header: 1010 ; 000100011100000
未压缩头：010100001000000压缩头：1010；000100011100000
Uncompressed header: 0110000101110000 Compressed header: 1101 ; 001000011101000
未压缩头：01100001110000压缩头：1101；001000011101000
Uncompressed header: 0111000110101110 Compressed header: 01110 ; 001100011110111
未压缩头：01110010101110压缩头：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”头组成，压缩流中头的平均大小现在刚好超过未压缩流中头大小的四分之一。
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).
早些时候，我们创建了一种新格式“flags_set”，用于处理所有三个标志位都已设置的数据包。碰巧的是，这三个标志总是为“类型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，所以不需要在压缩头中对类型字段进行编码。类型字段先前编码为“unregular（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”格式只应用于“type 3”标题，而“flags_static”格式仅在类型不是三时使用，有必要在每个格式中说明这些条件。这可以通过“强制”语句完成：
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 ];
}
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);
}
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;
}
DEFAULT {
type =:= irregular(2);
scaled_seq_no =:= lsb(1, -1);
flow_id =:= static;
}
COMPRESSED irregular_format {
discriminator =:= '00' [ 2 ];
type [ 2 ];
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 ];
}
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_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 ];
}
}
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.
最后两种格式中的两个“强制”语句充当“保护”。防护装置防止在错误的情况下使用格式。事实上，“flags_set”中的“ENFORCE”语句是多余的。它所保护的条件已由用于“type”字段的新编码方法强制执行。编码方法“uncompressed_value（2,3）”将“UVALUE”属性绑定到3。这正是“强制”语句所做的，因此可以删除它而不改变其含义。另一方面，“未压缩_值”编码方法不是冗余的。除了“强制”语句指定的绑定外，它还指定类型字段上的其他绑定。因此，不可能删除编码方法而只保留“强制”语句。
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
未压缩标题：010100010000压缩标题：00010001011000
Uncompressed header: 0101000101000000 Compressed header: 1010 ; 000100011100000
未压缩头：010100001000000压缩头：1010；000100011100000
Uncompressed header: 0110000101110000 Compressed header: 1101 ; 001000011101000
未压缩头：01100001110000压缩头：1101；001000011101000
Uncompressed header: 0111000110101110 Compressed header: 010 ; 001100011110111
未压缩集管：01110010101110压缩集管：010；001100011110111
This saves just two extra bits (a 7% saving) in the example flow.
这在示例流中只节省了两个额外的位（节省了7%）。
Authors' Addresses
作者地址
Robert Finking Siemens/Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK
Robert Finking西门子/Roke Manor Research英国汉普郡老索尔兹伯里巷罗姆西SO51 0ZN
Phone: +44 (0)1794 833189
EMail: robert.finking@roke.co.uk
URI: http://www.roke.co.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信箱920 Lulea SE-971 28瑞典
Phone: +46 (0) 8 404 29 43
EMail: ghyslain.pelletier@ericsson.com
Phone: +46 (0) 8 404 29 43
EMail: ghyslain.pelletier@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。