Network Working Group Ghyslain Pelletier
INTERNET-DRAFT Ericsson
Expires: August 2002
February 22, 2002
RObust Header Compression (ROHC):
Profiles for UDP Lite
<draft-pelletier-rohc-udplite-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
This document defines ROHC (Robust Header Compression) profiles for
compression of IP/UDP Lite/RTP packets (Internet Protocol, User
Datagram Protocol Lite, Real-Time Transport Protocol) and IP/UDP
Lite. These profiles are defined based on their differences with the
profiles specified in [RFC-3095] for the classic UDP [RFC-768].
Although both transport protocols are very similar, ROHC profiles
must be defined separately for robust compression of UDP Lite headers
Pelletier [Page 1]
INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002
because it does not share protocol identifier with the classic UDP.
Also, the UDP Lite Checksum Coverage field does not either share the
semantics of the corresponding classic UDP Length field and as a
consequence cannot always be inferred anymore. In addition, this
coverage field may open new possibilities for additional compression
efficiency when compared to the UDP profiles defined in [RFC-3095].
Table of contents
1. Introduction....................................................3
2. Terminology.....................................................4
3. Background......................................................4
3.1. The UDP Lite Protocol....................................4
3.2. Checksum Coverage........................................6
4. Rationale behind the design of UDP Lite ROHC profiles...........8
4.1. UDP Lite Considerations..................................8
4.2. ROHC Considerations......................................8
4.3. Header Compression strategies for UDP Lite...............9
4.4. UPD Lite checksum and ROHC CRC..........................10
5. ROHC UDP Lite profiles.........................................10
5.1. Initialization of the UDP Lite header [UDPLITE]..........11
5.2. States and modes.........................................11
5.3. Packet type format.......................................11
5.4. IP/UDP Lite/RTP compression: ROHC RTP/UDPLite............12
5.4.1. Initialization........................................12
5.4.2. Packet types..........................................12
5.4.2.1 Packet type 0: TBD...................................12
5.4.2.2 Packet type 1: TBD...................................13
5.4.2.3 Packet types 2, IR, IR-DYN and extensions............13
5.5. Non-RTP IP/UPD Lite compression: ROHC UDPLite............13
5.5.1. Initialization........................................13
5.5.2. Packet types..........................................13
6. Security considerations........................................13
7. Acknowledgements...............................................14
8. Intellectual Property Right Claim Considerations...............14
9. References.....................................................14
10. Authors address................................................14
Pelletier [Page 2]
INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002
1. Introduction
The ROHC WG has developed a header compression framework on top of
which various profiles can be defined for different protocol sets, or
for different compression strategies. Due to the demands of the
cellular industry for an efficient way of transporting voice over IP
over wireless, the main focus of ROHC [RFC-3095] has so far been on
compression of IP/UDP/RTP headers, which are generous in size,
especially compared to the payloads often carried by the packets with
these headers.
ROHC RTP has become a very efficient, robust and capable compression
scheme, able to compress the headers down to a total size of one
octet only. Also, transparency is guaranteed to an extremely high
extent even when residual bit errors are present in compressed
headers delivered to the decompressor.
UDP Lite is a transport protocol similar to the classic UDP protocol
[RFC-768]. UDP Lite is useful for applications that are designed with
the capability to tolerate errors in the payload and for which
receiving damaged data is better than dealing with the loss of entire
packets. The protocol is particularly suitable for link technologies
where data can be partially damaged, such as wireless links.
New ROHC profiles are needed for UDP Lite because it does not share
protocol identifier with the classic UDP. Also, the UDP Lite Checksum
Coverage field does not either share the semantics of the
corresponding Length field of the classic UDP and cannot always be
inferred. In addition, the coverage field may open new possibilities
for additional compression efficiency when compared to ROHC RTP.
This document thus defines two ROHC profiles to allow compression of
UDP Lite headers. The objectives of these profiles are to provide
simple modifications to the existing profiles for compressing classic
UDP headers, as well as introducing a simple method by which the UDP
Lite checksum may be entirely compressed away in certain specific
scenarios, without threats to the end-to-end nature of this checksum.
This document therefore focuses on differences to the compression
profiles for classic UDP headers, as specified in [RFC-3095], to
define corresponding profiles for UDP Lite header compression.
Revision history:
00: First version of this document, including:
Motivation for the work, the problematic and some possible
directions.
This first draft is currently showing the initial state of the work,
and will hopefully generate fruitful discussions around header
compression for UDP Lite within the ROHC WG.
Pelletier [Page 3]
INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002
2. Terminology
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.
ROHC Robust Header Compression
Classic UDP Classic UDP, as defined in [RFC-768]
UDP Lite UDP Lite, as defined in [UDPLite]
ROHC RTP
ROHC RTP in this document refers to the RTP/UDP/IP profile 0x0001
as defined in [RFC-3095].
ROHC UDP
ROHC UDP in this document refers to the non-RTP UDP/IP profile
0x0002 as defined in [RFC-3095].
ROHC UDPLite
ROHC UDPLite in this document refers to the non-RTP UDP Lite/RTP
profile, as defined in this document.
ROHC RTP/UDPLite
ROHC RTP/UDPLite in this document refers to the RTP/UDP Lite
profile, as defined in this document.
3. Background
3.1. The UDP Lite Protocol
UDP Lite is a datagram transport protocol defined as an independant
variant of the classic UDP transport protocol [RFC-768]. UDP Lite is
very similar to the classic UDP, and allow applications that can
tolerate errors in the payload to use a checksum with optionally
partial coverage. See [UDPLite] for further information about the
motivations and benefits of the protocol.
UDP Lite replaces the classic UDP Length field of the header with a
Checksum Coverage field indicating the number of octets covered by
the 16-bit checksum, applied on a per-packet basis. The coverage area
must minimally always include the entire UDP Lite header and may
cover the entire datagram, in which case UDP Lite becomes
semantically identical to the classic UDP. However, UDP Lite and
classic UDP do not share protocol identifier.
Pelletier [Page 4]
INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002
UDP Lite Header Format:
0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| Checksum | |
| Coverage | Checksum |
+--------+--------+--------+--------+
| |
| data bytes ... |
+---------------- ...---------------+
The UDP Lite checksum, like the classic UDP checksum, is an end-to-
end mechanism against erroneous delivery of error sensitive data.
In the case where the checksum is enabled for classic UDP (mandatory
for IPv6 [RFC-2460]), such an unpredictable field cannot be
compressed and is sent unmodified. The classic UDP Length field,
however, is redundant and can be provided by the IP module. Header
compression schemes do not normally transmit any bits of information
for this field, as its value can be inferred.
For UDP Lite, the Length field being redefined as the Checksum
Coverage field leads to different properties for both the Checksum
Coverage and the Checksum fields from a header compression
perspective. The following table summarizes a possible classification
for the UDP Lite header fields, using the same classes as in [RFC-
3095].
UDP Lite header fields and Classic UDP fields:
+-------------------+-------------+
| UDP Lite | Classic UDP |
+-------------------+--------+-------------------+-------------+
| Header | Size | Class | Class |
| Field | (bits) | | |
+-------------------+--------+-------------------+-------------+
| Source Port | 16 | STATIC-DEF | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF | STATIC-DEF |
| Checksum Coverage | 16 | CHANGING/INFERRED | |
| Length | 16 | | INFERRED |
| Checksum | 16 | CHANGING/INFERRED | CHANGING |
+-------------------+--------+-------------------+-------------+
One difference from the classic UDP header fields behavior is that
only in some cases may the Checksum Coverage be inferred, more
specifically when either only the header(s) (UDP Lite header only or
UDP Lite/RTP headers) or the entire datagram is covered.
Another difference lies in the nature of the UDP Lite checksum field
itself: the checksum value depends on the Checksum Coverage field and
Pelletier [Page 5]
INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002
may exclude payload. An interesting consideration from a header
compression perspective is that it may be acceptable under certain
circumstances to replace the UDP Lite checksum and its functionality
by a stronger cyclic redundancy check (CRC) using less bits, similar
to the CRC currently used in ROHC profiles. Using the ROHC CRC could
in some specific and potentially frequently occurring cases allow the
UDP Lite checksum to be replaced and inferred at the receiver. In
this respect, the presence of a stronger CRC using less bits would
thus make the Checksum field redundant and make it acceptable not to
transmit its uncompressed value.
3.2. Checksum Coverage
It is of interest to consider the semantics of the UDP Lite checksum
when considering header compression, to find out if those semantics
allow for some additional compression efficiency gains. Referring to
[RFC-1144] section 3.1, when addressing the IP checksum:
It seems rather silly to protect the transmission of
information that is not being transmitted.
The semantics of the UDP Lite Checksum allow for partial coverage of
the datagram. It must minimally cover the transport-layer header
[UDPLite]. This is particularly useful with IPv6, where the
transport-layer checksum is mandatory [RFC-2460]. In this specific
case, no information other than the checksum coverage and the actual
checksum needs to be transmitted in the header compressed stream. It
thus seem justified to not transmit those four octets, as this
checksum in this case protects bits that are not transmitted.
Moving forward in this line of reasoning, the case where the checksum
also covers the entire RTP header in addition to the UDP Lite header
may offer a similar opportunity. When operating with a high
compression ratio, very few information bits are being sent as part
of the compressed stream. It this case, it may also be acceptable to
not transmit the checksum value, provided equal or superior
protection is provided within the header compression scheme to
replace the checksum functionality, for example transmitting a strong
enough CRC within the compressed header. At the receiver, the
checksum may then be regenerated locally when decompressing the
headers and then validated using the CRC.
The following figure shows the relationship between the possible UDP
Lite checksum coverage and the ROHC CRC coverage.
UDP Lite Checksum and ROHC CRC coverage:
+--------+--------------+---------+-------------+
| IP hdr | UDP Lite hdr | RTP hdr | RTP Payload |
+--------+--------------+---------+-------------+
<----- ROHC CRC coverage -------->
<- UDP Lite Checksum --><- Optional coverage -->
Pelletier [Page 6]
INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002
The UDP Lite Checksum Coverage field has four possible different
behaviors embodied via the following assignments for its value:
a. set to the UDP datagram length (or is set to 0)
b. set to the UDP Lite header size (set to 8)
c. set to the UDP Lite/RTP header size
d. set to an unpredictable value, fluctuating between the UDP Lite
(or UDP Lite/RTP) header length and the entire datagram length.
The semantics of the Checksum Coverage field thus yields a number of
different transport scenarios each having different properties from a
header compression perspective. These properties are further
summarized in the following figures, for each identified scenarios.
Note that c is a special case of d, for which optimal compression
efficiency may also be desirable.
Note also that it is possible that an application use any of the
possible coverage values within a single packet stream, and this is
unpredictable from a header compression perspective.
Total size of the fields in each class, for each scenarios:
Scenario #1 û Assignment a.:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| INFERRED | 2 | Checksum Coverage
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 2 | Checksum
+------------+---------------+
Scenario #2 û Assignment b. or c.:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| INFERRED | 4 | Checksum Coverage / Checksum
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 0 |
+------------+---------------+
Scenario #3 û Assignment d.:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| INFERRED | 0 |
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 4 | Checksum Coverage / Checksum
+------------+---------------+
Pelletier [Page 7]
INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002
For scenario #1, corresponding to the classic UDP semantics, the
checksum coverage field is inferred as in classic UDP case. The
checksum (if enabled for IPv4) has completely random values and this
field must be included as-is in the compressed header.
For scenario #2, the checksum coverage field may be inferred from the
size of the UDP Lite (UDP Lite or UDP Lite/RTP streams) or the size
of the UDP Lite/RTP header (UDP Lite/RTP streams only). The checksum
field can then be recalculated at the receiver and the ROHC CRC
applied on the entire decompressed to validate the checksum
recalculation.
For scenario #3, the checksum coverage field and the checksum field
have completely random values and these fields must both be included
as-is in the compressed header.
4. Design Rationale for UDP Lite ROHC profiles
A strong motivation for the design of the UDP Lite header compression
profiles is to use the semantics and properties of the UDP Lite
checksum coverage to improve efficiency when the transport-layer
checksum is enabled.
4.1. UDP Lite considerations
The UDP Lite checksum, like the classic UDP checksum, is an end-to-
end mechanism against erroneous delivery of error sensitive data.
Care must be taken not to violate this end-to-end functionality.
The checksum coverage of UDP Lite is applied on a per-packet basis.
As per the protocol definition, there is no guarantee that one of the
scenarios identified in section 3.2 will occur more often than
another. This in turn makes it difficult to maintain state in a
header compression for the coverage field.
The UDP Lite Checksum Coverage field may vary unpredictably and thus
cannot always be inferred, as opposed to the corresponding Length
field of the classic UDP.
4.2. ROHC considerations
The ROHC CRC
ROHC packets may carry a CRC calculated over the uncompressed
header. This CRC is defined at the framework level and is used by
the decompressor to verify that the decompressed header is correct.
This verification serves three purposes:
- Detection of longer losses than can be covered by the sequence
number LSBs
- Protection against failures caused by residual bit errors in the
Pelletier [Page 8]
INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002
compressed header
- Protection against faulty implementations or other error causes
Replacing the transport-layer checksum
Since this document suggests that the end-to-end UDPLite checksum
may be completely compressed away and replaced by the ROHC CRC,
care must be taken to ensure that the CRC used offers equal or
stronger robustness than what is provided by the UDP Lite checksum.
Specifically, the ROHC CRC cannot replace the UDP Lite checksum
unless the UDP Lite Checksum Coverage field covers only the UDP
Lite or the UDP Lite/RTP headers. Otherwise, it must be sent
uncompressed. This is necessary to ensure that the end-to-end
nature of the checksum is maintained.
It is thus reasonable to assume that compression and decompression
transparency can be guaranteed even without explicitly carrying the
uncompressed UPD Lite coverage field and/or uncompressed UDP Lite
Checksum field in header compressed packets, in certain specific
cases.
Reuse of ROHC RTP and ROHC UDP mechanisms
A ROHC compressor will initially behave as for ROHC RTP, however
based on the UDP Lite profile identifier.
The initialization of other headers than the UDP Lite header (IPv4,
IPv6, RTP) is the same as [RFC-3095].
The same actions are taken upon CRC failure as in ROHC 5.3.2.2.3.
Additional notes
A mechanism, for example via the definition of new packet types,
must be defined to allow the compressor to segregate the different
scenarios from each other (section 3.2), to allow the proper
parsing and decompression of both the coverage and checksum fields,
if these scenarios are to be used as a basis to improve compression
efficiency. This mechanism may be defined in combination with a
context value indicating if the checksum is enabled or not, similar
to [RFC-3095].
Additionally, for scenario #2 (section 3.2) it may be possible to
achieve a minimal compressed header of one octet, similar to PT-0
defined for ROHC RTP, even for IPv6 when the transport protocol
checksum is mandated.
4.3. Header compression strategies for UDP Lite
This table revisits the corresponding table for the classic UDP from
[RFC-3095] section A.3 and classifies the changing fields, based on
Pelletier [Page 9]
INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002
the previously identified scenarios and for the case when the UDP
Lite checksum is enabled.
Header compression strategies for UDP Lite:
+----------------------------+-------------+-----------+-----------+
| Field | Value/Delta | Class | Knowledge |
+============================+=============+===========+===========+
| Datagram| Value | STATIC | KNOWN |
+ --------+-------------+-----------+-----------+
| Checksum Coverage: Header | Value | STATIC | KNOWN |
+ --------+-------------+-----------+-----------+
| Partial | Value | IRREGULAR | UNKNOWN |
+----------------------------+-------------+-----------+-----------+
| Datagram| Value | IRREGULAR | UNKNOWN |
+ --------+-------------+-----------+-----------+
| Checksum(Enabled): Header | Value | IRREGULAR | UNKNOWN |
+ --------+-------------+-----------+-----------+
| Partial | Value | IRREGULAR | UNKNOWN |
+----------------------------+-------------+-----------+-----------+
Datagram: Scenario #1; Header: Scenario #2; Partial: Scenario #3
4.4. UPD Lite checksum and ROHC CRC
It is possible to replace the transport-layer checksum and the ROHC
checksum by a stronger CRC, without removing the protection required
by the transport-layer.
Note well that the idea is to maintain the transport-layer checksum
protection and keep the strong CRC for header reconstruction
verification. Specifically, it consists into having both the header
compression CRC and the transport-layer checksum replaced with a
single checksum with the following properties:
- offers equal or stronger protection than transport-layer checksum
- protects all bits covered by the transport-layer checksum
- offers equal or stronger robustness than the header compression CRC
- protects the original transport-layer checksum
A header compression CRC having these properties would allow the
transport-layer checksum to be recalculated at the decompressor side
before the entire decompressed header, including the recalculated
checksum, is verified and validated using the CRC.
5. ROHC UDP Lite profiles
The profiles defined in this document borrows as much as possible the
mechanisms defined in [RFC-3095]. This section summarizes the
necessary additions and exceptions required from section 5.11 of
[RFC-3095].
Pelletier [Page 10]
INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002
This chapter is incomplete and is an initial proposal for directions.
5.1. Initialization of the UDP Lite header [UDPLITE]
The IR and IR-DYN packets structure and initialization procedures are
the same as for ROHC UDP, unless explicitly stated otherwise.
For ROHC UDPLite, the dynamic part of a UDP packet is different than
from [RFC-3095] (sections 5.11.1 and 5.7.7.5): a two-octet field
containing the UDP Lite Checksum Coverage field is added before the
Checksum field. This affects the format of dynamic chains in IR and
IR-DYN packets.
Static part:
+---+---+---+---+---+---+---+---+
/ Source Port / 2 octets
+---+---+---+---+---+---+---+---+
/ Destination Port / 2 octets
+---+---+---+---+---+---+---+---+
Dynamic part:
+---+---+---+---+---+---+---+---+
/ Checksum Coverage / 2 octets
+---+---+---+---+---+---+---+---+
/ Checksum / 2 octets
+---+---+---+---+---+---+---+---+
CRC-DYNAMIC: Checksum Coverage field, Checksum (octets 5-8).
CRC-STATIC: All other fields (octets 1-4).
5.2. States and modes
ROHC UDPLite uses the same states, state logic and transitions as
ROHC UDP, except when explicitly stated otherwise.
It has not yet been determined whether ROHC UDPLite can use the same
modes as ROHC RTP, and if so - how. This will require more
explanations.
5.3. Packet type format
The general format of a ROHC UDPLite packet is the same as for ROHC
UDP (see [RFC-3095] section 5.11). Padding and CIDs are the same, as
are the feedback packet type (see [RFC-3095] section 5.7.6.1) and the
feedback. IR and IR-DYN packets differ as described in section 5.1.
The general format of compressed packets is also the same, but there
are differences in specific formats as detailed below. These
Pelletier [Page 11]
INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002
differences are introduced by the UPD Lite semantics of the Checksum
Coverage field and the Checksum.
The same notation as in ROHC RTP is used in this section:
<mode format is used in>-<packet type number>-<some property>
5.4. IP/UPD Lite/RTP compression: ROHC RTP/UDPLite (Profile TBD)
Unless stated otherwise, the mechanisms of ROHC RTP are used also for
ROHC RTP/UDPLite.
5.4.1. Initialization
The static context is initialized in the same way as for ROHC RTP
([RFC-3095], section 5.11.1).
5.4.2 Packet types
The notation used in this section is the same as in [RFC-3095]
section 5.7. The general packet format is the same as for a
compressed ROHC RTP header, with an exception for the field
pertaining to the UDP Lite checksum and the addition of a field for
the Checksum Coverage.
--- --- --- --- --- --- --- ---
: :
+ UDP Lite Checksum Coverage + 2 octets,
: : if context(UDP Lite Checksum) != 0
--- --- --- --- --- --- --- ---
: :
+ UDP Lite Checksum + 2 octets,
: : if context(UDP Lite Checksum) != 0
--- --- --- --- --- --- --- ---
Note that the order of the fields following the optional extension is
the same as the order between the fields in an uncompressed header.
Note that the presence of the UDP Lite Checksum and Checksum Coverage
fields is inferred in a similar manner than for [RFC-3095] for every
packet formats, with the exception of PT-0 and PT-1 where it is
instead dependent on the packet format.
5.4.2.1 Packet type 0: PT-0
PT-0: TBA
It has not yet been determined if a 3-bit CRC is suitable to achieve
the desired properties mentioned in section 4.4, and as a consequence
if the U/O-0 packet format of ROHC RTP could be used as PT-0 for this
profile.
Pelletier [Page 12]
INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002
5.4.2.2 Packet type 1: TBD
Packet type 1: TBA
The following header bits should be useful when defining PT-1:
- Packet type (2 bits) : 1 0, for packet type 1
- Checksum Coverage Flag (1 bit): 1, if field is present
- Checksum Flag (1 bit) : 1, if field is present
- CRC (? bits) : ROHC ?-bit CRC
([ROHC], section 5.9.2)
- Other bits, depending on the packet type properties, based on ROHC
RTP PT-0 and PT-1.
Note that the flags are used to identify how the values of the
Checksum Coverage and Checksum fields are to be decompressed, based
on the different scenarios described in section 3.2.
5.4.2.3 Packet types 2, IR, IR-DYN and extensions
Packet type 2 and extensions are the same as [RFC-3095]. Packet types
IR and IR-DYN are the same as in [RFC-3095], except for the changes
of section 5.1.
5.5. Non-RTP IP/UPD Lite compression: ROHC UDPLite (Profile TBD)
Unless stated otherwise, the mechanisms of ROHC UDP are used also for
ROHC UDPLite, with the same considerations regarding the UDP SN
taking the role of the RTP Sequence Number ([RFC-3095] section 5.11).
5.5.1. Initialization
The static context for ROHC UDPLite streams can be initialized in
similar ways as for ROHC UDP, however using the modified IR packet
from section 5.1 and with the profile value set to (TBD) or reusing
an existing context of a stream compressed using ROHC RTP/UDPLite.
Note: In the case where an existing context is reused, the stream may
have originally been assumed a UDP Lite/RTP stream, based on the UDP
Lite protocol identifier (as opposed to assuming profile 0x0001).
5.5.2. Packet types
TBA
6. Security considerations
The security considerations of [RFC-3095] apply integrally to this
document without modifications.
Pelletier [Page 13]
INTERNET-DRAFT ROHC Profiles for UDP Lite February 22, 2002
7. Acknowledgements
The author would like to thank Lars-Erik Jonsson, Krister Svanbro for
reviews and discussions around this document.
8. Intellectual Property Right Claim Considerations
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
9. References
[RFC-3095] C. Bormann, "Robust Header Compression (ROHC)",
RFC 3095, July 2001.
[UDPLite] L. Larzon, M. Degermark, "The UDP Lite Protocol",
Internet draft (work in progress), January 2002.
<draft-ietf-tsvwg-udp-lite-00.txt>
[RFC-1144] V. Jacobson, "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, February 1990.
[RFC-791] J. Postel, "Internet Protocol", RFC 791, September 1981.
[RFC-2460] S. Deering, R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC-768] J. Postel, "User Datagram Protocol", RFC 768, August
1980.
[RFC-1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996.
10. Authors address
Ghyslain Pelletier Tel: +46 920 20 24 32
Ericsson Erisoft AB Fax: +46 920 20 20 99
Box 920
SE-971 28 Lulea
Sweden EMail: ghyslain.pelletier@epl.ericsson.se
This Internet-Draft expires August 22, 2002.
Pelletier [Page 14]