5.  Compressor and Decompressor Logic (Normative)

5.1.  Context Initialization

   The static context of ROHC-TCP flows can be initialized in either of
   two ways:

   1.  By using an IR packet as in Section 7.1, where the profile number
       is 0x06 and the static chain ends with the static part of a TCP
       header.

   2.  By replicating an existing context using the mechanism defined by
       [RFC4164].  This is done with the IR-CR packet defined in
       Section 7.2, where the profile number is 0x06.

5.2.  Compressor Operation

5.2.1.  Compression Logic

   The task of the compressor is to determine what data must be sent
   when compressing a TCP/IP packet, so that the decompressor can
   successfully reconstruct the original packet based on its current
   state.  The selection of the type of compressed header to send thus
   depends on a number of factors, including:

   o  The change behavior of header fields in the flow, e.g., conveying
      the necessary information within the restrictions of the set of
      available packet formats.

   o  The compressor's level of confidence regarding decompressor state,
      e.g., by selecting header formats updating the same type of
      information for a number of consecutive packets or from the
      reception of decompressor feedback (ACKs and/or NACKs).

   o  Additional robustness required for the flow, e.g., periodic
      refreshes of static and dynamic information using IR and IR-DYN
      packets when decompressor feedback is not expected.

   The impact of these factors on the compressor's packet type selection
   is described in more detail in the following subsections.

   In this section, a "higher compression state" means that less data
   will be sent in compressed packets, i.e., smaller compressed headers
   are used, while a lower compression state means that a larger amount
   of data will be sent using larger compressed headers.

5.2.1.1.  Optimistic Approach

   The optimistic approach is the principle by which a compressor sends
   the same type of information for a number of packets (consecutively
   or not) until it is fairly confident that the decompressor has
   received the information.  The optimistic approach is useful to
   ensure robustness when ROHC-TCP is used to compress packets over
   lossy links.

   Therefore, if field X in the uncompressed packet changes value, the
   compressor MUST use a packet type that contains an encoding for field
   X until it has gained confidence that the decompressor has received
   at least one packet containing the new value for X.  The compressor
   SHOULD choose a compressed format with the smallest header that can
   convey the changes needed to fulfill the optimistic approach
   condition used.

5.2.1.2.  Periodic Context Refreshes

   When the optimistic approach is used, there will always be a
   possibility of decompression failures since the decompressor may not
   have received sufficient information for correct decompression.

   Therefore, until the decompressor has established a feedback channel,
   the compressor SHOULD periodically move to a lower compression state
   and send IR and/or IR-DYN packets.  These refreshes can be based on
   timeouts, on the number of compressed packets sent for the flow, or
   any other strategy specific to the implementation.  Once the feedback
   channel is established, the decompressor MAY stop performing periodic
   refreshes.

5.2.2.  Feedback Logic

   The semantics of feedback messages, acknowledgments (ACKs) and
   negative acknowledgments (NACKs or STATIC-NACKs), are defined in
   Section 5.2.4.1 of [RFC5795].

5.2.2.1.  Optional Acknowledgments (ACKs)

   The compressor MAY use acknowledgment feedback (ACKs) to move to a
   higher compression state.

   Upon reception of an ACK for a context-updating packet, the
   compressor obtains confidence that the decompressor has received the
   acknowledged packet and that it has observed changes in the packet
   flow up to the acknowledged packet.

   This functionality is optional, so a compressor MUST NOT expect to
   get such ACKs, even if a feedback channel is available and has been
   established for that flow.

5.2.2.2.  Negative Acknowledgments (NACKs)

   The compressor uses feedback from the decompressor to move to a lower
   compression state (NACKs).

   On reception of a NACK feedback, the compressor SHOULD:

   o  assume that only the static part of the decompressor is valid, and

   o  re-send all dynamic information (via an IR or IR-DYN packet) the
      next time it compresses a packet for the indicated flow

   unless it has confidence that information sent after the packet being
   acknowledged already provides a suitable response to the NACK
   feedback.  In addition, the compressor MAY use a CO packet carrying a
   7-bit Cyclic Redundancy Check (CRC) if it can determine with enough
   confidence what information provides a suitable response to the NACK
   feedback.

   On reception of a STATIC-NACK feedback, the compressor SHOULD:

   o  assume that the decompressor has no valid context, and

   o  re-send all static and all dynamic information (via an IR packet)
      the next time it compresses a packet for the indicated flow

   unless it has confidence that information sent after the packet that
   is being acknowledged already provides a suitable response to the
   STATIC-NACK feedback.

5.2.3.  Context Replication

   A compressor MAY support context replication by implementing the
   additional compression and feedback logic defined in [RFC4164].

5.3.  Decompressor Operation

5.3.1.  Decompressor States and Logic

   The three states of the decompressor are No Context (NC), Static
   Context (SC), and Full Context (FC).  The decompressor starts in its
   lowest compression state, the NC state.  Successful decompression
   will always move the decompressor to the FC state.  The decompressor
   state machine normally never leaves the FC state once it has entered
   this state; only repeated decompression failures will force the
   decompressor to transit downwards to a lower state.

   Below is the state machine for the decompressor.  Details of the
   transitions between states and decompression logic are given in the
   subsections following the figure.

                                 Success
                +-->------>------>------>------>------>--+
                |                                        |
    No Static   |            No Dynamic        Success   |    Success
     +-->--+    |             +-->--+      +--->----->---+    +-->--+
     |     |    |             |     |      |             |    |     |
     |     v    |             |     v      |             v    |     v
   +-----------------+   +---------------------+   +-------------------+
   | No Context (NC) |   | Static Context (SC) |   | Full Context (FC) |
   +-----------------+   +---------------------+   +-------------------+
      ^                         |        ^                         |
      |  Static Context         |        | Context Damage Assumed  |
      |  Damage Assumed         |        |                         |
      +-----<------<------<-----+        +-----<------<------<-----+

