GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4997

Network Working Group R. Finking Request for Comments: 4997 Siemens/Roke Manor Research Category: Standards Track G. Pelletier

                                                              Ericsson
                                                             July 2007
      Formal Notation for RObust Header Compression (ROHC-FN)

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The IETF Trust (2007).

Abstract

 This document defines Robust Header Compression - Formal Notation
 (ROHC-FN), a formal notation to specify field encodings for
 compressed formats when defining new profiles within the ROHC
 framework.  ROHC-FN offers a library of encoding methods that are
 often used in ROHC profiles and can thereby help to simplify future
 profile development work.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
 3.  Overview of ROHC-FN  . . . . . . . . . . . . . . . . . . . . .  5
   3.1.  Scope of the Formal Notation . . . . . . . . . . . . . . .  6
   3.2.  Fundamentals of the Formal Notation  . . . . . . . . . . .  7
     3.2.1.  Fields and Encodings . . . . . . . . . . . . . . . . .  7
     3.2.2.  Formats and Encoding Methods . . . . . . . . . . . . .  9
   3.3.  Example Using IPv4 . . . . . . . . . . . . . . . . . . . . 11
 4.  Normative Definition of ROHC-FN  . . . . . . . . . . . . . . . 13
   4.1.  Structure of a Specification . . . . . . . . . . . . . . . 13
   4.2.  Identifiers  . . . . . . . . . . . . . . . . . . . . . . . 14
   4.3.  Constant Definitions . . . . . . . . . . . . . . . . . . . 15
   4.4.  Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     4.4.1.  Attribute References . . . . . . . . . . . . . . . . . 17
     4.4.2.  Representation of Field Values . . . . . . . . . . . . 17

Finking & Pelletier Standards Track [Page 1] RFC 4997 ROHC-FN July 2007

   4.5.  Grouping of Fields . . . . . . . . . . . . . . . . . . . . 17
   4.6.  "THIS" . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   4.7.  Expressions  . . . . . . . . . . . . . . . . . . . . . . . 19
     4.7.1.  Integer Literals . . . . . . . . . . . . . . . . . . . 20
     4.7.2.  Integer Operators  . . . . . . . . . . . . . . . . . . 20
     4.7.3.  Boolean Literals . . . . . . . . . . . . . . . . . . . 20
     4.7.4.  Boolean Operators  . . . . . . . . . . . . . . . . . . 20
     4.7.5.  Comparison Operators . . . . . . . . . . . . . . . . . 21
   4.8.  Comments . . . . . . . . . . . . . . . . . . . . . . . . . 21
   4.9.  "ENFORCE" Statements . . . . . . . . . . . . . . . . . . . 22
   4.10. Formal Specification of Field Lengths  . . . . . . . . . . 23
   4.11. Library of Encoding Methods  . . . . . . . . . . . . . . . 24
     4.11.1. uncompressed_value . . . . . . . . . . . . . . . . . . 24
     4.11.2. compressed_value . . . . . . . . . . . . . . . . . . . 25
     4.11.3. irregular  . . . . . . . . . . . . . . . . . . . . . . 26
     4.11.4. static . . . . . . . . . . . . . . . . . . . . . . . . 27
     4.11.5. lsb  . . . . . . . . . . . . . . . . . . . . . . . . . 27
     4.11.6. crc  . . . . . . . . . . . . . . . . . . . . . . . . . 29
   4.12. Definition of Encoding Methods . . . . . . . . . . . . . . 29
     4.12.1. Structure  . . . . . . . . . . . . . . . . . . . . . . 30
     4.12.2. Arguments  . . . . . . . . . . . . . . . . . . . . . . 37
     4.12.3. Multiple Formats . . . . . . . . . . . . . . . . . . . 38
   4.13. Profile-Specific Encoding Methods  . . . . . . . . . . . . 40
 5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 41
 6.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41
 7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
 8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
   8.1.  Normative References . . . . . . . . . . . . . . . . . . . 42
   8.2.  Informative References . . . . . . . . . . . . . . . . . . 42
 Appendix A.  Formal Syntax of ROHC-FN  . . . . . . . . . . . . . . 43
 Appendix B.  Bit-level Worked Example  . . . . . . . . . . . . . . 45
   B.1.  Example Packet Format  . . . . . . . . . . . . . . . . . . 45
   B.2.  Initial Encoding . . . . . . . . . . . . . . . . . . . . . 46
   B.3.  Basic Compression  . . . . . . . . . . . . . . . . . . . . 47
   B.4.  Inter-Packet Compression . . . . . . . . . . . . . . . . . 48
   B.5.  Specifying Initial Values  . . . . . . . . . . . . . . . . 50
   B.6.  Multiple Packet Formats  . . . . . . . . . . . . . . . . . 51
   B.7.  Variable Length Discriminators . . . . . . . . . . . . . . 53
   B.8.  Default Encoding . . . . . . . . . . . . . . . . . . . . . 55
   B.9.  Control Fields . . . . . . . . . . . . . . . . . . . . . . 56
   B.10. Use of "ENFORCE" Statements as Conditionals  . . . . . . . 59

Finking & Pelletier Standards Track [Page 2] RFC 4997 ROHC-FN July 2007

1. Introduction

 Robust Header Compression - Formal Notation (ROHC-FN) is a formal
 notation designed to help with the definition of ROHC [RFC4995]
 header compression profiles.  Previous header compression profiles
 have been so far specified using a combination of English text
 together with ASCII Box notation.  Unfortunately, this was sometimes
 unclear and ambiguous, revealing the limitations of defining complex
 structures and encodings for compressed formats this way.  The
 primary objective of the Formal Notation is to provide a more
 rigorous means to define header formats -- compressed and
 uncompressed -- as well as the relationships between them.  No other
 formal notation exists that meets these requirements, so ROHC-FN aims
 to meet them.
 In addition, ROHC-FN offers a library of encoding methods that are
 often used in ROHC profiles, so that the specification of new
 profiles using the formal notation can be achieved without having to
 redefine this library from scratch.  Informally, an encoding method
 defines a two-way mapping between uncompressed data and compressed
 data.

2. Terminology

 o  Compressed format
    A compressed format consists of a list of fields that provides
    bindings between encodings and the fields it compresses.  One or
    more compressed formats can be combined to represent an entire
    compressed header format.
 o  Context
    Context is information about the current (de)compression state of
    the flow.  Specifically, a context for a specific field can be
    either uninitialised, or it can include a set of one or more
    values for the field's attributes defined by the compression
    algorithm, where a value may come from the field's attributes
    corresponding to a previous packet.  See also a more generalized
    definition in Section 2.2 of [RFC4995].
 o  Control field
    Control fields are transmitted from a ROHC compressor to a ROHC
    decompressor, but are not part of the uncompressed header itself.

Finking & Pelletier Standards Track [Page 3] RFC 4997 ROHC-FN July 2007

 o  Encoding method, encodings
    Encoding methods are two-way relations that can be applied to
    compress and decompress fields of a protocol header.
 o  Field
    The protocol header is divided into a set of contiguous bit
    patterns known as fields.  Each field is defined by a collection
    of attributes that indicate its value and length in bits for both
    the compressed and uncompressed headers.  The way the header is
    divided into fields is specific to the definition of a profile,
    and it is not necessary for the field divisions to be identical to
    the ones given by the specification(s) for the protocol header
    being compressed.
 o  Library of encoding methods
    The library of encoding methods contains a number of commonly used
    encoding methods for compressing header fields.
 o  Profile
    A ROHC [RFC4995] profile is a description of how to compress a
    certain protocol stack.  Each profile consists of a set of formats
    (for example, uncompressed and compressed formats) along with a
    set of rules that control compressor and decompressor behaviour.
 o  ROHC-FN specification
    The specification of the set of formats of a ROHC profile using
    ROHC-FN.
 o  Uncompressed format
    An uncompressed format consists of a list of fields that provides
    the order of the fields to be compressed for a contiguous set of
    bits whose bit layout corresponds to the protocol header being
    compressed.

