draft-ietf-avt-crtp-enhance-02.txt   draft-ietf-avt-crtp-enhance-03.txt 
Audio/Video Transport Working Group Tmima Koren Audio/Video Transport Working Group Tmima Koren
Internet Draft Cisco Systems Internet Draft Cisco Systems
July 16, 2001 Stephen Casner November 12, 2001 Stephen Casner
Expires March 2002 Packet Design Expires June 2002 Packet Design
draft-ietf-avt-crtp-enhance-02.txt John Geevarghese draft-ietf-avt-crtp-enhance-03.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 38 skipping to change at line 38
The list of current Internet-Drafts can be accessed at: The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
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.txt http://www.ietf.org/shadow.txt
This draft is a work item of the IETF Audio/Video Transport working This draft is a work item of the IETF Audio/Video Transport working
group. The working group mailing list is avt@ietf.org. Subscribe via group. The working group mailing list is avt@ietf.org. Subscribe via
the web at http://www.ietf.org/mailman/listinfo/avt. the web at http://www.ietf.org/mailman/listinfo/avt.
Copyright Notice
Copyright (C) The Internet Society (1999-2001). All Rights Reserved. Copyright (C) The Internet Society (1999-2001). All Rights Reserved.
Abstract Abstract
This document describes a header compression scheme for point to This document describes a header compression scheme for point to
point links with packet loss and long delays. It is based on CRTP, point links with packet loss and long delays. It is based on CRTP,
the IP/UDP/RTP header compression described in [RFC2508]. CRTP does the IP/UDP/RTP header compression described in [RFC2508]. CRTP does
not perform well on such links: packet loss results in context not perform well on such links: packet loss results in context
corruption and due to the long delay, many more packets are corruption and due to the long delay, many more packets are
discarded before the context is repaired. To correct the behavior of discarded before the context is repaired. To correct the behavior of
CRTP over such links, a few extensions to the protocol are specified CRTP over such links, a few extensions to the protocol are specified
here. The extensions aim to reduce context corruption by changing here. The extensions aim to reduce context corruption by changing
the way the compressor updates the context at the decompressor: the way the compressor updates the context at the decompressor:
updates are repeated and include updates to full and differential updates are repeated and include updates to full and differential
context parameters. With these extensions, CRTP performs well over context parameters. With these extensions, CRTP performs well over
links with packet loss, packet reordering and long delays. links with packet loss, packet reordering and long delays.
The IPCP option 'IP header compression' (described in RFC 2509) is
also extended to negotiate using the extended CRTP.
1.0 Introduction 1.0 Introduction
RTP header compression (CRTP) as described in RFC 2508 was designed RTP header compression (CRTP) as described in RFC 2508 was designed
to reduce the header overhead of IP/UDP/RTP datagrams by compressing to reduce the header overhead of IP/UDP/RTP datagrams by compressing
the three headers. The IP/UDP/RTP headers are compressed to 2-4 the three headers. The IP/UDP/RTP headers are compressed to 2-4
bytes most of the time. bytes most of the time.
CRTP was designed for reliable point to point links with short CRTP was designed for reliable point to point links with short
delays. It does not perform well over links with high rate of packet delays. It does not perform well over links with high rate of packet
loss, packet reordering and long delays. loss, packet reordering and long delays.
skipping to change at line 186 skipping to change at line 185
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 RTP values. This
allows context sync to be maintained even with some packet allows context sync to be maintained even with some packet
loss. 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.
2.1 Extended COMPRESSED_UDP packet 2.1 Extended COMPRESSED_UDP packet
It is possible to accommodate some packet loss between the It is possible to accommodate some packet loss between the
compressor and decompressor using the "twice" algorithm in RFC 2508 compressor and decompressor using the "twice" algorithm in RFC 2508
so long as the context remains in sync. This requires reliably so long as the context remains in sync. In that algorithm, the delta
communicating both the absolute value and the delta value whenever values are added to the previous context twice (or more) to effect
the delta value changes. For many environments, sufficient the change that would have occurred if the missing packets had
reliability can be achieved by repeating the update with each of arrived. The result is verified with the UDP checksum. Keeping the
several successive packets. context in sync requires reliably communicating both the absolute
value and the delta value whenever the delta value changes. For many
environments, sufficient reliability can be achieved by repeating
the update with each of several successive packets.
The COMPRESSED_UDP packet satisfies the need to communicate the The COMPRESSED_UDP packet satisfies the need to communicate the
absolute values of the differential RTP fields, but it is specified absolute values of the differential RTP fields, but it is specified
in RFC 2508 to reset the delta RTP timestamp. That limitation can be in RFC 2508 to reset the delta RTP timestamp. That limitation can be
removed with the following simple change: RFC 2508 describes the removed with the following simple change: RFC 2508 describes the
format of COMPRESSED_UDP as being the same as COMPRESSED_RTP except format of COMPRESSED_UDP as being the same as COMPRESSED_RTP except
that the M, S and T bits are always 0 and the corresponding delta that the M, S and T bits are always 0 and the corresponding delta
fields are never included. This enhanced version of CRTP changes fields are never included. This enhanced version of CRTP changes
that specification to say that the T bit may be nonzero to indicate that specification to say that the T bit MAY be nonzero to indicate
that the delta RTP timestamp is included explicitly rather than that the delta RTP timestamp is included explicitly rather than
being reset to zero. being reset to zero.
A second change adds another byte of flag bits to the COMPRESSED_UDP A second change adds another byte of flag bits to the COMPRESSED_UDP
packet to allow only selected individual uncompressed fields of the packet to allow only selected individual uncompressed fields of the
RTP header to be included in the packet rather than carrying the RTP header to be included in the packet rather than carrying the
full RTP header as part of the UDP data. The additional flags do full RTP header as part of the UDP data. The additional flags do
increase computational complexity somewhat, but the corresponding increase computational complexity somewhat, but the corresponding
increase in bit efficiency is important when the differential field increase in bit efficiency is important when the differential field
updates are communicated multiple times in successive COMPRESSED_UDP updates are communicated multiple times in successive COMPRESSED_UDP
skipping to change at line 270 skipping to change at line 272
dI = delta IP ID dI = delta IP ID
dT = delta RTP timestamp dT = delta RTP timestamp
I = absolute IP ID I = absolute IP ID
F = additional flags byte F = additional flags byte
M = marker bit M = marker bit
S = absolute RTP sequence number S = absolute RTP sequence number
T = absolute RTP timestamp T = absolute RTP timestamp
P = RTP payload type P = RTP payload type
CC = number of CSRC identifiers CC = number of CSRC identifiers
When F=0, there is only one flags byte, and the only available flags When F=0, there is only one flags byte, and the only available flags
are: dI, dT and I. In this case the packet includes the full RTP are: dI, dT and I. In this case the packet includes the full RTP
header. As in RFC 2508, if dI=0, the decompressor does not change header. As in RFC 2508, if dI=0, the decompressor does not change
deltaI. If dT=0, the decompressor sets deltaT to 0. deltaI. If dT=0, the decompressor sets deltaT to 0.
Some example packet formats will illustrate the use of the new Some example packet formats will illustrate the use of the new
flags. First, when F=0, the 'traditional' COMPRESSED_UDP packet flags. First, when F=0, the "traditional" COMPRESSED_UDP packet
which carries the full RTP header as part of the UDP data: which carries the full RTP header as part of the UDP data:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+...............................+ +...............................+
: msb of session context ID : (if 16-bit CID) : msb of session context ID : (if 16-bit CID)
+-------------------------------+ +-------------------------------+
| lsb of session context ID | | lsb of session context ID |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
|F=0| I |dT |dI | link sequence | |F=0| I |dT |dI | link sequence |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
skipping to change at line 386 skipping to change at line 390
It is useful for the compressor to periodically refresh the state of It is useful for the compressor to periodically refresh the state of
the decompressor to avoid having the decompressor send CONTEXT_STATE the decompressor to avoid having the decompressor send CONTEXT_STATE
messages in the case of unrecoverable packet loss. Using the flags messages in the case of unrecoverable packet loss. Using the flags
F=0 and I=1, dI=1, dT=1, the COMPRESSED_UDP packet refreshes all the F=0 and I=1, dI=1, dT=1, the COMPRESSED_UDP packet refreshes all the
context parameters. context parameters.
When compression is done over a lossy link with a long round trip When compression is done over a lossy link with a long round trip
delay, we want to minimize context invalidation. If the delta values delay, we want to minimize context invalidation. If the delta values
are changing frequently, the context might get invalidated often. In are changing frequently, the context might get invalidated often. In
such cases the compressor may choose to always send absolute values such cases the compressor MAY choose to always send absolute values
and never delta values, using COMPRESSED_UDP packets with the flags and never delta values, using COMPRESSED_UDP packets with the flags
F=1, and any of S, T, I as necessary. F=1, and any of S, T, I as necessary.
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.
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
skipping to change at line 423 skipping to change at line 427
that it does not cover all of the UDP data. That is, the HDRCKSUM is that it does not cover all of the UDP data. That is, the HDRCKSUM is
the 16-bit one's complement of the one's complement sum of the the 16-bit one's complement of the one's complement sum of the
pseudo-IP header (as defined for UDP), the UDP header, and the first pseudo-IP header (as defined for UDP), the UDP header, and the first
12 bytes of the UDP data which are assumed to hold the fixed part of 12 bytes of the UDP data which are assumed to hold the fixed part of
an RTP header. The extended part of the RTP header and the RTP data an RTP header. The extended part of the RTP header and the RTP data
will not be included in the HDRCKSUM. The HDRCKSUM is placed in the will not be included in the HDRCKSUM. The HDRCKSUM is placed in the
COMPRESSED_UDP or COMPRESSED_RTP packet where a UDP checksum would COMPRESSED_UDP or COMPRESSED_RTP packet where a UDP checksum would
have been. The decompressor MUST zero out the UDP checksum field in have been. The decompressor MUST zero out the UDP checksum field in
the reconstructed packets. the reconstructed packets.
For a non-RTP context, there may fewer than 12 UDP data bytes For a non-RTP context, there may be fewer than 12 UDP data bytes
present. The IP and UDP headers may still be compressed into a present. The IP and UDP headers can still be compressed into a
COMPRESSED_UDP packet. For this case, the HDRCKSUM is calculated COMPRESSED_UDP packet. For this case, the HDRCKSUM is calculated
over the pseudo-IP header, the UDP header, and the UDP data bytes over the pseudo-IP header, the UDP header, and the UDP data bytes
that are present. If the number of data bytes is odd, then a zero that are present. If the number of data bytes is odd, then a zero
padding byte is appended for the purpose of calculating the padding byte is appended for the purpose of calculating the
checksum, but not transmitted. checksum, but not transmitted.
The HDRCKSUM does not validate the RTP data. If the link layer is The HDRCKSUM does not validate the RTP data. If the link layer is
configured to deliver packets without checking for errors, then configured to deliver packets without checking for errors, then
errors in the RTP data will not be detected. Over such links, the errors in the RTP data will not be detected. Over such links, the
compressor SHOULD add the HDRCKSUM if a UDP checksum is not present, compressor SHOULD add the HDRCKSUM if a UDP checksum is not present,
skipping to change at line 467 skipping to change at line 471
For 16-bit context ID: For 16-bit context ID:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Generation| 0 |C| seq | First length field |1|1| Generation| 0 |C| seq | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C=1: HDRCKSUM will be added
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID | Second length field | CID | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.3 CRTP operation in 'N' mode 2.3 Achieving robust operation
The 'N' mode is a method of operation where the compressor tries to Enhanced CRTP achieves robust operation by sending changes multiple
keep the decompressor in sync by sending changes multiple times. The times to keep the compressor and decompressor in sync. This method
'N' is a number that represents the quality of the link between the is characterized by a number "N" that represents the quality of the
hosts, and it means that the probability of more than N adjacent link between the hosts. What it means is that the probability of
packets getting lost on this link is small. For every change in a more than N adjacent packets getting lost on this link is small. For
full value or a delta value, if the compressor includes the change every change in a full value or a delta value, if the compressor
in N+1 consecutive packets, there is a very good chance that the includes the change in N+1 consecutive packets, then the
compressor and decompressor can stay in sync using the 'twice' decompressor can keep its context state in sync with the compressor
algorithm. CONTEXT_STATE packets should also be repeated N+1 times using the "twice" algorithm so long as no more than N adjacent
(using the same sequence number). It is up to the implementation to packets are lost.
find a scheme to derive an appropriate N for a link.
This scheme may be used at any time and does not require Since updates are repeated in N+1 packets, if at least one of these
negotiation. N+1 update packets is received by the decompressor, both the full
and delta values in the context at the decompressor will get updated
and its context will stay synchronized with the context at the
compressor. We can conclude that as long as less than N+1 adjacent
packets are lost, the context at the decompressor is guaranteed to
be synchronized with the context at the compressor, and use of the
"twice" algorithm to recover from packet loss will successfully
update the context and restore the compressed packets.
Some short notations: The link sequence number cycles in 16 packets, so it's not always
clear how many packets were lost. For example, if the previous link
sequence number was 5 and the current number is 4, one possibility
is that 15 packets were lost, but another possibility is that due to
misordering packet 5 arrived before packet 4 and they are really
adjacent. If there is an interpretation of the link sequence numbers
that could be a gap of less than N+1, the "twice" algorithm may be
applied that many times and verified with the UDP checksum (or the
HDRCKSUM).
FH FULL_HEADER When more than N packets are lost, all of the repetitions of an
CR COMPRESSED_RTP update might have been lost. The context state may then be different
CU COMPRESSED_UDP at the compressor and decompressor. The decompressor can still try
to recover by making one or more guesses for how many packets were
lost and then applying the "twice" algorithm that many times.
However, since the IPv4 ID field is not included in the checksum,
this does not validate the IPv4 ID.
Here is an example to demonstrate the usage of the N scheme. The conclusion is that for IPv4 if more than N packets were lost,
In this stream the audio codec sends a sample every 10 milliseconds the decompressor SHOULD NOT try to recover using the "twice"
The first talkspurt is 1 second long. Then there are 2 seconds of algorithm and instead SHOULD invalidate the context and send a
silence, then another talkspurt. We also assume in this example that CONTEXT_STATE packet. In IPv6 the decompressor MAY always try to
the IP ID field does not increment at a constant rate because the recover from packet loss by using the "twice" algorithm and
verifying the result with the UDP checksum.
It is up to the implementation to derive an appropriate N for a
link. The value is maintained independently for each context and is
not required to be the same for all contexts. When compressing a new
stream, the compressor sets a value of N for that context and sends
N+1 FULL_HEADER packets. The compressor MUST also repeat each
subsequent COMPRESSED_UDP update N+1 times. The value of N may be
changed for an existing context by sending a new sequence of
FULL_HEADER packets.
The decompressor learns the value of N by counting the number of
times the FULL_HEADER packet is repeated and storing the resulting
value in the corresponding context. If some of the FULL_HEADER
packets are lost, the decompressor may still be able to determine
the correct value of N by observing the change in the 4-bit sequence
number carried in the FULL_HEADER packets. Any inaccuracy in the
counting will lead the decompressor to assume a smaller value of N
than the compressor is sending. This is safe in that the only
negative consequence is that the decompressor might send a
CONTEXT_STATE packet when it was not really necessary to do so. In
response, the compressor will send FULL_HEADER packets again,
providing another opportunity for the decompressor to count the
correct N.
The sending of FULL_HEADER packets is also triggered by a change in
one of the fields held constant in the context, such as the IP TOS.
If such a change should occur while the compressor is in the middle
of sending the N+1 FULL_HEADER packets, then the compressor MUST
send N+1 FULL_HEADER packets after making the change. This could
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
is correct. That could lead to an undetected loss of context
synchronization. Therefore, the compressor MUST change the
"generation" number in the context and in the FULL_HEADER packet
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
change in behavior relative to RFC 2508.
CONTEXT_STATE packets SHOULD also be repeated N+1 times (using the
same sequence number) to provide a similar measure of robustness
against packet loss.
2.3.1 Examples
Here are some examples to demonstrate the robust operation of
enhanced CRTP using N+1 repetitions of updates. In this stream the
audio codec sends a sample every 10 milliseconds. The first
talkspurt is 1 second long. Then there are 2 seconds of silence,
then another talkspurt. We also assume in this first example that
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
time and therefore the delta IP ID changes for each packet. time and therefore the delta IP ID changes for each packet.
When there is no loss on the link, we can use COMPRESSED_RTP packets In these examples, we will use some short notations:
in the following sequence:
FH FULL_HEADER
CR COMPRESSED_RTP
CU COMPRESSED_UDP
When operating on a link with low loss, we can just use
COMPRESSED_RTP packets in the basic CRTP method specified in RFC
2508. We might have the following packet sequence:
seq Time pkt updates and comments seq Time pkt updates and comments
# type # type
1 10 FH 1 10 FH
2 20 CR dI dT=10 2 20 CR dI dT=10
3 30 CR dI 3 30 CR dI
4 40 CR dI 4 40 CR dI
... ...
100 1000 CR dI 100 1000 CR dI
101 3010 CR dI dT=2010 101 3010 CR dI dT=2010
102 3020 CR dI dT=10 102 3020 CR dI dT=10
103 3030 CR dI 103 3030 CR dI
104 3040 CR dI 104 3040 CR dI
... ...
In the above sequence, if a packet is lost we cannot recover In the above sequence, if a packet is lost we cannot recover
('twice' will not work due to the unpredictable IP ID) and the ("twice" will not work due to the unpredictable IP ID) and the
context must be invalidated. context must be invalidated.
Here is the same example in 'N' mode, when N=2. Note that the Here is the same example using the enhanced CRTP method specified in
compressor only sends the absolute IP ID (I) and not the delta IP ID this document, when N=2. Note that the compressor only sends the
(dI). absolute IP ID (I) and not the delta IP ID (dI).
seq Time pkt CU flags updates and comments seq Time pkt CU flags updates and comments
# type F I dT dI M S T P # type F I dT dI M S T P
1 10 FH 1 10 FH
2 20 FH repeat constant fields 2 20 FH repeat constant fields
3 30 FH repeat constant fields 3 30 FH repeat constant fields
4 40 CU 1 1 1 0 M 0 1 0 I T=40 dT=10 4 40 CU 1 1 1 0 M 0 1 0 I T=40 dT=10
5 50 CU 1 1 1 0 M 0 1 0 I T=50 dT=10 repeat update T & dT 5 50 CU 1 1 1 0 M 0 1 0 I T=50 dT=10 repeat update T & dT
6 60 CU 1 1 1 0 M 0 1 0 I T=60 dT=10 repeat update T & dT 6 60 CU 1 1 1 0 M 0 1 0 I T=60 dT=10 repeat update T & dT
7 70 CU 1 1 0 0 M 0 0 0 I 7 70 CU 1 1 0 0 M 0 0 0 I
skipping to change at line 562 skipping to change at line 642
4 40 CR 4 40 CR
... ...
100 1000 CR 100 1000 CR
101 3010 CR dT=2010 101 3010 CR dT=2010
102 3020 CR dT=10 102 3020 CR dT=10
103 3030 CR 103 3030 CR
104 3040 CR 104 3040 CR
... ...
For the equivalent sequence in 'N' mode, the more efficient For the equivalent sequence in enhanced CRTP, the more efficient
COMPRESSED_RTP packet can still be used once the deltas are all COMPRESSED_RTP packet can still be used once the deltas are all
established: established:
seq Time pkt CU flags updates and comments seq Time pkt CU flags updates and comments
# type F I dT dI M S T P # type F I dT dI M S T P
1 10 FH 1 10 FH
2 20 FH repeat constant fields 2 20 FH repeat constant fields
3 30 FH repeat constant fields 3 30 FH repeat constant fields
4 40 CU 1 1 1 1 M 0 1 0 I dI T=40 dT=10 4 40 CU 1 1 1 1 M 0 1 0 I dI T=40 dT=10
5 50 CU 1 1 1 1 M 0 1 0 I dI T=50 dT=10 repeat updates 5 50 CU 1 1 1 1 M 0 1 0 I dI T=50 dT=10 repeat updates
skipping to change at line 588 skipping to change at line 668
101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T changed, keep deltas 101 3010 CU 1 0 0 0 M 0 1 0 T=3010 T changed, keep deltas
102 3020 CU 1 0 0 0 M 0 1 0 T=3020 repeat updated T 102 3020 CU 1 0 0 0 M 0 1 0 T=3020 repeat updated T
103 3030 CU 1 0 0 0 M 0 1 0 T=3030 repeat updated T 103 3030 CU 1 0 0 0 M 0 1 0 T=3030 repeat updated T
104 3040 CR 104 3040 CR
105 3050 CR 105 3050 CR
... ...
3. Negotiating usage of enhanced-CRTP 3. Negotiating usage of enhanced-CRTP
RFC 2509 [IPCPHC] specifies how the use of CRTP is negotiated on PPP The use of IP/UDP/RTP compression (CRTP) over a particular link is
links using the IP Compression Protocol option of IPCP: a function of the link-layer protocol. It is expected that
negotiation of the use of CRTP will be defined separately
IPCP option 2: IP compression protocol for each link layer.
protocol 0x61: indicates RFC 2507 header compression
sub-option 1: enables use of COMPRESSED_RTP, COMPRESSED_UDP
and CONTEXT_STATE as specified in RFC 2508
To use the enhanced CRTP defined in this document, a new sub-option
2 is added. The new sup-option 2 is negotiated instead of, not in
addition to, sub-option 1.
Description
Enable use of Protocol Identifiers COMPRESSED_RTP and
CONTEXT_STATE as specified in RFC 2508 plus COMPRESSED_UDP with
additional flags as defined in this document, and enable use of
the C flag with the FULL_HEADER Protocol Identifier as defined in
this document to indicate use of HDRCKSUM with COMPRESSED_RTP and
COMPRESSED_UDP packets.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
2
Length For link layers that already have defined a negotiation for the use
2 of CRTP as specified in RFC 2508, an extension to that negotiation
will be required to indicate use of the enhanced CRTP defined in
this document since the syntax of the existing packet formats has
been extended.
4. Security Considerations 4. Security Considerations
Because encryption eliminates the redundancy that this compression Because encryption eliminates the redundancy that this compression
scheme tries to exploit, there is some inducement to forego scheme tries to exploit, there is some inducement to forego
encryption in order to achieve operation over a low-bandwidth link. encryption in order to achieve operation over a low-bandwidth link.
However, for those cases where encryption of data and not headers is However, for those cases where encryption of data and not headers is
satisfactory, RTP does specify an alternative encryption method in satisfactory, RTP does specify an alternative encryption method in
which only the RTP payload is encrypted and the headers are left in which only the RTP payload is encrypted and the headers are left in
the clear. That would allow compression to still be applied. the clear. That would allow compression to still be applied.
skipping to change at line 688 skipping to change at line 746
"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
Tmima Koren Tmima Koren
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: tmima@cisco.com Email: tmima@cisco.com
Stephen L. Casner Stephen L. Casner
Packet Design Packet Design
2465 Latham Street, Third Floor 2465 Latham Street, Third Floor
Mountain View, CA 94040 Mountain View, CA 94040
United States of America United States of America
Email: casner@acm.org Email: casner@acm.org
John Geevarghese John Geevarghese
Telseon Inc. Telseon Inc.
480 S. California 480 S. California
Palo Alto, CA 94306 Palo Alto, CA 94306
United States of America United States of America
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
Patrick Ruddy Email: brucet@cisco.com
Cisco Systems, Inc.
3rd Floor, 96 Commercial Street
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/