5.3.1.1.  Reconstruction and Verification

   When decompressing an IR or an IR-DYN packet, the decompressor MUST
   validate the integrity of the received header using CRC-8 validation
   [RFC5795].  If validation fails, the packet MUST NOT be delivered to
   upper layers.

   Upon receiving an IR-CR packet, the decompressor MUST perform the
   actions as specified in [RFC4164].

   When decompressing other packet types (e.g., CO packets), the
   decompressor MUST validate the outcome of the decompression attempt
   using CRC verification [RFC5795].  If verification fails, a
   decompressor implementation MAY attempt corrective or repair measures
   on the packet, and the result of any attempt MUST be validated using
   the CRC verification; otherwise, the packet MUST NOT be delivered to
   upper layers.

   When the CRC-8 validation or the CRC verification of the received
   header is successful, the decompressor SHOULD update its context with
   the information received in the current header; the decompressor then
   passes the reconstructed packet to the system's network layer.
   Otherwise, the decompressor context MUST NOT be updated.

   If the received packet is older than the current reference packet,
   e.g., based on the master sequence number (MSN) in the compressed
   packet, the decompressor MAY refrain from updating the context using
   the information received in the current packet, even if the
   correctness of its header was successfully verified.

5.3.1.2.  Detecting Context Damage

   All header formats carry a CRC and are context updating.  A packet
   for which the CRC succeeds updates the reference values of all header
   fields, either explicitly (from the information about a field carried
   within the compressed header) or implicitly (fields that are inferred
   from other fields).

   The decompressor may assume that some or the entire context is
   invalid, following one or more failures to validate or verify a
   header using the CRC.  Because the decompressor cannot know the exact
   reason(s) for a CRC failure or what field caused it, the validity of
   the context hence does not refer to what exact context entry is
   deemed valid or not.

   Validity of the context rather relates to the detection of a problem
   with the context.  The decompressor first assumes that the type of
   information that most likely caused the failure(s) is the state that
   normally changes for each packet, i.e., context damage of the dynamic
   part of the context.  Upon repeated failures and unsuccessful
   repairs, the decompressor then assumes that the entire context,
   including the static part, needs to be repaired, i.e., static context
   damage.

   Context Damage Detection

      The assumption of context damage means that the decompressor will
      not attempt decompression of a CO header that carries a 3-bit CRC,
      and only attempt decompression of IR, IR-DYN, or IR-CR headers or
      CO headers protected by a CRC-7.

   Static Context Damage Detection

      The assumption of static context damage means that the
      decompressor refrains from attempting decompression of any type of
      header other than the IR header.

   How these assumptions are made, i.e., how context damage is detected,
   is open to implementations.  It can be based on the residual error
   rate, where a low error rate makes the decompressor assume damage
   more often than on a high-rate link.

   The decompressor implements these assumptions by selecting the type
   of compressed header for which it may attempt decompression.  In
   other words, validity of the context refers to the ability of a
   decompressor to attempt or not attempt decompression of specific
   packet types.

5.3.1.3.  No Context (NC) State

   Initially, while working in the No Context (NC) state, the
   decompressor has not yet successfully decompressed a packet.

   Allowing decompression:

      In the NC state, only packets carrying sufficient information on
      the static fields (IR and IR-CR packets) can be decompressed;
      otherwise, the packet MUST NOT be decompressed and MUST NOT be
      delivered to upper layers.

   Feedback logic:

      In the NC state, the decompressor should send a STATIC-NACK if a
      packet of a type other than IR is received, or if decompression of
      an IR packet has failed, subject to the feedback rate limitation
      as described in Section 5.3.2.

   Once a packet has been validated and decompressed correctly, the
   decompressor MUST transit to the FC state.

5.3.1.4.  Static Context (SC) State

   When the decompressor is in the Static Context (SC) state, only the
   static part of the decompressor context is valid.

   From the SC state, the decompressor moves back to the NC state if
   static context damage is detected.

   Allowing decompression:

      In the SC state, packets carrying sufficient information on the
      dynamic fields covered by an 8-bit CRC (e.g., IR and IR-DYN) or CO
      packets covered by a 7-bit CRC can be decompressed; otherwise, the
      packet MUST NOT be decompressed and MUST NOT be delivered to upper
      layers.

   Feedback logic:

      In the SC state, the decompressor should send a STATIC-NACK if CRC
      validation of an IR/IR-DYN/IR-CR fails and static context damage
      is assumed.  If any other packet type is received, the
      decompressor should send a NACK.  Both of the above cases are
      subject to the feedback rate limitation as described in
      Section 5.3.2.

   Once a packet has been validated and decompressed correctly, the
   decompressor MUST transit to the FC state.

