Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 6846


RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)

Part 5 of 5, p. 88 to 96
Prev RFC Part


prevText      Top      Up      ToC       Page 88 
8.3.  Feedback Formats and Options

8.3.1.  Feedback Formats

   This section describes the feedback formats for the ROHC-TCP profile,
   following the general ROHC feedback format described in Section 5.2.4
   of [RFC5795].

   All feedback formats carry a field labeled MSN.  The MSN field
   contains LSBs of the MSN control field described in Section 6.1.1.
   The sequence number to use is the MSN corresponding to the last
   header that was successfully CRC-8 validated or CRC verified.


        0   1   2   3   4   5   6   7
      |              MSN              |

      MSN: The LSB-encoded master sequence number.

   A FEEDBACK-1 is an ACK.  In order to send a NACK or a STATIC-NACK,
   FEEDBACK-2 must be used.


        0   1   2   3   4   5   6   7
      |Acktype|          MSN          |
      |              MSN              |
      |              CRC              |
      /       Feedback options        /


         0 = ACK

         1 = NACK

         2 = STATIC-NACK

         3 is reserved (MUST NOT be used for parsability)

Top      Up      ToC       Page 89 
      MSN: The LSB-encoded master sequence number.

      CRC: 8-bit CRC computed over the entire feedback element (as
      defined in Section of [RFC5795]).  For the purpose of
      computing the CRC, the CRC field is zero.  The CRC is calculated
      using the polynomial defined in [RFC5795].

      Feedback options: A variable number of feedback options, see
      Section 8.3.2.  Options may appear in any order.

   A FEEDBACK-2 of type NACK or STATIC-NACK is always implicitly an
   acknowledgment for a successfully decompressed packet, which packet
   corresponds to the MSN of the feedback element, unless the MSN-NOT-
   VALID option (Section appears in the feedback element.

   The FEEDBACK-2 format always carries a CRC and is thus more robust
   than the FEEDBACK-1 format.  When receiving FEEDBACK-2, the
   compressor MUST verify the information by computing the CRC and by
   comparing the result with the CRC carried in the feedback format.  If
   the two are not identical, the feedback element MUST be discarded.

8.3.2.  Feedback Options

   A ROHC-TCP feedback option has variable length and the following
   general format:

        0   1   2   3   4   5   6   7
      |   Opt Type    |    Opt Len    |
      /          option data          /  Opt Length (octets)

   Each ROHC-TCP feedback option can appear at most once within a
   FEEDBACK-2.  The REJECT Option

   The REJECT option informs the compressor that the decompressor does
   not have sufficient resources to handle the flow.

      |  Opt Type = 2 |  Opt Len = 0  |

Top      Up      ToC       Page 90 
   When receiving a REJECT option, the compressor MUST stop compressing
   the packet flow, and SHOULD refrain from attempting to increase the
   number of compressed packet flows for some time.  The REJECT option
   MUST NOT appear more than once in the FEEDBACK-2 format; otherwise,
   the compressor MUST discard the entire feedback element.  The MSN-NOT-VALID Option

   The MSN-NOT-VALID option indicates that the MSN of the feedback is
   not valid.

      |  Opt Type = 3 |  Opt Len = 0  |

   A compressor MUST ignore the MSN of the feedback element when this
   option is present.  Consequently, a NACK or a STATIC-NACK feedback
   type sent with the MSN-NOT-VALID option is equivalent to a STATIC-
   NACK with respect to the semantics of the feedback message.

   The MSN-NOT-VALID option MUST NOT appear more than once in the
   FEEDBACK-2 format and MUST NOT appear in the same feedback element as
   the MSN option; otherwise, the compressor MUST discard the entire
   feedback element.  The MSN Option

   The MSN option provides 2 additional bits of MSN.

      |  Opt Type = 4 |  Opt Len = 1  |
      |  MSN  |        Reserved       |

   These 2 bits are the least significant bits of the MSN and are thus
   concatenated with the 14 bits already present in the FEEDBACK-2

   The MSN option MUST NOT appear more than once in the FEEDBACK-2
   format and MUST NOT appear in the same feedback element as the MSN-
   NOT-VALID option; otherwise, the compressor MUST discard the entire
   feedback element.

Top      Up      ToC       Page 91  The CONTEXT_MEMORY Feedback Option

   The CONTEXT_MEMORY option means that the decompressor does not have
   sufficient memory resources to handle the context of the packet flow,
   as the flow is currently compressed.

        0   1   2   3   4   5   6   7
      |  Opt Type = 9 |  Opt Len = 0  |

   When receiving a CONTEXT_MEMORY option, the compressor SHOULD take
   actions to compress the packet flow in a way that requires less
   decompressor memory resources, or stop compressing the packet flow.

   The CONTEXT_MEMORY option MUST NOT appear more than once in the
   FEEDBACK-2 format; otherwise, the compressor MUST discard the entire
   feedback element.  Unknown Option Types

   If an option type unknown to the compressor is encountered, the
   compressor MUST continue parsing the rest of the FEEDBACK element,
   which is possible since the length of the option is explicit, but
   MUST otherwise ignore the unknown option.

9.  Changes from RFC 4996

   This RFC revises RFC 4996.  It is mostly backwards-compatible with
   RFC 4996, except for two cases that did not interoperate as described

9.1.  Functional Changes

   o  The SACK option compression in [RFC4996] assumed that multiple
      SACK blocks within the same option would be in sorted order so
      that the block starts were LSB-encoded from the end of the
      previous block.  This meant that SACK blocks that are not in
      sorted order could be impossible to compress in some cases.
      Therefore, the SACK compression in the formal notation has changed
      and therefore also the bits-on-the-wire.

   o  The ESP NULL header compression has been deprecated due to
      interoperability problems with needing to know information from
      the trailer.  The ESP NULL compression was already removed from
      ROHCv2 [RFC5225] for the same reason and it was considered better
      to remove it from this profile rather than try to fix the
      interoperability issue.

Top      Up      ToC       Page 92 
9.2.  Non-functional Changes

   o  The way sequential IP-ID compression was described in the FN code
      was incorrect and the code used for ROHCv2 [RFC5225] has been
      imported into this specification (e.g., offset is made into a
      global control field).  This does not change the bits-on-the-wire.
      The only change is how this encoding is described in the formal
      notation, not how the compression occurs.

   o  Default encoding for the 'df' and 'ip_id' fields have been added
      for IPv6 with 0-bit uncompressed format to clarify that these
      never appear in IPv6.

   o  The scaled encoding of the Acknowledgment Number and Sequence
      Number were incorrectly described in the FN code in [RFC4996] and
      have been updated in the same style as in ROHCv2 [RFC5225].  This
      does not change the bits-on-the-wire, only the way the compression
      is described in the FN code.

   o  The external arguments to ipv4 and co_baseheader have been
      updated.  This is again only a change for FN correctness and does
      not affect interoperability.

   o  Errata for [RFC4996] related to minor errors in the FN and textual
      errors have also been corrected.

10.  Security Considerations

   A malfunctioning or malicious header compressor could cause the
   header decompressor to reconstitute packets that do not match the
   original packets but still have valid IP and TCP headers, and
   possibly also valid TCP checksums.  Such corruption may be detected
   with end-to-end authentication and integrity mechanisms that will not
   be affected by the compression.  Moreover, this header compression
   scheme uses an internal checksum for verification of reconstructed
   headers.  This reduces the probability of producing decompressed
   headers not matching the original ones without this being noticed.

   Denial-of-service attacks are possible if an intruder can introduce
   (for example) bogus IR, CO, or FEEDBACK packets onto the link and
   thereby cause compression efficiency to be reduced.  However, an
   intruder having the ability to inject arbitrary packets at the link
   layer in this manner raises additional security issues that dwarf
   those related to the use of header compression.

Top      Up      ToC       Page 93 
11.  IANA Considerations

   The reference for the ROHC profile identifier 0x0006 has been updated
   to reference this document instead of RFC 4996.

   A ROHC profile identifier has been reserved by IANA for the profile
   defined in this document.  Profiles 0x0000-0x0005 have previously
   been reserved; this profile is 0x0006.  As for previous ROHC
   profiles, profile numbers 0xnn06 have been reserved for future
   updates of this profile.

        Profile             Usage            Document

        0x0006              ROHC TCP         [RFC6846]
        0xnn06              Reserved

12.  Acknowledgments

   The authors would like to thank Qian Zhang, Hong Bin Liao, Richard
   Price, and Fredrik Lindstroem for their work with early versions of
   this specification.  Thanks also to Robert Finking and Carsten
   Bormann for valuable input and to Carl Knutsson and Gilbert Strom for
   suggestions and review of the updates made in this document.

   Additional thanks: this document was reviewed during working group
   last-call by committed reviewers Joe Touch and Ted Faber, as well as
   by Sally Floyd, who provided a review at the request of the Transport
   Area Directors.

13.  References

13.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC2004]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
              October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

