Robust Header Compression (ROHC) ‏

1. An introduction Jonathan Shufelt jshufelt@gmail.com Robust Header Compression (ROHC)‏

2. What is Robust Header Compression? • First specified in RFC 3095, updated by RFCs 4815 and 3759 created by the ROHC charter. • Utilizes the significant redundancy between header fields in consecutive packets from a packet stream. • Static field information is only sent initially. • Predictability of other fields is used to reduce header size.

3. What is Robust Header Compression? • Relevant information from past packets in the stream is used to maintain a context. • This context information is used to compress and decompress subsequent packets. • Certain events will cause the context to be updated. • Impairments may cause loss of context, or Context Damage. • Context Damage leads to incorrect decompression. • Provides mechanisms to avoid and recover from Context Damage.

4. ROHC Terminology • Channel – Logical link over which the ROHC header-compressed packets flow. • Context Identifiers (CID) – Uniquely identify a stream, useful when a channel is transporting more than one stream simultaneously. • Context Damage – Situation where decompressor is unable to decompress headers without error.

5. ROHC – how is it negotiated? • The use of ROHC can be manually configured, or negotiated at the time of the channel’s establishment. • State information and compression profiles available can be established at the time the channel is established, or may be predefined. • Per context parameters are initialized with IR packets, updated with IR-DYN packets.

6. Compression and Decompression states • ROHC can be characterized as an interaction between two state machines, compressor and decompressor. • State machine pairs are associated with a context identifier (CID). • The compressor and decompressor each have 3 possible states of operation. • The compressor and decompressor states are related to each other. • Both machines start in the lowest compression state.

7. Compression and Decompression states • State transitions occur in both the compressor and decompressor. • State transitions are not necessarily synchronized. • In normal operation, the compressor will temporarily transition to a lower state. • The decompressor will only transition to a lower state when context damage is detected.

8. Compressor States • Initialization and Refresh (IR) – Compressor will start here and transition to higher compression states such as FO and SO. • First Order (FO) – Efficiently communicates irregularities in the packet stream. • Second Order (SO) – Optimized compression is used and only minimal header information is sent in each packet.

9. Compressor States

10. Compressor States: Initialization and Refresh (IR) • Used to initialize static parts of context at decompresser, or to recover after failure. • Complete header information, static and non-static fields, is sent from the compressor in this state. • Compressor will remain in this state until it is fairly confident that the decompresser has correctly received the static information.

11. Compressor States: First Order (FO)‏ • Provides efficient communication of irregularities of packet stream. • Information about dynamic fields is rarely sent in this state. • Sent information in this state is usually partially compressed. • Only a few static fields can be updated in this state. • Compressor may enter this state from IR or SO states. • Transition to FO from IR is a normal step in the state machine transition.

12. Compressor States: First Order (FO)‏ • Transition to FO from SO will occur when a pattern change is present in the packet stream headers. • Compressor will remain in FO state until it is confident that decompresser has acquired all parameters of packet stream headers. • Changes in fields that are always irregular are communicated in all packets. • Some or all packets sent carry context updating information. • Detection of corruption of FO state packets is very important to avoid erroneous updates and context inconsistencies.

13. Compressor States: Second Order (SO)‏ • State of optimal compression. • Compressor enters this state when header is completely predictable given the sequence number (SN), and confidence that the decompressor has acquired the functions of SN to other fields. • Correct decompression of the SN is required to prevent Context Damage. • Compressor will transition to lower states when the header no longer conforms to uniform pattern established upon previous context information.

14. Decompressor States • No Context – Initial and lowest compression state. Used for initializing and refreshing context. • Static Context – Intermediate compression state. Used when some header fields are still dynamic in nature. • Full Context – Highest compression state. Used when all header fields are known from previous packets, or can be predicted from the SN.

15. Modes of Operation • Unidirectional – U-mode • Bidirectional Optimistic – O-mode • Bidirectional Reliable – R-mode • States and Modes abstractions are orthogonal to each other. • State abstraction is the same for all modes. • Mode controls the logic of state transitions and what actions to perform in each state. • The optimal mode of operation will depend on environmental characteristics of the compression protocol. These include feedback abilities, error probabilities and distributions, and effects of header size and variation.

16. Unidirectional mode – U-mode • Packets are sent in one direction only, from compressor to decompressor. • Useful in situations where the return path over communications link is unavailable or undesirable. • Transitions between compressor states result from periodic timeouts or irregularities in the header field change patterns of the packet stream. • Least efficient mode due to periodic refreshes and lack of feedback. • Slightly higher probability of loss propagation as compared to bidirectional modes (O-mode and R-mode) of operation. • U-mode must be used to start compression. • Transition to bidirectional modes will occur when feedback packet indicating a desire for transition is received from decompressor.