5.3.1.5.  Full Context (FC) State

   In the Full Context (FC) state, both the static and the dynamic parts
   of the decompressor context are valid.  From the FC state, the
   decompressor moves back to the SC state if context damage is
   detected.

   Allowing decompression:

      In the FC state, decompression can be attempted regardless of the
      type of packet received.

   Feedback logic:

      In the FC state, the decompressor should send a NACK if the
      decompression of any packet type fails and context damage is
      assumed, subject to the feedback rate limitation as described in
      Section 5.3.2.

5.3.2.  Feedback Logic

   The decompressor MAY send positive feedback (ACKs) to initially
   establish the feedback channel for a particular flow.  Either
   positive feedback (ACKs) or negative feedback (NACKs) establishes
   this channel.

   Once the feedback channel is established, the decompressor is
   REQUIRED to continue sending NACKs or STATIC-NACKs for as long as the
   context is associated with the same profile, in this case with
   profile 0x0006, as per the logic defined for each state in
   Section 5.3.1.

   The decompressor MAY send ACKs upon successful decompression of any
   packet type.  In particular, when a packet carrying a significant
   context update is correctly decompressed, the decompressor MAY send
   an ACK.

   The decompressor should limit the rate at which it sends feedback,
   for both ACKs and STATIC-NACK/NACKs, and should avoid sending
   unnecessary duplicates of the same type of feedback message that may
   be associated to the same event.

5.3.3.  Context Replication

   ROHC-TCP supports context replication; therefore, the decompressor
   MUST implement the additional decompressor and feedback logic defined
   in [RFC4164].

6.  Encodings in ROHC-TCP (Normative)

6.1.  Control Fields in ROHC-TCP

   In ROHC-TCP, a number of control fields are used by the decompressor
   in its interpretation of the format of the packets received from the
   compressor.

   A control field is a field that is transmitted from the compressor to
   the decompressor, but is not part of the uncompressed header.  Values
   for control fields can be set up in the context of both the
   compressor and the decompressor.  Once established at the
   decompressor, the values of these fields should be kept until updated
   by another packet.

6.1.1.  Master Sequence Number (MSN)

   There is no field in the TCP header that can act as the master
   sequence number for TCP compression, as explained in [RFC4413],
   Section 5.6.

   To overcome this problem, ROHC-TCP introduces a control field called
   the Master Sequence Number (MSN) field.  The MSN field is created at
   the compressor, rather than using one of the fields already present
   in the uncompressed header.  The compressor increments the value of
   the MSN by one for each packet that it sends.

   The MSN field has the following two functions:

   1.  Differentiating between packets when sending feedback data.

   2.  Inferring the value of incrementing fields such as the IP-ID.

   The MSN field is present in every packet sent by the compressor.  The
   MSN is LSB encoded within the CO packets, and the 16-bit MSN is sent
   in full in IR/IR-DYN packets.  The decompressor always sends the MSN
   as part of the feedback information.  The compressor can later use
   the MSN to infer which packet the decompressor is acknowledging.

   When the MSN is initialized, it SHOULD be initialized to a random
   value.  The compressor should only initialize a new MSN for the
   initial IR or IR-CR packet sent for a CID that corresponds to a
   context that is not already associated with this profile.  In other
   words, if the compressor reuses the same CID to compress many TCP
   flows one after the other, the MSN is not reinitialized but rather
   continues to increment monotonically.

   For context replication, the compressor does not use the MSN of the
   base context when sending the IR-CR packet, unless the replication
   process overwrites the base context (i.e., Base CID == CID).
   Instead, the compressor uses the value of the MSN if it already
   exists in the ROHC-TCP context being associated with the new flow
   (CID); otherwise, the MSN is initialized to a new value.

6.1.2.  IP-ID Behavior

   The IP-ID field of the IPv4 header can have different change
   patterns.  Conceptually, a compressor monitors changes in the value
   of the IP-ID field and selects encoding methods and packet formats
   that are the closest match to the observed change pattern.

   ROHC-TCP defines different types of compression techniques for the
   IP-ID, to provide the flexibility to compress any of the behaviors it
   may observe for this field: sequential in network byte order (NBO),
   sequential byte-swapped, random (RND), or constant to a value of
   zero.

   The compressor monitors changes in the value of the IP-ID field for a
   number of packets, to identify which one of the above listed
   compression alternatives is the closest match to the observed change
   pattern.  The compressor can then select packet formats and encoding
   methods based on the identified field behavior.

   If more than one level of IP headers is present, ROHC-TCP can assign
   a sequential behavior (NBO or byte-swapped) only to the IP-ID of the
   innermost IP header.  This is because only this IP-ID can possibly
   have a sufficiently close correlation with the MSN (see also
   Section 6.1.1) to compress it as a sequentially changing field.
   Therefore, a compressor MUST NOT assign either the sequential (NBO)
   or the sequential byte-swapped behavior to tunneling headers.

   The control field for the IP-ID behavior determines which set of
   packet formats will be used.  These control fields are also used to
   determine the contents of the irregular chain item (see Section 6.2)
   for each IP header.

