One document matched: draft-hiller-rohc-gehco-00.txt
Robust Header Compression Tom Hiller
Internet Draft Pete McCann
Document: draft-hiller-rohc-gehco-00.txt Lucent Technologies
Category: Standards Track August 2000
Good Enough Header COmpression (GEHCO)
Status of this Memo
This document is an Internet-Draft and is in full conformance
withall provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
1. Abstract
The Robust Header Compression Working Group has embarked upon the
development and standardization of header compression schemes that
perform well over links with high error rates and long round-trip
times. The goal is that the schemes must perform well for cellular
links built using technologies such as WCDMA, EDGE, and CDMA-2000.
One way the group plans to achieve this is by maintaining
connections with other standardization organizations developing
cellular technology for IP, such as 3GPP and 3GPP-2, to ensure that
its output fulfills their requirements and will be put to good use.
Of particular importance to the 3GPP2 community is the spectral
efficiency of IP/UDP/RTP header compression for the voice over IP
application to mobiles. Currently, the ROHC Working Group is
focusing on compression schemes where the uncompressed header is
identical to the original header seen by the compressor. This may
be categorized as transparent compression. Transparent compression
results in additional header bytes being transported over-the-air.
3GPP2 carriers have indicated that no additional bytes may be
transported over-the-air for voice over IP, that is, that voice
over IP must have spectral efficiency comparable to legacy circuit
Hiller, McCann Standards Track - January 2000 1
Good Enough Header Compression (GEHCO) August 2000
transport over-the-air. This draft proposes a specific scheme, Good
Enough Header Compression (GEHCO) that does not exactly reproduce
the IP/UDP/RTP header, but is otherwise "good enough" for voice
over IP applications over cellular links found in 3GPP2 3G wireless
networks.
This particular scheme is applicable to certain cellular links that
synchronously transport vocoded or other multimedia payloads so
that the compressor may be certain that the compressed frame will
be delivered with a fixed and predictable delay. One example of
such a cellular link is the cdma2000 air interface with cdma2000
vocoders. A summary of the cdma2000 link characteristics is
provided herein.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
3. Introduction
With the development of SIP [3], it is likely that new services
will be created that require support of SIP in mobile endpoints. In
concert, a need will then arise to support the transport of RTP
packets to and from an endpoint. Voice sessions transmit short
frames of data, usually on a continuous basis according to known
activity factors. The frequency and length of the voice packets
requires compression of RTP packet overhead in order to justify
such service relative to not using VOIP (or IP based multimedia) at
all. Such compression schemes rely on a lower data link layer for
framing (e.g. to provide a length) and while they can reduce the
impact of header overhead, they still require some additional
bandwidth compared to the existing circuit voice channel to carry
the compressed header bytes and feedback packets.
The Robust Header Compression Working Group has embarked upon the
development and standardization of header compression schemes that
perform well over links with high error rates and long round-trip
times. The goal is that the schemes must perform well for cellular
links built using technologies such as WCDMA, EDGE, and cdma2000.
The ROHC group plans to achieve its goals by maintaining
connections with other standardization organizations developing
cellular technology for IP, such as 3GPP and 3GPP2. Of particular
importance to the 3GPP2 community is the spectral efficiency of
IP/UDP/RTP header compression for voice-over-IP application to
mobiles.
Hiller, McCann January 2000 - Expiration 2
Good Enough Header Compression (GEHCO) August 2000
A number of RTP compression algorithms have emerged recently in the
IETF. A few are:
* Enhanced CRTP [3]
* ROCCO [4]
* ACE [5]
This list is not exhaustive. These algorithms are able to reduce
the IP/UDP/RTP overhead to one or two bytes. They are also able to
tolerate some loss of packets and still maintain local
decompression state without complete retransmission of a new
IP/UDP/RTP header. In addition to the one or two bytes of header
overhead some amount of bandwidth is necessary for feedback between
decompressor and compressor to retransmit a partial or complete
header when the local state cannot be repaired.
Transparent compression results in additional header bytes being
transported over-the-air. 3GPP2 carriers have indicated that voice
over IP must have spectral efficiency comparable to legacy circuit
transport over-the-air in order for them to deploy voice-over-IP to
mobiles. To achieve such spectral efficiency, IP/UDP/RTP header
compression must not transport any additional bytes over-the-air.
Such a scheme will not exactly reproduce all bits of the IP/UDP/RTP
header, however, the behavior of the reproduced header is "good
enough" for voice-over-IP applications over cellular links. Such
header compression may be categorized as non-transparent header
compression.
This draft first discusses the characteristics of the cdma2000 link
layer that makes GEHCO possible. It then reviews the impact of
other proposed IP/UDP/RTP header compression schemes on the
spectral capacity in the context of low bit rate vocoders. The
additional impact of the data link layer such as PPP is also
considered. . Finally, the draft discusses a particular approach
for non-transparent header compression called Good Enough Header
COmpression (GEHCO).
4 cdma2000 Link Characteristics
The cdma2000 link synchronously transports physical frames every
20ms. The number of bytes in a physical frame varies based on
signaling negotiation between the user and the radio network as
well as other criteria, such as backlog (for the forward direction
of the network to mobile). The physical frames are sent in over-
the-air connections. Currently, six such connections may exist
simultaneously. The connections feature two modes, one in which the
physical frames are subject to retransmission, and another in which
they are not. The over-the-air connections are referred to as Radio
Link Protocol (RLP) instances. The mode with retransmission serves
to improve the error rate and thereby improve the throughput of
TCP. It has variable delay. The one without retransmission behaves
Hiller, McCann January 2000 - Expiration 3
Good Enough Header Compression (GEHCO) August 2000
synchronously and each 20ms frame has a fixed number of bits such
that the physical frame will be delivered in 20ms. There are four
types of physical frames: full rate (172 bits), half rate (80
bits), quarter rate (40 bits) and eighth rate (16 bits). One reason
for these different "rate" frames is variable vocoding. Depending
on speech activity and patterns, the vocoder puts out a number of
bytes that exactly fits one of these four physical frame sizes.
The over-the-air connections have priority. Voice payloads are sent
in over-the-air connections with high priority in the mode without
any retransmission. It is possible to say with certainty for these
kinds of frames that if a physical frame is transmitted it will be
delivered 20ms later, if it is received at all. We consider the
frame to not be "received" if it has uncorrectable errors.
5. Transparent Compression and Spectral Efficiency
3GPP2 vendors and service providers are developing a vocoder
referred to as Selectable-Mode-Vocoder (SMV) which outputs encoded
voice frames every 20ms. Like other low bit rate vocoders, this one
does not output constant bit rate. Table 1 [7] shows the
percentages of times that the vocoder is outputting various
payloads (measured in terms of numbers of bits in a given payload).
(Note that the activities sum to 100% so that the vocoder outputs a
voice frame every 20ms).
Rate Activity % Payload (bits)
Full 20 172
Half 20 80
Quarter 10 40
Eighth 50 16
Table 1: Activity of a 3GPP-2 Vocoder
As can be seen, even one or two bytes of data per vocoded frame
represents a considerable taxation on the spectral capacity of the
system.
In the current 3GPP2 wireless packet data architecture, byte
oriented HDLC framing provides packet delimitation. 3GPP2 selected
byte oriented HDLC [8] and PPP [9] due to its wide deployment in
operating systems commonly found in laptops and other portable
devices, as well as its ability to flexibly negotiate data link
configurations. PPP overhead may be compressed by having the
mobile negotiate the address/control/protocol fields to one byte,
and negotiate no CRC via RFC 1570 [10]. This reduces PPP overhead
to two bytes of overhead per vocoder frame, that is one protocol ID
byte and one flag between frames.
Hiller, McCann January 2000 - Expiration 4
Good Enough Header Compression (GEHCO) August 2000
Assuming one overhead byte for IP/UDP/RTP transparent compression
schemes, and two bytes for PPP, the compressed overhead header
bytes will exceed the payload 50% of the time. Even at peak vocoder
output, the compressed headers amount to a 16% spectral tax [11].
If two bytes of IP/UDP/RTP compression control bytes are needed,
the overhead is even worse. This quick analysis assumes that there
is no need for IP packets to be synchronized with the physical
frame. It also ignores payload expansion due to HDLC escaping.
Since the taxation is a result of the shortness of the vocoded
voice frame, one might try to aggregate voice frames into a single
IP/UDP/RTP packet. If more vocoded frames could be combined within
one RTP packet, then loss of spectrum capacity would
correspondingly decrease. Given that many of the packets are very
short, aggregating more vocoder frames (20ms frames) does not
necessarily create PPP frames larger than the basic rate, 172-bit
payload. This approach does imply additional delay end to end. The
number of voice frames aggregated into a VOIP packet should be
adjusted dynamically based on the coding rate. Dynamic aggregation
requires a scheme for delimiting the vocoded frames within the RTP
payload which might consume three to five bits per packet. This
approach also requires more study to determine if users can, for
example, tolerate the added 20ms delay incurred by aggregating two
short vocoder frames into one PPP frame. Such an analysis should
probably consider the case when there is an IP multimedia
conference bridge involved. For this case, each direction then
requires two voice encodes and decodes so that the bridge can sum
the speech from the call participants, which gives rise to
additional delay.
6. Non-Transparent Header Compression
A different method to improve spectral efficiency may be to simply
not transmit the RTP or PPP headers with the vocoded frames, but
instead construct IP/UDP/RTP headers at the decompressor based on
state context information forwarded to the decompressor by the
compressor. The IP/UDP/RTP header reconstructed by the decompressor
does not match the original IP/UDP/RTP sent packet bit for bit.
Some fields such as RTP sequence counts and UDP CRC may be altered
from an end-to-end point of view. Non-transparent header
compression results in no loss of spectrum capacity (except for a
couple of control packets involved in arranging the non-transparent
compression). This form of compression has also been called
_header stripping and regeneration._
The compressor removes headers before transmitting and the
decompressor creates IP/UDP/RTP header information including RTP
sequence counts. Static header information such as IP address and
UDP port will exactly match those sent by the transmitter. Other
header information such as RTP sequence counts may not, hence the
category _non transparent compression".
Hiller, McCann January 2000 - Expiration 5
Good Enough Header Compression (GEHCO) August 2000
There are a variety of methods to implement non-transparent header
compression. This contribution will focus upon header compression
using link (PPP) control mechanisms we refer to as _Good Enough
Header COmpression (GEHCO)". Compressed voice (e.g. SMV) is sent
with no headers (i.e. no PPP, IP, UDP, or RTP) over-the-air in
physical frames and the decompressor regenerates all IP/UDP/RTP
headers. This includes RTP sequence counts and UDP checksum. The
compressor's job is simply to delete the various IP/UDP/RTP headers
and pass the compressed voice to air framing hardware for
transmission over the air interface. The decompressor's job is to
wrap the compressed voice in an IP/UDP/RTP packet, creating
sequence numbers and checksums as necessary.
Depending on the vocoder used, the decompressor may wrap and
forward erred data in RTP packets. Regardless, the decompressor
increments a sequence count for each received physical frame. The
receiver may then use the payload bits or the sequence numbers to
detect missing packets and possibly mask the error.
The compressor and decompressor communicate via an over-the-air
connection established to transport the voice frames. As explained
above, the cdma2000 link can support an over-the air connection
that transports payloads synchronously in physical frames every
20ms. The type of over-the-air connection for voice has priority
and the vocoder output will dictate the size of the physical frame.
This connection inherently provides framing for the vocoder voice
frames, that is,we are not using a transparent data link layer like
byte HDLC for framing. This connection is separate from the over-
the-air connection over which usual PPP frames flow. That
connection has lower priority and the physical frames on that
connection will be subject to retransmission. There will be one RTP
flow per over-the-air connection, since otherwise it is impossible
to distinguish flows given no headers exist with the payloads. The
physical basis and control (e.g. establishment and release) of
connections for the usual PPP frames and for the voice frames is
outside the scope of this document.
In Section 7, we refer to the over-the-air connection that
transports voice payloads as the "vocoder connection" and the one
that transports PPP frames as the "PPP connection".
In the network to mobile station direction (forward direction), the
RTP packets received from the IP network will experience variable
delays. The gateway (PPP termination point) will buffer some
packets to compensate for jitter in the IP network. Because the
over-the air connection that transports the RTP payloads is
synchronous, does not feature retransmission, and has high
priority, the gateway can simply play out the payloads of the RTP
packets over the vocoder connection. These physical frames will be
delivered exactly 20ms later. The decompressor in the mobile then
Hiller, McCann January 2000 - Expiration 6
Good Enough Header Compression (GEHCO) August 2000
will assign timestamps that increment by 20ms each frame and
deliver the packets to the IP layer in the mobile station.
The loss of RTP packets in the network, or possibly significant
delays due to transient congestion, could cause buffer under-run at
the gateway. In this case the compressor has no frame to output on
the over-the-air link used to carry the voice frames. One solution
is to have the compressor output a "NO DATA" frame over-the-air to
the decompressor. This would be part of the air interface
definition and would be analogous to an approach pursued in 3GPP
[12] for this same purpose.
The decompressed IP/UDP/RTP packets are not bit for bit identical
end-to-end but there is no impact to the service. The term _good
enough_ means that the compression/decompression scheme is adequate
for transport of voice sessions even though the headers are not
reconstructed exactly. For example, RTP sequence counts sent by the
mobile can differ from those sent by the network to other endpoints
involved in a given multimedia call if the receiver does not start
counting physical frames precisely at the same time the transmitter
begins to send physical frames. While different RTP sequence
counts and time stamps will imply different UDP checksums, the
receiver will be able to make use of all generated RTP sequence
counts and time stamps.
The IP Identification field is generated from information supplied
to the decompressor by the compressor, and with proper engineering
of the sender's IP stack it will maintain the uniqueness property
that is important for proper functioning of IP fragmentation, ICMP
processing, and multi-path routing. However, even without such
engineering, duplicate Identification fields will be rare and those
that cause problems even more rare. This is especially true since
voice RTP packets will be quite small and should never be
fragmented.
7. Good Enough Header Compression (GEHCO)
The next two sections consider the identification of an end-to-end
bit flow between link (e.g. PPP) entities and the actual GEHCO
procedures. The establishment of the over-the-air connection is
properly not a GEHCO function and is dependent on the particular
link layer protocol in use. GEHCO only requires an abstraction that
allows link entities to determine the identity of a bit flow.
7.1 Link Layer Connections
In order to make use of a connection that carries compressed voice
or other multimedia without any link or higher layer headers
Hiller, McCann January 2000 - Expiration 7
Good Enough Header Compression (GEHCO) August 2000
between mobile station and a PPP peer in the network, the mobile
station and network PPP peer must agree upon a connection
identifier. This is so that both ends are able to identify a given
bit flow with a given RTP flow.
We assume that the network and mobile will use separate over-the-
air connections for purposes of transporting PPP, and for
transporting compressed voice. Typically in a cellular environment,
the connection for the PPP frames will feature improved error rates
via retransmission at the physical layer. However, due to latency
requirements, the connection that transports the vocoded frames
will not feature such retransmission.
In the mobile station, the PPP implementation must have separate
service access points for each connection (i.e. PPP frame
connection and vocoder frame connection). This will allow the PPP
implementation to direct compressed IP/UDP/RTP packets to the
vocoder frame connection and normal data traffic to the PPP frame
connection. In a relay model phone connected to a laptop, these
connections are accessed via multiple access points, possibly
supported by advanced modem interface protocols such as V.80.
Similarly, the PPP implementation in the network side PPP peer must
have separate service access points for each such connection.
7.2 Compression and Decompression Operation
This section describes how the mobile station and network (i.e. the
radio gateway) agree to use GEHCO and establish auxiliary
connections as described above. The mobile station and network must
negotiate GEHCO as part of PPP establishment (e.g. as an extension
to PPP's IPCP or IPv6CP). This negotiation would be carried out
over the PPP frame connection. Once negotiated, the two PPP
implementations could dynamically establish and delete compression
contexts for VOIP sessions. These contexts could be sent as "full
headers" [13] over PPP frame connection, and the CID (i.e.
Connection ID from [13]) should be set equal to some identifier
that identifies the over-the-air connection that will be used to
transport the compressed packets for the session. The full headers
need to be sent using a new PPP Protocol Type to distinguish them
from ordinary (transparent) header compression that may be taking
place over the same PPP session. Below we refer to this new
protocol type as GEHCO_FULL_HEADER. No additional compression
(i.e., PPP payload compression) or transformation would be
performed on the compressed RTP packets. The vocoder frame
connection would carry voice frames exactly as for normal circuit
voice. This implies that the vocoder has a real-time relationship
to the physical frame rate just as in circuit voice, and the mobile
host must be properly engineered to deliver voice traffic to the
physical layer at the physical frame rate. For now we assume that
this will be in the form of IP/UDP/RTP packets delivered to PPP,
although some architectures may provide a direct link between the
Hiller, McCann January 2000 - Expiration 8
Good Enough Header Compression (GEHCO) August 2000
vocoder and the physical layer. Similarly, the network side PPP
peer must be able to guarantee that compressed voice frames are
delivered in a way that enables real-time transmission over the
air.
The GEHCO compressor and decompressor are part of the PPP layer in
both the mobile station and network side gateway. The compressor
maintains a table of active RTP sessions that consists of source
and destination IP address, source and destination UDP port,
current RTP sequence number, and connection ID. When the compressor
receives an IP/UDP/RTP packet from the IP layer, it scans a table
of entries to find a match based the packet's source and
destination addresses and ports. If the compressor does not find a
matching entry, and if an appropriate over-the-air connection
exists to carry the compressed voice, the compressor sends a PPP
control frame of type GEHCO_FULL_HEADER to the decompressor over
the PPP frame connection. If an appropriate over-the-air connection
does not exist the peer may take steps to create one. For future
packets that match, the compressor removes the IP/UDP/RTP headers
and places the compressed voice in the RTP payload onto the vocoder
frame connection associated with this RTP flow.
As explained above, the network side compressor will maintain a
buffer to compensate for to incoming packet jitter from the IP
network. The mobile decompressor then creates timestamps per the
20ms physical frame rate and delivers packets to the IP layer. For
the compressor on the mobile side, we do not expect any real jitter
from the mobile's vocoder since the vocoder is integral to the
mobile station. If there is a small level of jitter (perhaps due to
small variable delays in the mobile station) the compressor could
likewise maintain a small buffer to compensate. At the network side
the decompressor assigns timestamps that increment very 20ms. If a
compressor buffer underruns (perhaps due to uncorrectable errors or
significant delays in the IP network), the compressor outputs a
radio frame that has "NULL DATA". The decompressor would not
produce an RTP frame for such NULL DATA frames.
The GEHCO_FULL_HEADER message contains a complete IP/UDP/RTP
packet, including:
* IP source and destination address
* Initial RTP sequence number
* UDP source and destination port
* Initial IP Identification field
* CID (Connection ID)
By way of an example, a convenient and trivial Connection ID for
the case of cdma2000 is the Radio Link Protocol (RLP) instance.
However, there is no real constraint other than that the system is
Hiller, McCann January 2000 - Expiration 9
Good Enough Header Compression (GEHCO) August 2000
able to identify a particular radio connection with a bit flow
received by a link layer entity on the network side. The
GEHCO_FULL_HEADER is distinct from the RFC2509 FULL_HEADER to keep
the space of CIDs used here which correspond to vocoder frame
connection CIDs separate from RFC2509 CIDs. The decompressor in the
PPP link layer stores the above information in a similar table. The
mobile station and network side PPP peer use the CIDs as indices to
the table.
The decompressor sends a GEHCO_FULL_HEADER_ACK in response with the
CID. The decompressor will then access the RTP payload and wrap the
compressed voice in an IP/UDP/RTP packet and pass it to the IP
layer for further processing or transport. The initial starting RTP
sequence number is equal to that in the GEHCO_FULL_HEADER control
frame, and is incremented by 1 for each decompressed frame. The IP
address and UDP port are determined from the table. The
decompressor also inserts an RTP timestamp according to the value
of a local clock at the time the frame was received. Any other
fields such as the IP Identification field and any Checksums are
set to appropriate values by the decompressor.
The initial IP Identification field is determined from the
GEHCO_FULL_HEADER and is incremented by 1 for each decompressed
frame. To ensure uniqueness of IP Identification values, the RTP
sender should assign IDs in increasing order on a per-flow basis.
This might mean that the sender allocates a certain range of IDs
for use by a flow; when the range is exhausted the sender will
start a new range and the compressor will optionally send a new
GEHCO_FULL_HEADER with the new start value. The compressor is
specifically NOT REQUIRED to do so, however, as duplicate IDs are
expected to be rare even when the initial range is exhausted.
While the compressor waits for the GEHCO_FULL_HEADER_ACK, the
compressor places RTP payloads into the designated physical
connection. This allows the decompressor to create RTP packets as
soon as it receives the GEHCO_FULL_HEADER control frame. The
compressor periodically sends a GEHCO_FULL_HEADER frame until it
receives a GEHCO_FULL_HEADER_ACK.
The mobile station or network may reclaim the UDP port and IP
address for a new RTP flow that happens to use the same IP address
and UDP port. Reclaiming could happen long after a given call has
terminated or perhaps even during a call if the SIP control so
determines to use the same parameters for a different call. If
this happens the compressor need only send a new GEHCO_FULL_HEADER
frame with the new information for the new call.
The compressor and decompressor physically will have a maximum
number of table entries. When the table size is exceeded, the
oldest table entry is overwritten.
Hiller, McCann January 2000 - Expiration 10
Good Enough Header Compression (GEHCO) August 2000
7.3 Protocol
GEHCO uses the Configuration Option of Section 2.1 of RFC 2509 [13]
and requires a new field for the RTP-compression sub-option of
Section 2.2 of RFC 2509. That is, we propose that the RTP-
compression sub-option be extended with additional bytes indicating
which RTP compression schemes are in use.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Scheme ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
1
Length
Variable
Scheme
Sequence of CRTP, ROHC, GEHCO (values TBD)
Section 3.3.1 of RFC 2508 [14] specifies that a FULL_HEADER packet
is a PPP frame with a full header and the context ID placed in the
IP and UDP length field. Two context formats are specified, one an
8 bit and the other a 16 bit length ID. Section 3.3.1 specifies the
placement of the Context ID in those length fields.
The GEHCO_FULL_HEADER carries only one RTP flow in a given
connection. Therefore, the connection ID we propose above fulfills
a similar function as the Context ID does in RFC 2508. We propose
that the connection ID be placed in the IP and UDP fields, that
there be two such connection ID options, and that the placement of
the connection ID be the same as that of the Context ID as
specified in RFC 2508. GEHCO does not require that a sequence
number be carried in the GEHCO_FULL_HEADER.
7.4 RTCP
RTP has a control protocol that occasionally sends control packets.
In GEHCO, these would be transported over the PPP frame connection
in PPP frames. The taxation is negligible because very few packets
are sent.
7.5 GEHCO and Cell Phones
The decompressor was depicted above as recreating RTP packets from
the compressed voice (or IP multimedia) and passing that packet up
the IP stack. In an integrated cell phone, actual creation of
Hiller, McCann January 2000 - Expiration 11
Good Enough Header Compression (GEHCO) August 2000
these packets may not be required because there would be no need to
add IP/UDP/RTP headers to pass up an IP stack just to be taken off
again before delivery to a vocoder. In a laptop or palmtop, etc.,
the story is different because of an existing IP stack with
applications that must be accommodated.
Cell phones in general will have an IP stack to support the
integral browser and SIP (and RTCP) protocols. The compressed voice
need not be placed into RTP format within the phone.
7.6 Simultaneous Use of Transparent and Non-Transparent Compression
This section would not apply to VOIP header compression in cell
phones since non-transparent compression alone will suffice.
Usually one would expect only one RTP compression scheme to be
active on a given mobile (i.e. a laptop) at any time. For laptops,
if it is necessary to allow transparent and non-transparent header
compression methods to be simultaneously active, then the PPP layer
would not know whether to use a transparent scheme (like ROCCO,
ACE, CRTP, etc.) or GEHCO for a given flow. There are a couple of
solutions. One would be to for the mobile application to have an
API to the PPP layer that indicates the type on a per flow basis.
The mobile would then negotiate with the PPP peer the appropriate
type of compression to use for the flow. The other approach would
be for ROHC to agree upon RTP Payload types to be used with non-
transparent compression. The mobile and network PPP peers then
just use this to determine when to use GEHCO.
8. Security Considerations
Non transparent compression will be used over radio links that
feature strong encryption; such encryption is optional and users
who defer it are more susceptible to attack. The identity of users
of these radio links will be authenticated via a private key in
both the radio realm and the IETF based AAA realm. In general, it
is very difficult in inject frames onto the radio links; as other
drafts on compression have pointed out, if a hacker is able to
inject frames onto the radio links, the problems this creates far
exceed just those associated with compression and decompression.
9. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] RFC 2543, SIP: Session Initiation Protocol, Handley,
Schulzrinne, Schooler, Rosenberg, March 1999
Hiller, McCann January 2000 - Expiration 12
Good Enough Header Compression (GEHCO) August 2000
[4] Enhancements to IP/UDP/RTP Header Compression (draft-koren-avt-
crtp-enhance-01.txt), Koren, Casner, Ruddy, Thompson, Tweedly,
Geevarghese, March, 2000 (IETF draft)
[5] Robust Checksum-based header COmpression (ROCCO) (draft-
jonsson-robust-hc-04.txt), Lars-Erik Jonsson, Mikael Degermark,
Hans Hannu,Krister Svanbro, March 10, 2000 (IETF draft)
[6] Adaptive Header ComprEssion (ACE) for Real-Time Multimedia
(draft-ace-robust-hc-01.txt), Le, Clanton, Liu, Zheng, March 2000
(IETF draft)
[7] Over-the-Air Voice over IP (VoIP) Issues and Recommended Phases
(ALLIP-20000323-006_QUA_VoIP_Issues), Hsu, Odenwalder, Chen,
Tiedemann, 3GPP2 All IP, March 2000
[8] RFC 1661, The Point-to-Point Protocol (PPP), W. Simpson, July
1994
[9] RFC 1662, PPP in HDLC-like Framing, W. Simpson, July 1994
[10] RFC 1570, PPP LCP Extensions, W. Simpson, January 1994
[11] End-to-End QoS for VOIP and Multimedia in 3GPP2 ALL IP
Networks (SC-ALLIP-20000426-009_LUC_End-to_End), Tom Hiller, Pete
McCann, 3GPP2 All IP, April 2000
[12] Tdoc SMG2 981/00, Voice Over GERAN/UTRAN PS Domain, Nortel
Networks, ETSI SMG2 #36, see Table 3
[13] RFC2509, IP Header Compression over PPP, Engan, Casner,
Bormann, February 1999
[14] RFC2508, Compressing IP/UDP/RTP Headers for Low-Speed Serial
Links, Casner, Jacobson, February 1999
10. Acknowledgments
The author wish to acknowledge the input of Qualcomm's Ray Hsu et
al who initially identified the spectral tax associated with
IP/UDP/RTP transparent compression schemes, and Mark Lipford of
SPCS and Mark Munson of Verizon for their business insights on
spectral capacity, and encouragement to pursue non transparent
compression.
11. Author's Addresses
Tom Hiller
Lucent Technologies
263 Shuman Drive
Hiller, McCann January 2000 - Expiration 13
Good Enough Header Compression (GEHCO) August 2000
Naperville, IL. USA 60137
Phone: 630-979-7673
Email: tom.hiller@lucent.com
Pete McCann
Lucent Technologies
263 Shuman Drive
Naperville, IL. USA 60137
Phone: 630-713-9359
Email: mccap@lucent.com
Hiller, McCann January 2000 - Expiration 14
Good Enough Header Compression (GEHCO) August 2000
Full Copyright Statement
"Copyright (C) The Internet Society 2000. All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into other
languages._
Hiller, McCann January 2000 - Expiration 15
Good Enough Header Compression (GEHCO) August 2000
Hiller, McCann January 2000 - Expiration 16
| PAFTECH AB 2003-2026 | 2026-04-22 15:18:23 |