3. Overview of ROHC-FN

 This section gives an overview of ROHC-FN.  It also explains how
 ROHC-FN can be used to specify the compression of header fields as
 part of a ROHC profile.

Finking & Pelletier Standards Track [Page 4] RFC 4997 ROHC-FN July 2007

3.1. Scope of the Formal Notation

 This section explains how the formal notation relates to the ROHC
 framework and to specifications of ROHC profiles.
 The ROHC framework [RFC4995] provides the general principles for
 performing robust header compression.  It defines the concept of a
 profile, which makes ROHC a general platform for different
 compression schemes.  It sets link layer requirements, and in
 particular negotiation requirements, for all ROHC profiles.  It
 defines a set of common functions such as Context Identifiers (CIDs),
 padding, and segmentation.  It also defines common formats (IR, IR-
 DYN, Feedback, Add-CID, etc.), and finally it defines a generic,
 profile independent, feedback mechanism.
 A ROHC profile is a description of how to compress a certain protocol
 stack.  For example, ROHC profiles are available for RTP/UDP/IP and
 many other protocol stacks.
 At a high level, each ROHC profile consists of a set of formats
 (defining the bits to be transmitted) along with a set of rules that
 control compressor and decompressor behaviour.  The purpose of the
 formats is to define how to compress and decompress headers.  The
 formats define one or more compressed versions of each uncompressed
 header, and simultaneously define the inverse: how to relate a
 compressed header back to the original uncompressed header.
 The set of formats will typically define compression of headers
 relative to a context of field values from previous headers in a
 flow, improving the overall compression by taking into account
 redundancies between headers of successive packets.  Therefore, in
 addition to defining the formats, a profile has to:
 o  specify how to manage the context for both the compressor and the
    decompressor,
 o  define when and what to send in feedback messages, if any, from
    decompressor to compressor,
 o  outline compression principles to make the profile robust against
    bit errors and dropped packets.
 All this is needed to ensure that the compressor and decompressor
 contexts are kept consistent with each other, while still
 facilitating the best possible compression performance.
 The ROHC-FN is designed to help in the specification of compressed
 formats that, when put together based on the profile definition, make

Finking & Pelletier Standards Track [Page 5] RFC 4997 ROHC-FN July 2007

 up the formats used in a ROHC profile.  It offers a library of
 encoding methods for compressing fields, and a mechanism for
 combining these encoding methods to create compressed formats
 tailored to a specific protocol stack.
 The scope of ROHC-FN is limited to specifying the relationship
 between the compressed and uncompressed formats.  To form a complete
 profile specification, the control logic for the profile behaviour
 needs to be defined by other means.

3.2. Fundamentals of the Formal Notation

 There are two fundamental elements to the formal notation:
 1.  Fields and their encodings, which define the mapping between a
     header's uncompressed and compressed forms.
 2.  Encoding methods, which define the way headers are broken down
     into fields.  Encoding methods define lists of uncompressed
     fields and the lists of compressed fields they map onto.
 These two fundamental elements are at the core of the notation and
 are outlined below.

3.2.1. Fields and Encodings

 Headers are made up of fields.  For example, version number, header
 length, and sequence number are all fields used in real protocols.
 Fields have attributes.  Attributes describe various things about the
 field.  For example:
   field.ULENGTH
 The above indicates the uncompressed length of the field.  A field is
 said to have a value attribute, i.e., a compressed value or an
 uncompressed value, if the corresponding length attribute is greater
 than zero.  See Section 4.4 for more details on field attributes.
 The relationship between the compressed and uncompressed attributes
 of a field are specified with encoding methods, using the following
 notation:
   field   =:=   encoding_method;
 In the field definition above, the symbol "=:=" means "is encoded
 by".  This field definition does not represent an assignment
 operation from the right hand side to the left side.  Instead, it is

Finking & Pelletier Standards Track [Page 6] RFC 4997 ROHC-FN July 2007

 a two-way mapping between the compressed and uncompressed attributes
 of the field.  It both represents the compression and the
 decompression operation in a single field definition, through a
 process of two-way matching.
 Two-way matching is a binary operation that attempts to make the
 operands (i.e., the compressed and uncompressed attributes) match.
 This is similar to the unification process in logic.  The operands
 represent one unspecified data object and one specified object.
 Values can be matched from either operand.
 During compression, the uncompressed attributes of the field are
 already defined.  The given encoding matches the compressed
 attributes against them.  During decompression, the compressed
 attributes of the field are already defined, so the uncompressed
 attributes are matched to the compressed attributes using the given
 encoding method.  Thus, both compression and decompression are
 defined by a single field definition.
 Therefore, an encoding method (including any parameters specified)
 creates a reversible binding between the attributes of a field.  At
 the compressor, a format can be used if a set of bindings that is
 successful for all the attributes in all its fields can be found.  At
 the decompressor, the operation is reversed using the same bindings
 and the attributes in each field are filled according to the
 specified bindings; decoding fails if the binding for an attribute
 fails.
 For example, the "static" encoding method creates a binding between
 the attribute corresponding to the uncompressed value of the field
 and the corresponding value of the field in the context.
 o  For the compressor, the "static" binding is successful when both
    the context value and the uncompressed value are the same.  If the
    two values differ then the binding fails.
 o  For the decompressor, the "static" binding succeeds only if a
    valid context entry containing the value of the uncompressed field
    exists.  Otherwise, the binding will fail.
 Both the compressed and uncompressed forms of each field are
 represented as a string of bits; the most significant bit first, of
 the length specified by the length attribute.  The bit string is the
 binary representation of the value attribute of the field, modulo
 "2^length", where "length" is the length attribute of the field.
 However, this is only the representation of the bits exchanged
 between the compressor and the decompressor, designed to allow

Finking & Pelletier Standards Track [Page 7] RFC 4997 ROHC-FN July 2007

 maximum compression efficiency.  The FN itself uses the full range of
 integers.  See Section 4.4.2 for further details.