6.1.3.  Explicit Congestion Notification (ECN)

   When ECN [RFC3168] is used once on a flow, the ECN bits could change
   quite often.  ROHC-TCP maintains a control field in the context to
   indicate whether or not ECN is used.  This control field is
   transmitted in the dynamic chain of the TCP header, and its value can
   be updated using specific compressed headers carrying a 7-bit CRC.

   When this control field indicates that ECN is being used, items of
   all IP and TCP headers in the irregular chain include bits used for
   ECN.  To preserve octet-alignment, all of the TCP reserved bits are
   transmitted and, for outer IP headers, the entire Type of Service/
   Traffic Class (TOS/TC) field is included in the irregular chain.
   When there is only one IP header present in the packet (i.e., no IP
   tunneling is used), this compression behavior allows the compressor
   to handle changes in the ECN bits by adding a single octet to the
   compressed header.

   The reason for including the ECN bits of all IP headers in the
   compressed packet when the control field is set is that the profile
   needs to efficiently compress flows containing IP tunnels using the
   "full-functionality option" of Section 9.1 of [RFC3168].  For these
   flows, a change in the ECN bits of an inner IP header is propagated
   to the outer IP headers.  When the "limited-functionality" option is
   used, the compressor will therefore sometimes send one octet more
   than necessary per tunnel header, but this has been considered a
   reasonable trade-off when designing this profile.

6.2.  Compressed Header Chains

   Some packet types use one or more chains containing sub-header
   information.  The function of a chain is to group fields based on
   similar characteristics, such as static, dynamic, or irregular
   fields.  Chaining is done by appending an item for each header to the
   chain in their order of appearance in the uncompressed packet,
   starting from the fields in the outermost header.

   Chains are defined for all headers compressed by ROHC-TCP, as listed
   below.  Also listed are the names of the encoding methods used to
   encode each of these protocol headers.

   o  TCP [RFC0793], encoding method: "tcp"

   o  IPv4 [RFC0791], encoding method: "ipv4"

   o  IPv6 [RFC2460], encoding method: "ipv6"

   o  AH [RFC4302], encoding method: "ah"

   o  GRE [RFC2784][RFC2890], encoding method: "gre"

   o  MINE [RFC2004], encoding method: "mine"

   o  IPv6 Destination Options header [RFC2460], encoding method:
      "ip_dest_opt"

   o  IPv6 Hop-by-Hop Options header [RFC2460], encoding method:
      "ip_hop_opt"

   o  IPv6 Routing header [RFC2460], encoding method: "ip_rout_opt"

   Static chain:

      The static chain consists of one item for each header of the chain
      of protocol headers to be compressed, starting from the outermost
      IP header and ending with a TCP header.  In the formal description
      of the packet formats, this static chain item for each header is a
      format whose name is suffixed by "_static".  The static chain is
      only used in IR packets.

   Dynamic chain:

      The dynamic chain consists of one item for each header of the
      chain of protocol headers to be compressed, starting from the
      outermost IP header and ending with a TCP header.  The dynamic
      chain item for the TCP header also contains a compressed list of
      TCP options (see Section 6.3).  In the formal description of the
      packet formats, the dynamic chain item for each header type is a
      format whose name is suffixed by "_dynamic".  The dynamic chain is
      used in both IR and IR-DYN packets.

   Replicate chain:

      The replicate chain consists of one item for each header in the
      chain of protocol headers to be compressed, starting from the
      outermost IP header and ending with a TCP header.  The replicate
      chain item for the TCP header also contains a compressed list of
      TCP options (see Section 6.3).  In the formal description of the
      packet formats, the replicate chain item for each header type is a

      format whose name is suffixed by "_replicate".  Header fields that
      are not present in the replicate chain are replicated from the
      base context.  The replicate chain is only used in the IR-CR
      packet.

   Irregular chain:

      The structure of the irregular chain is analogous to the structure
      of the static chain.  For each compressed packet, the irregular
      chain is appended at the specified location in the general format
      of the compressed packets as defined in Section 7.3.  This chain
      also includes the irregular chain items for TCP options as defined
      in Section 6.3.6, which are placed directly after the irregular
      chain item of the TCP header, and in the same order as the options
      appear in the uncompressed packet.  In the formal description of
      the packet formats, the irregular chain item for each header type
      is a format whose name is suffixed by "_irregular".  The irregular
      chain is used only in CO packets.

      The format of the irregular chain for the innermost IP header
      differs from the format of outer IP headers, since this header is
      part of the compressed base header.

6.3.  Compressing TCP Options with List Compression

   This section describes in detail how list compression is applied to
   the TCP options.  In the definition of the packet formats for ROHC-
   TCP, the most frequent TCP options have one encoding method each, as
   listed in the table below.

           +-----------------+------------------------+
           |   Option name   |  Encoding method name  |
           +-----------------+------------------------+
           |      NOP        | tcp_opt_nop            |
           |      EOL        | tcp_opt_eol            |
           |      MSS        | tcp_opt_mss            |
           |  WINDOW SCALE   | tcp_opt_wscale         |
           |   TIMESTAMP     | tcp_opt_ts             |
           | SACK-PERMITTED  | tcp_opt_sack_permitted |
           |      SACK       | tcp_opt_sack           |
           | Generic options | tcp_opt_generic        |
           +-----------------+------------------------+

   Each of these encoding methods has an uncompressed format, a format
   suffixed by "_list_item" and a format suffixed by "_irregular".  In
   some cases, a single encoding method may have multiple "_list_item"

   or "_irregular" formats, in which case bindings inside these formats
   determine what format is used.  This is further described in the
   following sections.

