One document matched: draft-ietf-rohc-rtp-lla-impl-guide-00.txt

Network Working Group                      Kristofer Sandlund, Effnet AB
INTERNET-DRAFT
Expires: March 2005                                   September 17, 2004



                       ROHC LLA Implementer's Guide
                <draft-ietf-rohc-rtp-lla-impl-guide-00.txt>


Status of this memo

   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
   disclosed, and any of which I (we) become aware will be disclosed, in
   accordance with RFC 3668 (BCP 79).

   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 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 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   September 17, 2004


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..................................................3
  7. Authors' Addresses...............................................4
  8. References.......................................................4
     8.1. Normative references........................................4
     Intellectual Property Statement..................................5


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   September 17, 2004


      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.


5. Security Consideration

   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




Sandlund                                                        [Page 3]

INTERNET-DRAFT        ROHC LLA Implementer's Guide   September 17, 2004


   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   September 17, 2004


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 IETF's procedures with respect to rights in IETF Documents can
   be found in RFC 3667 (BCP 78) and RFC 3668 (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 March 17, 2005.







Sandlund                                                        [Page 5]