3.2.2. Formats and Encoding Methods

 The ROHC-FN provides a library of commonly used encoding methods.
 Encoding methods can be defined using plain English, or using a
 formal definition consisting of, for example, a collection of
 expressions (Section 4.7) and "ENFORCE" statements (Section 4.9).
 ROHC-FN also provides mechanisms for combining fields and their
 encoding methods into higher level encoding methods following a well-
 defined structure.  This is similar to the definition of functions
 and procedures in an ordinary programming language.  It allows
 complexity to be handled by being broken down into manageable parts.
 New encoding methods are defined at the top level of a profile.
 These can then be used in the definition of other higher level
 encoding methods, and so on.
 new_encoding_method         // This block is an encoding method
 {
   UNCOMPRESSED {            // This block is an uncompressed format
     field_1   [ 16 ];
     field_2   [ 32 ];
     field_3   [ 48 ];
   }
   CONTROL {                 // This block defines control fields
     ctrl_field_1;
     ctrl_field_2;
   }
   DEFAULT {                 // This block defines default encodings
                             // for specified fields
     ctrl_field_2 =:= encoding_method_2;
     field_1      =:= encoding_method_1;
   }
   COMPRESSED format_0 {     // This block is a compressed format
     field_1;
     field_2      =:= encoding_method_2;
     field_3      =:= encoding_method_3;
     ctrl_field_1 =:= encoding_method_4;
     ctrl_field_2;
   }

Finking & Pelletier Standards Track [Page 8] RFC 4997 ROHC-FN July 2007

   COMPRESSED format_1 {     // This block is a compressed format
     field_1;
     field_2      =:= encoding_method_3;
     field_3      =:= encoding_method_4;
     ctrl_field_2 =:= encoding_method_5;
     ctrl_field_3 =:= encoding_method_6; // This is a control field
                                         // with no uncompressed value
   }
 }
 In the example above, the encoding method being defined is called
 "new_encoding_method".  The section headed "UNCOMPRESSED" indicates
 the order of fields in the uncompressed header, i.e., the
 uncompressed header format.  The number of bits in each of the fields
 is indicated in square brackets.  After this is another section,
 "CONTROL", which defines two control fields.  Following this is the
 "DEFAULT" section which defines default encoding methods for two of
 the fields (see below).  Finally, two alternative compressed formats
 follow, each defined in sections headed "COMPRESSED".  The fields
 that occur in the compressed formats are either:
 o  fields that occur in the uncompressed format; or
 o  control fields that have an uncompressed value and that occur in
    the CONTROL section; or
 o  control fields that do not have an uncompressed value and thus are
    defined as part of the compressed format.
 Central to each of these formats is a "field list", which defines the
 fields contained in the format and also the order that those fields
 appear in that format.  For the "DEFAULT" and "CONTROL" sections, the
 field order is not significant.
 In addition to specifying field order, the field list may also
 specify bindings for any or all of the fields it contains.  Fields
 that have no bindings defined for them are bound using the default
 bindings specified in the "DEFAULT" section (see Section 4.12.1.5).
 Fields from the compressed format have the same name as they do in
 the uncompressed format.  If there are any fields that are present
 exclusively in the compressed format, but that do have an
 uncompressed value, they must be declared in the "CONTROL" section of
 the definition of the encoding method (see Section 4.12.1.3 for more
 details on defining control fields).
 Fields that have no uncompressed value do not appear in an
 "UNCOMPRESSED" field list and do not have to appear in the "CONTROL"

Finking & Pelletier Standards Track [Page 9] RFC 4997 ROHC-FN July 2007

 field list either.  Instead, they are only declared in the compressed
 field lists where they are used.
 In the example above, all the fields that appear in the compressed
 format are also found in the uncompressed format, or the control
 field list, except for ctrl_field_3; this is possible because
 ctrl_field_3 has no "uncompressed" value at all.  Fields such as a
 checksum on the compressed information fall into this category.

3.3. Example Using IPv4

 This section gives an overview of how the notation is used by means
 of an example.  The example will develop the formal notation for an
 encoding method capable of compressing a single, well-known header:
 the IPv4 header [RFC791].
 The first step is to specify the overall structure of the IPv4
 header.  To do this, we use an encoding method that we will call
 "ipv4_header".  More details on definitions of encoding methods can
 be found in Section 4.12.  This is notated as follows:
   ipv4_header
   {
 The fragment of notation above declares the encoding method
 "ipv4_header", the definition follows the opening brace (see
 Section 4.12).
 Definitions within the pair of braces are local to "ipv4_header".
 This scoping mechanism helps to clarify which fields belong to which
 formats; it is also useful when compressing complex protocol stacks
 with several headers, often with the same field names occurring in
 multiple headers (see Section 4.2).
 The next step is to specify the fields contained in the uncompressed
 IPv4 header to represent the uncompressed format for which the
 encoding method will define one or more compressed formats.  This is
 accomplished using ROHC-FN as follows:

Finking & Pelletier Standards Track [Page 10] RFC 4997 ROHC-FN July 2007

     UNCOMPRESSED {
       version         [  4 ];
       header_length   [  4 ];
       dscp            [  6 ];
       ecn             [  2 ];
       length          [ 16 ];
       id              [ 16 ];
       reserved        [  1 ];
       dont_frag       [  1 ];
       more_fragments  [  1 ];
       offset          [ 13 ];
       ttl             [  8 ];
       protocol        [  8 ];
       checksum        [ 16 ];
       src_addr        [ 32 ];
       dest_addr       [ 32 ];
     }
 The width of each field is indicated in square brackets.  This part
 of the notation is used in the example for illustration to help the
 reader's understanding.  However, indicating the field lengths in
 this way is optional since the width of each field can also normally
 be derived from the encoding that is used to compress/decompress it
 for a specific format.  This part of the notation is formally defined
 in Section 4.10.
 The next step is to specify the compressed format.  This includes the
 encodings for each field that map between the compressed and
 uncompressed forms of the field.  In the example, these encoding
 methods are mainly taken from the ROHC-FN library (see Section 4.11).
 Since the intention here is to illustrate the use of the notation,
 rather than to describe the optimum method of compressing IPv4
 headers, this example uses only three encoding methods.
 The "uncompressed_value" encoding method (defined in Section 4.11.1)
 can compress any field whose uncompressed length and value are fixed,
 or can be calculated using an expression.  No compressed bits need to
 be sent because the uncompressed field can be reconstructed using its
 known size and value.  The "uncompressed_value" encoding method is
 used to compress five fields in the IPv4 header, as described below:
     COMPRESSED {
       header_length  =:= uncompressed_value(4, 5);
       version        =:= uncompressed_value(4, 4);
       reserved       =:= uncompressed_value(1, 0);
       offset         =:= uncompressed_value(13, 0);
       more_fragments =:= uncompressed_value(1, 0);

Finking & Pelletier Standards Track [Page 11] RFC 4997 ROHC-FN July 2007

 The first parameter indicates the length of the uncompressed field in
 bits, and the second parameter gives its integer value.
 Note that the order of the fields in the compressed format is
 independent of the order of the fields in the uncompressed format.
 The "irregular" encoding method (defined in Section 4.11.3) can be
 used to encode any field for which both uncompressed attributes
 (ULENGTH and UVALUE) are defined, and whose ULENGTH attribute is
 either fixed or can be calculated using an expression.  It is a fail-
 safe encoding method that can be used for such fields in the case
 where no other encoding method applies.  All of the bits in the
 uncompressed form of the field are present in the compressed form as
 well; hence this encoding does not achieve any compression.
       src_addr       =:= irregular(32);
       dest_addr      =:= irregular(32);
       length         =:= irregular(16);
       id             =:= irregular(16);
       ttl            =:= irregular(8);
       protocol       =:= irregular(8);
       dscp           =:= irregular(6);
       ecn            =:= irregular(2);
       dont_frag      =:= irregular(1);
 Finally, the third encoding method is specific only to the
 uncompressed format defined above for the IPv4 header,
 "inferred_ip_v4_header_checksum":
       checksum       =:= inferred_ip_v4_header_checksum [ 0 ];
     }
   }
 The "inferred_ip_v4_header_checksum" encoding method is different
 from the other two encoding methods in that it is not defined in the
 ROHC-FN library of encoding methods.  Its definition could be given
 either by using the formal notation as part of the profile definition
 itself (see Section 4.12) or by using plain English text (see
 Section 4.13).
 In our example, the "inferred_ip_v4_header_checksum" is a specific
 encoding method that calculates the IP checksum from the rest of the
 header values.  Like the "uncompressed_value" encoding method, no
 compressed bits need to be sent, since the field value can be
 reconstructed at the decompressor.  This is notated explicitly by
 specifying, in square brackets, a length of 0 for the checksum field
 in the compressed format.  Again, this notation is optional since the
 encoding method itself would be defined as sending zero compressed

Finking & Pelletier Standards Track [Page 12] RFC 4997 ROHC-FN July 2007

 bits, however it is useful to the reader to include such notation
 (see Section 4.10 for details on this part of the notation).
 Finally the definition of the format is terminated with a closing
 brace.  At this point, the above example has defined a compressed
 format that can be used to represent the entire compressed IPv4
 header, and provides enough information to allow an implementation to
 construct the compressed format from an uncompressed format
 (compression) and vice versa (decompression).

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