6.3.1.  List Compression

   The TCP options in the uncompressed packet can be represented as an
   ordered list, whose order and presence are usually constant between
   packets.  The generic structure of such a list is as follows:

            +--------+--------+--...--+--------+
      list: | item 1 | item 2 |       | item n |
            +--------+--------+--...--+--------+

   To compress this list, ROHC-TCP uses a list compression scheme, which
   compresses each of these items individually and combines them into a
   compressed list.

   The basic principles of list-based compression are the following:


      1) When a context is being initialized, a complete representation
      of the compressed list of options is transmitted.  All options
      that have any content are present in the compressed list of items
      sent by the compressor.

   Then, once the context has been initialized:

      2) When the structure AND the content of the list are unchanged,
      no information about the list is sent in compressed headers.

      3) When the structure of the list is constant, and when only the
      content defined within the irregular format for one or more
      options is changed, no information about the list needs to be sent
      in compressed base headers; the irregular content is sent as part
      of the irregular chain, as described in Section 6.3.6.

      4) When the structure of the list changes, a compressed list is
      sent in the compressed base header, including a representation of
      its structure and order.  Content defined within the irregular
      format of an option can still be sent as part of the irregular
      chain (as described in Section 6.3.6), provided that the item
      content is not part of the compressed list.

6.3.2.  Table-Based Item Compression

   The table-based item compression compresses individual items sent in
   compressed lists.  The compressor assigns a unique identifier,
   "Index", to each item, "Item", of a list.

   Compressor Logic

      The compressor conceptually maintains an item table containing all
      items, indexed using "Index".  The (Index, Item) pair is sent
      together in compressed lists until the compressor gains enough
      confidence that the decompressor has observed the mapping between
      items and their respective index.  Confidence is obtained from the
      reception of an acknowledgment from the decompressor, or by
      sending (Index, Item) pairs using the optimistic approach.  Once
      confidence is obtained, the index alone is sent in compressed
      lists to indicate the presence of the item corresponding to this
      index.

      The compressor may reassign an existing index to a new item, by
      re-establishing the mapping using the procedure described above.

   Decompressor Logic

      The decompressor conceptually maintains an item table that
      contains all (Index, Item) pairs received.  The item table is
      updated whenever an (Index, Item) pair is received and
      decompression is successfully verified using the CRC.  The
      decompressor retrieves the item from the table whenever an index
      without an accompanying item is received.

      If an index without an accompanying item is received and the
      decompressor does not have any context for this index, the header
      MUST be discarded and a NACK SHOULD be sent.

6.3.3.  Encoding of Compressed Lists

   Each item present in a compressed list is represented by:

   o  an index into the table of items

   o  a presence bit indicating if a compressed representation of the
      item is present in the list

   o  an item (if the presence bit is set)

   Decompression of an item will fail if the presence bit is not set and
   the decompressor has no entry in the context for that item.

   A compressed list of TCP options uses the following encoding:

        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      | Reserved  |PS |       m       |
      +---+---+---+---+---+---+---+---+
      |        XI_1, ..., XI_m        | m octets, or m * 4 bits
      /                --- --- --- ---/
      |               :    Padding    : if PS = 0 and m is odd
      +---+---+---+---+---+---+---+---+
      |                               |
      /      item_1, ..., item_n      / variable
      |                               |
      +---+---+---+---+---+---+---+---+

      Reserved: MUST be set to zero; otherwise, the decompressor MUST
      discard the packet.


      PS: Indicates size of XI fields:

         PS = 0 indicates 4-bit XI fields;

         PS = 1 indicates 8-bit XI fields.


      m: Number of XI item(s) in the compressed list.

      XI_1, ..., XI_m: m XI items.  Each XI represents one TCP option in
      the uncompressed packet, in the same order as they appear in the
      uncompressed packet.

         The format of an XI item is as follows:

                 +---+---+---+---+
         PS = 0: | X |   Index   |
                 +---+---+---+---+

                   0   1   2   3   4   5   6   7
                 +---+---+---+---+---+---+---+---+
         PS = 1: | X | Reserved  |     Index     |
                 +---+---+---+---+---+---+---+---+

         X: Indicates whether the item is present in the list:

            X = 1 indicates that the item corresponding to the Index is
            sent in the item_1, ..., item_n list;

            X = 0 indicates that the item corresponding to the Index is
            not sent and is instead included in the irregular chain.

         Reserved: MUST be set to zero; otherwise, the decompressor MUST
         discard the packet.

         Index: An index into the item table.  See Section 6.3.4.

         When 4-bit XI items are used, the XI items are placed in octets
         in the following manner:

           0   1   2   3   4   5   6   7
         +---+---+---+---+---+---+---+---+
         |     XI_k      |    XI_k + 1   |
         +---+---+---+---+---+---+---+---+

      Padding: A 4-bit padding field is present when PS = 0 and the
      number of XIs is odd.  The Padding field MUST be set to zero;
      otherwise, the decompressor MUST discard the packet.

      Item 1, ..., item n: Each item corresponds to an XI with X = 1 in
      XI 1, ..., XI m.  The format of the entries in the item list is
      described in the table in Section 6.3.  The compressed format(s)
      suffixed by "_list_item" in the encoding methods defines the item
      inside the compressed item list.

