[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 RFC 4815

Network Working Group                             Peter Kremer, Ericsson
INTERNET-DRAFT                               Lars-Erik Jonsson, Ericsson
Expires: August 2003                                   February 28, 2003

                         ROHC Implementer's Guide

Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This document is a submission of the IETF ROHC WG. Comments should be
   directed to the ROHC WG mailing list, rohc@ietf.org.


   This document describes common misinterpretations and some ambiguous
   points of ROHC [RFC 3095], which defines the framework and four
   profiles of a robust and efficient header compression scheme.  These
   points have been identified by the members of the ROHC working group
   during different interoperability test events.

Kremer, Jonsson                                                 [Page 1]

INTERNET-DRAFT          ROHC Implementer's Guide       February 28, 2003

Table of Contents

   1.  Introduction....................................................2
   2.  CRC Calculation.................................................3
   3.  Enhanced mode transition procedures.............................3
   3.1.  Modified transition logic for enhanced transitions............3
   3.2.  Transition from Reliable to Optimistic mode...................4
   3.3.  Transition to Unidirectional mode.............................5
   4.  Other protocol clarifications...................................5
   4.1.  Padding octet in CRC..........................................5
   4.2.  Timestamp encoding considerations.............................5
   4.2.1.  Encoding of TS values.......................................5
   4.2.2.  Interpretation intervals for TS encoding....................5
   4.2.3.  Recalculating TS_OFFSET.....................................6
   4.3.  List compression issues.......................................6
   4.3.1.  Generic extension header list...............................6
   4.3.2.  CSRC list items in RTP dynamic chain........................6
   4.3.3.  RTP dynamic chain...........................................7
   4.3.4.  CSRC list in UO-1-ID packets................................7
   4.3.5.  Bit masks in list compression...............................7
   4.4.  Meaning of NBO................................................8
   4.5.  Implicit updates..............................................8
   4.6.  IP-ID.........................................................8
   4.7.  Extension-3 in UO-1-ID packets................................8
   4.8.  Extension-3 in UOR-2* packets.................................9
   4.9.  Multiple SN options in one feedback packet....................9
   4.10.  Packet decoding during mode transition.......................9
   4.11.  How to respond to lost feedback links?.......................9
   4.12.  What does "presumed zero if absent" mean on page 88?........10
   4.13.  UOR-2 in profile 2 (UDP)....................................10
   5.  ROHC negotiation clarifications................................10
   6.  PROFILES suboption in ROHC-over-PPP............................11
   7.  Test Configuration.............................................11
   8.  Security considerations........................................12
   9.  Acknowledgment.................................................12
   10.  References....................................................12
   11.  Authors' Addresses............................................12
   Appendix A.  Sample CRC algorithm..................................13

1.  Introduction

   ROHC [RFC 3095] addresses a robust and efficient header compression
   algorithm and as a such its description is long and complex.  During
   the implementation and the interoperability tests of the algorithm
   some unclear areas have been identified.  This document tries to
   collect and clarify these points.  Note that all section and chapter

Kremer, Jonsson                                                 [Page 2]

INTERNET-DRAFT          ROHC Implementer's Guide       February 28, 2003

   references in this document refer to [RFC-3095], if not stated

2.  CRC Calculation

   ROHC uses CRC checksum in order to provide some protection against
   bit errors. CRC is used in the segmentation protocol and in the
   compressed packets, as well.

   Section describes the segmentation protocol and refers to
   [RFC 1662], which describes a well-defined CRC algorithm for 32 bit
   checksums.  Although, Section 5.9 only defines the polynomials for 3,
   7 and 8-bit long checksum, the same algorithm can be used in these
   cases as well.

   A PERL implementation of the algorithm (written by Carsten Bormann)
   can be found in Appendix A.

3.  Enhanced mode transition procedures

   To reduce transmission overhead and computational complexity
   (including CRC calculation) associated with feedback packets sent for
   each decompressed packet during mode transition, a decompressor can
   be implemented with slightly modified mode transition procedures,
   compared to those defined in [RFC3095].

   These modifications affect transitions to Optimistic and
   Unidirectional modes of operation, i.e. the transitions described in
   sections 5.6.5 and 5.6.6 of [RFC3095], and make those transition
   diagrams more consistent with the diagram describing the transition
   to R-mode. However, the differences between the original diagrams of
   [RFC3095] were motivated by robustness concerns for mode transitions
   to Optimistic and Unidirectional modes. To avoid deadlock situations
   in mode transitions, these aspects must be addressed also when a
   decompressor implements the enhanced transition procedures, and that
   is done by following a slightly modified definition of the
   decompressor transition states. All aspects related to implementation
   of the enhanced transition procedures are described in subsequent

   Note that these modified operations should be seen only as an
   improved decompressor implementation, since interoperability is not
   at all affected. A decompressor implemented according to the
   optimized procedures would be able to interoperate with an RFC3095
   compressor, as well as a decompressor implemented according to the
   procedures described in RFC3095 would do.

3.1.  Modified transition logic for enhanced transitions

   The intent with these enhanced transition procedures is to allow the
   decompressor to stop sending feedback packets for all packets

Kremer, Jonsson                                                 [Page 3]

INTERNET-DRAFT          ROHC Implementer's Guide       February 28, 2003

   decompressed during the second half of the transition procedure, i.e.
   after an appropriate IR/IR-DYN/UOR-2 packet has been received from
   the compressor. In the transition diagrams, sections 3.2 and 3.3
   below, this is realized by allowing the decompressor transition
   parameter (D_TRANS) to be set to P (Pending) at that stage. However,
   as mentioned above, there are robustness concerns related to this
   optimization, and to avoid deadlock situations with never completed
   transitions as a result of feedback losses, the decompressor must
   continue to send feedback at least periodically, also when in Pending
   transition state. That would be the equivalence of enhancing the
   D_TRANS parameter definition in section 5.6.1 of [RFC3095], to
   include a definition of Pending state operation.

   - D_TRANS:
      Possible values for the D_TRANS parameter are (I)NITIATED,
      (P)ENDING and (D)ONE. D_TRANS MUST be initialized to D, and a mode
      transition can be initiated only when D_TRANS is D. While D_TRANS
      is I, the decompressor sends a NACK or ACK carrying a CRC option
      for each packet received. When D_TRANS is set to P, the
      decompressor do not have to send a NACK or ACK for each packet
      received, but it MUST continue to send feedback on a regular
      basis, and all feedback packets sent MUST include the CRC option.
      This ensures that all mode transitions will be completed also in
      case of feedback losses.

3.2.  Transition from Reliable to Optimistic mode

   The enhanced procedure for transition from Reliable to Optimistic
   mode is shown below:

            Compressor                     Decompressor
                 |                               |
                 |        ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
                 |       +-<-<-<-<-<-<-<-+       |
     C_TRANS = P |-<-<-<-+                       |
     C_MODE = O  |                               |
                 |->->->-+ IR/IR-DYN/UOR-2(SN,O) |
                 |       +->->->->->->->-+       |
                 |->-..                  +->->->-| D_TRANS = P
                 |->-..                          | D_MODE = O
                 |           ACK(SN,O)   +-<-<-<-|
                 |       +-<-<-<-<-<-<-<-+       |
     C_TRANS = D |-<-<-<-+                       |
                 |                               |
                 |->->->-+  UO-0, UO-1*          |
                 |       +->->->->->->->-+       |
                 |                       +->->->-| D_TRANS = D
                 |                               |

Kremer, Jonsson                                                 [Page 4]

INTERNET-DRAFT          ROHC Implementer's Guide       February 28, 2003

3.3.  Transition to Unidirectional mode

   The enhanced procedure for transition to Unidirectional mode is shown
   on the following figure:

                Compressor                     Decompressor
                 |                               |
                 |        ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
                 |       +-<-<-<-<-<-<-<-+       |
     C_TRANS = P |-<-<-<-+                       |
     C_MODE = U  |                               |
                 |->->->-+ IR/IR-DYN/UOR-2(SN,U) |
                 |       +->->->->->->->-+       |
                 |->-..                  +->->->-| D_TRANS = P
                 |->-..                          |
                 |           ACK(SN,U)   +-<-<-<-|
                 |       +-<-<-<-<-<-<-<-+       |
     C_TRANS = D |-<-<-<-+                       |
                 |                               |
                 |->->->-+  UO-0, UO-1*          |
                 |       +->->->->->->->-+       |
                 |                       +->->->-| D_TRANS = D
                 |                               | D_MODE= U

4.  Other protocol clarifications

4.1.  Padding octet in CRC

   According to Section 5.9.1, in case of IR and IR-DYN packets the CRC
   "is calculated over the entire IR or IR-DYN packet, excluding Payload
   and including CID or Add-CID octet".  Padding isn't meant to be
   meaningful part of a packet and not included in CRC calculation.  As
   a result, CRC doesn't cover the Add-CID octet for CID 0, either.

4.2.  Timestamp encoding considerations

4.2.1.  Encoding of TS values

   RTP Timestamp values (TS) are always encoded using W-LSB encoding,
   both when sent scaled and when sent unscaled. For TS values sent in
   Extension 3, W-LSB encoded values are sent using the self-describing
   variable-length format (section 4.5.6), and this applies to both
   scaled and unscaled values.

4.2.2.  Interpretation intervals for TS encoding

   Section 4.5.4 defines the interpretation interval, p, for timer-based
   compression of the RTP timestamp.  However, Section 5.7 defines a
   different interpretation interval, which is defined as the

Kremer, Jonsson                                                 [Page 5]

INTERNET-DRAFT          ROHC Implementer's Guide       February 28, 2003

   interpretation interval to use for all TS values.  It is thus unclear
   which p-value to use, at least for timer-based compression.

   The way this should be interpreted is that the p-value differs
   depending on whether timer-based compression is enabled or not.  For
   timer-based compression, the interpretation interval of section
   4.5.4, p = 2^(k-1) - 1, is used for TS.  Otherwise, the interval of
   section 5.7, p = 2^(k-2) - 1, is used for TS with regular W-LSB

   Since two different p-values are used, the compressor must take this
   into account during the process of enabling timer-based compression.
   Before timer-based compression can be used, the decompressor will
   have to inform the compressor (on a per-channel basis) about its
   clock resolution, and the compressor has to send (on a per-context
   basis) a non-zero TIME_STRIDE to the decompressor.

   When the compressor is confident that the decompressor has received
   the TIME_STRIDE value, it can switch to timer-based compression.
   During this transition from window-based compression to timer-based
   compression, it is necessary that the compressor keeps k large enough
   to cover both interpretation intervals.

4.2.3.  Recalculating TS_OFFSET

   TS can be sent unscaled if the TS value change does not match the
   established TS_STRIDE, but the TS_STRIDE might still stay unchanged.
   To ensure correct decompression of subsequent packets, the
   decompressor should therefore always recalculate the RTP TS modulo,
   TS_OFFSET, when a packet with an unscaled TS value is received.

4.3.  List compression issues

4.3.1.  Generic extension header list

   Section defines the static and dynamic parts of the IPv4
   header.  This section indicates a 'Generic extension header list'
   field in the dynamic chain, which has a variable length.  The
   detailed description of this field can be found in Section

   The generic extension header list starts with an octet that is always
   present, so its length is one octet, at least.  If the 'GP' bit in
   the first octet is set to 1 then the length of the list is two
   octets, even if the list is empty.

4.3.2.  CSRC list items in RTP dynamic chain

   Section defines the static and dynamic parts of the RTP
   header.  This section indicates a 'Generic CSRC list' field in the
   dynamic chain, which has a variable length.  This field uses the same

Kremer, Jonsson                                                 [Page 6]

INTERNET-DRAFT          ROHC Implementer's Guide       February 28, 2003

   encoding rules as the 'Generic extension header list' in the IPv4
   header, so the same rules apply to its length.

4.3.3.  RTP dynamic chain

   Section defines the static and dynamic parts of the RTP
   header.  In the dynamic part, a 'CC' field indicates the number of
   CSRC items present in the 'Generic CSRC list'. It should be noted
   that when the value of this CC field is equal to zero, there is no
   Generic CSRC list present in the dynamic chain, i.e. the field
   comment should have said "variable length, present if CC > 0". A 'CC'
   field can also be found within the 'Generic CSRC list' (when
   present), and these fields would then have the same meaning. In order
   to decode a compressed packet correctly it's necessary to know the
   'CC' value because it has serious impact on the packet's length.  In
   normal case, the values of the fields are equal.

   Proposed behavior if the values are different:
      Both fields are within the RTP dynamic part but only the second
      'CC' field resides inside the 'Generic CSRC list' together with
      the XI items.  Since the 'CC' value determines the number of XI
      items in the CSRC list and isn't used otherwise, the first CC
      field should be ignored and only the second field (inside the CSRC
      list) should be used for incoming packets.  For outgoing packets
      both fields should be set to the same value.

4.3.4.  CSRC list in UO-1-ID packets

   This section describes the situation when a UO-1-ID packet carries a
   CSRC list.  Compressed CSRC lists are encoded using Encoding Type 0
   (section 5.7.5 and and every list may have a unique
   identifier (gen_id).  The identifier is present in U/O-mode when the
   compressor decides that it may use this list as a future reference.

   On one hand, the decompressor shouldn't save the list because UO-1-ID
   packets doesn't update the context.  On the other hand, the
   decompressor updates its translation table whenever an (Index, item)
   pair is received (section 5.8.1).  The decompressor must be able to
   handle such a packet, thus it has to behave as described in the
   latter case.  According to section, the compressor must
   increment Counter by 1.

4.3.5.  Bit masks in list compression

   A 7-bit or 15-bit mask may be used in the insertion and/or removal
   schemes for compressed lists. It should be noted that even if a list
   has more than 7 items, a 7-bit mask can be used as long as changes
   are only applied in the first part of the reference list, and all
   items with an index not covered by the 7-bit mask are then kept

Kremer, Jonsson                                                 [Page 7]

INTERNET-DRAFT          ROHC Implementer's Guide       February 28, 2003

4.4.  Meaning of NBO

   In general, an unset flag indicates the normal operation and a set
   flag indicates unusual behavior.  However, in IPv4 dynamic part
   (Section, if the 'NBO' bit is set, it means that network
   byte order is used.

4.5.  Implicit updates

   If an updating packet (e.g. R-0-CRC or UO-0) contains information
   about a specific field X (compressed RTP sequence number, typically),
   then X is updated according to the content of that packet.  But this
   packet implicitly updates all other inferred fields (i.e. RTP
   timestamp) according to the current mode and the appropriate mapping
   function of the updated and the inferred fields.

   An updating packet thus updates the reference values of all header
   fields, either explicitly or implicitly, with an exception for the
   UO-1-ID packet, which only updates TS, SN and IP-ID (see 5.7.3). In
   UO-mode, all packets are updating packets, while in R-mode all
   packets with a CRC are updating packets.

   For example, a UO-0 packet contains the compressed RTP sequence
   number (SN).  Such a packet also updates RTP timestamp and IPv4 ID,

4.6.  IP-ID

   According to Section 5.7 IP-ID means the compressed value of the IPv4
   header's 'Identification' field. Type 0, 1 and 2 packets contain the
   compressed value (IP-ID), however IR packets with dynamic chain and
   IR-DYN packets transmit the original, uncompressed value.  This is
   because the dynamic part of the IPv4 header (Section
   contains the 'Identification' field instead of the IP-ID.

4.7.  Extension-3 in UO-1-ID packets

   Extension-3 is applied to give values and indicate changes to fields
   other than SN, TS and IP-ID in IP header(s) and RTP header.  In case
   of UO-1-ID packets, it should be noted that values provided in
   extensions do not update the context, with an exception for SN, TS
   and IP-ID fields, which always update the context (Section 5.7.3.).
   It should also be noted that a UO-1-ID packet with Extension 3 must
   never be sent with RND flags that changes the packet interpretation,
   i.e. that would violate the base condition for UO-1-ID (at least one
   RND value must be 0).

   Besides, usage of Extension-3 in UO-1-ID can be useful to compress a
   transient change in a packet stream.  For example, if a field's value
   changes in the current packet but in the next packet it returns to
   its regular behavior.  E.g. changes in TTL.

Kremer, Jonsson                                                 [Page 8]

INTERNET-DRAFT          ROHC Implementer's Guide       February 28, 2003

4.8.  Extension-3 in UOR-2* packets

   If Extension-3 is used in a UOR-2* packet then the information of the
   extension updates the context (Section 5.7.4).  Some flags of the IP
   header in the extension (e.g. NBO or RND) can change the
   interpretation of fields in UOR-2* packets. In these cases, when a
   flag changes in Extension-3, a decompressor should re-parse the UOR-
   2* packet.

4.9.  Multiple SN options in one feedback packet

   The length of the sequence number field in the original ESP header is
   32 bits.  A decompressor can't send back all the 32 bits in a
   feedback packet unless it uses multiple SN options in one feedback
   packet.  Section declares that a FEEDABCK-2 packet can
   contain variable number of feedback options and the options can
   appear in any order.

   A compressor - that wants to be conform to the specification - should
   be able to process multiple SN options in one feedback packet.

4.10.  Packet decoding during mode transition

   Each ROHC profile defines its own set of packet formats, and also its
   own feedback packets. The use of various operational modes is also
   defined by each specific profile. A decompressor can therefore not
   initiate a mode transfer request before at least one packet of a new
   context has been correctly decompressed, establishing the context
   based on one specific profile (as specified in IR packets). First
   then the context has been established, the decompressor knows the
   profile used, which modes are defined by that profile, and the
   feedback packet formats available.

   If the transition procedures in sections 5.6.5 and 5.6.6 of [RFC3095]
   are followed (and not the enhanced procedures described in section 3
   of this document), it is important to note that type 0 or type 1
   packets may be received by the decompressor during the first half of
   the transition procedure, and these packets must not mistakenly be
   interpreted as the packets sent by the compressor to indicate
   completed transition. The decompressor side must therefore keep track
   of the transition status, e.g. with an additional parameter. If the
   enhanced transition procedures described in section 3 of this
   document are used, the D_TRANS parameter can serve this purpose since
   its definition and usage is slightly modified.

4.11.  How to respond to lost feedback links?

   One potential issue that might have to be considered, depending on
   link technology, is whether feedback links might get lost, and in
   such cases how this is handled. When the compressor is notified that

Kremer, Jonsson                                                 [Page 9]

INTERNET-DRAFT          ROHC Implementer's Guide       February 28, 2003

   the feedback channel is down, the compressor must be able to handle
   it by restarting compression with creating a new context. Creating a
   new context also implies to use a new CID value.

   Generally, feedback links are not expected to disappear when once
   present, but it should be noted that this might be the case for
   certain link technologies.

4.12.  What does "presumed zero if absent" mean on page 88?

   On page 88, RFC 3095 says that R-P contains the absolute value of RTP
   Padding bit and it's presumed zero if absent.  It could be absent
   from RTP header flags and fields, from the extension type 3 or from
   the ROHC packet. It's been agreed that the RTP padding bit is
   presumed zero if absent from the RTP header flags.

4.13.  UOR-2 in profile 2 (UDP)

   One single new format is defined for UOR-2 in profile 2, which
   replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) formats from profile
   1. The same UOR-2 format is thus used independent of if there are IP
   headers with a corresponding RND=1 or not.

5.  ROHC negotiation clarifications

   Section 4.1 states that the link layer must provide means to
   negotiate e.g. the channel parameters listed in section 5.1.1.  One
   of these parameters is the PROFILES parameter, which is said to be a
   set of non-negative integers where each integer indicates a profile
   supported by the decompressor.  This can be interpreted as if it is
   sufficient to have a mechanism to announce profile support from
   decompressor to compressor.  However, things are a little bit more
   complicated than that.

   Each profile is identified by a 16-bit value, where the 8 LSB bits
   indicate the actual profile, and the 8 MSB bits indicate the variant
   of that profile (see chapter 8).  In the ROHC headers sent over the
   link, the profile used is identified only with the 8 LSB bits, which
   means that the compressor and decompressor must have agreed on which
   variant to use for each profile.  This can be done in various ways,
   but the negotiation protocol must provide means to do it.

   In conclusion, the negotiation protocol must be able to communicate
   to the compressor the set of profiles supported by the decompressor,
   and when multiple variants of the same profile are available, also
   provide means for the decompressor to know which variant will be used
   by the compressor.  This basically means that the PROFILES set after
   negotiation must not include more than one variant of the same

Kremer, Jonsson                                                [Page 10]

INTERNET-DRAFT          ROHC Implementer's Guide       February 28, 2003

6.  PROFILES suboption in ROHC-over-PPP

   The logical union of suboptions for IPCP and IPV6CP negotiations, as
   specified by ROHC over PPP [RFC-3241], can not be used for the
   PROFILES suboption, as the whole union would then have to be
   considered within each of the two IPCP negotiations, to avoid getting
   an ambiguous profile set. An implementation of RFC 3241 must
   therefore make sure the same profile set is negotiated for both IPv4
   and IPv6 (IPCP and IPV6CP).

7.  Test Configuration

   ROHC is used to compress IP/UDP/RTP, IP/UDP and IP/ESP headers, thus
   every ROHC implementation has an interface that can send and receive
   IP packets (i.e. Ethernet).  On the other hand, there must be an
   interface (a serial link for example) or other means of transport (an
   IP/UDP flow), which can transmit ROHC packets.  Having these two
   interfaces several configurations can be set up.  The figure below
   shows sample configurations that can be used for testing a ROHC

    IP/UDP/RTP +------------+      ROHC      +--------------+ IP/UDP/RTP
     packets   |    ROHC    |     packets    |     ROHC     | packets
    ---------->| Compressor |----->    ----->| Decompressor |---------->
               +------------+                +--------------+

   Unfortunately, comparing the IP/UDP/RTP packets at the endpoints can
   only show whether the reconstructed stream differs from the original
   or not.  In order to identify the place of the error more detailed
   tests are needed.  The next figure shows another possible scenario:

    IP/UDP/RTP +------------+  ROHC  IP/UDP/RTP +--------------+  ROHC
     packets   |    ROHC    | packets  packets  |     ROHC     | packets
        +----->| Compressor |----->+     +<-----| Decompressor |<-----+
        |      +------------+      |     |      +--------------+      |
        |                          |     |                            |
        |      +------------+      |     |       +------------+       |
        |      |    Test    |      |     |       |    Test    |       |
        +<-----| Equipment  |<-----+     +------>| Equipment  |------>+
               +------------+                    +------------+

   In the first case, the test equipment generates the RTP stream and
   also acts as a ROHC decompressor.  The tester must recognize if the
   original RTP stream was compressed in a bad way and gives an alarm.
   In the second case, it is the test equipment that sends the
   compressed ROHC packets and the Decompressor reconstructs the RTP
   stream.  Since the tester knows the ROHC packets and the
   reconstructed RTP stream it can detect if the Decompressor makes a

Kremer, Jonsson                                                [Page 11]

INTERNET-DRAFT          ROHC Implementer's Guide       February 28, 2003

8.  Security considerations

   This document provides a number of clarifications to [RFC-3095], but
   it does not make any changes or additions to the protocol.  As a
   consequence, the security considerations of [RFC-3095] apply without

9.  Acknowledgment

   The authors would like thank Vicknesan Ayadurai, Carsten Bormann,
   Zhigang Liu, Abigail Surtees and Mark West for their contributions
   and comments.

10.  References

   [RFC-3095]   C. Bormann, Editor, "RObust Header Compression (ROHC)",
                RFC 3095, July 2001.

   [RFC-3241]   C. Bormann, "Robust Header Compression (ROHC) over PPP",
                RFC 3241, April 2002.

   [RFC-1662]   W. Simpson, Editor, "PPP in HDLC-like Framing",
                RFC 1662, July 1994.

11.  Authors' Addresses

   Peter Kremer
   Conformance and Software Test Laboratory
   Ericsson Hungary
   H-1300 Bp. 3., P.O. Box 107, HUNGARY

   Phone: +36-1-437-7033
   Fax:   +36-1-437-7767
   Email: Peter.Kremer@ericsson.com

   Lars-Erik Jonsson
   Ericsson AB
   Box 920
   SE-971 28 Lulea, Sweden

   Phone: +46 920 20 21 07
   Fax:   +46 920 20 20 99
   EMail: lars-erik.jonsson@ericsson.com

Kremer, Jonsson                                                [Page 12]

INTERNET-DRAFT          ROHC Implementer's Guide       February 28, 2003

Appendix A.  Sample CRC algorithm

   #!/usr/bin/perl -w
   use strict;
   # ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
   # This little demo shows the three types of CRC in use in RFC 3095,
   # the robust header compression standard.  Type your data in
   # hexadecimal form and the press Control+D.
   # utility
   sub dump_bytes($) {
       my $x = shift;
       my $i;
       for ($i = 0; $i < length($x); ) {
     printf("%02x ", ord(substr($x, $i, 1)));
     printf("\n") if (++$i % 16 == 0);
       printf("\n") if ($i % 16 != 0);

   # The CRC calculation algorithm.
   sub do_crc($$$) {
       my $nbits = shift;
       my $poly = shift;
       my $string = shift;

       my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
       for (my $i = 0; $i < length($string); ++$i) {
     my $byte = ord(substr($string, $i, 1));
     for( my $b = 0; $b < 8; $b++ ) {
         if (($crc & 1) ^ ($byte & 1)) {
          $crc >>= 1;
          $crc ^= $poly;
         } else {
          $crc >>= 1;
         $byte >>= 1;
       printf "%2d bits, ", $nbits;
       printf "CRC: %02x\n", $crc;

Kremer, Jonsson                                                [Page 13]

INTERNET-DRAFT          ROHC Implementer's Guide       February 28, 2003

   # Test harness
   $/ = undef;
   $_ = <>;         # read until EOF
   my $string = ""; # extract all that looks hex:
   s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;

   # 32-bit segmentation CRC
   # Note that the text implies this is complemented like for PPP
   # (this differs from 8, 7, and 3-bit CRC)
   #      C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
   #             x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
   do_crc(32, 0xedb88320, $string);

   # 8-bit IR/IR-DYN CRC
   #      C(x) = x^0 + x^1 + x^2 + x^8
   do_crc(8, 0xe0, $string);

   # 7-bit FO/SO CRC
   #      C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7
   do_crc(7, 0x79, $string);

   # 3-bit FO/SO CRC
   #      C(x) = x^0 + x^1 + x^3
   do_crc(3, 0x6, $string);

Kremer, Jonsson                                                [Page 14]

INTERNET-DRAFT          ROHC Implementer's Guide       February 28, 2003

Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

This Internet-Draft expires August 28, 2003.

Kremer, Jonsson                                                [Page 15]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/