RFC 5225
RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite
6.9. Feedback Formats and Options
6.9.1. Feedback Formats
This section describes the feedback format for ROHCv2 profiles, using the formats described in Section 5.2.3 of [RFC4995]. The Acknowledgment Number field of the feedback formats contains the least significant bits of the MSN (see Section 6.3.1) that corresponds to the reference header that is being acknowledged. A reference header is a header that has been successfully CRC-8 validated or CRC verified. If there is no reference header available, the feedback MUST carry an ACKNUMBER-NOT-VALID option. FEEDBACK-1
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Acknowledgment Number |
+---+---+---+---+---+---+---+---+
Acknowledgment Number: The eight least significant bits of the
MSN.
A FEEDBACK-1 is an ACK. In order to send a NACK or a STATIC-NACK,
FEEDBACK-2 must be used.
FEEDBACK-2
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| Acknowledgment Number |
+---+---+---+---+---+---+---+---+
| Acknowledgment Number |
+---+---+---+---+---+---+---+---+
| CRC |
+---+---+---+---+---+---+---+---+
/ Feedback options /
+---+---+---+---+---+---+---+---+
Acktype:
0 = ACK
1 = NACK
2 = STATIC-NACK
3 is reserved (MUST NOT be used for parsability)
Acknowledgment Number: The least significant bits of the MSN.
CRC: 8-bit CRC computed over the entire feedback payload including
any CID fields but excluding the feedback type, the 'Size' field,
and the 'Code' octet, using the polynomial defined in Section
5.3.1.1 of [RFC4995]. If the CID is given with an Add-CID octet,
the Add-CID octet immediately precedes the FEEDBACK-1 or
FEEDBACK-2 format. For purposes of computing the CRC, the CRC
field is zero.
Feedback options: A variable number of feedback options, see
Section 6.9.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 corresponds to a packet whose LSBs match the Acknowledgment Number of the feedback element, unless the ACKNUMBER-NOT-VALID option (see Section 6.9.2.2) 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 comparing the result with the CRC carried in the feedback format. If the two are not identical, the feedback element MUST be discarded.6.9.2. Feedback Options
A 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 Len (octets) +---+---+---+---+---+---+---+---+ Opt Type: Unsigned integer that represents the type of the feedback option. Section 6.9.2.1 through Section 6.9.2.4 describes the ROHCv2 feedback options. Opt Len: Unsigned integer that represents the length of the Option Data field, in octets. Option Data: Feedback type specific data. Present if the value of the Opt Len field is set to a non-zero value.6.9.2.1. The REJECT Option
The REJECT option informs the compressor that the decompressor does not have sufficient resources to handle the flow. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | Opt Type = 2 | Opt Len = 0 | +---+---+---+---+---+---+---+---+ 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.6.9.2.2. The ACKNUMBER-NOT-VALID Option
The ACKNUMBER-NOT-VALID option indicates that the Acknowledgment Number field of the feedback is not valid. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | Opt Type = 3 | Opt Len = 0 | +---+---+---+---+---+---+---+---+ A compressor MUST NOT use the Acknowledgment Number of the feedback to find the corresponding sent header when this option is present. When this option is used, the Acknowledgment Number field of the FEEDBACK-2 format is set to zero. Consequently, a NACK or a STATIC- NACK feedback type sent with the ACKNUMBER-NOT-VALID option is equivalent to a STATIC-NACK with respect to the type of context repair requested by the decompressor. The ACKNUMBER-NOT-VALID option MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, the compressor MUST discard the entire feedback element.6.9.2.3. The CONTEXT_MEMORY Option
The CONTEXT_MEMORY option informs the compressor 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.6.9.2.4. The CLOCK_RESOLUTION Option
The CLOCK_RESOLUTION option informs the compressor of the clock resolution of the decompressor. It also informs whether or not the decompressor supports timer-based compression of the RTP TS timestamp
(see Section 6.6.9). The CLOCK_RESOLUTION option is applicable per channel, i.e., it applies to any context associated with a profile for which the option is relevant between a compressor and decompressor pair. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | Opt Type = 10 | Opt Len = 1 | +---+---+---+---+---+---+---+---+ | Clock resolution (ms) | +---+---+---+---+---+---+---+---+ Clock resolution: Unsigned integer that represents the clock resolution of the decompressor expressed in milliseconds. The smallest clock resolution that can be indicated is 1 millisecond. The value zero has a special meaning: it indicates that the decompressor cannot do timer-based compression of the RTP Timestamp. The CLOCK_RESOLUTION option MUST NOT appear more than once in the FEEDBACK-2 format; otherwise, the compressor MUST discard the entire feedback element.6.9.2.5. Unknown Option Types
If an option type other than those defined in this document is encountered, the compressor MUST discard the entire feedback element.7. Security Considerations
Impairments such as bit errors on the received compressed headers, missing packets, and reordering between packets could cause the header decompressor to reconstitute erroneous packets, i.e., packets that do not match the original packet, but still have a valid IP, UDP (or UDP-Lite), and RTP headers, and possibly also valid UDP (or UDP- Lite) checksums. The header compression profiles defined herein use an internal checksum for verification of reconstructed headers. This reduces the probability that a header decompressor delivers erroneous packets to upper layers without the error being noticed. In particular, the probability that consecutive erroneous packets are not detected by the internal checksum is close to zero. This small but non-zero probability remains unchanged when integrity protection is applied after compression and verified before decompression, in the case where an attacker could discard or reorder packets between the compression endpoints.
The impairments mentioned above could be caused by a malfunctioning or malicious header compressor. Such corruption may be detected with end-to-end integrity mechanisms that will not be affected by the compression. Moreover, the internal checksum can also be useful in the case of malfunctioning compressors. Denial-of-service attacks are possible if an intruder can introduce (for example) bogus IR 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.8. IANA Considerations
The following ROHC profile identifiers have been assigned by the IANA for the profiles defined in this document: Identifier Profile ---------- ------- 0x0101 ROHCv2 RTP 0x0102 ROHCv2 UDP 0x0103 ROHCv2 ESP 0x0104 ROHCv2 IP 0x0107 ROHCv2 RTP/UDP-Lite 0x0108 ROHCv2 UDP-Lite9. Acknowledgements
The authors would like to thank Mark West, Robert Finking, Haipeng Jin, and Rohit Kapoor for serving as committed document reviewers, and also for constructive discussions during the development of this document. Thanks to Carl Knutsson for his extensive contribution to this specification, as well as to Jani Juvan and Anders Edqvist for useful comments and feedback. Thanks also to Elwyn Davies for his review as the General Area Review Team (Gen-ART) reviewer, and to Stephen Kent for his review on behalf of the IETF security directorate, during IETF last-call. Finally, thanks to the many people who have contributed to previous ROHC specifications and supported this effort.
10. References
10.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 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. [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. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. [RFC4019] Pelletier, G., "RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite", RFC 4019, April 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust Header Compression (ROHC) Framework", RFC 4995, July 2007.
[RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust Header Compression (ROHC-FN)", RFC 4997, July 2007.10.2. Informative References
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999. [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. [RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Compression Profile for IP", RFC 3843, June 2004. [RFC4224] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, January 2006.
Appendix A. Detailed Classification of Header Fields
Header compression is possible due to the fact that most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When designing a header compression scheme, it is of fundamental importance to understand the behavior of the fields in detail. In this appendix, all fields in the headers compressible by these profiles are classified and analyzed. The analysis is based on behavior for the types of traffic that are expected to be the most frequently compressed (e.g., RTP field behavior is based on voice and/or video traffic behavior). Fields are classified as belonging to one of the following classes: INFERRED - These fields contain values that can be inferred from other values, for example the size of the frame carrying the packet, and thus do not have to be included in compressed packets. STATIC - These fields are expected to be constant throughout the lifetime of the flow; in general, it is sufficient to design a compressed format so that these fields are only updated by IR packets. STATIC-DEF - These fields are expected to be constant throughout the lifetime of the flow and their values can be used to define a flow. They are only sent in IR packets. STATIC-KNOWN - These fields are expected to have well-known values and therefore do not need to be communicated at all. SEMISTATIC - These fields are unchanged most of the time. However, occasionally the value changes but will revert to its original value. For ROHCv2, the values of such fields do not need to be possible to change with the smallest compressed packet formats, but should be possible to change via slightly larger compressed packets. RARELY CHANGING (RACH) - These are fields that change their values occasionally and then keep their new values. For ROHCv2, the values of such fields do not need to be possible to change with the smallest compressed packet formats, but should be possible to change via slightly larger compressed packets. IRREGULAR - These are the fields for which no useful change pattern can be identified and should be transmitted uncompressed in all compressed packets.
PATTERN - These are fields that change between each packet, but change in a predictable pattern.A.1. IPv4 Header Fields
+------------------------+----------------+ | Field | Class | +------------------------+----------------+ | Version | STATIC-KNOWN | | Header Length | STATIC-KNOWN | | Type Of Service | RACH | | Packet Length | INFERRED | | Identification | | | Sequential | PATTERN | | Seq. swap | PATTERN | | Random | IRREGULAR | | Zero | STATIC | | Reserved flag | STATIC-KNOWN | | Don't Fragment flag | RACH | | More Fragments flag | STATIC-KNOWN | | Fragment Offset | STATIC-KNOWN | | Time To Live | RACH | | Protocol | STATIC-DEF | | Header Checksum | INFERRED | | Source Address | STATIC-DEF | | Destination Address | STATIC-DEF | +------------------------+----------------+ Version The version field states which IP version is used and is set to the value four. Header Length As long as no options are present in the IP header, the header length is constant with the value five. If there are options, the field could be RACH or STATIC-DEF, but only option-less headers are compressed by ROHCv2 profiles. The field is therefore classified as STATIC-KNOWN. Type Of Service For the type of flows compressed by the ROHCv2 profiles, the DSCP (Differentiated Services Code Point) and ECN (Explicit Congestion Notification) fields are expected to change relatively seldom.
Packet Length
Information about packet length is expected to be provided by the
link layer. The field is therefore classified as INFERRED.
IPv4 Identification
The Identification field (IP-ID) is used to identify what
fragments constitute a datagram when reassembling fragmented
datagrams. The IPv4 specification does not specify exactly how
this field is to be assigned values, only that each packet should
get an IP-ID that is unique for the source-destination pair and
protocol for the time the datagram (or any of its fragments) could
be alive in the network. This means that assignment of IP-ID
values can be done in various ways, but the expected behaviors
have been separated into four classes.
Sequential
In this behavior, the IP-ID is expected to increment by one for
most packets, but may increment by a value larger than one,
depending on the behavior of the transmitting IPv4 stack.
Sequential Swapped
When using this behavior, the IP-ID behaves as in the
Sequential behavior, but the two bytes of IP-ID are byte-
swapped. Therefore, the IP-ID can be swapped before
compression to make it behave exactly as the Sequential
behavior.
Random
Some IP stacks assign IP-ID values using a pseudo-random number
generator. There is thus no correlation between the ID values
of subsequent datagrams, and therefore there is no way to
predict the IP-ID value for the next datagram. For header
compression purposes, this means that the IP-ID field needs to
be sent uncompressed with each datagram, resulting in two extra
octets of header.
Zero
This behavior, although not a legal implementation of IPv4, is
sometimes seen in existing IPv4 stacks. When this behavior is
used, all IP packets have the IP-ID value set to zero.
Flags
The Reserved flag must be set to zero and is therefore classified
as STATIC-KNOWN. The Don't Fragment (DF) flag changes rarely and
is therefore classified as RACH. Finally, the More Fragments (MF)
flag is expected to be zero because IP fragments will not be
compressed by ROHC and is therefore classified as STATIC-KNOWN.
Fragment Offset
Under the assumption that no fragmentation occurs, the fragment
offset is always zero and is therefore classified as STATIC-KNOWN.
Time To Live
The Time To Live field is expected to be constant during the
lifetime of a flow or to alternate between a limited number of
values due to route changes.
Protocol
This field will have the same value in all packets of a flow and
is therefore classified as STATIC-DEF.
Header Checksum
The header checksum protects individual hops from processing a
corrupted header. When almost all IP header information is
compressed away, there is no point in having this additional
checksum; instead, it can be regenerated at the decompressor side.
The field is therefore classified as INFERRED.
Source and Destination addresses
These fields are part of the definition of a flow and must thus be
constant for all packets in the flow.
A.2. IPv6 Header Fields
+----------------------+----------------+ | Field | Class | +----------------------+----------------+ | Version | STATIC-KNOWN | | Traffic Class | RACH | | Flow Label | STATIC-DEF | | Payload Length | INFERRED | | Next Header | STATIC-DEF | | Hop Limit | RACH | | Source Address | STATIC-DEF | | Destination Address | STATIC-DEF | +----------------------+----------------+ Version The version field states which IP version is used and is set to the value six. Traffic Class For the type of flows compressed by the ROHCv2 profiles, the DSCP and ECN fields are expected to change relatively seldom. Flow Label This field may be used to identify packets belonging to a specific flow. If it is not used, the value should be set to zero. Otherwise, all packets belonging to the same flow must have the same value in this field. The field is therefore classified as STATIC-DEF. Payload Length Information about packet length (and, consequently, payload length) is expected to be provided by the link layer. The field is therefore classified as INFERRED. Next Header This field will have the same value in all packets of a flow and is therefore classified as STATIC-DEF.
Hop Limit
The Hop Limit field is expected to be constant during the lifetime
of a flow or to alternate between a limited number of values due
to route changes.
Source and Destination addresses
These fields are part of the definition of a flow and must thus be
constant for all packets in the flow. The fields are therefore
classified as STATIC-DEF.
A.3. UDP Header Fields
+------------------+-------------+
| Field | Class |
+------------------+-------------+
| Source Port | STATIC-DEF |
| Destination Port | STATIC-DEF |
| Length | INFERRED |
| Checksum | |
| Disabled | STATIC |
| Enabled | IRREGULAR |
+------------------+-------------+
Source and Destination ports
These fields are part of the definition of a flow and must thus be
constant for all packets in the flow.
Length
Information about packet length is expected to be provided by the
link layer. The field is therefore classified as INFERRED.
Checksum
The checksum can be optional. If disabled, its value is
constantly zero and can be compressed away. If enabled, its value
depends on the payload, which for compression purposes is
equivalent to it changing randomly with every packet.
A.4. UDP-Lite Header Fields
+--------------------+-------------+ | Field | Class | +--------------------+-------------+ | Source Port | STATIC-DEF | | Destination Port | STATIC-DEF | | Checksum Coverage | | | Zero | STATIC-DEF | | Constant | INFERRED | | Variable | IRREGULAR | | Checksum | IRREGULAR | +--------------------+-------------+ Source and Destination Port These fields are part of the definition of a flow and must thus be constant for all packets in the flow. Checksum Coverage The Checksum Coverage field may behave in different ways: it may have a value of zero, it may be equal to the datagram length, or it may have any value between eight octets and the length of the datagram. From a compression perspective, this field is expected to either be entirely predictable (for the cases where it follows the same behavior as the UDP Length field or where it takes on a constant value) or to change randomly for each packet (making the value unpredictable from a header-compression perspective). For all cases, the behavior itself is not expected to change for this field during the lifetime of a packet flow, or to change relatively seldom. Checksum The information used for the calculation of the UDP-Lite checksum is governed by the value of the checksum coverage and minimally includes the UDP-Lite header. The checksum is a changing field that must always be sent as-is.
A.5. RTP Header Fields
+----------------+----------------+ | Field | Class | +----------------+----------------+ | Version | STATIC-KNOWN | | Padding | RACH | | Extension | RACH | | CSRC Counter | RACH | | Marker | SEMISTATIC | | Payload Type | RACH | | Sequence Number| PATTERN | | Timestamp | PATTERN | | SSRC | STATIC-DEF | | CSRC | RACH | +----------------+----------------+ Version This field is expected to have the value two and the field is therefore classified as STATIC-KNOWN. Padding The use of this field is application-dependent, but when payload padding is used, it is likely to be present in most or all packets. The field is classified as RACH to allow for the case where the value of this field changes. Extension If RTP extensions are used by the application, these extensions are often present in all packets, although the use of extensions is infrequent. To allow efficient compression of a flow using extensions in only a few packets, this field is classified as RACH. CSRC Count This field indicates the number of CSRC items present in the CSRC list. This number is expected to be mostly constant on a packet- to-packet basis and when it changes, change by small amounts. As long as no RTP mixer is used, the value of this field will be zero.
Marker
For audio, the marker bit should be set only in the first packet
of a talkspurt, while for video, it should be set in the last
packet of every picture. This means that in both cases the RTP
marker is classified as SEMISTATIC.
Payload Type
Applications could adapt to congestion by changing payload type
and/or frame sizes, but that is not expected to happen frequently,
so this field is classified as RACH.
RTP Sequence Number
The RTP Sequence Number will be incremented by one for each packet
sent.
Timestamp
In the audio case:
As long as there are no pauses in the audio stream, the RTP
Timestamp will be incremented by a constant value, which
corresponds to the number of samples in the speech frame. It
will thus mostly follow the RTP Sequence Number. When there
has been a silent period and a new talkspurt begins, the
timestamp will jump in proportion to the length of the silent
period. However, the increment will probably be within a
relatively limited range.
In the video case:
Between two consecutive packets, the timestamp will either be
unchanged or increase by a multiple of a fixed value
corresponding to the picture clock frequency. The timestamp
can also decrease by a multiple of the fixed value for certain
coding schemes. The change in timestamp value, expressed as a
multiple of the picture clock frequency, is in most cases
within a limited range.
SSRC
This field is part of the definition of a flow and must thus be
constant for all packets in the flow. The field is therefore
classified as STATIC-DEF.
Contributing Sources (CSRC)
The participants in a session, who are identified by the CSRC
fields, are usually expected to be unchanged on a packet-to-packet
basis, but will infrequently change by a few additions and/or
removals.
A.6. ESP Header Fields
+------------------+-------------+
| Field | Class |
+------------------+-------------+
| SPI | STATIC-DEF |
| Sequence Number | PATTERN |
+------------------+-------------+
SPI
This field is used to identify a distinct flow between two IPsec
peers and it changes rarely; therefore, it is classified as
STATIC-DEF.
ESP Sequence Number
The ESP Sequence Number will be incremented by one for each packet
sent.
A.7. IPv6 Extension Header Fields
+-----------------------+---------------+
| Field | Class |
+-----------------------+---------------+
| Next Header | STATIC-DEF |
| Ext Hdr Len | |
| Routing | STATIC-DEF |
| Hop-by-hop | STATIC |
| Destination | STATIC |
| Options | |
| Routing | STATIC-DEF |
| Hop-by-hop | RACH |
| Destination | RACH |
+-----------------------+---------------+
Next Header
This field will have the same value in all packets of a flow and
is therefore classified as STATIC-DEF.
Ext Hdr Len
For the Routing header, it is expected that the length will remain
constant for the duration of the flow, and that a change in the
length should be classified as a new flow by the ROHC compressor.
For Hop-by-hop and Destination options headers, the length is
expected to remain static, but can be updated by an IR packet.
Options
For the Routing header, it is expected that the option content
will remain constant for the duration of the flow, and that a
change in the routing information should be classified as a new
flow by the ROHC compressor. For Hop-by-hop and Destination
options headers, the options are expected to remain static, but
can be updated by an IR packet.
A.8. GRE Header Fields
+--------------------+---------------+
| Field | Class |
+--------------------+---------------+
| C flag | STATIC |
| K flag | STATIC |
| S flag | STATIC |
| R flag | STATIC-KNOWN |
| Reserved0, Version | STATIC-KNOWN |
| Protocol | STATIC-DEF |
| Checksum | IRREGULAR |
| Reserved | STATIC-KNOWN |
| Sequence Number | PATTERN |
| Key | STATIC-DEF |
+--------------------+---------------+
Flags
The four flag bits are not expected to change for the duration of
the flow, and the R flag is expected to always be set to zero.
Reserved0, Version
Both of these fields are expected to be set to zero for the
duration of any flow.
Protocol
This field will have the same value in all packets of a flow and
is therefore classified as STATIC-DEF.
Checksum
When the checksum field is present, it is expected to behave
unpredictably.
Reserved
When present, this field is expected to be set to zero.
Sequence Number
When present, the Sequence Number increases by one for each
packet.
Key
When present, the Key field is used to define the flow and does
not change.
A.9. MINE Header Fields
+---------------------+----------------+
| Field | Class |
+---------------------+----------------+
| Protocol | STATIC-DEF |
| S bit | STATIC-DEF |
| Reserved | STATIC-KNOWN |
| Checksum | INFERRED |
| Source Address | STATIC-DEF |
| Destination Address | STATIC-DEF |
+---------------------+----------------+
Protocol
This field will have the same value in all packets of a flow and
is therefore classified as STATIC-DEF.
S bit
The S bit is not expected to change during a flow.
Reserved
The reserved field is expected to be set to zero.
Checksum
The header checksum protects individual routing hops from
processing a corrupted header. Since all fields of this header
are compressed away, there is no need to include this checksum in
compressed packets and it can be regenerated at the decompressor
side.
Source and Destination Addresses
These fields can be used to define the flow and are not expected
to change.
A.10. AH Header Fields
+---------------------+----------------+
| Field | Class |
+---------------------+----------------+
| Next Header | STATIC-DEF |
| Payload Length | STATIC |
| Reserved | STATIC-KNOWN |
| SPI | STATIC-DEF |
| Sequence Number | PATTERN |
| ICV | IRREGULAR |
+---------------------+----------------+
Next Header
This field will have the same value in all packets of a flow and
is therefore classified as STATIC-DEF.
Payload Length
It is expected that the length of the header is constant for the
duration of the flow.
Reserved
The value of this field will be set to zero.
SPI
This field is used to identify a specific flow and only changes
when the sequence number wraps around, and is therefore classified
as STATIC-DEF.
Sequence Number
The Sequence Number will be incremented by one for each packet
sent.
ICV
The ICV is expected to behave unpredictably and is therefore
classified as IRREGULAR.
Appendix B. Compressor Implementation Guidelines
This section describes some guiding principles for implementing a
ROHCv2 compressor with focus on how to efficiently select appropriate
packet formats. The text in this appendix should be considered
guidelines; it does not define any normative requirement on how
ROHCv2 profiles are implemented.
B.1. Reference Management
The compressor usually maintains a sliding window of reference
headers, which contains as many references as needed for the
optimistic approach. Each reference contains a description of which
changes occurred in the flow between two consecutive headers in the
flow, and a new reference is inserted into the window each time a
packet is compressed by this context. A reference may for example be
implemented as a stored copy of the uncompressed header being
represented. When the compressor is confident that a specific
reference is no longer used by the decompressor (for example by using
the optimistic approach or feedback received), the reference is
removed from the sliding window.
B.2. Window-based LSB Encoding (W-LSB)
Section 5.1.1 describes how the optimistic approach impacts the
packet format selection for the compressor. Exactly how the
compressor selects a packet format is up to the implementation to
decide, but the following is an example of how this process can be
performed for lsb-encoded fields through the use of Window-based LSB
encoding (W-LSB).
With W-LSB encoding, the compressor uses a number of references (a
window) from its context. What references to use is determined by
its optimistic approach. The compressor extracts the value of the
field to be W-LSB encoded from each reference in the window, and
finds the maximum and minimum values. Once it determines these
values, the compressor uses the assumption that the decompressor has
a value for this field within the range given by these boundaries
(inclusively) as its reference. The compressor can then select a number of LSBs from the value to be compressed, so that the LSBs can be decompressed regardless of whether the decompressor uses the minimum value, the maximum value or any other value in the range of possible references.B.3. W-LSB Encoding and Timer-based Compression
Section 6.6.9 defines decompressor behavior for timer-based RTP timestamp compression. This section gives guidelines on how the compressor should determine the number of LSB bits it should send for the timestamp field. When using timer-based compression, this number depends on the sum of the jitter before the compressor and the jitter between the compressor and decompressor. The jitter before the compressor can be estimated using the following computation: Max_Jitter_BC = max {|(T_n - T_j) - ((a_n - a_j) / time_stride)|, for all headers j in the sliding window} where (T_n - T_j) is the difference in the timestamp between the currently compressed header and a reference header and (a_n - a_j) is the difference in arrival time between those same two headers. In addition to this, the compressor needs to estimate an upper bound for the jitter between the compressor and decompressor (Max_Jitter_CD). This information may for example come from lower layers. A compressor implementation can determine whether the difference in clock resolution between the compressor and decompressor induces an error when performing integer arithmetics; it can then treat this error as additional jitter. After obtaining estimates for the jitters, the number of bits needed to transmit is obtained using the following calculation: ceiling(log2(2 * (Max_Jitter_BC + Max_Jitter_CD + 2) + 1)) This number is then used to select a packet format that contains at least this many scaled timestamp bits.
Authors' Addresses
Ghyslain Pelletier Ericsson Box 920 Lulea SE-971 28 Sweden Phone: +46 (0) 8 404 29 43 EMail: ghyslain.pelletier@ericsson.com Kristofer Sandlund Ericsson Box 920 Lulea SE-971 28 Sweden Phone: +46 (0) 8 404 41 58 EMail: kristofer.sandlund@ericsson.com
Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.