6.3.4.  Item Table Mappings

   The item table for TCP options list compression is limited to 16
   different items, since it is unlikely that any packet flow will
   contain a larger number of unique options.

   The mapping between the TCP option type and table indexes are listed
   in the table below:

         +-----------------+---------------+
         |   Option name   |  Table index  |
         +-----------------+---------------+
         |      NOP        |       0       |
         |      EOL        |       1       |
         |      MSS        |       2       |
         |  WINDOW SCALE   |       3       |
         |   TIMESTAMP     |       4       |
         | SACK-PERMITTED  |       5       |
         |      SACK       |       6       |
         | Generic options |      7-15     |
         +-----------------+---------------+

   Some TCP options are used more frequently than others.  To simplify
   their compression, a part of the item table is reserved for these
   option types, as shown on the table above.  Both the compressor and
   the decompressor MUST use these mappings between item and indexes to
   (de)compress TCP options when using list compression.

   It is expected that the option types for which an index is reserved
   in the item table will only appear once in a list.  However, if an
   option type is detected twice in the same options list and if both
   options have a different content, the compressor should compress the
   second occurrence of the option type by mapping it to a generic
   compressed option.  Otherwise, if the options have the exact same
   content, the compressor can still use the same table index for both.

   The NOP option

      The NOP option can appear more than once in the list.  However,
      since its value is always the same, no context information needs
      to be transmitted.  Multiple NOP options can thus be mapped to the
      same index.  Since the NOP option does not have any content when
      compressed as a "_list_item", it will never be present in the item
      list.  For consistency, the compressor should still establish an
      entry in the list by setting the presence bit, as done for the
      other type of options.

      List compression always preserves the original order of each item
      in the decompressed list, whether or not the item is present in
      the compressed "_list_item" or if multiple items of the same type
      can be mapped to the same index, as for the NOP option.

   The EOL option

      The size of the compressed format for the EOL option can be larger
      than one octet, and it is defined so that it includes the option
      padding.  This is because the EOL should terminate the parsing of
      the options, but it can also be followed by padding octets that
      all have the value zero.

   The Generic option

      The Generic option can be used to compress any type of TCP option
      that does not have a reserved index in the item table.

6.3.5.  Compressed Lists in Dynamic Chain

   A compressed list for TCP options that is part of the dynamic chain
   (e.g., in IR or IR-DYN packets) must have all its list items present,
   i.e., all X-bits in the XI list MUST be set.

6.3.6.  Irregular Chain Items for TCP Options

   The "_list_item" represents the option inside the compressed item
   list, and the "_irregular" format is used for the option fields that
   are expected to change with each packet.  When an item of the
   specified type is present in the current context, these irregular
   fields are present in each compressed packet, as part of the
   irregular chain.  Since many of the TCP option types are not expected
   to change for the duration of a flow, many of the "_irregular"
   formats are empty.

   The irregular chain for TCP options is structured analogously to the
   structure of the TCP options in the uncompressed packet.  If a
   compressed list is present in the compressed packet, then the
   irregular chain for TCP options must not contain irregular items for
   the list items that are transmitted inside the compressed list (i.e.,
   items in the list that have the X-bit set in its XI).  The items that
   are not present in the compressed list, but are present in the
   uncompressed list, must have their respective irregular items present
   in the irregular chain.

6.3.7.  Replication of TCP Options

   The entire table of TCP options items is always replicated when using
   the IR-CR packet.  In the IR-CR packet, the list of options for the
   new flow is also transmitted as a compressed list in the IR-CR
   packet.

6.4.  Profile-Specific Encoding Methods

   This section defines encoding methods that are specific to this
   profile.  These methods are used in the formal definition of the
   packet formats in Section 8.

6.4.1.  inferred_ip_v4_header_checksum

   This encoding method compresses the Header Checksum field of the IPv4
   header.  This checksum is defined in [RFC0791] as follows:

      Header Checksum: 16 bits

         A checksum on the header only.  Since some header fields change
         (e.g., time to live), this is recomputed and verified at each
         point that the internet header is processed.

      The checksum algorithm is:

         The checksum field is the 16-bit one's complement of the one's
         complement sum of all 16-bit words in the header.  For purposes
         of computing the checksum, the value of the checksum field is
         zero.

   As described above, the header checksum protects individual hops from
   processing a corrupted header.  When almost all IP header information
   is compressed away, and when decompression is verified by a CRC
   computed over the original header for every compressed packet, there
   is no point in having this additional checksum; instead, it can be
   recomputed at the decompressor side.

   The "inferred_ip_v4_header_checksum" encoding method thus compresses
   the IPv4 header checksum down to a size of zero bits.  Using this
   encoding method, the decompressor infers the value of this field
   using the computation above.

   This encoding method implicitly assumes that the compressor will not
   process a corrupted header; otherwise, it cannot guarantee that the
   checksum as recomputed by the decompressor will be bitwise identical
   to its original value before compression.

6.4.2.  inferred_mine_header_checksum

   This encoding method compresses the minimal encapsulation header
   checksum.  This checksum is defined in [RFC2004] as follows:

      Header Checksum

         The 16-bit one's complement of the one's complement sum of all
         16-bit words in the minimal forwarding header.  For purposes of
         computing the checksum, the value of the checksum field is
         zero.  The IP header and IP payload (after the minimal
         forwarding header) are not included in this checksum
         computation.

   The "inferred_mine_header_checksum" encoding method compresses the
   minimal encapsulation header checksum down to a size of zero bits,
   i.e., no bits are transmitted in compressed headers for this field.
   Using this encoding method, the decompressor infers the value of this
   field using the above computation.

   The motivations and the assumptions for inferring this checksum are
   similar to the ones explained above in Section 6.4.1.

