Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 4997

Formal Notation for RObust Header Compression (ROHC-FN)

Pages: 62
Proposed Standard
Part 2 of 3 – Pages 13 to 41
First   Prev   Next

Top   ToC   RFC4997 - Page 13   prevText

4. Normative Definition of 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). 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

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 and one or more encoding method definitions (Section 4.12). Encoding methods can be defined using the formal notation or can be predefined encoding methods. Encoding methods are defined using the formal notation by giving one or more uncompressed formats to represent the uncompressed header and one or more compressed formats. These formats are related to each other by "fields", each of which describes a certain part of an
Top   ToC   RFC4997 - Page 14
   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.

   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

4.2. Identifiers

In ROHC-FN, identifiers are used for any of the following: o encoding methods o formats o fields o parameters o constants All identifiers may be of any length and may contain any combination of alphanumeric characters and underscores, within the restrictions defined in this section. All identifiers must start with an alphabetic character. It is illegal to have two or more identifiers that differ from each other only in capitalisation, in the same scope. All letters in identifiers for constants must be upper case. It is illegal to use any of the following as identifiers (including alternative capitalisations): o "false", "true" o "ENFORCE", "THIS", "VARIABLE" o "ULENGTH", "UVALUE"
Top   ToC   RFC4997 - Page 15


   Format names cannot be referred to in the notation, although they are
   considered to be identifiers.  (See Section for more details
   on format names.)

   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.

   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 are considered
   to be identifiers, they are not referred to in the notation, but are
   primarily for the benefit of the reader.

4.3. Constant Definitions

Constant values can be defined using the "=" operator. Identifiers for constants must be all upper case. For example: SOME_CONSTANT = 3; Constants are defined by an expression (see Section 4.7) on the right-hand side of the "=" operator. The expression must yield a constant value. That is, the expression must be one whose terms are
Top   ToC   RFC4997 - Page 16
   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

4.4. Fields

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. The properties of the compressed form of a field are defined by an encoding method and/or "ENFORCE" statements. This entirely characterises the relationship between the uncompressed and compressed forms of that field. This is achieved by specifying the relationships between the field's attributes. The notation defines four field attributes, two for the uncompressed form and a corresponding two for the compressed form. The attributes available for each field are: uncompressed attributes of a field: o "UVALUE" and "ULENGTH", compressed attributes of a field: o "CVALUE" and "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. 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.
Top   ToC   RFC4997 - Page 17
   Attributes are undefined unless they are bound to a value, in which
   case they become defined.  If two conflicting bindings are given for
   a field attribute then the bindings fail along with the (combination
   of) formats in which those bindings were defined.

   Uncompressed attributes do not always reflect an aspect of the
   uncompressed header.  Some fields do not originate from the
   uncompressed header, but are control fields.

4.4.1. Attribute References

Attributes of a particular field are formally referred to by using the field's name followed by a "." and the attribute's identifier. For example: rtp_seq_number.UVALUE 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.

4.4.2. Representation of Field Values

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)". 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. 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.

4.5. Grouping of Fields

