RE: [rohc] Short summary of the new ROHCv2 profiles:draft-pelletier-rohc-rohcv2-profiles-00.txt
"Sarkar, Biplab" <bsarkar@starentnetworks.com> Tue, 01 August 2006 11:45 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7sgn-0005Da-Uz; Tue, 01 Aug 2006 07:45:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7sgm-0005DU-8e for rohc@ietf.org; Tue, 01 Aug 2006 07:45:32 -0400
Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7sgk-0004nJ-OF for rohc@ietf.org; Tue, 01 Aug 2006 07:45:32 -0400
Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 44BFC90022; Tue, 1 Aug 2006 07:45:27 -0400 (EDT)
Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25325-09; Tue, 1 Aug 2006 07:45:22 -0400 (EDT)
Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP; Tue, 1 Aug 2006 07:45:22 -0400 (EDT)
X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.]
Received: from exchindia3.starentnetworks.com ([10.6.0.5]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Aug 2006 07:41:18 -0400
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Content-Class: urn:content-classes:message
Subject: RE: [rohc] Short summary of the new ROHCv2 profiles:draft-pelletier-rohc-rohcv2-profiles-00.txt
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 01 Aug 2006 17:08:19 +0530
Message-ID: <69FADB84C90B1248A7DE59422771FA0C10080C@exchindia3.starentnetworks.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rohc] Short summary of the new ROHCv2 profiles:draft-pelletier-rohc-rohcv2-profiles-00.txt
thread-index: AcaYrnv2JzJnOfhrQiO3MBH3t+TpWQcr5gHQ
From: "Sarkar, Biplab" <bsarkar@starentnetworks.com>
To: "Ghyslain Pelletier (LU/EAB)" <ghyslain.pelletier@ericsson.com>
Importance: normal
Priority: normal
X-OriginalArrivalTime: 01 Aug 2006 11:41:18.0503 (UTC) FILETIME=[673A4370:01C6B55F]
X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 43317e64100dd4d87214c51822b582d1
Cc: rohc@ietf.org, "Lars-Erik Jonsson (LU/EAB)" <lars-erik.jonsson@ericsson.com>
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
Errors-To: rohc-bounces@ietf.org
Ghyslain/All, I have a query. When IR-PD (IR -payload discard) is sent we discard the payload. Any reason why do we go for discarding the payload? Won't this have any adverse effect? When should this packet be used? Thanks, Biplab -----Original Message----- From: Ghyslain Pelletier (LU/EAB) [mailto:ghyslain.pelletier@ericsson.com] Sent: Monday, June 26, 2006 4:54 AM To: rohc@ietf.org Cc: Ghyslain Pelletier (LU/EAB); Lars-Erik Jonsson (LU/EAB) Subject: [rohc] Short summary of the new ROHCv2 profiles:draft-pelletier-rohc-rohcv2-profiles-00.txt RoHCers, We have submitted a new set of ROHC profiles (ROHCv2), draft-pelletier-rohc-rohcv2-profiles-00.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pelletier-rohc-rohcv2-profiles-00.txt One of the objectives of these new profile definitions is to create simpler compression profiles, that handle more flexibly robustness in terms of both out-of-order delivery and consecutive packet losses. The packet formats have been defined using the formal notation for ROHC (ROHC-FN). Below is a summary of the main "features" of draft-pelletier-rohcv2-profiles-00.txt Comments welcome. We would like to have support and re-submit this draft as a working group document after the July meeting. I assume that this draft will be a topic for the RoHC session in Montreal. /Ghyslain and Kristofer o (De)Compression logic ----------------------- In general, most of the logic is inspired from the ROHC-TCP profile. Some changes depart from 3095-logic, especially with respect to how the decompressor is allowed to attempt decompression of packets (i.e. the decompressor state machine). Somewhat stricter rules are also introduced, with respect to CRC-8, CRC-3 and CRC-7. Of interest for comments is the state diagram in section "5.3.1. Decompressor State Machine": CRC-8(IR) or CRC-8(IR-DYN) Validation CRC-8(IR) or CRC-7(CO) or CRC-8(IR) CRC-8(IR) CRC-8(IR-DYN) CRC-7(CO) CRC-3(CO) Failure Validation Validation Verification Verification +--->---+ +-->---->--+ +-->----->--+ +-->---->--+ +-->---->--+ | | | | | | | | | | | v | v | v | v | v +-----------------+ +----------------------+ +-------------------+ | No Context (NC) | | Initial Context (IC) | | Full Context (FC) | +-----------------+ +----------------------+ +-------------------+ ^ | ^ CRC-7(CO) | ^ | | Static Context | | Failure or | | Context Damage | | Damage Detected | | PT not allowed | | Detected | +--<-----<-----<--+ +----<------<----+ +--<-----<-----<--+ Note that the SC state has been replaced with the IC state, for which transitions to and from are now different and more geared towards robustness. See more in 5.3.1. We've also added some mechanisms to improve robustness against out-of-order delivery. For fields that are not LSB encoded, it is based on the definition of the optimistic approachh and the reordering depth that the compressor wants to provide robustness for, and for LSB encoded fields it is based on a new control field that defines a ratio between the robustness to losses and the robusntess to reordering in the interpretation interval of the LSB encoding. More specifically, no reordering, quarter interval, half interval and three quarter interval can be used for the interpretation interval offset. More details on the definition of the packet formats. o Packet formats: ----------------- The packet formats follow the guidelines from draft-ietf-rohc-rfc3095bis-improvements-02.txt. With the following we'd like to provide some additional descriptions of the packet formats. Lots of inspiration has been taken from the ROHC-TCP profile and the compression of all extension headers is 100% identical to that in ROHC-TCP. The packet formats are an inital attempt for this draft and the authors encourage discussion on how these should look in the final version. But since we want to keep things simple, the packet formats have much less optional fields (apart from co_common, which is the "utility" packet) and therefore, it should be easier to both implement and test the specification. Here's a quick description of the packet formats (this applies to all profiles covered in the RoHCv2 draft): PT-0: - pt_0_crc3, MSN-only packet w/ 3-bit CRC (identical to 3095 UO-0) - pt_0_crc7, MSN-only packet w/ 7-bit CRC PT-1: (3-bit CRC) Carries one LSB-coded field other than MSN (either TS or IP-ID) - pt_1_rnd, used for non-sequential IP-ID (UO-1-replacement from 3095) - pt_1_seq_id, used for sequential IP-ID (UO-1-ID-replacement from 3095) - pt_1_seq_ts (only for UDP/RTP and UDP-Lite/RTP profiles) (UO-1-TS-replacement from 3095) PT-2: (7-bit CRC) Carries one LSB-coded field other than MSN (either TS or IP-ID) Also carry the M-bit (only for UDP/RTP and UDP-Lite/RTP profiles) - pt_2_rnd, used for non-sequential IP-ID, (UOR-2-replacement from 3095) - pt_2_seq_id, used for sequential IP-ID (UOR-2-ID-replacement from 3095)) - pt_2_seq_ts (only for UDP/RTP and UDP-Lite/RTP profiles) (UOR-2-TS-replacement from 3095) co_common: (7-bit CRC) - Replacement for 3095 "UOR-2-with-extension-3" - Can carry practically everything from the dynamic chain of innermost IP header and "endpoint headers". Can also carry TOS/TC and TTL/HopLimit of outer IP headers. - We have added an additional CRC3, which covers some of the control fields to avoid the decompressor sending ACKs on packets that contained a bad control field which was not used during the decompression. IR-DYN/IR: - Only small changes compared to v1, but some added control fields and more efficient compression of other fields (such as IP version field) IR-PD (IR packet): - Since 3095 offered too many conbinations of so-called frame stealing packets, we decided to simplify things and redefine the "D-bit" in the IR so that it define a packet where the payload has been explicitly dropped. We now also allow the compression of payload-less packets with the RTP profile, which removes some of the many IR-specific options. -- Ghyslain Pelletier, Dipl. Ing. Wireless IP Optimizations Ericsson Research, Corporate Unit Ericsson AB, Laboratoriegränd 11 Box 920, S-97128 Luleå, SWEDEN Phone : +46 (0) 8 404 29 43 Mobile: +46 (0) 70 264 83 14 Ghyslain.Pelletier at ericsson.com http://www.ericsson.com ----------------------------------- The opinions expressed in this message are my personal opinions. These opinions are not necessarily those of my employer, unless stated otherwise. ----------------------------------- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc
- RE: [rohc] Short summary of the new ROHCv2 profil… Sarkar, Biplab
- RE: [rohc] Short summary of the new ROHCv2profile… Kristofer Sandlund (LU/EAB)