6.4.3.  inferred_ip_v4_length

   This encoding method compresses the Total Length field of the IPv4
   header.  The Total Length field of the IPv4 header is defined in
   [RFC0791] as follows:

      Total Length: 16 bits

         Total Length is the length of the datagram, measured in octets,
         including internet header and data.  This field allows the
         length of a datagram to be up to 65,535 octets.

   The "inferred_ip_v4_length" encoding method compresses the IPv4 Total
   Length field down to a size of zero bits.  Using this encoding
   method, the decompressor infers the value of this field by counting
   in octets the length of the entire packet after decompression.

6.4.4.  inferred_ip_v6_length

   This encoding method compresses the Payload Length field of the IPv6
   header.  This length field is defined in [RFC2460] as follows:

      Payload Length: 16-bit unsigned integer

         Length of the IPv6 payload, i.e., the rest of the packet
         following this IPv6 header, in octets.  (Note that any
         extension headers present are considered part of the payload,
         i.e., included in the length count.)

   The "inferred_ip_v6_length" encoding method compresses the Payload
   Length field of the IPv6 header down to a size of zero bits.  Using
   this encoding method, the decompressor infers the value of this field
   by counting in octets the length of the entire packet after
   decompression.

6.4.5.  inferred_offset

   This encoding method compresses the data offset field of the TCP
   header.

   The "inferred_offset" encoding method is used on the Data Offset
   field of the TCP header.  This field is defined in [RFC0793] as:

      Data Offset: 4 bits

         The number of 32-bit words in the TCP header.  This indicates
         where the data begins.  The TCP header (even one including
         options) is an integral number of 32 bits long.

   The "inferred_offset" encoding method compresses the Data Offset
   field of the TCP header down to a size of zero bits.  Using this
   encoding method, the decompressor infers the value of this field by
   first decompressing the TCP options list, and by then setting:

              data offset = (options length / 4) + 5

   The equation above uses integer arithmetic.

6.4.6.  baseheader_extension_headers

   In CO packets (see Section 7.3), the innermost IP header and the TCP
   header are combined to create a compressed base header.  In some
   cases, the IP header will have a number of extension headers between
   itself and the TCP header.

   To remain formally correct, the base header must define some
   representation of these extension headers, which is what this
   encoding method is used for.  This encoding method skips over all the
   extension headers and does not encode any of the fields.  Changed
   fields in these headers are encoded in the irregular chain.

6.4.7.  baseheader_outer_headers

   This encoding method, as well as the baseheader_extension_headers
   encoding method described above, is needed for the specification to
   remain formally correct.  It is used in CO packets (see Section 7.3)
   to describe tunneling IP headers and their respective extension
   headers (i.e., all headers located before the innermost IP header).

   This encoding method skips over all the fields in these headers and
   does not perform any encoding.  Changed fields in outer headers are
   instead handled by the irregular chain.

6.4.8.  Scaled Encoding of Fields

   Some header fields will exhibit a change pattern where the field
   increases by a constant value or by multiples of the same value.

   Examples of fields that may have this behavior are the TCP Sequence
   Number and the TCP Acknowledgment Number.  For such fields, ROHC-TCP
   provides the means to downscale the field value before applying LSB
   encoding, which allows the compressor to transmit fewer bits.

   To be able to use scaled encoding, the field is required to fulfill
   the following equation:

        unscaled_value = scaling_factor * scaled_value + residue

   To use the scaled encoding, the compressor must be confident that the
   decompressor has established values for the "residue" and the
   "scaling_factor", so that it can correctly decompress the field when
   only an LSB-encoded "scaled_value" is present in the compressed
   packet.

   Once the compressor is confident that the value of the scaling_factor
   and the value of the residue have been established in the
   decompressor, the compressor may send compressed packets using the
   scaled representation of the field.  The compressor MUST NOT use
   scaled encoding with the value of the scaling_factor set to zero.

   If the compressor detects that the value of the residue has changed,
   or if the compressor uses a different value for the scaling factor,
   it MUST NOT use scaled encoding until it is confident that the
   decompressor has received the new value(s) of these fields.

   When the unscaled value of the field wraps around, the value of the
   residue is likely to change, even if the scaling_factor remains
   constant.  In such a case, the compressor must act in the same way as
   for any other change in the residue.

   The following subsections describe how the scaled encoding is applied
   to specific fields in ROHC-TCP, in particular, how the scaling_factor
   and residue values are established for the different fields.

6.4.8.1.  Scaled TCP Sequence Number Encoding

   For some TCP flows, such as data transfers, the payload size will be
   constant over periods of time.  For such flows, the TCP Sequence
   Number is bound to increase by multiples of the payload size between
   packets, which means that this field can be a suitable target for
   scaled encoding.  When using this encoding, the payload size will be
   used as the scaling factor (i.e., as the value for scaling_factor) of
   this encoding.  This means that the scaling factor does not need to
   be explicitly transmitted, but is instead inferred from the length of
   the payload in the compressed packet.

   Establishing scaling_factor:

      The scaling factor is established by sending unscaled TCP Sequence
      Number bits, so that the decompressor can infer the scaling_factor
      from the payload size.

   Establishing residue:

      The residue is established identically as the scaling_factor,
      i.e., by sending unscaled TCP Sequence Number bits.

   A detailed specification of how the TCP Sequence Number uses the
   scaled encoding can be found in the definitions of the packet
   formats, in Section 8.2.

