From mailnull@www1.ietf.org Thu May 1 13:01:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22638 for ; Thu, 1 May 2003 13:01:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41H83g16710 for rohc-archive@odin.ietf.org; Thu, 1 May 2003 13:08:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41H83816707 for ; Thu, 1 May 2003 13:08:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22619 for ; Thu, 1 May 2003 13:01:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BHT1-0003yE-00 for rohc-web-archive@ietf.org; Thu, 01 May 2003 13:03:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BHT0-0003yB-00 for rohc-web-archive@ietf.org; Thu, 01 May 2003 13:03:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41H7L816286; Thu, 1 May 2003 13:07:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41H6c815548 for ; Thu, 1 May 2003 13:06:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22504 for ; Thu, 1 May 2003 13:00:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BHRj-0003x4-00 for rohc@ietf.org; Thu, 01 May 2003 13:02:11 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19BHRd-0003uy-00 for rohc@ietf.org; Thu, 01 May 2003 13:02:05 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 1 May 2003 17:59:42 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F21F@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Yousuf.Saifullah@nokia.com'" , rohc@ietf.org Date: Thu, 1 May 2003 17:59:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [rohc] ROHC-FN and TCP Profile - Version 3 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi Yousuf and others, We've updated our implementation to print out a list of the TCP/IP packet formats. A copy is available at: http://sigcomp.srmr.co.uk/~rjp/ROHC-FN_Version_3.zip Just type "build(n)." where n = 0, 1 or 2 depending on how much information you'd like to be displayed: n = 0: Prints the 'core' packet formats only, excluding any fields compressed using list encoding (such as the TCP options). n = 1: Prints the packet formats in full, including any fields compressed using list encoding. n = 2: Prints all packet formats. If a variable-length compressed field is encountered, the formula for calculating its length is also displayed. The results are saved in the file "output.txt" for later reference. As an example, Packet Format 0 (the simplest one) is as follows: Packet Format 0: discriminator: 00 header_crc: 3 bits master_seq_number: 2 bits tcp_psh_flag: 1 bit tcp_checksum: 16 bits Let me know if you have any suggestions for improvements! Regards, Richard > -----Original Message----- > From: Yousuf.Saifullah@nokia.com [mailto:Yousuf.Saifullah@nokia.com] > Sent: Tuesday, April 29, 2003 9:43 PM > To: Price, Richard; rohc@ietf.org > Subject: RE: [rohc] ROHC-FN and TCP Profile - Version 2 > > > Hi Richard, > I think it would be useful to have the pictorial format generation. > > Thanks, > Yousuf > > -----Original Message----- > From: ext Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Tuesday, April 29, 2003 9:51 AM > To: Saifullah Yousuf (NRC/Dallas); rohc@ietf.org > Subject: RE: [rohc] ROHC-FN and TCP Profile - Version 2 > > > Hi Yousuf, > > Drawing the Version 2 packet formats out pictorially might > be a bit of a challenge, as they're a *lot* more complex > than the Version 1 formats. They're now roughly as > complicated as the packet formats in RFC 3095, so the > pictorial form plus accompanying text will be around 100 > pages long - a non-trivial amount of effort to generate > by hand ;-) > > A possible solution would be to modify our implementation > so that it can automatically convert a ROHC-FN description > of the packet formats into a pictorial one. If you think > this feature would be useful, let me know so that we can > add it to the next version of the implementation. > > Regards, > > Richard > > > -----Original Message----- > > From: Yousuf.Saifullah@nokia.com [mailto:Yousuf.Saifullah@nokia.com] > > Sent: Friday, April 25, 2003 6:07 PM > > To: Price, Richard; rohc@ietf.org > > Subject: RE: [rohc] ROHC-FN and TCP Profile - Version 2 > > > > > > Hi Richard, > > Could you please share the version 2 for the TCP compression > > profile in the pictorial form with textual description > > (basically, in the I-D format). Something similar you did for > > the previous version. > > > > Thanks, > > Yousuf > > > > -----Original Message----- > > From: ext Price, Richard [mailto:richard.price@roke.co.uk] > > Sent: Wednesday, April 23, 2003 6:49 AM > > To: 'rohc@ietf.org' > > Subject: [rohc] ROHC-FN and TCP Profile - Version 2 > > > > > > Hi, > > > > Now that Easter's out of the way, it might be a good > > time to restart the discussion on ROHC-FN and the TCP > > compression profile. In the interests of getting the > > discussion going, here's a link to Version 2 of our > > implementation: > > > > http://sigcomp.srmr.co.uk/~rjp/ROHC-FN_Version_2.zip > > > > For the updated implementation we've added all of the > > encoding methods not supported in Version 1, including > > Huffman-based discriminator encoding (i.e. EPIC-lite) > > as well as "list" encoding for the TCP options and > > the IP extension headers. We've also added support for > > real IR packets with the correct indicator bits. > > > > The TCP packet formats have been updated to take > > advantage of the new encoding methods - we can now > > compress various TCP options using list encoding, and > > have a single discriminator for the header as a whole. > > Minimum compressed header size is now 3 bytes. > > > > One other issue - the updated implementation is > > written in a different language from the original > > (namely Prolog rather than Haskell). We're still > > working on the Haskell code, but we're turning it into > > a "proper" implementation (with full debugging and a > > nice user interface). > > > > A suitable Prolog interpreter can be downloaded from: > > > > http://www.swi-prolog.org/download.html > > > > For simplicity, the implementation is provided as a > > single Prolog source file. Just open it and type > > "comp_list(tcp_test_n)." where n is the TCP test flow > > to be compressed. > > > > Regards, > > > > Richard > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu May 8 03:42:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14943 for ; Thu, 8 May 2003 03:42:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h487q0T17246 for rohc-archive@odin.ietf.org; Thu, 8 May 2003 03:52:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h487px817240 for ; Thu, 8 May 2003 03:51:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14940 for ; Thu, 8 May 2003 03:42:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dg4Z-0000oV-00 for rohc-web-archive@ietf.org; Thu, 08 May 2003 03:44:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Dg4Y-0000oR-00 for rohc-web-archive@ietf.org; Thu, 08 May 2003 03:44:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h487pS817226; Thu, 8 May 2003 03:51:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h485A3828090 for ; Thu, 8 May 2003 01:10:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00602 for ; Thu, 8 May 2003 01:00:15 -0400 (EDT) From: sha@cgmaersk.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DdXu-0007j5-00 for rohc@ietf.org; Thu, 08 May 2003 01:02:18 -0400 Received: from mail.cgmaersk.com ([202.154.160.52] helo=cgmaersk.com) by ietf-mx with esmtp (Exim 4.12) id 19DdXt-0007j2-00 for rohc@ietf.org; Thu, 08 May 2003 01:02:18 -0400 To: rohc@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 8 May 2003 10:34:01 +0530 X-MIMETrack: Serialize by Router on CGMLOT03/CGMAERSK(Release 5.0.9a |January 7, 2002) at 05/08/2003 10:24:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [rohc] Ip routing in rohc.. Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi all. In the ROHC the headers are compressed and the ip address is not in the compressed headers as far as i know. Since the header doesnt have any info about the ip address, how the packets are routed. Thanks in advance.. Brgds Shanmugasundaram.M CGM ********************************************************************************** Confidentiality Information & Notice: Information contained and transmitted in this E-MAIL and its attachment(s) is proprietary to CG Maersk Technologies and is for the sole use of the intended recipient(s) and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any use, distribution, transmission, forwarding, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this email in error, please delete this email and inform us at emailerror@cgmaersk.com. ********************************************************************************** _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Thu May 8 04:39:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16029 for ; Thu, 8 May 2003 04:39:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h488mSV22008 for rohc-archive@odin.ietf.org; Thu, 8 May 2003 04:48:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h488mS822005 for ; Thu, 8 May 2003 04:48:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16007 for ; Thu, 8 May 2003 04:38:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DgxD-00019h-00 for rohc-web-archive@ietf.org; Thu, 08 May 2003 04:40:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DgxC-00019e-00 for rohc-web-archive@ietf.org; Thu, 08 May 2003 04:40:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h488m3821971; Thu, 8 May 2003 04:48:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h488k0821854 for ; Thu, 8 May 2003 04:46:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15965 for ; Thu, 8 May 2003 04:36:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dgup-00018I-00 for rohc@ietf.org; Thu, 08 May 2003 04:38:11 -0400 Received: from w1312.hostcentric.net ([66.40.206.254]) by ietf-mx with smtp (Exim 4.12) id 19Dguo-00018F-00 for rohc@ietf.org; Thu, 08 May 2003 04:38:10 -0400 Received: (qmail 2550 invoked by alias); 8 May 2003 08:39:01 -0000 Received: from unknown (HELO cs.arizona.edu) (202.9.179.70) by 0 with SMTP; 8 May 2003 08:39:01 -0000 Message-ID: <3EBA1799.1020503@cs.arizona.edu> Date: Thu, 08 May 2003 14:08:49 +0530 From: Kausik Sinnaswamy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: sha@cgmaersk.com CC: rohc@ietf.org Subject: Re: [rohc] Ip routing in rohc.. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi ROHC compression/decompression is done on a per-hop basis. So ROHC packets will be compressed at post-routing stage and decompressed at pre-routing stage. When I say post-routing, I mean that the next hop has been detected from the forwarding table and pre-routing means as soon as the packet gets off the wire. Cheers Kausik sha@cgmaersk.com wrote: >Hi all. > In the ROHC the headers are compressed and the ip address is not in >the compressed headers as far as i know. Since the header doesnt have any >info about the ip address, how the packets are routed. Thanks in advance.. >Brgds >Shanmugasundaram.M >CGM > > > >********************************************************************************** >Confidentiality Information & Notice: > >Information contained and transmitted in this E-MAIL and its attachment(s) >is proprietary to CG Maersk Technologies and is for the sole use of the >intended recipient(s) and may contain information that is privileged, >confidential or exempt from disclosure under applicable law. If you are not >the intended recipient, you are notified that any use, distribution, >transmission, forwarding, printing, copying or dissemination of this >information in any way or in any manner is strictly prohibited. If you have >received this email in error, please delete this email and inform us at >emailerror@cgmaersk.com. >********************************************************************************** > > >_______________________________________________ >Rohc mailing list >Rohc@ietf.org >https://www1.ietf.org/mailman/listinfo/rohc > > _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri May 9 06:18:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11488 for ; Fri, 9 May 2003 06:18:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49AS5D24057 for rohc-archive@odin.ietf.org; Fri, 9 May 2003 06:28:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49AS4824054 for ; Fri, 9 May 2003 06:28:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11476 for ; Fri, 9 May 2003 06:17:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19E4yc-0003IQ-00 for rohc-web-archive@ietf.org; Fri, 09 May 2003 06:19:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19E4yc-0003IM-00 for rohc-web-archive@ietf.org; Fri, 09 May 2003 06:19:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49ARM824008; Fri, 9 May 2003 06:27:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49AQP823961 for ; Fri, 9 May 2003 06:26:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11426 for ; Fri, 9 May 2003 06:16:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19E4x1-0003HN-00 for rohc@ietf.org; Fri, 09 May 2003 06:18:03 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19E4x0-0003HH-00 for rohc@ietf.org; Fri, 09 May 2003 06:18:02 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 9 May 2003 11:18:26 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F22B@rsys002a.roke.co.uk> From: "Price, Richard" To: "'william zheng'" Cc: "'rohc@ietf.org'" Subject: RE: [rohc] ROHC-FN and TCP Profile - Version 3 Date: Fri, 9 May 2003 11:18:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31614.539A5A8C" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C31614.539A5A8C Content-Type: text/plain; charset="iso-8859-1" Hi William, The FIELD(n) encoding method takes the next n bits from the uncompressed header and stores them in a temporary variable called Field_Value. The NEXT_FIELD encoding method works in a similar manner, but rather than taking the bits from the uncompressed header, it takes them from a labelled field instead. As you spotted in the TCP/IP profile, it's possible to encounter an instance of NEXT_FIELD immediately followed by an instance of FIELD(n). In this case the NEXT_FIELD encoding method is considered to "win" - i.e. the Field_Value is taken from the labelled field rather than from the uncompressed header. We can see that this is the case from the following pseudocode, taken from the definition of FIELD(n): If Field_Value == Null then set Field_Value:= F and set Remaining_Data := Remaining_Data - n. So, the FIELD(n) encoding method must first check whether the Field_Value temporary variable already contains a field value or not. If it doesn't then the next n bits are extracted from the uncompressed header as expected. However, if the NEXT_FIELD encoding method has been used previously, then Field_Value will already be set and the FIELD(n) encoding method will be ignored. This behaviour is a little clumsy, so why do we need it? The benefit is that we can compress labelled fields using ordinary encoding methods such as STATIC and IRREGULAR, e.g: next_field(order)++ static // irregular(24)++ next_field(presence)++ static // irregular(8). As you pointed out, the STATIC and IRREGULAR encoding methods both call an instance of FIELD(n) to extract some bits from the uncompressed header. Using the NEXT_FIELD encoding method we can "override" this default behaviour and force them to compress a labelled field instead. If you can think of a neater way of doing this then please let me know ;-) Regards, Richard -----Original Message----- From: william zheng [mailto:zheng_william@hotmail.com] Sent: Friday, May 09, 2003 3:40 AM To: Price, Richard Subject: Re: [rohc] ROHC-FN and TCP Profile - Version 3 Hi, Richard, I am confused on the definition of FIELD and NEXT_FIELD. According to ROHC-FN draft, FIELD encoding method extracts an n-bit field from the uncompressed packet and stores it in a temporary variable. It means this encoding method operates on the header rather than any label or temporary varialbe. NEXT_FIELD instead operates on labeled field. See the example where NEXT_FIELD is used as follows. tcp_options --> list(data_offset,1,32,-160, [optional(tcp_sack), optional(tcp_timestamp), optional(tcp_end), optional(tcp_no_operation), optional(tcp_no_operation), optional(tcp_generic), optional(tcp_generic), optional(tcp_generic)])++ next_field(order)++ static // irregular(24)++ next_field(presence)++ static // irregular(8). The encoding method that follows the next_field is either STATIC or IRREGULAR, both further using FIELD encoding method via RANGE. It seems quite difficult to understand we can use FIELD encoding method when a labeled field is expected to be encoded/decoded. Consider that following next_field(order)++ we expect to add the labeled field 'order' to the compressed header, but when we use static or irregular(24), we point to the uncompressed header and try to shift the 'remaining_data'. But this is not the action we want to take, is it right? Thanks. RGDS, William _____ The new MSN 8: smart spam protection and 2 months FREE* ------_=_NextPart_001_01C31614.539A5A8C Content-Type: text/html; charset="iso-8859-1"
Hi William,
 