Finking & Pelletier Standards Track [Page 13] RFC 4997 ROHC-FN July 2007

 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"

Finking & Pelletier Standards Track [Page 14] RFC 4997 ROHC-FN July 2007

 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

Finking & Pelletier Standards Track [Page 15] RFC 4997 ROHC-FN July 2007

 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.

Finking & Pelletier Standards Track [Page 16] RFC 4997 ROHC-FN July 2007

 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.

Finking & Pelletier Standards Track [Page 17] RFC 4997 ROHC-FN July 2007

 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

Finking & Pelletier Standards Track [Page 18] RFC 4997 ROHC-FN July 2007

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:

Finking & Pelletier Standards Track [Page 19] RFC 4997 ROHC-FN July 2007

    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.

Finking & Pelletier Standards Track [Page 20] RFC 4997 ROHC-FN July 2007

 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

Finking & Pelletier Standards Track [Page 21] RFC 4997 ROHC-FN July 2007

 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.

Finking & Pelletier Standards Track [Page 22] RFC 4997 ROHC-FN July 2007

 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:

Finking & Pelletier Standards Track [Page 23] RFC 4997 ROHC-FN July 2007

   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:

Finking & Pelletier Standards Track [Page 24] RFC 4997 ROHC-FN July 2007

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

Finking & Pelletier Standards Track [Page 25] RFC 4997 ROHC-FN July 2007

 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.

Finking & Pelletier Standards Track [Page 26] RFC 4997 ROHC-FN July 2007

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.

Finking & Pelletier Standards Track [Page 27] RFC 4997 ROHC-FN July 2007

 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.

Finking & Pelletier Standards Track [Page 28] RFC 4997 ROHC-FN July 2007

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

Finking & Pelletier Standards Track [Page 29] RFC 4997 ROHC-FN July 2007

 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.

Finking & Pelletier Standards Track [Page 30] RFC 4997 ROHC-FN July 2007

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

Finking & Pelletier Standards Track [Page 31] RFC 4997 ROHC-FN July 2007

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

Finking & Pelletier Standards Track [Page 32] RFC 4997 ROHC-FN July 2007

 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

Finking & Pelletier Standards Track [Page 33] RFC 4997 ROHC-FN July 2007

       ip_id;         // 16 bits
       src_addr;      // 32 bits
       dst_addr;      // 32 bits
       checksum;      // 16 bits
       length;        // 16 bits
     }
     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.

Finking & Pelletier Standards Track [Page 34] RFC 4997 ROHC-FN July 2007

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

Finking & Pelletier Standards Track [Page 35] RFC 4997 ROHC-FN July 2007

     }
 Here default bindings are specified for fields 1 to 3.  A default
 binding for the "ULENGTH" attribute of field_4 is also specified.
 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
     }

Finking & Pelletier Standards Track [Page 36] RFC 4997 ROHC-FN July 2007

     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.

Finking & Pelletier Standards Track [Page 37] RFC 4997 ROHC-FN July 2007

 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.

Finking & Pelletier Standards Track [Page 38] RFC 4997 ROHC-FN July 2007

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

Finking & Pelletier Standards Track [Page 39] RFC 4997 ROHC-FN July 2007

     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

Finking & Pelletier Standards Track [Page 40] RFC 4997 ROHC-FN July 2007

 specification itself.  Such profile-specific encoding methods,
 defined either in ROHC-FN syntax or rigorously in plain text, can be
 referred to in the ROHC-FN specification of the profile's formats in
 the same way as any method in the ROHC-FN library.
 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";

5. Security Considerations

 This document describes a formal notation similar to ABNF [RFC4234],
 and hence is not believed to raise any security issues (note that
 ABNF has a completely separate purpose to the ROHC formal notation).

6. Contributors

 Richard Price did much of the foundational work on the formal
 notation.  He authored the initial document describing a formal
 notation on which this document is based.
 Kristofer Sandlund contributed to this work by applying new ideas to
 the ROHC-TCP profile, by providing feedback, and by helping resolve
 different issues during the entire development of the notation.
 Carsten Bormann provided the translation of the formal notation
 syntax using ABNF in Appendix A, and also contributed with feedback
 and reviews to validate the completeness and correctness of the
 notation.

7. Acknowledgements

 A number of important concepts and ideas have been borrowed from ROHC
 [RFC3095].
 Thanks to Mark West, Eilert Brinkmann, Alan Ford, and Lars-Erik
 Jonsson for their contributions, reviews, and feedback that led to
 significant improvements to the readability, completeness, and
 overall quality of the notation.
 Thanks to Stewart Sadler, Caroline Daniels, Alan Finney, and David
 Findlay for their reviews and comments.  Thanks to Rob Hancock and
 Stephen McCann for their early work on the formal notation.  The

Finking & Pelletier Standards Track [Page 41] RFC 4997 ROHC-FN July 2007

 authors would also like to thank Christian Schmidt, Qian Zhang,
 Hongbin Liao, and Max Riegel for their comments and valuable input.
 Additional thanks: this document was reviewed during working group
 last-call by committed reviewers Mark West, Carsten Bormann, and Joe
 Touch, as well as by Sally Floyd who provided a review at the request
 of the Transport Area Directors.  Thanks also to Magnus Westerlund
 for his feedback in preparation for the IESG review.

8. References