6.4.8.2.  Scaled Acknowledgment Number Encoding

   Similar to the pattern exhibited by the TCP Sequence Number, the
   expected increase in the TCP Acknowledgment Number is often constant
   and is therefore suitable for scaled encoding.

   For the TCP Acknowledgment Number, the scaling factor depends on the
   size of packets flowing in the opposite direction; this information
   might not be available to the compressor/decompressor pair.  For this
   reason, ROHC-TCP uses an explicitly transmitted scaling factor to
   compress the TCP Acknowledgment Number.

   Establishing scaling_factor:

      The scaling factor is established by explicitly transmitting the
      value of the scaling factor (called ack_stride in the formal
      notation in Section 8.2) to the decompressor, using one of the
      packet types that can carry this information.

   Establishing residue:

      The scaling residue is established by sending unscaled TCP
      Acknowledgment Number bits, so that the decompressor can infer its
      value from the unscaled value and the scaling factor (ack_stride).

   A detailed specification of how the TCP Acknowledgment Number uses
   the scaled encoding can be found in the definitions of the packet
   formats, in Section 8.2.

   The compressor MAY use the scaled acknowledgment number encoding;
   what value it will use as the scaling factor is up to the compressor
   implementation.  In the case where there is a co-located decompressor
   processing packets of the same TCP flow in the opposite direction,
   the scaling factor for the sequence number used for that flow can be
   used by the compressor to determine a suitable scaling factor for the
   TCP Acknowledgment number for this flow.

6.5.  Encoding Methods with External Parameters

   A number of encoding methods in Section 8.2 have one or more
   arguments for which the derivation of the parameter's value is
   outside the scope of the ROHC-FN specification of the header formats.
   This section lists the encoding methods together with a definition of
   each of their parameters.

   o  ipv6(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn):

         is_innermost: This Boolean flag is set to true when processing
         the innermost IP header; otherwise, it is set to false.

         ttl_irregular_chain_flag: This parameter must be set to the
         value that was used for the corresponding
         "ttl_irregular_chain_flag" parameter of the "co_baseheader"
         encoding method (as defined below) when extracting the
         irregular chain for a compressed header; otherwise, it is set
         to zero and ignored for other types of chains.

         ip_inner_ecn: This parameter is bound by the encoding method;
         therefore, it should be undefined when calling this encoding
         method.  This value is then used to bind the corresponding

         parameter in the "tcp" encoding method, as its value is needed
         when processing the irregular chain for TCP.  See the
         definition of the "ip_inner_ecn" parameter for the "tcp"
         encoding method below.

   o  ipv4(is_innermost, ttl_irregular_chain_flag, ip_inner_ecn,
      ip_id_behavior_value):

         See definition of arguments for "ipv6" above.

         ip_id_behavior_value: Set to a 2-bit integer value, using one
         of the constants whose name begins with the prefix
         IP_ID_BEHAVIOR_ and as defined in Section 8.2.

   o  tcp_opt_eol(nbits):

         nbits: This parameter is set to the length of the padding data
         located after the EOL option type octet to the end of the TCP
         options in the uncompressed header.

   o  tcp_opt_sack(ack_value):

         ack_value: Set to the value of the Acknowledgment Number field
         of the TCP header.

   o  tcp(payload_size, ack_stride_value, ip_inner_ecn):

         payload_size: Set to the length (in octets) of the payload
         following the TCP header.

         ack_stride_value: This parameter is the scaling factor used
         when scaling the TCP Acknowledgment Number.  Its value is set
         by the compressor implementation.  See Section 6.4.8.2 for
         recommendations on how to set this value.

         ip_inner_ecn: This parameter binds with the value given to the
         corresponding "ip_inner_ecn" parameter by the "ipv4" or the
         "ipv6" encoding method when processing the innermost IP header
         of this packet.  See also the definition of the "ip_inner_ecn"
         parameter to the "ipv6" and "ipv4" encoding method above.

   o  co_baseheader(payload_size, ack_stride_value,
      ttl_irregular_chain_flag, ip_id_behavior_value):

         payload_size: Set to the length (in octets) of the payload
         following the TCP header.

         ack_stride_value: This parameter is the scaling factor used
         when scaling the TCP Acknowledgment Number.  Its value is set
         by the compressor implementation.  See Section 6.4.8.2 for
         recommendations on how to set this value.

         ttl_irregular_chain_flag: This parameter is set to one if the
         TTL/Hop Limit of an outer header has changed compared to its
         reference in the context; otherwise, it is set to zero.  The
         value used for this parameter is also used for the
         "ttl_irregular_chain_flag" argument for the "ipv4" and "ipv6"
         encoding methods when processing the irregular chain, as
         defined above for the "ipv6" and "ipv4" encoding methods.

         ip_id_behavior_value: Set to a 2-bit integer value, using one
         of the constants whose name begins with the prefix
         IP_ID_BEHAVIOR_ and as defined in Section 8.2.