The FIELD(n) encoding method takes the next n bits from the
uncompressed header and stores them in a temporary variable
called Field_Value.  The NEXT_FIELD encoding method works
in a similar manner, but rather than taking the bits from the
uncompressed header, it takes them from a labelled field instead.
 
As you spotted in the TCP/IP profile, it's possible to encounter
an instance of NEXT_FIELD immediately followed by an instance
of FIELD(n).  In this case the NEXT_FIELD encoding method is
considered to "win" - i.e. the Field_Value is taken from the
labelled field rather than from the uncompressed header.  We
can see that this is the case from the following pseudocode, taken
from the definition of FIELD(n):
 
   If Field_Value == Null then set Field_Value:= F and set 
   Remaining_Data := Remaining_Data - n.
So, the FIELD(n) encoding method must first check whether
the Field_Value temporary variable already contains a field value
or not.  If it doesn't then the next n bits are extracted from the
uncompressed header as expected.  However, if the NEXT_FIELD
encoding method has been used previously, then Field_Value
will already be set and the FIELD(n) encoding method will be
ignored.
 
This behaviour is a little clumsy, so why do we need it?  The
benefit is that we can compress labelled fields using ordinary
encoding methods such as STATIC and IRREGULAR, e.g:
 
                            next_field(order)++
                            static // irregular(24)++
                            next_field(presence)++
                            static // irregular(8).
 
