draft-ietf-avt-crtp-enhance-03.txt   draft-ietf-avt-crtp-enhance-04.txt 
Audio/Video Transport Working Group Tmima Koren Audio/Video Transport Working Group Tmima Koren
Internet Draft Cisco Systems Internet Draft Cisco Systems
November 12, 2001 Stephen Casner February 24, 2002 Stephen Casner
Expires June 2002 Packet Design Expires September 2002 Packet Design
draft-ietf-avt-crtp-enhance-03.txt John Geevarghese draft-ietf-avt-crtp-enhance-04.txt John Geevarghese
Telseon Telseon
Bruce Thompson Bruce Thompson
Patrick Ruddy Patrick Ruddy
Cisco Systems Cisco Systems
Compressing IP/UDP/RTP headers on links with high delay, Compressing IP/UDP/RTP headers on links with high delay,
packet loss and reordering packet loss and reordering
Status of this memo Status of this memo
skipping to change at line 181 skipping to change at line 181
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Enhanced CRTP 2. Enhanced CRTP
This chapter specifies the changes in this enhanced version of CRTP. This chapter specifies the changes in this enhanced version of CRTP.
They are: They are:
- Extensions to the COMPRESSED_UDP packet to allow updating the - Extensions to the COMPRESSED_UDP packet to allow updating the
differential RTP values in the decompressor context and to differential RTP values in the decompressor context and to
selectively update the absolute IP ID and RTP values. This selectively update the absolute IP ID and the following RTP
allows context sync to be maintained even with some packet values: sequence number, timestamp, payload type, and CSRC
loss. count. This allows context sync to be maintained even with
some packet loss.
- A "headers checksum" to be inserted by the compressor and - A "headers checksum" to be inserted by the compressor and
removed by the decompressor when the UDP checksum is not removed by the decompressor when the UDP checksum is not
present so that validation of the decompressed headers is present so that validation of the decompressed headers is
still possible. This allows the decompressor to verify that still possible. This allows the decompressor to verify that
context sync has not been lost after a packet loss. context sync has not been lost after a packet loss.
An algorithm is then described to use these changes with repeated An algorithm is then described to use these changes with repeated
updates to achieve robust operation over links with packet loss and updates to achieve robust operation over links with packet loss and
long delay. long delay.
skipping to change at line 403 skipping to change at line 404
2.2 CRTP Headers Checksum 2.2 CRTP Headers Checksum
RFC 2508, in Section 3.3.5, describes how the UDP checksum may be RFC 2508, in Section 3.3.5, describes how the UDP checksum may be
used to validate header reconstruction periodically or when the used to validate header reconstruction periodically or when the
"twice" algorithm is used. When a UDP checksum is not present (has "twice" algorithm is used. When a UDP checksum is not present (has
value zero) in a stream, such validation would not be possible. To value zero) in a stream, such validation would not be possible. To
cover that case, this enhanced CRTP provides an option whereby the cover that case, this enhanced CRTP provides an option whereby the
compressor MAY replace the null UDP checksum with a 16-bit headers compressor MAY replace the null UDP checksum with a 16-bit headers
checksum (HDRCKSUM) which is subsequently removed by the checksum (HDRCKSUM) which is subsequently removed by the
decompressor after validation. decompressor after validation. Note that this option is never used
with IPv6 since a null UDP checksum is not allowed.
A new flag C in the FULL_HEADER packet, as specified below, A new flag C in the FULL_HEADER packet, as specified below,
indicates when set that all COMPRESSED_UDP and COMPRESSED_RTP indicates when set that all COMPRESSED_UDP and COMPRESSED_RTP
packets sent in that context will have HDRCKSUM inserted. The packets sent in that context will have HDRCKSUM inserted. The
compressor MAY set the C flag when UDP packet carried in the compressor MAY set the C flag when UDP packet carried in the
FULL_HEADER packet originally contained a checksum value of zero. FULL_HEADER packet originally contained a checksum value of zero.
If the C flag is set, the FULL_HEADER packet itself MUST also have If the C flag is set, the FULL_HEADER packet itself MUST also have
the HDRCKSUM inserted. If a packet in the same stream subsequently the HDRCKSUM inserted. If a packet in the same stream subsequently
arrives at the compressor with a UDP checksum present, then a new arrives at the compressor with a UDP checksum present, then a new
FULL_HEADER packet MUST be sent with the flag cleared to re- FULL_HEADER packet MUST be sent with the flag cleared to re-
skipping to change at line 557 skipping to change at line 559
cause the decompressor to receive more than N+1 FULL_HEADER packets cause the decompressor to receive more than N+1 FULL_HEADER packets
in a row with the result that it assumes a larger value for N than in a row with the result that it assumes a larger value for N than
is correct. That could lead to an undetected loss of context is correct. That could lead to an undetected loss of context
synchronization. Therefore, the compressor MUST change the synchronization. Therefore, the compressor MUST change the
"generation" number in the context and in the FULL_HEADER packet "generation" number in the context and in the FULL_HEADER packet
when it begins sending the sequence of N+1 FULL_HEADER packets so when it begins sending the sequence of N+1 FULL_HEADER packets so
the decompressor can detect the new sequence. For IPv4, this is a the decompressor can detect the new sequence. For IPv4, this is a
change in behavior relative to RFC 2508. change in behavior relative to RFC 2508.
CONTEXT_STATE packets SHOULD also be repeated N+1 times (using the CONTEXT_STATE packets SHOULD also be repeated N+1 times (using the
same sequence number) to provide a similar measure of robustness same sequence number for each context) to provide a similar measure
against packet loss. of robustness against packet loss. Here N can be the largest N of
all contexts included in the CONTEXT_STATE packet, or any number the
decompressor finds necessary in order to ensure robustness.
2.3.1 Examples 2.3.1 Examples
Here are some examples to demonstrate the robust operation of Here are some examples to demonstrate the robust operation of
enhanced CRTP using N+1 repetitions of updates. In this stream the enhanced CRTP using N+1 repetitions of updates. In this stream the
audio codec sends a sample every 10 milliseconds. The first audio codec sends a sample every 10 milliseconds. The first
talkspurt is 1 second long. Then there are 2 seconds of silence, talkspurt is 1 second long. Then there are 2 seconds of silence,
then another talkspurt. We also assume in this first example that then another talkspurt. We also assume in this first example that
the IPv4 ID field does not increment at a constant rate because the the IPv4 ID field does not increment at a constant rate because the
host is generating other uncorrelated traffic streams at the same host is generating other uncorrelated traffic streams at the same
skipping to change at line 729 skipping to change at line 733
Dan Wing. Dan Wing.
6. References 6. References
[CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links", RFC2508, February 1999. Low-Speed Serial Links", RFC2508, February 1999.
[IPHCOMP] M. Degermark, B. Nordgren, S. Pink, [IPHCOMP] M. Degermark, B. Nordgren, S. Pink,
"IP Header Compression", RFC2507, February 1999. "IP Header Compression", RFC2507, February 1999.
[IPCPHC] M. Engan, S. Casner, C. Bormann, [IPCPHC] M. Engan, S. Casner, C. Bormann, T. Koren,
"IP Header Compression over PPP", RFC2509, February 1999. "IP Header Compression over PPP",
draft-koren-pppext-rfc2509bis-01.txt, February 2002.
[KEYW] S. Bradner, "Key words for use in RFCs to Indicate [KEYW] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC2119, BCP 14, March 1997. Requirement Levels", RFC2119, BCP 14, March 1997.
[RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC1889, "RTP: A Transport Protocol for Real-Time Applications", RFC1889,
January 1996. January 1996.
7. Authors' Addresses 7. Authors' Addresses
skipping to change at line 772 skipping to change at line 777
Email: geevjohn@hotmail.com Email: geevjohn@hotmail.com
Bruce Thompson Bruce Thompson
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
United States of America United States of America
Email: brucet@cisco.com Email: brucet@cisco.com
Patrick Ruddy
Cisco Systems, Inc.
3rd Floor
96 Commercial Street
Leith, Edinburgh EH6 6LX
Scotland
Email: pruddy@cisco.com
8. Copyright 8. Copyright
Copyright (C) The Internet Society 1999-2001. All Rights Reserved. Copyright (C) The Internet Society 1999-2001. 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 kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
 End of changes. 

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