Since the order of fields in a "COMPRESSED" field list (Section do not have to be the same as the order of fields in an "UNCOMPRESSED" field list (Section, 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.
Top   ToC   RFC4997 - Page 18
   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:

         minor_seq_num;  // 12 bits
         other_field;    //  8 bits
         major_seq_num;  //  4 bits

         other_field     =:= irregular(8);
         : minor_seq_num =:= lsb(3, 0);

   The group of fields is presented to the encoding method as a
   contiguous group of bits, assembled by the concatenation of the
   fields in the order they are given in the group.  The most
   significant bit of the combined field is the most significant bit of
   the first field in the list, and the least significant bit of the
   combined field is the least significant bit of the last field in the

   Finally, the length attributes of the combined field are equal to the
   sum of the corresponding length attributes for all the fields in the

4.6. "THIS"

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
Top   ToC   RFC4997 - Page 19

4.7. Expressions

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. 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: o There is no limit on the range of integers. 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 There is no comma operator. o There are no "modify" operators (no assignment operators and no increment or decrement). o There are no bitwise operators. 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). 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:
Top   ToC   RFC4997 - Page 20
      tcp_list_length =:= (data_offset + 20) / 4;

   There is only enough information here to define a single attribute of
   "tcp_list_length".  Although this makes no sense formally, this could
   intuitively be read as defining the "UVALUE" attribute.  However,
   that would still leave the length of the uncompressed field undefined
   at the decompressor.  Such usage is therefore prohibited.

4.7.1. Integer Literals

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.

4.7.2. Integer Operators

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 *, / 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 +, - for addition and subtraction. "x + y" returns the sum of "x" and "y". "x - y" returns the difference. o % for modulo. "x % y" returns "x" modulo "y"; x - y * (x / y).

4.7.3. Boolean Literals

The boolean literals are "false", and "true".

4.7.4. Boolean Operators

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 ||, for logical "or". Returns true if at least one argument is true. Returns false otherwise.
Top   ToC   RFC4997 - Page 21
   o  !, for logical "not".  Returns true if its argument is false.
      Returns false otherwise.

4.7.5. Comparison Operators

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 <, >, 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 >=, <=, 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.


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. 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: //----------------------------------------------------------------- // IR-REPLICATE header formats //----------------------------------------------------------------- // The following fields are included in all of the IR-REPLICATE // header formats: // UNCOMPRESSED { discriminator; // 8 bits tcp_seq_number; // 32 bits tcp_flags_ecn; // 2 bits Comments do not affect the formal meaning of what is notated, but can be used to improve readability. Their use is optional. Comments may help to provide clarifications to the reader, and serve different purposes to implementers. Comments should thus not be
Top   ToC   RFC4997 - Page 22
   considered of lesser importance when inserting them into a ROHC-FN
   specification; they should be consistent with the normative part of
   the specification.

4.9. "ENFORCE" Statements

The "ENFORCE" statement provides a way to add predicates to a format, all of which must be fulfilled for the format to succeed. An "ENFORCE" statement shares some similarities with an encoding method. Specifically, whereas an encoding method binds several field attributes at once, an "ENFORCE" statement typically binds just one of them. In fact, all the bindings that encoding methods create can be expressed in terms of a collection of "ENFORCE" statements. Here is an example "ENFORCE" statement which binds the "UVALUE" attribute of a field to 5. ENFORCE(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. An abbreviated form of an "ENFORCE" statement is available for binding length attributes using "[" and "]", see Section 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. An "ENFORCE" statement takes a boolean expression as a parameter. It can be used to assert that the expression is true, in order to choose a particular format from a list of possible formats specified in an encoding method (see Section 4.12), or just to bind an expression as in the example above. The general form of an "ENFORCE" statement is therefore: ENFORCE(<boolean expression>); There are three possible conditions that the expression may be in: 1. The boolean expression evaluates to false, in which case the local scope of the format that contains the "ENFORCE" statement cannot be used.
Top   ToC   RFC4997 - Page 23
   2.  The boolean expression evaluates to true, in which case the
       binding is created and successful.

   3.  The value of the boolean expression is undefined.  In this case,
       the binding is also created and successful.

   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.

4.10. Formal Specification of Field Lengths

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. An expression defining the length of a field can be specified in square brackets after the appearance of that field in a format. If the field can take several alternative lengths, then the expressions defining those lengths can be enumerated as a comma separated list within the square brackets. For example: field_1 [ 4 ]; field_2 [ a+b, 2 ]; field_3 =:= lsb(16, 16) [ 26 ]; The actual length attribute, which is bound by this notation, depends on whether it appears in a "COMPRESSED", "UNCOMPRESSED", or "CONTROL" field list (see Section 4.12.1 and its subsections). In a "COMPRESSED" field list, the field's "CLENGTH" attribute is bound. In "UNCOMPRESSED" and "CONTROL" field lists, the field's "ULENGTH" attribute is bound. Abbreviated "ENFORCE" statements are not allowed in "DEFAULT" sections (see Section 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:
Top   ToC   RFC4997 - Page 24
     field_1;                 ENFORCE(field_1.ULENGTH == 4);
     field_2;                 ENFORCE((field_2.ULENGTH == 2)
                                   || (field_2.ULENGTH == a+b));
     field_3 =:= lsb(16, 16); ENFORCE(field_3.ULENGTH == 26);

   A special case exists for fields that have a variable length that the
   notator does not wish, or is not able to, define using an expression.
   The keyword "VARIABLE" can be used in the following case:

     variable_length_field  [ VARIABLE ];

   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 and Section  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:

         field  [ 8 * (5 + VARIABLE) ];

   This defines a field whose length is a whole number of octets and at
   least 40 bits (5 octets).

4.11. Library of Encoding Methods

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. 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).

4.11.1. uncompressed_value

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:
Top   ToC   RFC4997 - Page 25
     uncompressed_value(len, val) {
         ENFORCE(field.ULENGTH == len);
         ENFORCE(field.UVALUE == val);
         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:

     version   =:=   uncompressed_value(4, 6);

   Here is another example of value encoding, using an expression to
   calculate the length:

     padding =:= uncompressed_value(nbits - 8, 0);

   The expression above uses an encoding method parameter, "nbits", that
   in this example specifies how many significant bits there are in the
   data to calculate how many pad bits to use.  See Section 4.12.2 for
   more information on encoding method parameters.

4.11.2. compressed_value

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); } }
Top   ToC   RFC4997 - Page 26
   One possible use of this encoding method is to define padding in a
   compressed format:

     pad_to_octet_boundary      =:=   compressed_value(3, 0);

   A more common use is to define a discriminator field to make it
   possible to differentiate between different compressed formats within
   an encoding method (see Section 4.12).  For convenience, the notation
   provides syntax for specifying "compressed_value" encoding in the
   form of a binary string.  The binary string to be encoded is simply
   given in single quotes; the "CLENGTH" attribute of the field binds
   with the number of bits in the string, while its "CVALUE" attribute
   binds with the value given by the string.  For example:

     discriminator     =:=   '01101';

   This has exactly the same meaning as:

     discriminator     =:=   compressed_value(5, 13);

