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

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

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"

   o  "CLENGTH", "CVALUE"

   o  "UNCOMPRESSED", "COMPRESSED", "CONTROL", "INITIAL", or "DEFAULT"

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

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

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

   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

   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.

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

   The group is notated by giving a colon-separated list of the fields
   to be grouped together.  For example there may be two non-contiguous
   fields in an uncompressed header that are two halves of what is
   effectively a single sequence number:

     grouping_example
     {
       UNCOMPRESSED {
         minor_seq_num;  // 12 bits
         other_field;    //  8 bits
         major_seq_num;  //  4 bits
       }

       COMPRESSED {
         other_field     =:= irregular(8);
         major_seq_num
         : minor_seq_num =:= lsb(3, 0);
       }
     }

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

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

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

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:

      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.

   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.

4.8.  Comments

   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

   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.

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

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

         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:

     uncompressed_value(len, val) {
       UNCOMPRESSED {
         field;
         ENFORCE(field.ULENGTH == len);
         ENFORCE(field.UVALUE == val);
       }
       COMPRESSED {
         field;
         ENFORCE(field.CLENGTH == 0);
       }
     }

   To exemplify the usage of "uncompressed_value" encoding, the IPv6
   header version number is a 4-bit field that always has the value 6:

     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);
       }
     }

   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.

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.

   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

   where:

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

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

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

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

   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.

4.12.1.1.  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 4.12.1.2 below), "CONTROL" (see
   Section 4.12.1.3 below), "INITIAL" (see Section 4.12.1.4 below), and
   "DEFAULT" (see Section 4.12.1.5 below) field lists must, between
   them, define the "ULENGTH" attribute of every field in an

   uncompressed format so that there is an unambiguous mapping from the
   bits in the uncompressed format to the fields listed in the
   "UNCOMPRESSED" field list.

4.12.1.2.  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
       }
     }

   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"

   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

         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:

     example_encoding_method_definition
     {
       UNCOMPRESSED {
         field_1 =:= some_encoding;
       }

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

       COMPRESSED {
         scaled_field =:= lsb(4, 0);
       }
     }

   This control field is used to scale down a field in the uncompressed
   format by a factor of 8 before encoding it with the "lsb" encoding
   method.  Scaling it down makes the "lsb" encoding more efficient.

   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.

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:

     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.

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 are optional and may be given for any combination of
   fields and attributes which are in scope.

   The syntax for specifying default bindings is similar to that used to
   specify a compressed or uncompressed format.  However, the order of
   the fields in the field list does not affect the order of the fields
   in either the compressed or uncompressed format.  This is because the
   field order is specified individually for each "COMPRESSED" format
   and "UNCOMPRESSED" format.

   Here is an example:

       DEFAULT {
         field_1 =:= uncompressed_value(4, 1);
         field_2 =:= uncompressed_value(4, 2);
         field_3 =:= lsb(3, -1);
         ENFORCE(field_4.ULENGTH == 4);

       }

   Here default bindings are specified for fields 1 to 3.  A default
   binding for the "ULENGTH" attribute of field_4 is also specified.

   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
       }

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

   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.

   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.

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.

   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.

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.

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

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:

     example_multiple_formats
     {
       UNCOMPRESSED {
         field_1;  //  4 bits
         field_2;  //  4 bits
         field_3;  // 24 bits
       }

       DEFAULT {
         field_1 =:= static;
         field_2 =:= uncompressed_value(4, 2);
         field_3 =:= lsb(4, 0);
       }

       COMPRESSED format0 {
         discriminator =:= '0'; // 1 bit
         field_3;               // 4 bits
       }

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

   Note the following:

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

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

   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";