draft-ietf-rohc-udp-lite-03.txt   draft-ietf-rohc-udp-lite-04.txt 
Network Working Group Ghyslain Pelletier Network Working Group Ghyslain Pelletier
INTERNET-DRAFT Ericsson AB INTERNET-DRAFT Ericsson AB
Expires: November 2004 Expires: December 2004
May 12, 2004 June 9, 2004
RObust Header Compression (ROHC): RObust Header Compression (ROHC):
Profiles for UDP-Lite Profiles for UDP-Lite
<draft-ietf-rohc-udp-lite-03.txt> <draft-ietf-rohc-udp-lite-04.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, I (we) certify that any applicable By submitting this Internet-Draft, I (we) certify that any applicable
patent or other IPR claims of which I am (we are) aware have been patent or other IPR claims of which I am (we are) aware have been
disclosed, and any of which I (we) become aware will be disclosed, in disclosed, and any of which I (we) become aware will be disclosed, in
accordance with RFC 3668 (BCP 79). accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, I (we) accept the provisions of By submitting this Internet-Draft, I (we) accept the provisions of
Section #3 of RFC 3667 (BCP 78). Section #3 of RFC 3667 (BCP 78).
skipping to change at page 1, line 46 skipping to change at page 1, line 46
This document is a submission of the IETF ROHC WG. Comments should be This document is a submission of the IETF ROHC WG. Comments should be
directed to the ROHC WG mailing list, rohc@ietf.org. directed to the ROHC WG mailing list, rohc@ietf.org.
Abstract Abstract
This document defines ROHC (Robust Header Compression) profiles for This document defines ROHC (Robust Header Compression) profiles for
compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol, compression of RTP/UDP-Lite/IP packets (Real-Time Transport Protocol,
User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP. User Datagram Protocol Lite, Internet Protocol) and UDP-Lite/IP.
These profiles are defined based on their differences with the These profiles are defined based on their differences with the
profiles specified in RFC 3095 [2] for UDP [6]. profiles for UDP specified in RFC 3095.
Table of Contents Table of Contents
1. Introduction.....................................................3 1. Introduction.....................................................3
2. Terminology......................................................4 2. Terminology......................................................4
3. Background.......................................................4 3. Background.......................................................4
3.1. Overview of the UDP-Lite Protocol...........................4 3.1. Overview of the UDP-Lite Protocol...........................4
3.2. Expected Behaviours of UDP-Lite Flows.......................5 3.2. Expected Behaviours of UDP-Lite Flows.......................5
3.2.1. Per-packet behavior....................................5 3.2.1. Per-packet behavior....................................5
3.2.2. Inter-packet behavior..................................5 3.2.2. Inter-packet behavior..................................5
3.2.3. Per-flow behavior......................................6 3.2.3. Per-flow behavior......................................6
3.3. Header Field Classification.................................6 3.3. Header Field Classification.................................6
4. Rationale behind the Design of ROHC Profiles for UDP-Lite........7 4. Rationale behind the Design of ROHC Profiles for UDP-Lite........7
4.1. Design Motivations..........................................7 4.1. Design Motivations..........................................7
4.2. ROHC Considerations.........................................7 4.2. ROHC Considerations.........................................7
5. ROHC Profiles for UDP-Lite.......................................7 5. ROHC Profiles for UDP-Lite.......................................7
5.1. Context Parameters..........................................8 5.1. Context Parameters..........................................8
5.2. Initialization..............................................9 5.2. Initialization..............................................9
5.2.1. Initialization of the UDP-Lite Header [7]..............9 5.2.1. Initialization of the UDP-Lite Header [1]..............9
5.2.2. Compressor and Decompressor Logic......................9 5.2.2. Compressor and Decompressor Logic......................9
5.3. Packet Formats.............................................10 5.3. Packet Formats.............................................10
5.3.1. General Packet Format.................................10 5.3.1. General Packet Format.................................10
5.3.2. Packet Type CCE: CCE(), CCE(ON) and CCE(OFF)..........11 5.3.2. Packet Type CCE: CCE(), CCE(ON) and CCE(OFF)..........11
5.3.2.1. Properties of CCE():.............................12 5.3.2.1. Properties of CCE():.............................12
5.3.2.2. Properties of CCE(ON):...........................12 5.3.2.2. Properties of CCE(ON):...........................12
5.3.2.3. Properties of CCE(OFF):..........................12 5.3.2.3. Properties of CCE(OFF):..........................12
5.4. Compressor Logic...........................................13 5.4. Compressor Logic...........................................13
5.5. Decompressor Logic.........................................13 5.5. Decompressor Logic.........................................13
5.6. Additional Mode Transition Logic...........................13 5.6. Additional Mode Transition Logic...........................13
skipping to change at page 3, line 21 skipping to change at page 3, line 21
over wireless, ROHC [2] has mainly focused on compression of over wireless, ROHC [2] has mainly focused on compression of
IP/UDP/RTP headers, which are generous in size, especially compared IP/UDP/RTP headers, which are generous in size, especially compared
to the payloads often carried by packets with these headers. to the payloads often carried by packets with these headers.
ROHC RTP has become a very efficient, robust and capable compression ROHC RTP has become a very efficient, robust and capable compression
scheme, able to compress the headers down to a total size of one scheme, able to compress the headers down to a total size of one
octet only. Also, transparency is guaranteed to an extremely high octet only. Also, transparency is guaranteed to an extremely high
extent, even when residual bit errors are present in compressed extent, even when residual bit errors are present in compressed
headers delivered to the decompressor. headers delivered to the decompressor.
UDP-Lite [7] is a transport protocol similar to the UDP protocol [6]. UDP-Lite [1] is a transport protocol similar to the UDP protocol [7].
UDP-Lite is useful for applications that are designed with the UDP-Lite is useful for applications that are designed with the
capability to tolerate errors in the payload and for which receiving capability to tolerate errors in the payload and for which receiving
damaged data is better than dealing with the loss of entire packets. damaged data is better than dealing with the loss of entire packets.
This may be particularly suitable when packets are transported over This may be particularly suitable when packets are transported over
link technologies where data can be partially damaged, such as link technologies where data can be partially damaged, such as
wireless links. wireless links.
Although both transport protocols are very similar, ROHC profiles Although both transport protocols are very similar, ROHC profiles
must be defined separately for robust compression of UDP-Lite headers must be defined separately for robust compression of UDP-Lite headers
because UDP-Lite does not share protocol identifier with UDP. Also, because UDP-Lite does not share the same protocol identifier with
the UDP-Lite Checksum Coverage field does not share the semantics of UDP. Also, the UDP-Lite Checksum Coverage field does not share the
the corresponding UDP Length field and as a consequence it cannot semantics of the corresponding UDP Length field and as a consequence
always be inferred anymore. it cannot always be inferred anymore.
This document defines two ROHC profiles for efficient compression of This document defines two ROHC profiles for efficient compression of
UDP-Lite headers. The objective of this document is to provide simple UDP-Lite headers. The objective of this document is to provide simple
modifications to the corresponding ROHC profiles for UDP specified in modifications to the corresponding ROHC profiles for UDP specified in
RFC 3095 [2]. In addition, the ROHC profiles for UDP-Lite support RFC 3095 [2]. In addition, the ROHC profiles for UDP-Lite support
some of the mechanisms defined in the profile for compression of IP some of the mechanisms defined in the profile for compression of IP
headers [3] (ROHC IP-Only). This specification includes support for headers [3] (ROHC IP-Only). This specification includes support for
compression of multiple IP headers and for compressing IP-ID fields compression of multiple IP headers and for compressing IP-ID fields
with constant behavior, as well as improved mode transition logic and with constant behavior, as well as improved mode transition logic and
a feedback option for decompressors with limited memory resources. a feedback option for decompressors with limited memory resources.
skipping to change at page 4, line 24 skipping to change at page 4, line 24
ROHC RTP/UDP-Lite: RTP/UDP-Lite/IP profile defined in this document. ROHC RTP/UDP-Lite: RTP/UDP-Lite/IP profile defined in this document.
3. Background 3. Background
3.1. Overview of the UDP-Lite Protocol 3.1. Overview of the UDP-Lite Protocol
UDP-Lite is a transport protocol defined as an independent variant of UDP-Lite is a transport protocol defined as an independent variant of
the UDP transport protocol. UDP-Lite is very similar to UDP, and it the UDP transport protocol. UDP-Lite is very similar to UDP, and it
allows applications that can tolerate errors in the payload to use a allows applications that can tolerate errors in the payload to use a
checksum with an optional partial coverage. This is particularly checksum with an optional partial coverage. This is particularly
useful with IPv6 [5], where the use of the transport-layer checksum useful with IPv6 [6], where the use of the transport-layer checksum
is mandatory. is mandatory.
UDP-Lite replaces the Length field of the UDP header with a Checksum UDP-Lite replaces the Length field of the UDP header with a Checksum
Coverage field. This field indicates the number of octets covered by Coverage field. This field indicates the number of octets covered by
the 16-bit checksum, which is applied on a per-packet basis. The the 16-bit checksum, which is applied on a per-packet basis. The
coverage area must always include the UDP-Lite header and may cover coverage area always include the UDP-Lite header and may cover the
the entire packet, in which case UDP-Lite becomes semantically entire packet, in which case UDP-Lite becomes semantically identical
identical to UDP. UDP-Lite and UDP do not share protocol identifier. to UDP. UDP-Lite and UDP do not share the same protocol identifier.
The UDP-Lite header format: The UDP-Lite header format:
0 15 16 31 0 15 16 31
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Source | Destination | | Source | Destination |
| Port | Port | | Port | Port |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Checksum | | | Checksum | |
| Coverage | Checksum | | Coverage | Checksum |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| | | |
: Payload : : Payload :
| | | |
+-----------------------------------+ +-----------------------------------+
The UDP-Lite checksum, like the UDP checksum, is an end-to-end The UDP-Lite checksum, like the UDP checksum, is an end-to-end
mechanism against erroneous delivery of error sensitive data. mechanism against erroneous delivery of error sensitive data.
This checksum is mandatory with IPv6 [5] for both protocols.
However, as opposed to UDP, the UDP-Lite checksum may not be However, as opposed to UDP, the UDP-Lite checksum may not be
transmitted as all zeroes and cannot be disabled for IPv4 [4]. transmitted as all zeroes and cannot be disabled for IPv4 [5].
For UDP, in the case where the checksum is disabled (IPv4 only), the For UDP, in the case where the checksum is disabled (IPv4 only), the
Checksum field maintains a constant value and is normally not sent by Checksum field maintains a constant value and is normally not sent by
the header compression scheme. In the case where the UDP checksum is the header compression scheme. In the case where the UDP checksum is
enabled (mandatory for IPv6), such an unpredictable field cannot be enabled (mandatory for IPv6), such an unpredictable field cannot be
compressed and is sent uncompressed. The UDP Length field, however, compressed and is sent uncompressed. The UDP Length field, however,
is always redundant and can be provided by the IP module. Header is always redundant and can be provided by the IP module. Header
compression schemes do not normally transmit any bits of information compression schemes do not normally transmit any bits of information
for this field, as its value can be inferred from the link layer. for this field, as its value can be inferred from the link layer.
skipping to change at page 5, line 30 skipping to change at page 5, line 30
The following summarizes the relationship between UDP and UDP-Lite: The following summarizes the relationship between UDP and UDP-Lite:
- UDP-Lite and UDP have different protocol identifiers; - UDP-Lite and UDP have different protocol identifiers;
- The UDP-Lite checksum cannot be disabled for IPv4; - The UDP-Lite checksum cannot be disabled for IPv4;
- UDP-Lite redefines the UDP Length field as the Checksum - UDP-Lite redefines the UDP Length field as the Checksum
Coverage field, with different semantics; Coverage field, with different semantics;
- UDP-Lite is semantically equivalent to UDP when the Checksum - UDP-Lite is semantically equivalent to UDP when the Checksum
Coverage field indicates the total length of the packet. Coverage field indicates the total length of the packet.
The next section provides a more detailed discussion of the behavior The next section provides a more detailed discussion of the behavior
of the Checksum Coverage field of UPD-Lite in relation to header of the Checksum Coverage field of UDP-Lite in relation to header
compression. compression.
3.2. Expected Behaviours of UDP-Lite Flows 3.2. Expected Behaviours of UDP-Lite Flows
3.2.1. Per-packet behavior 3.2.1. Per-packet behavior
As mentioned in the previous section, the checksum coverage value As mentioned in the previous section, the checksum coverage value
is applied independently of other packets that may belong to the is applied independently of other packets that may belong to the
same flow. Specifically, the value of the checksum coverage may same flow. Specifically, the value of the checksum coverage may
indicate that the UDP-Lite packet is either entirely covered by the indicate that the UDP-Lite packet is either entirely covered by the
skipping to change at page 9, line 17 skipping to change at page 9, line 17
Unless stated otherwise, the mechanisms of ROHC RTP and ROHC UDP Unless stated otherwise, the mechanisms of ROHC RTP and ROHC UDP
found in [2] are used also for the ROHC RTP/UDP-Lite and the ROHC found in [2] are used also for the ROHC RTP/UDP-Lite and the ROHC
UDP-Lite profiles, respectively. UDP-Lite profiles, respectively.
In particular, the considerations of ROHC UDP regarding the UDP SN In particular, the considerations of ROHC UDP regarding the UDP SN
taking the role of the RTP Sequence Number apply to ROHC UDP-Lite. taking the role of the RTP Sequence Number apply to ROHC UDP-Lite.
Also, the static context for ROHC UDP-Lite may be initialized by Also, the static context for ROHC UDP-Lite may be initialized by
reusing an existing context belonging to a stream compressed using reusing an existing context belonging to a stream compressed using
ROHC RTP/UDP-Lite (profile 0x0007), similarly as for ROHC UDP. ROHC RTP/UDP-Lite (profile 0x0007), similarly as for ROHC UDP.
5.2.1. Initialization of the UDP-Lite Header [7] 5.2.1. Initialization of the UDP-Lite Header [1]
The structure of the IR and IR-DYN packets and the initialization The structure of the IR and IR-DYN packets and the initialization
procedures are the same as for the ROHC profiles for UDP [2], with procedures are the same as for the ROHC profiles for UDP [2], with
the exception of the dynamic part as specified for UDP. A 2-octet the exception of the dynamic part as specified for UDP. A 2-octet
field containing the checksum coverage is added before the Checksum field containing the checksum coverage is added before the Checksum
field. This affects the format of dynamic chains in both IR and IR- field. This affects the format of dynamic chains in both IR and IR-
DYN packets. DYN packets.
Dynamic part: Dynamic part:
skipping to change at page 15, line 12 skipping to change at page 15, line 12
Note: All other fields are the same as for the respective ROHC Note: All other fields are the same as for the respective ROHC
profiles for UDP [2]. profiles for UDP [2].
6. Security Considerations 6. Security Considerations
The security considerations of RFC 3095 [2] apply integrally to this The security considerations of RFC 3095 [2] apply integrally to this
document without modifications. document without modifications.
7. IANA Considerations 7. IANA Considerations
ROHC profile identifiers 0x00XX and 0x00YY <# Editor's Note: To be ROHC profile identifiers 0x0007 (ROHC RTP/UDP-Lite) and 0x0008 (ROHC
replaced before publication #> has been reserved by the IANA for the UDP-Lite) have been reserved by the IANA for the profiles defined in
profiles defined in this document. this document.
<# Editor's Note: To be removed before publication #> { NOTE TO IANA - TO BE REMOVED BEFORE PUBLICATION }
A ROHC profile identifier must be reserved by the IANA for the
profiles defined in this document. Profiles 0x0000-0x0006 have
previously been reserved, which means that these profiles could be
assigned identifiers 0x0007 and 0x0008.
<# Editor's Note: To be removed before publication #> Two ROHC profile identifiers must be reserved by the IANA for the
As for previous ROHC profiles, profile numbers 0xnnXX and 0xnnYY must profiles defined in this document. Since profile number 0x0006 is
also be reserved for future updates of these profiles. A suggested being saved for the TCP/IP (ROHC-TCP) profile, profile numbers
registration in the "RObust Header Compression (ROHC) Profile 0x0007 and 0x0008 are the most suitable unused identifiers
Identifiers" name space would then be: available, and should thus be used. As for previous ROHC profiles,
profile numbers 0xnn07 and 0xnn08 must also be reserved for future
variants of these profiles. The registration suggested for the
"RObust Header Compression (ROHC) Profile Identifiers" name space:
Profile Document Usage OLD: 0x0006-0xnn7F To be Assigned by IANA
Identifier
0x0007 RFCXXXX (this) ROHC RTP/UDP-Lite NEW: 0xnn06 To be Assigned by IANA
0x0007 ROHC RTP/UDP-Lite [RFCXXXX (this)]
0xnn07 Reserved 0xnn07 Reserved
0x0008 RFCXXXX (this) ROHC UDP-Lite 0x0008 ROHC UDP-Lite [RFCXXXX (this)]
0xnn08 Reserved 0xnn08 Reserved
0x0009-0xnn7F To be Assigned by IANA
{ END OF NOTE }
8. Acknowledgments 8. Acknowledgments
The author would like to thank Lars-Erik Jonsson, Kristofer Sandlund, The author would like to thank Lars-Erik Jonsson, Kristofer Sandlund,
Mark West, Richard Price, Fredrik Linstroem and Mats Nordberg for Mark West, Richard Price, Gorry Fairhurst, Fredrik Linstroem and Mats
useful reviews and discussions around this document. Nordberg for useful reviews and discussions around this document.
9. Author's Address 9. Author's Address
Ghyslain Pelletier Ghyslain Pelletier
Ericsson AB Ericsson AB
Box 920 Box 920
SE-971 28 Lulea, Sweden SE-971 28 Lulea, Sweden
Phone: +46 920 20 24 32 Phone: +46 920 20 24 32
Fax : +46 920 20 20 99 Fax : +46 920 20 20 99
Email: ghyslain.pelletier@ericsson.com Email: ghyslain.pelletier@ericsson.com
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] S. Bradner, "Key words for use in RFCs to Indicate Requirement [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
skipping to change at page 16, line 25 skipping to change at page 16, line 25
Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed", Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001. RFC 3095, July 2001.
<# Editor's Note: RFC number to be updated before publication #> <# Editor's Note: RFC number to be updated before publication #>
<# for <draft-ietf-rohc-ip-only-05.txt> #> <# for <draft-ietf-rohc-ip-only-05.txt> #>
[3] Jonsson, L. and G. Pelletier, "RObust Header Compression (ROHC): [3] Jonsson, L. and G. Pelletier, "RObust Header Compression (ROHC):
A compression profile for IP", RFCZZZZ, %Month% 2004. A compression profile for IP", RFCZZZZ, %Month% 2004.
<# Editor's Note: RFC number to be updated before publication #>
<# for <draft-ietf-tsvwg-udp-lite-02.txt> #>
[4] Larzon, L., Degermark, M., Pink, S., Jonsson, L. and G.
Fairhurst, "The UDP-Lite Protocol", RFCUUUU, %Month% 2004.
10.2. Informative References 10.2. Informative References
[4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August [7] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980. 1980.
[7] Larzon, L., Degermark, M., Pink, S., Jonsson, L. and G.
Fairhurst, "The UDP-Lite Protocol", Internet draft (work in
progress), August 2003, <draft-ietf-tsvwg-udp-lite-02.txt>
[8] Schulzrinne, H., Casner S., Frederick, R. and V. Jacobson, "RTP: [8] Schulzrinne, H., Casner S., Frederick, R. and V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications", RFC 1889, A Transport Protocol for Real-Time Applications", RFC 1889,
January 1996. January 1996.
Appendix A - Detailed Classification of Header Fields Appendix A - Detailed Classification of Header Fields
This section summarizes the difference from the classification found This section summarizes the difference from the classification found
in the corresponding appendix in RFC 3095 [2], and similarly provides in the corresponding appendix in RFC 3095 [2], and similarly provides
conclusions about how the various header fields should be handled by conclusions about how the various header fields should be handled by
the header compression scheme to optimize compression and the header compression scheme to optimize compression and
skipping to change at page 22, line 45 skipping to change at page 22, line 45
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires November 12, 2004. This Internet-Draft expires December 9, 2004.
 End of changes. 

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