From klaus.warnke@acticom.de Wed Jan 6 03:50:05 2010 Return-Path: X-Original-To: rohc@core3.amsl.com Delivered-To: rohc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671393A6874 for ; Wed, 6 Jan 2010 03:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKFgUaux70Co for ; Wed, 6 Jan 2010 03:49:59 -0800 (PST) Received: from mail.acticom-networks.com (mail.acticom-networks.com [87.106.254.214]) by core3.amsl.com (Postfix) with ESMTP id 0F7E23A68ED for ; Wed, 6 Jan 2010 03:49:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.acticom-networks.com (Postfix) with ESMTP id 378B91C00426; Wed, 6 Jan 2010 12:49:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at acticom-networks.com Received: from mail.acticom-networks.com ([127.0.0.1]) by localhost (mail.acticom-networks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsGYYGhN7lDt; Wed, 6 Jan 2010 12:49:32 +0100 (CET) Received: from godfather.bln.acticom.de (mail.oosoft.net [212.99.204.33]) by mail.acticom-networks.com (Postfix) with ESMTP id 3D4F61C00423; Wed, 6 Jan 2010 12:49:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by godfather.bln.acticom.de (Postfix) with ESMTP id D5207F3ADA; Wed, 6 Jan 2010 12:49:30 +0100 (CET) X-Virus-Scanned: amavisd-new at bln.acticom.de Received: from godfather.bln.acticom.de ([127.0.0.1]) by localhost (godfather.bln.acticom.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uG4AMKTUjaM; Wed, 6 Jan 2010 12:49:17 +0100 (CET) Received: from TORNADO.acticom.de (tornado.bln.acticom.de [192.168.33.27]) by godfather.bln.acticom.de (Postfix) with ESMTP id 1E0A1F3AA8; Wed, 6 Jan 2010 12:49:17 +0100 (CET) Date: Wed, 06 Jan 2010 12:49:16 +0100 Message-ID: From: Klaus Warnke To: Anil Maguluri In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.7 Emacs/22.2 (i386-mingw-nt6.0.6002) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "rohc@ietf.org" , "anilmaguluri@gmail.com" Subject: Re: [rohc] CRC correction algorithms in ROHCv2 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 11:50:05 -0000 Hi Anil, > Is CRC Correction algorithms are used in ROHCv2? It is not forbidden, but it is not required. "may attempt corrective or repair measures" But remember: Maybe the CRC value is damaged, not the header... I think, you can not reapir the packet, but you can reapir the context. If you assume, a previous packet was damaged, but the CRC check did not catched the error due to its limited length. Then the context is damaged, but the current packet and CRC is correct. Then you can roll back the last context updated and try again with the current packet. This makes sense, if you receive three subsequent packets with an CRC error. In such case, a context damaged can be assumed. And remember from 4995, 5.3.1.2. 3-bit CRC in Compressed Headers: > Therefore, compressed headers carrying a 3-bit CRC are normally not > suitable to perform context repairs at the decompressor; You can develop a CRC repair mechanism, if you want. It is only important, that the CRC verification succeeds after reapir. > If yes, where did they mentioned the procedures? No, but maybe you use the repair mechanism from 3095? "5.3.2.2.5. Repair of incorrect SN updates" br Klaus At Mon, 21 Dec 2009 14:54:15 +0530, Anil Maguluri wrote: > Hi All, > > Please clarify whether my understanding is right or not. As per my > understanding, there is no need of CRC Correction algorithms in > ROHCv2 because every packet has CRC in ROHCv2. As you know the CRC > Correction algorithms are clearly mentioned in ROHCv1 (RFC 3095). > > But, the RFC 5225 has the below information: > "6.4. Reconstruction and Verification Validation of the IR header > (8-bit CRC) The decompressor MUST always validate the integrity of > the IR header using the 8-bit CRC carried within the IR header. When > the header is validated, the decompressor updates the context with > the information in the IR header. Otherwise, if the IR cannot be > validated, the context MUST NOT be updated and the IR header MUST > NOT be delivered to upper layers. > > Verification of CO headers (3-bit CRC or 7-bit CRC) > The decompressor MUST always verify the decompression of a CO header > using the CRC carried within the compressed header. When the > decompression is verified and successful, the decompressor updates > the context with the information received in the CO header; > otherwise, if the reconstructed header fails the CRC verification, > these updates MUST NOT be performed. > > A packet for which the decompression attempt cannot be verified > using the CRC MUST NOT be delivered to upper layers. > > Decompressor implementations may attempt corrective or repair > measures on CO headers prior to performing the above actions, and > the result of any decompression attempt MUST be verified using the > CRC." > > Please clarify the below queries. > Is CRC Correction algorithms are used in ROHCv2? > If yes, where did they mentioned the procedures? > > Thanks for your support. > > Regards, > Anil Kumar Maguluri From root@core3.amsl.com Wed Jan 13 05:45:02 2010 Return-Path: X-Original-To: rohc@ietf.org Delivered-To: rohc@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BA4783A6837; Wed, 13 Jan 2010 05:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100113134502.BA4783A6837@core3.amsl.com> Date: Wed, 13 Jan 2010 05:45:02 -0800 (PST) Cc: rohc@ietf.org Subject: [rohc] I-D Action:draft-ietf-rohc-rfc4995bis-03.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 13:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Robust Header Compression Working Group of the IETF. Title : The RObust Header Compression (ROHC) Framework Author(s) : K. Sandlund, et al. Filename : draft-ietf-rohc-rfc4995bis-03.txt Pages : 42 Date : 2010-01-13 The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics. The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095. This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on July 17, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rfc4995bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-rohc-rfc4995bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-13053101.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Thu Jan 14 07:14:53 2010 Return-Path: X-Original-To: rohc@ietf.org Delivered-To: rohc@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 1A0093A67DA; Thu, 14 Jan 2010 07:14:52 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100114151453.1A0093A67DA@core3.amsl.com> Date: Thu, 14 Jan 2010 07:14:53 -0800 (PST) Cc: rohc mailing list , rohc chair , Internet Architecture Board , RFC Editor Subject: [rohc] Protocol Action: 'The RObust Header Compression (ROHC) Framework' to Proposed Standard X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 15:14:53 -0000 The IESG has approved the following document: - 'The RObust Header Compression (ROHC) Framework ' as a Proposed Standard This document is the product of the Robust Header Compression Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rfc4995bis-03.txt Technical Summary The document describes the ROHC framework. It obsoletes the old framework document RFC 4995 and includes two important updates. ROHC feedback encoding has been corrected to conform with RFC 3095, the original definition of the ROHC framework, and a new section describing context initialization for profile 0x0000 (uncompressed) has been added. Working Group Summary This document represents a rough consensus of the working group. The mismatch in feedback formats that lead to the creation of this document was discovered during the last call of RFC 5225. Document Quality Implementations of the ROHC protocol specified by this document are in existence. This document contains corrections to the ROHC framework document (RFC 4995) and replaces it in full. This document and its predecessors have received reviews from both implementers and ROHC experts. Personnel Document shepherd is Carl Knutsson and responsible AD Magnus Westerlund.