draft-ietf-rohc-rtp-impl-guide-04.txt   draft-ietf-rohc-rtp-impl-guide-05.txt 
Network Working Group Lars-Erik Jonsson, Ericsson Network Working Group L-E. Jonsson, Ericsson
INTERNET-DRAFT Peter Kremer, Ericsson INTERNET-DRAFT P. Kremer, Ericsson
Expires: March 2004 September 23, 2003 Expires: December 2004 June 9, 2004
ROHC Implementer's Guide ROHC Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-04.txt> <draft-ietf-rohc-rtp-impl-guide-05.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I (we) certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am (we are) aware have been
disclosed, and any of which I (we) become aware will be disclosed, in
accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, I (we) accept the provisions of
Section 3 of RFC 3667 (BCP 78).
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress". material or cite them other than as "work in progress".
skipping to change at page 1, line 36 skipping to change at page 1, line 41
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is a submission of the IETF ROHC WG. Comments should be This document is a submission of the IETF ROHC WG. Comments should be
directed to the ROHC WG mailing list, rohc@ietf.org. directed to the ROHC WG mailing list, rohc@ietf.org.
Abstract Abstract
This document describes common misinterpretations and some ambiguous This document describes common misinterpretations and some ambiguous
points of ROHC [RFC 3095], which defines the framework and four points of ROHC [1], which defines the framework and four profiles of
profiles of a robust and efficient header compression scheme. These a robust and efficient header compression scheme. These points have
points have been identified by the members of the ROHC working group been identified by the members of the ROHC working group during
during different interoperability test events. different interoperability test events.
Table of Contents Table of Contents
1. Introduction....................................................3 1. Introduction.....................................................3
2. CRC calculation and coverage issues.............................3 2. CRC calculation and coverage issues..............................3
2.1. CRC calculation...............................................3 2.1. CRC calculation.............................................3
2.2. Padding octet in CRC..........................................3 2.2. Padding octet in CRC........................................3
2.3. CRC coverage in CRC feedback options..........................3 2.3. CRC coverage in CRC feedback options........................3
2.4. CRC coverage of the ESP NULL header...........................3 2.4. CRC coverage of the ESP NULL header.........................4
3. Enhanced mode transition procedures.............................4 3. Enhanced mode transition procedures..............................4
3.1. Modified transition logic for enhanced transitions ...........4 3.1. Modified transition logic for enhanced transitions..........4
3.2. Transition from Reliable to Optimistic mode...................5 3.2. Transition from Reliable to Optimistic mode.................5
3.3. Transition to Unidirectional mode.............................6 3.3. Transition to Unidirectional mode...........................6
4. Timestamp encoding considerations...............................6 4. Timestamp encoding considerations................................6
4.1. Encoding of TS values.........................................6 4.1. Encoding of TS values.......................................6
4.2. Interpretation intervals for TS encoding......................6 4.2. Interpretation intervals for TS encoding....................6
4.3. Recalculating TS_OFFSET.......................................7 4.3. Recalculating TS_OFFSET.....................................7
4.4. Meaning of the Tsc flag.......................................7 4.4. TS_STRIDE and the Tsc flag in Extension 3...................7
5. List compression issues.........................................7 5. List compression issues..........................................7
5.1. Generic extension header list.................................7 5.1. Generic extension header list...............................7
5.2. CSRC list items in RTP dynamic chain..........................7 5.2. CSRC list items in RTP dynamic chain........................8
5.3. RTP dynamic chain.............................................8 5.3. RTP dynamic chain...........................................8
5.4. Compressed lists in UO-1-ID packets...........................8 5.4. Compressed lists in UO-1-ID packets.........................8
5.5. Bit masks in list compression.................................8 5.5. Bit masks in list compression...............................8
5.6. Headers compressed with list compression......................9 5.6. Headers compressed with list compression....................9
5.7. ESP NULL header list compression..............................9 5.7. ESP NULL header list compression............................9
6. Updating properties.............................................9 6. Updating properties..............................................9
6.1. Implicit updates..............................................9 6.1. Implicit updates............................................9
6.2. Updating properties of UO-1*..................................9 6.2. Updating properties of UO-1*................................9
7. Other protocol clarifications..................................10 7. Other protocol clarifications...................................10
7.1. Meaning of NBO...............................................10 7.1. Meaning of NBO.............................................10
7.2. IP-ID........................................................10 7.2. IP-ID......................................................10
7.3. Extension-3 in UO-1-ID packets...............................10 7.3. Extension-3 in UO-1-ID packets.............................10
7.4. Extension-3 in UOR-2* packets................................10 7.4. Extension-3 in UOR-2* packets..............................10
7.5. Multiple SN options in one feedback packet...................11 7.5. Multiple SN options in one feedback packet.................11
7.6. Packet decoding during mode transition.......................11 7.6. Multiple CRC options in one feedback packet................11
7.7. How to respond to lost feedback links?.......................11 7.7. Packet decoding during mode transition.....................11
7.8. What does "presumed zero if absent" mean on page 88?.........12 7.8. How to respond to lost feedback links?.....................11
7.9. UOR-2 in profile 2 (UDP).....................................12 7.9. What does "presumed zero if absent" mean on page 88?.......12
7.10. Sequence number LSB's in IP extension headers...............12 7.10. UOR-2 in profile 2 (UDP)..................................12
8. ROHC negotiation clarifications................................12 7.11. Sequence number LSB's in IP extension headers.............12
9. PROFILES suboption in ROHC-over-PPP............................13 8. ROHC negotiation clarifications.................................12
10. Test configuration............................................13 9. PROFILES suboption in ROHC-over-PPP.............................13
11. Security considerations.......................................14 10. Test Configuration.............................................13
12. Acknowledgements..............................................14 11. Security considerations........................................14
13. References....................................................14 12. Acknowledgment.................................................14
14. Authors' addresses............................................14 13. References.....................................................14
Appendix A. Sample CRC algorithm..................................15 14. Authors' Addresses.............................................14
Appendix B. Potential improvements in updated profiles............17 Appendix A - Sample CRC algorithm..................................15
Appendix B - Potential improvements in updated profiles............17
Appendix C - Issues identified but not yet resolved................17
1. Introduction 1. Introduction
ROHC [RFC 3095] defines a robust and efficient header compression ROHC [1] defines a robust and efficient header compression algorithm,
algorithm, and its description is rather long and complex. During and its description is rather long and complex. During the
the implementation and the interoperability tests of the algorithm implementation and the interoperability tests of the algorithm some
some unclear areas have been identified. This document tries to unclear areas have been identified. This document tries to collect
collect and clarify these points. Note that all section and chapter and clarify these points. Note that all section and chapter
references in this document refer to [RFC-3095], if not stated references in this document refer to [1], if not stated otherwise.
otherwise.
2. CRC calculation and coverage issues 2. CRC calculation and coverage issues
2.1. CRC calculation 2.1. CRC calculation
ROHC uses CRC checksum in order to provide some protection against ROHC uses CRC checksum in order to provide some protection against
bit errors. CRC is used in the segmentation protocol and in the bit errors. CRC is used in the segmentation protocol and in the
compressed packets, as well. compressed packets, as well.
Section 5.2.5.2 describes the segmentation protocol and refers to Section 5.2.5.2 describes the segmentation protocol and refers to
[RFC 1662], which describes a well-defined CRC algorithm for 32 bit [3], which describes a well-defined CRC algorithm for 32 bit
checksums. Although, Section 5.9 only defines the polynomials for 3, checksums. Although, Section 5.9 only defines the polynomials for 3,
7 and 8-bit long checksum, the same algorithm can be used in these 7 and 8-bit long checksum, the same algorithm can be used in these
cases as well. cases as well.
A PERL implementation of the algorithm (written by Carsten Bormann) A PERL implementation of the algorithm (written by Carsten Bormann)
can be found in Appendix A. can be found in Appendix A.
2.2. Padding octet in CRC 2.2. Padding octet in CRC
According to Section 5.9.1, in case of IR and IR-DYN packets the CRC According to Section 5.9.1, in case of IR and IR-DYN packets the CRC
"is calculated over the entire IR or IR-DYN packet, excluding Payload "is calculated over the entire IR or IR-DYN packet, excluding Payload
and including CID or Add-CID octet". Padding isn't meant to be and including CID or Add-CID octet". Padding isn't meant to be
meaningful part of a packet and not included in CRC calculation. As meaningful part of a packet and not included in CRC calculation. As
a result, CRC doesn't cover the Add-CID octet for CID 0, either. a result, CRC doesn't cover the Add-CID octet for CID 0, either.
2.3. CRC coverage in CRC feedback options 2.3. CRC coverage in CRC feedback options
Section 5.7.6.3 states that "The CRC option contains an 8-bit CRC Section 5.7.6.3 states "The CRC option contains an 8-bit CRC computed
computed over the entire feedback payload, without the packet type over the entire feedback payload, without the packet type and code
and code octet, but including any CID fields, using the polynomial of octet, but including any CID fields, using the polynomial of section
section 5.9.1". However, it does not mention how the "size" field is 5.9.1". However, it does not mention how the "size" field is handled,
handled, if present. Since the "size" field can be considered an if present. Since the "size" field can be considered an extension of
extension of the "code" field, it must be treated as the "code" the "code" field, it must be treated as the "code" field, i.e. the
field, i.e. the "size" field is not covered by the CRC. "size" field is not covered by the CRC.
2.4. CRC coverage of the ESP NULL header 2.4. CRC coverage of the ESP NULL header
Section 5.8.7 gives the CRC coverage of the ESP NULL header as Section 5.8.7 gives the CRC coverage of the ESP NULL header as
"Entire ESP header". This should be interpreted as being only the "Entire ESP header". This should be interpreted as being only the
initial part of the header (i.e. SPI and Sequence number), and not initial part of the header (i.e. SPI and Sequence number), and not
the trailer part at the end of the payload. Therefore, the ESP NULL the trailer part at the end of the payload. Therefore, the ESP NULL
header will have the same CRC coverage as the header will have the same CRC coverage as the ESP header used in the
ESP header used in the ESP profile (section 5.7.7.7). ESP profile (section 5.7.7.7).
3. Enhanced mode transition procedures 3. Enhanced mode transition procedures
To reduce transmission overhead and computational complexity To reduce transmission overhead and computational complexity
(including CRC calculation) associated with feedback packets sent for (including CRC calculation) associated with feedback packets sent for
each decompressed packet during mode transition, a decompressor can each decompressed packet during mode transition, a decompressor can
be implemented with slightly modified mode transition procedures, be implemented with slightly modified mode transition procedures,
compared to those defined in [RFC3095]. compared to those defined in [1].
These modifications affect transitions to Optimistic and These modifications affect transitions to Optimistic and
Unidirectional modes of operation, i.e. the transitions described in Unidirectional modes of operation, i.e. the transitions described in
sections 5.6.5 and 5.6.6 of [RFC3095], and make those transition sections 5.6.5 and 5.6.6 of [1], and make those transition diagrams
diagrams more consistent with the diagram describing the transition more consistent with the diagram describing the transition to R-mode.
to R-mode. However, the differences between the original diagrams of However, the differences between the original diagrams of [1] were
[RFC3095] were motivated by robustness concerns for mode transitions motivated by robustness concerns for mode transitions to Optimistic
to Optimistic and Unidirectional modes. To avoid deadlock situations and Unidirectional modes. To avoid deadlock situations in mode
in mode transitions, these aspects must be addressed also when a transitions, these aspects must be addressed also when a decompressor
decompressor implements the enhanced transition procedures, and that implements the enhanced transition procedures, and that is done by
is done by following a slightly modified definition of the following a slightly modified definition of the decompressor
decompressor transition states. All aspects related to implementation transition states. All aspects related to implementation of the
of the enhanced transition procedures are described in subsequent enhanced transition procedures are described in subsequent chapters.
chapters.
Note that these modified operations should be seen only as an Note that these modified operations should be seen only as an
improved decompressor implementation, since interoperability is not improved decompressor implementation, since interoperability is not
at all affected. A decompressor implemented according to the at all affected. A decompressor implemented according to the
optimized procedures would be able to interoperate with an RFC3095 optimized procedures would be able to interoperate with an RFC3095
compressor, as well as a decompressor implemented according to the compressor, as well as a decompressor implemented according to the
procedures described in RFC3095 would do. procedures described in RFC3095 would do.
3.1. Modified transition logic for enhanced transitions 3.1. Modified transition logic for enhanced transitions
skipping to change at page 4, line 51 skipping to change at page 5, line 5
decompressed during the second half of the transition procedure, i.e. decompressed during the second half of the transition procedure, i.e.
after an appropriate IR/IR-DYN/UOR-2 packet has been received from after an appropriate IR/IR-DYN/UOR-2 packet has been received from
the compressor. In the transition diagrams, sections 3.2 and 3.3 the compressor. In the transition diagrams, sections 3.2 and 3.3
below, this is realized by allowing the decompressor transition below, this is realized by allowing the decompressor transition
parameter (D_TRANS) to be set to P (Pending) at that stage. However, parameter (D_TRANS) to be set to P (Pending) at that stage. However,
as mentioned above, there are robustness concerns related to this as mentioned above, there are robustness concerns related to this
optimization, and to avoid deadlock situations with never completed optimization, and to avoid deadlock situations with never completed
transitions as a result of feedback losses, the decompressor must transitions as a result of feedback losses, the decompressor must
continue to send feedback at least periodically, also when in Pending continue to send feedback at least periodically, also when in Pending
transition state. That would be the equivalence of enhancing the transition state. That would be the equivalence of enhancing the
D_TRANS parameter definition in section 5.6.1 of [RFC3095], to D_TRANS parameter definition in section 5.6.1 of [1], to include a
include a definition of Pending state operation. definition of Pending state operation.
- D_TRANS: - D_TRANS:
Possible values for the D_TRANS parameter are (I)NITIATED, Possible values for the D_TRANS parameter are (I)NITIATED,
(P)ENDING and (D)ONE. D_TRANS MUST be initialized to D, and a mode (P)ENDING and (D)ONE. D_TRANS MUST be initialized to D, and a mode
transition can be initiated only when D_TRANS is D. While D_TRANS transition can be initiated only when D_TRANS is D. While D_TRANS
is I, the decompressor sends a NACK or ACK carrying a CRC option is I, the decompressor sends a NACK or ACK carrying a CRC option
for each packet received. When D_TRANS is set to P, the for each packet received. When D_TRANS is set to P, the
decompressor do not have to send a NACK or ACK for each packet decompressor do not have to send a NACK or ACK for each packet
received, but it MUST continue to send feedback on a regular received, but it MUST continue to send feedback on a regular
basis, and all feedback packets sent MUST include the CRC option. basis, and all feedback packets sent MUST include the CRC option.
skipping to change at page 7, line 26 skipping to change at page 7, line 26
to cover both interpretation intervals. to cover both interpretation intervals.
4.3. Recalculating TS_OFFSET 4.3. Recalculating TS_OFFSET
TS can be sent unscaled if the TS value change does not match the TS can be sent unscaled if the TS value change does not match the
established TS_STRIDE, but the TS_STRIDE might still stay unchanged. established TS_STRIDE, but the TS_STRIDE might still stay unchanged.
To ensure correct decompression of subsequent packets, the To ensure correct decompression of subsequent packets, the
decompressor should therefore always recalculate the RTP TS modulo, decompressor should therefore always recalculate the RTP TS modulo,
TS_OFFSET, when a packet with an unscaled TS value is received. TS_OFFSET, when a packet with an unscaled TS value is received.
4.4. Meaning of the Tsc flag 4.4. TS_STRIDE and the Tsc flag in Extension 3
The Tsc flag in extension 3 indicates whether TS is scaled or not. It The Tsc flag in Extension 3 indicates whether TS is scaled or not. It
must be noted that the Tsc value apply to all TS bits, also if there must be noted that the Tsc value apply to all TS bits, also if there
are no TS bits in the extension itself. are no TS bits in the extension itself.
Note also that if Tsc=1, TS is scaled using context(TS_STRIDE), not
value(TS_STRIDE) as is said in the legend for Extension 3 in section
5.7.5.
When a compressor uses Extension 3 to re-establish a new value for
TS_STRIDE, it must send unscaled TS together with TS_STRIDE for some
packets until decompressor confidence is obtained. When the TS_STRIDE
field is present in Extension 3, the Tsc flag must thus be set to 0.
5. List compression issues 5. List compression issues
5.1. Generic extension header list 5.1. Generic extension header list
Section 5.7.7.4 defines the static and dynamic parts of the IPv4 Section 5.7.7.4 defines the static and dynamic parts of the IPv4
header. This section indicates a 'Generic extension header list' header. This section indicates a 'Generic extension header list'
field in the dynamic chain, which has a variable length. The field in the dynamic chain, which has a variable length. The
detailed description of this field can be found in Section 5.8.6.1. detailed description of this field can be found in Section 5.8.6.1.
The generic extension header list starts with an octet that is always The generic extension header list starts with an octet that is always
skipping to change at page 8, line 45 skipping to change at page 8, line 53
decompressor updates its translation table whenever an (Index, item) decompressor updates its translation table whenever an (Index, item)
pair is received (section 5.8.1). The decompressor must be able to pair is received (section 5.8.1). The decompressor must be able to
handle such a packet, thus it has to behave as described in the handle such a packet, thus it has to behave as described in the
latter case. According to section 5.8.1.2, the compressor must latter case. According to section 5.8.1.2, the compressor must
increment Counter by 1. increment Counter by 1.
5.5. Bit masks in list compression 5.5. Bit masks in list compression
A 7-bit or 15-bit mask may be used in the insertion and/or removal A 7-bit or 15-bit mask may be used in the insertion and/or removal
schemes for compressed lists. It should be noted that even if a list schemes for compressed lists. It should be noted that even if a list
has more than 7 items, a 7-bit mask can be used as long as changes has more than 7 items, a 7-bit mask could be used as long as changes
are only applied in the first part of the reference list, and all are only applied in the first part of the reference list, and items
items with an index not covered by the 7-bit mask are then kept with an index not covered by the 7-bit mask are thus kept unchanged.
unchanged.
5.6. Headers compressed with list compression 5.6. Headers compressed with list compression
In section 5.8, it is stated that headers which can be part of In section 5.8, it is stated that headers which can be part of
extension header chains INCLUDE AH, null ESP, minimal encapsulation, extension header chains INCLUDE AH, null ESP, minimal encapsulation,
GRE, and IPv6 extensions. This list of headers which can be GRE, and IPv6 extensions. This list of headers which can be
compressed is correct, but the work INCLUDE should not be there, compressed is correct, but the work INCLUDE should not be there,
since only the header types listed can actually be handled. since only the header types listed can actually be handled.
5.7. ESP NULL header list compression 5.7. ESP NULL header list compression
skipping to change at page 9, line 32 skipping to change at page 9, line 32
If an updating packet (e.g. R-0-CRC or UO-0) contains information If an updating packet (e.g. R-0-CRC or UO-0) contains information
about a specific field X (compressed RTP sequence number, typically), about a specific field X (compressed RTP sequence number, typically),
then X is updated according to the content of that packet. But this then X is updated according to the content of that packet. But this
packet implicitly updates all other inferred fields (i.e. RTP packet implicitly updates all other inferred fields (i.e. RTP
timestamp) according to the current mode and the appropriate mapping timestamp) according to the current mode and the appropriate mapping
function of the updated and the inferred fields. function of the updated and the inferred fields.
An updating packet thus updates the reference values of all header An updating packet thus updates the reference values of all header
fields, either explicitly or implicitly, with an exception for the fields, either explicitly or implicitly, with an exception for the
UO-1-ID packet, which only updates TS, SN and IP-ID (see 5.7.3). In UO-1-ID packet, which only updates TS, SN, IP-ID, and sequence
UO-mode, all packets are updating packets, while in R-mode all numbers of IP extension headers (see 5.7.3). In UO-mode, all packets
packets with a CRC are updating packets. are updating packets, while in R-mode all packets with a CRC are
updating packets.
For example, a UO-0 packet contains the compressed RTP sequence For example, a UO-0 packet contains the compressed RTP sequence
number (SN). Such a packet also updates RTP timestamp and IPv4 ID, number (SN). Such a packet also implicitly updates RTP timestamp,
implicitly. IPv4 ID, and sequence numbers of IP extension headers.
6.2. Updating properties of UO-1* 6.2. Updating properties of UO-1*
In section 5.7.3, the updating properties of UO-1* are stated as In section 5.7.3, the updating properties of UO-1* are stated:
follows:
"Values provided in extensions, except those in other SN, TS, "Values provided in extensions, except those in other SN, TS,
or IP-ID fields, do not update the context." or IP-ID fields, do not update the context."
However, also sequence number fields of extension headers must be However, also sequence number fields of extension headers must be
updated, which means the updating properties should be rephrased as: updated, which means the updating properties should be rephrased as:
"The only values provided in extensions that update the context are "The only values provided in extensions that update the context are
the additional bits for the SN, TS, or IP-ID fields. Other values the additional bits for the SN, TS, or IP-ID fields. Other values
provided in extensions do not update the context. Note that provided in extensions do not update the context. Note that
skipping to change at page 10, line 17 skipping to change at page 10, line 17
7.1. Meaning of NBO 7.1. Meaning of NBO
In general, an unset flag indicates the normal operation and a set In general, an unset flag indicates the normal operation and a set
flag indicates unusual behavior. However, in IPv4 dynamic part flag indicates unusual behavior. However, in IPv4 dynamic part
(Section 5.7.7.4), if the 'NBO' bit is set, it means that network (Section 5.7.7.4), if the 'NBO' bit is set, it means that network
byte order is used. byte order is used.
7.2. IP-ID 7.2. IP-ID
According to Section 5.7 IP-ID means the compressed value of the IPv4 According to Section 5.7 IP-ID means the compressed value of the IPv4
header's 'Identification' field. Type 0, 1 and 2 packets contain the header's 'Identification' field. Compressed packets contain this
compressed value (IP-ID), however IR packets with dynamic chain and compressed value (IP-ID), while IR packets with dynamic chain and IR-
IR-DYN packets transmit the original, uncompressed value. This is DYN packets transmit the original, uncompressed Identification field
because the dynamic part of the IPv4 header (Section 5.7.7.4) value. The IP-ID field always represents the Identification value of
contains the 'Identification' field instead of the IP-ID. the innermost IPv4 header whose corresponding RND flag is not 1.
It should be noted that also when 16 bits of IP-ID is sent in If RND or RND2 is set to 1, the corresponding IP-ID(s) is(are) sent
extension 3, it is still "compressed", i.e. expressed as an SN offset as 16-bit original Identification value(s) at the end of the
and byte-swapped if NBO=0. compressed base header, according to the IP-ID description (see the
beginning of section 5.7).
It should be noted that when RND*=0, IP-ID is always compressed, i.e.
expressed as an SN offset and byte-swapped if NBO=0. This is the case
even when 16 bits of IP-ID is sent in extension 3.
7.3. Extension-3 in UO-1-ID packets 7.3. Extension-3 in UO-1-ID packets
Extension-3 is applied to give values and indicate changes to fields Extension-3 is applied to give values and indicate changes to fields
other than SN, TS and IP-ID in IP header(s) and RTP header. In case other than SN, TS and IP-ID in IP header(s) and RTP header. In case
of UO-1-ID packets, it should be noted that values provided in of UO-1-ID packets, it should be noted that values provided in
extensions do not update the context, with an exception for SN, TS extensions do not update the context, with an exception for SN, TS
and IP-ID fields, which always update the context (Section 5.7.3.). and IP-ID fields, which always update the context (Section 5.7.3.).
It should also be noted that a UO-1-ID packet with Extension 3 must It should also be noted that a UO-1-ID packet with Extension 3 must
never be sent with RND flags that changes the packet interpretation, never be sent with RND flags that changes the packet interpretation,
skipping to change at page 10, line 48 skipping to change at page 10, line 53
Besides, usage of Extension-3 in UO-1-ID can be useful to compress a Besides, usage of Extension-3 in UO-1-ID can be useful to compress a
transient change in a packet stream. For example, if a field's value transient change in a packet stream. For example, if a field's value
changes in the current packet but in the next packet it returns to changes in the current packet but in the next packet it returns to
its regular behavior. E.g. changes in TTL. its regular behavior. E.g. changes in TTL.
7.4. Extension-3 in UOR-2* packets 7.4. Extension-3 in UOR-2* packets
If Extension-3 is used in a UOR-2* packet then the information of the If Extension-3 is used in a UOR-2* packet then the information of the
extension updates the context (Section 5.7.4). Some flags of the IP extension updates the context (Section 5.7.4). Some flags of the IP
header in the extension (e.g. NBO or RND) can change the header in the extension (e.g. NBO or RND) changes the interpretation
interpretation of fields in UOR-2* packets. In these cases, when a of fields in UOR-2* packets. In these cases, when a flag changes in
flag changes in Extension-3, a decompressor should re-parse the UOR- Extension-3, a decompressor should re-parse the UOR-2* packet.
2* packet.
7.5. Multiple SN options in one feedback packet 7.5. Multiple SN options in one feedback packet
The length of the sequence number field in the original ESP header is The length of the sequence number field in the original ESP header is
32 bits. A decompressor can't send back all the 32 bits in a 32 bits. A decompressor can't send back all the 32 bits in a
feedback packet unless it uses multiple SN options in one feedback feedback packet unless it uses multiple SN options in one feedback
packet. Section 5.7.6.1 declares that a FEEDABCK-2 packet can packet. Section 5.7.6.1 declares that a FEEDABCK-2 packet can
contain variable number of feedback options and the options can contain variable number of feedback options and the options can
appear in any order. appear in any order.
A compressor - that wants to be conform to the specification - should A compressor should be able to process multiple SN options in one
be able to process multiple SN options in one feedback packet. feedback packet.
7.6. Packet decoding during mode transition 7.6. Multiple CRC options in one feedback packet
Although it is never required to have more than one single CRC option
in a feedback packet, having multiple CRC options is still allowed.
If multiple CRC options are included, all such CRC options will be
identical, as they will be calculated over the same header.
7.7. Packet decoding during mode transition
Each ROHC profile defines its own set of packet formats, and also its Each ROHC profile defines its own set of packet formats, and also its
own feedback packets. The use of various operational modes is also own feedback packets. The use of various operational modes is also
defined by each specific profile. A decompressor can therefore not defined by each specific profile. A decompressor can therefore not
initiate a mode transfer request before at least one packet of a new initiate a mode transfer request before at least one packet of a new
context has been correctly decompressed, establishing the context context has been correctly decompressed, establishing the context
based on one specific profile (as specified in IR packets). First based on one specific profile (as specified in IR packets). First
then the context has been established, the decompressor knows the then the context has been established, the decompressor knows the
profile used, which modes are defined by that profile, and the profile used, which modes are defined by that profile, and the
feedback packet formats available. feedback packet formats available.
If the transition procedures in sections 5.6.5 and 5.6.6 of [RFC3095] If the transition procedures in sections 5.6.5 and 5.6.6 of [1] are
are followed (and not the enhanced procedures described in section 3 followed (and not the enhanced procedures described in section 3 of
of this document), it is important to note that type 0 or type 1 this document), it is important to note that type 0 or type 1 packets
packets may be received by the decompressor during the first half of may be received by the decompressor during the first half of the
the transition procedure, and these packets must not mistakenly be transition procedure, and these packets must not mistakenly be
interpreted as the packets sent by the compressor to indicate interpreted as the packets sent by the compressor to indicate
completed transition. The decompressor side must therefore keep track completed transition. The decompressor side must therefore keep track
of the transition status, e.g. with an additional parameter. If the of the transition status, e.g. with an additional parameter. If the
enhanced transition procedures described in section 3 of this enhanced transition procedures described in section 3 of this
document are used, the D_TRANS parameter can serve this purpose since document are used, the D_TRANS parameter can serve this purpose since
its definition and usage is slightly modified. its definition and usage is slightly modified.
7.7. How to respond to lost feedback links? 7.8. How to respond to lost feedback links?
One potential issue that might have to be considered, depending on One potential issue that might have to be considered, depending on
link technology, is whether feedback links might get lost, and in link technology, is whether feedback links might get lost, and in
such cases how this is handled. When the compressor is notified that such cases how this is handled. When the compressor is notified that
the feedback channel is down, the compressor must be able to handle the feedback channel is down, the compressor must be able to handle
it by restarting compression with creating a new context. Creating a it by restarting compression with creating a new context. Creating a
new context also implies to use a new CID value. new context also implies to use a new CID value.
Generally, feedback links are not expected to disappear when once Generally, feedback links are not expected to disappear when once
present, but it should be noted that this might be the case for present, but it should be noted that this might be the case for
certain link technologies. certain link technologies.
7.8. What does "presumed zero if absent" mean on page 88? 7.9. What does "presumed zero if absent" mean on page 88?
On page 88, RFC 3095 says that R-P contains the absolute value of RTP On page 88, RFC 3095 says that R-P contains the absolute value of RTP
Padding bit and it's presumed zero if absent. It could be absent Padding bit and it's presumed zero if absent. It could be absent
from RTP header flags and fields, from the extension type 3 or from from RTP header flags and fields, from the extension type 3 or from
the ROHC packet. It's been agreed that the RTP padding bit is the ROHC packet. It's been agreed that the RTP padding bit is
presumed zero if absent from the RTP header flags. presumed zero if absent from the RTP header flags.
7.9. UOR-2 in profile 2 (UDP) 7.10. UOR-2 in profile 2 (UDP)
One single new format is defined for UOR-2 in profile 2, which One single new format is defined for UOR-2 in profile 2, which
replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) formats from profile replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) formats from profile
1. The same UOR-2 format is thus used independent of if there are IP 1. The same UOR-2 format is thus used independent of if there are IP
headers with a corresponding RND=1 or not. headers with a corresponding RND=1 or not.
7.10. Sequence number LSB's in IP extension headers 7.11. Sequence number LSB's in IP extension headers
In section 5.8.5, formats are defined for compression of IP extension In section 5.8.5, formats are defined for compression of IP extension
header fields. These include compressed sequence number fields, and header fields. These include compressed sequence number fields, and
it is said that these fields contain "LSB of sequence number". This it is said that these fields contain "LSB of sequence number". This
means these sequence numbers are not "LSB-encoded" as e.g. the RTP means these sequence numbers are not "LSB-encoded" as e.g. the RTP
sequence number with an interpretation interval, but are actually sequence number with an interpretation interval, but are actually
just the LSB's of the uncompressed fields. just the LSB's of the uncompressed fields.
8. ROHC negotiation clarifications 8. ROHC negotiation clarifications
skipping to change at page 13, line 8 skipping to change at page 13, line 16
to the compressor the set of profiles supported by the decompressor, to the compressor the set of profiles supported by the decompressor,
and when multiple variants of the same profile are available, also and when multiple variants of the same profile are available, also
provide means for the decompressor to know which variant will be used provide means for the decompressor to know which variant will be used
by the compressor. This basically means that the PROFILES set after by the compressor. This basically means that the PROFILES set after
negotiation must not include more than one variant of the same negotiation must not include more than one variant of the same
profile. profile.
9. PROFILES suboption in ROHC-over-PPP 9. PROFILES suboption in ROHC-over-PPP
The logical union of suboptions for IPCP and IPV6CP negotiations, as The logical union of suboptions for IPCP and IPV6CP negotiations, as
specified by ROHC over PPP [RFC-3241], can not be used for the specified by ROHC over PPP [2], can not be used for the PROFILES
PROFILES suboption, as the whole union would then have to be suboption, as the whole union would then have to be considered within
considered within each of the two IPCP negotiations, to avoid getting each of the two IPCP negotiations, to avoid getting an ambiguous
an ambiguous profile set. An implementation of RFC 3241 must profile set. An implementation of RFC 3241 must therefore make sure
therefore make sure the same profile set is negotiated for both IPv4 the same profile set is negotiated for both IPv4 and IPv6 (IPCP and
and IPv6 (IPCP and IPV6CP). IPV6CP).
10. Test Configuration 10. Test Configuration
ROHC is used to compress IP/UDP/RTP, IP/UDP and IP/ESP headers, thus ROHC is used to compress IP/UDP/RTP, IP/UDP and IP/ESP headers, thus
every ROHC implementation has an interface that can send and receive every ROHC implementation has an interface that can send and receive
IP packets (i.e. Ethernet). On the other hand, there must be an IP packets (i.e. Ethernet). On the other hand, there must be an
interface (a serial link for example) or other means of transport (an interface (a serial link for example) or other means of transport (an
IP/UDP flow), which can transmit ROHC packets. Having these two IP/UDP flow), which can transmit ROHC packets. Having these two
interfaces several configurations can be set up. The figure below interfaces several configurations can be set up. The figure below
shows sample configurations that can be used for testing a ROHC shows sample configurations that can be used for testing a ROHC
skipping to change at page 13, line 36 skipping to change at page 13, line 44
IP/UDP/RTP +------------+ ROHC +--------------+ IP/UDP/RTP IP/UDP/RTP +------------+ ROHC +--------------+ IP/UDP/RTP
packets | ROHC | packets | ROHC | packets packets | ROHC | packets | ROHC | packets
---------->| Compressor |-----> ----->| Decompressor |----------> ---------->| Compressor |-----> ----->| Decompressor |---------->
+------------+ +--------------+ +------------+ +--------------+
Unfortunately, comparing the IP/UDP/RTP packets at the endpoints can Unfortunately, comparing the IP/UDP/RTP packets at the endpoints can
only show whether the reconstructed stream differs from the original only show whether the reconstructed stream differs from the original
or not. In order to identify the place of the error more detailed or not. In order to identify the place of the error more detailed
tests are needed. The next figure shows another possible scenario: tests are needed. The next figure shows another possible scenario:
IP/UDP/RTP +------------+ ROHC IP/UDP/RTP +--------------+ ROHC IP/UDP/RTP +------------+ ROHC ROHC +--------------+ IP/UDP/RTP
packets | ROHC | packets packets | ROHC | packets packets | ROHC | packets packets | ROHC | packets
+----->| Compressor |----->+ +<-----| Decompressor |<-----+ +----->| Compressor |----->+ +----->| Decompressor |----->+
| +------------+ | | +--------------+ | | +------------+ | | +--------------+ |
| | | | | | | |
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
| | Test | | | | Test | | | | Test | | | | Test | |
+<-----| Equipment |<-----+ +------>| Equipment |------>+ +<-----| Equipment |<-----+ +<------| Equipment |<------+
+------------+ +------------+ +------------+ +------------+
In the first case, the test equipment generates the RTP stream and In the first case, the test equipment generates the RTP stream and
also acts as a ROHC decompressor. The tester must recognize if the also acts as a ROHC decompressor. The tester must recognize if the
original RTP stream was compressed in a bad way and gives an alarm. original RTP stream was compressed in a bad way and gives an alarm.
In the second case, it is the test equipment that sends the In the second case, it is the test equipment that sends the
compressed ROHC packets and the Decompressor reconstructs the RTP compressed ROHC packets and the Decompressor reconstructs the RTP
stream. Since the tester knows the ROHC packets and the stream. Since the tester knows the ROHC packets and the
reconstructed RTP stream it can detect if the Decompressor makes a reconstructed RTP stream it can detect if the Decompressor makes a
mistake. mistake.
11. Security considerations 11. Security considerations
skipping to change at page 14, line 7 skipping to change at page 14, line 15
also acts as a ROHC decompressor. The tester must recognize if the also acts as a ROHC decompressor. The tester must recognize if the
original RTP stream was compressed in a bad way and gives an alarm. original RTP stream was compressed in a bad way and gives an alarm.
In the second case, it is the test equipment that sends the In the second case, it is the test equipment that sends the
compressed ROHC packets and the Decompressor reconstructs the RTP compressed ROHC packets and the Decompressor reconstructs the RTP
stream. Since the tester knows the ROHC packets and the stream. Since the tester knows the ROHC packets and the
reconstructed RTP stream it can detect if the Decompressor makes a reconstructed RTP stream it can detect if the Decompressor makes a
mistake. mistake.
11. Security considerations 11. Security considerations
This document provides a number of clarifications to [RFC-3095], but This document provides a number of clarifications to [1], but it does
it does not make any changes or additions to the protocol. As a not make any changes or additions to the protocol. As a consequence,
consequence, the security considerations of [RFC-3095] apply without the security considerations of [1] apply without additions.
additions.
12. Acknowledgment 12. Acknowledgment
The authors would like thank Vicknesan Ayadurai, Carsten Bormann, The authors would like thank Vicknesan Ayadurai, Carsten Bormann,
Mikael Degermark, Ghyslain Pelletier, Zhigang Liu, Abigail Surtees, Mikael Degermark, Ghyslain Pelletier, Zhigang Liu, Abigail Surtees,
Mark West, Kristofer Sandlund, Tommy Lundemo, Alan Kennington and Mark West, Kristofer Sandlund, Tommy Lundemo, Alan Kennington and
Remi Pelland for their contributions and comments. Remi Pelland for their contributions and comments.
13. References 13. References
[RFC-3095] C. Bormann, Editor, "RObust Header Compression (ROHC)", [1] C. Bormann, et al., "RObust Header Compression (ROHC)",
RFC 3095, July 2001. RFC 3095, July 2001.
[RFC-3241] C. Bormann, "Robust Header Compression (ROHC) over PPP", [2] C. Bormann, "Robust Header Compression (ROHC) over PPP",
RFC 3241, April 2002. RFC 3241, April 2002.
[RFC-1662] W. Simpson, Editor, "PPP in HDLC-like Framing", [3] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994.
RFC 1662, July 1994.
14. Authors' Addresses 14. Authors' Addresses
Lars-Erik Jonsson Lars-Erik Jonsson
Ericsson AB Ericsson AB
Box 920 Box 920
SE-971 28 Lulea, Sweden SE-971 28 Lulea, Sweden
Phone: +46 920 20 21 07 Phone: +46 70 513 56 21
Fax: +46 920 20 20 99 Fax: +46 920 20 20 99
EMail: lars-erik.jonsson@ericsson.com EMail: lars-erik.jonsson@ericsson.com
Peter Kremer Peter Kremer
Conformance and Software Test Laboratory Conformance and Software Test Laboratory
Ericsson Hungary Ericsson Hungary
H-1300 Bp. 3., P.O. Box 107, HUNGARY H-1300 Bp. 3., P.O. Box 107, HUNGARY
Phone: +36-1-437-7033 Phone: +36-1-437-7033
Fax: +36-1-437-7767 Fax: +36-1-437-7767
Email: Peter.Kremer@ericsson.com Email: Peter.Kremer@ericsson.com
Appendix A. Sample CRC algorithm Appendix A - Sample CRC algorithm
#!/usr/bin/perl -w #!/usr/bin/perl -w
use strict; use strict;
#================================= #=================================
# #
# ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02 # ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
# #
# This little demo shows the three types of CRC in use in RFC 3095, # This little demo shows the three types of CRC in use in RFC 3095,
# the robust header compression standard. Type your data in # the robust header compression standard. Type your data in
# hexadecimal form and the press Control+D. # hexadecimal form and the press Control+D.
skipping to change at page 17, line 5 skipping to change at page 17, line 5
do_crc(7, 0x79, $string); do_crc(7, 0x79, $string);
#--------------------------------- #---------------------------------
# #
# 3-bit FO/SO CRC # 3-bit FO/SO CRC
# #
# C(x) = x^0 + x^1 + x^3 # C(x) = x^0 + x^1 + x^3
# #
do_crc(3, 0x6, $string); do_crc(3, 0x6, $string);
Appendix B. Potential improvements in updated profiles Appendix B - Potential improvements in updated profiles
Regarding the CC field and CSRC list, the following interpretation Regarding the CC field and CSRC list, the following interpretation
has been proposed as an improvement: has been proposed as an improvement:
"It should be noted that when the value of this CC field is equal to "It should be noted that when the value of this CC field is equal to
zero, there is no Generic CSRC list present in the dynamic chain, zero, there is no Generic CSRC list present in the dynamic chain,
i.e. the field comment should have said "variable length, present if i.e. the field comment should have said "variable length, present if
CC > 0". " CC > 0". "<introduction text>
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Appendix C - Issues identified but not yet resolved
This document and translations of it may be copied and furnished to These issues have been identified but are still under discussion on
others, and derivative works that comment on or otherwise explain it the ROHC WG mail list. Resolutions to these issues will have to be
or assist in its implementation may be prepared, copied, published added in later revisions of this document.
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be * Mode inheritance in case of context re-use
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an * Slope used to compress/decompress RTP Timestamp
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
This Internet-Draft expires March 23, 2004. Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Disclaimer of Validity
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 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.
This Internet-Draft expires December 9, 2004.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/