17. Bidirectional Optimistic mode – O-mode • Utilizes a feedback channel from decompressor to compressor. • Feedback channel is used to send error recovery requests and optionally acknowledgements of significant context updates. • Periodic refreshes are not used in O-mode. • Maximizes compression while minimizing usage of the feedback channel. • Reduces number of damaged headers delivered to upper layers due to residual errors or context invalidation. • Frequency of context invalidation may be higher than in R-mode. • Prone to context invalidation when long loss or burst errors are present on link.

18. Bidirectional Reliable mode – R-mode • More intensive use of feedback channel when compared to U-mode and O-mode. • Stricter logic at compressor and decompressor prevents loss of context except in the case of very high residual Bit Error Rate (BER) conditions. • Feedback is sent to acknowledge all context updates, including SN updates. • Not every feedback packet is sent to update context in R-mode.

19. Encoding Methods • Least Significant Bits (LSB) – Used for header fields whose values are subject to small value changes. • Window-based LSB (W-LSB) – Adds robustness to the LSB encoding algorithm by the compressor using a sliding window reference approach based upon feedback from decompressor. • Scaled RTP Timestamp (TS) – Scaled counter method that minimizes the encoding field size. Applied to frame-based codecs. • Offset IP-ID – In the case of IPv4 the compressor will compress the offset of the IP-ID value subtracted from the RTP SN instead of the IP-ID value itself.

20. Encoding Methods • Timer-based compression of RTP Timestamp – Utilizes fixed sampling intervals, constant sampling rate, and the fact that packets are generated lock-step with sampling to make use of a linear time-of-day relationship and decompressor’s local clock to approximate the scaled TS in the header. • Self-describing variable-length values – Compressor examines the values of up to the first 3 bits, and chooses the number of octets to use based upon their values. • Encoded values across several fields in compressed headers – Compressor examines for extension headers, compares the bits available to the bits in the value, and chooses the appropriate packet type.

21. Residual Errors • Packets may become damaged in transit between compressor and decompressor. • CRC values calculated by compressor and included in packet are used by decompressor to detect damaged packets. • Damage to packets may cause misinterpretation of packet content. • Undetected damaged packets may be passed to upper layers.

22. Impairment Considerations • Impairments can cause loss or damage to individual headers, context invalidation, loss propagation, and damage propagation. • Impairments to headers can be classified as follows: • Lower layer decoding failure, and subsequent discarding of packet. • Lower layer error detection, and subsequent discarding of packet. • ROHC error detection, and subsequent discarding of packet. • ROHC error detection failure, and subsequent passing of packet to upper layers.

23. Per-context parameters, profiles • Established with IR headers, which contain a profile identifier. • Profile identifiers determine the syntax and semantics of the packet type identifiers, and the packet types used in conjunction with the specific context. • Profiles: 0x0000 – Uncompressed IP 0x0001 – RTP/UDP/IP 0x0002 – UDP/IP 0x0003 – ESP/IP 0x0004 – IP 0x0005 – Link Layer Assisted 0x0006 – TCP/IP 0x0007 – RTP/UDP-Lite/IP 0x0008 – UDP-Lite/IP

24. Contexts and context identifiers • A context is: - associated with each compressed flow. - used by compressor and decompressor to compress and decompress headers of a packet stream. - identified by Context Identifier (CID). • CIDs are sent along with compressed headers and feedback information. • CID space, size, for each channel direction may be distinct. • CID parameters are negotiated during channel establishment.

25. ROHC packets and packet types • Packet type design constraints: - must be possible to use limited number of packet sizes. - must be possible to send feedback information in separate ROHC packets as well as piggybacked on forward packets. - desirable to allow elimination of CID for one packet stream when few packet streams share a channel. - anticipated that some packets with large headers may be larger than the MTU of very constrained lower layers. • Packet design includes: - optional padding - a feedback packet type - optional Add-CID octet - simple segmentation and reassembly mechanism

26. ROHC feedback • Carries feedback from decompressor to compressor. • Principal kinds of feedback: ACK – acknowledges successful decompression. NACK – indicates that the dynamic context of the decompressor is out of sync. STATIC-NACK – indicates that the static context of the decompressor is not valid or has not been established. • Feedback for ROHC can be realized in many ways such as: • Lower layer specific mechanisms • Dedicated feedback-only channel (i.e. lower layer based, or timing based)‏ • Interspersed among normal compressed packets traveling in same direction • Piggybacking of feedback information in compressed packets traveling in same direction

27. Unidirectional Mode (U-mode) – compressor state machine • Transition logic for compression states in Unidirectional mode based upon three principles: - optimistic approach principle - timeouts - the need for updates • Feedback channels may or may not be available. Mode is designed to operate in the absence of a feedback channel.

28. Unidirectional Mode (U-mode) – compressor state machine • Optimistic approach, upwards transition – compressor will transit to a higher compression state when it is fairly confident that the decompressor has received enough information to decompress packets. • Timeouts/Updates, downwards transition – compressor must periodically transition to lower compression states (FO and IR) to ensure that the decompressor has the required information for successful decompression of packets. • Compression logic and packets used – Compressor will choose the smallest packet that can communicate the desired changes, and has the required number of bits for W-LSB encoding. • Feedback – If available, decompressor may send acknowledgements of successful decompression to the compressor. The compressor may then disable, or increase the interval, between periodic IR refreshes.

