Robust Header Compression G. Pelletier Internet-Draft K. Sandlund Intended status: Standards Track Ericsson Expires: April 4, 2008 October 2, 2007 RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP Lite draft-ietf-rohc-rfc3095bis-rohcv2-profiles-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 4, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP (Encapsulating Security Payload) headers. This specification defines a second version of the profiles found in Pelletier & Sandlund Expires April 4, 2008 [Page 1] Internet-Draft ROHCv2 Profiles October 2007 RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but does not obsolete them. The ROHCv2 profiles introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Finally, the ROHCv2 profiles define its own specific set of packet formats, using the ROHC formal notation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Background (Informative) . . . . . . . . . . . . . . . . . . 7 4.1. Classification of header fields . . . . . . . . . . . . . 7 4.2. Improvements of ROHCv2 over RFC3095 profiles . . . . . . 8 4.3. Operational Characteristics of ROHCv2 Profiles . . . . . 10 5. Overview of the ROHCv2 Profiles (Informative) . . . . . . . . 10 5.1. Compressor Concepts . . . . . . . . . . . . . . . . . . . 11 5.1.1. Optimistic Approach . . . . . . . . . . . . . . . . . 11 5.1.2. Tradeoff between robustness to losses and to reordering . . . . . . . . . . . . . . . . . . . . . 11 5.1.3. Interactions with the Decompressor Context . . . . . 13 5.2. Decompressor Concepts . . . . . . . . . . . . . . . . . . 14 5.2.1. Decompressor State Machine . . . . . . . . . . . . . 14 5.2.2. Decompressor Context Management . . . . . . . . . . . 17 5.2.3. Feedback logic . . . . . . . . . . . . . . . . . . . 19 6. ROHCv2 Profiles (Normative) . . . . . . . . . . . . . . . . . 19 6.1. Channel Parameters, Segmentation and Reordering . . . . . 19 6.2. Profile Operation, per-context . . . . . . . . . . . . . 19 6.3. Control Fields . . . . . . . . . . . . . . . . . . . . . 20 6.3.1. Master Sequence Number (MSN) . . . . . . . . . . . . 21 6.3.2. Reordering Ratio . . . . . . . . . . . . . . . . . . 21 6.3.3. IP-ID behavior . . . . . . . . . . . . . . . . . . . 21 6.3.4. UDP-Lite Coverage Behavior . . . . . . . . . . . . . 22 6.3.5. Timestamp Stride . . . . . . . . . . . . . . . . . . 22 6.3.6. Time Stride . . . . . . . . . . . . . . . . . . . . . 22 6.3.7. CRC-3 for Control Fields . . . . . . . . . . . . . . 22 6.4. Reconstruction and Verification . . . . . . . . . . . . . 23 6.5. Compressed Header Chains . . . . . . . . . . . . . . . . 23 6.6. Packet Formats and Encoding Methods . . . . . . . . . . . 25 6.6.1. baseheader_extension_headers . . . . . . . . . . . . 25 6.6.2. baseheader_outer_headers . . . . . . . . . . . . . . 25 6.6.3. inferred_udp_length . . . . . . . . . . . . . . . . . 25 Pelletier & Sandlund Expires April 4, 2008 [Page 2] Internet-Draft ROHCv2 Profiles October 2007 6.6.4. inferred_ip_v4_header_checksum . . . . . . . . . . . 26 6.6.5. inferred_mine_header_checksum . . . . . . . . . . . . 26 6.6.6. inferred_ip_v4_length . . . . . . . . . . . . . . . . 27 6.6.7. inferred_ip_v6_length . . . . . . . . . . . . . . . . 27 6.6.8. Scaled RTP Timestamp Encoding . . . . . . . . . . . . 28 6.6.9. timer_based_lsb . . . . . . . . . . . . . . . . . . . 29 6.6.10. inferred_scaled_field . . . . . . . . . . . . . . . . 30 6.6.11. control_crc3_encoding . . . . . . . . . . . . . . . . 31 6.6.12. inferred_sequential_ip_id . . . . . . . . . . . . . . 32 6.6.13. list_csrc(cc_value) . . . . . . . . . . . . . . . . . 32 6.7. Encoding Methods With External Parameters . . . . . . . . 36 6.8. Packet Formats . . . . . . . . . . . . . . . . . . . . . 39 6.8.1. Initialization and Refresh Packet (IR) . . . . . . . 39 6.8.2. Compressed Packet Formats (CO) . . . . . . . . . . . 40 6.9. Feedback Formats and Options . . . . . . . . . . . . . . 99 6.9.1. Feedback Formats . . . . . . . . . . . . . . . . . . 99 6.9.2. Feedback Options . . . . . . . . . . . . . . . . . . 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 103 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 105 10.1. Normative References . . . . . . . . . . . . . . . . . . 105 10.2. Informative References . . . . . . . . . . . . . . . . . 106 Appendix A. Detailed classification of header fields . . . . . 106 Appendix A.1. IPv4 Header Fields . . . . . . . . . . . . . . . . 107 Appendix A.2. IPv6 Header Fields . . . . . . . . . . . . . . . . 109 Appendix A.3. UDP Header Fields . . . . . . . . . . . . . . . . 111 Appendix A.4. UDP-Lite Header Fields . . . . . . . . . . . . . . 111 Appendix A.5. RTP Header Fields . . . . . . . . . . . . . . . . 112 Appendix A.6. ESP Header Fields . . . . . . . . . . . . . . . . 114 Appendix A.7. IPv6 Extension Header Fields . . . . . . . . . . . 114 Appendix A.8. GRE Header Fields . . . . . . . . . . . . . . . . 115 Appendix A.9. MINE Header Fields . . . . . . . . . . . . . . . . 116 Appendix A.10. AH Header Fields . . . . . . . . . . . . . . . . . 117 Appendix B. Compressor Implementation Guidelines . . . . . . . 117 Appendix B.1. Reference Management . . . . . . . . . . . . . . . 118 Appendix B.2. Window-based LSB Encoding (W-LSB) . . . . . . . . 118 Appendix B.3. W-LSB Encoding and Timer-based Compression . . . . 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 119 Intellectual Property and Copyright Statements . . . . . . . . . 120 Pelletier & Sandlund Expires April 4, 2008 [Page 3] Internet-Draft ROHCv2 Profiles October 2007 1. Introduction The ROHC WG has developed a header compression framework on top of which various profiles can be defined for different protocol sets or compression requirements. The ROHC framework was first documented in [RFC3095], together with profiles for compression of RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), UDP/IP, IP and ESP/IP (Encapsulating Security Payload) headers. Additional profiles for compression of IP headers [RFC3843] and UDP-Lite (User Datagram Protocol Lite) headers [RFC4019] were later specified to complete the initial set of ROHC profiles. This document defines an updated version for each of the above mentioned profiles, and its definition is based on the specification of the ROHC framework as found in [RFC4995]. Specifically, this document defines header compression schemes for: o RTP/UDP/IP : profile 0x0101 o UDP/IP : profile 0x0102 o ESP/IP : profile 0x0103 o IP : profile 0x0104 o RTP/UDP-Lite/IP : profile 0x0107 o UDP-Lite/IP : profile 0x0108 ROHCv2 compresses the following type of extension headers: o AH [RFC4302] o GRE [RFC2784][RFC2890] o MINE [RFC2004] o NULL-encrypted ESP [RFC4303] o IPv6 Destination Options header[RFC2460] o IPv6 Hop-by-hop Options header[RFC2460] o IPv6 Routing header [RFC2460]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document is consistent with the terminology found in the ROHC framework [RFC4995] and in the formal notation for ROHC [RFC4997]. In addition, this document uses or defines the following terms: Acknowledgment Number Pelletier & Sandlund Expires April 4, 2008 [Page 4] Internet-Draft ROHCv2 Profiles October 2007 The Acknowledgment Number identifies what packet is being acknowledged in the RoHCv2 feedback element. The value of this field normally corresponds to the Master Sequence Number (MSN) of the header that was last successfully decompressed, for the compression context (CID) for which the feedback information applies. Chaining of Items A chain of items groups fields based on similar characteristics. ROHCv2 defines chain items for static, dynamic and irregular fields. Chaining is achieved by appending to the chain an item for e.g. each header in their order of appearance in the uncompressed packet. Chaining is useful to construct compressed headers from an arbitrary number of any of the protocol headers for which a ROHCv2 profile defines a compressed format. CRC-3 Control Validation The CRC-3 control validation refers to the validation of the control fields when receiving a CO header that contains a 3-bit CRC calculated over the control fields that it carries and over specific control fields in the context. In the formal definition of the header formats, the 3-bit CRC is labelled "control_crc3" and uses the "control_crc3_encoding" (See also Section 6.6.11). Delta The delta refers to the difference in the absolute value of a field between two consecutive packets being processed by the same compression endpoint. Reordering Depth The number of packets by which a packet is received late within its sequence due to reordering between the compressor and the decompressor, i.e. reordering between packets associated with the same context (CID). See definition of sequentially late packet below. ROHCv2 Packet Types ROHCv2 profiles use two different packet types: the Initialization and Refresh (IR) packet type, and the Compressed (CO) packet type. Sequentially Early Packet Pelletier & Sandlund Expires April 4, 2008 [Page 5] Internet-Draft ROHCv2 Profiles October 2007 A packet that reaches the decompressor before one or several packets that were delayed over the channel, whereas all of the said packets belong to the same header-compressed flow and are associated to the same compression context (CID). At the time of the arrival of a sequentially early packet, the packet(s) delayed on the link cannot be differentiated from lost packet(s). Sequentially Late Packet A packet is late within its sequence if it reaches the decompressor after one or several other packets belonging to the same CID have been received, although the sequentially late packet was sent from the compressor before the other packet(s). How the decompressor detects a sequentially late packet is outside the scope of this specification, but it can for example use the MSN to this purpose. Timestamp Stride (ts_stride) The timestamp stride (ts_stride) is the expected increase in the timestamp value between two RTP packets with consecutive sequence numbers. For example, for a media encoding with a sample rate of 8 kHz producing one frame every 20ms, the RTP timestamp will typically increase by n * 160 (= 8000 * 0.02), for some integer n. Time Stride (time_stride) The time stride (time_stride) is the time interval equivalent to one ts_stride, e.g., 20 ms in the example for the RTP timestamp increment above. 3. Acronyms This section lists most acronyms used for reference, in addition to those defined in [RFC4995]. Pelletier & Sandlund Expires April 4, 2008 [Page 6] Internet-Draft ROHCv2 Profiles October 2007 AH Authentication Header. ESP Encapsulating Security Payload. GRE Generic Routing Encapsulation. FC Full Context state (decompressor). IP Internet Protocol. LSB Least Significant Bits. MINE Minimal Encapsulation in IP. MSB Most Significant Bits. MSN Master Sequence Number. NC No Context state (decompressor). OA Optimistic Approach. RC Repair Context state (decompressor). ROHC Header compression framework (RFC4995). ROHCv2 Set of header compression profiles defined in this document. RTP Real-time Transport Protocol. SSRC Synchronization source. Field in RTP header. CSRC Contributing source. Optional list of CSRCs in RTP header. TC Traffic Class. Octet in IPv6 header. See also TOS. TOS Type Of Service. Octet in IPv4 header. See also TC. TS RTP Timestamp. UDP User Datagram Protocol. UDP-Lite User Datagram Protocol Lite. 4. Background (Informative) This section provides background information on the compression profiles defined in this document. The fundamentals of general header compression and of the ROHC framework may be found in section 3 and 4 of [RFC4995], respectively. The fundamentals of the formal notation for ROHC are defined in [RFC4997]. [RFC4224] describes the impacts of out-of-order delivery on profiles based on [RFC3095]. 4.1. Classification of header fields Section 3.1 of [RFC4995] explains that header compression is possible due to the fact that there is much redundancy between field values within the headers of a packet, but especially between the headers of consecutive packets. Appendix A lists and classifies in detail all the header fields relevant to this document. The appendix concludes with recommendations on how the various fields should be handled by header compression algorithms. The main conclusion is that most of the header fields can easily be compressed away since they never or seldom change. A small number of fields however need more sophisticated mechanisms. Pelletier & Sandlund Expires April 4, 2008 [Page 7] Internet-Draft ROHCv2 Profiles October 2007 These fields are: - IPv4 Identification (16 bits) - IP-ID - ESP Sequence Number (32 bits) - ESP SN - UDP Checksum (16 bits) - Checksum - UDP-Lite Checksum (16 bits) - Checksum - UDP-Lite Checksum Coverage (16 bits) - CCov - RTP Marker ( 1 bit ) - M-bit - RTP Sequence Number (16 bits) - RTP SN - RTP Timestamp (32 bits) - TS In particular, for RTP, the analysis in Appendix A reveals that the values of the RTP Timestamp (TS) field usually have a strong correlation to the RTP Sequence Number (SN), which increments by one for each packet emitted by an RTP source. The RTP M-bit is expected to have the same value most of the time, but it needs to be communicated explicitly on occasion. For UDP, the Checksum field cannot be inferred or recalculated at the receiving end without violating its end-to-end properties, and is thus sent as-is when enabled (mandatory with IPv6). The same applies to the UDP-Lite Checksum (mandatory with both IPv4 and IPv6), while the UDP-Lite Checksum Coverage may in some cases be compressible. For IPv4, a similar correlation as the one of the RTP TS to the RTP SN is often observed between the Identifier field (IP-ID) and the master sequence number used for compression (e.g. the RTP SN when compressing RTP headers). 4.2. Improvements of ROHCv2 over RFC3095 profiles The ROHCv2 profiles can achieve compression efficiency and robustness that are both at least equivalent to RFC3095 profiles, when used under the same operating conditions. In particular, the size and bit layout of the smallest compressed header (i.e. PT-0 format U/O-0 in RFC3095, and pt_0_crc3 in ROHCv2) are identical. There are a number of differences and improvements between profiles defined in this document and their earlier version defined in RFC3095 [RFC3095]. This section provides an overview of some of the most significant improvements: Tolerance to reordering Pelletier & Sandlund Expires April 4, 2008 [Page 8] Internet-Draft ROHCv2 Profiles October 2007 Profiles defined in RFC3095 require that the channel between compressor and decompressor provide in-order delivery between compression endpoints. ROHCv2 profiles, however, can handle robustly and efficiently a limited amount of reordering before and after the compression point as part of the compression algorithm itself. Operational logic Profiles in RFC3095 define multiple operational modes, each with different updating logic and compressed header formats. ROHCv2 profiles operate in unidirectional operation until feedback is first received for a context (CID), at which point bidirectional is used; the formats are independent of what operational logic is used. IP extension header Profiles in RFC3095 compressed IP Extension headers using list compression. ROHCv2 profiles instead treat extension headers in the same manner as other protocol headers, i.e. using the chaining mechanism; it thus assumes that extension header are not added or removed during the lifetime of a context (CID), otherwise compression has to be restarted for this flow. IP encapsulation Profiles in RFC3095 can compress at most two levels of IP headers. ROHCv2 profiles can compress an arbitrary number of IP headers. List compression ROHCv2 profiles does not support reference-based list compression. Robustness and repairs ROHCv2 profiles do not define a format for the IR-DYN packet; instead, each profile defines a compressed header that can be used to perform a more robust context repair using a 7-bit CRC verification. This also implies that only the IR header can change the association between a CID and the profile it uses. Feedback Pelletier & Sandlund Expires April 4, 2008 [Page 9] Internet-Draft ROHCv2 Profiles October 2007 ROHCv2 profiles define a CRC in the format of the FEEDBACK-2, and different feedback options are available. 4.3. Operational Characteristics of ROHCv2 Profiles Robust header compression can be used over many type of link technologies. Section 4.4 of [RFC4995] lists the operational characteristics of the ROHC channel. The ROHCv2 profiles address a wide range of applications, and this section summarizes some of the operational characteristics that are specific to these profiles. Packet length ROHCv2 profiles assume that the lower layer indicates the length of a compressed packet. ROHCv2 compressed headers do not contain length information for the payload. Out-of-order delivery between compression endpoints The definition of the ROHCv2 profiles places no strict requirement on the delivery sequence between the compression endpoints, i.e. packets may be received in a different order than the compressor sent them and still have a fair probability to be successfully decompressed. However, frequent out-of-order delivery and/or significant reordering depth will negatively impact the compression efficiency. More specifically, if the compressor can operate using a proper estimate of the reordering characteristics of the path between the compression endpoints, larger headers can be sent more often to increase the robustness against decompression failures due to out-of-order delivery. Otherwise, the compression efficiency will be impaired from an increase in the frequency of decompression failures and recovery attempts. 5. Overview of the ROHCv2 Profiles (Informative) This section provides an overview of concepts that are important and useful to the ROHCv2 profiles. These concepts may be used as guidelines for implementations but they are not part of the normative definition of the profiles, as these concepts relates to the compression efficiency of the protocol without impacting the interoperability characteristics of an implementation. Pelletier & Sandlund Expires April 4, 2008 [Page 10] Internet-Draft ROHCv2 Profiles October 2007 5.1. Compressor Concepts Header compression can be conceptually characterized as the interaction of a compressor with a decompressor state machine, one per context. The responsibility of the compressor is to convey the information needed to successfully decompress a packet, based on a certain confidence regarding the state of the decompressor context. This confidence is obtained from the frequency and the type of information the compressor sends when updating the decompressor context, from the optimistic approach (Section 5.1.1) and optionally from feedback messages received from the decompressor. 5.1.1. Optimistic Approach A compressor always uses the optimistic approach when it performs context updates. The compressor normally repeats the same type of update until it is fairly confident that the decompressor has successfully received the information. If the decompressor successfully receives any of the headers containing this update, state will be available for the decompressor to process smaller compressed headers. If field X in the uncompressed header changes value, the compressor uses a packet type that contains an encoding of field X until it has gained confidence that the decompressor has received at least one packet containing the new value for X. The compressor normally selects a compressed format with the smallest header that can convey the changes needed to achieve confidence. The number of repetitions that is needed to obtain this confidence is normally related to the packet loss and out-of-order delivery characteristics of the link where header compression is used; it is thus not defined in this document and is left open to implementations. 5.1.2. Tradeoff between robustness to losses and to reordering The ability of a header compression algorithm to handle sequentially late packets is mainly limited by two factors: the interpretation interval offset of the sliding window used for LSB encoded fields [RFC4997], and the optimistic approach (See Section 5.1.1) for seldom changing fields. LSB encoded fields: Pelletier & Sandlund Expires April 4, 2008 [Page 11] Internet-Draft ROHCv2 Profiles October 2007 The interpretation interval offset specifies an upper limit for the maximum reordering depth, by which is it possible for the decompressor to recover the original value of a dynamically changing (i.e. sequentially incrementing) field that is encoded using W-LSB. Its value is bound to the number of LSB compressed bits in the compressed header format, and grows with the number of bits transmitted. However, the offset and the LSB encoding only provide robustness for the field that it compresses, and (implicitly) for other sequentially changing fields that are derived from that field. This is shown in the figure below: <--- interpretation interval (size is 2^k) ----> |------------------+---------------------------| v_ref-p v_ref v_ref + (2^k-1) - p Lower Upper Bound Bound <--- reordering --> <--------- losses ---------> where p is the maximum negative delta, corresponding to the maximum reordering depth for which the lsb encoding can recover the original value of the field; where (2^k-1) - p is the maximum positive delta, corresponding to the maximum number of consecutive losses for which the lsb encoding can recover the original value of the field where v_ref is the reference value, as defined in the lsb encoding method in [RFC4997]. There is thus a tradeoff between the robustness against reordering and the robustness against packet losses, with respect to the number of MSN bits needed and the distribution of the interpretation interval between negative and positive deltas in the MSN. Seldom changing fields The optimistic approach (Section 5.1.1) provides the upper limit for the maximum reordering depth for seldom changing fields. There is thus a tradeoff between compression efficiency and robustness. When only information on the MSN needs to be conveyed to the decompressor, the tradeoff relates to the number of compressed MSN bits in the compressed header format. Otherwise, the tradeoff Pelletier & Sandlund Expires April 4, 2008 [Page 12] Internet-Draft ROHCv2 Profiles October 2007 relates to the implementation of the optimistic approach. In particular, compressor implementations should adjust their optimistic approach strategy to match both packet loss and reordering characteristics. For example, the number of repetitions for each update of a non-LSB encoded field can be increased. The compressor can ensure that each update is repeated until it is reasonably confident that at least one packet containing the change has reached the decompressor before the first packet sent after this sequence. 5.1.3. Interactions with the Decompressor Context The compressor normally starts compression with the initial assumption that the decompressor has no useful information to process the new flow, and sends Initialization and Refresh (IR) packets. Initially, when sending the first IR packet for a compressed flow, the compressor does not expect to receive feedback for that flow, until such feedback is first received. At this point, the compressor may then assume that the decompressor will continue to send feedback in order to repair its context when necessary. The former is referred to as unidirectional operation, while the latter is called bidirectional operation. The compressor can then adjust the compression level (i.e. what header format it selects) based on its confidence that the decompressor has the necessary information to successfully process the compressed headers that it selects. In other words, the responsibility of the compressor is to ensure that the decompressor operates with state information that is sufficient to allow decompression of the most efficient compressed header(s), and to allow the decompressor to successfully recover that state information as soon as possible otherwise. The compressor thus has the entire responsibility to ensure that the decompressor has the proper information to decompress the type of compressed header that it sends. In other words, the choice of compressed header depends on the following factors: o the outcome of the encoding method applied to each field; o the optimistic approach, with respect to the characteristics of the channel; o the type of operation (unidirectional or bidirectional), and if in birectional operation, feedback received from the decompressor (ACKs, NACKs, STATIC-NACK, and options). Encoding methods normally use previous value(s) from a history of packets whose headers it has previously compressed. The optimistic Pelletier & Sandlund Expires April 4, 2008 [Page 13] Internet-Draft ROHCv2 Profiles October 2007 approach is meant to ensure that at least one compressed header containing the information to update the state for a field is received. Finally, feedback indicates what actions the decompressor has taken with respect to its assumptions regarding the validity of its context (Section 5.2.2); it indicates what type of compressed header the decompressor can or cannot decompress. The decompressor has the means to detect decompression failures for any type of compressed (CO) header, using the CRC verification. Depending on the frequency and/or on the type of the failure, it might send a negative acknowledgement (NACK) or an explicit request for a complete context update (STATIC-NACK). However, the decompressor does not have the means to identify the cause of the failure, and in particular decompression of what field(s) is responsible for the failure. The compressor is thus always responsible to determine what is the most suitable response to a negative acknowledgement, using the confidence it has in the state of the decompressor context, when selecting the type of compressed header it will use when compressing a header. 5.2. Decompressor Concepts The decompressor normally uses the last received and successfully validated (IR packets) or verified (CO packets) header as the reference for future decompression. If the received packet is older than the current reference packet based on the MSN in the compressed header, the decompressor may refrain from using this packet as the new reference packet, even if the correctness of its header was successfully verified. The decompressor is responsible to always verify the outcome of the decompression attempt, to update its context when successful and finally to request context repairs by making coherent usage of feedback, once it has started using feedback. Specifically, the outcome of every decompression attempt is verified using the CRC present in the compressed header; the decompressor updates the context information when this outcome is successfully verified; finally if the decompressor uses feedback once for a compressed flow then it will continue to do so for as long as the corresponding context is associated with the same profile. 5.2.1. Decompressor State Machine The decompressor operation may be represented as a state machine defining three states: No Context (NC), Repair Context (RC) and Full Context (FC). Pelletier & Sandlund Expires April 4, 2008 [Page 14] Internet-Draft ROHCv2 Profiles October 2007 The decompressor starts without a valid context, the NC state. Upon receiving an IR packet, the decompressor validates the integrity of its header using the CRC-8 validation. If the IR header is successfully validated, the decompressor updates the context and uses this header as the reference header, and moves to the FC state. The decompressor state machine normally does not leave the FC state once it has entered this state; only repeated decompression failures will force the decompressor to transit downwards to a lower state. When context damage is detected, the decompressor moves to the repair context (RC) state, where it stays until it successfully verifies a decompression attempt for a compressed header with a 7-bit CRC or for an IR header. When static context damage is detected, the decompressor moves back to the NC state. Below is the state machine for the decompressor. Details of the transitions between states and decompression logic are given in the sub-sections following the figure. CRC-8(IR) Validation +----->----->----->----->----->----->----->----->----->----->----+ | CRC-8(IR) | | !CRC-8(IR) or CRC-7(CO) or or CRC-7(CO) | | PT not allowed CRC-8(IR) or CRC-3(CO) | | +--->---+ +--->----->----->----->---+ +--->---->---+ | | | | | | | | | | | v | v | v v +-----------------+ +----------------------+ +--------------------+ | No Context (NC) | | Repair Context (RC) | | Full Context (FC) | +-----------------+ +----------------------+ +--------------------+ ^ ^ Static Context | ^ !CRC-7(CO) or | ^ Context Damage | | | | Damage Detected | | PT not allowed | | Detected | | | +--<-----<-----<--+ +----<------<----+ +--<-----<-----<--+ | | | | Static Context Damage Detected | +--<-----<-----<-----<-----<-----<-----<-----<-----<---------+ where: CRC-8(IR): successful CRC-8 validation for the IR header. !CRC-8(IR): Unsuccessful CRC-8 validation for the IR header. CRC-7(CO) and/or CRC-3(CO): successful CRC verification for the decompression of a CO header, based on the number of CRC bits carried in the CO header. !CRC-7(CO): failure to CRC verify the decompression of a CO header carrying a 7-bit CRC. Pelletier & Sandlund Expires April 4, 2008 [Page 15] Internet-Draft ROHCv2 Profiles October 2007 PT not allowed: the decompressor has received a packet type (PT) for which the decompressor's current context does not provide enough valid state information for that packet to be decompressed. Static Context Damaged Detected: see definition in Section 5.2.2. Context Damage Detected: see definition in Section 5.2.2. 5.2.1.1. No Context (NC) State Initially, while working in the No Context (NC) state, the decompressor has not yet successfully validated an IR header. Attempting decompression: In the NC state, only packets carrying sufficient information on the static fields (i.e. IR packets) can be decompressed. Upward transition: The decompressor can move to the Full Context (FC) state when the CRC validation of an 8-bit CRC in an IR header is successful. Feedback logic: In the No Context state, the decompressor should send a STATIC- NACK if a packet of a type other than IR is received, or if an IR header has failed the CRC-8 validation, subject to the feedback rate limitation as described in Section 5.2.3. 5.2.1.2. Repair Context (RC) State In the Repair Context (RC) state, the decompressor has successfully decompressed packets for this context, but does not have confidence that the entire context is valid. Attempting decompression: In the RC state, only headers covered by an 8-bit CRC (i.e. IR) or CO headers carrying a 7-bit CRC can be decompressed. Upward transition: The decompressor can move to the Full Context (FC) state when the CRC verification succeeds for a CO header carrying a 7-bit CRC or validation of an 8-bit CRC in an IR header. Downward transition: Pelletier & Sandlund Expires April 4, 2008 [Page 16] Internet-Draft ROHCv2 Profiles October 2007 The decompressor moves back to the NC state if it assumes static context damage. Feedback logic: In the RC state, the decompressor should send a STATIC-NACK when CRC-8 validation of an IR fails, or when a CO header carrying a 7-bit CRC fails and static context damage is assumed, subject to the feedback rate limitation as described in Section 5.2.3. If any other packet type is received, the decompressor should treat it as a CRC verification failure when deciding if a NACK is to be sent. 5.2.1.3. Full Context (FC) State In the Full Context (FC) state, the decompressor assumes that its entire context is valid. Attempting decompression: In the FC state, decompression can be attempted regardless of the type of packet received. Downward transition: The decompressor moves back to the RC state if it assumes context damage. If the decompressor assumes static context damage, it moves directly to the NC state. Feedback logic: In the FC state, the decompressor should send a NACK when CRC-8 validation or CRC verification of any header type fails and if context damage is assumed, or STATIC-NACK if static context damage is assumed, subject to the feedback rate limitation as described in Section 5.2.3. 5.2.2. Decompressor Context Management All header formats carry a CRC and are context updating. A packet for which the CRC succeeds updates the reference values of all header fields, either explicitly (from the information about a field carried within the compressed header) or implicitly (fields that are inferred from other fields). The decompressor may assume that some or the entire context is invalid, when it fails to validate or to verify one or more headers using the CRC. Because the decompressor cannot know the exact Pelletier & Sandlund Expires April 4, 2008 [Page 17] Internet-Draft ROHCv2 Profiles October 2007 reason(s) for a CRC failure or what field caused it, the validity of the context hence does not refer to what specific part(s) of the context is deemed valid or not. Validity of the context rather relates to the detection of a problem with the context. The decompressor first assume that the type of information that most likely caused the failure(s) is the state that normally changes for each packet, i.e. context damage of the dynamic part of the context. Upon repeated decompression failures and unsuccessful repairs, the decompressor then assumes that the entire context, including the static part, needs to be repaired, i.e. static context damage. Failure to validate the 3-bit CRC that protects control fields should be treated as a decompression failure when the decompressor asserts the validity of its context. Context Damage Detection The assumption of context damage means that the decompressor will not attempt decompression of a CO header that carries only a 3-bit CRC, and will only attempt decompression of IR headers, or CO headers protected by a CRC-7. Static Context Damage Detection The assumption of static context damage means that the decompressor refrains from attempting decompression of any type of header other than the IR header. How these assumptions are made, i.e. how context damage is detected, is open to implementations. It can be based on the residual error rate, where a low error rate makes the decompressor assume damage more often than on a high rate link. The decompressor implements these assumptions by selecting the type of compressed header for which it will attempt decompression. In other words, validity of the context refers to the ability of a decompressor to attempt or not decompression of specific packet types. When ROHCv2 profiles are used over a channel that cannot guarantee in-order delivery, the decompressor may refrain from updating its context with the content of a sequentially late packet that is successfully decompressed. This is to avoid updating the context with information that is older than what the decompressor already has in its context. Pelletier & Sandlund Expires April 4, 2008 [Page 18] Internet-Draft ROHCv2 Profiles October 2007 5.2.3. Feedback logic ROHCv2 profiles may be used in environments with or without feedback capabilities from decompressor to compressor. ROHCv2 however assumes that if a ROHC feedback channel is available and if this channel is used at least once by the decompressor for a specific context, this channel will be used during the entire compression operation for that context (i.e. bidirectional operation). The ROHC framework defines 3 types of feedback messages: ACKs, NACKs and STATIC-NACKs. The semantics of each message if defined in section 5.2.3.1. of [RFC4995]. What feedback to send is coupled to the context management of the decompressor, i.e. to the implementation of the context damage detection algorithms as described in Section 5.2.2. The decompressor should send a NACK when it assumes context damage, and it should send a STATIC-NACK when it assumes static context damage. The decompressor is not strictly expected to send ACK feedback upon successful decompression, other than for the purpose of improving compression efficiency. When ROHCv2 profiles are used over a channel that cannot guarantee in-order delivery, the decompressor may refrain to send ACK feedback for a sequentially late packet that is successfully decompressed. The decompressor should limit the rate at which it sends feedback, for both ACKs and STATIC-NACK/NACKs, and should avoid sending unnecessary duplicates of the same type of feedback message that may be associated to the same event. 6. ROHCv2 Profiles (Normative) 6.1. Channel Parameters, Segmentation and Reordering The compressor MUST NOT use ROHC segmentation (see [RFC4995] section 5.2.5), i.e. MRRU MUST be set to 0), if the configuration of the ROHC channel contains at least one ROHCv2 profile in the list of supported profiles (i.e. the PROFILES parameter) and if the channel cannot guarantee in-order delivery of packets between compression endpoints. 6.2. Profile Operation, per-context ROHCv2 profiles operate differently, per context, depending on how the decompressor makes use of the feedback channel, if any. Once the decompressor uses the feedback channel for a context, it establishes Pelletier & Sandlund Expires April 4, 2008 [Page 19] Internet-Draft ROHCv2 Profiles October 2007 the feedback channel for that CID. The compressor always start assuming that the decompressor will not send feedback when it initializes a new context (see also the definition of a new context insection 5.1.1. of [RFC4995]), i.e. there is no established feedback channel for the new context. There will always be a possibility of decompression failure with the optimistic approach, because the decompressor may not have received sufficient information for correct decompression. Therefore, until the decompressor has established a feedback channel, the compressor SHOULD periodically send IR packets. The periodicity can be based on timeouts, on the number of compressed packets sent for the flow, or any other strategy the implementer chooses. The reception of either positive feedback (ACKs) or negative feedback (NACKs or STATIC-NACKs) establishes the feedback channel from the decompressor for the context (CID) for which the feedback was received. Once there is an established feedback channel for a specific context, the compressor can make use of this feedback to estimate the current state of the decompressor. This helps increasing the compression efficiency by providing the information needed for the compressor to achieve the necessary confidence level. When the feedback channel is established, it becomes superfluous for the compressor to send periodic refreshes, and instead it can rely entirely on the optimistic approach and feedback from the decompressor. The decompressor MAY send positive feedback (ACKs) to initially establish the feedback channel for a particular flow. Either positive feedback (ACKs) or negative feedback (NACKs) establishes this channel. The decompressor is REQUIRED to continue sending feedback once it has established a feedback channel for a CID, for the lifetime of the context, i.e. until the CID is associated with a different profile from the reception of an IR packet, to send error recovery requests and (optionally) acknowledgments of significant context updates. Compression without an established feedback channel will be less efficient, because of the periodic refreshes and from the lack of feedback for initiation of error recovery; there will also be a slightly higher probability of loss propagation compared to the case where the decompressor uses feedback. 6.3. Control Fields ROHCv2 defines a number of control fields that are used by the decompressor in its interpretation of the packet formats received from the compressor. The control fields listed in the following Pelletier & Sandlund Expires April 4, 2008 [Page 20] Internet-Draft ROHCv2 Profiles October 2007 subsections are all defined in Section 6.8.2.4 using ROHC-FN [RFC4995]. 6.3.1. Master Sequence Number (MSN) The Master Sequence Number (MSN) field is either taken from a field that already exists in each of the headers of the protocol that the profile compresses (e.g. RTP SN), or alternatively it is created at the compressor. There is one MSN space per context (CID). The MSN field has the following two functions: o Differentiating between reference headers when receiving feedback data. o Inferring the value of incrementing fields (e.g. IPv4 Identifier). The MSN field is present in every ROHCv2 header sent by the compressor. The MSN is sent in full in IR packets, while it can be sent LSB encoded within CO header formats. The decompressor always includes LSBs of the MSN in the Acknowledgment Number field in feedback (see Section 6.9). The compressor can later use this field to infer what packet the decompressor is acknowledging. For profiles for which the MSN is created by the compressor, the following applies: o The compressor should only initialize a new MSN for the initial IR sent for a CID that corresponds to a context that is not already associated with this profile; o When the MSN is initialized, it is initialized to a random value; o The value of the MSN is incremented by one for each packet that the compressor sends for a specific CID. 6.3.2. Reordering Ratio The control field reorder_ratio specifies how much reordering is handled by the LSB encoding of the MSN. This is useful when header compression is performed over links with varying reordering characteristics. The reorder_ratio control field is a means for the compressor to adjust the robustness characteristics of the LSB encoding method with respect to reordering and consecutive losses, as described in Section 5.1.2. 6.3.3. IP-ID behavior The IP-ID field of the IPv4 header can have different change patterns: sequential in network byte order, sequential byte-swapped, Pelletier & Sandlund Expires April 4, 2008 [Page 21] Internet-Draft ROHCv2 Profiles October 2007 random or constant (a constant value of zero, although not conformant with [RFC0791], has been observed in practice). There is one IP-ID behavior control field per IP header. The control field for the IP-ID behavior of the innermost IP header determines which set of header formats will be used. The IP-ID behavior control field is also used to determine the contents of the irregular chain item, for each IP header. ROHCv2 profiles can assign a sequential behavior (network byte order or byte-swapped) only to the IP-ID of innermost IP header, when compressing more than one level of IP headers. This is because only the IP-ID of the innermost IP header is likely to have a sufficiently close correlation with the MSN to compress it as a sequentially changing field. Therefore, a compressor MUST assign either the constant zero IP-ID or the random IP-ID behavior to tunneling headers. 6.3.4. UDP-Lite Coverage Behavior The control field coverage_behavior specifies how the checksum coverage field of the UDP-Lite header is compressed with RoHCv2. It can indicate one of he following encoding methods: irregular, static or inferred compression. 6.3.5. Timestamp Stride The ts_stride control field is used in scaled RTP timestamp encoding (see Section 6.6.8). It defines the expected increase in the RTP timestamp between consecutive RTP sequence numbers. 6.3.6. Time Stride The time_stride control field is used in timer-based compression encoding (see Section 6.6.9). When timer-based compression is used, time_stride should be set to the expected difference in arrival time between consecutive RTP packets. 6.3.7. CRC-3 for Control Fields ROHCv2 profiles define a CRC-3 calculated over a number of control fields. This 3-bit CRC protecting the control fields is present in the header format for the co_common and co_repair header types. Failure to validate the control fields using this CRC should be considered as a decompression failure by the decompressor, in the algorithm that assesses the validity of the context. However, if the decompression attempt can be verified using either the CRC-3 or the CRC-7 calculated over the uncompressed header, the decompressor may Pelletier & Sandlund Expires April 4, 2008 [Page 22] Internet-Draft ROHCv2 Profiles October 2007 still forward the decompressed header to upper layers. This is because the protected control fields are not always used for decompression of the specific co_common or the co_repair header that updates their respective value. The CRC polynomial and coverage of this CRC-3 is defined in Section 6.6.11. 6.4. Reconstruction and Verification Validation of the IR header (8-bit CRC) The decompressor MUST always validate the integrity of the IR header using the 8-bit CRC carried within the IR header. When the header is validated, the decompressor updates the context with the information in the IR header. Otherwise, if the IR cannot be validated, the context MUST NOT be updated and the IR header MUST NOT be delivered to upper layers. Verification of CO headers (3-bit CRC or 7-bit CRC) The CRC carried within compressed headers MUST be used to verify decompression of CO headers. When the decompression is verified and successful, the decompressor updates the context with the information received in the CO header; otherwise if the reconstructed header fails the CRC verification, these updates MUST NOT be performed. A packet for which the decompression attempt cannot be verified using the CRC MUST NOT be delivered to upper layers. Decompressor implementations may attempt corrective or repair measures on CO headers prior to performing the above actions, and the result of any decompression attempt MUST be verified using the CRC. 6.5. Compressed Header Chains Some packet types use one or more chains containing sub-header information. The function of a chain is to group fields based on similar characteristics, such as static, dynamic or irregular fields. Chaining is done by appending an item for each header to the chain in their order of appearance in the uncompressed packet, starting from the fields in the outermost header. Static chain: Pelletier & Sandlund Expires April 4, 2008 [Page 23] Internet-Draft ROHCv2 Profiles October 2007 The static chain consists of one item for each header of the chain of protocol headers to be compressed, starting from the outermost IP header. In the formal description of the packet formats, this static chain item for each header type is labelled _static. The static chain is only used in the IR header format. Dynamic chain: The dynamic chain consists of one item for each header of the chain of protocol headers to be compressed, starting from the outermost IP header. In the formal description of the packet formats, the dynamic chain item for each header type is labelled _dynamic. The dynamic chain is only used in the IR header format. Irregular chain: The structure of the irregular chain is analogous to the structure of the static chain. For each compressed packet, the irregular chain is appended at the specified location in the general format of the compressed packets as defined in Section 6.8. The irregular chain is used in all CO packets. The format of the irregular chain for the innermost IP header differs from the format used for the outer IP headers, because this header is part of the compressed base header. In the definition of the packet formats using the formal notation, the argument "is_innermost" passed to the corresponding encoding method (ipv4 or ipv6) determines what irregular chain items to use. The format of the irregular chain item for the outer IP headers is also determined using one flag for TTL/Hop Limit and one for TOS/TC. These flags are defined in the format of some of the compressed base headers. ROHCv2 profiles compresses extension headers as other headers, and thus extension headers have a static chain, a dynamic chain and an irregular chain. ROHCv2 profiles define chains for all headers that can be compressed, i.e. RTP [RFC3550], UDP [RFC0768], UDP Lite [RFC3828], IPv4 [RFC0791], IPv6 [RFC2460], AH [RFC4302], GRE [RFC2784][RFC2890], MINE [RFC2004], NULL-encrypted ESP [RFC4303], IPv6 Destination Options header[RFC2460], IPv6 Hop-by-hop Options header[RFC2460] and IPv6 Routing header [RFC2460]. Pelletier & Sandlund Expires April 4, 2008 [Page 24] Internet-Draft ROHCv2 Profiles October 2007 6.6. Packet Formats and Encoding Methods The packet formats are defined using the ROHC formal notation. Some of the encoding methods used in the packet formats are defined in [RFC4997], while other methods are defined in this section. 6.6.1. baseheader_extension_headers The baseheader_extension_headers encoding method skips over all fields of the extension headers of the innermost IP header, without encoding any of the them. Fields in these extension headers are instead encoded in the irregular chain. This encoding is used in CO headers (see Section 6.8.2). The innermost IP header is combined with other header(s) (i.e. UDP, UDP Lite, RTP) to create the compressed base header. In this case, there may be a number of extension headers between the IP headers and the other headers. The base header defines a representation of the extension headers, to comply with the syntax of the formal notation; this encoding method provides this representation. 6.6.2. baseheader_outer_headers The baseheader_outer_headers encoding method skips over all the fields of the extension header(s) that do not belong to the innermost IP header, without encoding any of them. Changing fields in outer headers are instead handled by the irregular chain. This encoding method, similarly to the baseheader_extension_headers encoding method above, is necessary to keep the definition of the packet formats syntactically correct. It describes tunneling IP headers and their respective extension headers (i.e. all headers located before the innermost IP header) for CO headers (see Section 6.8.2). 6.6.3. inferred_udp_length The decompressor infers the value of the UDP length field as being the size of the UDP payload. The compressor must therefore ensure that the UDP length field is consistent with the length field(s) of preceeding subheaders, i.e., there must not be any padding after the UDP payload that is covered by the IP Length. This encoding method is also used for the UDP-Lite Checksum Coverage field, when it behaves in the same manner as the UDP length field (i.e. when the checksum always covers the entire UDP-Lite payload). Pelletier & Sandlund Expires April 4, 2008 [Page 25] Internet-Draft ROHCv2 Profiles October 2007 6.6.4. inferred_ip_v4_header_checksum This encoding method compresses the header checksum field of the IPv4 header. This checksum is defined in RFC 791 [RFC0791] as follows: Header Checksum: 16 bits A checksum on the header only. Since some header fields change (e.g., time to live), this is recomputed and verified at each point that the internet header is processed. The checksum algorithm is: The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero. As described above, the header checksum protects individual hops from processing a corrupted header. There is no reason to transmit this checksum when almost all IP header information is compressed away, and when decompression is verified by a CRC computed over the original header for every compressed packet; instead, the checksum can be recomputed by the decompressor. The "inferred_ip_v4_header_checksum" encoding method thus compresses the header checksum field of the IPv4 header down to a size of zero bits, i.e. no bits are transmitted in compressed headers for this field. Using this encoding method, the decompressor infers the value of this field using the computation above. The compressor MAY use the header checksum to validate the correctness of the header before compressing it, to avoid processing a corrupted header. 6.6.5. inferred_mine_header_checksum This encoding method compresses the minimal encapsulation header checksum. This checksum is defined in RFC 2004 [RFC2004] as follows: Header Checksum The 16-bit one's complement of the one's complement sum of all 16-bit words in the minimal forwarding header. For purposes of computing the checksum, the value of the checksum field is 0. The IP header and IP payload (after the minimal forwarding header) are not included in this checksum computation. Pelletier & Sandlund Expires April 4, 2008 [Page 26] Internet-Draft ROHCv2 Profiles October 2007 The "inferred_mine_header_checksum" encoding method compresses the minimal encapsulation header checksum down to a size of zero bits, i.e. no bits are transmitted in compressed headers for this field. Using this encoding method, the decompressor infers the value of this field using the above computation. The motivations for inferring this checksum are similar to the ones explained above in Section 6.6.4. The compressor MAY use the minimal encapsulation header checksum to validate the correctness of the header before compressing it, to avoid processing a corrupted header. 6.6.6. inferred_ip_v4_length This encoding method compresses the total length field of the IPv4 header. The total length field of the IPv4 header is defined in RFC 791 [RFC0791] as follows: Total Length: 16 bits Total Length is the length of the datagram, measured in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets. The "inferred_ip_v4_length" encoding method compresses the IPv4 header checksum down to a size of zero bits, i.e. no bits are transmitted in compressed headers for this field. Using this encoding method, the decompressor infers the value of this field by counting in octets the length of the entire packet after decompression. 6.6.7. inferred_ip_v6_length This encoding method compresses the payload length field in the IPv6 header. This length field is defined in RFC 2460 [RFC2460] as follows: Payload Length: 16-bit unsigned integer Length of the IPv6 payload, i.e., the rest of the packet following this IPv6 header, in octets. (Note that any extension headers present are considered part of the payload, i.e., included in the length count.) The "inferred_ip_v6_length" encoding method compresses the payload length field of the IPv6 header down to a size of zero bits, i.e. no bits are transmitted in compressed headers for this field. Using Pelletier & Sandlund Expires April 4, 2008 [Page 27] Internet-Draft ROHCv2 Profiles October 2007 this encoding method, the decompressor infers the value of this field by counting in octets the length of the entire packet after decompression. 6.6.8. Scaled RTP Timestamp Encoding The RTP timestamp (TS) usually increases by a multiple of the RTP Sequence Number's (SN) increase and is therefore a suitable candidate for scaled encoding. This scaling factor is labeled ts_stride in the definition of the profile in ROHC-FN Section 6.8. The compressor sets the scaling factor based on the change in TS with respect to the change in the RTP SN. As defined in Section 6.8.2.4, the initial value of the scaling factor ts_stride is always set to 160. For the compressor to start using scaled encoding using a value different than this default value, it must first explicitly transmit the new value of ts_stride to the decompressor, using one of the packet types that can carry this information. If the compressor decides to use the default value, the stride does not need to be transmit in this step. Once the value of the scaling factor is established, before using the new scaling factor, the compressor must have enough confidence that the decompressor has successfully calculated the residue (ts_offset) of the scaling function for the timestamp. This is done by sending unscaled timestamp values to allow the decompressor to establish the residue based on the current ts_stride. The compressor MAY send the unscaled timestamp in the same packets as the ones establishing the new ts_stride value. Once the compressor has gained enough confidence that both the value of the scaling factor and the value of the residue have been established in the decompressor, the compressor can start compressing packets using the new scaling factor. If the compressor notices that the residue (ts_offset) value changes, the compressor cannot use scaled timestamp packet formats until it has re-established the residue as described above. If the decompressor receives a packet containing scaled timestamp bits while the ts_stride equals zero, it MUST NOT deliver the packet to upper layers. When the value of the timestamp field wraps around, the value of the residue of the scaling function is likely to change. When this occurs, the compressor re-establishes the new residue value as described above. Pelletier & Sandlund Expires April 4, 2008 [Page 28] Internet-Draft ROHCv2 Profiles October 2007 The compressor MAY use the scaled timestamp encoding; what value it will use as the scaling factor is up to the compressor implementation, but to achive any gains from the scaling, the ts_stride should be set to the value of the expected incease in timestamp between consecutive sequence numbers. When scaled timestamp encoding is used for packet formats that do not transmit any LSB-encoded timestamp bits at all, the inferred_scaled_field encoding of Section 6.6.10 is used for encoding the timestamp. 6.6.9. timer_based_lsb The timer-based compression encoding method, "timer_based_lsb", compresses a field whose change pattern approximates a linear function of the time of day. This encoding uses the local clock to obtain an approximation of the value that it encodes. The approximated value is then used as a reference value together with the num_lsbs_param least-significant bits received as the encoded value, where num_lsbs_param represents a number of bits that is sufficient to uniquely represent the encoded value in the presence of jitter between compression endpoints. The clock resolution of the compressor or decompressor can be less than time_stride; in this case, the difference, i.e., actual resolution - time_stride, is treated as additional jitter in the calculation of the number of LSBs that needs to be transmitted. ts_scaled =:= timer_based_lsb(, , ) The parameters "num_lsbs_param" and "offset_param" are the parameters to use for the lsb encoding, i.e. the number of least significant bits and the interpretation interval offset, respectively. The parameter "time_stride_param" represents the context value of the control field time_stride. This encoding method always uses a scaled version of the field it compresses. The value of the field is decoded by calculating an approximation of the uncompressed value, using: Pelletier & Sandlund Expires April 4, 2008 [Page 29] Internet-Draft ROHCv2 Profiles October 2007 tsc_ref_advanced = tsc_ref + (a_n - a_ref) / time_stride. where: - tsc_ref is a reference value of the scaled representation of the field. - a_n is the arrival time associated to the value to decode. - a_ref is the arrival time associated to the reference header. - tsc_ref_advanced is an approximation of the uncompressed value of the field. The lsb() encoding is then applied using the num_lsbs_param bits received in the CO header and tsc_ref_advanced as "ref_value" (as per Section 4.11.5 of [RFC4997]). Appendix B.3 provides an example on how the compressor can calculate jitter. The control field time_stride controls whether or not the timer_based_lsb method is used in the CO header. The decompressor SHOULD send the CLOCK_RESOLUTION option if it receives a non-zero time_stride value and it has not previously informed the compressor that it supports timer-based compression using the CLOCK_RESOLUTION option with a non-zero value. Whether the CLOCK_RESOLUTION is set to a non-zero value or to a zero value is up to the implementation. The support and usage of timer-based compression is optional for both the compressor and the decompressor; the compressor is never required to set the time_stride control field to a non-zero value when it has received a non-zero value for the CLOCK_RESOLUTION option. 6.6.10. inferred_scaled_field The "inferred_scaled_field" encoding method is used to encode a field that is defined as changing in relation to the MSN but for each increase is scaled by an established scaling factor. This encoding method is to be used in the case when a packet format contains MSN bits, but does not contain any bits for the scaled field. In this case, the new value for the field being scaled is calculated according to the following formula: unscaled_value = delta_msn * stride + reference_unscaled_value Where "delta_msn" is the difference in MSN between the reference value of the MSN in the context and the value of the MSN decompressed from this packet, "reference_unscaled_value" is the value of the field being scaled in the context, and "stride" is the scaling value for this field. Pelletier & Sandlund Expires April 4, 2008 [Page 30] Internet-Draft ROHCv2 Profiles October 2007 For example, when this encoding method is applied to the RTP timestamp in the RTP profile, the calculation above becomes: timestamp = delta_msn * ts_stride + reference_timestamp 6.6.11. control_crc3_encoding The "control_crc3_encoding" method provides a CRC calculated over a number of control fields. The definition of this encoding method is the same as for the "crc" encoding method specified in section 4.11.6 of [RFC4997], with the difference that the data that is covered by the CRC is given by a concatenated list of control fields. In other words, the definition of the control_crc3_encoding method is equivalent to the following definition: control_crc_encoding(data_value, data_length) { UNCOMPRESSED { } COMPRESSED { control_crc3 =:= crc(3, 0x06, 0x07, ctrl_data_value, ctrl_data_length) [ 3 ]; } } where the parameter "ctrl_data_value" binds to the concatenated values of the following control fields, in the order listed below: o reorder_ratio, 2 bits padded by 6 MSB of zeroes o ts_stride, 32 bits (applicable only for profiles 0x0101 and 0x0107) o time_stride, 32 bits (applicable only for profiles 0x0101 and 0x0107) o msn, 16 bits (not applicable for profiles 0x0101 and 0x0107, since the RTP Sequence Number is already verified as part of the uncompressed header) o coverage_behavior, 2 bits padded by 6 MSB of zeroes, applicable only to profiles 0x0107 and 0x0108 o ip_id_behavior, one octet for each IP header in the compressible header chain starting from the outermost header. Each octet consists of 2 bits padded by 6 MSBs of zeroes The "ctrl_data_length" binds to the sum of the length of the control field(s) that are applicable. Pelletier & Sandlund Expires April 4, 2008 [Page 31] Internet-Draft ROHCv2 Profiles October 2007 A 3-bit CRC is used to validate the control fields that are updated by the co_common and co_repair packet types; it cannot verify the outcome of a decompression attempt. The definition of this CRC comes from the fact that the decompression of a header that carries and updates control fields does not necessarily make use of these control fields, and the update to the control fields is thus not protected by the CRC-7 validation. For example, without a verification of the updates to the control fields, there would be a possibility that a decompression attempt succeeds for a co_common or for a co_repair packet for which the decompressor would send a positive feedback, even in the case where one of the control fields had been corrupted on the link between the compression endpoints. 6.6.12. inferred_sequential_ip_id This encoding method is used when a sequential IP-ID behavior is used (sequential or sequential byte-swapped) and no coded IP-ID bits are present in the compressed header. When these packet types are used, the IP-ID offset from the MSN will be constant, and therefore, the IP-ID will increase by the same amount as the MSN increases by (similar to the inferred_scaled_field encoding method). Therefore, the new value for the IP-ID is calculated according to the following formula: IP-ID = delta_msn + reference_IP_ID_value Where "delta_msn" is the difference is MSN between the reference value of MSN in the context and the value of the MSN decompressed from this packet, "previous_IP_ID_value" is the value of the IP-ID in the context. If the IP-ID behavior is random or zero, this encoding method does not update any fields. 6.6.13. list_csrc(cc_value) This encoding method describes how the list of CSRC identifiers can be compressed using list compression. This list compression operates by establishing content for the different CSRC identifiers (items) and list describing the order that they appear. The argument to this encoding method (cc_value) is the value of the CC field from the RTP header which the compressor passes to this encoding method. The decompressor is required to bind the value of this argument to the number of items in the list, which will allow the decompressor to corectly reconstruct the CC field. Pelletier & Sandlund Expires April 4, 2008 [Page 32] Internet-Draft ROHCv2 Profiles October 2007 6.6.13.1. List Compression The CSRC identifiers in the uncompressed packet can be represented as an ordered list, whose order and presence are usually constant between packets. The generic structure of such a list is as follows: +--------+--------+--...--+--------+ list: | item 1 | item 2 | | item n | +--------+--------+--...--+--------+ When performing list compression on a CSRC list, each item is the uncompressed value of one CSRC identifier. The basic principles of list-based compression are the following: 1) When a context is being initialized, a complete representation of the list of CSRC identifiers is transmitted. Then, once the context has been initialized: 2) When the structure of the list is unchanged, no information about the list is sent in compressed headers. 3) When the structure of the list changes, a compressed list is sent in the compressed header, including a representation of its structure and order. Previously unknown items are sent uncompressed in the list, while previously known items are only represented by an index pointing to the context. 6.6.13.2. Table-based Item Compression The Table-based item compression compresses individual items sent in compressed lists. The compressor assigns a unique identifier, "Index", to each item "Item" of a list. Compressor Logic The compressor conceptually maintains an Item Table containing all items, indexed using "Index". The (Index, Item) pair is sent together in compressed lists until the compressor gains enough confidence that the decompressor has observed the mapping between items and their respective index. Confidence is obtained from the reception of an acknowledgment from the decompressor, or by sending (Index, Item) pairs using the optimistic approach. Once confidence is obtained, the index alone is sent in compressed lists to indicate the presence of the item corresponding to this index. Pelletier & Sandlund Expires April 4, 2008 [Page 33] Internet-Draft ROHCv2 Profiles October 2007 The compressor may reset its item table upon receiving negative acknowledgement. The compressor may reassign an existing index to a new item, by re-establishing the mapping using the procedure described above. Decompressor Logic The decompressor conceptually maintains an Item Table that contains all (Index, Item) pairs received. The Item Table is updated whenever an (Index, Item) pair is received and decompression is successfully verified using the CRC. The decompressor retrieves the item from the table whenever an Index without an accompanying Item is received. If an index without an accompanying item is received and the decompressor does not have any context for this index, the packet MUST NOT be delivered to upper layers. 6.6.13.3. Encoding of Compressed Lists Each item present in a compressed list is represented by: o an index into the table of items, and o a presence bit indicating if a compressed representation of the item is present in the list. o an item (if the presence bit is set) If the presence bit is not set, the item must already be known by the decompressor. A compressed list of items uses the following encoding: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | Reserved |PS | m | +---+---+---+---+---+---+---+---+ | XI_1, ..., XI_m | m octets, or m * 4 bits / --- --- --- ---/ | : Padding : if PS = 0 and m is odd +---+---+---+---+---+---+---+---+ | | / item_1, ..., item_n / variable | | +---+---+---+---+---+---+---+---+ Pelletier & Sandlund Expires April 4, 2008 [Page 34] Internet-Draft ROHCv2 Profiles October 2007 Reserved: Must be set to zero. PS: Indicates size of XI fields: PS = 0 indicates 4-bit XI fields; PS = 1 indicates 8-bit XI fields. m: Number of XI item(s) in the compressed list. Also the value of the cc_value argument. XI_1, ..., XI_m: m XI items. Each XI represents one item in the list of item of the uncompressed header, in the same order as they appear in the uncompressed header. The format of an XI item is as follows: +---+---+---+---+ PS = 0: | X | Index | +---+---+---+---+ 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ PS = 1: | X | Reserved | Index | +---+---+---+---+---+---+---+---+ X: Indicates whether the item present in the list: X = 1 indicates that the item corresponding to the Index is sent in the item_1, ..., item_n list; X = 0 indicates that the item corresponding to the Index is not sent. Reserved: Set to zero when sending, ignored when received. Index: An index into the item table. See Section 6.6.13.4 When 4-bit XI items are used and, the XI items are placed in octets in the following manner: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | XI_k | XI_k + 1 | +---+---+---+---+---+---+---+---+ Pelletier & Sandlund Expires April 4, 2008 [Page 35] Internet-Draft ROHCv2 Profiles October 2007 Padding: A 4-bit padding field is present when PS = 0 and the number of XIs is odd. The Padding field is set to zero when sending and ignored when receiving. Item 1, ..., item n: Each item corresponds to an XI with X = 1 in XI 1, ..., XI m. Each entry in the item list is the uncompressed representation of one CSRC identifier. 6.6.13.4. Item Table Mappings The item table for list compression is limited to 16 different items, since the RTP header can only carry at most 15 simultaneous CSRC identifiers. The effect of having more than 16 items will only cause a slight overhead to the compressor when items are swapped in/out of the item table. 6.6.13.5. Compressed Lists in Dynamic Chain A compressed list that is part of the dynamic chain (i.e. in IR packets) must have all its list items present, i.e. all X-bits in the XI list MUST be set. All items previously established in the item table that are not present in the list decompressed from this packet MUST also be retained in the decompressor context. 6.7. Encoding Methods With External Parameters A number of encoding methods in Section 6.8.2.4 have one or more arguments for which the derivation of the parameter's value is outside the scope of the ROHC-FN specification of the header formats. This section lists the encoding methods together with a definition of each of their parameters. o esp_null(next_header_value): next_header_value: Set to the value of the Next Header field located in the ESP trailer, usually 12 octets from the end of the packet. Compression of null-encrypted ESP headers should only be performed when the compressor has prior knowledge of the exact location of the next header field. o ipv6(profile, is_innermost, outer_ip_flag)): profile: Set to the 16-bit profile number of the profile used to compress this packet. Pelletier & Sandlund Expires April 4, 2008 [Page 36] Internet-Draft ROHCv2 Profiles October 2007 is_innermost: This boolean flag is set to 1 when processing the innermost IP header; otherwise it is set to 0. outer_ip_flag: This parameter is set to 1 if one or more of a number of semi-static fields in outer IP headers have changed compared to their reference values in the context, otherwise it is set to 0. The value used for this parameter is also used for the "outer_ip_flag" argument for a number of encoding methods defined above, when these are processing the irregular chain. This flag may only be set to 1 for the "co_common" packet format in the different profiles. o ipv4(profile, is_innermost, outer_ip_flag) See definition of arguments for "ipv6" above. o udp(profile) profile: Set to the 16-bit profile number of the profile used to compress this packet. o rtp(profile, ts_stride_value, time_stride_value) profile: Set to the 16-bit profile number of the profile used to compress this packet. ts_stride_value: The value of this parameter should be set to the expected increase in the RTP Timestamp between consecutive RTP sequence numbers and the selected value is implementation- specific. See also Section 6.6.8. time_stride_value: The value of this parameter should be set to the expected inter-arrival time between consecutive packets for the flow, and the selected value is implementation-specific. It MUST NOT be set to a non-zero value, unless the compressor has received a feedback message with the CLOCK_RESOLUTION option set to a non-zero value. See also Section 6.6.9. o esp(profile) Pelletier & Sandlund Expires April 4, 2008 [Page 37] Internet-Draft ROHCv2 Profiles October 2007 profile: Set to the 16-bit profile number of the profile used to compress this packet. o udp_lite(profile) profile: Set to the 16-bit profile number of the profile used to compress this packet. o rtp_baseheader(profile, ts_stride_value, time_stride_value, outer_ip_flag): profile: Set to the 16-bit profile number of the profile used to compress this packet. ts_stride_value: The value of this parameter should be set to the expected increase in the RTP Timestamp between consecutive RTP sequence numbers and the selected value is implementation- specific. See also Section 6.6.8. time_stride_value: The value of this parameter should be set to the expected inter-arrival time between consecutive packets for the flow, and the selected value is implementation-specific. It MUST NOT be set to a non-zero value, unless the compressor has received a feedback message with the CLOCK_RESOLUTION option set to a non-zero value. See also Section 6.6.9. outer_ip_flag: This parameter is set to 1 if one or more of a number of semi-static fields in outer IP headers have changed compared to their reference values in the context, otherwise it is set to 0. The value used for this parameter is also used for the "outer_ip_flag" argument for a number of encoding methods defined above, when these are processing the irregular chain. This flag may only be set to 1 either for the "co_common" packet format in the different profiles. o udp_baseheader(profile, outer_ip_flag): profile: Set to the 16-bit profile number of the profile used to compress this packet. Pelletier & Sandlund Expires April 4, 2008 [Page 38] Internet-Draft ROHCv2 Profiles October 2007 outer_ip_flag: See definition of this argument for "rtp_baseheader" above. o esp_baseheader(profile, outer_ip_flag): See definition of arguments for "udp_baseheader" above. o iponly_baseheader(profile, outer_ip_flag): See definition of arguments for "udp_baseheader" above. o udplite_rtp_baseheader(profile, ts_stride_value, time_stride_value, outer_ip_flag): See definition of arguments for "rtp_baseheader" above. o udplite_baseheader(profile, outer_ip_flag): See definition of arguments for "udp_baseheader" above. 6.8. Packet Formats ROHCv2 profiles use two different packet types: the Initialization and Refresh (IR) packet type, and the Compressed packet type (CO). Each packet type defines a number of packet formats: An IR packet format, and two sets base header formats are defined for the CO type with a few additional formats that are common to both sets. 6.8.1. Initialization and Refresh Packet (IR) The IR packet format uses the structure of the ROHC IR packet as defined in [RFC4995], section 5.2.2.1. Packet type: IR This packet type communicates the static part and the dynamic part of the context. Pelletier & Sandlund Expires April 4, 2008 [Page 39] Internet-Draft ROHCv2 Profiles October 2007 The ROHCv2 IR packet has the following format: 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : Add-CID octet : if for small CIDs and (CID != 0) +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 1 | IR type octet +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / 1-2 octets if for large CIDs : : +---+---+---+---+---+---+---+---+ | Profile | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ | | / Static chain / variable length | | - - - - - - - - - - - - - - - - | | / Dynamic chain / variable length | | - - - - - - - - - - - - - - - - | | / Payload / variable length | | - - - - - - - - - - - - - - - - Static chain: See Section 6.5. Dynamic chain: See Section 6.5. Payload: The payload of the corresponding original packet, if any. The payload consists of all data after the last octet of the last header compressed by the current profile. The presence of a payload is inferred from the packet length. 6.8.2. Compressed Packet Formats (CO) 6.8.2.1. Design rationale for compressed base headers The compressed packet formats are defined as two separate sets for each profile: one set for the packets where the innermost IP header contains a sequential IP-ID (either network byte order or byte swapped), and one set for the packets without sequential IP-ID Pelletier & Sandlund Expires April 4, 2008 [Page 40] Internet-Draft ROHCv2 Profiles October 2007 (either random, zero, or no IP-ID). There are also a number of common packet format shared between both sets. When described below, the packet formats belonging to the sequential set contain "seq" in their names, while those belonging to the non-sequential set contain the "rnd" in their names. The design of the packet formats is derived from the field behavior analysis found in Appendix A. All of the compressed base headers transmit LSB-encoded MSN bits and a CRC. The following packet formats exist for all profiles defined in this document, both for the sequential and random packet format sets: o co_common: The common packet format is designed so that it can be used for changes to any dynamic field in the context, but can not always transmit all such fields uncompressed. It is therefore useful for when some of the more rarely changing fields in the headers change. Since this packet format may modify the value of the control fields that determine how the decompressor interprets different compressed header format, it carries a 7-bit CRC to reduce the probability of context corruption. This packet format uses a large set of flags to provide information about which fields are present in the packet format and can therefore be of very varied size. This packet format is similar to the UOR-2- extension 3 packet format in [RFC3095] o co_repair: This format is intended to be used when context damage has been assumed, and therefore changing fields are transmit uncompressed in this format and contains a complete dynamic chain. This packet format should be considered a replacement for the IR- DYN packet format which is not defined for the profiles defined in this document. o pt_0_crc3: This packet format only transmits the MSN, and can therefore only be used to update the MSN and fields that are derived from the MSN, such as IP-ID and the RTP Timestamp (where applicable). This packet format is equivalent to the UO-0 packet format in [RFC3095] o pt_0_crc7: This packet has the same properties as pt_0_crc3, but is instead protected by a 7-bit CRC and contains a larger amount of LSB-encoded MSN bits. This format can for example be used on ROHC channels that expect a high amount of reordering or link layers with high residual error rates. Pelletier & Sandlund Expires April 4, 2008 [Page 41] Internet-Draft ROHCv2 Profiles October 2007 The following packet format descriptions apply to profiles 0x101 and 0x107. o pt_1_rnd: This format is a replacement for the UO-1 packet format in [RFC3095] and can be used to transmit changes in the MSN, RTP Marker bit and it can update the RTP timestamp using scaled timestamp encoding. o pt_1_seq_id: This format is a replacement for the UO-1-ID packet format in [RFC3095] and can be used to transmit changes in the MSN and IP-ID. o pt_1_seq_ts: This format is a replacement for the UO-1-TS packet format in [RFC3095] and can be used to transmit changes in the MSN, RTP Marker bit and can update the RTP Timestamp using scaled timestamp encoding. o pt_2_rnd: This format is a replacement for the UOR-2 packet format in [RFC3095] and can be used to transmit changes in the MSN, RTP Marker bit and the RTP Timestamp, and is protected by a 7-bit CRC. o pt_2_seq_id: This format is a replacement for the UO-2-ID packet format in [RFC3095] and can be used to transmit changes in the MSN and IP-ID. This format is also protected by a 7-bit CRC. o pt_2_seq_ts: This format is a replacement for the UO-2-TS packet format in [RFC3095] and can be used to transmit changes in the MSN, RTP Marker bit and can update the RTP Timestamp using scaled timestamp encoding. This format is also protected by a 7-bit CRC. o pt_2_seq_both: This format is replaces the UOR-2-ID extension 1 format in [RFC3095] and can carry changes in both the RTP Timestamp and IP-ID in addition to the MSN and Marker bit. The following packet formats descriptions apply to profiles 0x102, 0x103, 0x104 and 0x108. o pt_1_seq_id: This format is a replacement for the UO-1-ID packet format in [RFC3095] and can be used to transmit changes in the MSN and IP-ID. o pt_2_rnd: This format is a replacement for the UOR-2 packet format in [RFC3095] and can be used to transmit changes in the MSN and is protected by a 7-bit CRC. Pelletier & Sandlund Expires April 4, 2008 [Page 42] Internet-Draft ROHCv2 Profiles October 2007 o pt_2_seq_id: This format is a replacement for the UO-2-ID packet format in [RFC3095] and can be used to transmit changes in the MSN and IP-ID. This format is also protected by a 7-bit CRC. 6.8.2.2. co_repair Header Format The ROHCv2 co_repair packet has the following format: 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : Add-CID octet : if for small CIDs and CID 1-15 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 0 1 1 | discriminator +---+---+---+---+---+---+---+---+ : : / 0, 1, or 2 octets of CID / 1-2 octets if large CIDs : : +---+---+---+---+---+---+---+---+ |r1 | CRC-7 | +---+---+---+---+---+---+---+---+ | r2 | CRC-3 | +---+---+---+---+---+---+---+---+ | | / Dynamic chain / variable length | | - - - - - - - - - - - - - - - - | | / Payload / variable length | | - - - - - - - - - - - - - - - - r1: MUST be set to zero; otherwise, the decompressor MUST discard the packet. CRC-7: A 7-bit CRC over the entire uncompressed header, computed using the crc7(data_value, data_length) encoding method defined in Section 6.8.2.4, where data_value corresponds to the entire uncompressed header chain and data_length the length of this header chain. r2: MUST be set to zero; otherwise, the decompressor MUST discard the packet. Pelletier & Sandlund Expires April 4, 2008 [Page 43] Internet-Draft ROHCv2 Profiles October 2007 CRC-3: See Section 6.6.11. Dynamic chain: See Section 6.5. Payload: The payload of the corresponding original packet, if any. The payload consists of all data after the last octet of the last header compressed by the current profile. The presence of a payload is inferred from the packet length. 6.8.2.3. General CO Header Format The CO packets communicate irregularities in the packet header. All CO packets carry a CRC and can update the context. All CO formats except for co_repair which is defined in Section 6.8.2.2 use the general format defined in this section. The general format for a compressed header is as follows: 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : Add-CID octet : if for small CIDs and CID 1-15 +---+---+---+---+---+---+---+---+ | first octet of base header | (with type indication) +---+---+---+---+---+---+---+---+ : : / 0, 1, or 2 octets of CID / 1-2 octets if large CIDs : : +---+---+---+---+---+---+---+---+ / remainder of base header / variable number of octets +---+---+---+---+---+---+---+---+ : : / Irregular Chain / variable : : --- --- --- --- --- --- --- --- The base header in the figure above is the compressed representation of the innermost IP header and other header(s), if any, in the uncompressed packet. The entire set of base headers are defined in Section 6.8.2.4 using the ROHC Formal notation [RFC4997] . 6.8.2.4. Header Formats in ROHC-FN //////////////////////////////////////////// // Constants //////////////////////////////////////////// Pelletier & Sandlund Expires April 4, 2008 [Page 44] Internet-Draft ROHCv2 Profiles October 2007 // IP-ID behavior constants IP_ID_BEHAVIOR_SEQUENTIAL = 0; IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED = 1; IP_ID_BEHAVIOR_RANDOM = 2; IP_ID_BEHAVIOR_ZERO = 3; // UDP-lite checksum coverage behavior constants UDP_LITE_COVERAGE_INFERRED = 0; UDP_LITE_COVERAGE_STATIC = 1; UDP_LITE_COVERAGE_IRREGULAR = 2; UDP_LITE_COVERAGE_RESERVED = 3; // Variable reordering offset REORDERING_NONE = 0; REORDERING_QUARTER = 1; REORDERING_HALF = 2; REORDERING_THREEQUARTERS = 3; // Profile names and versions PROFILE_RTP_0101 = 0x0101; PROFILE_UDP_0102 = 0x0102; PROFILE_ESP_0103 = 0x0103; PROFILE_IP_0104 = 0x0104; PROFILE_RTP_0107 = 0x0107; // With UDP-LITE PROFILE_UDPLITE_0108 = 0x0108; // Without RTP // Default values for RTP timestamp encoding TS_STRIDE_DEFAULT = 160; TIME_STRIDE_DEFAULT = 0; //////////////////////////////////////////// // Global control fields //////////////////////////////////////////// CONTROL { msn [ 16 ]; reorder_ratio [ 2 ]; ip_id_offset [ 16 ]; // Used if innermost IP is IPv4 } /////////////////////////////////////////////// // Encoding methods not specified in FN syntax: /////////////////////////////////////////////// baseheader_extension_headers "defined in Section 6.6.1"; baseheader_outer_headers "defined in Section 6.6.2"; control_crc3_encoding "defined in Section 6.6.11"; inferred_ip_v4_header_checksum "defined in Section 6.6.4"; Pelletier & Sandlund Expires April 4, 2008 [Page 45] Internet-Draft ROHCv2 Profiles October 2007 inferred_ip_v4_length "defined in Section 6.6.6"; inferred_ip_v6_length "defined in Section 6.6.7"; inferred_mine_header_checksum "defined in Section 6.6.5"; inferred_scaled_field "defined in Section 6.6.10"; inferred_sequential_ip_id "defined in Section 6.6.12"; inferred_udp_length "defined in Section 6.6.3"; list_csrc(cc_value) "defined in Section 6.6.13"; timer_based_lsb(time_stride, k, p) "defined in Section 6.6.9"; //////////////////////////////////////////// // General encoding methods //////////////////////////////////////////// reorder_choice { UNCOMPRESSED { ratio [ 2 ]; } DEFAULT { ratio =:= irregular(2); } COMPRESSED none { ENFORCE(ratio.UVALUE == REORDERING_NONE); ratio [ 2 ]; } COMPRESSED quarter { ENFORCE(ratio.UVALUE == REORDERING_QUARTER); ratio [ 2 ]; } COMPRESSED half { ENFORCE(ratio.UVALUE == REORDERING_HALF); ratio [ 2 ]; } COMPRESSED three_quarters { ENFORCE(ratio.UVALUE == REORDERING_THREEQUARTERS); ratio [ 2 ]; } } static_or_irreg(flag, width) { UNCOMPRESSED { field [ width ]; Pelletier & Sandlund Expires April 4, 2008 [Page 46] Internet-Draft ROHCv2 Profiles October 2007 } COMPRESSED irreg_enc { ENFORCE(flag == 1); field =:= irregular(width) [ width ]; } COMPRESSED static_enc { ENFORCE(flag == 0); field =:= static [ 0 ]; } } optional_32(flag) { UNCOMPRESSED { item [ 0, 32 ]; } COMPRESSED present { ENFORCE(flag == 1); item =:= irregular(32) [ 32 ]; } COMPRESSED not_present { ENFORCE(flag == 0); item =:= compressed_value(0, 0) [ 0 ]; } } // Send the entire value, or keep previous value sdvl_or_static(flag) { UNCOMPRESSED { field [ 32 ]; } COMPRESSED present_7bit { ENFORCE(flag == 1); ENFORCE(field.UVALUE < 2^7); ENFORCE(field.CVALUE == field.UVALUE); discriminator =:= '0' [ 1 ]; field [ 7 ]; } COMPRESSED present_14bit { ENFORCE(flag == 1); ENFORCE(field.UVALUE < 2^14); Pelletier & Sandlund Expires April 4, 2008 [Page 47] Internet-Draft ROHCv2 Profiles October 2007 ENFORCE(field.CVALUE == field.UVALUE); discriminator =:= '10' [ 2 ]; field [ 14 ]; } COMPRESSED present_21bit { ENFORCE(flag == 1); ENFORCE(field.UVALUE < 2^21); ENFORCE(field.CVALUE == field.UVALUE); discriminator =:= '110' [ 3 ]; field [ 21 ]; } COMPRESSED present_28bit { ENFORCE(flag == 1); ENFORCE(field.UVALUE < 2^28); ENFORCE(field.CVALUE == field.UVALUE); discriminator =:= '1110' [ 4 ]; field [ 28 ]; } COMPRESSED present_32bit { ENFORCE(flag == 1); ENFORCE(field.CVALUE == field.UVALUE); discriminator =:= '11111111' [ 8 ]; field [ 32 ]; } COMPRESSED not_present { ENFORCE(flag == 0); field =:= static; } } // Send the entire value, or revert to default value sdvl_or_default(flag, default_value) { UNCOMPRESSED { field [ 32 ]; } COMPRESSED present_7bit { ENFORCE(flag == 1); ENFORCE(field.UVALUE < 2^7); ENFORCE(field.CVALUE == field.UVALUE); discriminator =:= '0' [ 1 ]; field [ 7 ]; } Pelletier & Sandlund Expires April 4, 2008 [Page 48] Internet-Draft ROHCv2 Profiles October 2007 COMPRESSED present_14bit { ENFORCE(flag == 1); ENFORCE(field.UVALUE < 2^14); ENFORCE(field.CVALUE == field.UVALUE); discriminator =:= '10' [ 2 ]; field [ 14 ]; } COMPRESSED present_21bit { ENFORCE(flag == 1); ENFORCE(field.UVALUE < 2^21); ENFORCE(field.CVALUE == field.UVALUE); discriminator =:= '110' [ 3 ]; field [ 21 ]; } COMPRESSED present_28bit { ENFORCE(flag == 1); ENFORCE(field.UVALUE < 2^28); ENFORCE(field.CVALUE == field.UVALUE); discriminator =:= '1110' [ 4 ]; field [ 28 ]; } COMPRESSED present_32bit { ENFORCE(flag == 1); ENFORCE(field.CVALUE == field.UVALUE); discriminator =:= '11111111' [ 8 ]; field [ 32 ]; } COMPRESSED not_present { ENFORCE(flag == 0); field =:= uncompressed_value(32, default_value); } } lsb_7_or_31 { UNCOMPRESSED { item [ 32 ]; } COMPRESSED lsb_7 { discriminator =:= '0' [ 1 ]; item =:= lsb(7, ((2^7) / 4) - 1) [ 7 ]; } Pelletier & Sandlund Expires April 4, 2008 [Page 49] Internet-Draft ROHCv2 Profiles October 2007 COMPRESSED lsb_31 { discriminator =:= '1' [ 1 ]; item =:= lsb(31, ((2^31) / 4) - 1) [ 31 ]; } } crc3(data_value, data_length) { UNCOMPRESSED { } COMPRESSED { crc_value =:= crc(3, 0x06, 0x07, data_value, data_length) [ 3 ]; } } crc7(data_value, data_length) { UNCOMPRESSED { } COMPRESSED { crc_value =:= crc(7, 0x79, 0x7f, data_value, data_length) [ 7 ]; } } // Encoding method for updating a scaled field and its associated // control fields. Should be used both when the value is scaled // or unscaled in a compressed format. field_scaling(stride_value, scaled_value, unscaled_value) { UNCOMPRESSED { residue_field [ 32 ]; } COMPRESSED no_scaling { ENFORCE(stride_value == 0); ENFORCE(residue_field.UVALUE == unscaled_value); ENFORCE(scaled_value == 0); } COMPRESSED scaling_used { ENFORCE(stride_value != 0); ENFORCE(residue_field.UVALUE == (unscaled_value % stride_value)); ENFORCE(unscaled_value == scaled_value * stride_value + residue_field.UVALUE); } } Pelletier & Sandlund Expires April 4, 2008 [Page 50] Internet-Draft ROHCv2 Profiles October 2007 //////////////////////////////////////////// // IPv6 Destination options header //////////////////////////////////////////// ip_dest_opt { UNCOMPRESSED { next_header [ 8 ]; length [ 8 ]; value [ length.UVALUE * 64 + 48 ]; } DEFAULT { length =:= static; next_header =:= static; value =:= static; } COMPRESSED dest_opt_static { next_header =:= irregular(8) [ 8 ]; length =:= irregular(8) [ 8 ]; } COMPRESSED dest_opt_dynamic { value =:= irregular(length.UVALUE * 64 + 48) [ length.UVALUE * 64 + 48 ]; } COMPRESSED dest_opt_irregular { } } //////////////////////////////////////////// // IPv6 Hop-by-Hop options header //////////////////////////////////////////// ip_hop_opt { UNCOMPRESSED { next_header [ 8 ]; length [ 8 ]; value [ length.UVALUE * 64 + 48 ]; } DEFAULT { length =:= static; next_header =:= static; Pelletier & Sandlund Expires April 4, 2008 [Page 51] Internet-Draft ROHCv2 Profiles October 2007 value =:= static; } COMPRESSED hop_opt_static { next_header =:= irregular(8) [ 8 ]; length =:= irregular(8) [ 8 ]; } COMPRESSED hop_opt_dynamic { value =:= irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; } COMPRESSED hop_opt_irregular { } } //////////////////////////////////////////// // IPv6 Routing header //////////////////////////////////////////// ip_rout_opt { UNCOMPRESSED { next_header [ 8 ]; length [ 8 ]; value [ length.UVALUE * 64 + 48 ]; } DEFAULT { length =:= static; next_header =:= static; value =:= static; } COMPRESSED rout_opt_static { next_header =:= irregular(8) [ 8 ]; length =:= irregular(8) [ 8 ]; value =:= irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ]; } COMPRESSED rout_opt_dynamic { } COMPRESSED rout_opt_irregular { } Pelletier & Sandlund Expires April 4, 2008 [Page 52] Internet-Draft ROHCv2 Profiles October 2007 } //////////////////////////////////////////// // GRE Header //////////////////////////////////////////// optional_lsb_7_or_31(flag) { UNCOMPRESSED { item [ 0, 32 ]; } COMPRESSED present { ENFORCE(flag == 1); item =:= lsb_7_or_31 [ 8, 32 ]; } COMPRESSED not_present { ENFORCE(flag == 0); item =:= compressed_value(0, 0) [ 0 ]; } } optional_checksum(flag_value) { UNCOMPRESSED { value [ 0, 16 ]; reserved1 [ 0, 16 ]; } COMPRESSED cs_present { ENFORCE(flag_value == 1); value =:= irregular(16) [ 16 ]; reserved1 =:= uncompressed_value(16, 0) [ 0 ]; } COMPRESSED not_present { ENFORCE(flag_value == 0); value =:= compressed_value(0, 0) [ 0 ]; reserved1 =:= compressed_value(0, 0) [ 0 ]; } } gre_proto { UNCOMPRESSED { protocol [ 16 ]; } Pelletier & Sandlund Expires April 4, 2008 [Page 53] Internet-Draft ROHCv2 Profiles October 2007 COMPRESSED ether_v4 { discriminator =:= compressed_value(1, 0) [ 1 ]; protocol =:= uncompressed_value(16, 0x0800) [ 0 ]; } COMPRESSED ether_v6 { discriminator =:= compressed_value(1, 1) [ 1 ]; protocol =:= uncompressed_value(16, 0x86DD) [ 0 ]; } } gre { UNCOMPRESSED { c_flag [ 1 ]; r_flag =:= uncompressed_value(1, 0) [ 1 ]; k_flag [ 1 ]; s_flag [ 1 ]; reserved0 =:= uncompressed_value(9, 0) [ 9 ]; version =:= uncompressed_value(3, 0) [ 3 ]; protocol [ 16 ]; checksum_and_res [ 0, 32 ]; key [ 0, 32 ]; sequence_number [ 0, 32 ]; } DEFAULT { c_flag =:= static; k_flag =:= static; s_flag =:= static; protocol =:= static; key =:= static; sequence_number =:= static; } COMPRESSED gre_static { protocol =:= gre_proto [ 1 ]; c_flag =:= irregular(1) [ 1 ]; k_flag =:= irregular(1) [ 1 ]; s_flag =:= irregular(1) [ 1 ]; padding =:= compressed_value(4, 0) [ 4 ]; key =:= optional_32(k_flag.UVALUE) [ 0, 32 ]; } COMPRESSED gre_dynamic { checksum_and_res =:= optional_checksum(c_flag.UVALUE) [ 0, 16 ]; sequence_number =:= optional_32(s_flag.UVALUE) [ 0, 32 ]; Pelletier & Sandlund Expires April 4, 2008 [Page 54] Internet-Draft ROHCv2 Profiles October 2007 } COMPRESSED gre_irregular { checksum_and_res =:= optional_checksum(c_flag.UVALUE) [ 0, 16 ]; sequence_number =:= optional_lsb_7_or_31(s_flag.UVALUE) [ 0, 8, 32 ]; } } ///////////////////////////////////////////// // MINE header ///////////////////////////////////////////// mine { UNCOMPRESSED { next_header [ 8 ]; s_bit [ 1 ]; res_bits [ 7 ]; checksum [ 16 ]; orig_dest [ 32 ]; orig_src [ 0, 32 ]; } DEFAULT { next_header =:= static; s_bit =:= static; res_bits =:= static; checksum =:= inferred_mine_header_checksum; orig_dest =:= static; orig_src =:= static; } COMPRESSED mine_static { next_header =:= irregular(8) [ 8 ]; s_bit =:= irregular(1) [ 1 ]; // Reserved bits are included to achieve byte-alignment res_bits =:= irregular(7) [ 7 ]; orig_dest =:= irregular(32) [ 32 ]; orig_src =:= optional_32(s_bit.UVALUE) [ 0, 32 ]; } COMPRESSED mine_dynamic { } COMPRESSED mine_irregular { } Pelletier & Sandlund Expires April 4, 2008 [Page 55] Internet-Draft ROHCv2 Profiles October 2007 } ///////////////////////////////////////////// // Authentication Header (AH) ///////////////////////////////////////////// ah { UNCOMPRESSED { next_header [ 8 ]; length [ 8 ]; res_bits =:= uncompressed_value(16, 0) [ 16 ]; spi [ 32 ]; sequence_number [ 32 ]; icv [ length.UVALUE*32-32 ]; } DEFAULT { next_header =:= static; length =:= static; spi =:= static; sequence_number =:= static; } COMPRESSED ah_static { next_header =:= irregular(8) [ 8 ]; length =:= irregular(8) [ 8 ]; spi =:= irregular(32) [ 32 ]; } COMPRESSED ah_dynamic { sequence_number =:= irregular(32) [ 32 ]; icv =:= irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; } COMPRESSED ah_irregular { sequence_number =:= lsb_7_or_31 [ 8, 32 ]; icv =:= irregular(length.UVALUE*32-32) [ length.UVALUE*32-32 ]; } } ///////////////////////////////////////////// // ESP header (NULL encrypted) ///////////////////////////////////////////// Pelletier & Sandlund Expires April 4, 2008 [Page 56] Internet-Draft ROHCv2 Profiles October 2007 // The value of the next header field from the trailer // part of the packet is passed as a parameter. esp_null(next_header_value) { UNCOMPRESSED { spi [ 32 ]; sequence_number [ 32 ]; } CONTROL { nh_field [ 8 ]; } DEFAULT { spi =:= static; sequence_number =:= static; nh_field =:= static; } COMPRESSED esp_static { nh_field =:= compressed_value(8, next_header_value) [ 8 ]; spi =:= irregular(32) [ 32 ]; } COMPRESSED esp_dynamic { sequence_number =:= irregular(32) [ 32 ]; } COMPRESSED esp_irregular { sequence_number =:= lsb_7_or_31 [ 8, 32 ]; } } ///////////////////////////////////////////// // IPv6 Header ///////////////////////////////////////////// fl_enc { UNCOMPRESSED { flow_label [ 20 ]; } COMPRESSED fl_zero { discriminator =:= '0' [ 1 ]; flow_label =:= uncompressed_value(20, 0) [ 0 ]; reserved =:= '0000' [ 4 ]; Pelletier & Sandlund Expires April 4, 2008 [Page 57] Internet-Draft ROHCv2 Profiles October 2007 } COMPRESSED fl_non_zero { discriminator =:= '1' [ 1 ]; flow_label =:= irregular(20) [ 20 ]; } } ipv6(profile, is_innermost, outer_ip_flag) { UNCOMPRESSED { version =:= uncompressed_value(4, 6) [ 4 ]; tos_tc [ 8 ]; flow_label [ 20 ]; payload_length [ 16 ]; next_header [ 8 ]; ttl_hopl [ 8 ]; src_addr [ 128 ]; dst_addr [ 128 ]; } DEFAULT { tos_tc =:= static; flow_label =:= static; payload_length =:= inferred_ip_v6_length; next_header =:= static; ttl_hopl =:= static; src_addr =:= static; dst_addr =:= static; } COMPRESSED ipv6_static { version_flag =:= '1' [ 1 ]; reserved =:= '00' [ 2 ]; flow_label =:= fl_enc [ 5, 21 ]; next_header =:= irregular(8) [ 8 ]; src_addr =:= irregular(128) [ 128 ]; dst_addr =:= irregular(128) [ 128 ]; } COMPRESSED ipv6_endpoint_static { ENFORCE((is_innermost == 1) && (profile == PROFILE_IP_0104)); version_flag =:= '1' [ 1 ]; innermost_indicator =:= compressed_value(1, 1) [ 1 ]; reserved =:= '0' [ 1 ]; flow_label =:= fl_enc [ 5, 21 ]; next_header =:= irregular(8) [ 8 ]; Pelletier & Sandlund Expires April 4, 2008 [Page 58] Internet-Draft ROHCv2 Profiles October 2007 src_addr =:= irregular(128) [ 128 ]; dst_addr =:= irregular(128) [ 128 ]; } COMPRESSED ipv6_endpoint_dynamic { ENFORCE((is_innermost == 1) && (profile == PROFILE_IP_0104)); tos_tc =:= irregular(8) [ 8 ]; ttl_hopl =:= irregular(8) [ 8 ]; reserved =:= compressed_value(6, 0) [ 6 ]; reorder_ratio =:= reorder_choice [ 2 ]; msn =:= irregular(16) [ 16 ]; } COMPRESSED ipv6_regular_dynamic { ENFORCE((is_innermost == 0) || (profile != PROFILE_IP_0104)); tos_tc =:= irregular(8) [ 8 ]; ttl_hopl =:= irregular(8) [ 8 ]; } COMPRESSED ipv6_outer_irregular { ENFORCE(is_innermost == 0); tos_tc =:= static_or_irreg(outer_ip_flag, 8) [ 0, 8 ]; ttl_hopl =:= static_or_irreg(outer_ip_flag, 8) [ 0, 8 ]; } COMPRESSED ipv6_innermost_irregular { ENFORCE(is_innermost == 1); } } ///////////////////////////////////////////// // IPv4 Header ///////////////////////////////////////////// ip_id_enc_dyn(behavior) { UNCOMPRESSED { ip_id [ 16 ]; } COMPRESSED ip_id_seq { ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); Pelletier & Sandlund Expires April 4, 2008 [Page 59] Internet-Draft ROHCv2 Profiles October 2007 ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE); ip_id =:= irregular(16) [ 16 ]; } COMPRESSED ip_id_random { ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM); ip_id =:= irregular(16) [ 16 ]; } COMPRESSED ip_id_zero { ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO); ip_id =:= uncompressed_value(16, 0) [ 0 ]; } } ip_id_enc_irreg(behavior) { UNCOMPRESSED { ip_id [ 16 ]; } COMPRESSED ip_id_seq { ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL); } COMPRESSED ip_id_seq_swapped { ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); } COMPRESSED ip_id_rand { ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM); ip_id =:= irregular(16) [ 16 ]; } COMPRESSED ip_id_zero { ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO); ip_id =:= uncompressed_value(16, 0) [ 0 ]; } } ip_id_behavior_choice(is_inner) { UNCOMPRESSED { behavior [ 2 ]; } DEFAULT { behavior =:= irregular(2); Pelletier & Sandlund Expires April 4, 2008 [Page 60] Internet-Draft ROHCv2 Profiles October 2007 } COMPRESSED sequential { ENFORCE(is_inner == 1); ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL); behavior [ 2 ]; } COMPRESSED sequential_swapped { ENFORCE(is_inner == 1); ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); behavior [ 2 ]; } COMPRESSED random { ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM); behavior [ 2 ]; } COMPRESSED zero { ENFORCE(behavior.UVALUE == IP_ID_BEHAVIOR_ZERO); behavior [ 2 ]; } } ipv4(profile, is_innermost, outer_ip_flag) { UNCOMPRESSED { version =:= uncompressed_value(4, 4) [ 4 ]; hdr_length =:= uncompressed_value(4, 5) [ 4 ]; tos_tc [ 8 ]; length =:= inferred_ip_v4_length [ 16 ]; ip_id [ 16 ]; rf =:= uncompressed_value(1, 0) [ 1 ]; df [ 1 ]; mf =:= uncompressed_value(1, 0) [ 1 ]; frag_offset =:= uncompressed_value(13, 0) [ 13 ]; ttl_hopl [ 8 ]; protocol [ 8 ]; checksum =:= inferred_ip_v4_header_checksum [ 16 ]; src_addr [ 32 ]; dst_addr [ 32 ]; } CONTROL { ip_id_behavior [ 2 ]; } Pelletier & Sandlund Expires April 4, 2008 [Page 61] Internet-Draft ROHCv2 Profiles October 2007 DEFAULT { tos_tc =:= static; df =:= static; ttl_hopl =:= static; protocol =:= static; src_addr =:= static; dst_addr =:= static; ip_id_behavior =:= static; } COMPRESSED ipv4_static { version_flag =:= '0' [ 1 ]; reserved =:= '0000000' [ 7 ]; protocol =:= irregular(8) [ 8 ]; src_addr =:= irregular(32) [ 32 ]; dst_addr =:= irregular(32) [ 32 ]; } COMPRESSED ipv4_endpoint_static { ENFORCE((is_innermost == 1) && (profile == PROFILE_IP_0104)); version_flag =:= '0' [ 1 ]; innermost_indicator =:= compressed_value(1, 1) [ 1 ]; reserved =:= '000000' [ 6 ]; protocol =:= irregular(8) [ 8 ]; src_addr =:= irregular(32) [ 32 ]; dst_addr =:= irregular(32) [ 32 ]; } COMPRESSED ipv4_endpoint_dynamic { ENFORCE((is_innermost == 1) && (profile == PROFILE_IP_0104)); reserved =:= '000' [ 3 ]; reorder_ratio =:= reorder_choice [ 2 ]; df =:= irregular(1) [ 1 ]; ip_id_behavior =:= ip_id_behavior_choice(is_innermost) [ 2 ]; tos_tc =:= irregular(8) [ 8 ]; ttl_hopl =:= irregular(8) [ 8 ]; ip_id =:= ip_id_enc_dyn(ip_id_behavior.UVALUE) [ 0, 16 ]; msn =:= irregular(16) [ 16 ]; } COMPRESSED ipv4_regular_dynamic { ENFORCE((is_innermost == 0) || (profile != PROFILE_IP_0104)); reserved =:= '00000' [ 5 ]; df =:= irregular(1) [ 1 ]; ip_id_behavior =:= ip_id_behavior_choice(is_innermost) [ 2 ]; Pelletier & Sandlund Expires April 4, 2008 [Page 62] Internet-Draft ROHCv2 Profiles October 2007 tos_tc =:= irregular(8) [ 8 ]; ttl_hopl =:= irregular(8) [ 8 ]; ip_id =:= ip_id_enc_dyn(ip_id_behavior.UVALUE) [ 0, 16 ]; } COMPRESSED ipv4_outer_irregular { ENFORCE(is_innermost == 0); ip_id =:= ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ]; tos_tc =:= static_or_irreg(outer_ip_flag, 8) [ 0, 8 ]; ttl_hopl =:= static_or_irreg(outer_ip_flag, 8) [ 0, 8 ]; } COMPRESSED ipv4_innermost_irregular { ip_id =:= ip_id_enc_irreg(ip_id_behavior.UVALUE) [ 0, 16 ]; ENFORCE(is_innermost == 1); } } ///////////////////////////////////////////// // UDP Header ///////////////////////////////////////////// udp(profile) { UNCOMPRESSED { ENFORCE((profile == PROFILE_RTP_0101) || (profile == PROFILE_UDP_0102)); src_port [ 16 ]; dst_port [ 16 ]; udp_length =:= inferred_udp_length [ 16 ]; checksum [ 16 ]; } CONTROL { checksum_used [ 1 ]; } DEFAULT { src_port =:= static; dst_port =:= static; } COMPRESSED udp_static { src_port =:= irregular(16) [ 16 ]; dst_port =:= irregular(16) [ 16 ]; } Pelletier & Sandlund Expires April 4, 2008 [Page 63] Internet-Draft ROHCv2 Profiles October 2007 COMPRESSED udp_endpoint_dynamic { ENFORCE(profile == PROFILE_UDP_0102); ENFORCE(checksum_used.UVALUE == (checksum.UVALUE != 0)); checksum =:= irregular(16) [ 16 ]; msn =:= irregular(16) [ 16 ]; reserved =:= compressed_value(6, 0) [ 6 ]; reorder_ratio =:= reorder_choice [ 2 ]; } COMPRESSED udp_regular_dynamic { ENFORCE(profile == PROFILE_RTP_0101); ENFORCE(checksum_used == (checksum.UVALUE != 0)); checksum =:= irregular(16) [ 16 ]; } COMPRESSED udp_zero_checksum_irregular { ENFORCE(checksum_used.UVALUE == 0); checksum =:= uncompressed_value(16, 0) [ 0 ]; } COMPRESSED udp_with_checksum_irregular { ENFORCE(checksum_used.UVALUE == 1); checksum =:= irregular(16) [ 16 ]; } } ///////////////////////////////////////////// // RTP Header ///////////////////////////////////////////// csrc_list_dynchain(presence, cc_value) { UNCOMPRESSED { csrc_list; } COMPRESSED no_list { ENFORCE(cc_value == 0); ENFORCE(presence == 0); csrc_list =:= uncompressed_value(0, 0) [ 0 ]; } COMPRESSED list_present { ENFORCE(presence == 1); csrc_list =:= list_csrc(cc_value) [ VARIABLE ]; } } Pelletier & Sandlund Expires April 4, 2008 [Page 64] Internet-Draft ROHCv2 Profiles October 2007 rtp(profile, ts_stride_value, time_stride_value) { UNCOMPRESSED { ENFORCE((profile == PROFILE_RTP_0101) || (profile == PROFILE_RTP_0107)); rtp_version =:= uncompressed_value(2, 0) [ 2 ]; pad_bit [ 1 ]; extension [ 1 ]; cc [ 4 ]; marker [ 1 ]; payload_type [ 7 ]; sequence_number [ 16 ]; timestamp [ 32 ]; ssrc [ 32 ]; csrc_list [ cc.UVALUE * 32 ]; } CONTROL { ENFORCE(time_stride_value == time_stride.UVALUE); ENFORCE(ts_stride_value == ts_stride.UVALUE); ts_stride [ 32 ]; time_stride [ 32 ]; ts_scaled [ 32 ]; ts_offset =:= field_scaling(ts_stride.UVALUE, ts_scaled.UVALUE, timestamp.UVALUE) [ 32 ]; } INITIAL { ts_stride =:= uncompressed_value(32, TS_STRIDE_DEFAULT); time_stride =:= uncompressed_value(32, TIME_STRIDE_DEFAULT); } DEFAULT { ENFORCE(msn.UVALUE == sequence_number.UVALUE); pad_bit =:= static; extension =:= static; cc =:= static; marker =:= static; payload_type =:= static; sequence_number =:= static; timestamp =:= static; ssrc =:= static; csrc_list =:= static; } COMPRESSED rtp_static { ssrc =:= irregular(32) [ 32 ]; Pelletier & Sandlund Expires April 4, 2008 [Page 65] Internet-Draft ROHCv2 Profiles October 2007 } COMPRESSED rtp_dynamic { reserved =:= compressed_value(1, 0) [ 1 ]; reorder_ratio =:= reorder_choice [ 2 ]; list_present =:= irregular(1) [ 1 ]; tss_indicator =:= irregular(1) [ 1 ]; tis_indicator =:= irregular(1) [ 1 ]; pad_bit =:= irregular(1) [ 1 ]; extension =:= irregular(1) [ 1 ]; marker =:= irregular(1) [ 1 ]; payload_type =:= irregular(7) [ 7 ]; sequence_number =:= irregular(16) [ 16 ]; timestamp =:= irregular(32) [ 32 ]; ts_stride =:= sdvl_or_default(tss_indicator, TS_STRIDE_DEFAULT) [ VARIABLE ]; time_stride =:= sdvl_or_default(tis_indicator, TIME_STRIDE_DEFAULT) [ VARIABLE ]; csrc_list =:= csrc_list_dynchain(list_present, cc.UVALUE) [ VARIABLE ]; } COMPRESSED rtp_irregular { } } ///////////////////////////////////////////// // UDP-Lite Header ///////////////////////////////////////////// checksum_coverage_dynchain(behavior) { UNCOMPRESSED { checksum_coverage [ 16 ]; } COMPRESSED inferred_coverage { ENFORCE(behavior == UDP_LITE_COVERAGE_INFERRED); checksum_coverage =:= inferred_udp_length [ 0 ]; } COMPRESSED static_coverage { ENFORCE(behavior == UDP_LITE_COVERAGE_STATIC); checksum_coverage =:= irregular(16) [ 16 ]; } COMPRESSED irregular_coverage { ENFORCE(behavior == UDP_LITE_COVERAGE_IRREGULAR); Pelletier & Sandlund Expires April 4, 2008 [Page 66] Internet-Draft ROHCv2 Profiles October 2007 checksum_coverage =:= irregular(16) [ 16 ]; } } checksum_coverage_irregular(behavior) { UNCOMPRESSED { checksum_coverage [ 16 ]; } COMPRESSED inferred_coverage { ENFORCE(behavior == UDP_LITE_COVERAGE_INFERRED); checksum_coverage =:= inferred_udp_length [ 0 ]; } COMPRESSED static_coverage { ENFORCE(behavior == UDP_LITE_COVERAGE_STATIC); checksum_coverage =:= static [ 0 ]; } COMPRESSED irregular_coverage { ENFORCE(behavior == UDP_LITE_COVERAGE_IRREGULAR); checksum_coverage =:= irregular(16) [ 16 ]; } } udp_lite(profile) { UNCOMPRESSED { ENFORCE((profile == PROFILE_RTP_0107) || (profile == PROFILE_UDPLITE_0108)); src_port [ 16 ]; dst_port [ 16 ]; checksum_coverage [ 16 ]; checksum [ 16 ]; } CONTROL { coverage_behavior [ 2 ]; } DEFAULT { src_port =:= static; dst_port =:= static; } COMPRESSED udp_lite_static { src_port =:= irregular(16) [ 16 ]; Pelletier & Sandlund Expires April 4, 2008 [Page 67] Internet-Draft ROHCv2 Profiles October 2007 dst_port =:= irregular(16) [ 16 ]; } COMPRESSED udp_lite_endpoint_dynamic { ENFORCE(profile == PROFILE_UDPLITE_0108); reserved =:= compressed_value(4, 0) [ 4 ]; coverage_behavior =:= irregular(2) [ 2 ]; reorder_ratio =:= reorder_choice [ 2 ]; checksum_coverage =:= checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 16 ]; checksum =:= irregular(16) [ 16 ]; msn =:= irregular(16) [ 16 ]; } COMPRESSED udp_lite_regular_dynamic { coverage_behavior =:= irregular(2) [ 2 ]; reserved =:= compressed_value(6, 0) [ 6 ]; checksum_coverage =:= checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 16 ]; checksum =:= irregular(16) [ 16 ]; } COMPRESSED udp_lite_irregular { checksum_coverage =:= checksum_coverage_irregular(coverage_behavior.UVALUE) [ 0, 16 ]; checksum =:= irregular(16) [ 16 ]; } } ///////////////////////////////////////////// // ESP Header (Non-NULL encrypted // i.e. only used for the ESP profile) ///////////////////////////////////////////// esp(profile) { UNCOMPRESSED { ENFORCE(profile == PROFILE_ESP_0103); ENFORCE(msn.UVALUE == sequence_number.UVALUE % 65536); spi [ 32 ]; sequence_number [ 32 ]; } DEFAULT { spi =:= static; sequence_number =:= static; } Pelletier & Sandlund Expires April 4, 2008 [Page 68] Internet-Draft ROHCv2 Profiles October 2007 COMPRESSED esp_static { // Needs to be discriminated from ESP NULL headers, // and therefore we have a dummy protocol field here. discriminator =:= uncompressed_value(8, 255) [ 8 ]; spi =:= irregular(32) [ 32 ]; } COMPRESSED esp_dynamic { sequence_number =:= irregular(32) [ 32 ]; reserved =:= compressed_value(6, 0) [ 6 ]; reorder_ratio =:= reorder_choice [ 2 ]; } COMPRESSED esp_irregular { } } /////////////////////////////////////////////////// // Encoding methods used in the profiles' CO packets /////////////////////////////////////////////////// // Variable reordering offset used for MSN msn_lsb(k) { UNCOMPRESSED { master [ VARIABLE ]; } COMPRESSED none { ENFORCE(reorder_ratio.UVALUE == REORDERING_NONE); master =:= lsb(k, 1); } COMPRESSED quarter { ENFORCE(reorder_ratio.UVALUE == REORDERING_QUARTER); master =:= lsb(k, ((2^k) / 4) - 1); } COMPRESSED half { ENFORCE(reorder_ratio.UVALUE == REORDERING_HALF); master =:= lsb(k, ((2^k) / 2) - 1); } COMPRESSED threequarters { ENFORCE(reorder_ratio.UVALUE == REORDERING_THREEQUARTERS); master =:= lsb(k, (((2^k) * 3) / 4) - 1); } } Pelletier & Sandlund Expires April 4, 2008 [Page 69] Internet-Draft ROHCv2 Profiles October 2007 ip_id_lsb(behavior, k) { UNCOMPRESSED { ip_id [ 16 ]; } CONTROL { ip_id_nbo [ 16 ]; } COMPRESSED nbo { ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL); ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE); ip_id_offset =:= lsb(k, ((2^k) / 4) - 1) [ k ]; } COMPRESSED non_nbo { ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED); ENFORCE(ip_id_nbo.UVALUE == (ip_id.UVALUE / 256) + (ip_id.UVALUE % 256) * 256); ENFORCE(ip_id_nbo.ULENGTH == 16); ENFORCE(ip_id_offset.UVALUE == ip_id_nbo.UVALUE - msn.UVALUE); ip_id_offset =:= lsb(k, ((2^k) / 4) - 1) [ k ]; } } ip_id_sequential_variable(behavior, indicator) { UNCOMPRESSED { ip_id [ 16 ]; } COMPRESSED short { ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); ENFORCE(indicator == 0); ip_id =:= ip_id_lsb(behavior, 8) [ 8 ]; } COMPRESSED long { ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) || (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); ENFORCE(indicator == 1); ENFORCE(ip_id_offset.UVALUE == ip_id.UVALUE - msn.UVALUE); ip_id =:= irregular(16) [ 16 ]; } COMPRESSED not_present { Pelletier & Sandlund Expires April 4, 2008 [Page 70] Internet-Draft ROHCv2 Profiles October 2007 ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) || (behavior == IP_ID_BEHAVIOR_ZERO)); } } dont_fragment(version) { UNCOMPRESSED { df [ 1 ]; } COMPRESSED v4 { ENFORCE(version == 4); df =:= irregular(1) [ 1 ]; } COMPRESSED v6 { ENFORCE(version == 6); unused =:= compressed_value(1, 0) [ 1 ]; } } pt_irr_or_static(flag) { UNCOMPRESSED { payload_type [ 7 ]; } COMPRESSED not_present { ENFORCE(flag == 0); payload_type =:= static [ 0 ]; } COMPRESSED present { ENFORCE(flag == 1); reserved =:= compressed_value(1, 0) [ 1 ]; payload_type =:= irregular(7) [ 7 ]; } } csrc_list_presence(presence, cc_value) { UNCOMPRESSED { csrc_list; } COMPRESSED no_list { ENFORCE(presence == 0); Pelletier & Sandlund Expires April 4, 2008 [Page 71] Internet-Draft ROHCv2 Profiles October 2007 csrc_list =:= static [ 0 ]; } COMPRESSED list_present { ENFORCE(presence == 1); csrc_list =:= list_csrc(cc_value) [ VARIABLE ]; } } scaled_ts_lsb(time_stride_value, k) { UNCOMPRESSED { timestamp [ 32 ]; } COMPRESSED timerbased { ENFORCE(time_stride_value != 0); timestamp =:= timer_based_lsb(time_stride_value, k, ((2^k) / 4) - 1); } COMPRESSED regular { ENFORCE(time_stride_value == 0); timestamp =:= lsb(k, ((2^k) / 4) - 1); } } // Self-describing variable length encoding with reordering offset sdvl_sn_lsb(field_width) { UNCOMPRESSED { field [ field_width ]; } COMPRESSED lsb7 { discriminator =:= '0' [ 1 ]; field =:= msn_lsb(7) [ 7 ]; } COMPRESSED lsb14 { discriminator =:= '10' [ 2 ]; field =:= msn_lsb(14) [ 14 ]; } COMPRESSED lsb21 { discriminator =:= '110' [ 3 ]; field =:= msn_lsb(21) [ 21 ]; } Pelletier & Sandlund Expires April 4, 2008 [Page 72] Internet-Draft ROHCv2 Profiles October 2007 COMPRESSED lsb28 { discriminator =:= '1110' [ 4 ]; field =:= msn_lsb(28) [ 28 ]; } COMPRESSED lsb32 { discriminator =:= '11111111' [ 8 ]; field =:= irregular(field_width) [ field_width ]; } } // Self-describing variable length encoding sdvl_lsb(field_width) { UNCOMPRESSED { field [ field_width ]; } COMPRESSED lsb7 { discriminator =:= '0' [ 1 ]; field =:= lsb(7, ((2^7) / 4) - 1) [ 7 ]; } COMPRESSED lsb14 { discriminator =:= '10' [ 2 ]; field =:= lsb(14, ((2^14) / 4) - 1) [ 14 ]; } COMPRESSED lsb21 { discriminator =:= '110' [ 3 ]; field =:= lsb(21, ((2^21) / 4) - 1) [ 21 ]; } COMPRESSED lsb28 { discriminator =:= '1110' [ 4 ]; field =:= lsb(28, ((2^28) / 4) - 1) [ 28 ]; } COMPRESSED lsb32 { discriminator =:= '11111111' [ 8 ]; field =:= irregular(field_width) [ field_width ]; } } variable_scaled_timestamp(tss_flag, tsc_flag, ts_stride) { UNCOMPRESSED { timestamp [ 32 ]; Pelletier & Sandlund Expires April 4, 2008 [Page 73] Internet-Draft ROHCv2 Profiles October 2007 } COMPRESSED present { ENFORCE((tss_flag == 0) && (tsc_flag == 1)); ENFORCE(ts_stride != 0); timestamp =:= sdvl_lsb(32) [ VARIABLE ]; } COMPRESSED not_present { ENFORCE(((tss_flag == 1) && (tsc_flag == 0)) || ((tss_flag == 0) && (tsc_flag == 0))); } } variable_unscaled_timestamp(tss_flag, tsc_flag) { UNCOMPRESSED { timestamp [ 32 ]; } COMPRESSED present { ENFORCE(((tss_flag == 1) && (tsc_flag == 0)) || ((tss_flag == 0) && (tsc_flag == 0))); timestamp =:= sdvl_lsb(32); } COMPRESSED not_present { ENFORCE((tss_flag == 0) && (tsc_flag == 1)); } } profile_1_7_flags1_enc(flag) { UNCOMPRESSED { ip_outer_indicator [ 1 ]; ttl_hopl_indicator [ 1 ]; tos_tc_indicator [ 1 ]; df [ 1 ]; ip_id_behavior [ 2 ]; reorder_ratio [ 2 ]; } COMPRESSED not_present { ENFORCE(flag == 0); ENFORCE(ip_outer_indicator.CVALUE == 0); ENFORCE(ttl_hopl_indicator.CVALUE == 0); ENFORCE(tos_tc_indicator.CVALUE == 0); df =:= static; Pelletier & Sandlund Expires April 4, 2008 [Page 74] Internet-Draft ROHCv2 Profiles October 2007 ip_id_behavior =:= static; reorder_ratio =:= static; } COMPRESSED present { ENFORCE(flag == 1); ip_outer_indicator =:= irregular(1) [ 1 ]; ttl_hopl_indicator =:= irregular(1) [ 1 ]; tos_tc_indicator =:= irregular(1) [ 1 ]; df =:= dont_fragment(ip_version) [ 1 ]; ip_id_behavior =:= ip_id_behavior_choice(1) [ 2 ]; reorder_ratio =:= reorder_choice [ 2 ]; } } profile_1_flags2_enc(flag, ip_version) { UNCOMPRESSED { list_indicator [ 1 ]; pt_indicator [ 1 ]; pad_bit [ 1 ]; extension [ 1 ]; time_stride_indicator [ 1 ]; } COMPRESSED not_present{ ENFORCE(flag == 0); ENFORCE(list_indicator.UVALUE == 0); ENFORCE(pt_indicator.UVALUE == 0); ENFORCE(time_stride_indicator.UVALUE == 0); pad_bit =:= static; extension =:= static; } COMPRESSED present { ENFORCE(flag == 1); list_indicator =:= irregular(1) [ 1 ]; pt_indicator =:= irregular(1) [ 1 ]; time_stride_indicator =:= irregular(1) [ 1 ]; pad_bit =:= irregular(1) [ 1 ]; extension =:= irregular(1) [ 1 ]; reserved =:= compressed_value(3, 0) [ 3 ]; } } profile_2_3_4_flags_enc(flag, ip_version) { UNCOMPRESSED { Pelletier & Sandlund Expires April 4, 2008 [Page 75] Internet-Draft ROHCv2 Profiles October 2007 ip_outer_indicator [ 1 ]; df [ 1 ]; ip_id_behavior [ 2 ]; } COMPRESSED not_present { ENFORCE(flag == 0); ENFORCE(ip_outer_indicator.CVALUE == 0); df =:= static; ip_id_behavior =:= static; } COMPRESSED present { ENFORCE(flag == 1); ip_outer_indicator =:= irregular(1) [ 1 ]; df =:= dont_fragment(ip_version) [ 1 ]; ip_id_behavior =:= ip_id_behavior_choice(1) [ 2 ]; reserved =:= compressed_value(4, 0) [ 4 ]; } } profile_8_flags_enc(flag, ip_version) { UNCOMPRESSED { ip_outer_indicator [ 1 ]; df [ 1 ]; ip_id_behavior [ 2 ]; coverage_behavior [ 2 ]; } COMPRESSED not_present { ENFORCE(flag == 0); ENFORCE(ip_outer_indicator.CVALUE == 0); df =:= static; ip_id_behavior =:= static; coverage_behavior =:= static; } COMPRESSED present { ENFORCE(flag == 1); reserved =:= compressed_value(2, 0) [ 2 ]; ip_outer_indicator =:= irregular(1) [ 1 ]; df =:= dont_fragment(ip_version) [ 1 ]; ip_id_behavior =:= ip_id_behavior_choice(1) [ 2 ]; coverage_behavior =:= irregular(2) [ 2 ]; } } Pelletier & Sandlund Expires April 4, 2008 [Page 76] Internet-Draft ROHCv2 Profiles October 2007 profile_7_flags2_enc(flag, ip_version) { UNCOMPRESSED { list_indicator [ 1 ]; pt_indicator [ 1 ]; time_stride_indicator [ 1 ]; pad_bit [ 1 ]; extension [ 1 ]; coverage_behavior [ 2 ]; } COMPRESSED not_present{ ENFORCE(flag == 0); ENFORCE(list_indicator.CVALUE == 0); ENFORCE(pt_indicator.CVALUE == 0); ENFORCE(time_stride_indicator.CVALUE == 0); pad_bit =:= static; extension =:= static; coverage_behavior =:= static; } COMPRESSED present { ENFORCE(flag == 1); reserved =:= compressed_value(1, 0) [ 1 ]; list_indicator =:= irregular(1) [ 1 ]; pt_indicator =:= irregular(1) [ 1 ]; time_stride_indicator =:= irregular(1) [ 1 ]; pad_bit =:= irregular(1) [ 1 ]; extension =:= irregular(1) [ 1 ]; coverage_behavior =:= irregular(2) [ 2 ]; } } //////////////////////////////////////////// // RTP profile //////////////////////////////////////////// rtp_baseheader(profile, ts_stride_value, time_stride_value, outer_ip_flag) { UNCOMPRESSED v4 { ENFORCE(msn.UVALUE == sequence_number.UVALUE); outer_headers =:= baseheader_outer_headers [ VARIABLE ]; ip_version =:= uncompressed_value(4, 4) [ 4 ]; header_length =:= uncompressed_value(4, 5) [ 4 ]; tos_tc [ 8 ]; length =:= inferred_ip_v4_length [ 16 ]; ip_id [ 16 ]; Pelletier & Sandlund Expires April 4, 2008 [Page 77] Internet-Draft ROHCv2 Profiles October 2007 rf =:= uncompressed_value(1, 0) [ 1 ]; df [ 1 ]; mf =:= uncompressed_value(1, 0) [ 1 ]; frag_offset =:= uncompressed_value(13, 0) [ 13 ]; ttl_hopl [ 8 ]; next_header [ 8 ]; ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ]; src_addr [ 32 ]; dest_addr [ 32 ]; extension_headers =:= baseheader_extension_headers [ VARIABLE ]; src_port [ 16 ]; dst_port [ 16 ]; udp_length =:= inferred_udp_length [ 16 ]; udp_checksum [ 16 ]; rtp_version =:= uncompressed_value(2, 2) [ 2 ]; pad_bit [ 1 ]; extension [ 1 ]; cc [ 4 ]; marker [ 1 ]; payload_type [ 7 ]; sequence_number [ 16 ]; timestamp [ 32 ]; ssrc [ 32 ]; csrc_list [ VARIABLE ]; } UNCOMPRESSED v6 { ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM); ENFORCE(msn.UVALUE == sequence_number.UVALUE); outer_headers =:= baseheader_outer_headers [ VARIABLE ]; ip_version =:= uncompressed_value(4, 6) [ 4 ]; tos_tc [ 8 ]; flow_label [ 20 ]; payload_length =:= inferred_ip_v6_length [ 16 ]; next_header [ 8 ]; ttl_hopl [ 8 ]; src_addr [ 128 ]; dest_addr [ 128 ]; extension_headers =:= baseheader_extension_headers [ VARIABLE ]; src_port [ 16 ]; dst_port [ 16 ]; udp_length =:= inferred_udp_length [ 16 ]; udp_checksum [ 16 ]; rtp_version =:= uncompressed_value(2, 2) [ 2 ]; pad_bit [ 1 ]; extension [ 1 ]; cc [ 4 ]; marker [ 1 ]; Pelletier & Sandlund Expires April 4, 2008 [Page 78] Internet-Draft ROHCv2 Profiles October 2007 payload_type [ 7 ]; sequence_number [ 16 ]; timestamp [ 32 ]; ssrc [ 32 ]; csrc_list [ VARIABLE ]; df =:= uncompressed_value(0,0) [ 0 ]; ip_id =:= uncompressed_value(0,0) [ 0 ]; } CONTROL { ENFORCE(time_stride.UVALUE == time_stride_value); ENFORCE(ts_stride.UVALUE == ts_stride_value); ENFORCE(profile == PROFILE_RTP_0101); ts_stride [ 32 ]; time_stride [ 32 ]; ts_scaled [ 32 ]; ts_offset =:= field_scaling(ts_stride.UVALUE, ts_scaled.UVALUE, timestamp.UVALUE) [ 32 ]; ip_id_behavior [ 2 ]; } INITIAL { ts_stride =:= uncompressed_value(32, TS_STRIDE_DEFAULT); time_stride =:= uncompressed_value(32, TIME_STRIDE_DEFAULT); } DEFAULT { ENFORCE(outer_ip_flag == 0); tos_tc =:= static; dest_addr =:= static; ttl_hopl =:= static; src_addr =:= static; df =:= static; ip_id_behavior =:= static; flow_label =:= static; next_header =:= static; src_port =:= static; dst_port =:= static; pad_bit =:= static; extension =:= static; cc =:= static; // When marker not present in packets, it is assumed 0 marker =:= uncompressed_value(1, 0); payload_type =:= static; sequence_number =:= static; timestamp =:= static; ssrc =:= static; csrc_list =:= static; Pelletier & Sandlund Expires April 4, 2008 [Page 79] Internet-Draft ROHCv2 Profiles October 2007 } // Replacement for UOR-2-ext3 COMPRESSED co_common { ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE); discriminator =:= '11111010' [ 8 ]; marker =:= irregular(1) [ 1 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; flags1_indicator =:= irregular(1) [ 1 ]; flags2_indicator =:= irregular(1) [ 1 ]; tsc_indicator =:= irregular(1) [ 1 ]; tss_indicator =:= irregular(1) [ 1 ]; ip_id_indicator =:= irregular(1) [ 1 ]; control_crc3 =:= control_crc3_encoding [ 3 ]; outer_ip_indicator : ttl_hopl_indicator : tos_tc_indicator : ip_id_behavior : reorder_ratio =:= profile_1_7_flags1_enc(flags1_indicator.CVALUE) [ 0, 8 ]; list_indicator : pt_indicator : tis_indicator :pad_bit : extension : df =:= profile_1_flags2_enc(flags2_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ]; tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ]; ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE, ttl_hopl.ULENGTH) [ 0, 8 ]; payload_type =:= pt_irr_or_static(pt_indicator) [ 0, 8 ]; sequence_number =:= sdvl_sn_lsb(sequence_number.ULENGTH) [ VARIABLE ]; ip_id =:= ip_id_sequential_variable(ip_id_behavior.UVALUE, ip_id_indicator.CVALUE) [ 0, 8, 16 ]; ts_scaled =:= variable_scaled_timestamp(tss_indicator.CVALUE, tsc_indicator, ts_stride.UVALUE) [ VARIABLE ]; timestamp =:= variable_unscaled_timestamp(tss_indicator.CVALUE, tsc_indicator) [ VARIABLE ]; ts_stride =:= sdvl_or_static(tss_indicator.CVALUE) [ VARIABLE ]; time_stride =:= sdvl_or_static(tis_indicator.CVALUE) [ VARIABLE ]; csrc_list =:= csrc_list_presence(list_indicator.CVALUE, cc.UVALUE) [ VARIABLE ]; } // UO-0 COMPRESSED pt_0_crc3 { discriminator =:= '0' [ 1 ]; msn =:= msn_lsb(4) [ 4 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; timestamp =:= inferred_scaled_field [ 0 ]; ip_id =:= inferred_sequential_ip_id [ 0 ]; } Pelletier & Sandlund Expires April 4, 2008 [Page 80] Internet-Draft ROHCv2 Profiles October 2007 // New format, Type 0 with strong CRC and more SN bits COMPRESSED pt_0_crc7 { discriminator =:= '1000' [ 4 ]; msn =:= msn_lsb(5) [ 5 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; timestamp =:= inferred_scaled_field [ 0 ]; ip_id =:= inferred_sequential_ip_id [ 0 ]; } // UO-1 replacement COMPRESSED pt_1_rnd { ENFORCE(ts_stride.UVALUE != 0); ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); discriminator =:= '101' [ 3 ]; msn =:= msn_lsb(4) [ 4 ]; marker =:= irregular(1) [ 1 ]; ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; } // UO-1-ID replacement COMPRESSED pt_1_seq_id { ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '1001' [ 4 ]; ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4) [ 4 ]; msn =:= msn_lsb(5) [ 5 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; timestamp =:= inferred_scaled_field [ 0 ]; } // UO-1-TS replacement COMPRESSED pt_1_seq_ts { ENFORCE(ts_stride.UVALUE != 0); ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '101' [ 3 ]; marker =:= irregular(1) [ 1 ]; msn =:= msn_lsb(4) [ 4 ]; ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; } // UOR-2 replacement COMPRESSED pt_2_rnd { Pelletier & Sandlund Expires April 4, 2008 [Page 81] Internet-Draft ROHCv2 Profiles October 2007 ENFORCE(ts_stride.UVALUE != 0); ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); discriminator =:= '110' [ 3 ]; msn =:= msn_lsb(7) [ 7 ]; ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 6) [ 6 ]; marker =:= irregular(1) [ 1 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; } // UOR-2-ID replacement COMPRESSED pt_2_seq_id { ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '11000' [ 5 ]; msn =:= msn_lsb(7) [ 7 ]; ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; timestamp =:= inferred_scaled_field [ 0 ]; } // UOR-2-ID-ext1 replacement (both TS and IP-ID) COMPRESSED pt_2_seq_both { ENFORCE(ts_stride.UVALUE != 0); ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '11001' [ 5 ]; msn =:= msn_lsb(7) [ 7 ]; ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 8) [ 8 ]; } // UOR-2-TS replacement COMPRESSED pt_2_seq_ts { ENFORCE(ts_stride.UVALUE != 0); ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '1101' [ 4 ]; msn =:= msn_lsb(7) [ 7 ]; ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ]; marker =:= irregular(1) [ 1 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; } } Pelletier & Sandlund Expires April 4, 2008 [Page 82] Internet-Draft ROHCv2 Profiles October 2007 //////////////////////////////////////////// // UDP profile //////////////////////////////////////////// udp_baseheader(profile, outer_ip_flag) { UNCOMPRESSED v4 { outer_headers =:= baseheader_outer_headers [ VARIABLE ]; ip_version =:= uncompressed_value(4, 4) [ 4 ]; header_length =:= uncompressed_value(4, 5) [ 4 ]; tos_tc [ 8 ]; length =:= inferred_ip_v4_length [ 16 ]; ip_id [ 16 ]; rf =:= uncompressed_value(1, 0) [ 1 ]; df [ 1 ]; mf =:= uncompressed_value(1, 0) [ 1 ]; frag_offset =:= uncompressed_value(13, 0) [ 13 ]; ttl_hopl [ 8 ]; next_header [ 8 ]; ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ]; src_addr [ 32 ]; dest_addr [ 32 ]; extension_headers =:= baseheader_extension_headers [ VARIABLE ]; src_port [ 16 ]; dst_port [ 16 ]; udp_length =:= inferred_udp_length [ 16 ]; udp_checksum [ 16 ]; } UNCOMPRESSED v6 { ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM); outer_headers =:= baseheader_outer_headers [ VARIABLE ]; ip_version =:= uncompressed_value(4, 6) [ 4 ]; tos_tc [ 8 ]; flow_label [ 20 ]; payload_length =:= inferred_ip_v6_length [ 16 ]; next_header [ 8 ]; ttl_hopl [ 8 ]; src_addr [ 128 ]; dest_addr [ 128 ]; extension_headers =:= baseheader_extension_headers [ VARIABLE ]; src_port [ 16 ]; dst_port [ 16 ]; udp_length =:= inferred_udp_length [ 16 ]; udp_checksum [ 16 ]; df =:= uncompressed_value(0,0) [ 0 ]; ip_id =:= uncompressed_value(0,0) [ 0 ]; } Pelletier & Sandlund Expires April 4, 2008 [Page 83] Internet-Draft ROHCv2 Profiles October 2007 CONTROL { ENFORCE(profile == PROFILE_UDP_0102); ip_id_behavior [ 2 ]; } DEFAULT { ENFORCE(outer_ip_flag == 0); tos_tc =:= static; dest_addr =:= static; ip_version =:= static; ttl_hopl =:= static; src_addr =:= static; df =:= static; ip_id_behavior =:= static; flow_label =:= static; next_header =:= static; src_port =:= static; dst_port =:= static; } // Replacement for UOR-2-ext3 COMPRESSED co_common { ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE); discriminator =:= '11111010' [ 8 ]; ip_id_indicator =:= irregular(1) [ 1 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; flags_indicator =:= irregular(1) [ 1 ]; ttl_hopl_indicator =:= irregular(1) [ 1 ]; tos_tc_indicator =:= irregular(1) [ 1 ]; reorder_ratio =:= reorder_choice [ 2 ]; control_crc3 =:= control_crc3_encoding [ 3 ]; outer_ip_indicator : df : ip_id_behavior =:= profile_2_3_4_flags_enc( flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ]; tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ]; ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE, ttl_hopl.ULENGTH) [ 0, 8 ]; msn =:= msn_lsb(8) [ 8 ]; ip_id =:= ip_id_sequential_variable(ip_id_behavior.UVALUE, ip_id_indicator.CVALUE) [ 0, 8, 16 ]; } // UO-0 COMPRESSED pt_0_crc3 { discriminator =:= '0' [ 1 ]; msn =:= msn_lsb(4) [ 4 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; ip_id =:= inferred_sequential_ip_id [ 0 ]; Pelletier & Sandlund Expires April 4, 2008 [Page 84] Internet-Draft ROHCv2 Profiles October 2007 } // New format, Type 0 with strong CRC and more SN bits COMPRESSED pt_0_crc7 { discriminator =:= '100' [ 3 ]; msn =:= msn_lsb(6) [ 6 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; ip_id =:= inferred_sequential_ip_id [ 0 ]; } // UO-1-ID replacement (PT-1 only used for sequential) COMPRESSED pt_1_seq_id { ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '101' [ 3 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; msn =:= msn_lsb(6) [ 6 ]; ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4) [ 4 ]; } // UOR-2 replacement COMPRESSED pt_2_rnd { ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); discriminator =:= '110' [ 3 ]; msn =:= msn_lsb(6) [ 6 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; } // UOR-2-ID replacement COMPRESSED pt_2_seq_id { ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '1100' [ 4 ]; ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; msn =:= msn_lsb(8) [ 8 ]; } } //////////////////////////////////////////// // ESP profile //////////////////////////////////////////// esp_baseheader(profile, outer_ip_flag) { Pelletier & Sandlund Expires April 4, 2008 [Page 85] Internet-Draft ROHCv2 Profiles October 2007 UNCOMPRESSED v4 { ENFORCE(msn.UVALUE == sequence_number.UVALUE % 65536); outer_headers =:= baseheader_outer_headers [ VARIABLE ]; ip_version =:= uncompressed_value(4, 4) [ 4 ]; header_length =:= uncompressed_value(4, 5) [ 4 ]; tos_tc [ 8 ]; length =:= inferred_ip_v4_length [ 16 ]; ip_id [ 16 ]; rf =:= uncompressed_value(1, 0) [ 1 ]; df [ 1 ]; mf =:= uncompressed_value(1, 0) [ 1 ]; frag_offset =:= uncompressed_value(13, 0) [ 13 ]; ttl_hopl [ 8 ]; next_header [ 8 ]; ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ]; src_addr [ 32 ]; dest_addr [ 32 ]; extension_headers =:= baseheader_extension_headers [ VARIABLE ]; spi [ 32 ]; sequence_number [ 32 ]; } UNCOMPRESSED v6 { ENFORCE(msn.UVALUE == (sequence_number.UVALUE % 65536)); ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM); outer_headers =:= baseheader_outer_headers [ VARIABLE ]; ip_version =:= uncompressed_value(4, 6) [ 4 ]; tos_tc [ 8 ]; flow_label [ 20 ]; payload_length =:= inferred_ip_v6_length [ 16 ]; next_header [ 8 ]; ttl_hopl [ 8 ]; src_addr [ 128 ]; dest_addr [ 128 ]; extension_headers =:= baseheader_extension_headers [ VARIABLE ]; spi [ 32 ]; sequence_number [ 32 ]; df =:= uncompressed_value(0,0) [ 0 ]; ip_id =:= uncompressed_value(0,0) [ 0 ]; } CONTROL { ENFORCE(profile == PROFILE_ESP_0103); ip_id_behavior [ 2 ]; } DEFAULT { ENFORCE(outer_ip_indicator == 0); Pelletier & Sandlund Expires April 4, 2008 [Page 86] Internet-Draft ROHCv2 Profiles October 2007 tos_tc =:= static; dest_addr =:= static; ttl_hopl =:= static; src_addr =:= static; df =:= static; ip_id_behavior =:= static; flow_label =:= static; next_header =:= static; spi =:= static; sequence_number =:= static; } // Replacement for UOR-2-ext3 COMPRESSED co_common { ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE); discriminator =:= '11111010' [ 8 ]; ip_id_indicator =:= irregular(1) [ 1 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; flags_indicator =:= irregular(1) [ 1 ]; ttl_hopl_indicator =:= irregular(1) [ 1 ]; tos_tc_indicator =:= irregular(1) [ 1 ]; reorder_ratio =:= reorder_choice [ 2 ]; control_crc3 =:= control_crc3_encoding [ 3 ]; outer_ip_indicator : df : ip_id_behavior =:= profile_2_3_4_flags_enc( flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ]; tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ]; ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE, ttl_hopl.ULENGTH) [ 0, 8 ]; sequence_number =:= sdvl_sn_lsb(sequence_number.ULENGTH) [ VARIABLE ]; ip_id =:= ip_id_sequential_variable(ip_id_behavior.UVALUE, ip_id_indicator.CVALUE) [ 0, 8, 16 ]; } // Sequence number sent instead of MSN due to field length // UO-0 COMPRESSED pt_0_crc3 { discriminator =:= '0' [ 1 ]; sequence_number =:= msn_lsb(4) [ 4 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; ip_id =:= inferred_sequential_ip_id [ 0 ]; } // New format, Type 0 with strong CRC and more SN bits COMPRESSED pt_0_crc7 { discriminator =:= '100' [ 3 ]; Pelletier & Sandlund Expires April 4, 2008 [Page 87] Internet-Draft ROHCv2 Profiles October 2007 sequence_number =:= msn_lsb(6) [ 6 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; ip_id =:= inferred_sequential_ip_id [ 0 ]; } // UO-1-ID replacement (PT-1 only used for sequential) COMPRESSED pt_1_seq_id { ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminato =:= '101' [ 3 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; sequence_number =:= msn_lsb(6) [ 6 ]; ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4) [ 4 ]; } // UOR-2 replacement COMPRESSED pt_2_rnd { ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); discriminator =:= '110' [ 3 ]; sequence_number =:= msn_lsb(6) [ 6 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; } // UOR-2-ID replacement COMPRESSED pt_2_seq_id { ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '1100' [ 4 ]; ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; sequence_number =:= msn_lsb(8) [ 8 ]; } } //////////////////////////////////////////// // IP-only profile //////////////////////////////////////////// iponly_baseheader(profile, outer_ip_flag) { UNCOMPRESSED v4 { outer_headers =:= baseheader_outer_headers [ VARIABLE ]; ip_version =:= uncompressed_value(4, 4) [ 4 ]; header_length =:= uncompressed_value(4, 5) [ 4 ]; tos_tc [ 8 ]; Pelletier & Sandlund Expires April 4, 2008 [Page 88] Internet-Draft ROHCv2 Profiles October 2007 length =:= inferred_ip_v4_length [ 16 ]; ip_id [ 16 ]; rf =:= uncompressed_value(1, 0) [ 1 ]; df [ 1 ]; mf =:= uncompressed_value(1, 0) [ 1 ]; frag_offset =:= uncompressed_value(13, 0) [ 13 ]; ttl_hopl [ 8 ]; next_header [ 8 ]; ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ]; src_addr [ 32 ]; dest_addr [ 32 ]; extension_headers =:= baseheader_extension_headers [ VARIABLE ]; } UNCOMPRESSED v6 { ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM); outer_headers =:= baseheader_outer_headers [ VARIABLE ]; ip_version =:= uncompressed_value(4, 6) [ 4 ]; tos_tc [ 8 ]; flow_label [ 20 ]; payload_length =:= inferred_ip_v6_length [ 16 ]; next_header [ 8 ]; ttl_hopl [ 8 ]; src_addr [ 128 ]; dest_addr [ 128 ]; extension_headers =:= baseheader_extension_headers [ VARIABLE ]; df =:= uncompressed_value(0,0) [ 0 ]; ip_id =:= uncompressed_value(0,0) [ 0 ]; } CONTROL { ENFORCE(profile == PROFILE_IP_0104); ip_id_behavior [ 2 ]; } DEFAULT { ENFORCE(outer_ip_indicator == 0); tos_tc =:= static; dest_addr =:= static; ttl_hopl =:= static; src_addr =:= static; df =:= static; ip_id_behavior =:= static; flow_label =:= static; next_header =:= static; } // Replacement for UOR-2-ext3 Pelletier & Sandlund Expires April 4, 2008 [Page 89] Internet-Draft ROHCv2 Profiles October 2007 COMPRESSED co_common { ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE); discriminator =:= '11111010' [ 8 ]; ip_id_indicator =:= irregular(1) [ 1 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; flags_indicator =:= irregular(1) [ 1 ]; ttl_hopl_indicator =:= irregular(1) [ 1 ]; tos_tc_indicator =:= irregular(1) [ 1 ]; reorder_ratio =:= reorder_choice [ 2 ]; control_crc3 =:= control_crc3_encoding [ 3 ]; outer_ip_indicator : df : ip_id_behavior =:= profile_2_3_4_flags_enc( flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ]; tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ]; ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE, ttl_hopl.ULENGTH) [ 0, 8 ]; msn =:= msn_lsb(8) [ 8 ]; ip_id =:= ip_id_sequential_variable(ip_id_behavior.UVALUE, ip_id_indicator.CVALUE) [ 0, 8, 16 ]; } // UO-0 COMPRESSED pt_0_crc3 { discriminator =:= '0' [ 1 ]; msn =:= msn_lsb(4) [ 4 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; ip_id =:= inferred_sequential_ip_id [ 0 ]; } // New format, Type 0 with strong CRC and more SN bits COMPRESSED pt_0_crc7 { discriminator =:= '100' [ 3 ]; msn =:= msn_lsb(6) [ 6 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; ip_id =:= inferred_sequential_ip_id [ 0 ]; } // UO-1-ID replacement (PT-1 only used for sequential) COMPRESSED pt_1_seq_id { ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '101' [ 3 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; msn =:= msn_lsb(6) [ 6 ]; ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4) [ 4 ]; } Pelletier & Sandlund Expires April 4, 2008 [Page 90] Internet-Draft ROHCv2 Profiles October 2007 // UOR-2 replacement COMPRESSED pt_2_rnd { ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); discriminator =:= '110' [ 3 ]; msn =:= msn_lsb(6) [ 6 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; } // UOR-2-ID replacement COMPRESSED pt_2_seq_id { ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '1100' [ 4 ]; ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; msn =:= msn_lsb(8) [ 8 ]; } } //////////////////////////////////////////// // UDP-lite/RTP profile //////////////////////////////////////////// udplite_rtp_baseheader(profile, ts_stride_value, time_stride_value, outer_ip_flag) { UNCOMPRESSED v4 { ENFORCE(msn.UVALUE == sequence_number.UVALUE); outer_headers =:= baseheader_outer_headers [ VARIABLE ]; ip_version =:= uncompressed_value(4, 4) [ 4 ]; header_length =:= uncompressed_value(4, 5) [ 4 ]; tos_tc [ 8 ]; length =:= inferred_ip_v4_length [ 16 ]; ip_id [ 16 ]; rf =:= uncompressed_value(1, 0) [ 1 ]; df [ 1 ]; mf =:= uncompressed_value(1, 0) [ 1 ]; frag_offset =:= uncompressed_value(13, 0) [ 13 ]; ttl_hopl [ 8 ]; next_header [ 8 ]; ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ]; src_addr [ 32 ]; dest_addr [ 32 ]; extension_headers =:= baseheader_extension_headers [ VARIABLE ]; src_port [ 16 ]; dst_port [ 16 ]; Pelletier & Sandlund Expires April 4, 2008 [Page 91] Internet-Draft ROHCv2 Profiles October 2007 checksum_coverage [ 16 ]; udp_checksum [ 16 ]; rtp_version =:= uncompressed_value(2, 2) [ 2 ]; pad_bit [ 1 ]; extension [ 1 ]; cc [ 4 ]; marker [ 1 ]; payload_type [ 7 ]; sequence_number [ 16 ]; timestamp [ 32 ]; ssrc [ 32 ]; csrc_list [ VARIABLE ]; } UNCOMPRESSED v6 { ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM); outer_headers =:= baseheader_outer_headers [ VARIABLE ]; ip_version =:= uncompressed_value(4, 6) [ 4 ]; tos_tc [ 8 ]; flow_label [ 20 ]; payload_length =:= inferred_ip_v6_length [ 16 ]; next_header [ 8 ]; ttl_hopl [ 8 ]; src_addr [ 128 ]; dest_addr [ 128 ]; extension_headers =:= baseheader_extension_headers [ VARIABLE ]; src_port [ 16 ]; dst_port [ 16 ]; checksum_coverage [ 16 ]; udp_checksum [ 16 ]; rtp_version =:= uncompressed_value(2, 2) [ 2 ]; pad_bit [ 1 ]; extension [ 1 ]; cc [ 4 ]; marker [ 1 ]; payload_type [ 7 ]; sequence_number [ 16 ]; timestamp [ 32 ]; ssrc [ 32 ]; csrc_list [ VARIABLE ]; df =:= uncompressed_value(0,0) [ 0 ]; ip_id =:= uncompressed_value(0,0) [ 0 ]; } CONTROL { ENFORCE(time_stride.UVALUE == time_stride_value); ENFORCE(ts_stride.UVALUE == ts_stride_value); ENFORCE(profile == PROFILE_RTP_0107); Pelletier & Sandlund Expires April 4, 2008 [Page 92] Internet-Draft ROHCv2 Profiles October 2007 ip_id_behavior [ 2 ]; coverage_behavior [ 2 ]; ts_stride [ 32 ]; time_stride [ 32 ]; ts_scaled [ 32 ]; ts_offset =:= field_scaling(ts_stride.UVALUE, ts_scaled.UVALUE, timestamp.UVALUE) [ 32 ]; } DEFAULT { ENFORCE(outer_ip_indicator == 0); tos_tc =:= static; dest_addr =:= static; ttl_hopl =:= static; src_addr =:= static; df =:= static; ip_id_behavior =:= static; flow_label =:= static; next_header =:= static; src_port =:= static; dst_port =:= static; pad_bit =:= static; extension =:= static; cc =:= static; // When marker not present in packets, it is assumed 0 marker =:= uncompressed_value(1, 0); payload_type =:= static; sequence_number =:= static; timestamp =:= static; ssrc =:= static; csrc_list =:= static; } // Replacement for UOR-2-ext3 COMPRESSED co_common { ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE); discriminator =:= '11111010' [ 8 ]; marker =:= irregular(1) [ 1 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; flags1_indicator =:= irregular(1) [ 1 ]; flags2_indicator =:= irregular(1) [ 1 ]; tsc_indicator =:= irregular(1) [ 1 ]; tss_indicator =:= irregular(1) [ 1 ]; ip_id_indicator =:= irregular(1) [ 1 ]; control_crc3 =:= control_crc3_encoding [ 3 ]; outer_ip_indicator : ttl_hopl_indicator : tos_tc_indicator : ip_id_behavior : reorder_ratio =:= Pelletier & Sandlund Expires April 4, 2008 [Page 93] Internet-Draft ROHCv2 Profiles October 2007 profile_1_7_flags1_enc(flags1_indicator.CVALUE) [ 0, 8 ]; list_indicator : tis_indicator : pt_indicator : pad_bit : extension : df : coverage_behavior =:= profile_7_flags2_enc(flags2_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ]; tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ]; ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE, ttl_hopl.ULENGTH) [ 0, 8 ]; payload_type =:= pt_irr_or_static(pt_indicator.CVALUE) [ 0, 8 ]; sequence_number =:= sdvl_sn_lsb(sequence_number.ULENGTH) [ VARIABLE ]; ip_id =:= ip_id_sequential_variable(ip_id_behavior.UVALUE, ip_id_indicator.CVALUE) [ 0, 8, 16 ]; ts_scaled =:= variable_scaled_timestamp(tss_indicator.CVALUE, tsc_indicator.CVALUE, ts_stride.UVALUE) [ VARIABLE ]; timestamp =:= variable_unscaled_timestamp(tss_indicator.CVALUE, tsc_indicator.CVALUE) [ VARIABLE ]; ts_stride =:= sdvl_or_static(tss_indicator.CVALUE) [ VARIABLE ]; time_stride =:= sdvl_or_static(tis_indicator.CVALUE) [ VARIABLE ]; csrc_list =:= csrc_list_presence(list_indicator.CVALUE, cc.UVALUE) [ VARIABLE ]; } // UO-0 COMPRESSED pt_0_crc3 { discriminator =:= '0' [ 1 ]; msn =:= msn_lsb(4) [ 4 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; timestamp =:= inferred_scaled_field [ 0 ]; ip_id =:= inferred_sequential_ip_id [ 0 ]; } // New format, Type 0 with strong CRC and more SN bits COMPRESSED pt_0_crc7 { discriminator =:= '1000' [ 4 ]; msn =:= msn_lsb(5) [ 5 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; timestamp =:= inferred_scaled_field [ 0 ]; ip_id =:= inferred_sequential_ip_id [ 0 ]; } // UO-1 replacement COMPRESSED pt_1_rnd { ENFORCE(ts_stride.UVALUE != 0); ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); discriminator =:= '101' [ 3 ]; Pelletier & Sandlund Expires April 4, 2008 [Page 94] Internet-Draft ROHCv2 Profiles October 2007 msn =:= msn_lsb(4) [ 4 ]; marker =:= irregular(1) [ 1 ]; ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; } // UO-1-ID replacement COMPRESSED pt_1_seq_id { ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '1001' [ 4 ]; ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4) [ 4 ]; msn =:= msn_lsb(5) [ 5 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; timestamp =:= inferred_scaled_field [ 0 ]; } // UO-1-TS replacement COMPRESSED pt_1_seq_ts { ENFORCE(ts_stride.UVALUE != 0); ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '101' [ 3 ]; marker =:= irregular(1) [ 1 ]; msn =:= msn_lsb(4) [ 4 ]; ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; } // UOR-2 replacement COMPRESSED pt_2_rnd { ENFORCE(ts_stride.UVALUE != 0); ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); discriminator =:= '110' [ 3 ]; msn =:= msn_lsb(7) [ 7 ]; ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 6) [ 6 ]; marker =:= irregular(1) [ 1 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; } // UOR-2-ID replacement COMPRESSED pt_2_seq_id { ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); Pelletier & Sandlund Expires April 4, 2008 [Page 95] Internet-Draft ROHCv2 Profiles October 2007 discriminator =:= '11000' [ 5 ]; msn =:= msn_lsb(7) [ 7 ]; ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; timestamp =:= inferred_scaled_field [ 0 ]; } // UOR-2-ID-ext1 replacement (both TS and IP-ID) COMPRESSED pt_2_seq_both { ENFORCE(ts_stride.UVALUE != 0); ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '11001' [ 5 ]; msn =:= msn_lsb(7) [ 7 ]; ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 8) [ 8 ]; } // UOR-2-TS replacement COMPRESSED pt_2_seq_ts { ENFORCE(ts_stride.UVALUE != 0); ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '1101' [ 4 ]; msn =:= msn_lsb(7) [ 7 ]; ts_scaled =:= scaled_ts_lsb(time_stride.UVALUE, 5) [ 5 ]; marker =:= irregular(1) [ 1 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; } } //////////////////////////////////////////// // UDP-lite profile //////////////////////////////////////////// udplite_baseheader(profile, outer_ip_flag) { UNCOMPRESSED v4 { outer_headers =:= baseheader_outer_headers [ VARIABLE ]; ip_version =:= uncompressed_value(4, 4) [ 4 ]; header_length =:= uncompressed_value(4, 5) [ 4 ]; tos_tc [ 8 ]; length =:= inferred_ip_v4_length [ 16 ]; ip_id [ 16 ]; rf =:= uncompressed_value(1, 0) [ 1 ]; Pelletier & Sandlund Expires April 4, 2008 [Page 96] Internet-Draft ROHCv2 Profiles October 2007 df [ 1 ]; mf =:= uncompressed_value(1, 0) [ 1 ]; frag_offset =:= uncompressed_value(13, 0) [ 13 ]; ttl_hopl [ 8 ]; next_header [ 8 ]; ip_checksum =:= inferred_ip_v4_header_checksum [ 16 ]; src_addr [ 32 ]; dest_addr [ 32 ]; extension_headers =:= baseheader_extension_headers [ VARIABLE ]; src_port [ 16 ]; dst_port [ 16 ]; checksum_coverage [ 16 ]; udp_checksum [ 16 ]; } UNCOMPRESSED v6 { ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM); outer_headers =:= baseheader_outer_headers [ VARIABLE ]; ip_version =:= uncompressed_value(4, 6) [ 4 ]; tos_tc [ 8 ]; flow_label [ 20 ]; payload_length =:= inferred_ip_v6_length [ 16 ]; next_header [ 8 ]; ttl_hopl [ 8 ]; src_addr [ 128 ]; dest_addr [ 128 ]; extension_headers =:= baseheader_extension_headers [ VARIABLE ]; src_port [ 16 ]; dst_port [ 16 ]; checksum_coverage [ 16 ]; udp_checksum [ 16 ]; df =:= uncompressed_value(0,0) [ 0 ]; ip_id =:= uncompressed_value(0,0) [ 0 ]; } CONTROL { ENFORCE(profile == PROFILE_UDPLITE_0108); ip_id_behavior [ 2 ]; coverage_behavior [ 2 ]; } DEFAULT { ENFORCE(outer_ip_indicator == 0); tos_tc =:= static; dest_addr =:= static; ttl_hopl =:= static; src_addr =:= static; df =:= static; Pelletier & Sandlund Expires April 4, 2008 [Page 97] Internet-Draft ROHCv2 Profiles October 2007 ip_id_behavior =:= static; flow_label =:= static; next_header =:= static; src_port =:= static; dst_port =:= static; } // Replacement for UOR-2-ext3 COMPRESSED co_common { ENFORCE(outer_ip_flag == outer_ip_indicator.CVALUE); discriminator =:= '11111010' [ 8 ]; ip_id_indicator =:= irregular(1) [ 1 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; flags_indicator =:= irregular(1) [ 1 ]; ttl_hopl_indicator =:= irregular(1) [ 1 ]; tos_tc_indicator =:= irregular(1) [ 1 ]; reorder_ratio =:= reorder_choice [ 2 ]; control_crc3 =:= control_crc3_encoding [ 3 ]; outer_ip_indicator : df : ip_id_behavior : coverage_behavior =:= profile_8_flags_enc(flags_indicator.CVALUE, ip_version.UVALUE) [ 0, 8 ]; tos_tc =:= static_or_irreg(tos_tc_indicator.CVALUE, 8) [ 0, 8 ]; ttl_hopl =:= static_or_irreg(ttl_hopl_indicator.CVALUE, ttl_hopl.ULENGTH) [ 0, 8 ]; msn =:= msn_lsb(8) [ 8 ]; ip_id =:= ip_id_sequential_variable(ip_id_behavior.UVALUE, ip_id_indicator.CVALUE) [ 0, 8, 16 ]; } // UO-0 COMPRESSED pt_0_crc3 { discriminator =:= '0' [ 1 ]; msn =:= msn_lsb(4) [ 4 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; ip_id =:= inferred_sequential_ip_id [ 0 ]; } // New format, Type 0 with strong CRC and more SN bits COMPRESSED pt_0_crc7 { discriminator =:= '100' [ 3 ]; msn =:= msn_lsb(6) [ 6 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; ip_id =:= inferred_sequential_ip_id [ 0 ]; } // UO-1-ID replacement (PT-1 only used for sequential) COMPRESSED pt_1_seq_id { Pelletier & Sandlund Expires April 4, 2008 [Page 98] Internet-Draft ROHCv2 Profiles October 2007 ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '101' [ 3 ]; header_crc =:= crc3(THIS.UVALUE, THIS.ULENGTH) [ 3 ]; msn =:= msn_lsb(6) [ 6 ]; ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 4) [ 4 ]; } // UOR-2 replacement COMPRESSED pt_2_rnd { ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_ZERO)); discriminator =:= '110' [ 3 ]; msn =:= msn_lsb(6) [ 6 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; } // UOR-2-ID replacement COMPRESSED pt_2_seq_id { ENFORCE((ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL) || (ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED)); discriminator =:= '1100' [ 4 ]; ip_id =:= ip_id_lsb(ip_id_behavior.UVALUE, 5) [ 5 ]; header_crc =:= crc7(THIS.UVALUE, THIS.ULENGTH) [ 7 ]; msn =:= msn_lsb(8) [ 8 ]; } } 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. Pelletier & Sandlund Expires April 4, 2008 [Page 99] Internet-Draft ROHCv2 Profiles October 2007 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 packet type, the 'Size' field and the 'Code' octet, using the polynomial defined in [RFC4995], Section 5.3.1.1. 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 implicitely an acknowlegement for a successfully decompressed packet, which Pelletier & Sandlund Expires April 4, 2008 [Page 100] Internet-Draft ROHCv2 Profiles October 2007 corresponds to a packet whose LSBs match the Acknowledgment Number of the feedback element, unless the ACKNUMBER-NOT-VALID option Section 6.9.2.2 appears in the feedback element. The FEEDBACK-2 format always carry 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 Length (octets) +---+---+---+---+---+---+---+---+ 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. +---+---+---+---+---+---+---+---+ | 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. +---+---+---+---+---+---+---+---+ | 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. Pelletier & Sandlund Expires April 4, 2008 [Page 101] Internet-Draft ROHCv2 Profiles October 2007 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 and MUST NOT appear in the same feedback element as the MSN option, otherwise the compressor MUST discard the entire feedback element. 6.9.2.3. The CONTEXT_MEMORY Feedback 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 Feedback Option The CLOCK_RESOLUTION option informs the compressor of the clock resolution of the decompressor. It also informs whether the decompressor supports timer-based compression of the RTP TS timestamp (see Section 6.6.9) or not. 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 one compressor and decompressor pair. +---+---+---+---+---+---+---+---+ | Opt Type = 10 | Opt Len = 1 | +---+---+---+---+---+---+---+---+ | clock resolution (ms) | +---+---+---+---+---+---+---+---+ The smallest clock resolution which 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 Pelletier & Sandlund Expires April 4, 2008 [Page 102] Internet-Draft ROHCv2 Profiles October 2007 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 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, UDP and RTP headers and possibly also valid UDP checksums. Such corruption may be detected with end-to-end authentication and integrity mechanisms which 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 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 reserved 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-Lite <# Editor's Note: To be removed before publication #> ROHC profile identifiers must be reserved by the IANA for the updated profiles defined in this document. A suggested registration in the Pelletier & Sandlund Expires April 4, 2008 [Page 103] Internet-Draft ROHCv2 Profiles October 2007 "RObust Header Compression (ROHC) Profile Identifiers" name space would then be: Profile Identifier Usage Reference ------------------ ---------------------- --------- 0x0000 ROHC uncompressed RFC 3095 0xnn00 Reserved 0x0001 ROHC RTP RFC 3095 0x0101 ROHCv2 RTP [RFCXXXX (this)] 0xnn01 Reserved 0x0002 ROHC UDP RFC 3095 0x0102 ROHCv2 UDP [RFCXXXX (this)] 0xnn02 Reserved 0x0003 ROHC ESP RFC 3095 0x0103 ROHCv2 ESP [RFCXXXX (this)] 0xnn03 Reserved 0x0004 ROHC IP RFC 3843 0x0104 ROHCv2 IP [RFCXXXX (this)] 0xnn04 Reserved 0x0005 ROHC LLA RFC 4362 0x0105 ROHC LLA with R-mode RFC 3408 0xnn05 Reserved 0x0006 ROHC TCP RFC4996 0xnn06 Reserved 0x0007 ROHC RTP/UDP-Lite RFC 4019 0x0107 ROHCv2 RTP/UDP-Lite [RFCXXXX (this)] 0xnn07 Reserved 0x0008 ROHC UDP-Lite RFC 4019 0x0108 ROHCv2 UDP-Lite [RFCXXXX (this)] 0xnn08 Reserved 0x0009-0xnn7F To be Assigned by IANA 0xnn80-0xnnFE To be Assigned by IANA 0xnnFF Reserved 9. Acknowledgements The authors would like to thank Carl Knutsson, Haipeng Jin and Rohit Kapoor for comments and discussions about these profiles. Also thanks to the many people who have contributed to previous ROHC specifications. 10. References Pelletier & Sandlund Expires April 4, 2008 [Page 104] Internet-Draft ROHCv2 Profiles October 2007 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. Pelletier & Sandlund Expires April 4, 2008 [Page 105] Internet-Draft ROHCv2 Profiles October 2007 10.2. Informative References [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 and any change to them only has to be possible to convey in IR packets. STATIC-DEF - These fields are expected to be constant throughout the lifetime of the flow and whose 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 Pelletier & Sandlund Expires April 4, 2008 [Page 106] Internet-Draft ROHCv2 Profiles October 2007 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 (RC) 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 field that change between each packet, but change in a predictable pattern. Appendix A.1. IPv4 Header Fields +------------------------+----------------+ | Field | Class | +------------------------+----------------+ | Version | STATIC-KNOWN | | Header Length | STATIC-KNOWN | | Type Of Service | RC | | Packet Length | INFERRED | | Identification | | | Sequential | PATTERN | | Seq. swap | PATTERN | | Random | IRREGULAR | | Zero | STATIC | | Reserved flag | STATIC-KNOWN | | Don't Fragment flag | RC | | More Fragments flag | STATIC-KNOWN | | Fragment Offset | STATIC-KNOWN | | Time To Live | RC | | Protocol | STATIC-DEF | | Header Checksum | INFERRED | | Source Address | STATIC-DEF | | Destination Address | STATIC-DEF | +------------------------+----------------+ Version Pelletier & Sandlund Expires April 4, 2008 [Page 107] Internet-Draft ROHCv2 Profiles October 2007 The version field states which IP version is used, and is set to the value four. Header Length As long 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 RC or STATIC-DEF, but only option-less headers are compressed by ROHCv2 profiles. The field is therefore classified as STATIC-KNOWN. Type Of Service The Type Of Service field is expected to be constant during the lifetime of a flow or 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. Pelletier & Sandlund Expires April 4, 2008 [Page 108] Internet-Draft ROHCv2 Profiles October 2007 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 will changes rarely and is therefore classified as RC. 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 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. Appendix A.2. IPv6 Header Fields Pelletier & Sandlund Expires April 4, 2008 [Page 109] Internet-Draft ROHCv2 Profiles October 2007 +----------------------+----------------+ | Field | Class | +----------------------+----------------+ | Version | STATIC-KNOWN | | Traffic Class | RC | | Flow Label | STATIC-DEF | | Payload Length | INFERRED | | Next Header | STATIC-DEF | | Hop Limit | RC | | 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 The Traffic Class field is expected to be constant during the lifetime of a flow or to change relatively seldom. Flow Label This field may be used to identify packets belonging to a specific flow. If 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. Pelletier & Sandlund Expires April 4, 2008 [Page 110] Internet-Draft ROHCv2 Profiles October 2007 Appendix 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. Appendix 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 Pelletier & Sandlund Expires April 4, 2008 [Page 111] Internet-Draft ROHCv2 Profiles October 2007 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 either 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. Appendix A.5. RTP Header Fields +----------------+----------------+ | Field | Class | +----------------+----------------+ | Version | STATIC-KNOWN | | Padding | RC | | Extension | RC | | CSRC Counter | RC | | Marker | SEMISTATIC | | Payload Type | RC | | Sequence Number| PATTERN | | Timestamp | PATTERN | | SSRC | STATIC-DEF | | CSRC | RC | +----------------+----------------+ 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 RC to allow for the case where the value of this field is changes. Extension Pelletier & Sandlund Expires April 4, 2008 [Page 112] Internet-Draft ROHCv2 Profiles October 2007 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 RC. 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 RC. 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, corresponding 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. This increase, expressed as a multiple of the picture clock frequency, is in most cases very limited. SSRC Pelletier & Sandlund Expires April 4, 2008 [Page 113] Internet-Draft ROHCv2 Profiles October 2007 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. Appendix A.6. ESP Header Fields This classification applies both to the encrypted ESP header used in profile 0x0103 and the NULL-encrypted ESP header used in all the profiles of this document. +------------------+-------------+ | Field | Class | +------------------+-------------+ | SPI | STATIC-DEF | | Sequence Number | PATTERN | +------------------+-------------+ 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. ESP Sequence Number The ESP Sequence Number will be incremented by one for each packet sent. Appendix 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 | RC | | Destination | RC | +-----------------------+---------------+ Pelletier & Sandlund Expires April 4, 2008 [Page 114] Internet-Draft ROHCv2 Profiles October 2007 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 remains constant for the duration of the flow, and 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 remains constant for the duration of the flow, and 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. Appendix 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 these fields are expected to be set to zero for the duration of any flow. Protocol Pelletier & Sandlund Expires April 4, 2008 [Page 115] Internet-Draft ROHCv2 Profiles October 2007 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. Appendix 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. Pelletier & Sandlund Expires April 4, 2008 [Page 116] Internet-Draft ROHCv2 Profiles October 2007 Source and Destination Addresses These fields can be used to define the flow are not expected to change. Appendix 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 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. All the text in this appendix should be considered guidelines and they have no normative impact on how a ROHCv2 Pelletier & Sandlund Expires April 4, 2008 [Page 117] Internet-Draft ROHCv2 Profiles October 2007 implementation must be realized. Appendix 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 occured 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. Appendix 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 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, though the use of Window-based LSB encoding (W-LSB). When using W-LSB encoding, the compressor uses a number of references from its context decided by its optimistic approach and extracts the value of the field to be encoded from each reference and finds the maximum and minimum values. When having obtained these limits, the compressor assumes that the decompressor is currently using a value in the range from the minimum to the maximum value (inclusive) as its reference. The compressor should then select a number of LSBs of the new value so that these can be decompressed both if the decompressor has the minimum value or the maximum value as its current reference. Appendix 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 select how many bits of timestamp LSBs need to transmitted. When using timer-based compression, the number of bits to transmit depend on the amount of jitter both before the compressor and the jitter between compressor and decompressor. The jitter before the compressor can be estimated using the following computation: Pelletier & Sandlund Expires April 4, 2008 [Page 118] Internet-Draft ROHCv2 Profiles October 2007 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 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 compressor and decompressor (Max_Jitter_CD). This information may for example come from lower layers, but if such information is not available, the compressor should use an upper bound which is significantly higher than the link roundtrip time. 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 which 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 Pelletier & Sandlund Expires April 4, 2008 [Page 119] Internet-Draft ROHCv2 Profiles October 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Pelletier & Sandlund Expires April 4, 2008 [Page 120]