RFC4997 日本語訳
4997 Formal Notation for RObust Header Compression (ROHC-FN). R.Finking, G. Pelletier. July 2007. (Format: TXT=131231 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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)
Formal Notation for RObust Header Compression (ROHC-FN)
Status of This Memo
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.
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.
Copyright Notice
Copyright Notice
Copyright (C) The IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
Abstract
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.
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.
Table of Contents
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
Finking & Pelletier Standards Track [Page 1] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 1] RFC 4997 ROHC-FN July 2007
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
Finking & Pelletier Standards Track [Page 2] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 2] RFC 4997 ROHC-FN July 2007
1. Introduction
1. Introduction
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.
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.
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.
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.
2. Terminology
2. Terminology
o Compressed format
o Compressed format
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.
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
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].
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].
o Control field
o Control field
Control fields are transmitted from a ROHC compressor to a ROHC
decompressor, but are not part of the uncompressed header itself.
Control fields are transmitted from a ROHC compressor to a ROHC decompressor, but are not part of the uncompressed header itself.
Finking & Pelletier Standards Track [Page 3] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 3] RFC 4997 ROHC-FN July 2007
o Encoding method, encodings
o Encoding method, encodings
Encoding methods are two-way relations that can be applied to
compress and decompress fields of a protocol header.
Encoding methods are two-way relations that can be applied to compress and decompress fields of a protocol header.
o Field
o Field
The protocol header is divided into a set of contiguous bit
patterns known as fields. Each field is defined by a collection
of attributes that indicate its value and length in bits for both
the compressed and uncompressed headers. The way the header is
divided into fields is specific to the definition of a profile,
and it is not necessary for the field divisions to be identical to
the ones given by the specification(s) for the protocol header
being compressed.
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 Library of encoding methods
The library of encoding methods contains a number of commonly used
encoding methods for compressing header fields.
The library of encoding methods contains a number of commonly used encoding methods for compressing header fields.
o Profile
o Profile
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.
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.
o ROHC-FN specification
o ROHC-FN specification
The specification of the set of formats of a ROHC profile using
ROHC-FN.
The specification of the set of formats of a ROHC profile using ROHC-FN.
o Uncompressed format
o Uncompressed format
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.
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.
3. Overview of ROHC-FN
3. Overview of ROHC-FN
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.
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.
Finking & Pelletier Standards Track [Page 4] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 4] RFC 4997 ROHC-FN July 2007
3.1. Scope of the Formal Notation
3.1. Scope of the Formal Notation
This section explains how the formal notation relates to the ROHC framework and to specifications of ROHC profiles.
This section explains how the formal notation relates to the ROHC framework and to specifications of ROHC profiles.
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.
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.
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.
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.
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.
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.
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:
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 specify how to manage the context for both the compressor and the decompressor,
o define when and what to send in feedback messages, if any, from
decompressor to compressor,
o define when and what to send in feedback messages, if any, from decompressor to compressor,
o outline compression principles to make the profile robust against
bit errors and dropped packets.
o outline compression principles to make the profile robust against bit errors and dropped packets.
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.
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
The ROHC-FN is designed to help in the specification of compressed formats that, when put together based on the profile definition, make
Finking & Pelletier Standards Track [Page 5] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 5] RFC 4997 ROHC-FN July 2007
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.
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.
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.
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.
3.2. Fundamentals of the Formal Notation
3.2. Fundamentals of the Formal Notation
There are two fundamental elements to the formal notation:
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. Fields and their encodings, which define the mapping between a header's uncompressed and compressed forms.
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. 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.
These two fundamental elements are at the core of the notation and are outlined below.
These two fundamental elements are at the core of the notation and are outlined below.
3.2.1. Fields and Encodings
3.2.1. Fields and Encodings
Headers are made up of fields. For example, version number, header length, and sequence number are all fields used in real protocols.
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:
Fields have attributes. Attributes describe various things about the field. For example:
field.ULENGTH
field.ULENGTH
The above indicates the uncompressed length of the field. A field is said to have a value attribute, i.e., a compressed value or an uncompressed value, if the corresponding length attribute is greater than zero. See Section 4.4 for more details on field attributes.
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.
The relationship between the compressed and uncompressed attributes of a field are specified with encoding methods, using the following notation:
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
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
Finking & Pelletier Standards Track [Page 6] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 6] RFC 4997 ROHC-FN July 2007
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.
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.
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.
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.
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.
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 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 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 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.
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
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
Finking & Pelletier Standards Track [Page 7] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 7] RFC 4997 ROHC-FN July 2007
maximum compression efficiency. The FN itself uses the full range of integers. See Section 4.4.2 for further details.
maximum compression efficiency. The FN itself uses the full range of integers. See Section 4.4.2 for further details.
3.2.2. Formats and Encoding Methods
3.2.2. Formats and Encoding Methods
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).
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 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 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.
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; }
Finking & Pelletier Standards Track [Page 8] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 8] RFC 4997 ROHC-FN July 2007
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:
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:
o fields that occur in the uncompressed format; or
o fields that occur in the uncompressed format; or
o control fields that have an uncompressed value and that occur in
the CONTROL section; or
o control fields that have an uncompressed value and that occur in the CONTROL section; or
o control fields that do not have an uncompressed value and thus are
defined as part of the compressed format.
o control fields that do not have an uncompressed value and thus are defined as part of the compressed format.
Central to each of these formats is a "field list", which defines the fields contained in the format and also the order that those fields appear in that format. For the "DEFAULT" and "CONTROL" sections, the field order is not significant.
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).
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).
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).
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).
Fields that have no uncompressed value do not appear in an "UNCOMPRESSED" field list and do not have to appear in the "CONTROL"
Fields that have no uncompressed value do not appear in an "UNCOMPRESSED" field list and do not have to appear in the "CONTROL"
Finking & Pelletier Standards Track [Page 9] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 9] RFC 4997 ROHC-FN July 2007
field list either. Instead, they are only declared in the compressed field lists where they are used.
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.
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.
3.3. Example Using IPv4
3.3. Example Using IPv4
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].
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].
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:
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_header
{
ipv4_header {
The fragment of notation above declares the encoding method "ipv4_header", the definition follows the opening brace (see Section 4.12).
The fragment of notation above declares the encoding method "ipv4_header", the definition follows the opening brace (see Section 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).
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).
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:
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:
Finking & Pelletier Standards Track [Page 10] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 10] RFC 4997 ROHC-FN July 2007
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.
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.
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.
次のステップは圧縮形式を指定することです。 これは各分野への圧縮されて解凍にされるのの間で分野のフォームを写像するencodingsを含んでいます。 例では、メソッドをコード化するこれらがROHC-FNライブラリから主に抜粋されます(セクション4.11を見てください)。 ここでの意志が記法の使用を例証することであるので、むしろ、この例はIPv4ヘッダーを圧縮する最適なメソッドを説明するよりメソッドをコード化する3だけを使用します。
The "uncompressed_value" encoding method (defined in Section 4.11.1) can compress any field whose uncompressed length and value are fixed, or can be calculated using an expression. No compressed bits need to be sent because the uncompressed field can be reconstructed using its known size and value. The "uncompressed_value" encoding method is used to compress five fields in the IPv4 header, as described below:
メソッド(セクション4.11.1では、定義される)をコード化する「解凍された_値」は、式を使用することで解凍された長さと値が固定しているか、または計算できるどんな分野も圧縮できます。 どんな圧縮されたビットも、その既知サイズと値を使用することで解凍された分野を再建できるので送られる必要がありません。 メソッドをコード化する「解凍された_値」はIPv4ヘッダーの5つの分野を圧縮するのに以下で説明されるように使用されます:
COMPRESSED {
header_length =:= uncompressed_value(4, 5);
version =:= uncompressed_value(4, 4);
reserved =:= uncompressed_value(1, 0);
offset =:= uncompressed_value(13, 0);
more_fragments =:= uncompressed_value(1, 0);
COMPRESSED、ヘッダー_長さ=: =は_値(4、5)を解凍しました; バージョン=: =は_値(4、4)を解凍しました; 予約された=: =は_値(1、0)を解凍しました; =を相殺してください: =は_値(13、0)を解凍しました; より多くの_が=を断片化します: =は_値(1、0)を解凍しました。
Finking & Pelletier Standards Track [Page 11] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[11ページ]。
The first parameter indicates the length of the uncompressed field in bits, and the second parameter gives its integer value.
最初のパラメタはビットの解凍された分野の長さを示します、そして、2番目のパラメタは整数値を与えます。
Note that the order of the fields in the compressed format is independent of the order of the fields in the uncompressed format.
圧縮形式における、分野の注文が解凍された形式における、分野の注文から独立していることに注意してください。
The "irregular" encoding method (defined in Section 4.11.3) can be used to encode any field for which both uncompressed attributes (ULENGTH and UVALUE) are defined, and whose ULENGTH attribute is either fixed or can be calculated using an expression. It is a fail- safe encoding method that can be used for such fields in the case where no other encoding method applies. All of the bits in the uncompressed form of the field are present in the compressed form as well; hence this encoding does not achieve any compression.
ULENGTH属性が式を使用することで両方の解凍された属性(ULENGTHとUVALUE)が定義されて、固定しているか、または計算できるどんな分野もコード化するのにメソッド(セクション4.11.3では、定義される)をコード化する「不規則」は使用できます。 メソッドをコード化するもう一方が全く適用されないケースの中のそのような分野に使用できるのは、メソッドをコード化するやり損ない金庫です。 優に分野の解凍された形のビットはまた、圧縮形に存在しています。 したがって、このコード化は少しの圧縮も達成しません。
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=: =不規則(32)。 dest_addr=: =不規則(32)。 長さ=: =不規則(16)。 イド=: =不規則(16)。 ttl=: =不規則(8)。 =について議定書の中で述べてください: =不規則(8) dscp=: =不規則(6)。 ecn=: =不規則(2)。 dont_は=を破片手榴弾で殺傷します: 不規則(1)と等しいです。
Finally, the third encoding method is specific only to the uncompressed format defined above for the IPv4 header, "inferred_ip_v4_header_checksum":
最終的に、3番目のコード化メソッドはIPv4ヘッダーのために上で定義された、解凍された書式、「推論された_ip_v4_ヘッダー_チェックサム」だけ、に特定です:
checksum =:= inferred_ip_v4_header_checksum [ 0 ];
}
}
チェックサム=: =は_ip_v4_ヘッダー_チェックサム[ 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図書館で定義されないのでメソッドをコード化する他の2と異なっています。 プロフィール定義(セクション4.12を見る)自体の一部として正式な記法を使用するか、または明瞭な英文を使用することによって、定義を与えることができるでしょう(セクション4.13を見てください)。
In our example, the "inferred_ip_v4_header_checksum" is a specific encoding method that calculates the IP checksum from the rest of the header values. Like the "uncompressed_value" encoding method, no compressed bits need to be sent, since the field value can be reconstructed at the decompressor. This is notated explicitly by specifying, in square brackets, a length of 0 for the checksum field in the compressed format. Again, this notation is optional since the encoding method itself would be defined as sending zero compressed
私たちの例では、「推論された_ip_v4_ヘッダー_チェックサム」はヘッダー値の残りからIPチェックサムについて計算する特定のコード化メソッドです。 メソッドをコード化する「解凍された_値」のように、どんな圧縮されたビットも、送られる必要がありません、減圧装置で分野値を再建できるので。 これは指定することによって、明らかにnotatedされます、角括弧で、圧縮形式のチェックサム分野への0の長さ。 コード化メソッド自体はゼロが圧縮した発信と定義されるでしょう、したがって、一方、この記法が任意です。
Finking & Pelletier Standards Track [Page 12] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[12ページ]。
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ヘッダーの代理をするのに使用できる圧縮形式を定義して、実装が解凍された形式(圧縮)から圧縮形式を逆もまた同様に構成するのを許容できるくらいの情報(減圧)を提供します。
4. Normative Definition of ROHC-FN
4. ROHC-FNの標準の定義
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.
このセクションの中の様々な場所では、角ブラケットの中のテキストが描写的であるプレースホルダとして使用されました。 このようにおける角ブラケットの使用は唯一このドキュメントの読者の利益のためのものです。 角ブラケットもそれらのコンテンツも記法の一部を形成しません。
4.1. Structure of a Specification
4.1. 仕様の構造
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)をコード化する1つ以上。
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
コード化メソッドは、解凍されたヘッダーの代理をするために1かさらに解凍された書式を与えるのによる正式な記法と1つ以上の圧縮形式を使用することで定義されます。 これらの形式は「分野」で互いに関連します。それはそれぞれある部分について説明します。
Finking & Pelletier Standards Track [Page 13] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[13ページ]。
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.
解凍される、そして/または、a圧縮されたヘッダー。 形式に加えて、それぞれメソッドをコード化すると、制御フィールド、初期の値、およびデフォルト分野encodings部は含むかもしれません。 分野の属性は、それにコード化メソッドを使用することによって縛られる、そして/または、形式の中で使用することによって、声明(セクション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.
事前に定義されたコード化メソッドは正式な記法で定義されません。 代わりに、それらは、コード化メソッドがどこで定義されるかがわかる短い原文の参照を与えることによって、定義されます。 本書ではこのように含まれたコード化メソッドのライブラリを定義するのは必要でない、彼らの定義が正式な記法の用法に暗黙です。
4.2. Identifiers
4.2. 識別子
In ROHC-FN, identifiers are used for any of the following:
ROHC-FNでは、識別子は以下のどれかに使用されます:
o encoding methods
o メソッドをコード化します。
o formats
o 形式
o fields
o 分野
o parameters
o パラメタ
o constants
o 定数
All identifiers may be of any length and may contain any combination of alphanumeric characters and underscores, within the restrictions defined in this section.
すべての識別子が、どんな長さもあって、英数字と強調のどんな組み合わせも含むかもしれません、このセクションで定義された制限の中で。
All identifiers must start with an alphabetic character.
すべての識別子が英字から始まらなければなりません。
It is illegal to have two or more identifiers that differ from each other only in capitalisation, in the same scope.
資本化だけにおいて互いに異なっている2つ以上の識別子を持っているのは不法です、同じ範囲で。
All letters in identifiers for constants must be upper case.
定数のための識別子のすべての手紙が大文字であるに違いありません。
It is illegal to use any of the following as identifiers (including alternative capitalisations):
識別子として以下のどれかを使用するのは不法です(代替の資本化を含んでいて):
o "false", "true"
o 「虚偽」「本当に」
o "ENFORCE", "THIS", "VARIABLE"
o 「実施」、「これ」、「変数」
o "ULENGTH", "UVALUE"
o "ULENGTH"、"UVALUE"
Finking & Pelletier Standards Track [Page 14] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[14ページ]。
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.)
それらは識別子であると考えられますが、記法で形式名を示すことができません。 (形式に関するその他の詳細のための.1が命名するセクション4.12.3を見てください。)
All identifiers used in ROHC-FN have a "scope". The scope of an identifier defines the parts of the specification where that identifier applies and from which it can be referred to. If an identifier has a "global" scope, then it applies throughout the specification that contains it and can be referred to from anywhere within it. If an identifier has a "local" scope, then it only applies to the encoding method in which it is defined, it cannot be referenced from outside the local scope of that encoding method. If an identifier has a local scope, that identifier can therefore be used in multiple different local scopes to refer to different items.
ROHC-FNで使用されるすべての識別子が「範囲」を持っています。 識別子の範囲はその識別子を適用して、それについて言及できる仕様の部分を定義します。 識別子に「グローバルな」範囲があるなら、それについて、それを含む仕様中で適用して、それの中でどこからでも言及できます。 識別子に「地方」の範囲があるなら、定義されるコード化メソッドにそれを適用するだけであり、メソッドをコード化しながら、その地方の範囲の外から参照をつけることができません。 したがって、識別子に地方の範囲があるなら、異なった項目を示すのに複数の異なった地方の範囲でその識別子を使用できます。
All instances of an identifier within its scope refer to the same item. It is not possible to have different items referred to by a single identifier within any given scope. For this reason, if there is an identifier that has global scope it cannot be used separately in a local scope, since a globally-scoped identifier is already applicable in all local scopes.
範囲の中の識別子のすべてのインスタンスが同じ項目を示します。 範囲を考えて、いずれも中にただ一つの識別子によって示された異なった項目を持っているのは可能ではありません。 この理由のために、グローバルな範囲を持っている識別子があれば、別々に地方の範囲でそれを使用できません、グローバルに見られた識別子がすべての地方の範囲で既に適切であるので。
The identifiers for each encoding method and each constant all have a global scope. Each format and field also has an identifier. The scope of format and field identifiers is local, with the exception of global control fields, which have a global scope. Therefore it is illegal for a format or field to have the same identifier as another format or field within the same scope, or as an encoding method or a constant (since they have global scope).
それぞれメソッドと各定数をコード化するための識別子にはすべて、グローバルな範囲があります。 また、各形式と分野には、識別子があります。 形式と分野識別子の範囲は地方です、グローバルな制御フィールドを除いて。(制御フィールドには、グローバルな範囲があります)。 したがって、形式か分野に、同じ範囲の中の別の形式か分野、コード化メソッドまたは定数と同じ識別子を持っているのは不法です(彼らがグローバルな範囲を持っているので)。
Note that although format names (see Section 4.12.3.1) are considered to be identifiers, they are not referred to in the notation, but are primarily for the benefit of the reader.
形式名ですが、それに注意してください。(.1が)識別子、それらが記法で言及されないのにもかかわらずの、主として読者の利益のためのものであるということであると考えられるセクション4.12.3を見てください。
4.3. Constant Definitions
4.3. 一定の定義
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を見る)によって定数は「=」オペレータの右側で定義されます。 式は恒常価値をもたらさなければなりません。 すなわち、式は用語があるものであるに違いありません。
Finking & Pelletier Standards Track [Page 15] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[15ページ]。
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.
定数には、グローバルな範囲があります。 メソッド定義をコード化しながら、先端でいずれも外で平らな状態で定数を定義しなければなりません。 定数は、彼らが言及する値に完全に同等であり、その値で完全に交換可能です。 定数には、フィールド属性と異なって、すべてのパケットのための同じ値があります。パケットによってフィールド属性は変化するかもしれません。
4.4. Fields
4.4. 分野
Fields are the basic building blocks of a ROHC-FN specification. Fields are the units into which headers are divided. Each field may have two forms: a compressed form and an uncompressed form. Both forms are represented as bits exchanged between the compressor and the decompressor in the same way, as an unsigned string of bits; the most significant bit first.
分野はROHC-FN仕様の基本的なブロックです。 分野はヘッダーが分割されているユニットです。 各分野には、2つのフォームがあるかもしれません: 圧縮形と解凍された用紙。 両方の書式は同様に、コンプレッサーと減圧装置の間で交換されたビットとして表されます、ビットの未署名のストリングとして。 最も重要であるのは最初に、噛み付きました。
The properties of the compressed form of a field are defined by an encoding method and/or "ENFORCE" statements. This entirely characterises the relationship between the uncompressed and compressed forms of that field. This is achieved by specifying the relationships between the field's attributes.
分野の圧縮形の特性は、コード化メソッドで定義される、そして/または、声明を「実施します」。 これはその分野の解凍されて圧縮されたフォームの間の関係を完全に特徴付けます。 これは、フィールドの属性の間の関係を指定することによって、達成されます。
The notation defines four field attributes, two for the uncompressed form and a corresponding two for the compressed form. The attributes available for each field are:
記法は4つのフィールド属性、解凍されたフォームのための2、および圧縮形のための対応する2を定義します。 各分野に利用可能な属性は以下の通りです。
uncompressed attributes of a field:
分野の解凍された属性:
o "UVALUE" and "ULENGTH",
o "UVALUE"と"ULENGTH"
compressed attributes of a field:
分野の圧縮された属性:
o "CVALUE" and "CLENGTH".
o "CVALUE"と"CLENGTH"。
The two value attributes contain the respective numerical values of the field, i.e., "UVALUE" gives the numerical value of the uncompressed form of the field, and the attribute "CVALUE" gives the numerical value of the compressed form of the field. The numerical values are derived by interpreting the bit-string representations of the field as bit strings; the most significant bit first.
2つの値の属性が分野のそれぞれの数値を含んでいます、そして、すなわち、"UVALUE"は分野の解凍されたフォームの数値を与えます、そして、属性"CVALUE"は分野の圧縮形の数値を与えます。 数値はビット列として分野のビット列表現を解釈することによって、引き出されます。 最も重要であるのは最初に、噛み付きました。
The two length attributes indicate the length in bits of the associated bit string; "ULENGTH" for the uncompressed form, and "CLENGTH" for the compressed form.
2つの長さ属性が関連ビット列のビットの長さを示します。 解凍されたフォームのための"ULENGTH"、および圧縮形のための"CLENGTH"。
Finking & Pelletier Standards Track [Page 16] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[16ページ]。
Attributes are undefined unless they are bound to a value, in which case they become defined. If two conflicting bindings are given for a field attribute then the bindings fail along with the (combination of) formats in which those bindings were defined.
それらが値に縛られない場合属性が未定義である、その場合、それらは定義されるようになります。 2つの闘争結合を分野に与えるなら結合が失敗するその時を結果と考えてください、(組み合わせ、)、それらの結合が定義された形式。
Uncompressed attributes do not always reflect an aspect of the uncompressed header. Some fields do not originate from the uncompressed header, but are control fields.
解凍された属性はいつも解凍されたヘッダーの局面を反映するというわけではありません。 いくつかの分野が、解凍されたヘッダーから発しませんが、制御フィールドです。
4.4.1. Attribute References
4.4.1. 属性参照
Attributes of a particular field are formally referred to by using the field's name followed by a "." and the attribute's identifier.
「a」があとに続いたフィールドの名前を使用することによって、特定の分野の属性は正式に言及され」て属性の識別子。
For example:
例えば:
rtp_seq_number.UVALUE
rtp_seq_number.UVALUE
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_ナンバーフィールドの解凍された値を与えます。 属性に参照をつけるプライマリ理由は式における使用のためのものです。(式はセクション4.7で説明されます)。
4.4.2. Representation of Field Values
4.4.2. 分野値の表現
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)」の2進法表示です。
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であるなら、分野の圧縮された表現はバイナリーにおいて255、11111111と等しい「-1%256」が等しい「-1%(2^8)」でしょうに。
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を見てください)、形式(すなわち、コンプレッサーと減圧装置の間で交換されたビット)の表現が上のフォームにあります。
4.5. Grouping of Fields
4.5. 分野の組分け
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.
「圧縮された」分野リストにおける、分野の注文、(.2が)するセクション4.12.1が「解凍された」分野リストにおける、分野の注文と同じである必要はない、(セクション4.12 .1 .1) いろいろなそれらのすべてがコード化されるのをメソッドをコード化するシングルを使用することで許容するために「圧縮された」形式で隣接であることの分野を一緒に分類するのは可能です。 分野のグループはただ一つのフィールド名に代わってすぐ「=: =」の左まで指定されます。
Finking & Pelletier Standards Track [Page 17] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[17ページ]。
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:
グループは、一緒に分類されるために分野のコロンで切り離されたリストを与えることによって、notatedされます。 例えば、解凍されたヘッダーの事実上、ただ一つの一連番号であることの2つの半分である2つの非隣接の分野があるかもしれません:
grouping_example
{
UNCOMPRESSED {
minor_seq_num; // 12 bits
other_field; // 8 bits
major_seq_num; // 4 bits
}
組分け_例、UNCOMPRESSED小さい方の_seq_num; //12ビットの他の_分野; //8ビットの主要な_seq_num;//4ビット
COMPRESSED {
other_field =:= irregular(8);
major_seq_num
: minor_seq_num =:= lsb(3, 0);
}
}
COMPRESSED、他の_分野=: =不規則(8)主要な_seq_num: 小さい方の_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.
最終的に、グループのすべての分野には、結合した分野の長さ属性が対応する長さ属性の合計と等しいです。
4.6. "THIS"
4.6. 「これ」
Within the definition of an encoding method, it is possible to refer to the field (i.e., the group of contiguous bits) the method is encoding, using the keyword "THIS".
コード化メソッドの定義の中では、メソッドがコード化している野原(すなわち、隣接のビットのグループ)について言及するのは可能です、「これ」というキーワードを使用して。
This is useful for gaining access to the attributes of the field being encoded. For example it is often useful to know the total uncompressed length of the uncompressed format that is being encoded:
これはコード化される分野の属性へのアクセスを得ることの役に立ちます。 例えば、合計がコード化されている解凍された形式の長さを解凍したのを知るのはしばしば役に立ちます:
THIS.ULENGTH
THIS.ULENGTH
Finking & Pelletier Standards Track [Page 18] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[18ページ]。
4.7. Expressions
4.7. 式
ROHC-FN includes the usual infix style of expressions, with
parentheses "(" and ")" used for grouping. Expressions can be made
up of any of the components described in the following subsections.
そして、ROHC-FNが括弧がある普通の挿入辞スタイルの式を含んでいる、「(「」、)、」 組分けにおいて、使用されています。 以下の小区分で説明されたコンポーネントのいずれでも式を作ることができます。
The semantics of expressions are generally similar to the expressions in the ANSI-C programming language [C90]. The definitive list of expressions in ROHC-FN follows in the next subsections; the list below provides some examples of the difference between expressions in ANSI-C and expressions in ROHC-FN:
一般に、式の意味論は、言語[C90]をプログラムしながら、ANSI-Cで式と同様です。 ROHC-FNの式の決定的なリストは次の小区分で従います。 以下のリストはANSI-Cの式と式の違いに関するいくつかの例をROHC-FNに供給します:
o There is no limit on the range of integers.
o 限界が全く整数の範囲にありません。
o "x ^ y" evaluates to x raised to the power of y. This has a
precedence higher than *, / and %, but lower than unary - and is
right to left associative.
o 「x^y」はyのパワーに上げられたxに評価します。 これで、先行は単項より*、/、および%より高いのですが、低くなります--そして、左に結合しやすい状態で正しいです。
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.3を見る)とも、そして、メソッドパラメタをコード化することとも分野(セクション4.4で説明されるように)の属性のどれかを呼ぶかもしれません、いずれか範囲にあるなら(セクション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.
式に使用される属性、定数、またはパラメタのどれかが未定義であるなら、式の値は未定義です。 未定義の式は定義された値が必要であるならそれらが失敗するのに使用される環境(例えば、圧縮形式)を引き起こします。 定義された値が圧縮形式に現れる野原のすべての圧縮された属性に必要です。 定義された値は解凍された形式に現れる野原のすべての解凍された属性に必要ではありません。 無限のフィールド属性がこの場合どうなるかを定義するのがプロフィールクリエイターまで達しています。 このような場合には、圧縮プロセスの透明が失われることに注意されるべきです。 すなわち、減圧装置がオリジナルのヘッダーを再生させるのは、可能でないでしょう。
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:
直接完全に分野を特徴付けるというわけではないのでメソッドをコード化するとして式を使用できません。 式はただ一つの値を指定するだけですが、分野はいくつかの値で作られます: その属性。 例えば、以下は不法です:
Finking & Pelletier Standards Track [Page 19] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[19ページ]。
tcp_list_length =:= (data_offset + 20) / 4;
tcp_リスト_の長さ=: =(データ_オフセット+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"属性を定義すると読むことができました。 しかしながら、それはまだ減圧装置で未定義の解凍された分野の長さを残しているでしょう。 したがって、そのような用法は禁止されています。
4.7.1. Integer Literals
4.7.1. 整数リテラル
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.
デシマル値、2進の値("0b"によって前に置かれている)、または16進値("0x"によって前に置かれている)として整数を表すことができます。 負の整数は「-」サインによって前に置かれています。 例えば、「それぞれ値10、10、および-10を持っていて、10インチ、"0b1010"、および"-0x0a"はすべて有効な整数リテラルです」。
4.7.2. Integer Operators
4.7.2. 整数オペレータ
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」は「x」法「y」を返します。 x--y*(x/y)。
4.7.3. Boolean Literals
4.7.3. ブールリテラル
The boolean literals are "false", and "true".
論理演算子リテラルは、「誤ってい」て、「本当です」。
4.7.4. Boolean Operators
4.7.4. 論理演算子
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"のために。 本当に、両方の議論が真であるなら、戻ります。 そうでなければ、虚偽で戻ります。
o ||, for logical "or". Returns true if at least one argument is
true. Returns false otherwise.
o ||, 論理的な“or"のために。 本当に、少なくとも1つの議論が真であるなら、戻ります。 そうでなければ、虚偽で戻ります。
Finking & Pelletier Standards Track [Page 20] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[20ページ]。
o !, for logical "not". Returns true if its argument is false.
Returns false otherwise.
o 論理的な“not"のために。 本当に、議論が誤っているなら、戻ります。 そうでなければ、虚偽で戻ります。
4.7.5. Comparison Operators
4.7.5. 比較オペレータ
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」は本当に戻ります。 そうでなければ、虚偽で戻ります。 xがyと等しくないなら、「x!=y」は本当に戻ります。 そうでなければ、虚偽で戻ります。
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以下であるなら本当に戻ります。 そうでなければ、虚偽で戻ります。 xがyより大きいなら、「x>y」は本当に戻ります。 そうでなければ、虚偽で戻ります。
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以下であるなら虚偽で戻ります。 そうでなければ、本当に、戻ります。 xがyより大きいなら、「x<はyと等しいこと」が虚偽で戻ります。 そうでなければ、本当に、戻ります。
4.8. Comments
4.8. コメント
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ヘッダー形式//-----------------------------------------------------------------
// The following fields are included in all of the IR-REPLICATE
// header formats:
//
UNCOMPRESSED {
discriminator; // 8 bits
tcp_seq_number; // 32 bits
tcp_flags_ecn; // 2 bits
以下の分野が含まれているIR-REPLICATE//ヘッダーが皆、フォーマットする//: //UNCOMPRESSED、弁別器; //8ビットのtcp_seq_番号; //32ビットは_旗_ecnを//2ビットtcpします。
Comments do not affect the formal meaning of what is notated, but can be used to improve readability. Their use is optional.
コメントは何をnotatedされますが、読み易さを改良するのに使用できるかに関する正式な意味に影響しません。 彼らの使用は任意です。
Comments may help to provide clarifications to the reader, and serve different purposes to implementers. Comments should thus not be
コメントは、明確化を読者に提供して、implementersに異なる役割に役立つのを助けるかもしれません。 その結果、コメントがあるべきではありません。
Finking & Pelletier Standards Track [Page 21] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[21ページ]。
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仕様にそれらを挿入するとき、より少ない重要性について考えられます。 それらは仕様の標準の部分と一致しているべきです。
4.9. "ENFORCE" Statements
4.9. 「実施」という声明
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.
「実施」という声明はそれのすべてが形式が成功するように実現しなければならない形式に述部を加える方法を提供します。 「実施」という声明はコード化メソッドといくつかの類似性を共有します。 明確に、コード化メソッドはすぐにいくつかのフィールド属性を縛りますが、「実施」という声明はちょうどそれらの1つを通常縛ります。 事実上、「実施」という声明の収集でコード化メソッドが作成するすべての結合を言い表すことができます。 ここに、「実施」という分野の"UVALUE"属性を5まで縛る例の声明があります。
ENFORCE(field.UVALUE == 5);
(field.UVALUE=5)を実施してください。
An "ENFORCE" statement must only be used inside a field list (see Section 4.12). It attempts to force the expression given to be true for the format that it belongs to.
分野リストの中で「実施」という声明を使用するだけでよいです(セクション4.12を見てください)。 それは、それが属す形式に本当になるように与えられた式を強制するのを試みます。
An abbreviated form of an "ENFORCE" statement is available for binding length attributes using "[" and "]", see Section 4.10.
そして、「実施」という声明の簡略化されたフォームが使用することで拘束力がある長さ属性に利用可能である、「[「」、]、」、セクション4.10を見てください。
Like an encoding method, an "ENFORCE" statement can only be successfully used in a format if the binding it describes is achievable. A format containing the example "ENFORCE" statement above would not be usable if the field had also been bound within that same format with "uncompressed_value" encoding, which gave it a "UVALUE" other than 5.
コード化メソッドのように、それが説明する結合が達成可能である場合にだけ、形式に「実施」という声明を首尾よく使用できます。 また、分野もその同じ形式の中で「解凍された_値」コード化(5を除いた"UVALUE"をそれに与えた)で制限されていたなら、「実施」という上の例の声明を含む形式は使用可能でないでしょう。
An "ENFORCE" statement takes a boolean expression as a parameter. It can be used to assert that the expression is true, in order to choose a particular format from a list of possible formats specified in an encoding method (see Section 4.12), or just to bind an expression as in the example above. The general form of an "ENFORCE" statement is therefore:
「実施」という声明はパラメタとして論理演算子式をみなします。 式が本当であると断言するのにそれを使用できて、可能な形式のリストからの特定の形式は、選ぶために上記の例のようにコード化メソッド(セクション4.12を見る)か、まさしくひもに式を指定しました。 したがって、「実施」という声明の一般的なフォームは以下の通りです。
ENFORCE(<boolean expression>);
ENFORCE(<論理演算子式>)。
There are three possible conditions that the expression may be in:
式が以下にあるかもしれないという3つの可能な条件があります。
1. The boolean expression evaluates to false, in which case the
local scope of the format that contains the "ENFORCE" statement
cannot be used.
1. 論理演算子式は、どれが誤る「実施」を含む形式の地方の範囲をケースに入れるかで声明を使用できないかを評価します。
Finking & Pelletier Standards Track [Page 22] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[22ページ]。
2. The boolean expression evaluates to true, in which case the
binding is created and successful.
2. 式が本当に評価する論理演算子であり、その場合、結合は、作成されていてうまくいっています。
3. The value of the boolean expression is undefined. In this case,
the binding is also created and successful.
3. 論理演算子式の値は未定義です。 この場合、結合は、また、作成されていてうまくいっています。
In all three cases, any undefined term becomes bound by the expression. Generally speaking, an "ENFORCE" statement is either being used as an assignment (condition 3 above) or being used to test if a particular format is usable, as is the case with conditions 1 and 2.
すべての3つの場合では、どんな未定義の用語も式でバウンドになります。 概して、特定の形式が使用可能であるなら、「実施」という声明は、課題(上記の状態3)として使用されるか、またはテストするのに使用されています、状態1と2のケースのように。
4.10. Formal Specification of Field Lengths
4.10. フィールド長に関する形式仕様
In many of the examples each field has been followed by a comment indicating the length of the field. Indicating the length of a field like this is optional, but can be very helpful for the reader. However, whilst useful to the reader, comments have no formal meaning.
例の多くでは、分野の長さを示すコメントは各野原のあとに続きました。 このような分野の長さを示すのは、任意ですが、読者にとって、非常に役立っている場合があります。 しかしながら、読者の役に立つ間、コメントには、どんな正式な意味もありません。
One of the most common uses for "ENFORCE" statements (see Section 4.9) is to explicitly define the length of a field within a header. Using "ENFORCE" statements for this purpose has formal meaning but is not so easy to read. Therefore, an abbreviated form is provided for this use of "ENFORCE", which is both easy to read and has formal meaning.
「実施」という声明(セクション4.9を見る)への最も一般的な用途の1つはヘッダーの中に明らかに分野の長さを定義することです。 「実施」という声明を使用するのは、このために正式な意味を持っていますが、それほど読みにくいです。 したがって、簡略化されたフォームは、ともに読みやすい「実施」のこの使用に提供されて、正式な意味を持っています。
An expression defining the length of a field can be specified in square brackets after the appearance of that field in a format. If the field can take several alternative lengths, then the expressions defining those lengths can be enumerated as a comma separated list within the square brackets. For example:
形式における、その分野の外観の後の角括弧で分野の長さを定義する式は指定できます。 分野がいくつかの代替の長さを取ることができるなら、コンマの切り離されたリストとして角括弧の中でそれらの長さを定義する式は列挙できます。 例えば:
field_1 [ 4 ];
field_2 [ a+b, 2 ];
field_3 =:= lsb(16, 16) [ 26 ];
_1[ 4 ]をさばいてください。 _2[+ b、2]をさばいてください。 _3=をさばいてください: =lsb(16、16)[ 26 ]
The actual length attribute, which is bound by this notation, depends on whether it appears in a "COMPRESSED", "UNCOMPRESSED", or "CONTROL" field list (see Section 4.12.1 and its subsections). In a "COMPRESSED" field list, the field's "CLENGTH" attribute is bound. In "UNCOMPRESSED" and "CONTROL" field lists, the field's "ULENGTH" attribute is bound. Abbreviated "ENFORCE" statements are not allowed in "DEFAULT" sections (see Section 4.12.1.5). Therefore, the above notation would not be allowed to appear in a "DEFAULT" section. However, if the above appeared in an "UNCOMPRESSED" or "CONTROL" section, it would be equivalent to:
実際の長さ属性(この記法で縛られる)は「圧縮され」、「解凍」か「コントロール」の分野リストに現れるかどうかに(セクション4.12.1とその小区分を見てください)よります。 「圧縮された」分野リストでは、フィールドの"CLENGTH"属性は制限されています。 「解凍」と「コントロール」分野リストでは、フィールドの"ULENGTH"属性は制限されています。 セクション4.12を見てください。簡略化された「実施」という声明が「デフォルト」セクションで許されていない、(.1 .5)。 したがって、上の記法は「デフォルト」セクションに現れることができないでしょう。 しかしながら、上記が「解凍」か「コントロール」セクションに現れるなら、以下のことのために同等でしょうに。
Finking & Pelletier Standards Track [Page 23] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[23ページ]。
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);
_1をさばいてください。 (分野_1.ULENGTH=4)を実施してください。 _2をさばいてください。 ENFORCE(分野_2.ULENGTH=2)| | (分野_2.ULENGTH=+b))。 _3=をさばいてください: =lsb(16、16) (分野_3.ULENGTH=26)を実施してください。
A special case exists for fields that have a variable length that the notator does not wish, or is not able to, define using an expression. The keyword "VARIABLE" can be used in the following case:
特別なケースはnotatorが願っていないか、またはできない可変長を持っている分野に存在して、使用を定義してください。式。 以下の場合に「変数」というキーワードを使用できます:
variable_length_field [ VARIABLE ];
可変_長さ_分野[VARIABLE]。
Formally, this provides no restrictions on the field length, but maps onto any positive integer or to a value of zero. It will therefore be necessary to define the length of the field elsewhere (see the final paragraphs of Section 4.12.1.1 and Section 4.12.1.2). This may either be in the notation or in the English text of the profile within which the FN is contained. Within the square brackets, the keyword "VARIABLE" may be used as a term in an expression, just like any other term that normally appears in an expression. For example:
正式に、これは、フィールド長における制限を全く提供しないで、どんな正の整数かゼロの値への地図を提供します。 セクション4.12.1の.1とセクション4.12の最終節を見てください。したがって、ほかの場所で分野の長さを定義するのが必要である、(.1 .2)。 これは記法かFNが含まれているプロフィールに関する英文にあるかもしれません。 角括弧の中では、「変数」というキーワードは用語として式に使用されるかもしれません、まさしく通常、式に現れるいかなる他の用語のようにも。 例えば:
field [ 8 * (5 + VARIABLE) ];
[8*(5+VARIABLE)]をさばいてください。
This defines a field whose length is a whole number of octets and at least 40 bits (5 octets).
これは長さが八重奏の整数である分野と少なくとも40ビット(5つの八重奏)を定義します。
4.11. Library of Encoding Methods
4.11. コード化メソッドの図書館
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を見てください)。
4.11.1. uncompressed_value
4.11.1. 解凍された_値
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:
メソッドをコード化する「解凍された_値」は、数式を使用することで(恒常価値を含んでいて)解凍された値を定義できるヘッダーフィールドをコード化するのに使用されます。 このコード化メソッドは以下の通り定義されます:
Finking & Pelletier Standards Track [Page 24] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[24ページ]。
uncompressed_value(len, val) {
UNCOMPRESSED {
field;
ENFORCE(field.ULENGTH == len);
ENFORCE(field.UVALUE == val);
}
COMPRESSED {
field;
ENFORCE(field.CLENGTH == 0);
}
}
解凍された_値(len、val)UNCOMPRESSED、分野; ENFORCE(field.ULENGTH=len); ENFORCE(field.UVALUE=val);、COMPRESSEDはさばきます; 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ヘッダーバージョン番号はいつも値6を持っている4ビットの分野です:
version =:= uncompressed_value(4, 6);
バージョン=: =は_値(4、6)を解凍しました。
Here is another example of value encoding, using an expression to calculate the length:
ここに、長さについて計算するのに式を使用して、値のコード化に関する別の例はあります:
padding =:= uncompressed_value(nbits - 8, 0);
=を水増しします: =は_値(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を見てください。
4.11.2. compressed_value
4.11.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);
}
}
圧縮された_値(len、val)UNCOMPRESSED分野; ENFORCE(field.ULENGTH=0);COMPRESSED、分野; ENFORCE(field.CLENGTH=len); ENFORCE(field.CVALUE=val)。
Finking & Pelletier Standards Track [Page 25] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[25ページ]。
One possible use of this encoding method is to define padding in a compressed format:
これのメソッドをコード化する1つの活用可能性は圧縮形式で詰め物を定義することです:
pad_to_octet_boundary =:= compressed_value(3, 0);
_八重奏_境界=へのパッド_: =は_値(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を見てください)ことです。 便宜のために、記法は2進のストリングの形における「圧縮された_値」コード化を指定するための構文を提供します。 シングル・クォーテション・マークで単にコード化されるべき2進のストリングを与えます。 ビットの数がストリングにある状態で、分野の"CLENGTH"属性は付きます、"CVALUE"属性はストリングで値を与えていて付きますが。 例えば:
discriminator =:= '01101';
弁別器=: ='01101'。
This has exactly the same meaning as:
これには、まさに以下と同じ意味があります。
discriminator =:= compressed_value(5, 13);
弁別器=: =は_値(5、13)を圧縮しました。
4.11.3. irregular
4.11.3. 不規則です。
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);
}
}
不規則(len)UNCOMPRESSED分野; ENFORCE(field.ULENGTH=len);COMPRESSED、分野; 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ヘッダーのチェックサム分野はどんな予測できる1個のヘッダーから別のヘッダーまでのパターンにも従わない16ビットの分野(したがって、それを圧縮できない)です:
tcp_checksum =:= irregular(16);
tcp_チェックサム=: =不規則(16)。
Note that the length does not have to be constant, for example, an expression can be used to derive the length of the field from the value of another field.
長さが一定である必要はないというメモ、例えば、別の分野の値から分野の長さを得るのに式を使用できます。
Finking & Pelletier Standards Track [Page 26] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[26ページ]。
4.11.4. static
4.11.4. 静電気
The "static" encoding method compresses a field whose length and value are the same as for a previous header in the flow, i.e., where the field completely matches an existing entry in the context:
メソッドをコード化する「静電気」はすなわち長さと値が前のヘッダーのように分野が文脈における既存のエントリーに完全に合っているところで流れで同じである分野を圧縮します:
field =:= static;
=をさばいてください: =静電気
The field's "UVALUE" and "ULENGTH" attributes bind with their respective values in the context and the "CLENGTH" attribute is bound to zero.
それらのそれぞれの値が文脈にある状態で、フィールドの"UVALUE"と"ULENGTH"属性は付きます、そして、"CLENGTH"属性はゼロまで縛られます。
Since the field value is the same as a previous field value, the entire field can be reconstructed from the context, so it is compressed to zero bits and does not appear in the compressed format.
以来、分野値は前の分野値、文脈から全体の分野を再建できるので、ビットのゼロを合わせるために圧縮されて、圧縮形式に現れないのと同じです。
For example, the source port of the TCP header is a field whose value does not change from one packet to the next for a given flow:
例えば、TCPヘッダーのソースポートは値が与えられた流れのために1つのパケットから次に変化しない分野です:
src_port =:= static;
src_ポート=: =静電気。
4.11.5. lsb
4.11.5. lsb
The least significant bits encoding method, "lsb", compresses a field whose value differs by a small amount from the value stored in the context. The least significant bits of the field value are transmitted instead of the original field value.
メソッドをコード化する最下位ビット、"lsb"は少量に従って値が文脈に保存された値と異なる分野を圧縮します。 分野価値の最下位ビットは元の分野値の代わりに伝えられます。
field =:= lsb(<num_lsbs_param>, <offset_param>);
=をさばいてください: =lsb(<num_lsbs_param>、<は_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」は使用する最下位ビットの数です、そして、「オフセット_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"属性(最下位ビットが"CVALUE"属性に合っている間隔中に値への"UVALUE"属性ひも)で付きます。 文脈に保存された情報から"ULENGTH"の値を得ることができます。
For example, the TCP sequence number:
例えば、TCP一連番号:
tcp_sequence_number =:= lsb(14, 8192);
tcp_系列_番号=: =lsb(14、8192)。
This takes up 14 bits, and can communicate any value that is between 8192 lower than the value of the field stored in context and 8191 above it.
これは、14ビットを取って、それが状況内において保存された分野の値とそれの上の8191年より8192低くいるどんな値も伝えることができます。
Finking & Pelletier Standards Track [Page 27] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[27ページ]。
The interpretation interval can be described as a function of a value stored in the context, ref_value, and of num_lsbs_param:
文脈に保存された値、審判_価値とnum_lsbs_paramの機能として解釈間隔を記述できます:
f(context_value, num_lsbs_param) = [ref_value - offset_param,
ref_value + (2^num_lsbs_param - 1) - offset_param]
f(文脈_価値、num_lsbs_param)=[審判_値--オフセット_param、審判_値の+(2^num_lsbs_param--1)--オフセット_param]
where offset_param is an integer.
_オフセットであるところでは、paramが整数です。
<-- interpretation interval (size is 2^num_lsbs_param) -->
|---------------------------+----------------------------|
lower ref_value upper
bound bound
<--解釈間隔(サイズは2^num_lsbs_paramである)-->。|---------------------------+----------------------------| 下側の審判_値の上限バウンド
where:
どこ:
lower bound = ref_value - offset_param
upper bound = ref_value + (2^num_lsbs_param-1) - offset_param
下界は審判_値と等しいです--+ _param上限=審判_価値の(2^num_lsbs_param-1)を相殺してください--_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"は値が下側と上限の間に解釈間隔を包括的に横たわらせる分野を圧縮できます。 特定の、そして、オフセットの_param=0では、分野値は、そして、基準値審判_値に比例して同じままである、または増加できるだけです。 相殺されるなら、_paramは-1と等しく、_相殺されるなら、paramは2^num_lsbs_paramと等しいのですが、次に、増加できるだけであって、次に、それは減少できるだけです。
The compressed field takes up the specified number of bits in the compressed format (i.e., num_lsbs_param).
圧縮された分野は圧縮形式(すなわち、num_lsbs_param)のビットの指定された数を取ります。
The compressor may not be able to determine the exact reference value stored in the decompressor context and that will be used by the decompressor, since some packets that would have updated the context may have been lost or damaged. However, from feedback received or by making assumptions, the compressor can limit the candidate set of values. The compressor can then select a format that uses "lsb" encoding, defined with suitable values for its parameters num_lsbs_param and offset_param, such that no matter which context value in the candidate set the decompressor uses, the resulting decompression is correct. If that is not possible, the "lsb" encoding method fails (which typically results in a less efficient compressed format being chosen by the compressor). How the compressor determines what reference values it stores and maintains in its set of candidate references is outside the scope of the notation.
コンプレッサーは減圧装置によって使用される減圧装置文脈に保存された正確な基準値を決定できないかもしれません、文脈をアップデートしたいくつかのパケットが失われたか、または破損したかもしれないので。 しかしながら、受け取るか、作成仮定によるフィードバックから、コンプレッサーは値の候補セットを制限できます。 コンプレッサーは、次に、パラメタnum_lsbs_paramのために適当な値で定義された"lsb"コード化を使用する形式を選択して、_paramを相殺できます、結果として起こる減圧が減圧装置が使用する候補セットにおける文脈値がどれであっても、正しいように。 それが可能でないなら、メソッドをコード化する"lsb"は失敗します(コンプレッサーによって選ばれているそれほど効率的でない圧縮形式を通常もたらします)。 記法の範囲の外にコンプレッサーが、それが候補参照のセットでどんな基準値を保存して、維持するかをどう決定するかがあります。
Finking & Pelletier Standards Track [Page 28] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[28ページ]。
4.11.6. crc
4.11.6. crc
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"は1ブロックのデータに関して計算された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>);
=をさばいてください: =crc(<num_ビット>、<ビット_パターン>、<の初期の_価値の>、<ブロック_データ_は>、<ブロック_データ_の長さの>を評価します)
When specifying the bit pattern for the polynomial, each bit represents the coefficient for the corresponding term in the polynomial. Note that the highest order term is always present (by definition) and therefore does not need specifying in the bit pattern. Therefore, a CRC polynomial with n terms in it is represented by a bit pattern with n-1 bits set.
多項式にビット・パターンを指定するとき、各ビットは多項式による対応する用語のための係数を表します。 最も高いオーダー用語がいつも存在していて(定義上)、したがって、ビット・パターンで指定する必要はないことに注意してください。 したがって、中にn用語があるそれが表されるCRC多項式は少しビットが設定するn-1で模様をつけます。
The CRC is calculated in least significant bit (LSB) order.
CRCは最下位ビット(LSB)オーダーで計算されます。
For example:
例えば:
// 3 bit CRC, C(x) = x^0 + x^1 + x^3
crc_field =:= crc(3, 0x6, 0xF, THIS.CVALUE, THIS.CLENGTH);
//3ビットのCRC、C(x)はx^0+x^1+x^3crc_分野=と等しいです: crc(3、0×6、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.
"crc"コード化を使用するとき、上で示されるとしての「これ」キーワード(セクション4.6を見る)の用法は典型的です。 例えば、全体のヘッダーにコード化メソッドで使用されると、それで、ヘッダーのすべての分野に関してCRCについて計算します。
4.12. Definition of Encoding Methods
4.12. コード化メソッドの定義
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
コード化メソッドは、名前を持っていて、パラメタを持っているかもしれません。 いかなる他のも同様に、また、ライブラリからメソッドをコード化しながら、それらを使用できます。
Finking & Pelletier Standards Track [Page 29] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[29ページ]。
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.
このセクションは、メソッドをコード化しながら、新しい状態で定義するのにおいて中古の様々な特徴について説明します。
4.12.1. Structure
4.12.1. 構造
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
}
_メソッドをコード化する_を合成してください、UNCOMPRESSED分野_1; //4ビット分野_2; //12ビット
COMPRESSED {
field_2 =:= uncompressed_value(12, 9); // 0 bits
field_1 =:= irregular(4); // 4 bits
}
}
COMPRESSEDは_2=: _値(12、9); //0ビット分野_1=: =不規則(4); //4ビット解凍された=をさばきます。
The above begins with the new method's identifier,
"compound_encoding_method". The definition of the method then
follows inside curly brackets, "{" and "}". The first item in the
definition is the "UNCOMPRESSED" field list, which gives the order of
the fields in the uncompressed format. This is followed by the
compressed format field list ("COMPRESSED"). This list gives the
order of fields in the compressed format and also gives the encoding
method for each field.
上記は新しいメソッドの識別子、「_メソッドをコード化する合成_」で始まります。 そして、次に、メソッドの定義がブレースで続く、「「」、」 定義における最初の項目は「解凍された」分野リストです。(そのリストは解凍された形式における、分野の注文を与えます)。 圧縮形式分野リスト(「圧縮される」)はこれのあとに続いています。 このリストは、圧縮形式における、分野の注文を与えて、また、コード化メソッドを各分野に与えます。
In the example, both the formats list each field exactly once. However, sometimes it is necessary to specify more than one binding for a given field, which means it appears more than once in the field list. In this case, it is the first occurrence of the field in the list that indicates its position in the field order. The subsequent occurrences of the field only specify binding information, not field order information.
例では、両方の形式はまさに一度各分野を記載します。 しかしながら、時々、1つ以上を指定するのが、与えられた分野(それが分野リストで一度より多く見えることを意味する)で付きながら、必要です。 この場合、それは分野オーダーにおける位置を示すリストで、分野の最初の発生です。 分野のその後の発生は分野オーダー情報ではなく、拘束力がある情報を指定するだけです。
The different components of this example are described in more detail below. Other components that can be used in the definition of encoding methods are also defined thereafter.
この例の異なった成分はさらに詳細に以下で説明されます。 また、コード化メソッドの定義に使用できる他のコンポーネントはその後、定義されます。
Finking & Pelletier Standards Track [Page 30] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[30ページ]。
4.12.1.1. Uncompressed Format - "UNCOMPRESSED"
4.12.1.1. 解凍された形式--「解凍されます」。
The uncompressed field list is defined by "UNCOMPRESSED", which specifies the fields of the uncompressed format in the order that they appear in the uncompressed header. The sum of the lengths of each individual uncompressed field in the list must be equal to the length of the field being encoded. Finally, the representation of the uncompressed format described using the list of fields in the "UNCOMPRESSED" section, for which compressed formats are being defined, always consists of one single contiguous block of bits.
解凍された分野リストは「解凍されること」によって定義されます(それらが解凍されたヘッダーで見えるオーダーにおける解凍された形式の分野を指定します)。 リストのそれぞれの個々の解凍された分野の長さはコード化される分野の長さと等しいに違いありません。 最終的に、「解凍された」セクションで分野のリストを使用することで説明された解凍された形式の表現は1つの単一の隣接のブロックのビットからいつも成ります。(圧縮形式は形式において定義されています)。
In the example above in Section 4.12.1, the uncompressed field list is "field_1", followed by "field_2". This means that a field being encoded by this method is divided into two subfields, "field_1" and "field_2". The total uncompressed length of these two fields therefore equals the length of the field being encoded:
解凍された分野リストがセクション4.12.1における上記の例では、そうである、「_1インチをさばいてください、続いて、「分野_2インチ」をさばきます。 これが、このメソッドでコード化される分野が2つの部分体に分割されることを意味する、「_1インチと「分野_2インチ」をさばいてください。 したがって、これらの2つの分野の総解凍された長さはコード化される分野の長さと等しいです:
field_1.ULENGTH + field_2.ULENGTH == THIS.ULENGTH
分野_1.ULENGTH+分野_2.ULENGTH=THIS.ULENGTH
In the example, there are only two fields, but any number of fields may be used. This relationship applies to however many fields are actually used. Any arrangement of fields that efficiently describes the content of the uncompressed header may be chosen -- this need not be the same as the one described in the specifications for the protocol header being compressed.
例には、2つの分野しかありませんが、いろいろな分野が使用されるかもしれません。 多くの分野が実際にどのように使用されても、この関係は、申し込みます。 効率的に解凍されたヘッダーの内容について説明する分野のどんなアレンジメントも選ばれるかもしれません--これは圧縮されていて、プロトコルヘッダーのために仕様で説明されたものと同じである必要はありません。
For example, there may be a protocol whose header contains a 16-bit sequence number, but whose sessions tend to be short-lived. This would mean that the high bits of the sequence number are almost always constant. The "UNCOMPRESSED" format could reflect this by splitting the original uncompressed field into two fields, one field to represent the almost-always-zero part of the sequence number, and a second field to represent the salient part.
例えば、ヘッダーが16ビットの一連番号を含みますが、セッションが短命である傾向があるプロトコルがあるかもしれません。 これは、一連番号の高いビットがほとんどいつも一定であることを意味するでしょう。 「解凍された」形式は元の解凍された分野を2つの分野に分けることによって、これを反映するかもしれません、表す1つの分野、ほとんどいつもゼロ、一連番号の一部、および顕著な部分を表す2番目の分野。
An "UNCOMPRESSED" field list may specify encoding methods in the same way as the "COMPRESSED" field list in the example. Encoding methods specified therein are used whenever a packet with that uncompressed format is being encoded. The encoding of a packet with a given uncompressed format can only succeed if all of its encoding methods and "ENFORCE" statements succeed (see Section 4.9).
「解凍された」分野リストは、例の「圧縮された」分野リストと同様に、メソッドをコード化しながら、指定するかもしれません。 その解凍された形式があるパケットがコード化されているときはいつも、そこに指定されたコード化メソッドは使用されています。 メソッドと「実施」という声明をコード化するすべてが成功する場合にだけ(セクション4.9を見てください)、与えられた解凍された形式があるパケットのコード化は成功できます。
The total length of each uncompressed format must always be defined. The length of each of the fields in an uncompressed format must also be defined. This means that the bindings in the "UNCOMPRESSED", "COMPRESSED" (see Section 4.12.1.2 below), "CONTROL" (see Section 4.12.1.3 below), "INITIAL" (see Section 4.12.1.4 below), and "DEFAULT" (see Section 4.12.1.5 below) field lists must, between them, define the "ULENGTH" attribute of every field in an
いつもそれぞれの解凍された形式の全長を定義しなければなりません。 また、解凍された形式のそれぞれの分野の長さを定義しなければなりません。 これが「解凍」での結合、その「圧縮であったこと」を意味する、(見る、セクション4.12 .1 .2 )、以下に「制御してください」、(見る、セクション4.12 .1 .3 )、以下に「イニシャル」、(見る、セクション4.12 .1 .4 )、以下に「デフォルトとしてください」、(.5下) 分野が記載するセクション4.12.1が中でそれらの間であらゆる分野の"ULENGTH"属性を定義しなければならないのを確実にしてください。
Finking & Pelletier Standards Track [Page 31] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[31ページ]。
uncompressed format so that there is an unambiguous mapping from the bits in the uncompressed format to the fields listed in the "UNCOMPRESSED" field list.
解凍された形式のビットから「解凍された」分野リストに記載された分野まで明白なマッピングがあるように、形式を解凍しました。
4.12.1.2. Compressed Format - "COMPRESSED"
4.12.1.2. 圧縮形式--「圧縮されます」。
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ビットを取る」コード化。 「分野_2インチが分野には一定の価値があることを意味する「解凍された_値」であるので、ビットのゼロを合わせるのが圧縮できる」ようにコード化。 それが取る値は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:
「分野_2インチ、長さにおけるゼロ・ビットへのどの湿布、リストの彼らの見解が重要でないので圧縮形式を変えないで、分野リストでどこでも現れるかもしれないか」のような分野。 事実上、この分野へのコード化メソッドがほかの場所(例えば「解凍された」セクションで)で定義されるなら、全体で「圧縮された」セクションからこの分野を省略できるでしょうに:
compound_encoding_method
{
UNCOMPRESSED {
field_1; // 4 bits
field_2 =:= uncompressed_value(12, 9); // 12 bits
}
_メソッドをコード化する_を合成してください、UNCOMPRESSED_1をさばいてください; //4ビットは_2=をさばきます: =は_値(12、9)を//12ビット解凍しました。
COMPRESSED {
field_1 =:= irregular(4); // 4 bits
}
}
COMPRESSEDは_1=: =不規則(4)を//4ビットさばきます。
Finking & Pelletier Standards Track [Page 32] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[32ページ]。
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.
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. Control Fields - "CONTROL"
4.12.1.3. Control Fields - "CONTROL"
Control fields are defined using the "CONTROL" field list. The control field list specifies all fields that do not appear in the uncompressed format, but that have an uncompressed value (specifically those with an "ULENGTH" greater than zero). Such fields may be used to help compress fields from the uncompressed format more efficiently. A control field could be used to improve efficiency by representing some commonality between a number of the uncompressed fields, or by representing some information about the flow that is not explicitly contained in the protocol headers.
Control 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.
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.
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.
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:
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:
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
Finking & Pelletier Standards Track [Page 33] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 33] RFC 4997 ROHC-FN July 2007
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
:
:
CONTROL { ip_id_behavior; // 1 bit : :
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.
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.
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:
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.
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.
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.
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.
Finking & Pelletier Standards Track [Page 34] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 34] RFC 4997 ROHC-FN July 2007
4.12.1.4. Initial Values - "INITIAL"
4.12.1.4. Initial Values - "INITIAL"
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:
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:
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.
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.
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.
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.
4.12.1.5. Default Field Bindings - "DEFAULT"
4.12.1.5. Default Field Bindings - "DEFAULT"
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).
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).
Default bindings are optional and may be given for any combination of fields and attributes which are in scope.
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.
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:
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);
Finking & Pelletier Standards Track [Page 35] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 35] RFC 4997 ROHC-FN July 2007
}
}
Here default bindings are specified for fields 1 to 3. A default binding for the "ULENGTH" attribute of field_4 is also specified.
Here default bindings are specified for fields 1 to 3. A default binding for the "ULENGTH" attribute of field_4 is also specified.
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.
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.
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.
The "DEFAULT" field list may contain default bindings for individual attributes by using "ENFORCE" statements. A default binding for an individual attribute will only be used if elsewhere there is no binding given for that attribute or the field to which it belongs. If elsewhere there is an "ENFORCE" statement binding that attribute, or an encoding method binding the field to which it belongs, the default binding for the attribute will not be used. This applies even if the specified encoding method does not bind the particular attribute given in the "DEFAULT" section. However, an "ENFORCE" statement elsewhere that only binds the length of the field still allows the default bindings to be used, except for default "ENFORCE" statements which bind nothing but the field's length.
To clarify, assuming the default bindings given in the example above, the first three of the following four compressed formats would not use the default binding for "field_4.ULENGTH":
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":
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 }
Finking & Pelletier Standards Track [Page 36] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 36] RFC 4997 ROHC-FN July 2007
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".
The fourth format is the only one that uses the default binding for "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.
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.
4.12.2. Arguments
4.12.2. Arguments
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.
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:
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.
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.
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.
Finking & Pelletier Standards Track [Page 37] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 37] RFC 4997 ROHC-FN July 2007
For example:
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".
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".
4.12.3. Multiple Formats
4.12.3. Multiple Formats
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.
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.
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.
This is the topic of the following sub-sections.
This is the topic of the following sub-sections.
4.12.3.1. Naming Convention
4.12.3.1. Naming Convention
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.
When compressed formats are defined, they must be defined using the reserved word "COMPRESSED". Similarly, uncompressed formats must be defined using the reserved word "UNCOMPRESSED". After each of these keywords, a name may be given for the format. If no name is given to the format, the name of the format is empty.
Format names, except for the case where the name is empty, follow the syntactic rules of identifiers as described in Section 4.2.
Format names, except for the case where the name is empty, follow the syntactic rules of identifiers as described in Section 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.
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.
Finking & Pelletier Standards Track [Page 38] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 38] RFC 4997 ROHC-FN July 2007
4.12.3.2. Format Discrimination
4.12.3.2. Format Discrimination
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.
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.
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.
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.
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).
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.12.3.3. Example of Multiple Formats
4.12.3.3. Example of Multiple Formats
Putting this all together, here is a complete example of the definition of an encoding method with multiple compressed formats:
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); }
Finking & Pelletier Standards Track [Page 39] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 39] RFC 4997 ROHC-FN July 2007
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:
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" 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" 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" 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_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" 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 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 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 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 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.
4.13. Profile-Specific Encoding Methods
4.13. Profile-Specific Encoding Methods
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.
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.
These methods are specific to the properties of the protocol being compressed and will thus have to be defined within the profile
These methods are specific to the properties of the protocol being compressed and will thus have to be defined within the profile
Finking & Pelletier Standards Track [Page 40] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 40] RFC 4997 ROHC-FN July 2007
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.
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.
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.
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:
For example:
inferred_ip_v4_header_checksum "defined in RFCxxxx Section 6.4.1";
inferred_ip_v4_header_checksum "defined in RFCxxxx Section 6.4.1";
5. Security Considerations
5. Security Considerations
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).
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).
6. Contributors
6. Contributors
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 did much of the foundational work on the formal notation. He authored the initial document describing a formal notation on which this document is based.
Kristofer Sandlund contributed to this work by applying new ideas to the ROHC-TCP profile, by providing feedback, and by helping resolve different issues during the entire development of the notation.
Kristofer Sandlund 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.
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 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.
7. Acknowledgements
7. Acknowledgements
A number of important concepts and ideas have been borrowed from ROHC [RFC3095].
A number of important concepts and ideas have been borrowed from 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.
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.
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
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
Finking & Pelletier Standards Track [Page 41] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 41] RFC 4997 ROHC-FN July 2007
authors would also like to thank Christian Schmidt, Qian Zhang, Hongbin Liao, and Max Riegel for their comments and valuable input.
authors would also like to thank Christian Schmidt, Qian Zhang, Hongbin Liao, and Max Riegel for their comments and valuable input.
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.
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.
8. References
8. References
8.1. Normative References
8.1. Normative References
[C90] ISO/IEC, "ISO/IEC 9899:1990 Information technology --
Programming Language C", ISO 9899:1990, April 1990.
[C90] ISO/IEC, "ISO/IEC 9899:1990 Information technology -- Programming Language C", ISO 9899:1990, April 1990.
[RFC2822] Resnick, P., Ed., "STANDARD FOR THE FORMAT OF ARPA
INTERNET TEXT MESSAGES", RFC 2822, April 2001.
[RFC2822] Resnick, P., Ed., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", RFC 2822, April 2001.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[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., and K. Sandlund, "The RObust Header Compression (ROHC) Framework", RFC 4995, July 2007.
8.2. Informative References
8.2. Informative References
[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., 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.
[RFC791] University of Southern California, "DARPA INTERNET PROGRAM
PROTOCOL SPECIFICATION", RFC 791, September 1981.
[RFC791] University of Southern California, "DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", RFC 791, September 1981.
Finking & Pelletier Standards Track [Page 42] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 42] RFC 4997 ROHC-FN July 2007
Appendix A. Formal Syntax of ROHC-FN
Appendix A. Formal Syntax of ROHC-FN
This section gives a definition of the syntax of ROHC-FN in ABNF [RFC4234], using "fnspec" as the start rule.
This section gives a definition of the syntax of ROHC-FN in ABNF [RFC4234], using "fnspec" as the start rule.
; 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
Finking & Pelletier Standards Track [Page 43] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 43] RFC 4997 ROHC-FN July 2007
; 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
Finking & Pelletier Standards Track [Page 44] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 44] RFC 4997 ROHC-FN July 2007
Appendix B. Bit-level Worked Example
Appendix B. Bit-level Worked Example
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.
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.
B.1. Example Packet Format
B.1. Example Packet Format
Our imaginary header is just 16 bits long, and consists of the following fields:
Our imaginary header is just 16 bits long, and consists of the following fields:
1. version number -- 2 bits
1. version number -- 2 bits
2. type -- 2 bits
2. type -- 2 bits
3. flow id -- 4 bits
3. flow id -- 4 bits
4. sequence number -- 4 bits
4. sequence number -- 4 bits
5. flag bits -- 4 bits
5. flag bits -- 4 bits
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.
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.
Here is an ASCII box notation diagram of the imaginary header:
Here is an ASCII box notation diagram of the imaginary header:
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 | +---+---+---+---+---+---+---+---+
Finking & Pelletier Standards Track [Page 45] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 45] RFC 4997 ROHC-FN July 2007
B.2. Initial Encoding
B.2. Initial Encoding
An initial definition based solely on the above information is as follows:
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:
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
Uncompressed header: 0101000100010000 Compressed header: 0101000100010000
This is because we have stated that all fields are "irregular" -- i.e., we haven't specified anything about their behaviour.
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:
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); }
Finking & Pelletier Standards Track [Page 46] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 46] RFC 4997 ROHC-FN July 2007
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 ]; } }
B.3. Basic Compression
B.3. Basic Compression
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:
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. version number -- indicates which version of the protocol this is: always one for this version of the protocol.
2. type -- may take any value.
2. type -- may take any value.
3. flow id -- may take any value.
3. flow id -- may take any value.
4. sequence number -- make take any value.
4. sequence number -- make take any value.
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. 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).
We could notate this knowledge as follows:
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 ];
Finking & Pelletier Standards Track [Page 47] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 47] RFC 4997 ROHC-FN July 2007
}
}
} }
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).
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).
Using this new encoding on the above header, we get:
Using this new encoding on the above header, we get:
Uncompressed header: 0101000100010000
Compressed header: 0100010001000
Uncompressed header: 0101000100010000 Compressed header: 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:
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:
Uncompressed header: 0101000100010000
Compressed header: 0100010001000
Uncompressed header: 0101000100010000 Compressed header: 0100010001000
Uncompressed header: 0101000101000000
Compressed header: 0100010100000
Uncompressed header: 0101000101000000 Compressed header: 0100010100000
Uncompressed header: 0110000101110000
Compressed header: 1000010111000
Uncompressed header: 0110000101110000 Compressed header: 1000010111000
B.4. Inter-Packet Compression
B.4. Inter-Packet Compression
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:
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:
o the sequence number is unusual -- it increases by three each time,
o the sequence number is unusual -- it increases by three each time,
o the flow_id stays the same -- it always has the same value that it
did in the previous header in the flow,
o the flow_id stays the same -- it always has the same value that it did in the previous header in the flow,
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 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.
Finking & Pelletier Standards Track [Page 48] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 48] RFC 4997 ROHC-FN July 2007
An obvious way of notating this is as follows:
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.
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.
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.
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.
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
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
Finking & Pelletier Standards Track [Page 49] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 49] RFC 4997 ROHC-FN July 2007
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.
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.
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.
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.5. Specifying Initial Values
B.5. Specifying Initial Values
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:
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:
// 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); }
Finking & Pelletier Standards Track [Page 50] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 50] RFC 4997 ROHC-FN July 2007
}
}
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.
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.
B.6. Multiple Packet Formats
B.6. Multiple Packet Formats
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.
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.
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 ];
Finking & Pelletier Standards Track [Page 51] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 51] RFC 4997 ROHC-FN July 2007
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.
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.
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.
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:
Using the above notation, we now get:
Uncompressed header: 0101000100010000
Compressed header: 00100010001000
Uncompressed header: 0101000100010000 Compressed header: 00100010001000
Uncompressed header: 0101000101000000
Compressed header: 10100 ; 00100010100000
Uncompressed header: 0101000101000000 Compressed header: 10100 ; 00100010100000
Uncompressed header: 0110000101110000
Compressed header: 11011 ; 01000010111000
Uncompressed header: 0110000101110000 Compressed header: 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".
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".
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
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
Finking & Pelletier Standards Track [Page 52] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 52] RFC 4997 ROHC-FN July 2007
probably wouldn't assume on the second packet that the decompressor had available the context necessary to decompress the shorter "compressed_format" form.
probably wouldn't assume on the second packet that the decompressor had available the context necessary to decompress the shorter "compressed_format" form.
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.
Finally, note that the fields whose encoding methods are specified in the uncompressed format have zero length when compressed. This means their position in the compressed format is not significant. In this case, there is no need to notate them when defining the compressed formats. In the next part of the example we will see that they have been removed from the compressed formats altogether.
B.7. Variable Length Discriminators
B.7. Variable Length Discriminators
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.
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.
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.
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.
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.
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.
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.
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.
Finking & Pelletier Standards Track [Page 53] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 53] RFC 4997 ROHC-FN July 2007
This gives us the following:
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:
Here is some example output:
Uncompressed header: 0101000100010000
Compressed header: 000100010001000
Uncompressed header: 0101000100010000 Compressed header: 000100010001000
Uncompressed header: 0101000101000000
Compressed header: 10100 ; 000100010100000
Uncompressed header: 0101000101000000 Compressed header: 10100 ; 000100010100000
Finking & Pelletier Standards Track [Page 54] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 54] RFC 4997 ROHC-FN July 2007
Uncompressed header: 0110000101110000
Compressed header: 11011 ; 001000010111000
Uncompressed header: 0110000101110000 Compressed header: 11011 ; 001000010111000
Uncompressed header: 0111000110101110
Compressed header: 011110 ; 001100011010111
Uncompressed header: 0111000110101110 Compressed header: 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.
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.
B.8. Default Encoding
B.8. Default Encoding
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.
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:
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;
Finking & Pelletier Standards Track [Page 55] RFC 4997 ROHC-FN July 2007
Finking & Pelletier Standards Track [Page 55] RFC 4997 ROHC-FN July 2007
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).
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).
B.9. Control Fields
B.9. Control Fields
One inefficiency in the compression scheme we have produced thus far is that it uses two bits to provide the "lsb" encoded sequence number with robustness for the loss of just one packet. In theory, only one bit should be needed. The root of the problem is the unusual sequence number that the protocol uses -- it counts up in increments of three. In order to encode it at maximum efficiency we need to translate this into a field that increments by one each time. We do this using a control field.
私たちがこれまでのところ作成した圧縮技術における1つの非能率はちょうど1つのパケットの損失で"lsb"コード化された一連番号に丈夫さを提供するのに2ビットを使用するということです。 1ビットだけが必要であるべきです。 問題の本質はプロトコルが使用する珍しい一連番号です--それは3の増分で数えられます。 最高効率でそれをコード化するために、私たちは、各回を1つ増加する分野にこれを翻訳する必要があります。 私たちは、制御フィールドを使用することでこれをします。
Finking & Pelletier Standards Track [Page 56] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[56ページ]。
A control field is extra data that is communicated in the compressed format, but which is not a direct encoding of part of the uncompressed header. Control fields can be used to communicate extra information in the compressed format, that allows other fields to be compressed more efficiently.
制御フィールドは圧縮形式でコミュニケートしますが、解凍されたヘッダーの一部のダイレクトコード化でない余分なデータです。 圧縮形式のその他の情報を伝えるのに制御フィールドを使用できて、それは、他の分野が、より効率的に圧縮されるのを許容します。
The control field that we introduce scales the sequence number down by a factor of three. Instead of encoding the original sequence number in the compressed packet, we encode the scaled sequence number, allowing us to have robustness to the loss of one packet by using just one bit of "lsb" encoding:
私たちが導入する制御フィールドは3の要素で一連番号を縮小させます。 圧縮されたパケットで元の一連番号をコード化することの代わりに、私たちはスケーリングされた一連番号をコード化します、私たちが"lsb"コード化のちょうど1ビットを使用することによって1つのパケットの損失に丈夫さを持っているのを許容して:
eg_header
{
UNCOMPRESSED {
version_no =:= uncompressed_value(2, 1) [ 2 ];
type [ 2 ];
flow_id [ 4 ];
sequence_no [ 4 ];
abc_flag_bits [ 3 ];
reserved_flag =:= uncompressed_value(1, 0) [ 1 ];
}
eg_ヘッダー、UNCOMPRESSED: バージョン_いいえ、==は_値(2、1)の[ 2 ]を解凍しました; タイプ[ 2 ]; 流れ_イド[ 4 ];系列_ノー[ 4 ]; abc_旗の_ビット[ 3 ];は_旗=を予約しました: =は_値(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);
}
コントロール計算する正しく比例する//必要性法数学、4ビットへの//支払われるべきものはスケーリングされた_seqに_[ 4 ]を全く巻きつけません; ENFORCE(系列_No.UVALUE=(スケーリングされた_seq_No.UVALUE*3)%16)
DEFAULT {
type =:= irregular(2);
flow_id =:= static;
scaled_seq_no =:= lsb(1, -1);
}
デフォルト=をタイプしてください: =: ==不規則(2); 流れ_イド=: =静電気; スケーリングされた_seq_ノー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の不規則な_形式弁別器=: = '00'[ 2 ]; [ 2 ] ; 流れ_イド=: =不規則(4)[ 4 ];スケーリングされた_seq_ノー=: =不規則(4)[ 4 ]をタイプしてください; //はデフォルトabc_旗の_ビット=をくつがえします: =不規則(3)[ 3 ]
COMPRESSED flags_set {
discriminator =:= '01' [ 2 ];
type [ 2 ];
_が設定したCOMPRESSED旗、弁別器=: ='01'[ 2 ]; タイプ[ 2 ]。
Finking & Pelletier Standards Track [Page 57] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[57ページ]。
scaled_seq_no [ 1 ]; // Uses default
abc_flag_bits =:= uncompressed_value(3, 7);
}
スケーリングされた_は_[ 1 ]を全くseqしません。 //はデフォルトabc_旗の_ビット=を使用します: =は_値(3、7)を解凍しました。 }
COMPRESSED flags_static {
discriminator =:= '1' [ 1 ];
type [ 2 ];
scaled_seq_no [ 1 ]; // Uses default
abc_flag_bits =:= static;
}
}
COMPRESSEDは_に静的に旗を揚げさせます。弁別器は: ='1'[ 1 ]; タイプ[ 2 ];スケーリングされた_seq_ノー[ 1 ]と等しいです; //はデフォルトabc_旗の_ビット=を使用します: =静電気
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.
通常、分野をコード化するのに使用されるコード化方法は分野の長さを指定します。 上の記法では、方法をコード化してはいけないので、直接「系列_いいえ」を使用する長さは、「実施」という声明を使用することで明らかに定義される必要があります。 これは一貫性と読み易さの容易さにも簡略化された構文を使用し終わっています。 これが珍しいことに注意してください: フィールド長指摘の大部分が、余分、そして、(その結果、任意)ですが、これは任意ではありません。 上の記法からそれを取り除くなら、「系列_いいえ」分野の長さは未定義でしょうに。
Here is some example output:
ここに、何らかの実例の出力があります:
Uncompressed header: 0101000100010000
Compressed header: 000100011011000
ヘッダーを解凍します: 0101000100010000の圧縮されたヘッダー: 000100011011000
Uncompressed header: 0101000101000000
Compressed header: 1010 ; 000100011100000
ヘッダーを解凍します: 0101000101000000の圧縮されたヘッダー: 1010 ; 000100011100000
Uncompressed header: 0110000101110000
Compressed header: 1101 ; 001000011101000
ヘッダーを解凍します: 0110000101110000の圧縮されたヘッダー: 1101 ; 001000011101000
Uncompressed header: 0111000110101110
Compressed header: 01110 ; 001100011110111
ヘッダーを解凍します: 0111000110101110の圧縮されたヘッダー: 01110 ; 001100011110111
In this form, we see that this gives us a saving of a further bit in most packets. Assuming the bulk of a flow is made up of "flags_static" headers, the mean size of the headers in a compressed flow is now just over a quarter of their size in an uncompressed flow.
このフォームでは、私たちは、これがほとんどのパケットでのさらなるビットの節約を私たちに与えるのを見ます。 ヘッダー、流れの大半が「旗_静電気」で補われると仮定して、現在、圧縮された流れにおける、ヘッダーの平均であるサイズはただ解凍された流れにおける彼らのサイズの4分の1以上です。
Finking & Pelletier Standards Track [Page 58] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[58ページ]。
B.10. Use of "ENFORCE" Statements as Conditionals
B.10。 「実施」というConditionalsとしての声明の使用
Earlier, we created a new format "flags_set" to handle packets with all three of the flag bits set. As it happens, these three flags are always all set for "type 3" packets, and are never all set for other packet types (a "type 3" packet is one where the type field is set to three).
より早く、私たちは、ビットが設定するすべての3個の旗でパケットを扱うために新しい形式「旗_セット」を作成しました。 たまたま、これらの3個の旗がいつもすべて、セットである、「3インチのパケットをタイプして、他のパケットタイプのための決してすべてのセットでない、(「タイプの3インチのパケットがタイプ分野が3に設定されるものである、)、」
This allows extra efficiency in encoding such packets. We know the type is three, so we don't need to encode the type field in the compressed header. The type field was previously encoded as "irregular(2)", which is two bits long. Removing this reduces the size of the "flags_set" format from five bits to three, making it the smallest format in the encoding method definition.
これはそのようなパケットをコード化する際に余分な効率を許容します。 タイプが3歳であることを知っているので、私たちは圧縮されたヘッダーのタイプ分野をコード化する必要はありません。 タイプ分野は以前に、「不規則(2)」としてコード化されました(長さ2ビットです)。 これを取り除くと、「旗_セット」形式のサイズは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:
それをnotateして、「旗_セット」形式は、「タイプが3歳でないときにだけ3インチヘッダー、および「旗_静電気」がフォーマットするタイプ、各形式でこれらの状態を述べるのが必要であること」に使用されるだけであるべきです。 「実施」という声明でこれができます:
eg_header
{
UNCOMPRESSED {
version_no =:= uncompressed_value(2, 1) [ 2 ];
type [ 2 ];
flow_id [ 4 ];
sequence_no [ 4 ];
abc_flag_bits [ 3 ];
reserved_flag =:= uncompressed_value(1, 0) [ 1 ];
}
eg_ヘッダー、UNCOMPRESSED: バージョン_いいえ、==は_値(2、1)の[ 2 ]を解凍しました; タイプ[ 2 ]; 流れ_イド[ 4 ];系列_ノー[ 4 ]; abc_旗の_ビット[ 3 ];は_旗=を予約しました: =は_値(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);
}
コントロール計算する正しく比例する//必要性法数学、4ビットへの//支払われるべきものはスケーリングされた_seqに_[ 4 ]を全く巻きつけません; ENFORCE(系列_No.UVALUE=(スケーリングされた_seq_No.UVALUE*3)%16)
DEFAULT {
type =:= irregular(2);
scaled_seq_no =:= lsb(1, -1);
flow_id =:= static;
}
デフォルト=をタイプしてください: =不規則(2); =: =スケーリングされた_seq_ノーlsb(1、-1); 流れ_イド=: =静電気
COMPRESSED irregular_format {
discriminator =:= '00' [ 2 ];
type [ 2 ];
COMPRESSEDの不規則な_形式、弁別器=: ='00'[ 2 ]; タイプ[ 2 ]。
Finking & Pelletier Standards Track [Page 59] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[59ページ]。
flow_id =:= irregular(4) [ 4 ];
scaled_seq_no =:= irregular(4) [ 4 ];
abc_flag_bits =:= irregular(3) [ 3 ];
}
流れ_イド=: =不規則(4)[ 4 ]。 スケーリングされた_seq_ノーは: =不規則(4)[ 4 ]と等しいです。 abc_旗の_ビット=: =不規則(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旗_セットENFORCE(type.UVALUE=3); //余分な状態弁別器=: ='01'[ 2 ]; タイプ=: =解凍された_価値(2、3)[ 0 ];スケーリングされた_seq_ノー[ 1 ]; abc_は_ビット=に旗を揚げさせます: =解凍された_価値(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は_静的なENFORCE(type.UVALUE!=3); 弁別器=: ='1'[ 1 ]; [ 2 ]をタイプします;スケーリングされた_seq_ノー[ 1 ]; abc_旗の_ビット=: =静電気[ 0 ];に旗を揚げさせます。
The two "ENFORCE" statements in the last two formats act as "guards". Guards prevent formats from being used under the wrong circumstances. In fact, the "ENFORCE" statement in "flags_set" is redundant. The condition it guards for is already enforced by the new encoding method used for the "type" field. The encoding method "uncompressed_value(2,3)" binds the "UVALUE" attribute to three. This is exactly what the "ENFORCE" statement does, so it can be removed without any change in meaning. The "uncompressed_value" encoding method on the other hand is not redundant. It specifies other bindings on the type field in addition to the one that the "ENFORCE" statement specifies. Therefore it would not be possible to remove the encoding method and leave just the "ENFORCE" statement.
「実施」という最後の2つの形式の2つの声明が「番人」として機能します。 番人は、形式が間違った状況で使用されるのを防ぎます。 事実上、「実施」という「_が設定した旗」による声明は余分です。 それが警備する状態は「タイプ」分野に使用される新しいコード化方法によって既に励行されます。 コード化している方法「解凍された_値(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
ヘッダーを解凍します: 0101000100010000の圧縮されたヘッダー: 000100011011000
Uncompressed header: 0101000101000000
Compressed header: 1010 ; 000100011100000
ヘッダーを解凍します: 0101000101000000の圧縮されたヘッダー: 1010 ; 000100011100000
Finking & Pelletier Standards Track [Page 60] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[60ページ]。
Uncompressed header: 0110000101110000
Compressed header: 1101 ; 001000011101000
ヘッダーを解凍します: 0110000101110000の圧縮されたヘッダー: 1101 ; 001000011101000
Uncompressed header: 0111000110101110
Compressed header: 010 ; 001100011110111
ヘッダーを解凍します: 0111000110101110の圧縮されたヘッダー: 010 ; 001100011110111
This saves just two extra bits (a 7% saving) in the example flow.
これは例の流動で余分なちょうど2ビット(7%の節約)を節約します。
Authors' Addresses
作者のアドレス
Robert Finking Siemens/Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK
Manorの研究の古いソールズベリーLaneロムジー、ロバートFinkingシーメンス/RokeハンプシャーSO51 0ZNイギリス
Phone: +44 (0)1794 833189 EMail: robert.finking@roke.co.uk URI: http://www.roke.co.uk
以下に電話をしてください。 +44 (0) 1794 833189はメールされます: robert.finking@roke.co.uk ユリ: http://www.roke.co.uk
Ghyslain Pelletier Ericsson Box 920 Lulea SE-971 28 Sweden
GhyslainペレティアエリクソンBox920ルーレオSE-971 28スウェーデン
Phone: +46 (0) 8 404 29 43 EMail: ghyslain.pelletier@ericsson.com
以下に電話をしてください。 +46(0) 8 404 29 43はメールされます: ghyslain.pelletier@ericsson.com
Finking & Pelletier Standards Track [Page 61] RFC 4997 ROHC-FN July 2007
FinkingとペレティアStandardsはROHC-FN2007年7月にRFC4997を追跡します[61ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Finking & Pelletier Standards Track [Page 62]
Finkingとペレティア標準化過程[62ページ]
一覧
スポンサーリンク