29. Unidirectional Mode (U-mode) – decompressor state machine • Successful decompression will always move the decompressor to the Full Context state. • Repeated failures will force the decompressor to transit to a lower state (Static Context (SC) or No Context (NC) ). • The decompressor does not attempt decompression in the lower states without sufficient context information present in received packets. • If feedback is present and used by the decompressor, acknowledgements may be used to control compressor state.

30. Unidirectional Mode (U-mode) – decompressor state machine • Decompression is carried out by following these steps: - Decide whether decompression is allowed. - Reconstruct and verify the header. - If header verifies correctly, remain in current state. - If header fails verification, attempt recovery, transitioning to lower state upon recovery failure. • Feedback – If available, the decompressor may send acknowledgement packets reducing the frequency of IR packets from the compressor. The decompressor may send repeated acknowledgement packets, but should not do so continuously.

31. Bidirectional Optimistic Mode (O-mode) – compressor state machine • Transition logic for compression states in Bidirectional Optimistic mode is based upon these principles: - optimistic approach principle - feedback - the need for updates • Feedback channel is available, and always used.

32. Bidirectional Optimistic Mode (O-mode) – compressor state machine • State transition logic has much in common with Unidirectional mode, but does not use timeouts. • Feedback from decompressor to compressor causes transitions to lower compression states, and may optionally be used to cause transitions to higher compression states. • Negative acknowledgements (NACKs), downward transition: - NACKs are also known as context requests. - NACKs transitions the compressor to the FO state, and prompts the compressor to send updates (IR-DYN, UOR-2, IR) to the decompressor. - Reception of a STATIC-NACK from decompressor will cause the compressor to transition to the IR state. • Optional acknowledgements, upwards transition – positive feedback (ACKs) may be used to transition the compressor to a higher state. • Compression logic and packets used – same as those used for the Unidirectional mode.

33. Bidirectional Optimistic Mode (O-mode) – decompressor state machine • Same decompression states and state logic as the Unidirectional case, with different decompression and feedback logic. • Decompression logic, timer-based timestamp decompression – May be used to improve compression efficiency when RTP timestamp values are proportional to wall clock time. • Feedback logic (O-mode): Decompressor - Three principal kinds of feedback: ACK, NACK, and STATIC-NACK. Use of optional feedback requires decompressor to send optional feedback for the lifetime of the stream. • Compressor – IR, IR-DYN, UOR-2, UO-1, and U0-0 may be sent to the decompressor depending on context conditions and state. • Decompressor State Actions – Are defined for NC, SC, and FC states and received packet types.

34. Bidirectional Reliable Mode (R-mode) – compressor state machine • Transition logic for compression states in Bidirectional Reliable Mode is based on three principles: - the secure reference principle - the need for updates - negative acknowledgements • Feedback logic is available, though more sparsely used.

35. Bidirectional Reliable Mode (R-mode) – compressor state machine • Upwards transition – Determined by secure reference principle. The secure reference principle uses acknowledgements from the decompressor to ensure that context is not lost due to packet losses. • Downward transition – Triggered by the need for context updates, or by NACK or STATIC-NACK packets received from the decompressor. • Compression logic and packets used – Compression logic starts in the IR state and makes a direct transition to the FO state upon receipt of a valid ACK from the decompressor. Transition to the SO state is dependent upon the presence of a string. The string contains information about the slope and offset values used in compression of packets. • Decompressor states and logic – State and state transition logic are the same as in the Unidirectional mode, but not the decompression and feedback logic. • Decompression logic – Rules for when decompression is allowed are the same as for U-mode. ACKing scheme in R-mode guarantees that non-decompress able packets are never sent by compressor. Residual errors may cause delivery of unexpected packets for which decompression will not be attempted. CRCs are only carried by update packets from the compressor. • Feedback logic – Rules: - Updating packets correctly decompressed cause ACK packets to be sent to compressor. - Upon detection of context damage, send NACK if in FC state, or send STATIC-NACK if in SC state. - Upon receipt of a non-IR packet in NC state, send a STATIC-NACK unless the CRC fails. - Feedback is never sent for packets not updating the context.

36. ROHC – mode transitions • The decision to move from one compression mode to another is taken by the decompressor

37. ROHC – mode transitions • For each context, the compressor and decompressor maintain a variable whose value is the current compression mode for that context. • The value of the variable controls, for the context in question, parameters such as; which packet types to use, which actions to be taken, etc. • CRCs must be used during all mode transitions as a safeguard. • Mode initiations must not be initiated by feedback that is not protected by a CRC. • Each compression mode has corresponding mode variables. • The behavior of the compressor and decompressor must be restricted during mode transition phases by exception parameters. • Exception parameters names and values are all explicitly defined for each case of mode transition.