4.11.3. irregular

The "irregular" encoding method is used to encode a field in the compressed format with a bit pattern identical to the uncompressed field. This encoding method is defined as follows: irregular(len) { UNCOMPRESSED { field; ENFORCE(field.ULENGTH == len); } COMPRESSED { field; ENFORCE(field.CLENGTH == len); ENFORCE(field.CVALUE == field.UVALUE); } } For example, the checksum field of the TCP header is a 16-bit field that does not follow any predictable pattern from one header to another (and so it cannot be compressed): tcp_checksum =:= irregular(16); Note that the length does not have to be constant, for example, an expression can be used to derive the length of the field from the value of another field.
Top   ToC   RFC4997 - Page 27

4.11.4. static

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. 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: src_port =:= static;

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. field =:= lsb(<num_lsbs_param>, <offset_param>); Here, "num_lsbs_param" is the number of least significant bits to use, and "offset_param" is the interpretation interval offset as defined below. 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. For example, the TCP sequence number: tcp_sequence_number =:= lsb(14, 8192); This takes up 14 bits, and can communicate any value that is between 8192 lower than the value of the field stored in context and 8191 above it.
Top   ToC   RFC4997 - Page 28
   The interpretation interval can be described as a function of a value
   stored in the context, ref_value, and of num_lsbs_param:

     f(context_value, num_lsbs_param) = [ref_value - offset_param,
                ref_value + (2^num_lsbs_param - 1) - offset_param]

   where offset_param is an integer.

          <-- interpretation interval (size is 2^num_lsbs_param) -->
        lower                     ref_value                      upper
        bound                                                    bound


        lower bound = ref_value - offset_param
        upper bound = ref_value + (2^num_lsbs_param-1) - offset_param

   The "lsb" encoding method can therefore compress a field whose value
   lies between the lower and the upper bounds, inclusively, of the
   interpretation interval.  In particular, if offset_param = 0, then
   the field value can only stay the same or increase relative to the
   reference value ref_value.  If offset_param = -1, then it can only
   increase, whereas if offset_param = 2^num_lsbs_param, then it can
   only decrease.

   The compressed field takes up the specified number of bits in the
   compressed format (i.e., 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
Top   ToC   RFC4997 - Page 29

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: o the number of bits for the CRC (crc_bits), o the bit-pattern for the polynomial (bit_pattern), o the initial value for the CRC register (initial_value), o the value of the block of data, represented using either the "UVALUE" or "CVALUE" attribute of a field (block_data_value); and o the size in octets of the block of data (block_data_length). That is: field =:= crc(<num_bits>, <bit_pattern>, <initial_value>, <block_data_value>, <block_data_length>); When specifying the bit pattern for the polynomial, each bit represents the coefficient for the corresponding term in the polynomial. Note that the highest order term is always present (by definition) and therefore does not need specifying in the bit pattern. Therefore, a CRC polynomial with n terms in it is represented by a bit pattern with n-1 bits set. The CRC is calculated in least significant bit (LSB) order. For example: // 3 bit CRC, C(x) = x^0 + x^1 + x^3 crc_field =:= crc(3, 0x6, 0xF, THIS.CVALUE, THIS.CLENGTH); Usage of the "THIS" keyword (see Section 4.6) as shown above, is typical when using "crc" encoding. For example, when used in the encoding method for an entire header, it causes the CRC to be calculated over all fields in the header.

4.12. Definition of Encoding Methods

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
Top   ToC   RFC4997 - Page 30
   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

This simplest form of defining an encoding method is to specify a single encoding. For example: compound_encoding_method { UNCOMPRESSED { field_1; // 4 bits field_2; // 12 bits } COMPRESSED { field_2 =:= uncompressed_value(12, 9); // 0 bits field_1 =:= irregular(4); // 4 bits } } The above begins with the new method's identifier, "compound_encoding_method". The definition of the method then follows inside curly brackets, "{" and "}". The first item in the definition is the "UNCOMPRESSED" field list, which gives the order of the fields in the uncompressed format. This is followed by the compressed format field list ("COMPRESSED"). This list gives the order of fields in the compressed format and also gives the encoding method for each field. In the example, both the formats list each field exactly once. However, sometimes it is necessary to specify more than one binding for a given field, which means it appears more than once in the field list. In this case, it is the first occurrence of the field in the list that indicates its position in the field order. The subsequent occurrences of the field only specify binding information, not field order information. The different components of this example are described in more detail below. Other components that can be used in the definition of encoding methods are also defined thereafter.
Top   ToC   RFC4997 - Page 31 Uncompressed Format - "UNCOMPRESSED"
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. 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: field_1.ULENGTH + field_2.ULENGTH == THIS.ULENGTH In the example, there are only two fields, but any number of fields may be used. This relationship applies to however many fields are actually used. Any arrangement of fields that efficiently describes the content of the uncompressed header may be chosen -- this need not be the same as the one described in the specifications for the protocol header being compressed. For example, there may be a protocol whose header contains a 16-bit sequence number, but whose sessions tend to be short-lived. This would mean that the high bits of the sequence number are almost always constant. The "UNCOMPRESSED" format could reflect this by splitting the original uncompressed field into two fields, one field to represent the almost-always-zero part of the sequence number, and a second field to represent the salient part. 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). 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 below), "CONTROL" (see Section below), "INITIAL" (see Section below), and "DEFAULT" (see Section below) field lists must, between them, define the "ULENGTH" attribute of every field in an
Top   ToC   RFC4997 - Page 32
   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. Compressed Format - "COMPRESSED"
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. 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. 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: compound_encoding_method { UNCOMPRESSED { field_1; // 4 bits field_2 =:= uncompressed_value(12, 9); // 12 bits } COMPRESSED { field_1 =:= irregular(4); // 4 bits } }
Top   ToC   RFC4997 - Page 33
   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 below), "INITIAL" (see
   Section below), and "DEFAULT" (see Section 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. 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. 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: 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
Top   ToC   RFC4997 - Page 34
         ip_id;         // 16 bits
         src_addr;      // 32 bits
         dst_addr;      // 32 bits
         checksum;      // 16 bits
         length;        // 16 bits

       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.

   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:

         field_1 =:= some_encoding;

       CONTROL {
         ENFORCE(scaled_field.UVALUE == field_1.UVALUE / 8);
         ENFORCE(scaled_field.ULENGTH == field_1.ULENGTH - 3);

         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.

   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.
Top   ToC   RFC4997 - Page 35 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: 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. 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. 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 are optional and may be given for any combination of fields and attributes which are in scope. The syntax for specifying default bindings is similar to that used to specify a compressed or uncompressed format. However, the order of the fields in the field list does not affect the order of the fields in either the compressed or uncompressed format. This is because the field order is specified individually for each "COMPRESSED" format and "UNCOMPRESSED" format. Here is an example: DEFAULT { field_1 =:= uncompressed_value(4, 1); field_2 =:= uncompressed_value(4, 2); field_3 =:= lsb(3, -1); ENFORCE(field_4.ULENGTH == 4);
Top   ToC   RFC4997 - Page 36

   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.

   If elsewhere a binding is not specified for the attributes of a
   field, the default encoding method is used.  If the default encoding
   method always compresses the field down to zero bits, the field can
   be omitted from the compressed format's field list.  Like any other
   zero-bit field, its position in the field list is not significant.

   The "DEFAULT" field list may contain default bindings for individual
   attributes by using "ENFORCE" statements.  A default binding for an
   individual attribute will only be used if elsewhere there is no
   binding given for that attribute or the field to which it belongs.
   If elsewhere there is an "ENFORCE" statement binding that attribute,
   or an encoding method binding the field to which it belongs, the
   default binding for the attribute will not be used.  This applies
   even if the specified encoding method does not bind the particular
   attribute given in the "DEFAULT" section.  However, an "ENFORCE"
   statement elsewhere that only binds the length of the field still
   allows the default bindings to be used, except for default "ENFORCE"
   statements which bind nothing but the field's length.

   To clarify, assuming the default bindings given in the example above,
   the first three of the following four compressed formats would not
   use the default binding for "field_4.ULENGTH":

       COMPRESSED format1 {
         ENFORCE(field_4.ULENGTH == 3); // set ULENGTH to 3
         ENFORCE(field_4.UVALUE == 7);  // set UVALUE to 7

       COMPRESSED format2 {
         field_4 =:= irregular(3);      // set ULENGTH to 3

       COMPRESSED format3 {
         field_4 =:= '1010';            // set ULENGTH to zero
Top   ToC   RFC4997 - Page 37
       COMPRESSED format4 {
         ENFORCE(field_4.UVALUE == 12); // use default ULENGTH

   The fourth format is the only one that uses the default binding for

   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

Encoding methods may take arguments that control the mapping between compressed and uncompressed fields. These are specified immediately after the method's name, in parentheses, as a comma-separated list. For example: poor_mans_lsb(variable_length) { UNCOMPRESSED { constant_bits; variable_bits; } COMPRESSED { variable_bits =:= irregular(variable_length); constant_bits =:= static; } } As with any encoding method, all arguments take individual values, such as an integer literal or a field attribute, rather than entire fields. Although entire fields cannot be passed as arguments, it is possible to pass each of their attributes instead, which is equivalent. Recall that all bindings are two-way, so that rather than the arguments acting as "inputs" to the encoding method, the result of an encoding method may be to bind the parameters passed to it.
Top   ToC   RFC4997 - Page 38
   For example:

     set_to_double(arg1, arg2)
       CONTROL {
         ENFORCE(arg1 == 2 * arg2);

   This encoding method will attempt to bind the first argument to twice
   the value of the second.  In fact this "encoding" method is
   pathological.  Since it defines no fields, it does not do any actual
   encoding at all.  "CONTROL" sections are more appropriate to use for
   this purpose than "UNCOMPRESSED".

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. 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. 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. 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.
Top   ToC   RFC4997 - Page 39 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. 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). Example of Multiple 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 } DEFAULT { field_1 =:= static; field_2 =:= uncompressed_value(4, 2); field_3 =:= lsb(4, 0); }
Top   ToC   RFC4997 - Page 40
       COMPRESSED format0 {
         discriminator =:= '0'; // 1 bit
         field_3;               // 4 bits

       COMPRESSED format1 {
         discriminator =:= '1';           //  1 bit
         field_1       =:= irregular(4);  //  4 bits
         field_3       =:= irregular(24); // 24 bits

   Note the following:

   o  "field_1" and "field_3" both have default encoding methods
      specified for them, which are used in "format0", but are
      overridden in "format1"; the default encoding method of "field_2"
      however, is not overridden.

   o  "field_1" 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  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.

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. These methods are specific to the properties of the protocol being compressed and will thus have to be defined within the profile
Top   ToC   RFC4997 - Page 41
   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.

   For example:

     inferred_ip_v4_header_checksum "defined in RFCxxxx Section 6.4.1";

(page 41 continued on part 3)

Next Section