draft-ietf-rohc-rtp-impl-guide-02.txt   draft-ietf-rohc-rtp-impl-guide-03.txt 
Network Working Group Peter Kremer, Ericsson Network Working Group Peter Kremer, Ericsson
INTERNET-DRAFT Lars-Erik Jonsson, Ericsson INTERNET-DRAFT Lars-Erik Jonsson, Ericsson
Expires: April 2003 October 31, 2002 Expires: August 2003 February 28, 2003
ROHC Implementer's Guide ROHC Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-02.txt> <draft-ietf-rohc-rtp-impl-guide-03.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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.
skipping to change at page 2, line 8 skipping to change at page 2, line 8
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 [RFC 3095], which defines the framework and four
profiles of a robust and efficient header compression scheme. These profiles of a robust and efficient header compression scheme. These
points have been identified by the members of the ROHC working group points have been identified by the members of the ROHC working group
during different interoperability test events. during different interoperability test events.
Table of Contents Table of Contents
1. Introduction....................................................2 1. Introduction....................................................2
2. CRC Calculation.................................................2 2. CRC Calculation.................................................3
3. Enhanced mode transition procedures.............................3 3. Enhanced mode transition procedures.............................3
3.1. Modified transition logic for enhanced transitions............3 3.1. Modified transition logic for enhanced transitions............3
3.2. Transition from Reliable to Optimistic mode...................4 3.2. Transition from Reliable to Optimistic mode...................4
3.3. Transition to Unidirectional mode.............................5 3.3. Transition to Unidirectional mode.............................5
4. Other protocol clarifications...................................5 4. Other protocol clarifications...................................5
4.1. Padding octet in CRC..........................................5 4.1. Padding octet in CRC..........................................5
4.2. Interpretation intervals for TS encoding......................5 4.2. Timestamp encoding considerations.............................5
4.3. Generic extension header list.................................6 4.2.1. Encoding of TS values.......................................5
4.4. Generic CSRC list.............................................6 4.2.2. Interpretation intervals for TS encoding....................5
4.5. RTP dynamic chain.............................................6 4.2.3. Recalculating TS_OFFSET.....................................6
4.6. Meaning of NBO................................................7 4.3. List compression issues.......................................6
4.7. Implicit updates..............................................7 4.3.1. Generic extension header list...............................6
4.8. IP-ID.........................................................7 4.3.2. CSRC list items in RTP dynamic chain........................6
4.9. Extension-3 in UO-1-ID packets................................7 4.3.3. RTP dynamic chain...........................................7
4.10. Extension-3 in UOR-2* packets................................7 4.3.4. CSRC list in UO-1-ID packets................................7
4.11. Multiple SN options in one feedback packet...................8 4.3.5. Bit masks in list compression...............................7
4.12. Packet decoding during mode transition.......................8 4.4. Meaning of NBO................................................8
4.13. How to respond to lost feedback links?.......................8 4.5. Implicit updates..............................................8
4.14. What does "presumed zero if absent" mean on page 88?.........9 4.6. IP-ID.........................................................8
4.15. CSRC list in UO-1-ID packets.................................9 4.7. Extension-3 in UO-1-ID packets................................8
5. ROHC negotiation clarifications.................................9 4.8. Extension-3 in UOR-2* packets.................................9
6. Test Configuration.............................................10 4.9. Multiple SN options in one feedback packet....................9
7. Security considerations........................................10 4.10. Packet decoding during mode transition.......................9
8. Acknowledgment.................................................11 4.11. How to respond to lost feedback links?.......................9
9. References.....................................................11 4.12. What does "presumed zero if absent" mean on page 88?........10
10. Authors' Addresses............................................11 4.13. UOR-2 in profile 2 (UDP)....................................10
Appendix A. Sample CRC algorithm..................................12 5. ROHC negotiation clarifications................................10
6. PROFILES suboption in ROHC-over-PPP............................11
7. Test Configuration.............................................11
8. Security considerations........................................12
9. Acknowledgment.................................................12
10. References....................................................12
11. Authors' Addresses............................................12
Appendix A. Sample CRC algorithm..................................13
1. Introduction 1. Introduction
ROHC [RFC 3095] addresses a robust and efficient header compression ROHC [RFC 3095] addresses a robust and efficient header compression
algorithm and as a such its description is long and complex. During algorithm and as a such its description is long and complex. During
the implementation and the interoperability tests of the algorithm the implementation and the interoperability tests of the algorithm
some unclear areas have been identified. This document tries to some unclear areas have been identified. This document tries to
collect and clarify these points. Note that all section and chapter collect 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 [RFC-3095], if not stated
otherwise. otherwise.
skipping to change at page 5, line 40 skipping to change at page 5, line 40
4. Other protocol clarifications 4. Other protocol clarifications
4.1. Padding octet in CRC 4.1. 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.
4.2. Interpretation intervals for TS encoding 4.2. Timestamp encoding considerations
4.2.1. Encoding of TS values
RTP Timestamp values (TS) are always encoded using W-LSB encoding,
both when sent scaled and when sent unscaled. For TS values sent in
Extension 3, W-LSB encoded values are sent using the self-describing
variable-length format (section 4.5.6), and this applies to both
scaled and unscaled values.
4.2.2. Interpretation intervals for TS encoding
Section 4.5.4 defines the interpretation interval, p, for timer-based Section 4.5.4 defines the interpretation interval, p, for timer-based
compression of the RTP timestamp. However, Section 5.7 defines a compression of the RTP timestamp. However, Section 5.7 defines a
different interpretation interval, which is defined as the different interpretation interval, which is defined as the
interpretation interval to use for all TS values. It is thus unclear interpretation interval to use for all TS values. It is thus unclear
which p-value to use, at least for timer-based compression. which p-value to use, at least for timer-based compression.
The way this should be interpreted is that the p-value differs The way this should be interpreted is that the p-value differs
depending on whether timer-based compression is enabled or not. For depending on whether timer-based compression is enabled or not. For
timer-based compression, the interpretation interval of section timer-based compression, the interpretation interval of section
skipping to change at page 6, line 18 skipping to change at page 6, line 27
have to inform the compressor (on a per-channel basis) about its have to inform the compressor (on a per-channel basis) about its
clock resolution, and the compressor has to send (on a per-context clock resolution, and the compressor has to send (on a per-context
basis) a non-zero TIME_STRIDE to the decompressor. basis) a non-zero TIME_STRIDE to the decompressor.
When the compressor is confident that the decompressor has received When the compressor is confident that the decompressor has received
the TIME_STRIDE value, it can switch to timer-based compression. the TIME_STRIDE value, it can switch to timer-based compression.
During this transition from window-based compression to timer-based During this transition from window-based compression to timer-based
compression, it is necessary that the compressor keeps k large enough compression, it is necessary that the compressor keeps k large enough
to cover both interpretation intervals. to cover both interpretation intervals.
4.3. Generic extension header list 4.2.3. Recalculating TS_OFFSET
TS can be sent unscaled if the TS value change does not match the
established TS_STRIDE, but the TS_STRIDE might still stay unchanged.
To ensure correct decompression of subsequent packets, the
decompressor should therefore always recalculate the RTP TS modulo,
TS_OFFSET, when a packet with an unscaled TS value is received.
4.3. List compression issues
4.3.1. Generic extension header list
Section 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
present, so its length is one octet, at least. If the 'GP' bit in present, so its length is one octet, at least. If the 'GP' bit in
the first octet is set to 1 then the length of the list is two the first octet is set to 1 then the length of the list is two
octets, even if the list is empty. octets, even if the list is empty.
4.4. Generic CSRC list 4.3.2. CSRC list items in RTP dynamic chain
Section 5.7.7.6 defines the static and dynamic parts of the RTP Section 5.7.7.6 defines the static and dynamic parts of the RTP
header. This section indicates a 'Generic CSRC list' field in the header. This section indicates a 'Generic CSRC list' field in the
dynamic chain, which has a variable length. This field uses the same dynamic chain, which has a variable length. This field uses the same
encoding rules as the 'Generic extension header list' in the IPv4 encoding rules as the 'Generic extension header list' in the IPv4
header, so the same rules apply to its length. header, so the same rules apply to its length.
4.5. RTP dynamic chain 4.3.3. RTP dynamic chain
Section 5.7.7.6 defines the static and dynamic parts of the RTP Section 5.7.7.6 defines the static and dynamic parts of the RTP
header. This section indicates a 'CC' field in the dynamic chain. header. In the dynamic part, a 'CC' field indicates the number of
The same field can be found in the 'Generic CSRC list' with the same CSRC items present in the 'Generic CSRC list'. It should be noted
meaning. In order to decode a compressed packet correctly it's that when the value of this CC field is equal to zero, there is no
necessary to know the 'CC' value because it has serious impact on the Generic CSRC list present in the dynamic chain, i.e. the field
packet's length. In normal case, the values of the fields are equal. comment should have said "variable length, present if CC > 0". A 'CC'
field can also be found within the 'Generic CSRC list' (when
present), and these fields would then have the same meaning. In order
to decode a compressed packet correctly it's necessary to know the
'CC' value because it has serious impact on the packet's length. In
normal case, the values of the fields are equal.
Proposed behavior if the values are different: Proposed behavior if the values are different:
Both fields are within the RTP dynamic part but only the second Both fields are within the RTP dynamic part but only the second
'CC' field resides inside the 'Generic CSRC list' together with 'CC' field resides inside the 'Generic CSRC list' together with
the XI items. Since the 'CC' value determines the number of XI the XI items. Since the 'CC' value determines the number of XI
items in the CSRC list and isn't used otherwise, the first CC items in the CSRC list and isn't used otherwise, the first CC
field should be ignored and only the second field (inside the CSRC field should be ignored and only the second field (inside the CSRC
list) should be used for incoming packets. For outgoing packets list) should be used for incoming packets. For outgoing packets
both fields should be set to the same value. both fields should be set to the same value.
4.6. Meaning of NBO 4.3.4. CSRC list in UO-1-ID packets
This section describes the situation when a UO-1-ID packet carries a
CSRC list. Compressed CSRC lists are encoded using Encoding Type 0
(section 5.7.5 and 5.8.6.1) and every list may have a unique
identifier (gen_id). The identifier is present in U/O-mode when the
compressor decides that it may use this list as a future reference.
On one hand, the decompressor shouldn't save the list because UO-1-ID
packets doesn't update the context. On the other hand, the
decompressor updates its translation table whenever an (Index, item)
pair is received (section 5.8.1). The decompressor must be able to
handle such a packet, thus it has to behave as described in the
latter case. According to section 5.8.1.2, the compressor must
increment Counter by 1.
4.3.5. Bit masks in list compression
A 7-bit or 15-bit mask may be used in the insertion and/or removal
schemes for compressed lists. It should be noted that even if a list
has more than 7 items, a 7-bit mask can be used as long as changes
are only applied in the first part of the reference list, and all
items with an index not covered by the 7-bit mask are then kept
unchanged.
4.4. 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. In IPv4 dynamic part (Section flag indicates unusual behavior. However, in IPv4 dynamic part
5.7.7.4), if the 'NBO' bit is set, it means that network byte order (Section 5.7.7.4), if the 'NBO' bit is set, it means that network
is used. Although, network byte order is the more common byte byte order is used.
alignment.
4.7. Implicit updates 4.5. Implicit updates
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
fields, either explicitly or implicitly, with an exception for the
UO-1-ID packet, which only updates TS, SN and IP-ID (see 5.7.3). In
UO-mode, all packets are updating packets, while in R-mode all
packets with a CRC are updating packets.
For example, a UO-0 packet contains the compressed RTP sequence 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 updates RTP timestamp and IPv4 ID,
implicitly. implicitly.
4.8. IP-ID 4.6. 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. Type 0, 1 and 2 packets contain the
compressed value (IP-ID), however IR packets with dynamic chain and compressed value (IP-ID), however IR packets with dynamic chain and
IR-DYN packets transmit the original, uncompressed value. This is IR-DYN packets transmit the original, uncompressed value. This is
because the dynamic part of the IPv4 header (Section 5.7.7.4) because the dynamic part of the IPv4 header (Section 5.7.7.4)
contains the 'Identification' field instead of the IP-ID. contains the 'Identification' field instead of the IP-ID.
4.9. Extension-3 in UO-1-ID packets 4.7. 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, values provided in extensions do not update the of UO-1-ID packets, it should be noted that values provided in
context, except those in other SN, TS and IP-ID fields (Section extensions do not update the context, with an exception for SN, TS
5.7.3.). Note, that SN, TS and IP-ID fields can also be sent in and IP-ID fields, which always update the context (Section 5.7.3.).
Extension-0, -1 and -2 and the other fields of Extension-3 don't It should also be noted that a UO-1-ID packet with Extension 3 must
update the context. never be sent with RND flags that changes the packet interpretation,
i.e. that would violate the base condition for UO-1-ID (at least one
RND value must be 0).
Besides, usage of Extension-3 in UO-1-ID can be useful to compress a 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.
4.10. Extension-3 in UOR-2* packets 4.8. 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). Some flags of the IP header extension updates the context (Section 5.7.4). Some flags of the IP
in the extension (e.g. NBO or RND) can change the interpretation of header in the extension (e.g. NBO or RND) can change the
fields in UOR-2* packets. interpretation of fields in UOR-2* packets. In these cases, when a
flag changes in Extension-3, a decompressor should re-parse the UOR-
In these cases, when a flag changes in Extension-3, a decompressor 2* packet.
should re-parse the UOR-2* packet.
4.11. Multiple SN options in one feedback packet 4.9. Multiple SN options in one feedback packet
The length of the sequence number field in the original RTP 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 - that wants to be conform to the specification - should
be able to process multiple SN options in one feedback packet. be able to process multiple SN options in one feedback packet.
4.12. Packet decoding during mode transition 4.10. 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.
skipping to change at page 8, line 46 skipping to change at page 9, line 50
of this document), it is important to note that type 0 or type 1 of this document), it is important to note that type 0 or type 1
packets may be received by the decompressor during the first half of packets may be received by the decompressor during the first half of
the transition procedure, and these packets must not mistakenly be the 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.
4.13. How to respond to lost feedback links? 4.11. 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.
4.14. What does "presumed zero if absent" mean on page 88? 4.12. What does "presumed zero if absent" mean on page 88?
On page 88, RFC 3095 says that R-P contains the absolute value of RTP 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.
4.15. CSRC list in UO-1-ID packets 4.13. UOR-2 in profile 2 (UDP)
This section describes the situation when a UO-1-ID packet carries a
CSRC list. Compressed CSRC lists are encoded using Encoding Type 0
(section 5.7.5 and 5.8.6.1) and every list may have a unique
identifier (gen_id). The identifier is present in U/O-mode when the
compressor decides that it may use this list as a future reference.
On one hand, the decompressor shouldn't save the list because UO-1-ID One single new format is defined for UOR-2 in profile 2, which
packets doesn't update the context. On the other hand, the replaces all three (UOR-2, UOR-2-ID, UOR-2-TS) formats from profile
decompressor updates its translation table whenever an (Index, item) 1. The same UOR-2 format is thus used independent of if there are IP
pair is received (section 5.8.1). The decompressor must be able to headers with a corresponding RND=1 or not.
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
increment Counter by 1.
5. ROHC negotiation clarifications 5. ROHC negotiation clarifications
Section 4.1 states that the link layer must provide means to Section 4.1 states that the link layer must provide means to
negotiate e.g. the channel parameters listed in section 5.1.1. One negotiate e.g. the channel parameters listed in section 5.1.1. One
of these parameters is the PROFILES parameter, which is said to be a of these parameters is the PROFILES parameter, which is said to be a
set of non-negative integers where each integer indicates a profile set of non-negative integers where each integer indicates a profile
supported by the decompressor. This can be interpreted as if it is supported by the decompressor. This can be interpreted as if it is
sufficient to have a mechanism to announce profile support from sufficient to have a mechanism to announce profile support from
decompressor to compressor. However, things are a little bit more decompressor to compressor. However, things are a little bit more
complicated than that. complicated than that.
Each profile is identified by a 16-bit value, where the 8 LSB bits Each profile is identified by a 16-bit value, where the 8 LSB bits
indicate the actual profile, and the 8 MSB bits indicate the version indicate the actual profile, and the 8 MSB bits indicate the variant
of that profile (see chapter 8). In the ROHC headers sent over the of that profile (see chapter 8). In the ROHC headers sent over the
link, the profile used is identified only with the 8 LSB bits, which link, the profile used is identified only with the 8 LSB bits, which
means that the compressor and decompressor must have agreed on which means that the compressor and decompressor must have agreed on which
version to use for each profile. This can be done in various ways, variant to use for each profile. This can be done in various ways,
but the negotiation protocol must provide means to do it. but the negotiation protocol must provide means to do it.
In conclusion, the negotiation protocol must be able to communicate In conclusion, the negotiation protocol must be able to communicate
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 versions 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 version 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 version of the same negotiation must not include more than one variant of the same
profile. profile.
6. Test Configuration 6. PROFILES suboption in ROHC-over-PPP
The logical union of suboptions for IPCP and IPV6CP negotiations, as
specified by ROHC over PPP [RFC-3241], can not be used for the
PROFILES suboption, as the whole union would then have to be
considered within each of the two IPCP negotiations, to avoid getting
an ambiguous profile set. An implementation of RFC 3241 must
therefore make sure the same profile set is negotiated for both IPv4
and IPv6 (IPCP and IPV6CP).
7. Test Configuration
ROHC is used to compress IP/UDP/RTP, IP/UDP and IP/ESP headers, thus 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
implementation: implementation:
skipping to change at page 10, line 48 skipping to change at page 12, line 5
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.
7. Security considerations 8. Security considerations
This document provides a number of clarifications to [RFC-3095], but This document provides a number of clarifications to [RFC-3095], but
it does not make any changes or additions to the protocol. As a it does not make any changes or additions to the protocol. As a
consequence, the security considerations of [RFC-3095] apply without consequence, the security considerations of [RFC-3095] apply without
additions. additions.
8. Acknowledgment 9. Acknowledgment
The authors would like thank Vicknesan Ayadurai, Carsten Bormann, The authors would like thank Vicknesan Ayadurai, Carsten Bormann,
Zhigang Liu, Abigail Surtees and Mark West for their contributions Zhigang Liu, Abigail Surtees and Mark West for their contributions
and comments. and comments.
9. References 10. References
[RFC-3095] C. Bormann, Editor, RObust Header Compression (ROHC), [RFC-3095] C. Bormann, Editor, "RObust Header Compression (ROHC)",
RFC 3095, July 2001. RFC 3095, July 2001.
[RFC-1662] W. Simpson, Editor, PPP in HDLC-like Framing, RFC 1662, [RFC-3241] C. Bormann, "Robust Header Compression (ROHC) over PPP",
July 1994. RFC 3241, April 2002.
10. Authors' Addresses [RFC-1662] W. Simpson, Editor, "PPP in HDLC-like Framing",
RFC 1662, July 1994.
11. Authors' Addresses
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
skipping to change at page 14, line 7 skipping to change at page 15, line 7
#--------------------------------- #---------------------------------
# #
# 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);
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 14, line 33 skipping to change at page 15, line 33
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires April 31, 2003. This Internet-Draft expires August 28, 2003.
 End of changes. 

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