As you pointed out, the STATIC and IRREGULAR encoding
methods both call an instance of FIELD(n) to extract some
bits from the uncompressed header.  Using the NEXT_FIELD
encoding method we can "override" this default behaviour and
force them to compress a labelled field instead.
 
If you can think of a neater way of doing this then please let
me know ;-)
 
Regards,
 
Richard
-----Original Message-----
From: william zheng [mailto:zheng_william@hotmail.com]
Sent: Friday, May 09, 2003 3:40 AM
To: Price, Richard
Subject: Re: [rohc] ROHC-FN and TCP Profile - Version 3

Hi, Richard,

I am confused on the definition of FIELD and NEXT_FIELD.

According to ROHC-FN draft, FIELD encoding method extracts an n-bit field from the uncompressed packet and stores it in a temporary variable. It means this encoding method operates on the header rather than any label or temporary varialbe. NEXT_FIELD instead operates on labeled field. See the example where NEXT_FIELD is used as follows. 

tcp_options           -->   list(data_offset,1,32,-160,
                             [optional(tcp_sack),
                              optional(tcp_timestamp),
                              optional(tcp_end),
                              optional(tcp_no_operation),
                              optional(tcp_no_operation),
                              optional(tcp_generic),
                              optional(tcp_generic),
                              optional(tcp_generic)])++
                            next_field(order)++
                            static // irregular(24)++
                            next_field(presence)++
                            static // irregular(8).