Top      Up      ToC       Page 94 
   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC 2890, September 2000.

   [RFC4164]  Pelletier, G., "RObust Header Compression (ROHC): Context
              Replication for ROHC Profiles", RFC 4164, August 2005.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [RFC4997]  Finking, R. and G. Pelletier, "Formal Notation for RObust
              Header Compression (ROHC-FN)", RFC 4997, July 2007.

   [RFC5795]  Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
              Header Compression (ROHC) Framework", RFC 5795,
              March 2010.

13.2.  Informative References

   [RFC1144]  Jacobson, V., "Compressing TCP/IP headers for low-speed
              serial links", RFC 1144, February 1990.

   [RFC1323]  Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
              for High Performance", RFC 1323, May 1992.

   [RFC2018]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
              Selective Acknowledgment Options", RFC 2018, October 1996.

   [RFC2507]  Degermark, M., Nordgren, B., and S. Pink, "IP Header
              Compression", RFC 2507, February 1999.

   [RFC2883]  Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
              Extension to the Selective Acknowledgement (SACK) Option
              for TCP", RFC 2883, July 2000.

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

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

Top      Up      ToC       Page 95 
   [RFC3759]  Jonsson, L-E., "RObust Header Compression (ROHC):
              Terminology and Channel Mapping Examples", RFC 3759,
              April 2004.

   [RFC4163]  Jonsson, L-E., "RObust Header Compression (ROHC):
              Requirements on TCP/IP Header Compression", RFC 4163,
              August 2005.

   [RFC4224]  Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust
              Header Compression (ROHC): ROHC over Channels That Can
              Reorder Packets", RFC 4224, January 2006.

   [RFC4413]  West, M. and S. McCann, "TCP/IP Field Behavior", RFC 4413,
              March 2006.

   [RFC4996]  Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West,
              "RObust Header Compression (ROHC): A Profile for TCP/IP
              (ROHC-TCP)", RFC 4996, July 2007.

   [RFC5225]  Pelletier, G. and K. Sandlund, "RObust Header Compression
              Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and
              UDP-Lite", RFC 5225, April 2008.

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, September 2009.

Top      Up      ToC       Page 96 
Authors' Addresses

   Ghyslain Pelletier
   InterDigital Communications
   1000, Sherbrooke Street West, 10th floor
   Montreal, Quebec  H3A 3G4

   Phone: +46 (0) 70 609 27 73

   Kristofer Sandlund
   Box 920
   Lulea  SE-971 28

   Phone: +46 (0) 8 404 41 58

   Lars-Erik Jonsson
   Optand 737
   Ostersund  SE-831 92

   Phone: +46 70 365 20 58

   Mark A West
   Siemens/Roke Manor
   Roke Manor Research Ltd.
   Romsey, Hampshire  SO51 0ZN

   Phone: +44 1794 833311