8.1. Normative References

 [C90]      ISO/IEC, "ISO/IEC 9899:1990 Information technology --
            Programming Language C", ISO 9899:1990, April 1990.
 [RFC2822]  Resnick, P., Ed., "STANDARD FOR THE FORMAT OF ARPA
            INTERNET TEXT MESSAGES", RFC 2822, April 2001.
 [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", RFC 4234, October 2005.
 [RFC4995]  Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust
            Header Compression (ROHC) Framework", RFC 4995, July 2007.

8.2. Informative References

 [RFC3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
            Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
            K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
            Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
            Compression (ROHC): Framework and four profiles: RTP, UDP,
            ESP, and uncompressed", RFC 3095, July 2001.
 [RFC791]   University of Southern California, "DARPA INTERNET PROGRAM
            PROTOCOL SPECIFICATION", RFC 791, September 1981.

Finking & Pelletier Standards Track [Page 42] RFC 4997 ROHC-FN July 2007

Appendix A. Formal Syntax of ROHC-FN

 This section gives a definition of the syntax of ROHC-FN in ABNF
 [RFC4234], using "fnspec" as the start rule.
 ; overall structure
 fnspec     = S *(constdef S) [globctl S] 1*(methdef S)
 constdef   = constname S "=" S expn S ";"
 globctl    = CONTROL S formbody
 methdef    = id S [parmlist S] "{" S 1*(formatdef S) "}"
            / id S [parmlist S] STRQ *STRCHAR STRQ S ";"
 parmlist   = "(" S id S *( "," S id S ) ")"
 formatdef  = formhead S formbody
 formhead   = UNCOMPRESSED [ 1*WS id ]
            / COMPRESSED [ 1*WS id ]
            / CONTROL / INITIAL / DEFAULT
 formbody   = "{" S *((fielddef/enforcer) S) "}"
 fielddef   = fieldgroup S ["=:=" S encspec S] [lenspec S] ";"
 fieldgroup = fieldname *( S ":" S fieldname )
 fieldname  = id
 encspec    = "'" *("0"/"1") "'"
            / id [ S "(" S expn S *( "," S expn S ) ")"]
 lenspec    = "[" S expn S *("," S expn S) "]"
 enforcer   = ENFORCE S "(" S expn S ")" S ";"
 ; expressions
 expn  = *(expnb S "||" S) expnb
 expnb = *(expna S "&&" S) expna
 expna = *(expn7 S ("=="/"!=") S) expn7
 expn7 = *(expn6 S ("<"/"<="/">"/">=") S) expn6
 expn6 = *(expn4 S ("+"/"-") S) expn4
 expn4 = *(expn3 S ("*"/"/"/"%") S) expn3
 expn3 = expn2 [S "^" S expn3]
 expn2 = ["!" S] expn1
 expn1 = expn0 / attref / constname / litval / id
 expn0 = "(" S expn S ")" / VARIABLE
 attref       = fieldnameref "." attname
 fieldnameref = fieldname / THIS
 attname      = ( U / C ) ( LENGTH / VALUE )
 litval       = ["-"] "0b" 1*("0"/"1")
              / ["-"] "0x" 1*(DIGIT/"a"/"b"/"c"/"d"/"e"/"f")
              / ["-"] 1*DIGIT
              / false / true

Finking & Pelletier Standards Track [Page 43] RFC 4997 ROHC-FN July 2007

 ; lexical categories
 constname = UPCASE *(UPCASE / DIGIT / "_")
 id        = ALPHA *(ALPHA / DIGIT / "_")
 ALPHA     = %x41-5A / %x61-7A
 UPCASE    = %x41-5A
 DIGIT     = %x30-39
 COMMENT   = "//" *(SP / HTAB / VCHAR) CRLF
 SP        = %x20
 HTAB      = %x09
 VCHAR     = %x21-7E
 CRLF      = %x0A / %x0D.0A
 NL        = COMMENT / CRLF
 WS        = SP / HTAB / NL
 S         = *WS
 STRCHAR   = SP / HTAB / %x21 / %x23-7E
 STRQ      = %x22
 ; case-sensitive literals
 C            = %d67
 COMPRESSED   = %d67.79.77.80.82.69.83.83.69.68
 CONTROL      = %d67.79.78.84.82.79.76
 DEFAULT      = %d68.69.70.65.85.76.84
 ENFORCE      = %d69.78.70.79.82.67.69
 INITIAL      = %d73.78.73.84.73.65.76
 LENGTH       = %d76.69.78.71.84.72
 THIS         = %d84.72.73.83
 U            = %d85
 UNCOMPRESSED = %d85.78.67.79.77.80.82.69.83.83.69.68
 VALUE        = %d86.65.76.85.69
 VARIABLE     = %d86.65.82.73.65.66.76.69
 false        = %d102.97.108.115.101
 true         = %d116.114.117.101

Finking & Pelletier Standards Track [Page 44] RFC 4997 ROHC-FN July 2007

Appendix B. Bit-level Worked Example

 This section gives a worked example at the bit level, showing how a
 simple ROHC-FN specification describes the compression of real data
 from an imaginary protocol header.  The example used has been kept
 fairly simple, whilst still aiming to illustrate some of the
 intricacies that arise in use of the notation.  In particular, fields
 have been kept short to make it possible to read the binary
 representation of the headers without too much difficulty.

B.1. Example Packet Format

 Our imaginary header is just 16 bits long, and consists of the
 following fields:
 1.  version number -- 2 bits
 2.  type -- 2 bits
 3.  flow id -- 4 bits
 4.  sequence number -- 4 bits
 5.  flag bits -- 4 bits
 So for example 0101000100010000 indicates a header with a version
 number of one, a type of one, a flow id of one, a sequence number of
 one, and all flag bits set to zero.
 Here is an ASCII box notation diagram of the imaginary header:
   0   1   2   3   4   5   6   7
 +---+---+---+---+---+---+---+---+
 |version| type  |    flow_id    |
 +---+---+---+---+---+---+---+---+
 |  sequence_no  |   flag_bits   |
 +---+---+---+---+---+---+---+---+

Finking & Pelletier Standards Track [Page 45] RFC 4997 ROHC-FN July 2007

B.2. Initial Encoding

 An initial definition based solely on the above information is as
 follows:
   eg_header
   {
     UNCOMPRESSED {
       version_no   [ 2 ];
       type         [ 2 ];
       flow_id      [ 4 ];
       sequence_no  [ 4 ];
       flag_bits    [ 4 ];
     }
     COMPRESSED initial_definition {
       version_no  =:= irregular(2);
       type        =:= irregular(2);
       flow_id     =:= irregular(4);
       sequence_no =:= irregular(4);
       flag_bits   =:= irregular(4);
     }
   }
 This defines the format nicely, but doesn't actually offer any
 compression.  If we use it to encode the above header, we get:
   Uncompressed header: 0101000100010000
   Compressed header:   0101000100010000
 This is because we have stated that all fields are "irregular" --
 i.e., we haven't specified anything about their behaviour.
 Note that since we have only one compressed format and one
 uncompressed format, it makes no difference whether the encoding
 methods for each field are specified in the compressed or
 uncompressed format.  It would make no difference at all if we wrote
 the following instead:
   eg_header
   {
     UNCOMPRESSED {
       version_no  =:= irregular(2);
       type        =:= irregular(2);
       flow_id     =:= irregular(4);
       sequence_no =:= irregular(4);
       flag_bits   =:= irregular(4);
     }

Finking & Pelletier Standards Track [Page 46] RFC 4997 ROHC-FN July 2007

     COMPRESSED initial_definition {
       version_no   [ 2 ];
       type         [ 2 ];
       flow_id      [ 4 ];
       sequence_no  [ 4 ];
       flag_bits    [ 4 ];
     }
   }

B.3. Basic Compression

 In order to achieve any compression we need to notate more knowledge
 about the header and its behaviour in a flow.  For example, we may
 know the following facts about the header:
 1.  version number -- indicates which version of the protocol this
     is: always one for this version of the protocol.
 2.  type -- may take any value.
 3.  flow id -- may take any value.
 4.  sequence number -- make take any value.
 5.  flag bits -- contains three flags, a, b, and c, each of which may
     be set or clear, and a reserved flag bit, which is always clear
     (i.e., zero).
 We could notate this knowledge as follows:
   eg_header
   {
     UNCOMPRESSED {
       version_no     [ 2 ];
       type           [ 2 ];
       flow_id        [ 4 ];
       sequence_no    [ 4 ];
       abc_flag_bits  [ 3 ];
       reserved_flag  [ 1 ];
     }
     COMPRESSED basic {
       version_no    =:= uncompressed_value(2, 1)  [ 0 ];
       type          =:= irregular(2)              [ 2 ];
       flow_id       =:= irregular(4)              [ 4 ];
       sequence_no   =:= irregular(4)              [ 4 ];
       abc_flag_bits =:= irregular(3)              [ 3 ];
       reserved_flag =:= uncompressed_value(1, 0)  [ 0 ];

Finking & Pelletier Standards Track [Page 47] RFC 4997 ROHC-FN July 2007

     }
   }
 Using this simple scheme, we have successfully encoded the fact that
 one of the fields has a permanently fixed value of one, and therefore
 contains no useful information.  We have also encoded the fact that
 the final flag bit is always zero, which again contains no useful
 information.  Both of these facts have been notated using the
 "uncompressed_value" encoding method (see Section 4.11.1).
 Using this new encoding on the above header, we get:
   Uncompressed header: 0101000100010000
   Compressed header:   0100010001000
 This reduces the amount of data we need to transmit by roughly 20%.
 However, this encoding fails to take advantage of relationships
 between values of a field in one packet and its value in subsequent
 packets.  For example, every header in the following sequence is
 compressed by the same amount despite the similarities between them:
   Uncompressed header: 0101000100010000
   Compressed header:   0100010001000
   Uncompressed header: 0101000101000000
   Compressed header:   0100010100000
   Uncompressed header: 0110000101110000
   Compressed header:   1000010111000

B.4. Inter-Packet Compression

 The profile we have defined so far has not compressed the sequence
 number or flow ID fields at all, since they can take any value.
 However the value of each of these fields in one header has a very
 simple relationship to their values in previous headers:
 o  the sequence number is unusual -- it increases by three each time,
 o  the flow_id stays the same -- it always has the same value that it
    did in the previous header in the flow,
 o  the abc_flag_bits stay the same most of the time -- they usually
    have the same value that they did in the previous header in the
    flow.

Finking & Pelletier Standards Track [Page 48] RFC 4997 ROHC-FN July 2007

 An obvious way of notating this is as follows:
   // This obvious encoding will not work (correct encoding below)
   eg_header
   {
     UNCOMPRESSED {
       version_no     [ 2 ];
       type           [ 2 ];
       flow_id        [ 4 ];
       sequence_no    [ 4 ];
       abc_flag_bits  [ 3 ];
       reserved_flag  [ 1 ];
     }
     COMPRESSED obvious {
       version_no    =:= uncompressed_value(2, 1);
       type          =:= irregular(2);
       flow_id       =:= static;
       sequence_no   =:= lsb(0, -3);
       abc_flag_bits =:= irregular(3);
       reserved_flag =:= uncompressed_value(1, 0);
     }
   }
 The dependency on previous packets is notated using the "static" and
 "lsb" encoding methods (see Section 4.11.4 and Section 4.11.5
 respectively).  However there are a few problems with the above
 notation.
 Firstly, and most importantly, the "flow_id" field is notated as
 "static", which means that it doesn't change from packet to packet.
 However, the notation does not indicate how to communicate the value
 of the field initially.  There is no point saying "it's the same
 value as last time" if there has not been a first time where we
 define what that value is, so that it can be referred back to.  The
 above notation provides no way of communicating that.  Similarly with
 the sequence number -- there needs to be a way of communicating its
 initial value.  In fact, except for the explicit notation indicating
 their lengths, even the lengths of these two fields would be left
 undefined.  This problem will be solved below, in Appendix B.5.
 Secondly, the sequence number field is communicated very efficiently
 in zero bits, but it is not at all robust against packet loss.  If a
 packet is lost then there is no way to handle the missing sequence
 number.  When communicating sequence numbers, or any other field
 encoded with "lsb" encoding, a very important consideration for the
 notator is how robust against packet loss the compressed protocol
 should be.  This will vary a lot from protocol stack to protocol

Finking & Pelletier Standards Track [Page 49] RFC 4997 ROHC-FN July 2007

 stack.  For the example protocol we'll assume short, low overhead
 flows and say we need to be robust to the loss of just one packet,
 which we can achieve with two bits of "lsb" encoding (one bit isn't
 enough since the sequence number increases by three each time -- see
 Section 4.11.5).  This will be addressed below in Appendix B.5.
 Finally, although the flag bits are usually the same as in the
 previous header in the flow, the profile doesn't make any use of this
 fact; since they are sometimes not the same as those in the previous
 header, it is not safe to say that they are always the same, so
 "static" encoding can't be used exclusively.  This problem will be
 solved later through the use of multiple formats in Appendix B.6.

B.5. Specifying Initial Values

 To communicate initial values for fields compressed with a context
 dependent encoding such as "static" or "lsb" we use an "INITIAL"
 field list.  This can help with fields whose start value is fixed and
 known.  For example, if we knew that at the start of the flow that
 "flow_id" would always be 1 and "sequence_no" would always be 0, we
 could notate that like this:
   // This encoding will not work either (correct encoding below)
   eg_header
   {
     UNCOMPRESSED {
       version_no     [ 2 ];
       type           [ 2 ];
       flow_id        [ 4 ];
       sequence_no    [ 4 ];
       abc_flag_bits  [ 3 ];
       reserved_flag  [ 1 ];
     }
     INITIAL {
       // set initial values of fields before flow starts
       flow_id     =:= uncompressed_value(4, 1);
       sequence_no =:= uncompressed_value(4, 0);
     }
     COMPRESSED obvious {
       version_no    =:= uncompressed_value(2, 1);
       type          =:= irregular(2);
       flow_id       =:= static;
       sequence_no   =:= lsb(2, -3);
       abc_flag_bits =:= irregular(3);
       reserved_flag =:= uncompressed_value(1, 0);
     }

Finking & Pelletier Standards Track [Page 50] RFC 4997 ROHC-FN July 2007

   }
 However, this use of "INITIAL" is no good since the initial values of
 both "flow_id" and "sequence_no" vary from flow to flow.  "INITIAL"
 is only applicable where the initial value of a field is fixed, as is
 often the case with control fields.

B.6. Multiple Packet Formats

 To communicate initial values for the sequence number and flow ID
 fields correctly, and to take advantage of the fact that the flag
 bits are usually the same as in the previous header, we need to
 depart from the single format encoding we are currently using and
 instead use multiple formats.  Here, we have expressed the encodings
 for two of the fields in the uncompressed format, since they will
 always be true for uncompressed headers of that format.  The
 remaining fields, whose encoding method may depend on exactly how the
 header is being compressed, have their encodings specified in the
 compressed formats.
   eg_header
   {
     UNCOMPRESSED {
       version_no    =:= uncompressed_value(2, 1) [ 2 ];
       type                                       [ 2 ];
       flow_id                                    [ 4 ];
       sequence_no                                [ 4 ];
       abc_flag_bits                              [ 3 ];
       reserved_flag =:= uncompressed_value(1, 0) [ 1 ];
     }
     COMPRESSED irregular_format {
       discriminator =:= '0'          [ 1 ];
       version_no                     [ 0 ];
       type          =:= irregular(2) [ 2 ];
       flow_id       =:= irregular(4) [ 4 ];
       sequence_no   =:= irregular(4) [ 4 ];
       abc_flag_bits =:= irregular(3) [ 3 ];
       reserved_flag                  [ 0 ];
     }
     COMPRESSED compressed_format {
       discriminator =:= '1'          [ 1 ];
       version_no                     [ 0 ];
       type          =:= irregular(2) [ 2 ];
       flow_id       =:= static       [ 0 ];
       sequence_no   =:= lsb(2, -3)   [ 2 ];

Finking & Pelletier Standards Track [Page 51] RFC 4997 ROHC-FN July 2007

       abc_flag_bits =:= static       [ 0 ];
       reserved_flag                  [ 0 ];
     }
   }
 Note that we have added a discriminator field, so that the
 decompressor can tell which format has been used by the compressor.
 The format with a "static" flow ID and "lsb" encoded sequence number
 is now 5 bits long.  Note that despite having to add the
 discriminator field, this format is still the same size as the
 original incorrect "obvious" format because it takes advantage of the
 fact that the abc flag bits rarely change.
 However, the original "basic" format has also grown by one bit due to
 the addition of the discriminator ("irregular_format").  An important
 consideration when creating multiple formats is whether each format
 occurs frequently enough that the average compressed header length is
 shorter as a result of its usage.  For example, if in fact the flag
 bits always changed between packets, the "compressed_format" encoding
 could never be used; all we would have achieved is lengthening the
 "basic" format by one bit.
 Using the above notation, we now get:
   Uncompressed header: 0101000100010000
   Compressed header:   00100010001000
   Uncompressed header: 0101000101000000
   Compressed header:   10100 ; 00100010100000
   Uncompressed header: 0110000101110000
   Compressed header:   11011 ; 01000010111000
 The first header in the stream is compressed the same way as before,
 except that it now has the extra 1-bit discriminator at the start
 (0).  When a second header arrives with the same flow ID as the first
 and its sequence number three higher, it can be compressed in two
 possible ways: either by using "compressed_format" or, in the same
 way as previously, by using "irregular_format".
 Note that we show all theoretically possible encodings of a header as
 defined by the ROHC-FN specification, separated by semi-colons.
 Either of the above encodings for each header could be produced by a
 valid implementation, although a good implementation would always aim
 to pick the encoding that leads to the best compression.  A good
 implementation would also take robustness into account and therefore

Finking & Pelletier Standards Track [Page 52] RFC 4997 ROHC-FN July 2007

 probably wouldn't assume on the second packet that the decompressor
 had available the context necessary to decompress the shorter
 "compressed_format" form.
 Finally, note that the fields whose encoding methods are specified in
 the uncompressed format have zero length when compressed.  This means
 their position in the compressed format is not significant.  In this
 case, there is no need to notate them when defining the compressed
 formats.  In the next part of the example we will see that they have
 been removed from the compressed formats altogether.

B.7. Variable Length Discriminators

 Suppose we do some analysis on flows of our example protocol and
 discover that whilst it is usual for successive packets to have the
 same flags, on the occasions when they don't, the packet is almost
 always a "flags set" packet in which all three of the abc flags are
 set.  To encode the flow more efficiently a format needs to be
 written to reflect this.
 This now gives a total of three formats, which means we need three
 discriminators to differentiate between them.  The obvious solution
 here is to increase the number of bits in the discriminator from one
 to two and use discriminators 00, 01, and 10 for example.  However we
 can do slightly better than this.
 Any uniquely identifiable discriminator will suffice, so we can use
 00, 01, and 1.  If the discriminator starts with 1, that's the whole
 thing.  If it starts with 0, the decompressor knows it has to check
 one more bit to determine the kind of format.
 Note that care must be taken when using variable length
 discriminators.  For example, it would be erroneous to use 0, 01, and
 10 as discriminators since after reading an initial 0, the
 decompressor would have no way of knowing if the next bit was a
 second bit of discriminator, or the first bit of the next field in
 the format.  However, 0, 10, and 11 would be correct, as the first
 bit again indicates whether or not there are further discriminator
 bits to follow.

Finking & Pelletier Standards Track [Page 53] RFC 4997 ROHC-FN July 2007

 This gives us the following:
   eg_header
   {
     UNCOMPRESSED {
       version_no    =:= uncompressed_value(2, 1) [ 2 ];
       type                                       [ 2 ];
       flow_id                                    [ 4 ];
       sequence_no                                [ 4 ];
       abc_flag_bits                              [ 3 ];
       reserved_flag =:= uncompressed_value(1, 0) [ 1 ];
     }
     COMPRESSED irregular_format {
       discriminator =:= '00'         [ 2 ];
       type          =:= irregular(2) [ 2 ];
       flow_id       =:= irregular(4) [ 4 ];
       sequence_no   =:= irregular(4) [ 4 ];
       abc_flag_bits =:= irregular(3) [ 3 ];
     }
     COMPRESSED flags_set {
       discriminator =:= '01'                     [ 2 ];
       type          =:= irregular(2)             [ 2 ];
       flow_id       =:= static                   [ 0 ];
       sequence_no   =:= lsb(2, -3)               [ 2 ];
       abc_flag_bits =:= uncompressed_value(3, 7) [ 0 ];
     }
     COMPRESSED flags_static {
       discriminator =:= '1'          [ 1 ];
       type          =:= irregular(2) [ 2 ];
       flow_id       =:= static       [ 0 ];
       sequence_no   =:= lsb(2, -3)   [ 2 ];
       abc_flag_bits =:= static       [ 0 ];
     }
   }
 Here is some example output:
   Uncompressed header: 0101000100010000
   Compressed header:   000100010001000
   Uncompressed header: 0101000101000000
   Compressed header:   10100 ; 000100010100000

Finking & Pelletier Standards Track [Page 54] RFC 4997 ROHC-FN July 2007

   Uncompressed header: 0110000101110000
   Compressed header:   11011 ; 001000010111000
   Uncompressed header: 0111000110101110
   Compressed header:   011110 ; 001100011010111
 Here we have a very similar sequence to last time, except that there
 is now an extra message on the end that has the flag bits set.  The
 encoding for the first message in the stream is now one bit larger,
 the encoding for the next two messages is the same as before, since
 that format has not grown; thanks to the use of variable length
 discriminators.  Finally, the packet that comes through with all the
 flag bits set can be encoded in just six bits, only one bit more than
 the most common format.  Without the extra format, this last packet
 would have to be encoded using the longest format and would have
 taken up 14 bits.

B.8. Default Encoding

 Some of the common encoding methods used so far have been "factored
 out" into the definition of the uncompressed format, meaning that
 they don't need to be defined for every compressed format.  However,
 there is still some redundancy in the notation.  For a number of
 fields, the same encoding method is used several times in different
 formats (though not necessarily in all of them), but the field
 encoding is redefined explicitly each time.  If the encoding for any
 of these fields changed in the future, then every format that uses
 that encoding would have to be modified to reflect this change.
 This problem can be avoided by specifying default encoding methods
 for these fields.  Doing so can also lead to a more concisely notated
 profile:
   eg_header
   {
     UNCOMPRESSED {
       version_no    =:= uncompressed_value(2, 1) [ 2 ];
       type                                       [ 2 ];
       flow_id                                    [ 4 ];
       sequence_no                                [ 4 ];
       abc_flag_bits                              [ 3 ];
       reserved_flag =:= uncompressed_value(1, 0) [ 1 ];
     }
     DEFAULT {
       type          =:= irregular(2);
       flow_id       =:= static;

Finking & Pelletier Standards Track [Page 55] RFC 4997 ROHC-FN July 2007

       sequence_no   =:= lsb(2, -3);
     }
     COMPRESSED irregular_format {
       discriminator =:= '00'         [ 2 ];
       type                           [ 2 ]; // Uses default
       flow_id       =:= irregular(4) [ 4 ]; // Overrides default
       sequence_no   =:= irregular(4) [ 4 ]; // Overrides default
       abc_flag_bits =:= irregular(3) [ 3 ];
     }
     COMPRESSED flags_set {
       discriminator =:= '01' [ 2 ];
       type                   [ 2 ]; // Uses default
       sequence_no            [ 2 ]; // Uses default
       abc_flag_bits =:= uncompressed_value(3, 7);
     }
     COMPRESSED flags_static {
       discriminator =:= '1' [ 1 ];
       type                  [ 2 ]; // Uses default
       sequence_no           [ 2 ]; // Uses default
       abc_flag_bits =:= static;
     }
   }
 The above profile behaves in exactly the same way as the one notated
 previously, since it has the same meaning.  Note that the purpose
 behind the different formats becomes clearer with the default
 encoding methods factored out: all that remains are the encodings
 that are specific to each format.  Note also that default encoding
 methods that compress down to zero bits have become completely
 implicit.  For example the compressed formats using the default
 encoding for "flow_id" don't mention it (the default is "static"
 encoding that compresses to zero bits).

B.9. Control Fields

 One inefficiency in the compression scheme we have produced thus far
 is that it uses two bits to provide the "lsb" encoded sequence number
 with robustness for the loss of just one packet.  In theory, only one
 bit should be needed.  The root of the problem is the unusual
 sequence number that the protocol uses -- it counts up in increments
 of three.  In order to encode it at maximum efficiency we need to
 translate this into a field that increments by one each time.  We do
 this using a control field.

Finking & Pelletier Standards Track [Page 56] RFC 4997 ROHC-FN July 2007

 A control field is extra data that is communicated in the compressed
 format, but which is not a direct encoding of part of the
 uncompressed header.  Control fields can be used to communicate extra
 information in the compressed format, that allows other fields to be
 compressed more efficiently.
 The control field that we introduce scales the sequence number down
 by a factor of three.  Instead of encoding the original sequence
 number in the compressed packet, we encode the scaled sequence
 number, allowing us to have robustness to the loss of one packet by
 using just one bit of "lsb" encoding:
   eg_header
   {
     UNCOMPRESSED {
       version_no    =:= uncompressed_value(2, 1) [ 2 ];
       type                                       [ 2 ];
       flow_id                                    [ 4 ];
       sequence_no                                [ 4 ];
       abc_flag_bits                              [ 3 ];
       reserved_flag =:= uncompressed_value(1, 0) [ 1 ];
     }
     CONTROL {
       // need modulo maths to calculate scaling correctly,
       // due to 4 bit wrap around
       scaled_seq_no   [ 4 ];
       ENFORCE(sequence_no.UVALUE
                 == (scaled_seq_no.UVALUE * 3) % 16);
     }
     DEFAULT {
       type          =:= irregular(2);
       flow_id       =:= static;
       scaled_seq_no =:= lsb(1, -1);
     }
     COMPRESSED irregular_format {
       discriminator =:= '00'         [ 2 ];
       type                           [ 2 ];
       flow_id       =:= irregular(4) [ 4 ];
       scaled_seq_no =:= irregular(4) [ 4 ]; // Overrides default
       abc_flag_bits =:= irregular(3) [ 3 ];
     }
     COMPRESSED flags_set {
       discriminator =:= '01' [ 2 ];
       type                   [ 2 ];

Finking & Pelletier Standards Track [Page 57] RFC 4997 ROHC-FN July 2007

       scaled_seq_no          [ 1 ]; // Uses default
       abc_flag_bits =:= uncompressed_value(3, 7);
     }
     COMPRESSED flags_static {
       discriminator =:= '1' [ 1 ];
       type                  [ 2 ];
       scaled_seq_no         [ 1 ]; // Uses default
       abc_flag_bits =:= static;
     }
   }
 Normally, the encoding method(s) used to encode a field specifies the
 length of the field.  In the above notation, since there is no
 encoding method using "sequence_no" directly, its length needs to be
 defined explicitly using an "ENFORCE" statement.  This is done using
 the abbreviated syntax, both for consistency and also for ease of
 readability.  Note that this is unusual: whereas the majority of
 field length indications are redundant (and thus optional), this one
 isn't.  If it was removed from the above notation, the length of the
 "sequence_no" field would be undefined.
 Here is some example output:
   Uncompressed header: 0101000100010000
   Compressed header:   000100011011000
   Uncompressed header: 0101000101000000
   Compressed header:   1010 ; 000100011100000
   Uncompressed header: 0110000101110000
   Compressed header:   1101 ; 001000011101000
   Uncompressed header: 0111000110101110
   Compressed header:   01110 ; 001100011110111
 In this form, we see that this gives us a saving of a further bit in
 most packets.  Assuming the bulk of a flow is made up of
 "flags_static" headers, the mean size of the headers in a compressed
 flow is now just over a quarter of their size in an uncompressed
 flow.

Finking & Pelletier Standards Track [Page 58] RFC 4997 ROHC-FN July 2007

B.10. Use of "ENFORCE" Statements as Conditionals

 Earlier, we created a new format "flags_set" to handle packets with
 all three of the flag bits set.  As it happens, these three flags are
 always all set for "type 3" packets, and are never all set for other
 packet types (a "type 3" packet is one where the type field is set to
 three).
 This allows extra efficiency in encoding such packets.  We know the
 type is three, so we don't need to encode the type field in the
 compressed header.  The type field was previously encoded as
 "irregular(2)", which is two bits long.  Removing this reduces the
 size of the "flags_set" format from five bits to three, making it the
 smallest format in the encoding method definition.
 In order to notate that the "flags_set" format should only be used
 for "type 3" headers, and the "flags_static" format only when the
 type isn't three, it is necessary to state these conditions inside
 each format.  This can be done with an "ENFORCE" statement:
   eg_header
   {
     UNCOMPRESSED {
       version_no    =:= uncompressed_value(2, 1) [ 2 ];
       type                                       [ 2 ];
       flow_id                                    [ 4 ];
       sequence_no                                [ 4 ];
       abc_flag_bits                              [ 3 ];
       reserved_flag =:= uncompressed_value(1, 0) [ 1 ];
     }
     CONTROL {
       // need modulo maths to calculate scaling correctly,
       // due to 4 bit wrap around
       scaled_seq_no   [ 4 ];
       ENFORCE(sequence_no.UVALUE
                 == (scaled_seq_no.UVALUE * 3) % 16);
     }
     DEFAULT {
       type          =:= irregular(2);
       scaled_seq_no =:= lsb(1, -1);
       flow_id       =:= static;
     }
     COMPRESSED irregular_format {
       discriminator =:= '00'         [ 2 ];
       type                           [ 2 ];

Finking & Pelletier Standards Track [Page 59] RFC 4997 ROHC-FN July 2007

       flow_id       =:= irregular(4) [ 4 ];
       scaled_seq_no =:= irregular(4) [ 4 ];
       abc_flag_bits =:= irregular(3) [ 3 ];
     }
     COMPRESSED flags_set {
       ENFORCE(type.UVALUE == 3); // redundant condition
       discriminator =:= '01'                      [ 2 ];
       type          =:= uncompressed_value(2, 3)  [ 0 ];
       scaled_seq_no                               [ 1 ];
       abc_flag_bits =:= uncompressed_value(3, 7)  [ 0 ];
     }
     COMPRESSED flags_static {
       ENFORCE(type.UVALUE != 3);
       discriminator =:= '1'    [ 1 ];
       type                     [ 2 ];
       scaled_seq_no            [ 1 ];
       abc_flag_bits =:= static [ 0 ];
     }
   }
 The two "ENFORCE" statements in the last two formats act as "guards".
 Guards prevent formats from being used under the wrong circumstances.
 In fact, the "ENFORCE" statement in "flags_set" is redundant.  The
 condition it guards for is already enforced by the new encoding
 method used for the "type" field.  The encoding method
 "uncompressed_value(2,3)" binds the "UVALUE" attribute to three.
 This is exactly what the "ENFORCE" statement does, so it can be
 removed without any change in meaning.  The "uncompressed_value"
 encoding method on the other hand is not redundant.  It specifies
 other bindings on the type field in addition to the one that the
 "ENFORCE" statement specifies.  Therefore it would not be possible to
 remove the encoding method and leave just the "ENFORCE" statement.
 Note that a guard is solely preventative.  A guard can never force a
 format to be chosen by the compressor.  A format can only be
 guaranteed to be chosen in a given situation if there are no other
 formats that can be used instead.  This is demonstrated in the
 example output below.  The compressor can still choose the
 "irregular" format if it wishes:
   Uncompressed header: 0101000100010000
   Compressed header:   000100011011000
   Uncompressed header: 0101000101000000
   Compressed header:   1010 ; 000100011100000

Finking & Pelletier Standards Track [Page 60] RFC 4997 ROHC-FN July 2007

   Uncompressed header: 0110000101110000
   Compressed header:   1101 ; 001000011101000
   Uncompressed header: 0111000110101110
   Compressed header:   010 ; 001100011110111
 This saves just two extra bits (a 7% saving) in the example flow.

Authors' Addresses

 Robert Finking
 Siemens/Roke Manor Research
 Old Salisbury Lane
 Romsey, Hampshire  SO51 0ZN
 UK
 Phone: +44 (0)1794 833189
 EMail: robert.finking@roke.co.uk
 URI:   http://www.roke.co.uk
 Ghyslain Pelletier
 Ericsson
 Box 920
 Lulea  SE-971 28
 Sweden
 Phone: +46 (0) 8 404 29 43
 EMail: ghyslain.pelletier@ericsson.com

Finking & Pelletier Standards Track [Page 61] RFC 4997 ROHC-FN July 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Finking & Pelletier Standards Track [Page 62]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4997.txt · Last modified: 2007/07/27 23:35 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki