Network Working Group Kristofer Sandlund, Effnet AB
INTERNET-DRAFT
Expires: August 2005
February 14, 2005
ROHC LLA Implementer's Guide
<draft-ietf-rohc-rtp-lla-impl-guide-01.txt>
Status of this memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668.
By submitting this Internet-Draft, I (we) accept the provisions of
Section 3 of RFC 3667 (BCP 78).
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is a submission of the IETF ROHC WG. Comments should be
directed to the ROHC WG mailing list, rohc@ietf.org.
Abstract
This document describes common misinterpretations and some ambiguous
points of ROHC LLA [3], which defines the Link-Layer Assisted profile
for IP/UDP/RTP.
These points have been identified by the members of the ROHC working
group during implementation of the profile.
Sandlund [Page 1]
INTERNET-DRAFT ROHC LLA Implementer's Guide February 14, 2005
Table of Contents
1. Introduction.....................................................2
2. Terminology......................................................2
3. CSP Packet Format................................................2
4. CRC Verification of CCP packets..................................3
5. Security Consideration...........................................3
6. Acknowledgments..................................................4
7. Authors' Addresses...............................................4
8. References.......................................................4
8.1. Normative references........................................4
1. Introduction
ROHC LLA [3] defines a profile for compressing IP/UDP/RTP by using
functionality provided by the lower layers to achieve a zero byte
compressed header during normal operation.
During implementation of this profile, some errors and unclear areas
have been identified. This document tries to correct and clarify
those points.
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 [1].
3. CSP Packet Format
The format of the CSP packet has been identified as non-interoperable
when carrying a RHP header with a 3-bit or 7-bit CRC. This problem
occurs due to the payload having been dropped by the compressor,
while the decompressor is supposed to use the payload length to infer
certain fields in the uncompressed header. These fields are the IPv4
total length, the IPv6 payload length, the UDP length and the IPv4
header checksum field (all INFERRED fields in [2]).
To correct this problem, the CSP packet needs to contain information
about the payload length carried in the RHP packet. Therefore the
length of the RTP payload is carried in the CSP packet. The redefined
format for the CSP packet is therefore as follows:
Sandlund [Page 2]
INTERNET-DRAFT ROHC LLA Implementer's Guide February 14, 2005
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 1 0 | Packet type identifier
+===+===+===+===+===+===+===+===+
/ RTP Payload Length / 2 octets
+---+---+---+---+---+---+---+---+
: ROHC header without padding :
: see [ROHC, section 5.7] :
+---+---+---+---+---+---+---+---+
Updating properties: CSP maintains the updating properties of the
ROHC header it carries.
RTP Payload Length: This field is the length of the payload
carried inside the RTP header, stored in network byte order. I.e.
this field will be set by the compressor to (UDP length - size of
the RTP header including CSRC identifiers).
When the decompressor receives a CSP packet, it MUST use the RTP
payload length field to calculate the value of fields classified as
INFERRED in [2] when attempting to verify a 3- or 7-bit CRC carried
in the RHP header enclosed in the CSP.
When the encapsulated RHP packet only carries an 8-bit CRC, the RTP
payload length MAY be used by the decompressor for verification of
the decompressed header.
The packet format defined in this section obsoletes the header format
for the CSP defined in [3] Section 4.1.2.
4. CRC Verification of CCP packets
When a CCP packet with the C-bit set is received by the decompressor,
the decompressor uses the 7-bit CRC in the packet to verify the
context. For this verification to succeed, the decompressor needs to
have access to the entire uncompressed header of the latest packet
decompressed.
Some implementations of [2] might not save the values of INFERRED
fields. An implementation of ROHC LLA MUST save these fields in the
decompressor context to be able to successfully verify CCP packets.
Also, section 4.1.3 of [3] states that upon CRC failure, the actions
of [2] section 5.3.2.2.3 MUST be taken. That section specifies that
detection of SN wraparound and local repair must be performed.
Neither of these steps apply when the failing packet is a CCP, and
therefore only the action described when both these steps fail should
be taken (i.e the steps a-d).
5. Security Consideration
Sandlund [Page 3]
INTERNET-DRAFT ROHC LLA Implementer's Guide February 14, 2005
This document provides some changes and clarifications to [3], but it
is not belived that these changes add any extra security
considerations than those listed in [3].
6. Acknowledgments
The author would like to thank Joakim Enerstam, Ghyslain Pelletier
and Lars-Erik Jonsson for their contributions and comments.
7. Authors' Addresses
Kristofer Sandlund Tel: +46 920 60917
Effnet AB EMail: kristofer.sandlund@effnet.com
Stationsgatan 69
97234 Lulea
Sweden
8. References
8.1. Normative references
[1] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] C. Bormann, et. al, "RObust Header Compression (ROHC): Framework
and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095,
July 2001.
[3] L. Jonsson, G. Pelletier, "RObust Header Compression (ROHC): A
Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, April
2002.
Sandlund [Page 4]
INTERNET-DRAFT ROHC LLA Implementer's Guide February 14, 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires August 14, 2005.
Sandlund [Page 5]