The encoding method that follows the next_field is either STATIC or IRREGULAR, both further using FIELD encoding method via RANGE. It seems quite difficult to understand we can use FIELD encoding method when a labeled field is expected to be encoded/decoded. Consider that following next_field(order)++ we expect to add the labeled field 'order' to the compressed header, but when we use static or irregular(24), we point to the uncompressed header and try to shift the 'remaining_data'. But this is not the action we want to take, is it right?

Thanks.

RGDS,

William 


The new MSN 8: smart spam protection and 2 months FREE*
------_=_NextPart_001_01C31614.539A5A8C-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Wed May 14 18:16:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08762 for ; Wed, 14 May 2003 18:16:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4ELgus22488 for rohc-archive@odin.ietf.org; Wed, 14 May 2003 17:42:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ELguB22484 for ; Wed, 14 May 2003 17:42:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08739 for ; Wed, 14 May 2003 18:15:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G4Z8-0001vA-00 for rohc-web-archive@ietf.org; Wed, 14 May 2003 18:17:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19G4Z8-0001v6-00 for rohc-web-archive@ietf.org; Wed, 14 May 2003 18:17:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ELgOB22460; Wed, 14 May 2003 17:42:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ELfNB22432 for ; Wed, 14 May 2003 17:41:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08593 for ; Wed, 14 May 2003 18:14:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19G4Xe-0001v2-00 for rohc@ietf.org; Wed, 14 May 2003 18:16:06 -0400 Received: from alanke.lnk.telstra.net ([139.130.140.14] helo=dog.topology.org) by ietf-mx with esmtp (Exim 4.12) id 19G4Xc-0001uo-00 for rohc@ietf.org; Wed, 14 May 2003 18:16:05 -0400 Received: by dog.topology.org (Postfix, from userid 1321) id D5FE98A6AF; Thu, 15 May 2003 07:46:36 +0930 (CST) Date: Thu, 15 May 2003 07:46:36 +0930 From: Alan Kennington To: ROHC mailing list Message-ID: <20030515074636.A3493@dog.topology.org> Reply-To: Alan Kennington Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i X-PGP-Key: http://www.topology.org/ak/key_ak2.asc X-PGP-Key-Fingerprint: 8A7B 7A8E 1C02 8298 579F 1860 7D56 121B D363 329E Subject: [rohc] linux constant IP ID field can't be compressed in profile 0x0001? Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Is there an obvious way to solve the problem of the constant value of the IP header Identifier field for UDP/IP from linux boxes? As I read it, RFC 3095, 5.7, p.75, says that the difference of the IP-ID minus the RTP is encoded with p = 0, which means that the _difference_ may be constant or slowly increasing. Therefore as I understand it, an IP ID field which is always equal to zero is incompressible. Can this be right? If so, this is a black mark against linux. Cheers, Alan Kennington. -------------------------------------------------------------------- name: Dr. Alan Kennington city: Adelaide, South Australia coords: 34.88051 S, 138.59334 E timezone: UTC+0930 http://topology.org/timezone.html company: Topoz Pty Ltd website: http://topoz.net/ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri May 30 07:20:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28817 for ; Fri, 30 May 2003 07:20:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UBJod25057 for rohc-archive@odin.ietf.org; Fri, 30 May 2003 07:19:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UBJnB25054 for ; Fri, 30 May 2003 07:19:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28777 for ; Fri, 30 May 2003 07:19:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lhtg-00029P-00 for rohc-web-archive@ietf.org; Fri, 30 May 2003 07:18:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Lhtg-00029L-00 for rohc-web-archive@ietf.org; Fri, 30 May 2003 07:18:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UBJPB24980; Fri, 30 May 2003 07:19:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UBEJB24783 for ; Fri, 30 May 2003 07:14:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28233; Fri, 30 May 2003 07:14:16 -0400 (EDT) Message-Id: <200305301114.HAA28233@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 30 May 2003 07:14:16 -0400 Subject: [rohc] I-D ACTION:draft-price-rohc-tcp-packet-formats-00.txt Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : TCP/IP Compressed Packet Formats Author(s) : R. Price, M. West Filename : draft-price-rohc-tcp-packet-formats-00.txt Pages : 0 Date : 2003-5-29 This document proposes a set of compressed packet formats for the ROHC-TCP compression profile [ROHC-TCP]. The ROHC-TCP profile is a robust header compression scheme for TCP/IP that provides improved compression efficiency and enhanced capabilities for compression of various header fields including TCP options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-price-rohc-tcp-packet-formats-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-price-rohc-tcp-packet-formats-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-price-rohc-tcp-packet-formats-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-29162206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-price-rohc-tcp-packet-formats-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-price-rohc-tcp-packet-formats-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-29162206.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri May 30 07:33:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29328 for ; Fri, 30 May 2003 07:33:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UBXIo25610 for rohc-archive@odin.ietf.org; Fri, 30 May 2003 07:33:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UBXIB25607 for ; Fri, 30 May 2003 07:33:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29317 for ; Fri, 30 May 2003 07:33:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Li6j-0002Fe-00 for rohc-web-archive@ietf.org; Fri, 30 May 2003 07:31:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Li6i-0002Fa-00 for rohc-web-archive@ietf.org; Fri, 30 May 2003 07:31:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UBX5B25595; Fri, 30 May 2003 07:33:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UBWeB25574 for ; Fri, 30 May 2003 07:32:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29301 for ; Fri, 30 May 2003 07:32:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Li66-0002F9-00 for rohc@ietf.org; Fri, 30 May 2003 07:30:58 -0400 Received: from rsys002a.roke.co.uk ([193.118.192.251]) by ietf-mx with esmtp (Exim 4.12) id 19Li65-0002Ex-00 for rohc@ietf.org; Fri, 30 May 2003 07:30:58 -0400 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Fri, 30 May 2003 12:32:06 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F26A@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Ghyslain Pelletier'" , "Hongbin Liao (Intl Staffing)" , "Qian Zhang (MSR)" , "Lars-Erik Jonsson (EAB)" , "West, Mark" , Carsten Bormann Cc: rohc@ietf.org Subject: RE: [rohc] I-D ACTION:draft-price-rohc-tcp-packet-formats-00.txt Date: Fri, 30 May 2003 12:32:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Hi, The draft that's just been published contains a proposed set of packet formats for ROHC-TCP, and a discussion of why we chose to encode each field as we did. I've included a list of all the open issues I can think of - comments welcome! Regards, Richard > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, May 30, 2003 12:14 PM > Cc: rohc@ietf.org > Subject: [rohc] I-D ACTION:draft-price-rohc-tcp-packet-formats-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : TCP/IP Compressed Packet Formats > Author(s) : R. Price, M. West > Filename : draft-price-rohc-tcp-packet-formats-00.txt > Pages : 0 > Date : 2003-5-29 > > This document proposes a set of compressed packet formats for the > ROHC-TCP compression profile [ROHC-TCP]. The ROHC-TCP profile is a > robust header compression scheme for TCP/IP that provides improved > compression efficiency and enhanced capabilities for compression of > various header fields including TCP options. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-price-rohc-tcp-packet-formats-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-price-rohc-tcp-packet-formats-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-price-rohc-tcp-packet-formats-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From mailnull@www1.ietf.org Fri May 30 15:16:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23695 for ; Fri, 30 May 2003 15:16:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UJFt029875 for rohc-archive@odin.ietf.org; Fri, 30 May 2003 15:15:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJFtB29872 for ; Fri, 30 May 2003 15:15:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23639 for ; Fri, 30 May 2003 15:15:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LpKP-0000LN-00 for rohc-web-archive@ietf.org; Fri, 30 May 2003 15:14:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LpKO-0000LK-00 for rohc-web-archive@ietf.org; Fri, 30 May 2003 15:14:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJFZB29849; Fri, 30 May 2003 15:15:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJE1B29782 for ; Fri, 30 May 2003 15:14:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23455 for ; Fri, 30 May 2003 15:14:00 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LpIa-0000Kk-00 for rohc@ietf.org; Fri, 30 May 2003 15:12:20 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19LpIZ-0000Kh-00 for rohc@ietf.org; Fri, 30 May 2003 15:12:19 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UJDsb08905 for ; Fri, 30 May 2003 14:13:59 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 May 2003 14:13:51 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 30 May 2003 14:13:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] linux constant IP ID field can't be compressed in profile 0x0001? Date: Fri, 30 May 2003 14:13:47 -0500 Message-ID: Thread-Topic: [rohc] linux constant IP ID field can't be compressed in profile 0x0001? Thread-Index: AcMlK2/Fs/Hw8rbMQPmjxfArLs99lABmmaQg To: , , X-OriginalArrivalTime: 30 May 2003 19:13:48.0697 (UTC) FILETIME=[993CD890:01C326DF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UJE1B29783 Sender: rohc-admin@ietf.org Errors-To: rohc-admin@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Robust Header Compression List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > Since the IP ID field being constant is clearly a pattern, it seems > reasonable to demand that this pattern should be detected in the normal > way patterns are detected. Thus, even if the existing WLSB encoding doesn't > compress the constantly zero field very well, the compressor would still > be able to send type 0 headers and the decompressor should be able do > decompress them. Also for profile 0x0001. > > I believe Zhigang said this about a year ago, and I don't recall any > protests at that time. Have we since decided to not recognize this pattern? Thanks for pointing this out, Micke. I cannot remember when I said that (probably 2 years ago?) but you're certainly right. In this case, the pattern of (IP-ID - SN) is slope = -1. So, it only takes two headers (successfully decompressed) for the decompressor to detect the pattern. Considering possible packet loss, the compressor only need to send a few (>2) non-type-0 headers. The overhead due to inefficient IP-ID offset encoding only occurs in those headers. In fact, since a few IR packets (carrying the full value of IP-ID) have to be sent at the beginning of a packet flow anyway, there is no additional cost to handle this particular case. BR, Zhigang _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc