draft-ietf-rohc-rtp-impl-guide-05.txt   draft-ietf-rohc-rtp-impl-guide-06.txt 
Network Working Group L-E. Jonsson, Ericsson Network Working Group L-E. Jonsson, Ericsson
INTERNET-DRAFT P. Kremer, Ericsson INTERNET-DRAFT P. Kremer, Ericsson
Expires: December 2004 June 9, 2004 Expires: April 2005 October 5, 2004
ROHC Implementer's Guide ROHC Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-05.txt> <draft-ietf-rohc-rtp-impl-guide-06.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, I (we) certify that any applicable By submitting this Internet-Draft, I (we) certify that any applicable
patent or other IPR claims of which I am (we are) aware have been 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 disclosed, and any of which I (we) become aware will be disclosed, in
accordance with RFC 3668 (BCP 79). accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, I (we) accept the provisions of By submitting this Internet-Draft, I (we) accept the provisions of
Section 3 of RFC 3667 (BCP 78). Section 3 of RFC 3667 (BCP 78).
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 [1], which defines the framework and four profiles of points of ROHC [1], which defines the framework and four profiles of
a robust and efficient header compression scheme. These points have a robust and efficient header compression scheme. The members of the
been identified by the members of the ROHC working group during ROHC working group have identified these issues during implementation
different interoperability test events. and at the various 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.........................4 2.4. CRC coverage of the ESP NULL header.........................4
3. Enhanced mode transition procedures..............................4 3. Enhanced mode transition procedures..............................4
skipping to change at page 2, line 33 skipping to change at page 2, line 33
5.1. Generic extension header list...............................7 5.1. Generic extension header list...............................7
5.2. CSRC list items in RTP dynamic chain........................8 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. Context management and CID/context re-use.......................10
7.1. Meaning of NBO.............................................10 7.1. Compressor and decompressor MUST keep MAX_CID contexts.....10
7.2. IP-ID......................................................10 7.2. CID/context re-use.........................................10
7.3. Extension-3 in UO-1-ID packets.............................10 7.2.1. Re-using a CID/context with the same profile..........10
7.4. Extension-3 in UOR-2* packets..............................10 7.2.2. Re-using a CID/context with a different profile.......11
7.5. Multiple SN options in one feedback packet.................11 7.3. Context updating properties for IR packets.................11
7.6. Multiple CRC options in one feedback packet................11 8. Other protocol clarifications...................................11
7.7. Packet decoding during mode transition.....................11 8.1. Meaning of NBO.............................................11
7.8. How to respond to lost feedback links?.....................11 8.2. IP-ID......................................................11
7.9. What does "presumed zero if absent" mean on page 88?.......12 8.3. Extension-3 in UO-1-ID packets.............................12
7.10. UOR-2 in profile 2 (UDP)..................................12 8.4. Extension-3 in UOR-2* packets..............................12
7.11. Sequence number LSB's in IP extension headers.............12 8.5. Multiple SN options in one feedback packet.................12
8. ROHC negotiation clarifications.................................12 8.6. Multiple CRC options in one feedback packet................13
9. PROFILES suboption in ROHC-over-PPP.............................13 8.7. Packet decoding during mode transition.....................13
10. Test Configuration.............................................13 8.8. How to respond to lost feedback links?.....................13
11. Security considerations........................................14 8.9. What does "presumed zero if absent" mean on page 88?.......13
12. Acknowledgment.................................................14 8.10. UOR-2 in profile 2 (UDP)..................................14
13. References.....................................................14 8.11. Sequence number LSB's in IP extension headers.............14
14. Authors' Addresses.............................................14 9. ROHC negotiation clarifications.................................14
Appendix A - Sample CRC algorithm..................................15 10. PROFILES suboption in ROHC-over-PPP............................15
Appendix B - Potential improvements in updated profiles............17 11. Test Configuration.............................................15
Appendix C - Issues identified but not yet resolved................17 12. Security considerations........................................16
13. Acknowledgment.................................................16
14. References.....................................................16
15. Authors' Addresses.............................................16
Appendix A - Sample CRC algorithm..................................17
Appendix B - Potential improvements in updated profiles............19
Appendix C - Issues identified but not yet resolved................19
1. Introduction 1. Introduction
ROHC [1] defines a robust and efficient header compression algorithm, ROHC [1] defines a robust and efficient header compression algorithm,
and its description is rather long and complex. During the and its description is rather long and complex. During the
implementation and the interoperability tests of the algorithm some implementation and the interoperability tests of the algorithm some
unclear areas have been identified. This document tries to collect unclear areas have been identified. This document tries to 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 [1], if not stated otherwise. references in this document refer to [1], if not stated otherwise.
skipping to change at page 7, line 9 skipping to change at page 7, line 9
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
4.5.4, p = 2^(k-1) - 1, is used for TS. Otherwise, the interval of 4.5.4, p = 2^(k-1) - 1, is used for TS. Otherwise, the interval of
section 5.7, p = 2^(k-2) - 1, is used for TS with regular W-LSB section 5.7, p = 2^(k-2) - 1, is used for TS with regular W-LSB
encoding. encoding.
Since two different p-values are used, the compressor must take this Since two different p-values are used, the compressor must take this
into account during the process of enabling timer-based compression. into account during the process of enabling timer-based compression.
Before timer-based compression can be used, the decompressor will Before timer-based compression can be used, the decompressor will
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. Further, the compressor has to send (on a per-
basis) a non-zero TIME_STRIDE to the decompressor. context 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 keep k large enough
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.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
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
sequence number fields of extension headers are also updated." sequence number fields of extension headers are also updated."
7. Other protocol clarifications 7. Context management and CID/context re-use
7.1. Meaning of NBO 7.1. Compressor and decompressor MUST keep MAX_CID contexts
As part of the negotiated channel parameters, compressor and
decompressor have through the MAX_CID parameter agreed on the highest
context identification (CID) number to be used. By agreeing on
MAX_CID, both compressor and decompressor also agrees to provide
memory resources to host at lest MAX_CID+1 contexts, and an
established context with CID within this negotiated space MUST be
kept by both compressor and decompressor until either the CID gets
re-used, or the channel is taken down or re-negotiated.
7.2. CID/context re-use
As part of the channel negotiation, the maximal number of active
contexts supported is negotiated between the compressor and the
decompressor through the MAX_CID parameter. The value of MAX_CID can
of course vary enormously between different link scenarios, as well
as the load in terms of actual packet streams to compress. Depending
on link technology, the ROHC channel lifetime will also vary from
almost permanent to rather short-lived. However, in general it is not
expected that resources will be allocated for more contexts than what
can reasonably be expected to be active concurrently over the link.
As a consequence hereof, context identifiers (CIDs) and context
memory are resources that will have to be re-used by the compressor
as part of what can be considered normal operation.
How context resources are re-used is in RFC 3095 [1] and subsequent
ROHC standards basically left unspecified and up to implementation.
However, re-using a CID and its allocated memory is not always as
simple as initiating a contexts with a previously unused CID. Because
some profiles can be operating in various modes where packet formats
vary depending on current mode, care has to be taken to ensure that
the old context data will be completely and safely overwritten,
eliminating the risk of undesired side effects from interactions
between old and new context data.
On a high level, CID/context re-use can be of two kinds, either re-
use for a new context based on the same profile as the old context,
or for a new context based on a different profile. These cases, are
discussed separately in the following two subsections.
7.2.1. Re-using a CID/context with the same profile
For multi-mode profiles, such as those defined in RFC 3095 [1], when
a CID/context is re-used for a new context based on the same profile
as the old context, the current mode of operation MUST be inherited
from the old to the new context. The reason for this is that there is
no reliable way for the compressor to inform the decompressor that a
CID/context re-use is happening. The decompressor can thus not be
expected to flush the context memory for the CID, and there is no way
to trigger a safe mode switching, which requires a decompressor-
initiated handshake procedure, as defined in section 5.6 of [1].
It should be noted that the rule of mode inheritance applies also
when the CONTEXT_REINITIALIZATION signal is used to reinitiate an
entire context.
7.2.2. Re-using a CID/context with a different profile
When a CID is re-used for a new context based on a different profile
than the old context, operation with that context MUST start in the
initial mode of the profile (if it is a multi-mode profile). This
applies both to IR-initiated new contexts and profile downgrades with
IR-DYN (e.g. the IP/UDP/RTP->IP/UDP downgrade in [1] section 5.11.1).
A CID for an R-mode operating context SHOULD NOT be re-used for a new
context based on a different profile than the old context, because of
the R-0/R-1 misinterpretation risk (these packets have no CRC). If a
compressor still wants or has to do this, the compressor must be very
careful to minimize the misinterpretation risk, e.g. by not using
packets of types beginning with 00 or 10 before the compressor is
highly confident that the new context has successfully been initiated
at the decompressor.
7.3. Context updating properties for IR packets
It should be noted that an IR does not flush the whole context, but
updates all fields carried in the IR header. Similarly, an IR without
a dynamic chain simply updates the static part of the context, while
the rest of the context is left unchanged.
8. Other protocol clarifications
8.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 8.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. Compressed packets contain this header's 'Identification' field. Compressed packets contain this
compressed value (IP-ID), while IR packets with dynamic chain and IR- compressed value (IP-ID), while IR packets with dynamic chain and IR-
DYN packets transmit the original, uncompressed Identification field DYN packets transmit the original, uncompressed Identification field
value. The IP-ID field always represents the Identification value of value. The IP-ID field always represents the Identification value of
the innermost IPv4 header whose corresponding RND flag is not 1. the innermost IPv4 header whose corresponding RND flag is not 1.
If RND or RND2 is set to 1, the corresponding IP-ID(s) is(are) sent If RND or RND2 is set to 1, the corresponding IP-ID(s) is(are) sent
as 16-bit original Identification value(s) at the end of the as 16-bit original Identification value(s) at the end of the
compressed base header, according to the IP-ID description (see the compressed base header, according to the IP-ID description (see the
beginning of section 5.7). beginning of section 5.7).
It should be noted that when RND*=0, IP-ID is always compressed, i.e. 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 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. even when 16 bits of IP-ID is sent in extension 3.
7.3. Extension-3 in UO-1-ID packets 8.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,
i.e. that would violate the base condition for UO-1-ID (at least one i.e. that would violate the base condition for UO-1-ID (at least one
RND value must be 0). 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.
7.4. Extension-3 in UOR-2* packets 8.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) changes the interpretation header in the extension (e.g. NBO or RND) changes the interpretation
of fields in UOR-2* packets. In these cases, when a flag changes in of fields in UOR-2* packets. In these cases, when a flag changes in
Extension-3, a decompressor should re-parse the UOR-2* packet. Extension-3, a decompressor should re-parse the UOR-2* packet.
7.5. Multiple SN options in one feedback packet 8.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 should be able to process multiple SN options in one A compressor should be able to process multiple SN options in one
feedback packet. feedback packet.
7.6. Multiple CRC options in one feedback packet 8.6. Multiple CRC options in one feedback packet
Although it is never required to have more than one single CRC option Although it is never required to have more than one single CRC option
in a feedback packet, having multiple CRC options is still allowed. in a feedback packet, having multiple CRC options is still allowed.
If multiple CRC options are included, all such CRC options will be If multiple CRC options are included, all such CRC options will be
identical, as they will be calculated over the same header. identical, as they will be calculated over the same header.
7.7. Packet decoding during mode transition 8.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.
skipping to change at page 11, line 48 skipping to change at page 13, line 36
this document), it is important to note that type 0 or type 1 packets 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 the may be received by the decompressor during the first half of 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.8. How to respond to lost feedback links? 8.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.9. What does "presumed zero if absent" mean on page 88? 8.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.10. UOR-2 in profile 2 (UDP) 8.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.11. Sequence number LSB's in IP extension headers 8.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 9. ROHC negotiation clarifications
Section 4.1 states that the link layer must provide means to According to section 4.1, 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 variant indicate the actual profile, and the 8 MSB bits indicate the variant
skipping to change at page 13, line 13 skipping to change at page 15, line 5
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 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 10. 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 [2], can not be used for the PROFILES specified by ROHC over PPP [2], can not be used for the PROFILES
suboption, as the whole union would then have to be considered within suboption, as the whole union would then have to be considered within
each of the two IPCP negotiations, to avoid getting an ambiguous each of the two IPCP negotiations, to avoid getting an ambiguous
profile set. An implementation of RFC 3241 must therefore make sure profile set. An implementation of RFC 3241 must therefore make sure
the same profile set is negotiated for both IPv4 and IPv6 (IPCP and the same profile set is negotiated for both IPv4 and IPv6 (IPCP and
IPV6CP). IPV6CP).
10. Test Configuration 11. 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 14, line 4 skipping to change at page 15, line 45
IP/UDP/RTP +------------+ ROHC ROHC +--------------+ IP/UDP/RTP 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 12. Security considerations
This document provides a number of clarifications to [1], but it does This document provides a number of clarifications to [1], but it does
not make any changes or additions to the protocol. As a consequence, not make any changes or additions to the protocol. As a consequence,
the security considerations of [1] apply without additions. the security considerations of [1] apply without additions.
12. Acknowledgment 13. Acknowledgment
The authors would like thank Vicknesan Ayadurai, Carsten Bormann, The authors would like to 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 14. References
[1] C. Bormann, et al., "RObust Header Compression (ROHC)", [1] C. Bormann, et al., "RObust Header Compression (ROHC)",
RFC 3095, July 2001. RFC 3095, July 2001.
[2] 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.
[3] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994. [3] W. Simpson, "PPP in HDLC-like Framing", RFC 1662, July 1994.
14. Authors' Addresses 15. 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 70 513 56 21 Phone: +46 8 404 29 61
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 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,
skipping to change at page 17, line 21 skipping to change at page 19, line 21
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". "<introduction text> CC > 0". "<introduction text>
Appendix C - Issues identified but not yet resolved Appendix C - Issues identified but not yet resolved
These issues have been identified but are still under discussion on These issues have been identified but are still under discussion on
the ROHC WG mail list. Resolutions to these issues will have to be the ROHC WG mail list. Resolutions to these issues will have to be
added in later revisions of this document. added in later revisions of this document.
* Mode inheritance in case of context re-use
* Slope used to compress/decompress RTP Timestamp * Slope used to compress/decompress RTP Timestamp
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires December 9, 2004. This Internet-Draft expires April 5, 2005.
 End of changes. 

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