draft-ietf-rohc-rtp-impl-guide-00.txt   draft-ietf-rohc-rtp-impl-guide-01.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: August 2002 February, 2002 Expires: December 2002 June, 2002
ROHC Implementer's Guide ROHC Implementer's Guide
<draft-ietf-rohc-rtp-impl-guide-00.txt> <draft-ietf-rohc-rtp-impl-guide-01.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 12 skipping to change at page 2, line 12
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.................................................2
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.............................4 3.3. Transition to Unidirectional mode.............................5
4. Other clarifications............................................5 4. Other clarifications............................................5
4.1. Padding octet in CRC..........................................5 4.1. Padding octet in CRC..........................................5
4.2. Transition to timer-based compression.........................5 4.2. Transition to timer-based compression.........................5
4.3. Generic extension header list.................................5 4.3. Generic extension header list.................................5
4.4. Generic CSRC list.............................................6 4.4. Generic CSRC list.............................................6
4.5. RTP dynamic chain.............................................6 4.5. RTP dynamic chain.............................................6
4.6. Meaning of NBO................................................6 4.6. Meaning of NBO................................................6
4.7. Implicit TS and IP-ID updates.................................6 4.7. Implicit updates..............................................6
4.8. IP-ID.........................................................6 4.8. IP-ID.........................................................7
4.9. Extension-3 in UO-1* packets..................................7 4.9. Extension-3 in UO-1-ID packets................................7
4.10. Extension-3 in UOR-2* packets................................7 4.10. Extension-3 in UOR-2* packets................................7
4.11. Multiple SN options in one feedback packet...................7 4.11. Multiple SN options in one feedback packet...................7
4.12. Packet decoding during mode transition.......................7 4.12. Packet decoding during mode transition.......................7
5. Test Configuration..............................................8 4.13. How to respond to lost feedback links?.......................8
6. References......................................................8 4.14. What does "presumed zero if absent" mean on page 88?.........8
7. Authors' Addresses..............................................9 4.15. CSRC list in UO-1-ID packets.................................8
Appendix A. Sample CRC algorithm..................................10 5. Test Configuration..............................................9
6. Acknowledgment..................................................9
7. References.....................................................10
8. Authors' Addresses.............................................10
Appendix A. Sample CRC algorithm..................................11
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. collect and clarify these points.
2. CRC Calculation 2. CRC Calculation
skipping to change at page 5, line 33 skipping to change at page 5, line 38
| | D_MODE= U | | D_MODE= U
4. Other clarifications 4. Other 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 an Add-CID octet for CID 0, either. a result, CRC doesn't cover the Add-CID octet for CID 0, either.
4.2. Transition to timer-based compression 4.2. Transition to timer-based compression
During transition from window-based compression to timer-based During transition from window-based compression to timer-based
compression it is necessary to keep k large enough to cover both compression it is necessary to keep k large enough to cover both
interpretation intervals. interpretation intervals.
4.3. Generic extension header list 4.3. 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
skipping to change at page 6, line 39 skipping to change at page 6, line 41
both fields should be set to the same value. both fields should be set to the same value.
4.6. Meaning of NBO 4.6. 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. In IPv4 dynamic part (Section
5.7.7.4), if the 'NBO' bit is set, it means that network byte order 5.7.7.4), if the 'NBO' bit is set, it means that network byte order
is used. Although, network byte order is the more common byte is used. Although, network byte order is the more common byte
alignment. alignment.
4.7. Implicit TS and IP-ID updates 4.7. Implicit updates
Type 0 packets (R-0-CRC, UO-0), which contain the compressed RTP If an updating packet (e.g. R-0-CRC or UO-0) contains information
sequence number (SN) and a CRC checksum updates not only the RTP about a specific field X (compressed RTP sequence number, typically),
sequence number. Such packets also update RTP timestamp and IPv4 ID then X is updated according to the content of that packet. But this
implicitly, unless there are explicit TS and IP-ID fields in the packet implicitly updates all other inferred fields (i.e. RTP
packet. timestamp) according to the current mode and the appropriate mapping
function of the updated and the inferred fields.
For example, a UO-0 packet contains the compressed RTP sequence
number (SN). Such a packet also updates RTP timestamp and IPv4 ID,
implicitly.
4.8. IP-ID 4.8. 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* packets 4.9. 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. It is other than SN, TS and IP-ID in IP header(s) and RTP header. In case
permitted to use it in UO-1* packets, however it may not make any of UO-1-ID packets, values provided in extensions do not update the
sense because of the updating properties of UO-1* packets (Section context, except those in other SN, TS and IP-ID fields (Section
5.7.3). 5.7.3.). Note, that SN, TS and IP-ID fields can also be sent in
Extension-0, -1 and -2 and the other fields of Extension-3 don't
update the context.
In case of UO-1* packets, values provided in extensions do not update Besides, usage of Extension-3 in UO-1-ID can be useful to compress a
the context, except those in other SN, TS and IP-ID fields. The SN, transient change in a packet stream. For example, if a field's value
TS and IP-ID fields can also be sent in Extension-0, -1 and -2 and changes in the current packet but in the next packet it returns to
the other fields of Extension-3 don't update the context. its regular behavior. E.g. changes in TTL.
4.10. Extension-3 in UOR-2* packets 4.10. 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. Some flags of the IP header in the extension updates the context (Section). Some flags of the IP header
extension (e.g. NBO or RND) can change the interpretation of fields in the extension (e.g. NBO or RND) can change the interpretation of
in UOR-2* packets. fields in UOR-2* packets.
In these cases, when a flag changes in Extension-3, a decompressor In these cases, when a flag changes in Extension-3, a decompressor
should re-parse the UOR-2* packet. should re-parse the UOR-2* packet.
4.11. Multiple SN options in one feedback packet 4.11. 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 RTP 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
skipping to change at page 8, line 13 skipping to change at page 8, line 23
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?
One potential issue that might have to be considered, depending on
link technology, is whether feedback links might get lost, and in
such cases how this is handled. When the compressor is notified that
the feedback channel is down, the compressor must be able to handle
it by restarting compression with creating a new context. Creating a
new context also implies to use a new CID value.
Generally, feedback links are not expected to disappear when once
present, but it should be noted that this might be the case for
certain link technologies.
4.14. 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
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
the ROHC packet. It's been agreed that the RTP padding bit is
presumed zero if absent from the RTP header flags.
4.15. 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.
5. Test Configuration 5. 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 8, line 53 skipping to change at page 9, line 49
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.
6. References 6. Acknowledgment
The authors would like thank Vicknesan Ayadurai, Carsten Bormann,
Zhigang Liu, Abigail Surtees and Mark West for their contributions
and comments.
7. 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-1662] W. Simpson, Editor, PPP in HDLC-like Framing, RFC 1662,
July 1994. July 1994.
7. Authors' Addresses 8. Authors' Addresses
Peter Kremer Peter Kremer
Ericsson Research, Conformance and Software Test Laboratory Conformance and Software Test Laboratory
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
Lars-Erik Jonsson Lars-Erik Jonsson
Box 920 Box 920
Ericsson Erisoft AB Ericsson AB
SE-971 28 Lulea, Sweden SE-971 28 Lulea, Sweden
Phone: +46 920 20 21 07 Phone: +46 920 20 21 07
Fax: +46 920 20 20 99 Fax: +46 920 20 20 99
EMail: lars-erik.jonsson@ericsson.com EMail: lars-erik.jonsson@ericsson.com
Appendix A. Sample CRC algorithm Appendix A. Sample CRC algorithm
#!/usr/bin/perl -w #!/usr/bin/perl -w
use strict; use strict;
 End of changes. 

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