From rohc-bounces@ietf.org Fri Sep 01 03:21:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ3L7-0005Qh-Bn; Fri, 01 Sep 2006 03:21:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ3L5-0005QT-O9 for rohc@ietf.org; Fri, 01 Sep 2006 03:21:19 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ3L2-0008F9-DS for rohc@ietf.org; Fri, 01 Sep 2006 03:21:19 -0400 Received: from Raghavendra (raghavendra.globaledgesoft.com [172.16.2.161]) by gesmail.globaledgesoft.com (Postfix) with SMTP id B20D2252E3B for ; Fri, 1 Sep 2006 12:51:08 +0530 (IST) Message-ID: From: "Raghavendra D P" To: Date: Fri, 1 Sep 2006 12:51:08 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=neXtPaRt_1157095197" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [rohc] dubts X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org ------=neXtPaRt_1157095197 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01C6CDC5.4B7FB5B0" This is a multi-part message in MIME format. ------=_NextPart_000_004F_01C6CDC5.4B7FB5B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi In RFC 3320 section 9.4.9 The returned feedback data is itself = subdivided into a returned feedback item and a list of returned SigComp = parameters. i am very much confused about these items=20 what returned feedback item contains , since sigcomp parameters contain = cycles_per_bit,decompression size state memory size and sigcomp version. end message instruction contains the returned_parametes_location=20 my question is what this location contains whether the address of = sigcomp parameters are returned feedback item , if both are = different(sigcomp parameter and returned feedback item ) my question is why in both format of sigcomp message and also end = instruction=20 we have returned feedback data and retuned_parameters_location . what = is the differnece=20 thanks in advance=20 Raghavendra dp ------=_NextPart_000_004F_01C6CDC5.4B7FB5B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi
In RFC 3320  section 9.4.9 = The returned feedback data is itself subdivided = into a=20 returned feedback item and a list of returned SigComp = parameters.
 
i am very much confused about these = items=20
what returned feedback item contains = , since=20 sigcomp parameters contain cycles_per_bit,decompression size state = memory size=20 and sigcomp version.
 
end message instruction contains the=20 returned_parametes_location
my  question is what this = location=20 contains  whether the address of sigcomp parameters are returned = feedback=20 item , if both are different(sigcomp parameter and returned feedback = item=20 )
 
 
my question is why in both  = format of=20 sigcomp message  and also end instruction
we have returned feedback data and=20 retuned_parameters_location  . what is the differnece
 
 
thanks in advance
 
Raghavendra dp
 
------=_NextPart_000_004F_01C6CDC5.4B7FB5B0-- ------=neXtPaRt_1157095197 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1157095197 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc ------=neXtPaRt_1157095197-- From rohc-bounces@ietf.org Fri Sep 01 06:17:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ65u-0001MR-5i; Fri, 01 Sep 2006 06:17:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ65t-0001Ic-2H for rohc@ietf.org; Fri, 01 Sep 2006 06:17:49 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ65q-0004EV-Dy for rohc@ietf.org; Fri, 01 Sep 2006 06:17:49 -0400 Received: from Raghavendra (raghavendra.globaledgesoft.com [172.16.2.161]) by gesmail.globaledgesoft.com (Postfix) with SMTP id 38D5B252E11 for ; Fri, 1 Sep 2006 15:47:33 +0530 (IST) Message-ID: From: "Raghavendra D P" To: Date: Fri, 1 Sep 2006 15:47:32 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=neXtPaRt_1157105786" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [rohc] doubt how to convert into bytecode X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org ------=neXtPaRt_1157105786 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A2_01C6CDDD.F0404C50" This is a multi-part message in MIME format. ------=_NextPart_000_00A2_01C6CDDD.F0404C50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi please convert into bytecode taking values of operand1 and operand 2 = thing that both containing the values not address ADD ($operand_1, %operand_2)=20 regards Raghavendra=20 ------=_NextPart_000_00A2_01C6CDDD.F0404C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

hi

please convert into bytecode taking values of operand1 = and operand=20 2  thing that both containing  the values not address

ADD ($operand_1, %operand_2) =

regards

Raghavendra=20

------=_NextPart_000_00A2_01C6CDDD.F0404C50-- ------=neXtPaRt_1157105786 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1157105786 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc ------=neXtPaRt_1157105786-- From rohc-bounces@ietf.org Fri Sep 01 09:54:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9TJ-0001Qj-Bf; Fri, 01 Sep 2006 09:54:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJ9TI-0001Qe-Kj for rohc@ietf.org; Fri, 01 Sep 2006 09:54:12 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ9TC-0006Db-5I for rohc@ietf.org; Fri, 01 Sep 2006 09:54:12 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 846C28E0001; Fri, 1 Sep 2006 15:54:03 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 15:54:03 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 15:54:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] ROHC Charter Update Proposal Date: Fri, 1 Sep 2006 15:54:01 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0503659633@esealmw109.eemea.ericsson.se> In-Reply-To: <2BB45D0F-7245-4880-9FAB-595E4DFCDF24@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] ROHC Charter Update Proposal thread-index: AcbNy/xxDOQ7F+IcTMah+9uFIXEcVAAANunA From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Carsten Bormann" , "Magnus Westerlund \(KI/EAB\)" X-OriginalArrivalTime: 01 Sep 2006 13:54:02.0332 (UTC) FILETIME=[14D861C0:01C6CDCE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org > On Aug 31 2006, at 19:24, Magnus Westerlund wrote: >=20 >> consensus in the WG that this is not needed for the HC over IPsec >> solution >=20 > (It's hard to read this, but I believe "this" =3D adopting legacy > schemes in the ROHC framework.) ...through encapsulation profile(s). Yes, that is what "this" means. =20 > I don't think we have that consensus. > (Clearly, I believe that "this" is the right way to do HCoIPsec, and > Ghyslain does not believe that "this" is the right way to do > HCoIPsec.)=20 >=20 > Obviously, by keeping this question in limbo, the question will > become moot: The legacy folks will go ahead and do their own > HCoIPsec, maybe even before we (ROHC) have stopped discussing. >=20 > Gruesse, Carsten Well, my take is that not doing "this" now does not close the door for doing it later on, when there is real interest and arguments for doing it, as well as people interested in doing it. I any case, I believe we have consensus not do provide support for non-ROHC compression by other means than possibly through the encapsulation approach. We can therefore do the rest of the HCoIPsec work without being dependent on a decision on this specific matter. Right? I really want to get the work with these three drafts going: Jan 2007 RObust Header Compression Protocol Number Registration submitted to IESG for publication as Proposed Standard =20 Mar 2007 IKE/IPsec extensions for HC-session Parameter Negotiation submitted to IESG for publication as Proposed Standard =20 Mar 2007 Header Compression over IPsec (HCoIPsec) submitted to IESG for publication as Informational=20 /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Sep 01 10:35:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJA7V-0002Oy-Rv; Fri, 01 Sep 2006 10:35:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJA7V-0002Ot-12 for rohc@ietf.org; Fri, 01 Sep 2006 10:35:45 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJA7N-0008OG-8I for rohc@ietf.org; Fri, 01 Sep 2006 10:35:45 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 689234F00C9; Fri, 1 Sep 2006 16:35:36 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 16:35:35 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 16:35:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] ROHC Charter Update Proposal Date: Fri, 1 Sep 2006 16:35:19 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC05036596A0@esealmw109.eemea.ericsson.se> In-Reply-To: <2BB45D0F-7245-4880-9FAB-595E4DFCDF24@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] ROHC Charter Update Proposal thread-index: AcbNy/xxDOQ7F+IcTMah+9uFIXEcVAABOtMA From: "Ghyslain Pelletier \(LU/EAB\)" To: "Carsten Bormann" , "Magnus Westerlund \(KI/EAB\)" X-OriginalArrivalTime: 01 Sep 2006 14:35:33.0952 (UTC) FILETIME=[E1F76C00:01C6CDD3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Carsten Bormann wrote: > On Aug 31 2006, at 19:24, Magnus Westerlund wrote: >=20 >> consensus in the WG that this is not needed for the HC over IPsec >> solution >=20 > (It's hard to read this, but I believe "this" =3D adopting > legacy schemes in the ROHC framework.) I read "this" as being "this milestone", "not needed" meaning "a possility not yet having consensus, but not a necessity as there might be other alternatives to solve this". > I don't think we have that consensus. > (Clearly, I believe that "this" is the right way to do > HCoIPsec, and Ghyslain does not believe that "this" is the right way > to do HCoIPsec.)=20 My first argument is that there are a number of possible alternatives to "this", i.e. that to adopt legacy schemes in the RoHC framework is one of many that has been proposed as a solution to HC over IPSec. My second argument is that I do not think that we have consensus in this WG about which alternative we should go for (independently of my personal opinion on this topic, a I haven't seen that consensus anyway). My third argument is that making RoHC profiles of legacy HC schemes is going quite far for the sake of only solving HC over IPSec, knowing that this has other impacts to our work and that we would then have to agree how this would be done. I personally don't think that we should treat the specification of legacy HC scheme any different than other work we take into this WG, e.g. a motivation for the work and proper requirements with respect to the level of robustness and efficiency that this WG strives to achieve. In this respect, I fell that RoHC already provides a sufficient compression profile for whatever legacy HC algorithm compresses, so motivation is hardly there. Wrt requirements, this is yet another story I already discussed a little about. Therefore it does not feel comfortable for me to list "this" as a milestone at this point in time. =20 > Obviously, by keeping this question in limbo, the question will > become moot: The legacy folks will go ahead and do their own HCoIPsec, > maybe even before we (ROHC) have stopped discussing. Well, I got aware of this question only since the Montreal meeting. So, instead of leaving it in "limbo", I would rather encourage a discussion on this issue instead. I have yet to see technical arguments motivating doing this. If legacy folk are to go ahead with their own solution before we have this discussion, it means two things: 1) we have so little resources in this WG that we can't discuss this issue, thus even less to adopt legacy schemes in this WG=20 and make them RoHC profiles would we have consensus to do this; 2) there is a strong drive for solving legacy HC over IPSec somewhere else in the IETF I hope that 1) is not the case. I don't believe 2) reflects the situation either. I even believe that the authors of the draft in question have mentionned that RoHCoverIPSec is what the're aiming at, and of particular interest is RoHCv2? I am personally not really keen on jumping into a solution like "this" without discussing it first, just for the sake that others might solve it in a different way. Going further, I actually encourage others to solve legacy HC over IPSec their own way, outside this WG. My opinion is that we should solve RoHCoverIPSec and not do anything wrt to legacy HC, as described why in a previous email I have sent to this WG earlier. Regards, ///Ghyslain _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Sep 01 11:34:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJB2M-0007Eg-Kp; Fri, 01 Sep 2006 11:34:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJB2L-0007EP-RS for rohc@ietf.org; Fri, 01 Sep 2006 11:34:29 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJB2C-0004ne-42 for rohc@ietf.org; Fri, 01 Sep 2006 11:34:29 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6BA3FFD6; Fri, 1 Sep 2006 17:34:17 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 17:34:16 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 17:34:16 +0200 Message-ID: <44F852F9.1040900@ericsson.com> Date: Fri, 01 Sep 2006 17:34:17 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Carsten Bormann Subject: Re: [rohc] ROHC Charter Update Proposal References: <026F8EEDAD2C4342A993203088C1FC0503553AD6@esealmw109.eemea.ericsson.se> <44F71B4C.1080004@ericsson.com> <2BB45D0F-7245-4880-9FAB-595E4DFCDF24@tzi.org> In-Reply-To: <2BB45D0F-7245-4880-9FAB-595E4DFCDF24@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Sep 2006 15:34:16.0809 (UTC) FILETIME=[15C0BD90:01C6CDDC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Carsten Bormann skrev: > On Aug 31 2006, at 19:24, Magnus Westerlund wrote: > >> consensus in the WG that this is not needed for the HC over IPsec >> solution > > (It's hard to read this, but I believe "this" = adopting legacy schemes > in the ROHC framework.) > To clarify, the discussion was around the milestone, not the support of legacy systems. It seems that you need to discuss this further. Please remember that what the WG is tasked with is in the charter text. The milestones are an attempt to provide guidance on the pieces and when they should be finished. It is your task to figure out how to resolve the HC over IPsec solution. It is you that need to come to consensus about what that means exactly. Due to this I think you should continue discussing the solution and that should hopefully enable to determine if you need this milestone or not. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Sep 01 11:48:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJBFP-00063z-Pf; Fri, 01 Sep 2006 11:47:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJBFO-00063l-Cs for rohc@ietf.org; Fri, 01 Sep 2006 11:47:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJ9ym-0007rp-BG for rohc@ietf.org; Fri, 01 Sep 2006 10:26:44 -0400 Received: from mailhost.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GJ9EX-0001uY-56 for rohc@ietf.org; Fri, 01 Sep 2006 09:38:59 -0400 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k81Dcplg009881; Fri, 1 Sep 2006 15:38:52 +0200 (CEST) In-Reply-To: <44F71B4C.1080004@ericsson.com> References: <026F8EEDAD2C4342A993203088C1FC0503553AD6@esealmw109.eemea.ericsson.se> <44F71B4C.1080004@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2BB45D0F-7245-4880-9FAB-595E4DFCDF24@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [rohc] ROHC Charter Update Proposal Date: Fri, 1 Sep 2006 15:38:49 +0200 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.6 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Carsten Bormann , rohc@ietf.org, "Lars-Erik Jonsson \(LU/EAB\)" , "Ghyslain Pelletier \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org On Aug 31 2006, at 19:24, Magnus Westerlund wrote: > consensus in the WG that this is not needed for the HC over IPsec > solution (It's hard to read this, but I believe "this" = adopting legacy schemes in the ROHC framework.) I don't think we have that consensus. (Clearly, I believe that "this" is the right way to do HCoIPsec, and Ghyslain does not believe that "this" is the right way to do HCoIPsec.) Obviously, by keeping this question in limbo, the question will become moot: The legacy folks will go ahead and do their own HCoIPsec, maybe even before we (ROHC) have stopped discussing. Gruesse, Carsten _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Sep 01 13:02:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJCPe-0001xb-Mm; Fri, 01 Sep 2006 13:02:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GJCPd-0001xQ-SJ for rohc@ietf.org; Fri, 01 Sep 2006 13:02:37 -0400 Received: from mclniron01-ext.bah.com ([156.80.1.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GJCPY-0003Ih-KK for rohc@ietf.org; Fri, 01 Sep 2006 13:02:37 -0400 Received: from mclnexbh01.resource.ds.bah.com ([156.80.7.151]) by mclniron01-ext.bah.com with ESMTP; 01 Sep 2006 13:02:32 -0400 x-SBRS: None X-REMOTE-IP: 156.80.7.151 X-IronPort-AV: i="4.08,201,1154923200"; d="scan'208"; a="69842051:sNHT48045456" Received: from MCLNEXVS05.resource.ds.bah.com ([156.80.7.122]) by mclnexbh01.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 13:02:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] ROHC Charter Update Proposal Date: Fri, 1 Sep 2006 13:02:31 -0400 Message-ID: <37BDD2FAF2AEAE459C6C70FDC2892E4E0148AFC0@MCLNEXVS05.resource.ds.bah.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] ROHC Charter Update Proposal Thread-Index: AcbNy/xxDOQ7F+IcTMah+9uFIXEcVAAANunAAAEjUiA= From: "Ertekin Emre" To: "Lars-Erik Jonsson \(LU/EAB\)" , "Carsten Bormann" , "Magnus Westerlund \(KI/EAB\)" X-OriginalArrivalTime: 01 Sep 2006 17:02:32.0219 (UTC) FILETIME=[6A102EB0:01C6CDE8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org > I any case, I believe we have consensus not do provide=20 > support for non-ROHC compression by other means than possibly=20 > through the encapsulation approach. We can therefore do the=20 > rest of the HCoIPsec work without being dependent on a=20 > decision on this specific matter. Right? I guess we can release the IKEv2 draft without resolving the unification/non-unification issue, however, I would like to point out that content of the IKEv2 draft is dependent on the outcome of the issue. For example, as we indicated at the last WG meeting -- what are the set of channel parameters that IKE will negotiate? Should the draft be written such that IKEv2 is extended to negotiate just RoHC channel parameters? Perhaps it should negotiate ECRTP and RoHC channel parameters? The set of HC parameters that IKEv2 negotiates depends on 1) If the two HC algorithms are unified, and 2) (if they are unified), how they are unified. Anyways, we have the IKEv2 draft prepared; we will submit the draft for review. Best Regards, Emre _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Sep 04 01:22:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK6uE-0005rN-KM; Mon, 04 Sep 2006 01:21:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK6uD-0005rI-Q6 for rohc@ietf.org; Mon, 04 Sep 2006 01:21:57 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GK6uA-0002YN-IA for rohc@ietf.org; Mon, 04 Sep 2006 01:21:57 -0400 Received: from Raghavendra (raghavendra.globaledgesoft.com [172.16.2.161]) by gesmail.globaledgesoft.com (Postfix) with SMTP id AE6DC252E2D; Mon, 4 Sep 2006 10:51:42 +0530 (IST) Message-ID: <70FF07BFCC41483FAE7A4F6AB15B1730@globaledgesoft.com> From: "Raghavendra D P" To: "Surtees, Abigail" References: Subject: Re: [rohc] testing sigcomp code Date: Mon, 4 Sep 2006 10:51:42 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=neXtPaRt_1157347278" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 78a8240bd7a9c0d7033035fffd7b84c6 Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org ------=neXtPaRt_1157347278 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01C6D010.1B581790" This is a multi-part message in MIME format. ------=_NextPart_000_0058_01C6D010.1B581790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi In RFC 3320 section 9.4.9 The returned feedback data is itself = subdivided into a returned feedback item and a list of returned SigComp = parameters. =20 i am very much confused about these items=20 what returned feedback item contains , since sigcomp parameters contain = cycles_per_bit,decompression size state memory size and sigcomp version. end message instruction contains the returned_parametes_location=20 my question is what this location contains whether the address of = sigcomp parameters are returned feedback item , if both are = different(sigcomp parameter and returned feedback item ) 1) my question is why in both format of sigcomp message and also end = instruction=20 we have returned feedback data and retuned_parameters_location . what = is the differnece=20 2) Please convert following instruction into bytecode taking values = of operand1 and operand 2 .=20 ADD ($operand_1, %operand_2)=20 thanks in advance=20 Raghavendra dp =20 ----- Original Message -----=20 From: Surtees, Abigail=20 To: Raghavendra D P=20 Sent: Friday, September 01, 2006 9:44 PM Subject: RE: [rohc] testing sigcomp code Hi Raghavendra, =20 When you send a message using SigComp it has to contain at least: * a byte saying it is a SigComp message [0b11111Txx] where T and xx = are defined in section 7 of RFC 3320. * xx indicates either that bytecode is included (usually the case for = the first message) or a state identifier (allowing=20 access to bytecode stored at the remote endpoint) * compressed message (which may have some internal structure, e.g. = the first n bytes may be a dictionary identifier,=20 depending on the bytecode you are using) =20 You can use whatever bytecode you want to use. The user guide = provides examples of how you could express different compression = algorithms in UDVM bytecode. =20 Whatever bytecode you use, your compressor has to match it, so that = the compressed message can be successfully decompressed using the = bytecode. =20 There is/was an assembler available as someone has already mentioned = (you may need to trawl the mailing list archive), but in general, it is = assumed that you can write your own. =20 Best regards, =20 Abbie -------------------------------------------------------------------------= --- From: Raghavendra D P [mailto:raghavendra.dp@globaledgesoft.com]=20 Sent: 01 September 2006 06:16 To: Surtees, Abigail Subject: Re: [rohc] testing sigcomp code hi u mean to say that after formatting the message i will get sigcomp = message, can i use the UDVM bytecode of the userguide directly.=20 how i can see the sigcomp message codes using ethreal capture. =20 how to write UDVM assembler, or it is avalible freely Thanks in advance regards Raghavendra=20 ----- Original Message -----=20 From: Surtees, Abigail=20 To: Raghavendra D P ; rohc@ietf.org=20 Sent: Thursday, August 31, 2006 8:01 PM Subject: RE: [rohc] testing sigcomp code Hi Raghavendra, =20 It is not possible to run the message because it is not a SigComp = message. I assume that this is the output from compressing the SIP = message. You need to provide a full SigComp message (probably beginning = 0xF8, certainly beginning 0b11111xxx) including bytecode for anyone to = be able to decompress a message with their UDVM. See section 7 of RFC = 3320 for the message format. =20 Best regards, =20 Abbie =20 ------------------------------------------------------------------------ From: Raghavendra D P [mailto:raghavendra.dp@globaledgesoft.com] = Sent: 31 August 2006 13:17 To: rohc@ietf.org Subject: [rohc] testing sigcomp code hi i am using deflate algorithm (zlib 1.2..3) for compressing the = sip message and implementing the UDVM algorithm Sip input message given to deflate algorithm is =20 "INVITE sip:bob at biloxi.com SIP/2.0\r\n Via: SIP/2.0/UDP = pc33.atlanta.com;branch=3Dz9hG4bKnashds8;comp=3Dsigcomp\r\n = Max-Forwards: 70\r\n To: Bob \r\n From: Alice = ;tag=3D1928301774 Call-ID: a84b4c76e66710 = CSeq: 314159 INVITE Contact: = Content-Type: application/sdp Content-Length: 142" Then the sigcomp message is = 78f98412156d8fdb4e84301086bd36f11de65381490431112655d435ccd268b7b3f9469ab= 06d8526ae3ebd653dc46cbc9a99fc5fbe99 = a99ff77573fb3d0b4552da081568cea285ca6eb0abb75ee0fa5797b017487f46ef65b55cd= c2d04533a234b8b0793ba16443f191df5 = 1fb28711eba39cd6da28b59f44bb59a273c3a6b35bde1d4cd1492c5dc28a7776f3cdbf279= 496584fea40e176148c7f51786a2df76 = 77f991becb92569e8932489a0c27174ea1554ca3366249cce338213e543bfe4a212411b9c= ee0fbfb4a59b33f44c7ffe63792b9344ef3aeb9356b6d513442496feef46fbae = 1b23735125179f2fe26f74b2fe26f7495abaa9d24367959f4ea5df5277ab32fecd31d8364= f8c2214080 if any one has implemented the UDVM , please run code with above = sigcomp message , whether output is correct or not. thanks in advance Regards Raghavendra=20 --=20 Roke Manor Research Ltd, Romsey, Hampshire, SO51 0ZN, United Kingdom A Siemens company = ------------------------------------------------------------------------ Visit our website at www.roke.co.uk = ------------------------------------------------------------------------ The information contained in this e-mail and any attachments is proprietary to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. = ------------------------------------------------------------------------ ------=_NextPart_000_0058_01C6D010.1B581790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
hi
In RFC 3320  section 9.4.9 = The returned feedback data is itself subdivided = into a=20 returned feedback item and a list of returned SigComp = parameters.
 
i am very much confused about these = items=20
what returned feedback item contains = , since=20 sigcomp parameters contain cycles_per_bit,decompression size state = memory size=20 and sigcomp version.
 
end message instruction contains the=20 returned_parametes_location
my  question is what this = location=20 contains  whether the address of sigcomp parameters are returned = feedback=20 item , if both are different(sigcomp parameter and returned feedback = item=20 )
 
 
1) my question is why in both  = format of=20 sigcomp message  and also end instruction
we have returned feedback data and=20 retuned_parameters_location  . what is the differnece
 
 
 
2)  Please convert following instruction into bytecode  = taking=20 values of operand1 and operand 2 . 

ADD ($operand_1, %operand_2) =

 
thanks in advance
 
Raghavendra dp
 
 
 
 
----- Original Message -----
From:=20 Surtees, Abigail
To: Raghavendra D P
Sent: Friday, September 01, = 2006 9:44=20 PM
Subject: RE: [rohc] testing = sigcomp=20 code

Hi Raghavendra,
 
When you send a message using SigComp it = has to contain=20 at least:
*  a byte saying it is a SigComp message = [0b11111Txx]=20 where T and xx are defined in section 7 of RFC = 3320.
*  xx indicates either that bytecode is = included=20 (usually the case for the first message) or a state identifier = (allowing=20
    =20  access to bytecode stored at the remote = endpoint)
*  compressed message (which may have some = internal=20 structure, e.g. the first n bytes may be a dictionary=20 identifier, 
     depending on the = bytecode you are=20 using)
 
You can use whatever bytecode you want to = use.  The=20 user guide provides examples of how you could express different = compression=20 algorithms in UDVM bytecode.
 
Whatever bytecode you use, your compressor has = to match it,=20 so that the compressed message can be successfully decompressed using = the=20 bytecode.
 
There is/was an assembler available as someone = has already=20 mentioned (you may need to trawl the mailing list archive), but in = general, it=20 is assumed that you can write your own.
 
Best regards,
 
Abbie

From: Raghavendra D P=20 [mailto:raghavendra.dp@globaledgesoft.com]
Sent: 01 = September=20 2006 06:16
To: Surtees, Abigail
Subject: Re: = [rohc]=20 testing sigcomp code

hi
u mean to say that after formatting = the message=20 i will get sigcomp message, can i use the UDVM bytecode of the=20 userguide  directly.
how i can see the sigcomp message = codes using=20 ethreal capture.
 
how to write UDVM assembler, or it = is avalible=20 freely
 
Thanks in advance
regards
Raghavendra 
 
----- Original Message ----- =
From:=20 Surtees, Abigail
To: Raghavendra D P ; rohc@ietf.org
Sent: Thursday, August 31, = 2006 8:01=20 PM
Subject: RE: [rohc] testing = sigcomp=20 code

Hi Raghavendra,
 
It is not possible to run the message = because it is not=20 a SigComp message.  I assume that this is the output = from=20 compressing the SIP message.  You need to provide a full = SigComp=20 message (probably beginning 0xF8, certainly beginning 0b11111xxx)=20 including bytecode for anyone to be able to decompress a message = with=20 their UDVM.  See section 7 of RFC 3320 for the message=20 format.
 
Best regards,
 
Abbie
 

From: Raghavendra D P=20 [mailto:raghavendra.dp@globaledgesoft.com]
Sent: 31 = August=20 2006 13:17
To: rohc@ietf.org
Subject: [rohc] = testing=20 sigcomp code

hi

i am using deflate algorithm (zlib 1.2..3) = for=20 compressing the sip message  and implementing the UDVM=20 algorithm

Sip input message given to deflate = algorithm=20 is 

"INVITE sip:bob at biloxi.com SIP/2.0\r\n = Via:=20 SIP/2.0/UDP = pc33.atlanta.com;branch=3Dz9hG4bKnashds8;comp=3Dsigcomp\r\n=20 Max-Forwards: 70\r\n To: Bob <sip:bob at biloxi.com>\r\n = From:=20 Alice <sip:alice at atlanta.com>;tag=3D1928301774 Call-ID: = a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice at=20 pc33.atlanta.com> Content-Type: application/sdp = Content-Length:=20 142"

Then the sigcomp message=20 = is
78f98412156d8fdb4e84301086bd36f11de65381490431112655d435ccd2= 68b7b3f9469ab06d8526ae3ebd653dc46cbc9a99fc5fbe99

=

a99ff77573fb3d0b4552da081568cea285ca6eb0abb75ee0fa5797b017487f46ef65b5= 5cdc2d04533a234b8b0793ba16443f191df5

=

1fb28711eba39cd6da28b59f44bb59a273c3a6b35bde1d4cd1492c5dc28a7776f3cdbf= 279496584fea40e176148c7f51786a2df76

=

77f991becb92569e8932489a0c27174ea1554ca3366249cce338213e543bfe4a212411= b9cee0fbfb4a59b33f44c7ffe63792b9344ef3aeb9356b6d513442496feef46fbae

=

1b23735125179f2fe26f74b2fe26f7495abaa9d24367959f4ea5df5277ab32fecd31d8= 364f8c2214080

 

if any one has implemented the UDVM , = please run=20 code with above sigcomp message , whether output is correct or=20 not.

thanks in advance

Regards

Raghavendra

=

 

--

Roke Manor Research Ltd, = Romsey,
Hampshire,=20 SO51 0ZN, United Kingdom

A Siemens company

--------------------------------------------------------------------= ----

Visit our website at www.roke.co.uk

--------------------------------------------------------------------= ----

The information contained in = this=20 e-mail and any attachments is
proprietary to Roke Manor Research = Ltd and=20 must not be passed to any
third party without permission. This=20 communication is for information
only and shall not create or = change any=20 contractual relationship.

--------------------------------------------------------------------= ----

------=_NextPart_000_0058_01C6D010.1B581790-- ------=neXtPaRt_1157347278 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1157347278 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc ------=neXtPaRt_1157347278-- From rohc-bounces@ietf.org Mon Sep 04 02:12:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK7gd-0006RD-Ox; Mon, 04 Sep 2006 02:11:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK7gc-0006Qy-DV for rohc@ietf.org; Mon, 04 Sep 2006 02:11:58 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GK7ga-0000pn-Ft for rohc@ietf.org; Mon, 04 Sep 2006 02:11:58 -0400 Received: from Raghavendra (raghavendra.globaledgesoft.com [172.16.2.161]) by gesmail.globaledgesoft.com (Postfix) with SMTP id A23F4252E2D for ; Mon, 4 Sep 2006 11:41:46 +0530 (IST) Message-ID: <916A64FB9BC749DCBD5F6E1DA7F4A4ED@globaledgesoft.com> From: "Raghavendra D P" To: Date: Mon, 4 Sep 2006 11:41:46 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=neXtPaRt_1157350316" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Subject: [rohc] help needed X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org ------=neXtPaRt_1157350316 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C6D017.19E41100" This is a multi-part message in MIME format. ------=_NextPart_000_0062_01C6D017.19E41100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi In the below Sigcomp message=20 f8 indicates it is an sigcomp message, 147 indicates the code len, 4 = =3D320 the desination address of the udvn bytecode to be stored in uDVM = memory, where to where bytecode limits , it is upto 147 length ie (1f a2 81 6 0 = 0 a4 0 0 f 86 7a a4 0 b6 e4 5 a4 0 0 3 0 4 0 5 0 6 0 7 0 8 0 9 0 a 1 b 1 = d 1 f 1 11 2 13 2 17 2 1b 2 1f 3 23 3 2b 3 33 3 3b 4 a0 43 4 a0 53 4 a0 = 63 4 a0 73 5 a0 83 5 a0 a3 5 a0 c3 5 a0 e3 0 a1 2 0 1 0 2 0 3 0 4 1 5 1 = 7 2 9 2 d 3 11 3 19 4 21 4 31 5 a0 41 5 a0 61 6 a0 81 6 a0 c1 7 a1 1 7 = a1 81 8 a2 1 8 a3 1 9 a4 1 9 a6 1 a a8 1 a ac 1 b ) compressed code is - b0 1 b b8 1 c 80 20 1 c 80 30 1 d 80 40 1 d 80 60 = 1 1d 3 22 9f b4 1e 20 a0 65 4 7 0 17 80 40 11 1 30 a0 bf 0 0 a0 c0 a0 c7 = 80 40 29 1 a1 90 a1 ff a0 90 17 50 80 40 11 9 a0 46 13 22 21 1 13 21 1 = 23 16 9f d1 8 10 4 12 50 4 22 1d 51 22 9f d7 6 12 51 1e 20 9f cf 1 5 0 = 1f 2f 8 10 4 12 50 4 26 1d 53 26 f6 6 14 53 e 20 63 14 54 52 23 22 50 52 = 16 9f 9e e a1 36 bb 1 1c 1 a1 35 a2 5a 1c c1 34 a1 38 a2 5a e 2a a4 86 f = 38 4 bf c0 86 a1 40 6 d 38 bf c8 2c 23 2a a1 35 b6 a4 86 a1 40 6 0 fb e5 = 7 df e5 e6 78 f9 6c a 95 fa 65 d8 c1 a 83 30 c 6 e0 3d 4a 9e 40 16 9b b5 = 15 46 71 7b 93 c4 d 26 c8 3a d0 c3 1e 7f a9 4e b1 f5 d6 43 68 e8 e5 ff = 92 fe 53 39 69 20 51 5a e9 87 f8 ed 2b 8d f9 35 ff e1 80 c1 a7 33 a6 e2 = 49 57 84 89 53 65 81 c0 9b c7 d7 63 f4 19 19 90 bb e0 54 6a d f6 7b 14 = b8 1e 3b 7 58 14 b8 d e9 cf 62 2e e0 74 6c 77 3d c3 8c 2 36 b5 37 67 74 = 8e 60 43 85 3d 9 75 ce 3e ad 75 ba b0 2d 90 18 24 bc 34 2b 41 9b 3a bb = bb cb 47 5 c8 c7 98 62 6a 85 12 4e a4 fa f4 3 a 4e 6b c4 =20 please give details from where to where in below ,hex codes indicates Sigcomp message f8 14 74 1f a2 81 6 0 0 a4 0 0 f 86 7a a4 0 b6 e4 5 a4 0 0 3 0 4 0 5 0 6 = 0 7 0 8 0 9 0 a 1 b 1 d 1 f 1 11 2 13 2 17 2 1b 2 1f 3 23 3 2b 3 33 3 3b = 4 a0 43 4 a0 53 4 a0 63 4 a0 73 5 a0 83 5 a0 a3 5 a0 c3 5 a0 e3 0 a1 2 0 = 1 0 2 0 3 0 4 1 5 1 7 2 9 2 d 3 11 3 19 4 21 4 31 5 a0 41 5 a0 61 6 a0 = 81 6 a0 c1 7 a1 1 7 a1 81 8 a2 1 8 a3 1 9 a4 1 9 a6 1 a a8 1 a ac 1 b b0 = 1 b b8 1 c 80 20 1 c 80 30 1 d 80 40 1 d 80 60 1 1d 3 22 9f b4 1e 20 a0 = 65 4 7 0 17 80 40 11 1 30 a0 bf 0 0 a0 c0 a0 c7 80 40 29 1 a1 90 a1 ff = a0 90 17 50 80 40 11 9 a0 46 13 22 21 1 13 21 1 23 16 9f d1 8 10 4 12 50 = 4 22 1d 51 22 9f d7 6 12 51 1e 20 9f cf 1 5 0 1f 2f 8 10 4 12 50 4 26 1d = 53 26 f6 6 14 53 e 20 63 14 54 52 23 22 50 52 16 9f 9e e a1 36 bb 1 1c 1 = a1 35 a2 5a 1c c1 34 a1 38 a2 5a e 2a a4 86 f 38 4 bf c0 86 a1 40 6 d 38 = bf c8 2c 23 2a a1 35 b6 a4 86 a1 40 6 0 fb e5 7 df e5 e6 78 f9 6c a 95 = fa 65 d8 c1 a 83 30 c 6 e0 3d 4a 9e 40 16 9b b5 15 46 71 7b 93 c4 d 26 = c8 3a d0 c3 1e 7f a9 4e b1 f5 d6 43 68 e8 e5 ff 92 fe 53 39 69 20 51 5a = e9 87 f8 ed 2b 8d f9 35 ff e1 80 c1 a7 33 a6 e2 49 57 84 89 53 65 81 c0 = 9b c7 d7 63 f4 19 19 90 bb e0 54 6a d f6 7b 14 b8 1e 3b 7 58 14 b8 d e9 = cf 62 2e e0 74 6c 77 3d c3 8c 2 36 b5 37 67 74 8e 60 43 85 3d 9 75 ce 3e = ad 75 ba b0 2d 90 18 24 bc 34 2b 41 9b 3a bb bb cb 47 5 c8 c7 98 62 6a = 85 12 4e a4 fa f4 3 a 4e 6b c4 thanks in advance regards Raghavendra D P =20 ------=_NextPart_000_0062_01C6D017.19E41100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi
In the below  Sigcomp message =
 
f8 indicates it is an sigcomp message, = 147=20 indicates the code len, 4 =3D320 the desination address of the udvn = bytecode to be=20 stored in uDVM memory,
where to where bytecode limits , it is = upto 147=20 length ie (1f a2 81 6 0 0 a4 0 0 f 86 7a a4 0 b6 e4 5 a4 0 0 3 0 4 0 5 0 = 6 0 7 0=20 8 0 9 0 a 1 b 1 d 1 f 1 11 2 13 2 17 2 1b 2 1f 3 23 3 2b 3 33 3 3b 4 a0 = 43 4 a0=20 53 4 a0 63 4 a0 73 5 a0 83 5 a0 a3 5 a0 c3 5 a0 e3 0 a1 2 0 1 0 2 0 3 0 = 4 1 5 1=20 7 2 9 2 d 3 11 3 19 4 21 4 31 5 a0 41 5 a0 61 6 a0 81 6 a0 c1 7 a1 1 7 = a1 81 8=20 a2 1 8 a3 1 9 a4 1 9 a6 1 a a8 1 a ac 1 b )
 
compressed code is  - b0 1 b b8 1 = c 80 20 1 c=20 80 30 1 d 80 40 1 d 80 60 1 1d 3 22 9f b4 1e 20 a0 65 4 7 0 17 80 40 11 = 1 30 a0=20 bf 0 0 a0 c0 a0 c7 80 40 29 1 a1 90 a1 ff a0 90 17 50 80 40 11 9 a0 46 = 13 22 21=20 1 13 21 1 23 16 9f d1 8 10 4 12 50 4 22 1d 51 22 9f d7 6 12 51 1e 20 9f = cf 1 5 0=20 1f 2f 8 10 4 12 50 4 26 1d 53 26 f6 6 14 53 e 20 63 14 54 52 23 22 50 52 = 16 9f=20 9e e a1 36 bb 1 1c 1 a1 35 a2 5a 1c c1 34 a1 38 a2 5a e 2a a4 86 f 38 4 = bf c0 86=20 a1 40 6 d 38 bf c8 2c 23 2a a1 35 b6 a4 86 a1 40 6 0 fb e5 7 df e5 e6 78 = f9 6c a=20 95 fa 65 d8 c1 a 83 30 c 6 e0 3d 4a 9e 40 16 9b b5 15 46 71 7b 93 c4 d = 26 c8 3a=20 d0 c3 1e 7f a9 4e b1 f5 d6 43 68 e8 e5 ff 92 fe 53 39 69 20 51 5a e9 87 = f8 ed 2b=20 8d f9 35 ff e1 80 c1 a7 33 a6 e2 49 57 84 89 53 65 81 c0 9b c7 d7 63 f4 = 19 19 90=20 bb e0 54 6a d f6 7b 14 b8 1e 3b 7 58 14 b8 d e9 cf 62 2e e0 74 6c 77 3d = c3 8c 2=20 36 b5 37 67 74 8e 60 43 85 3d 9 75 ce 3e ad 75 ba b0 2d 90 18 24 bc 34 = 2b 41 9b=20 3a bb bb cb 47 5 c8 c7 98 62 6a 85 12 4e a4 fa f4 3 a 4e 6b=20 c4

   
 
please give details from where to where = in below=20 ,hex codes indicates
 
 
 
Sigcomp = message
f8 14 74 1f a2 81 6 0 0 a4 0 0 f 86 7a = a4 0 b6 e4 5=20 a4 0 0 3 0 4 0 5 0 6 0 7 0 8 0 9 0 a 1 b 1 d 1 f 1 11 2 13 2 17 2 1b 2 = 1f 3 23 3=20 2b 3 33 3 3b 4 a0 43 4 a0 53 4 a0 63 4 a0 73 5 a0 83 5 a0 a3 5 a0 c3 5 = a0 e3 0=20 a1 2 0 1 0 2 0 3 0 4 1 5 1 7 2 9 2 d 3 11 3 19 4 21 4 31 5 a0 41 5 a0 61 = 6 a0 81=20 6 a0 c1 7 a1 1 7 a1 81 8 a2 1 8 a3 1 9 a4 1 9 a6 1 a a8 1 a ac 1 b b0 1 = b b8 1 c=20 80 20 1 c 80 30 1 d 80 40 1 d 80 60 1 1d 3 22 9f b4 1e 20 a0 65 4 7 0 17 = 80 40=20 11 1 30 a0 bf 0 0 a0 c0 a0 c7 80 40 29 1 a1 90 a1 ff a0 90 17 50 80 40 = 11 9 a0=20 46 13 22 21 1 13 21 1 23 16 9f d1 8 10 4 12 50 4 22 1d 51 22 9f d7 6 12 = 51 1e 20=20 9f cf 1 5 0 1f 2f 8 10 4 12 50 4 26 1d 53 26 f6 6 14 53 e 20 63 14 54 52 = 23 22=20 50 52 16 9f 9e e a1 36 bb 1 1c 1 a1 35 a2 5a 1c c1 34 a1 38 a2 5a e 2a = a4 86 f=20 38 4 bf c0 86 a1 40 6 d 38 bf c8 2c 23 2a a1 35 b6 a4 86 a1 40 6 0 fb e5 = 7 df e5=20 e6 78 f9 6c a 95 fa 65 d8 c1 a 83 30 c 6 e0 3d 4a 9e 40 16 9b b5 15 46 = 71 7b 93=20 c4 d 26 c8 3a d0 c3 1e 7f a9 4e b1 f5 d6 43 68 e8 e5 ff 92 fe 53 39 69 = 20 51 5a=20 e9 87 f8 ed 2b 8d f9 35 ff e1 80 c1 a7 33 a6 e2 49 57 84 89 53 65 81 c0 = 9b c7 d7=20 63 f4 19 19 90 bb e0 54 6a d f6 7b 14 b8 1e 3b 7 58 14 b8 d e9 cf 62 2e = e0 74 6c=20 77 3d c3 8c 2 36 b5 37 67 74 8e 60 43 85 3d 9 75 ce 3e ad 75 ba b0 2d 90 = 18 24=20 bc 34 2b 41 9b 3a bb bb cb 47 5 c8 c7 98 62 6a 85 12 4e a4 fa f4 3 a 4e = 6b=20 c4
 
 
thanks in advance
 
regards
Raghavendra D = P

   =20
------=_NextPart_000_0062_01C6D017.19E41100-- ------=neXtPaRt_1157350316 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1157350316 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc ------=neXtPaRt_1157350316-- From rohc-bounces@ietf.org Mon Sep 04 02:23:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK7rD-0006Uk-TD; Mon, 04 Sep 2006 02:22:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK7rC-0006Tg-K3 for rohc@ietf.org; Mon, 04 Sep 2006 02:22:54 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GK7r3-0002Dj-4q for rohc@ietf.org; Mon, 04 Sep 2006 02:22:54 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 353CF4F0042; Mon, 4 Sep 2006 08:22:36 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Sep 2006 08:22:36 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Sep 2006 08:22:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] ROHC Charter Update Proposal Date: Mon, 4 Sep 2006 08:22:33 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC050365980E@esealmw109.eemea.ericsson.se> In-Reply-To: <37BDD2FAF2AEAE459C6C70FDC2892E4E0148AFC0@MCLNEXVS05.resource.ds.bah.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] ROHC Charter Update Proposal thread-index: AcbNy/xxDOQ7F+IcTMah+9uFIXEcVAAANunAAAEjUiAAhhUeIA== From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Ertekin Emre" , "Carsten Bormann" , "Magnus Westerlund \(KI/EAB\)" X-OriginalArrivalTime: 04 Sep 2006 06:22:35.0509 (UTC) FILETIME=[83147250:01C6CFEA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: rohc@ietf.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org >> I any case, I believe we have consensus not do provide >> support for non-ROHC compression by other means than possibly >> through the encapsulation approach. We can therefore do the >> rest of the HCoIPsec work without being dependent on a >> decision on this specific matter. Right? >=20 > I guess we can release the IKEv2 draft without resolving the > unification/non-unification issue, however, I would like to point out > that content of the IKEv2 draft is dependent on the outcome of the > issue. For example, as we indicated at the last WG meeting -- what > are the set of channel parameters that IKE will negotiate? > Should the draft > be written such that IKEv2 is extended to negotiate just RoHC channel > parameters? Perhaps it should negotiate ECRTP and RoHC channel > parameters? The set of HC parameters that IKEv2 negotiates depends on > 1) If the two HC algorithms are unified, and 2) (if they are > unified), how they are unified.=20 >=20 > Anyways, we have the IKEv2 draft prepared; we will submit the > draft for> review. Excellent. I recommend you to assume ROHC-only for now, as that solution would match both the "no, we will not care about non-ROHC" approach and the "yes, other schemes can be supported through ROHC-encapsulation" approach. Are you updating the HCoIPsec draft as well? BR /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Sep 05 06:30:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKYCb-00058H-Iz; Tue, 05 Sep 2006 06:30:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GKYCa-000588-2r for rohc@ietf.org; Tue, 05 Sep 2006 06:30:44 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GKYCX-0002IC-AZ for rohc@ietf.org; Tue, 05 Sep 2006 06:30:44 -0400 Received: from Raghavendra (raghavendra.globaledgesoft.com [172.16.2.161]) by gesmail.globaledgesoft.com (Postfix) with SMTP id 8E292252E13 for ; Tue, 5 Sep 2006 16:00:31 +0530 (IST) Message-ID: From: "Raghavendra D P" To: Date: Tue, 5 Sep 2006 16:00:30 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=neXtPaRt_1157452240" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: [rohc] code indicates what X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org ------=neXtPaRt_1157452240 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C6D104.69B9DAA0" This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C6D104.69B9DAA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi=20 Sigcomp message got after formatting .=20 f8 14 74 1f a2 81 6 0 0 a4 0 0 f 86 7a a4 0 b6 e4 5 a4 0 0 3 0 4 0 5 0 6 = 0 7 0 8 0 9 0 a 1 b 1 d 1 f 1 11 2 13 2 17 2 1b 2 1f 3 23 3 2b 3 33 3 3b = 4 a0 43 4 a0 53 4 a0 63 4 a0 73 5 a0 83 5 a0 a3 5 a0 c3 5 a0 e3 0 a1 2 0 = 1 0 2 0 3 0 4 1 5 1 7 2 9 2 d 3 11 3 19 4 21 4 31 5 a0 41 5 a0 61 6 a0 = 81 6 a0 c1 7 a1 1 7 a1 81 8 a2 1 8 a3 1 9 a4 1 9 a6 1 a a8 1 a ac 1 b b0 = 1 b b8 1 c 80 20 1 c 80 30 1 d 80 40 1 d 80 60 1 1d 3 22 9f b4 1e 20 a0 = 65 4 7 0 17 80 40 11 1 30 a0 bf 0 0 a0 c0 a0 c7 80 40 29 1 a1 90 a1 ff = a0 90 17 50 80 40 11 9 a0 46 13 22 21 1 13 21 1 23 16 9f d1 8 10 4 12 50 = 4 22 1d 51 22 9f d7 6 12 51 1e 20 9f cf 1 5 0 1f 2f 8 10 4 12 50 4 26 1d = 53 26 f6 6 14 53 e 20 63 14 54 52 23 22 50 52 16 9f 9e e a1 36 bb 1 1c 1 = a1 35 a2 5a 1c c1 34 a1 38 a2 5a e 2a a4 86 f 38 4 bf c0 86 a1 40 6 d 38 = bf c8 2c 23 2a a1 35 b6 a4 86 a1 40 6 0 fb e5 7 df e5 e6 78 f9 6c a 95 = fa 65 d8 c1 a 83 30 c 6 e0 3d 4a 9e 40 16 9b b5 15 46 71 7b 93 c4 d 26 = c8 3a d0 c3 1e 7f a9 4e b1 f5 d6 43 68 e8 e5 ff 92 fe 53 39 69 20 51 5a = e9 87 f8 ed 2b 8d f9 35 ff e1 80 c1 a7 33 a6 e2 49 57 84 89 53 65 81 c0 = 9b c7 d7 63 f4 19 19 90 bb e0 54 6a d f6 7b 14 b8 1e 3b 7 58 14 b8 d e9 = cf 62 2e e0 74 6c 77 3d c3 8c 2 36 b5 37 67 74 8e 60 43 85 3d 9 75 ce 3e = ad 75 ba b0 2d 90 18 24 bc 34 2b 41 9b 3a bb bb cb 47 5 c8 c7 98 62 6a = 85 12 4e a4 fa f4 3 a 4e 6b c4 =20 here=20 f8 indicates that it is sigcomp message 14 74 1f a2 81 6 0 0 a4 0 - what this codes indicates after the first = byte f8 . udvm bytecode starts at 0f86 - it is correct or Not compressed code start at 78 f9 6c a 95 fa ..... please help me in this regard to find out from where to where code = indicates what regards Raghavendra=20 ------=_NextPart_000_0063_01C6D104.69B9DAA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi
 
Sigcomp message got after = formatting .=20
f8 14 74 1f a2 81 6 0 0 a4 0 0 f 86 7a = a4 0 b6 e4 5=20 a4 0 0 3 0 4 0 5 0 6 0 7 0 8 0 9 0 a 1 b 1 d 1 f 1 11 2 13 2 17 2 1b 2 = 1f 3 23 3=20 2b 3 33 3 3b 4 a0 43 4 a0 53 4 a0 63 4 a0 73 5 a0 83 5 a0 a3 5 a0 c3 5 = a0 e3 0=20 a1 2 0 1 0 2 0 3 0 4 1 5 1 7 2 9 2 d 3 11 3 19 4 21 4 31 5 a0 41 5 a0 61 = 6 a0 81=20 6 a0 c1 7 a1 1 7 a1 81 8 a2 1 8 a3 1 9 a4 1 9 a6 1 a a8 1 a ac 1 b b0 1 = b b8 1 c=20 80 20 1 c 80 30 1 d 80 40 1 d 80 60 1 1d 3 22 9f b4 1e 20 a0 65 4 7 0 17 = 80 40=20 11 1 30 a0 bf 0 0 a0 c0 a0 c7 80 40 29 1 a1 90 a1 ff a0 90 17 50 80 40 = 11 9 a0=20 46 13 22 21 1 13 21 1 23 16 9f d1 8 10 4 12 50 4 22 1d 51 22 9f d7 6 12 = 51 1e 20=20 9f cf 1 5 0 1f 2f 8 10 4 12 50 4 26 1d 53 26 f6 6 14 53 e 20 63 14 54 52 = 23 22=20 50 52 16 9f 9e e a1 36 bb 1 1c 1 a1 35 a2 5a 1c c1 34 a1 38 a2 5a e 2a = a4 86 f=20 38 4 bf c0 86 a1 40 6 d 38 bf c8 2c 23 2a a1 35 b6 a4 86 a1 40 6 0 fb e5 = 7 df e5=20 e6 78 f9 6c a 95 fa 65 d8 c1 a 83 30 c 6 e0 3d 4a 9e 40 16 9b b5 15 46 = 71 7b 93=20 c4 d 26 c8 3a d0 c3 1e 7f a9 4e b1 f5 d6 43 68 e8 e5 ff 92 fe 53 39 69 = 20 51 5a=20 e9 87 f8 ed 2b 8d f9 35 ff e1 80 c1 a7 33 a6 e2 49 57 84 89 53 65 81 c0 = 9b c7 d7=20 63 f4 19 19 90 bb e0 54 6a d f6 7b 14 b8 1e 3b 7 58 14 b8 d e9 cf 62 2e = e0 74 6c=20 77 3d c3 8c 2 36 b5 37 67 74 8e 60 43 85 3d 9 75 ce 3e ad 75 ba b0 2d 90 = 18 24=20 bc 34 2b 41 9b 3a bb bb cb 47 5 c8 c7 98 62 6a 85 12 4e a4 fa f4 3 a 4e = 6b=20 c4
 
here
f8 indicates that it is sigcomp message
14 74 1f a2 81 6 0 0 a4 0  - what this codes indicates after = the first=20 byte f8 .
 
udvm bytecode starts at 0f86 - it is correct or Not
 
compressed code start at 78 f9 6c a 95 fa .....
 
please help me in this regard to find out from where to where code = indicates what
 
regards
Raghavendra
 
 
------=_NextPart_000_0063_01C6D104.69B9DAA0-- ------=neXtPaRt_1157452240 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1157452240 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc ------=neXtPaRt_1157452240-- From rohc-bounces@ietf.org Thu Sep 07 10:32:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKvX-0003kO-Uf; Thu, 07 Sep 2006 10:32:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLKvX-0003kJ-F2 for rohc@ietf.org; Thu, 07 Sep 2006 10:32:23 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLKvQ-0005l9-RR for rohc@ietf.org; Thu, 07 Sep 2006 10:32:23 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 087B28E0001 for ; Thu, 7 Sep 2006 16:32:10 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 16:32:09 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Sep 2006 16:32:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Sep 2006 16:32:08 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC05036E2CE3@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Modification to the RFC 3095 corrections and clarifications draft thread-index: AcbSimYXl+iBM10JQ9ShqJ2tjlbBaA== From: "Lars-Erik Jonsson \(LU/EAB\)" To: X-OriginalArrivalTime: 07 Sep 2006 14:32:09.0728 (UTC) FILETIME=[66B7D000:01C6D28A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [rohc] Modification to the RFC 3095 corrections and clarifications draft X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org ROHCers, When reviewing draft-ietf-rohc-rtp-impl-guide-19.txt once more, Ghyslain has questioned the meaning of the content of section 3.3. Although I know both paragraphs were written based on questions from implementer's, I do agree they can now be questioned. The proposal is thus to: 1) Remove the first paragraph, in today's ROHC world it is a well-known fact that modes are profile specific. 2) Make a rewrite of the second paragraph to make it clearer. Proposed text: -------------------------------------------------------------- 3.3. Packet decoding during mode transition The purpose of a mode transition is to ensure that the compressor and the decompressor coherently move from one mode of operation to another using a three-way handshake. At one point during the mode transition, the decompressor acknowledges the reception of one (or more) IR, IR-DYN or UOR-2 packet(s) that have mode bits set to the new mode. Packets of type 0 or 1 that are received up to this point are decompressed using the old mode, while afterwards they are decompressed using the new mode. If the enhanced transition procedures described in section 3.1 of this document are used, the setting of the D_TRANS parameter to P represents this breakpoint. The successful decompression of a packet of type 0 or type 1 completes the mode transition. -------------------------------------------------------------- Any objections? Otherwise I plan to make this adjustment and then submit rev -20 of the draft next week.=20 /L-E ----------------------------------- Lars-Erik Jonsson, M.Sc. Senior Research Engineer Wireless IP Optimizations AWARE - Advanced Wireless Algorithm Research Ericsson Research, Corporate Unit Ericsson AB Box 920, S-971 28 Lule=E5, Sweden E-mail: lars-erik.jonsson@ericsson.com /"\ Phone: +46 8 404 29 61 \ / Fax: +46 920 996 21 ASCII Ribbon Campaign X Home: +46 63 355 24 against HTML email & vCards / \ My opinions are my personal opinions and should not be considered as the opinions of my employer, if not explicitly stated. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Sep 07 18:50:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLShp-0003ES-Gx; Thu, 07 Sep 2006 18:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLShf-00030z-Rl; Thu, 07 Sep 2006 18:50:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLShf-000334-Pa; Thu, 07 Sep 2006 18:50:35 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GLShc-0000DA-PY; Thu, 07 Sep 2006 18:50:35 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 7AD00175D1; Thu, 7 Sep 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GLSh8-00050j-2j; Thu, 07 Sep 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 07 Sep 2006 18:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org --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 : RObust Header Compression Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP and UDP Lite Author(s) : G. Pelletier, K. Sandlund Filename : draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt Pages : 110 Date : 2006-9-7 This document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP (Encapsulating Security Payload) headers. This specification update the profiles defined in RFC 3095, RFC 3843 and RFC 4019 to their second version (RoHCv2 profiles). The profiles herein thus supersede their earlier definition, but they do not obsolete them. The RoHCv2 specification introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Finally, the RoHCv2 profiles define its own specific set of packet formats, using the ROHC formal notation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-rohc-rfc3095bis-rohcv2-profiles-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-ietf-rohc-rfc3095bis-rohcv2-profiles-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: <2006-9-7153629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-7153629.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Fri Sep 08 02:33:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLZvA-0007Kb-SX; Fri, 08 Sep 2006 02:33:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLZv8-0007KW-NA for rohc@ietf.org; Fri, 08 Sep 2006 02:32:58 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLZv6-0007bb-IG for rohc@ietf.org; Fri, 08 Sep 2006 02:32:58 -0400 Received: from Raghavendra (unknown [172.16.2.161]) by gesmail.globaledgesoft.com (Postfix) with SMTP id 33DB7ABAA1 for ; Fri, 8 Sep 2006 06:32:42 +0000 (UTC) Message-ID: From: "Raghavendra D P" To: Date: Fri, 8 Sep 2006 12:02:41 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=neXtPaRt_1157697174" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: [rohc] please clarify this what this code indicates X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org ------=neXtPaRt_1157697174 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01C6D33E.AFB7CFD0" This is a multi-part message in MIME format. ------=_NextPart_000_005D_01C6D33E.AFB7CFD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi=20 this is the deflate decompressor bytecode shown in the user guide of = sigcomp 0x0f86 7aa2 528d 05a2 5200 0300 0400 0500 0600 0700 0800 0900 0a01 = 0x0b01 0d01 0f01 1102 1302 1702 1b02 1f03 2303=20 2b03 3303 3b04 a043 0x04a0 5304 a063 04a0 7305 a083 05a0 a305 a0c3 05a0 = e300 a102=20 0001 0x0002 0003 0004 0105 0107 0209 020d 0311 0319 0421 0431 05a0 4105 = 0xa061 06a0 8106 a0c1 07a1 0107 a181 08a2 0108 a301 09a4 0109 a601 0x0aa8 010a ac01 0bb0 010b b801 0c80 2001 0c80 = 3001 0d80 4001 0d80 0x6001 1d03 229f b41e=20 20a0 6504 0700 1780 4011 0130 a0bf 0000 a0c0 0xa0c7 8040 2901 a190 a1ff = a090 1750 8040 1109 a046 1322 2101 1321 0x0123 169f d108 1004 1250 0422 1d51 229f d706 1251 1e20 9fcf 0105 0x001f 2f08 1004 = 1250 0426 1d53 26f6 0614 530e 2063 1454 5223 2250=20 0x5216 9f9e 2300 00bf c086 a1de 06 please clarify my doubt , what is first 16bit 0x0f86 - i understood = that the 0f indicates bytecode for multiload, but i am not getting next = 8bit has got 86 =20 please ignore me if have lagging the basics Regards Raghavendra dp ------=_NextPart_000_005D_01C6D33E.AFB7CFD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi
this is the deflate decompressor=20 bytecode shown in the user guide of sigcomp
 
0x0f86 7aa2 528d 05a2 5200 0300 0400 = 0500 0600 0700=20 0800 0900 0a01 0x0b01 0d01 0f01 1102 1302 1702 1b02 1f03 2303
2b03 = 3303 3b04=20 a043 0x04a0 5304 a063 04a0 7305 a083 05a0 a305 a0c3 05a0 e300 a102 =
 
0001 0x0002 0003 0004 0105 0107 0209 = 020d 0311 0319=20 0421 0431 05a0 4105 0xa061 06a0 8106 a0c1 07a1 0107 a181 08a2
0108 = a301 09a4=20 0109 a601 0x0aa8 010a ac01 0bb0 010b b801 0c80 2001 0c80 3001 0d80 4001 = 0d80=20 0x6001 1d03 229f b41e
20a0 6504 0700 1780 4011 0130 a0bf 0000 a0c0 = 0xa0c7=20 8040 2901 a190 a1ff a090 1750 8040 1109 a046 1322 2101 1321 0x0123 = 169f
d108=20 1004 1250 0422 1d51 229f d706 1251 1e20 9fcf 0105 0x001f 2f08 1004 1250 = 0426=20 1d53 26f6 0614 530e 2063 1454 5223 2250
0x5216 9f9e 2300 00bf c086 = a1de=20 06
 
 please clarify my doubt ,  = what is first=20 16bit 0x0f86  - i understood that the 0f indicates bytecode = for =20 multiload, but i am not getting next 8bit has got 86   =
 
please ignore me if have lagging the=20 basics
 
 
Regards
Raghavendra dp
 
------=_NextPart_000_005D_01C6D33E.AFB7CFD0-- ------=neXtPaRt_1157697174 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1157697174 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc ------=neXtPaRt_1157697174-- From rohc-bounces@ietf.org Mon Sep 11 08:39:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMl3v-0000F5-QJ; Mon, 11 Sep 2006 08:38:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMl3u-0000Eu-OV for rohc@ietf.org; Mon, 11 Sep 2006 08:38:54 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMl3r-0004nn-35 for rohc@ietf.org; Mon, 11 Sep 2006 08:38:54 -0400 Received: from raghavendra.globaledgesoft.com (unknown [172.16.2.161]) by gesmail.globaledgesoft.com (Postfix) with ESMTP id 3037E252E13 for ; Mon, 11 Sep 2006 12:38:29 +0000 (UTC) From: Raghavendra To: rohc@ietf.org Content-Type: multipart/mixed; boundary="----=neXtPaRt_1157978330" Organization: Message-Id: <1157978308.2186.22.camel@raghavendra.globaledgesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 11 Sep 2006 18:08:28 +0530 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [rohc] please do clarify X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org ------=neXtPaRt_1157978330 Content-Type: text/plain Content-Transfer-Encoding: 7bit hi i am decoding the UDVM bytecode for the DEFLATE compression algorithm given in RFC 4464 -sigComp guide i am not geeting 2nd byte of staring word 0X0f86 0f - indicates the multiload instruction and first operand is 64 see below multiload instruction, but bytecode is showing 86 how MULTILOAD (64, 122, circular_buffer, udvm_memory_size, 5, circular_buffer ,......) Thanks regards ------=neXtPaRt_1157978330 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1157978330 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc ------=neXtPaRt_1157978330-- From rohc-bounces@ietf.org Mon Sep 11 09:02:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMlQJ-0001UT-Un; Mon, 11 Sep 2006 09:02:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GMlQI-0001UO-Pe for rohc@ietf.org; Mon, 11 Sep 2006 09:02:02 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GMlQC-0005uR-2O for rohc@ietf.org; Mon, 11 Sep 2006 09:02:02 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id k8BCnOQ02852 for ; Mon, 11 Sep 2006 13:49:24 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] please do clarify Date: Mon, 11 Sep 2006 14:00:56 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002CED879@svr-exchange.avocado.emccsoft.com> In-Reply-To: <1157978308.2186.22.camel@raghavendra.globaledgesoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] please do clarify Thread-Index: AcbVn8EIJ4/zCxwSTgmHU+Gny0pUkwAAhoKQ From: "John Barber" To: "Raghavendra" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi, 0x86 is the correct encoding of the value 64 for a multitype operand. See figure 10 in the SIGCOMP RFC. 0x86 is 0b10000110 so the operand format is 1000011n with n =3D=3D 0 and the equivalent value is 2 ^ (n + = 6) which is 64. Regards, John=20 > -----Original Message----- > From: Raghavendra [mailto:raghavendra.dp@globaledgesoft.com]=20 > Sent: 11 September 2006 13:38 > To: rohc@ietf.org > Subject: [rohc] please do clarify >=20 >=20 > hi > =20 > i am decoding the UDVM bytecode for the DEFLATE compression=20 > algorithm given in RFC 4464 -sigComp guide >=20 > i am not geeting 2nd byte of staring word 0X0f86 0f -=20 > indicates the multiload instruction=20 >=20 > and first operand is 64 see below multiload instruction, but=20 > bytecode is showing 86 how >=20 >=20 > MULTILOAD (64, 122, circular_buffer, udvm_memory_size, 5, > circular_buffer ,......) > =20 >=20 >=20 > Thanks > regards >=20 >=20 >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Sep 12 05:17:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN4OL-0001AH-N6; Tue, 12 Sep 2006 05:17:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN4OK-0001AC-EW for rohc@ietf.org; Tue, 12 Sep 2006 05:17:16 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN4OG-0007mS-SF for rohc@ietf.org; Tue, 12 Sep 2006 05:17:16 -0400 Received: from raghavendra.globaledgesoft.com (unknown [172.16.2.161]) by gesmail.globaledgesoft.com (Postfix) with ESMTP id 9A38A252E37 for ; Tue, 12 Sep 2006 09:17:04 +0000 (UTC) From: Raghavendra To: rohc@ietf.org Content-Type: multipart/mixed; boundary="----=neXtPaRt_1158052624" Organization: Message-Id: <1158052623.2089.22.camel@raghavendra.globaledgesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 12 Sep 2006 14:47:04 +0530 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [rohc] please clarify it X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org ------=neXtPaRt_1158052624 Content-Type: text/plain Content-Transfer-Encoding: 7bit hi UDVM bytecode for the DEFLATE compression is taken from SigComp user guide, which includes following instruction MULTILOAD (64, 122, circular_buffer, udvm_memory_size, 5, circular_buffer, 0, 3, 0, 4, 0, 5, 0, 6, 0, 7, 0, 8, 0, 9, 0, 10, 1, 11, 1, 13, 1, 15, 1, 17, 2, 19, 2, 23, 2, 27,what indicates 10 lines 2, 31, 3, 35, 3, 43, 3, 51, 3, 59, 4, 67, 4, 83, 4, 99, 4, 115, 5, 131, 5, 163, 5, 195, 5, 227, 0, 258, 0, 1, 0, 2, 0, 3, 0, 4, 1, 5, 1, 7, 2, 9, 2, 13, 3, 17, 3, 25, 4, 33, 4, 49, 5, 65, 5, 97, 6, 129, 6, 193, 7, 257, 7, 385,what indicates 10 lines 8, 513, 8, 769, 9, 1025, 9, 1537, 10, 2049, 10, 3073, 11, 4097, 11, 6145, 12, 8193, 12, 12289, 13, 16385, 13, 24577) i am decoding its corresponding bytecode given in SigComp guide 3, 51, 3, 59, 4, 67, these are the inputs to multiload instruction and its corresponding bytecode is 03 3303 3b04 a043 but 67 it has give 43 but it bytecode contains a043 - how a0 clarify my doubt thanks in advance Regards Raghavendra DP ------=neXtPaRt_1158052624 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1158052624 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc ------=neXtPaRt_1158052624-- From rohc-bounces@ietf.org Tue Sep 12 06:06:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN59O-0001IO-JT; Tue, 12 Sep 2006 06:05:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GN59M-0001HN-MT for rohc@ietf.org; Tue, 12 Sep 2006 06:05:52 -0400 Received: from [203.101.112.21] (helo=mail2.sonimtech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GN59K-00067N-5Z for rohc@ietf.org; Tue, 12 Sep 2006 06:05:52 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] please clarify it X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 12 Sep 2006 15:35:47 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] please clarify it Thread-Index: AcbWTG8F+hnD+NNqRnG2YqbgsDhgvQABOBow From: "Vishal Sudan" To: "Raghavendra" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Raghavendra, As mentioned in rfc3320 section 8.5 To reduce the size of typical UDVM bytecode, each operand for a UDVM instruction is compressed using variable-length encoding. The aim is to store more common operand values using fewer bytes than rarely occurring values. So the given number decimal 67 gets converted into 0xa043 going by =20 Figure 10 in rfc3320 ( which is the one for multitypes, as the given = operand=20 of MULTILOAD is ) The actual applicable row of that being=20 101nnnnn nnnnnnnn N 0 - 8191 Thanks and Regards, Vishal Sudan -----Original Message----- From: Raghavendra [mailto:raghavendra.dp@globaledgesoft.com] Sent: Tuesday, September 12, 2006 2:47 PM To: rohc@ietf.org Subject: [rohc] please clarify it hi UDVM bytecode for the DEFLATE compression is taken from SigComp user guide, which includes following instruction=20 MULTILOAD (64, 122, circular_buffer, udvm_memory_size, 5, circular_buffer, 0, 3, 0, 4, 0, 5, 0, 6, 0, 7, 0, 8, 0, 9, 0, 10, 1, 11, 1, 13, 1, 15, 1, 17, =20 2, 19, 2, 23, 2, 27,what indicates 10 lines=20 2, 31, 3, 35, 3, 43, 3, 51, 3, 59, 4, 67, =20 4, 83, 4, 99, 4, 115, 5, 131, 5, 163, 5, 195, 5, 227, 0, 258, 0, 1, 0, 2, 0, 3, 0, 4, 1, 5, 1, 7, 2, 9, 2, 13, 3, 17, 3, 25, 4, 33, 4, 49, 5, 65, 5, 97, 6, 129, 6, 193, 7, 257, 7, 385,what indicates 10 lines 8, 513, 8, 769, 9, 1025, 9, 1537, 10, 2049, 10, 3073, 11, 4097, 11, 6145, 12, 8193, 12, 12289, 13, 16385, 13, 24577) i am decoding its corresponding bytecode given in SigComp guide=20 3, 51, 3, 59, 4, 67, these are the inputs to multiload instruction and its corresponding bytecode is=20 03 3303 3b04 a043 but 67 it has give 43 but it bytecode contains a043 - how a0 clarify my doubt thanks in advance Regards Raghavendra DP =20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Sep 12 11:45:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNASD-00061c-Co; Tue, 12 Sep 2006 11:45:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNASB-00061R-IP for rohc@ietf.org; Tue, 12 Sep 2006 11:45:39 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNASA-0004RQ-TN for rohc@ietf.org; Tue, 12 Sep 2006 11:45:39 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k8CFjOuG024644 for ; Tue, 12 Sep 2006 16:45:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] Local state advertisements and the implementer's guide Date: Tue, 12 Sep 2006 16:45:24 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] Local state advertisements and the implementer's guide Thread-Index: AcbMMntX/6yF4222QlGcs8CbsV+G2gAFBmGgAo7pH7A= From: "Surtees, Abigail" To: X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi All, I haven't had any response to this so far. I'm out of the office for the rest of the week but it would be really good if there were some responses to come back to on Monday ;-)=20 Best regards, Abbie=20 > -----Original Message----- > From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk]=20 > Sent: 30 August 2006 16:12 > To: rohc@ietf.org > Subject: [rohc] Local state advertisements and the implementer's guide >=20 > Hi All, >=20 > Back in February and March we were having a discussion about=20 > locally available state items and the semantics of their=20 > advertisement. >=20 > We didn't conclude the discussion for the last version of the=20 > implementer's guide so I included an editor's note. The=20 > discussion seems to have stalled at that point, so here's=20 > where I think we are, and a proposal for how to progress. >=20 > (The previous email thread starts with the third part of this=20 > email=20 > tml> and continues till Fri 3rd March and the resulting ID is here > mpl-guide- > 06.txt> (section 10.3).) >=20 > 1) The definition of advertisement of locally available state=20 > (such as dictionaries and well-known pieces of bytecode) is=20 > relatively clear in RFC 3320. The assumptions are that: >=20 > a) such state is local to the endpoint and will not be=20 > deleted (ignoring I-bit, see below) >=20 > b) such state does NOT count towards the SMS of a compartment >=20 > [as an implementation choice, locally available states may be=20 > mapped onto compartments, but this must not affect (a) and=20 > (b), above.] >=20 > 2) Section 6.2 of RFC 3320 discusses mapping locally=20 > available state to a compartment. I believe that this=20 > concept (as specified in RFC 3320 > only) is not well-defined (e.g. does it count towards SMS, if=20 > so, how does the I-bit work? If not, why define the use of=20 > minimum retention > priority?) =20 >=20 > Can anyone (authors?) explain to me the intention of this for=20 > a basic (RFC 3320) implementation? >=20 > If not, then I suggest that the clarification for the=20 > implementer's guide is that the concept of mapping locally=20 > available state to a compartment can only be considered as an=20 > implementation choice and one that cannot interfere with the=20 > statements in (1), above. >=20 > A locally available state item that is advertised can be=20 > assumed to be available for the lifetime of the compartment. >=20 > 3) If the advertised state is to be used in any other way,=20 > then its use and semantics (including the concept of mapping=20 > state to a compartment) must be fully and completely specified. >=20 > There are currently three uses (or proposed uses) of state > advertisements: >=20 > (a) Shared-mode (defined in Section 5.2 in RFC 3321) - >=20 > I believe that shared-mode (as clarified by section 5.3 of=20 > the implementer's guide) is well-defined, covering=20 > state-creation, priority, state-advertisement and deletion=20 > rules within a specified compartment mapping. >=20 > (b) Endpoint-initiated acks (defined in Section 5.1.2 in RFC 3321) - >=20 > Endpoint B advertises the hash of a state item that Endpoint=20 > A has requested B to create (within a compartment). Given=20 > these discussions, this does not seem to be a well-defined=20 > concept. There are various possible interpretations at=20 > Endpoint A on receipt of the advertisement from B: >=20 > i) ignore it because the hash doesn't match any locally=20 > available state known by the=20 > endpoint (basic 3320); >=20 > ii) as an 'ack', it simply means that B has successfully=20 > created the state > (this is a stronger statement than receipt of requested=20 > feedback, which means only=20 > that the message was successfully decompressed); >=20 > iii) Endpoint B already has a piece of locally available=20 > state with this hash, so > creation has failed (not useful); >=20 > iv) Endpoint B is treating the state in a manner similar to=20 > a piece of locally=20 > available state (i.e. increasing its lifetime) > (whether the state still counts towards SMS at this=20 > point is unclear). >=20 > (c) State lifetime extension (beyond compartment lifetime)=20 > (from section 6.2 of > ft-ietf-ro > hc-sigcomp-sip-02.txt>) - >=20 > This is similar to endpoint initiated acks but this document=20 > specifies that advertisements mean that the endpoint will=20 > keep the state for an unspecified amount of time beyond the=20 > closure of the compartment. >=20 > Since this clearly overlaps with (b), I believe this concept=20 > is also NOT well defined. >=20 >=20 > My proposal for the implementer's guide is to clarify that: >=20 > *) For 'basic' RFC 3320 implementations locally available state is > - not mapped to compartments > - is local to the endpoint and persists for the duration=20 > of the compartment > - does not impact compartment SMS >=20 > *) SigComp 'extended' mechanisms may use state advertisements=20 > provided that their use > is clearly defined and does not conflict with any other usage >=20 > - shared-mode is one such well-defined usage > (although its definition in a non-standards-track=20 > document is still rather odd!) >=20 > - endpoint initiated acknowledgements should be further clarified. >=20 > The suggested clarification for the advertisement semantics=20 > with respect to endpoint-initiated acks is as follows (this=20 > merges interpretations > ii) and iv); interpretation i) must always be valid): >=20 > "Where Endpoint A requests state creation at Endpoint B,=20 > Endpoint B may subsequently advertise the hash of the created=20 > state item to Endpoint A. > This conveys to Endpoint A (i) that the state has been=20 > successfully created within the compartment; and (ii) that=20 > the state will be available for *at least* the lifetime of=20 > the state as defined by RFC 3320. If the state is available=20 > at Endpoint B after it would be deleted from the compartment=20 > according to RFC 3320, then the state no longer counts=20 > towards the SMS of the compartment. Since there is no=20 > guarantee of such state being available beyond its normally=20 > defined lifetime, endpoints should only attempt to access the=20 > state where NACK is available." >=20 > This seems to allow for all currently proposed behaviours and=20 > does not conflict with the basic RFC 3320 definition. >=20 > Finally, if this clarification is made in the implementer's=20 > guide, then it is only addressing general SigComp behaviour. =20 > If a stronger promise of keeping state is wanted (e.g. beyond=20 > the end of the compartment) then this can be specified in=20 > 'Sigcomp for SIP' or other equivalent documents in the same=20 > way as the minimum DMS or support of a dictionary is specified. >=20 > What do you think? =20 >=20 > Best regards, >=20 > Abbie >=20 > -- > Abbie Surtees > Consultant Engineer > Roke Manor Research Ltd > +44 1794 833131 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Sep 14 10:23:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNs7S-0004B2-4Y; Thu, 14 Sep 2006 10:23:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNs7Q-0004Au-D2 for rohc@ietf.org; Thu, 14 Sep 2006 10:23:08 -0400 Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNs7N-0004yO-7k for rohc@ietf.org; Thu, 14 Sep 2006 10:23:08 -0400 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Content-Class: urn:content-classes:message Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 14 Sep 2006 19:52:58 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Sep 2006 19:52:58 +0530 Message-ID: <012301731C23DE4DBFE035647C68F1CC03E55DEA@sindhu.ctd.hcltech.com> From: "Gangadharan G - TLS,Chennai" To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Date: Thu, 14 Sep 2006 19:52:48 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-OriginalArrivalTime: 14 Sep 2006 14:22:58.0372 (UTC) FILETIME=[46F9D040:01C6D809] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Subject: [rohc] Doubt in SigComp Torture Testcase(RFC: 4465) X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0617149182==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============0617149182== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D809.4104DD85" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D809.4104DD85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi All, =20 I have a doubt in SigComp Torture Testcase(RFC: 4465) =20 In the State Memory Management Testcase (Section 4.2),=20 =20 I am getting State-ID for the State B, which is not same as the one specified in the Testcase.(:state_identifier_b byte (249, 1, 14, 239, = 86, 123)) =20 State-ID which I am getting is : 0x52a869484902a44e2f8c15e0f01d3e4d4d43b34f =20 State-ID that is specified in =20 the Testcase (First 6 Byte) is : 0xF9010EEF567B =20 Also, I have verified the State Value for which State-ID is created and specified it below. State Value starts from the UDVM memory address 512 (i.e.,from 384th = byte of the bytecode ) and=20 contains zeros for the remaining bytes =20 BLUE - Hash Header (state_length, state_address, state_instruction, minimum_access_length)=20 RED - first 6 bytes of B's State ID(which is included in the State = Value) 0x01, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x06, 0x74, 0x65, 0x73, 0x74, 0x00, 0x00, 0x00, 0x01, 0x00, 0x02, 0x00, 0x03, 0x00, 0x04, 0x00, 0x03, 0x00, 0x02, 0x00, 0x01, 0x00, 0x00, 0x8e, 0xea, 0x4b, 0x43, 0xa7, 0x87, 0xf9, 0x01, 0x0e, 0xef, 0x56, 0x7b, 0x23, 0x9a, 0x34, 0x6b, 0x15, 0xa6, 0xb4, 0x0f, 0xc0, 0xe4, 0x4d, 0x2c, 0xd4, 0xa2, 0x21, 0x47, 0xe6, 0x0a, 0xef, 0xf2, 0xbc, 0x0f, 0xb6, 0xaf, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ......................(Deleted few rows of 0x00 for = clarity).............. 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, =20 In the first run of the Testcase, the bytecode created a State (B) = starting from the memory address 512 and of length 256. Also the State-ID of that State(marked in red above), reference for State-Access in future run, is included in the Buffer to which SHA has = to be calculated. =20 I think, the State-ID of a State should not be a part of its = State-Value. =20 Please clarify me whether my State Value is right or wrong. =20 Thanks, Gangadharan. DISCLAIMER=20 The contents of this e-mail and any attachment(s) are confidential and = intended for the=20 named recipient(s) only. It shall not attach any liability on the = originator or HCL or its=20 affiliates. Any views or opinions presented in this email are solely = those of the author and=20 may not necessarily reflect the opinions of HCL or its affiliates. Any = form of reproduction,=20 dissemination, copying, disclosure, modification, distribution and / or = publication of this=20 message without the prior written consent of the author of this e-mail = is strictly=20 prohibited. If you have received this email in error please delete it = and notify the sender=20 immediately. Before opening any mail and attachments please check them = for viruses and=20 defect. ------_=_NextPart_001_01C6D809.4104DD85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
Hi=20 All,
 
I have = a doubt in=20 SigComp Torture Testcase(RFC: 4465)
 
In = the State=20 Memory Management Testcase (Section 4.2),
 
I am = getting=20 State-ID for the State B, which is not same as the one specified in the=20 Testcase.(:state_identifier_b   byte (249, 1, 14, = 239, 86,=20 123))
 
State-ID which I am=20 getting  is  :=20 0x52a869484902a44e2f8c15e0f01d3e4d4d43b34f
 
State-ID that is=20 specified in   
the = Testcase (First=20 6 Byte) is   :=20 0xF9010EEF567B
 
Also, = I have=20 verified the State Value for which State-ID is created and specified it=20 below.
State = Value starts=20 from the UDVM memory address 512 (i.e.,from 384th byte of = the bytecode=20 ) and
contains zeros for=20 the remaining bytes
 
BLUE - = Hash Header=20 (state_length, state_address, state_instruction, minimum_access_length)=20
RED  - first 6=20 bytes of B's State ID(which is included in the State = Value)
0x01, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x06, = 0x74,=20 0x65,
0x73, 0x74, 0x00, 0x00, 0x00, 0x01, 0x00, 0x02, 0x00, = 0x03,
0x00,=20 0x04, 0x00, 0x03, 0x00, 0x02, 0x00, 0x01, 0x00, 0x00,
0x8e, 0xea, = 0x4b, 0x43,=20 0xa7, 0x87, 0xf9, 0x01, 0x0e, = 0xef,
0x56, 0x7b, 0x23, 0x9a, 0x34, 0x6b, 0x15, 0xa6, = 0xb4,=20 0x0f,
0xc0, 0xe4, 0x4d, 0x2c, 0xd4, 0xa2, 0x21, 0x47, 0xe6, = 0x0a,
0xef,=20 0xf2, 0xbc, 0x0f, 0xb6, 0xaf, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, = 0x00, 0x00,=20 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, = 0x00, 0x00,=20 0x00, 0x00, 0x00,
......................(Deleted few rows of = 0x00 for=20 clarity)..............
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, = 0x00, 0x00,=20 0x00,
0x00, 0x00, 0x00, 0x00,
 
In the = first run of=20 the Testcase, the bytecode created a State (B) starting from the memory = address=20 512 and of length 256.
Also = the State-ID of=20 that State(marked in red above), reference for State-Access in future = run, is=20 included in the Buffer to which SHA has to be = calculated.
 
I = think, the=20 State-ID of a State should not be a part of=20 its State-Value.
 
Please = clarify me=20 whether my State Value is right or wrong.
 
Thanks,
Gangadharan.
------_=_NextPart_001_01C6D809.4104DD85-- --===============0617149182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0617149182==-- From rohc-bounces@ietf.org Thu Sep 14 11:49:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtTB-0000uT-61; Thu, 14 Sep 2006 11:49:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNtT9-0000u9-Sf for rohc@ietf.org; Thu, 14 Sep 2006 11:49:39 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNtT8-0000Q3-Ip for rohc@ietf.org; Thu, 14 Sep 2006 11:49:39 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id k8EFb5Q18924 for ; Thu, 14 Sep 2006 16:37:05 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [rohc] Doubt in SigComp Torture Testcase(RFC: 4465) MIME-Version: 1.0 Date: Thu, 14 Sep 2006 16:48:26 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002D46874@svr-exchange.avocado.emccsoft.com> In-Reply-To: <012301731C23DE4DBFE035647C68F1CC03E55DEA@sindhu.ctd.hcltech.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] Doubt in SigComp Torture Testcase(RFC: 4465) thread-index: AcbYCWp65fafn6X1RRWVdpmk89YYnQACpqsg From: "John Barber" To: "Gangadharan G - TLS,Chennai" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1588088844==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============1588088844== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D815.3F854810" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D815.3F854810 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello Gangadharan, =20 The Torture Test document is correct and your state ID is not correct. =20 See this discussion on the ROHC archives: http://www1.ietf.org/mail-archive/web/rohc/current/msg04224.html =20 Regards, John ________________________________ From: Gangadharan G - TLS,Chennai [mailto:gangadharang@hcl.in]=20 Sent: 14 September 2006 15:23 To: rohc@ietf.org Subject: [rohc] Doubt in SigComp Torture Testcase(RFC: 4465) =09 =09 Hi All, =20 I have a doubt in SigComp Torture Testcase(RFC: 4465) =20 In the State Memory Management Testcase (Section 4.2),=20 =20 I am getting State-ID for the State B, which is not same as the one specified in the Testcase.(:state_identifier_b byte (249, 1, 14, 239, 86, 123)) =20 State-ID which I am getting is : 0x52a869484902a44e2f8c15e0f01d3e4d4d43b34f =20 State-ID that is specified in =20 the Testcase (First 6 Byte) is : 0xF9010EEF567B =20 Also, I have verified the State Value for which State-ID is created and specified it below. State Value starts from the UDVM memory address 512 (i.e.,from 384th byte of the bytecode ) and=20 contains zeros for the remaining bytes =20 BLUE - Hash Header (state_length, state_address, state_instruction, minimum_access_length)=20 RED - first 6 bytes of B's State ID(which is included in the State Value) 0x01, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x06, 0x74, 0x65, 0x73, 0x74, 0x00, 0x00, 0x00, 0x01, 0x00, 0x02, 0x00, 0x03, 0x00, 0x04, 0x00, 0x03, 0x00, 0x02, 0x00, 0x01, 0x00, 0x00, 0x8e, 0xea, 0x4b, 0x43, 0xa7, 0x87, 0xf9, 0x01, 0x0e, 0xef, 0x56, 0x7b, 0x23, 0x9a, 0x34, 0x6b, 0x15, 0xa6, 0xb4, 0x0f, 0xc0, 0xe4, 0x4d, 0x2c, 0xd4, 0xa2, 0x21, 0x47, 0xe6, 0x0a, 0xef, 0xf2, 0xbc, 0x0f, 0xb6, 0xaf, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ......................(Deleted few rows of 0x00 for clarity).............. 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, =20 In the first run of the Testcase, the bytecode created a State (B) starting from the memory address 512 and of length 256. Also the State-ID of that State(marked in red above), reference for State-Access in future run, is included in the Buffer to which SHA has to be calculated. =20 I think, the State-ID of a State should not be a part of its State-Value. =20 Please clarify me whether my State Value is right or wrong. =20 Thanks, Gangadharan. DISCLAIMER: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect.=20 ------_=_NextPart_001_01C6D815.3F854810 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hello Gangadharan,
 
The Torture Test document is correct and your = state ID is=20 not correct.
 
See this discussion on the ROHC archives: http://www1.ietf.org/mail-archive/web/rohc/current/msg04224.html
 
Regards, John

From: Gangadharan G - TLS,Chennai=20 [mailto:gangadharang@hcl.in]
Sent: 14 September 2006=20 15:23
To: rohc@ietf.org
Subject: [rohc] Doubt in = SigComp=20 Torture Testcase(RFC: 4465)

Hi=20 All,
 
I = have a doubt in=20 SigComp Torture Testcase(RFC: 4465)
 
In = the State=20 Memory Management Testcase (Section 4.2),
 
I am = getting=20 State-ID for the State B, which is not same as the one specified in = the=20 Testcase.(:state_identifier_b   byte (249, 1, = 14, 239, 86,=20 123))
 
State-ID which I=20 am getting  is  :=20 0x52a869484902a44e2f8c15e0f01d3e4d4d43b34f
 
State-ID that is=20 specified in   
the = Testcase=20 (First 6 Byte) is   = :=20 0xF9010EEF567B
 
Also, I have=20 verified the State Value for which State-ID is created and specified = it=20 below.
State Value starts=20 from the UDVM memory address 512 (i.e.,from 384th = byte of the=20 bytecode ) and
contains zeros for=20 the remaining bytes
 
BLUE = - Hash Header=20 (state_length, state_address, state_instruction, = minimum_access_length)=20
RED  - first=20 6 bytes of B's State ID(which is included in the State=20 Value)
0x01, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x06, = 0x74,=20 0x65,
0x73, 0x74, 0x00, 0x00, 0x00, 0x01, 0x00, 0x02, 0x00, = 0x03,
0x00,=20 0x04, 0x00, 0x03, 0x00, 0x02, 0x00, 0x01, 0x00, 0x00,
0x8e, 0xea, = 0x4b,=20 0x43, 0xa7, 0x87, 0xf9, 0x01, 0x0e, = 0xef,
0x56, 0x7b, 0x23, 0x9a, 0x34, 0x6b, 0x15, 0xa6, = 0xb4,=20 0x0f,
0xc0, 0xe4, 0x4d, 0x2c, 0xd4, 0xa2, 0x21, 0x47, 0xe6, = 0x0a,
0xef,=20 0xf2, 0xbc, 0x0f, 0xb6, 0xaf, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, = 0x00,=20 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, = 0x00,=20 0x00, 0x00, 0x00, 0x00, 0x00,
......................(Deleted few rows of = 0x00 for=20 clarity)..............
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, = 0x00,=20 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
 
In = the first run=20 of the Testcase, the bytecode created a State (B) starting from the = memory=20 address 512 and of length 256.
Also = the State-ID=20 of that State(marked in red above), reference for State-Access in = future run,=20 is included in the Buffer to which SHA has to be=20 calculated.
 
I = think, the=20 State-ID of a State should not be a part of=20 its State-Value.
 
Please clarify me=20 whether my State Value is right or wrong.
 
Thanks,
Gangadharan.
------_=_NextPart_001_01C6D815.3F854810-- --===============1588088844== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1588088844==-- From rohc-bounces@ietf.org Fri Sep 15 07:35:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOByH-00069T-Ul; Fri, 15 Sep 2006 07:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOByG-00069J-Kc for rohc@ietf.org; Fri, 15 Sep 2006 07:35:00 -0400 Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOByF-00077q-2H for rohc@ietf.org; Fri, 15 Sep 2006 07:35:00 -0400 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Content-Class: urn:content-classes:message Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 15 Sep 2006 17:04:56 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Sep 2006 17:04:56 +0530 Message-ID: <012301731C23DE4DBFE035647C68F1CC03E79D3F@sindhu.ctd.hcltech.com> From: "Gangadharan G - TLS,Chennai" To: "John Barber" , "Gangadharan G - TLS,Chennai" , Subject: RE: [rohc] Doubt in SigComp Torture Testcase(RFC: 4465) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Date: Fri, 15 Sep 2006 16:11:19 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-OriginalArrivalTime: 15 Sep 2006 11:34:56.0919 (UTC) FILETIME=[F85FEA70:01C6D8BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2035571850==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============2035571850== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D8B3.7A87F044" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D8B3.7A87F044 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Hi John, Thanks for ur valuable reponse. Mistake is on my State value. I had not followed the section 8.4(RFC 3320) for bytecopying in the State-Create instruction. Thanks, Gangadharan. -----Original Message----- From: John Barber [mailto:john.barber@emccsoft.com] Sent: Thursday, September 14, 2006 9:18 PM To: Gangadharan G - TLS,Chennai; rohc@ietf.org Subject: RE: [rohc] Doubt in SigComp Torture Testcase(RFC: 4465) Hello Gangadharan, The Torture Test document is correct and your state ID is not correct. See this discussion on the ROHC archives: http://www1.ietf.org/mail-archive/web/rohc/current/msg04224.html Regards, John _____ From: Gangadharan G - TLS,Chennai [mailto:gangadharang@hcl.in] Sent: 14 September 2006 15:23 To: rohc@ietf.org Subject: [rohc] Doubt in SigComp Torture Testcase(RFC: 4465) Hi All, I have a doubt in SigComp Torture Testcase(RFC: 4465) In the State Memory Management Testcase (Section 4.2), I am getting State-ID for the State B, which is not same as the one specified in the Testcase.(:state_identifier_b byte (249, 1, 14, 239, 86, 123)) State-ID which I am getting is : 0x52a869484902a44e2f8c15e0f01d3e4d4d43b34f State-ID that is specified in the Testcase (First 6 Byte) is : 0xF9010EEF567B Also, I have verified the State Value for which State-ID is created and specified it below. State Value starts from the UDVM memory address 512 (i.e.,from 384th byte of the bytecode ) and contains zeros for the remaining bytes BLUE - Hash Header (state_length, state_address, state_instruction, minimum_access_length) RED - first 6 bytes of B's State ID(which is included in the State Value) 0x01, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x06, 0x74, 0x65, 0x73, 0x74, 0x00, 0x00, 0x00, 0x01, 0x00, 0x02, 0x00, 0x03, 0x00, 0x04, 0x00, 0x03, 0x00, 0x02, 0x00, 0x01, 0x00, 0x00, 0x8e, 0xea, 0x4b, 0x43, 0xa7, 0x87, 0xf9, 0x01, 0x0e, 0xef, 0x56, 0x7b, 0x23, 0x9a, 0x34, 0x6b, 0x15, 0xa6, 0xb4, 0x0f, 0xc0, 0xe4, 0x4d, 0x2c, 0xd4, 0xa2, 0x21, 0x47, 0xe6, 0x0a, 0xef, 0xf2, 0xbc, 0x0f, 0xb6, 0xaf, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ......................(Deleted few rows of 0x00 for clarity).............. 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, In the first run of the Testcase, the bytecode created a State (B) starting from the memory address 512 and of length 256. Also the State-ID of that State(marked in red above), reference for State-Access in future run, is included in the Buffer to which SHA has to be calculated. I think, the State-ID of a State should not be a part of its State-Value. Please clarify me whether my State Value is right or wrong. Thanks, Gangadharan. DISCLAIMER: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ------_=_NextPart_001_01C6D8B3.7A87F044 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 John,
 
Thanks=20 for ur valuable reponse.
 
Mistake is on my State value.
I had=20 not followed the section 8.4(RFC 3320) for bytecopying in the = State-Create=20 instruction.
 
Thanks,
Gangadharan.
-----Original Message-----
From: John Barber=20 [mailto:john.barber@emccsoft.com]
Sent: Thursday, September = 14, 2006=20 9:18 PM
To: Gangadharan G - TLS,Chennai;=20 rohc@ietf.org
Subject: RE: [rohc] Doubt in SigComp Torture=20 Testcase(RFC: 4465)

Hello Gangadharan,
 
The Torture Test document is correct and = your state ID is=20 not correct.
 
 
Regards, John

From: Gangadharan G - = TLS,Chennai=20 [mailto:gangadharang@hcl.in]
Sent: 14 September 2006=20 15:23
To: rohc@ietf.org
Subject: [rohc] Doubt = in SigComp=20 Torture Testcase(RFC: 4465)

Hi=20 All,
 
I = have a doubt=20 in SigComp Torture Testcase(RFC: 4465)
 
In=20 the State Memory Management Testcase (Section 4.2),=20
 
I = am getting=20 State-ID for the State B, which is not same as the one specified in = the=20 Testcase.(:state_identifier_b   byte (249, = 1, 14, 239,=20 86, 123))
 
State-ID which I=20 am getting  is  :=20 0x52a869484902a44e2f8c15e0f01d3e4d4d43b34f
 
State-ID that is=20 specified in   
the Testcase=20 (First 6 Byte) is   :=20 0xF9010EEF567B
 
Also, I have=20 verified the State Value for which State-ID is created and = specified it=20 below.
State Value=20 starts from the UDVM memory address 512 (i.e.,from 384th = byte of the=20 bytecode ) and
contains zeros=20 for the remaining bytes
 
BLUE - Hash=20 Header (state_length, state_address, state_instruction,=20 minimum_access_length)
RED  -=20 first 6 bytes of B's State ID(which is included in the State=20 Value)
0x01, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, = 0x06, 0x74,=20 0x65,
0x73, 0x74, 0x00, 0x00, 0x00, 0x01, 0x00, 0x02, 0x00,=20 0x03,
0x00, 0x04, 0x00, 0x03, 0x00, 0x02, 0x00, 0x01, 0x00,=20 0x00,
0x8e, 0xea, 0x4b, 0x43, 0xa7, 0x87, 0xf9, 0x01,=20 0x0e, 0xef,
0x56, 0x7b, = 0x23, 0x9a,=20 0x34, 0x6b, 0x15, 0xa6, 0xb4, 0x0f,
0xc0, 0xe4, 0x4d, 0x2c, = 0xd4, 0xa2,=20 0x21, 0x47, 0xe6, 0x0a,
0xef, 0xf2, 0xbc, 0x0f, 0xb6, 0xaf, = 0x00, 0x00,=20 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, = 0x00,=20 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,=20 0x00,
......................(Deleted few rows = of 0x00 for=20 clarity)..............
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, = 0x00,=20 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
 
In the first run=20 of the Testcase, the bytecode created a State (B) starting from the = memory=20 address 512 and of length 256.
Al= so the=20 State-ID of that State(marked in red above), reference for = State-Access in=20 future run, is included in the Buffer to which SHA has to be=20 calculated.
 
I = think, the=20 State-ID of a State should not be a part of=20 its State-Value.
 
Please clarify=20 me whether my State Value is right or wrong.
 
Thanks,
Gangadharan.
------_=_NextPart_001_01C6D8B3.7A87F044-- --===============2035571850== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============2035571850==-- From rohc-bounces@ietf.org Fri Sep 15 07:37:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOC0X-0006bF-JQ; Fri, 15 Sep 2006 07:37:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOC0X-0006bA-7y for rohc@ietf.org; Fri, 15 Sep 2006 07:37:21 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOC0U-0007Vo-QX for rohc@ietf.org; Fri, 15 Sep 2006 07:37:21 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k8FBbElk030984 for ; Fri, 15 Sep 2006 14:37:17 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 14:37:16 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 14:37:16 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Sep 2006 14:37:16 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RoHCv2 and Timer-based compression of RTP Timestamp Thread-Index: AcbYu0uMg+fhLSZZRlKwM0WY8ezqpQ== From: To: X-OriginalArrivalTime: 15 Sep 2006 11:37:16.0228 (UTC) FILETIME=[4B68C840:01C6D8BB] X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [rohc] RoHCv2 and Timer-based compression of RTP Timestamp X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi, I looked at draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt and I couldn't find any mention about "Timer-based compression of RTP Timestamp" (as in chapter 4.5.4 in RFC3095). I wonder why it is not there? Thanks, Teemu _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Sep 15 08:22:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOCiD-00058i-2s; Fri, 15 Sep 2006 08:22:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GOCiB-00058b-AU for rohc@ietf.org; Fri, 15 Sep 2006 08:22:27 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GOCi1-0005J3-5h for rohc@ietf.org; Fri, 15 Sep 2006 08:22:27 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6B88F4F009F; Fri, 15 Sep 2006 14:22:14 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 14:22:14 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Sep 2006 14:22:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] RoHCv2 and Timer-based compression of RTP Timestamp Date: Fri, 15 Sep 2006 14:22:14 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC05037B8D87@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] RoHCv2 and Timer-based compression of RTP Timestamp thread-index: AcbYu0uMg+fhLSZZRlKwM0WY8ezqpQABI/5g From: "Ghyslain Pelletier \(LU/EAB\)" To: , X-OriginalArrivalTime: 15 Sep 2006 12:22:13.0876 (UTC) FILETIME=[93553340:01C6D8C1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Teemu, The technical merits of timer-based compression, and whether to include it or not in RoHCv2, have already been discussed on the list and at the Montreal meeting. As you know, everything sent to the list gets archived! The last mail on this thread is found at the following link: http://www1.ietf.org/mail-archive/web/rohc/current/msg04408.html You can start from there and make your way back through the discussion. I have also summarized pros and cons of having timer-based compression in RoHCv2 in my presentation at the MTL meeting:=20 http://www3.ietf.org/proceedings/06jul/slides/rohc-2/sld41.htm My understanding is that so far the consensus leans towards not to support tbc in RoHCv2. Personnally, based on the technical discussion, I am happy with this consensus. In our original individual submission, which later got accepted as a wg document, we consciously made the proposal wihtout supporting tbc so it is not something that was "forgotten". Regards, ///Ghyslain teemu.savolainen@nokia.com wrote: > Hi, >=20 > I looked at draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt > and I couldn't find any mention about "Timer-based > compression of RTP Timestamp" (as in chapter 4.5.4 in RFC3095). >=20 > I wonder why it is not there? >=20 > Thanks, >=20 > Teemu >=20 > _______________________________________________ > 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 rohc-bounces@ietf.org Mon Sep 18 12:06:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPLdE-0005e4-Sb; Mon, 18 Sep 2006 12:06:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPLdB-0005dQ-VR for rohc@ietf.org; Mon, 18 Sep 2006 12:06:01 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPLd2-0003gS-Fs for rohc@ietf.org; Mon, 18 Sep 2006 12:06:01 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BF3E68E0001 for ; Mon, 18 Sep 2006 18:05:49 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 18:05:49 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Sep 2006 18:05:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Sep 2006 18:05:48 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0503801D05@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Email with attached legal disclaimers thread-index: AcbVr13gN+ile67gRr6T3qFD3xgVfgFjOS+g From: "Lars-Erik Jonsson \(LU/EAB\)" To: X-OriginalArrivalTime: 18 Sep 2006 16:05:49.0367 (UTC) FILETIME=[4ED3EC70:01C6DB3C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [rohc] FW: Email with attached legal disclaimers X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org ----Original Message---- From: IETF Chair [mailto:chair@ietf.org] Sent: den 11 september 2006 16:28 To: IETF Announcement list Subject: Email with attached legal disclaimers > Sometimes people send IETF email with attached legal disclaimers, > usually inserted automatically by their employer's mail system. > These disclaimers make assertions about confidentiality and may > contain phrases like "If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of > this information is prohibited." >=20 > You are reminded that IETF contributions are automatically subject > to RFC 3978, which explicitly states in Section 3.2 that: >=20 > Each Contributor agrees that any statement in a Contribution, > whether generated automatically or otherwise, that states or > implies that the Contribution is confidential or subject to any > privilege, can be disregarded for all purposes, and will be of no > force or effect.=20 >=20 > Therefore, any such disclaimers attached to IETF email can be ignored > for IETF purposes. >=20 > However, we strongly advise all participants to take all possible > steps to prevent the addition of such disclaimers. Among other issues, > some other standards organizations will refuse to consider any liaison > message from an IETF source that contains such a disclaimer. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Sep 19 02:40:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPZHO-0007DR-4B; Tue, 19 Sep 2006 02:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNrwd-0001AP-5S for rohc@ietf.org; Thu, 14 Sep 2006 10:11:59 -0400 Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNrwb-00032F-Cu for rohc@ietf.org; Thu, 14 Sep 2006 10:11:59 -0400 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Content-Class: urn:content-classes:message Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 14 Sep 2006 19:41:52 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Sep 2006 19:41:52 +0530 Message-ID: <012301731C23DE4DBFE035647C68F1CC03E55DC7@sindhu.ctd.hcltech.com> From: "Gangadharan G - TLS,Chennai" To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Date: Thu, 14 Sep 2006 19:41:51 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-OriginalArrivalTime: 14 Sep 2006 14:11:52.0294 (UTC) FILETIME=[B9F66060:01C6D807] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 X-Mailman-Approved-At: Tue, 19 Sep 2006 02:40:24 -0400 Cc: mark.a.west@roke.co.uk, abigail.surtees@roke.co.uk Subject: [rohc] Doubt in SigComp Torture Testcase(RFC: 4465) X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1406092093==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============1406092093== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6D807.B93D2369" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6D807.B93D2369 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi All, =20 I have a doubt in SigComp Torture Testcase(RFC: 4465) =20 In the State Memory Management Testcase (Section 4.2),=20 =20 I am getting State-ID for the State B, which is not same as the one specified in the Testcase.(:state_identifier_b byte (249, 1, 14, 239, = 86, 123)) =20 State-ID which I am getting is : 0x52a869484902a44e2f8c15e0f01d3e4d4d43b34f =20 State-ID that is specified in =20 the Testcase (First 6 Byte) is : 0xF9010EEF567B =20 Also, I have verified the State Value for which State-ID is created and specified it below. State Value starts from the UDVM memory address 512 (i.e.,from 384th = byte of the bytecode ) and=20 contains zeros for the remaining bytes =20 BLUE - Hash Header (state_length, state_address, state_instruction, minimum_access_length)=20 RED - first 6 bytes of B's State ID(which is included in the State = Value) 0x01, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x06, 0x74, 0x65, 0x73, 0x74, 0x00, 0x00, 0x00, 0x01, 0x00, 0x02, 0x00, 0x03, 0x00, 0x04, 0x00, 0x03, 0x00, 0x02, 0x00, 0x01, 0x00, 0x00, 0x8e, 0xea, 0x4b, 0x43, 0xa7, 0x87, 0xf9, 0x01, 0x0e, 0xef, 0x56, 0x7b, 0x23, 0x9a, 0x34, 0x6b, 0x15, 0xa6, 0xb4, 0x0f, 0xc0, 0xe4, 0x4d, 0x2c, 0xd4, 0xa2, 0x21, 0x47, 0xe6, 0x0a, 0xef, 0xf2, 0xbc, 0x0f, 0xb6, 0xaf, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, ......................(Deleted few rows of 0x00 for = clarity).............. 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, =20 In the first run of the Testcase, the bytecode created a State (B) = starting from the memory address 512 and of length 256. Also the State-ID of that State(marked in red above), reference for State-Access in future run, is included in the Buffer to which SHA has = to be calculated. =20 I think, the State-ID of a State should not be a part of its = State-Value. =20 Please clarify me whether my State Value is right or wrong. =20 Thanks, Gangadharan. DISCLAIMER=20 The contents of this e-mail and any attachment(s) are confidential and = intended for the=20 named recipient(s) only. It shall not attach any liability on the = originator or HCL or its=20 affiliates. Any views or opinions presented in this email are solely = those of the author and=20 may not necessarily reflect the opinions of HCL or its affiliates. Any = form of reproduction,=20 dissemination, copying, disclosure, modification, distribution and / or = publication of this=20 message without the prior written consent of the author of this e-mail = is strictly=20 prohibited. If you have received this email in error please delete it = and notify the sender=20 immediately. Before opening any mail and attachments please check them = for viruses and=20 defect. ------_=_NextPart_001_01C6D807.B93D2369 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
Hi=20 All,
 
I have = a doubt in=20 SigComp Torture Testcase(RFC: 4465)
 
In = the State=20 Memory Management Testcase (Section 4.2),
 
I am = getting=20 State-ID for the State B, which is not same as the one specified in the=20 Testcase.(:state_identifier_b   byte (249, 1, 14, = 239, 86,=20 123))
 
State-ID which I am=20 getting  is  :=20 0x52a869484902a44e2f8c15e0f01d3e4d4d43b34f
 
State-ID that is=20 specified in   
the = Testcase (First=20 6 Byte) is   :=20 0xF9010EEF567B
 
Also, = I have=20 verified the State Value for which State-ID is created and specified it=20 below.
State = Value starts=20 from the UDVM memory address 512 (i.e.,from 384th byte of = the bytecode=20 ) and
contains zeros for=20 the remaining bytes
 
BLUE - = Hash Header=20 (state_length, state_address, state_instruction, minimum_access_length)=20
RED  - first 6=20 bytes of B's State ID(which is included in the State = Value)
0x01, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x06, = 0x74,=20 0x65,
0x73, 0x74, 0x00, 0x00, 0x00, 0x01, 0x00, 0x02, 0x00, = 0x03,
0x00,=20 0x04, 0x00, 0x03, 0x00, 0x02, 0x00, 0x01, 0x00, 0x00,
0x8e, 0xea, = 0x4b, 0x43,=20 0xa7, 0x87, 0xf9, 0x01, 0x0e, = 0xef,
0x56, 0x7b, 0x23, 0x9a, 0x34, 0x6b, 0x15, 0xa6, = 0xb4,=20 0x0f,
0xc0, 0xe4, 0x4d, 0x2c, 0xd4, 0xa2, 0x21, 0x47, 0xe6, = 0x0a,
0xef,=20 0xf2, 0xbc, 0x0f, 0xb6, 0xaf, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, = 0x00, 0x00,=20 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, = 0x00, 0x00,=20 0x00, 0x00, 0x00,
......................(Deleted few rows of = 0x00 for=20 clarity)..............
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, = 0x00, 0x00,=20 0x00,
0x00, 0x00, 0x00, 0x00,
 
In the = first run of=20 the Testcase, the bytecode created a State (B) starting from the memory = address=20 512 and of length 256.
Also = the State-ID of=20 that State(marked in red above), reference for State-Access in future = run, is=20 included in the Buffer to which SHA has to be = calculated.
 
I = think, the=20 State-ID of a State should not be a part of=20 its State-Value.
 
Please = clarify me=20 whether my State Value is right or wrong.
 
Thanks,
Gangadharan.
------_=_NextPart_001_01C6D807.B93D2369-- --===============1406092093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1406092093==-- From rohc-bounces@ietf.org Tue Sep 19 02:40:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPZHO-0007Dx-Oz; Tue, 19 Sep 2006 02:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPKgc-0008N2-WC for rohc@ietf.org; Mon, 18 Sep 2006 11:05:31 -0400 Received: from mail.cogent-dsn.com ([62.254.246.43]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GPKgb-0003pt-MF for rohc@ietf.org; Mon, 18 Sep 2006 11:05:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Sep 2006 16:05:28 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Local state advertisements and the implementer's guide Thread-Index: AcbMMntX/6yF4222QlGcs8CbsV+G2gL7U87gALqmt6A= From: "Richard Price" To: "John Barber" , "Surtees, Abigail" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-Mailman-Approved-At: Tue, 19 Sep 2006 02:40:24 -0400 Cc: jdrosen@dynamicsoft.com, zhigang.c.liu@nokia.com, Gonzalo.Camarillo@ericsson.com, hans.hannu@ericsson.com, "Lajos Zaccomer \(IJ/ETH\)" , jan.christoffersson@ericsson.com, cabo@tzi.org Subject: [rohc] RE: Local state advertisements and the implementer's guide X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org >> My proposal for the implementer's guide is to clarify that: >>=20 >> *) For 'basic' RFC 3320 implementations locally available state is >> - not mapped to compartments >> - is local to the endpoint and persists for the duration=20 >> of the compartment >> - does not impact compartment SMS >>=20 > I agree with this. Though I see it as a correction rather than a > clarification. The concept of mapping locally available state items to = a > compartment is to my mind a mistake by the authors of RFC3320, a > confusion of a possible private implementation strategies with > definitions of externally visible behaviours. It would certainly be nice if the storage of all locally available state could be considered an implementation issue at the decompressor. In fact this was exactly how early versions of RFC3320 were intended to work. However, an objection was raised that memory-intensive mechanisms such = as shared mode would be throwing away a large amount of memory advertising states that the remote endpoint might not even want to use. In response, we added to RFC3320 a mechanism for storing locally available state = inside the UDVM's own per-compartment memory. This allowed implementations to use mechanisms like shared mode without worrying about wasting memory unnecessarily. I don't think we can put the above into the implementer's guide as a "clarification", as it would be a technical change to RFC3320 to delete the ability to use the per-compartment memory to store locally available states. But nothing stops us from getting rid of this mechanism in the next version of RFC3320 if it is determined that implementers do not wish to make use of it. >> Finally, if this clarification is made in the implementer's=20 >> guide, then it is only addressing general SigComp behaviour. =20 >> If a stronger promise of keeping state is wanted (e.g. beyond=20 >> the end of the compartment) then this can be specified in=20 >> 'Sigcomp for SIP' or other equivalent documents in the same=20 >> way as the minimum DMS or support of a dictionary is specified. > Going a bit off topic here, I'd just add that the authors of such > documents should not only specify requirements as to state items which > must mandatorily be made available for specific environments, but = should > also make it clear whether or not those state items need to be > advertised. E.g. "Sigcomp for SIP" says the SIP/SDP dictionary must > always be available but it isn't stated whether or not it also needs = to > be advertised or whether its presence should just be assumed. If an item of state is mandatory in a particular environment, its presence can by definition be assumed by the compressor. So there's no need to advertise the state - you can advertise it anyway but I can't see any benefit to doing this. Cheers, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Sep 19 02:40:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPZHO-0007Dp-KG; Tue, 19 Sep 2006 02:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPKf2-000884-1N for rohc@ietf.org; Mon, 18 Sep 2006 11:03:52 -0400 Received: from mail.cogent-dsn.com ([62.254.246.43]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GPKez-0003S3-GJ for rohc@ietf.org; Mon, 18 Sep 2006 11:03:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Sep 2006 16:03:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Local state advertisements and the implementer's guide Thread-Index: AcbMMntX/6yF4222QlGcs8CbsV+G2gO4yoBQ From: "Richard Price" To: "Surtees, Abigail" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 X-Mailman-Approved-At: Tue, 19 Sep 2006 02:40:24 -0400 Cc: jdrosen@dynamicsoft.com, zhigang.c.liu@nokia.com, Gonzalo.Camarillo@ericsson.com, hans.hannu@ericsson.com, "Lajos Zaccomer \(IJ/ETH\)" , jan.christoffersson@ericsson.com, John Barber , cabo@tzi.org Subject: [rohc] RE: Local state advertisements and the implementer's guide X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org > 2) Section 6.2 of RFC 3320 discusses mapping locally available state = to > a compartment. I believe that this concept (as specified in RFC 3320 > only) is not well-defined (e.g. does it count towards SMS, if so, how > does the I-bit work? If not, why define the use of minimum retention > priority?) =20 If locally available state is defined as being mapped to a compartment, then it does indeed count towards the SMS of the compartment. I believe that this is clear from point 5.) of Section 6.2 - as you noted, the state could not have a minimum retention priority otherwise. I don't see how Section 6.2 contradicts the definition of the I-bit, could you expand on this one? > Can anyone (authors?) explain to me the intention of this for a basic > (RFC 3320) implementation? The reason for providing this mechanism is purely to give implementers of shared mode the ability to optimise their memory usage, by allowing them to store their locally available state items in the same memory as is reserved for the compartment. If we did not have this mechanism then implementers of shared mode would need to store their locally available state items in separate memory, which could potentially be very inefficient as the total size of the locally available state items created by shared mode is equal to the uncompressed size of all messages transmitted in one direction. For a basic implementation of RFC3320 (not implementing shared mode), there is no impact save for the fact that the special state retention priority of 65535 is reserved and causes a decompression failure if the bytecode tries to use it. > If not, then I suggest that the clarification for the implementer's > guide is that the concept of mapping locally available state to a > compartment can only be considered as an implementation choice and one > that cannot interfere with the statements in (1), above. The only support required in RFC3320 is the special state retention priority. > A locally available state item that is advertised can be assumed to be > available for the lifetime of the compartment. Yes, given the caveat that if it is defined to be mapped to a = compartment as in shared mode, then it can be pushed out of the compartment's memory by other states. > (b) Endpoint-initiated acks (defined in Section 5.1.2 in RFC 3321) - > Endpoint B advertises the hash of a state item that Endpoint A has > requested B to create (within a compartment). Given these = discussions, > this does not seem to be a well-defined concept. There are various > possible interpretations at Endpoint A on receipt of the advertisement > from B: Once a state has been advertised to the compressor in a compartment, it must remain available to the compressor until the compartment closes or one of the following occurs: i) The state item is pushed out of the compartment's memory by other state items. ii) The compressor uses the I-bit to indicate that it no longer wants the state. RFC3321 should not contradict this! In particular, just advertising a state should not increase its lifetime, unless this is standardised somehow (e.g. in the SigComp/SIP draft). > (c) State lifetime extension (beyond compartment lifetime)=20 > (from section 6.2 of > = hc-sigcomp-sip-02.txt>) - >=20 > This is similar to endpoint initiated acks but this document specifies > that advertisements mean that the endpoint will keep the state for an > unspecified amount of time beyond the closure of the compartment. >=20 > Since this clearly overlaps with (b), I believe this concept is also = NOT > well defined. Indeed it isn't - more needs to be said on the lifetime of the state if it is greater than that of a compartment, or the relevant paragraph should be deleted. > My proposal for the implementer's guide is to clarify that: >=20 > *) For 'basic' RFC 3320 implementations locally available state is > - not mapped to compartments > - is local to the endpoint and persists for the duration of the > compartment > - does not impact compartment SMS Ok with the caveat that in order to support shared mode, the special state retention priority of 65535 must still be reserved by "basic" RFC3320 implementations, even if they happen to not create any locally available state that is mapped to a compartment. > *) SigComp 'extended' mechanisms may use state advertisements provided > that their use > is clearly defined and does not conflict with any other usage >=20 > - shared-mode is one such well-defined usage > (although its definition in a non-standards-track document is = still > rather odd!) The IETF provides "hooks" in RFC3320 to allow implementations to support shared mode, but does not standardise shared mode itself. > - endpoint initiated acknowledgements should be further clarified. >=20 > The suggested clarification for the advertisement semantics with = respect > to endpoint-initiated acks is as follows (this merges interpretations > ii) and iv); interpretation i) must always be valid): >=20 > "Where Endpoint A requests state creation at Endpoint B, Endpoint B = may > subsequently advertise the hash of the created state item to Endpoint = A. > This conveys to Endpoint A (i) that the state has been successfully > created within the compartment; and (ii) that the state will be > available for *at least* the lifetime of the state as defined by RFC > 3320. If the state is available at Endpoint B after it would be = deleted > from the compartment according to RFC 3320, then the state no longer > counts towards the SMS of the compartment. Since there is no = guarantee > of such state being available beyond its normally defined lifetime, > endpoints should only attempt to access the state where NACK is > available." >=20 > This seems to allow for all currently proposed behaviours and does not > conflict with the basic RFC 3320 definition. Sounds good. > Finally, if this clarification is made in the implementer's guide, = then > it is only addressing general SigComp behaviour. If a stronger = promise > of keeping state is wanted (e.g. beyond the end of the compartment) = then > this can be specified in 'Sigcomp for SIP' or other equivalent = documents > in the same way as the minimum DMS or support of a dictionary is > specified. >=20 > What do you think? =20 All fine, with the caveat that the special state retention priority of 65535 is still special in RFC3320. Cheers, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Sep 19 02:40:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPZHO-0007Dx-Oz; Tue, 19 Sep 2006 02:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPKgc-0008N2-WC for rohc@ietf.org; Mon, 18 Sep 2006 11:05:31 -0400 Received: from mail.cogent-dsn.com ([62.254.246.43]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GPKgb-0003pt-MF for rohc@ietf.org; Mon, 18 Sep 2006 11:05:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Sep 2006 16:05:28 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Local state advertisements and the implementer's guide Thread-Index: AcbMMntX/6yF4222QlGcs8CbsV+G2gL7U87gALqmt6A= From: "Richard Price" To: "John Barber" , "Surtees, Abigail" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-Mailman-Approved-At: Tue, 19 Sep 2006 02:40:24 -0400 Cc: jdrosen@dynamicsoft.com, zhigang.c.liu@nokia.com, Gonzalo.Camarillo@ericsson.com, hans.hannu@ericsson.com, "Lajos Zaccomer \(IJ/ETH\)" , jan.christoffersson@ericsson.com, cabo@tzi.org Subject: [rohc] RE: Local state advertisements and the implementer's guide X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org >> My proposal for the implementer's guide is to clarify that: >>=20 >> *) For 'basic' RFC 3320 implementations locally available state is >> - not mapped to compartments >> - is local to the endpoint and persists for the duration=20 >> of the compartment >> - does not impact compartment SMS >>=20 > I agree with this. Though I see it as a correction rather than a > clarification. The concept of mapping locally available state items to = a > compartment is to my mind a mistake by the authors of RFC3320, a > confusion of a possible private implementation strategies with > definitions of externally visible behaviours. It would certainly be nice if the storage of all locally available state could be considered an implementation issue at the decompressor. In fact this was exactly how early versions of RFC3320 were intended to work. However, an objection was raised that memory-intensive mechanisms such = as shared mode would be throwing away a large amount of memory advertising states that the remote endpoint might not even want to use. In response, we added to RFC3320 a mechanism for storing locally available state = inside the UDVM's own per-compartment memory. This allowed implementations to use mechanisms like shared mode without worrying about wasting memory unnecessarily. I don't think we can put the above into the implementer's guide as a "clarification", as it would be a technical change to RFC3320 to delete the ability to use the per-compartment memory to store locally available states. But nothing stops us from getting rid of this mechanism in the next version of RFC3320 if it is determined that implementers do not wish to make use of it. >> Finally, if this clarification is made in the implementer's=20 >> guide, then it is only addressing general SigComp behaviour. =20 >> If a stronger promise of keeping state is wanted (e.g. beyond=20 >> the end of the compartment) then this can be specified in=20 >> 'Sigcomp for SIP' or other equivalent documents in the same=20 >> way as the minimum DMS or support of a dictionary is specified. > Going a bit off topic here, I'd just add that the authors of such > documents should not only specify requirements as to state items which > must mandatorily be made available for specific environments, but = should > also make it clear whether or not those state items need to be > advertised. E.g. "Sigcomp for SIP" says the SIP/SDP dictionary must > always be available but it isn't stated whether or not it also needs = to > be advertised or whether its presence should just be assumed. If an item of state is mandatory in a particular environment, its presence can by definition be assumed by the compressor. So there's no need to advertise the state - you can advertise it anyway but I can't see any benefit to doing this. Cheers, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Sep 19 02:40:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPZHO-0007Dp-KG; Tue, 19 Sep 2006 02:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPKf2-000884-1N for rohc@ietf.org; Mon, 18 Sep 2006 11:03:52 -0400 Received: from mail.cogent-dsn.com ([62.254.246.43]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GPKez-0003S3-GJ for rohc@ietf.org; Mon, 18 Sep 2006 11:03:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Sep 2006 16:03:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Local state advertisements and the implementer's guide Thread-Index: AcbMMntX/6yF4222QlGcs8CbsV+G2gO4yoBQ From: "Richard Price" To: "Surtees, Abigail" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 X-Mailman-Approved-At: Tue, 19 Sep 2006 02:40:24 -0400 Cc: jdrosen@dynamicsoft.com, zhigang.c.liu@nokia.com, Gonzalo.Camarillo@ericsson.com, hans.hannu@ericsson.com, "Lajos Zaccomer \(IJ/ETH\)" , jan.christoffersson@ericsson.com, John Barber , cabo@tzi.org Subject: [rohc] RE: Local state advertisements and the implementer's guide X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org > 2) Section 6.2 of RFC 3320 discusses mapping locally available state = to > a compartment. I believe that this concept (as specified in RFC 3320 > only) is not well-defined (e.g. does it count towards SMS, if so, how > does the I-bit work? If not, why define the use of minimum retention > priority?) =20 If locally available state is defined as being mapped to a compartment, then it does indeed count towards the SMS of the compartment. I believe that this is clear from point 5.) of Section 6.2 - as you noted, the state could not have a minimum retention priority otherwise. I don't see how Section 6.2 contradicts the definition of the I-bit, could you expand on this one? > Can anyone (authors?) explain to me the intention of this for a basic > (RFC 3320) implementation? The reason for providing this mechanism is purely to give implementers of shared mode the ability to optimise their memory usage, by allowing them to store their locally available state items in the same memory as is reserved for the compartment. If we did not have this mechanism then implementers of shared mode would need to store their locally available state items in separate memory, which could potentially be very inefficient as the total size of the locally available state items created by shared mode is equal to the uncompressed size of all messages transmitted in one direction. For a basic implementation of RFC3320 (not implementing shared mode), there is no impact save for the fact that the special state retention priority of 65535 is reserved and causes a decompression failure if the bytecode tries to use it. > If not, then I suggest that the clarification for the implementer's > guide is that the concept of mapping locally available state to a > compartment can only be considered as an implementation choice and one > that cannot interfere with the statements in (1), above. The only support required in RFC3320 is the special state retention priority. > A locally available state item that is advertised can be assumed to be > available for the lifetime of the compartment. Yes, given the caveat that if it is defined to be mapped to a = compartment as in shared mode, then it can be pushed out of the compartment's memory by other states. > (b) Endpoint-initiated acks (defined in Section 5.1.2 in RFC 3321) - > Endpoint B advertises the hash of a state item that Endpoint A has > requested B to create (within a compartment). Given these = discussions, > this does not seem to be a well-defined concept. There are various > possible interpretations at Endpoint A on receipt of the advertisement > from B: Once a state has been advertised to the compressor in a compartment, it must remain available to the compressor until the compartment closes or one of the following occurs: i) The state item is pushed out of the compartment's memory by other state items. ii) The compressor uses the I-bit to indicate that it no longer wants the state. RFC3321 should not contradict this! In particular, just advertising a state should not increase its lifetime, unless this is standardised somehow (e.g. in the SigComp/SIP draft). > (c) State lifetime extension (beyond compartment lifetime)=20 > (from section 6.2 of > = hc-sigcomp-sip-02.txt>) - >=20 > This is similar to endpoint initiated acks but this document specifies > that advertisements mean that the endpoint will keep the state for an > unspecified amount of time beyond the closure of the compartment. >=20 > Since this clearly overlaps with (b), I believe this concept is also = NOT > well defined. Indeed it isn't - more needs to be said on the lifetime of the state if it is greater than that of a compartment, or the relevant paragraph should be deleted. > My proposal for the implementer's guide is to clarify that: >=20 > *) For 'basic' RFC 3320 implementations locally available state is > - not mapped to compartments > - is local to the endpoint and persists for the duration of the > compartment > - does not impact compartment SMS Ok with the caveat that in order to support shared mode, the special state retention priority of 65535 must still be reserved by "basic" RFC3320 implementations, even if they happen to not create any locally available state that is mapped to a compartment. > *) SigComp 'extended' mechanisms may use state advertisements provided > that their use > is clearly defined and does not conflict with any other usage >=20 > - shared-mode is one such well-defined usage > (although its definition in a non-standards-track document is = still > rather odd!) The IETF provides "hooks" in RFC3320 to allow implementations to support shared mode, but does not standardise shared mode itself. > - endpoint initiated acknowledgements should be further clarified. >=20 > The suggested clarification for the advertisement semantics with = respect > to endpoint-initiated acks is as follows (this merges interpretations > ii) and iv); interpretation i) must always be valid): >=20 > "Where Endpoint A requests state creation at Endpoint B, Endpoint B = may > subsequently advertise the hash of the created state item to Endpoint = A. > This conveys to Endpoint A (i) that the state has been successfully > created within the compartment; and (ii) that the state will be > available for *at least* the lifetime of the state as defined by RFC > 3320. If the state is available at Endpoint B after it would be = deleted > from the compartment according to RFC 3320, then the state no longer > counts towards the SMS of the compartment. Since there is no = guarantee > of such state being available beyond its normally defined lifetime, > endpoints should only attempt to access the state where NACK is > available." >=20 > This seems to allow for all currently proposed behaviours and does not > conflict with the basic RFC 3320 definition. Sounds good. > Finally, if this clarification is made in the implementer's guide, = then > it is only addressing general SigComp behaviour. If a stronger = promise > of keeping state is wanted (e.g. beyond the end of the compartment) = then > this can be specified in 'Sigcomp for SIP' or other equivalent = documents > in the same way as the minimum DMS or support of a dictionary is > specified. >=20 > What do you think? =20 All fine, with the caveat that the special state retention priority of 65535 is still special in RFC3320. Cheers, Richard _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Sep 19 02:40:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPZHO-0007E5-Tl; Tue, 19 Sep 2006 02:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPLFf-0002Py-Kc for rohc@ietf.org; Mon, 18 Sep 2006 11:41:43 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPLFZ-0007GO-2c for rohc@ietf.org; Mon, 18 Sep 2006 11:41:43 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id k8IFT1Q01289 for ; Mon, 18 Sep 2006 16:29:01 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Sep 2006 16:40:35 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002DA880A@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Local state advertisements and the implementer's guide Thread-Index: AcbMMntX/6yF4222QlGcs8CbsV+G2gL7U87gALqmt6AACsntEA== From: "John Barber" To: "Richard Price" , "Surtees, Abigail" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-Mailman-Approved-At: Tue, 19 Sep 2006 02:40:25 -0400 Cc: jdrosen@dynamicsoft.com, zhigang.c.liu@nokia.com, Gonzalo.Camarillo@ericsson.com, hans.hannu@ericsson.com, "Lajos Zaccomer \(IJ/ETH\)" , jan.christoffersson@ericsson.com, cabo@tzi.org Subject: [rohc] RE: Local state advertisements and the implementer's guide X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org =20 > -----Original Message----- > From: Richard Price [mailto:Richard.Price@eads.com]=20 > Sent: 18 September 2006 16:05 > To: John Barber; Surtees, Abigail; rohc@ietf.org > Cc: Lajos Zaccomer (IJ/ETH); cabo@tzi.org;=20 > zhigang.c.liu@nokia.com; Gonzalo.Camarillo@ericsson.com;=20 > jan.christoffersson@ericsson.com; hans.hannu@ericsson.com;=20 > jdrosen@dynamicsoft.com > Subject: RE: Local state advertisements and the implementer's guide >=20 > >> My proposal for the implementer's guide is to clarify that: > >>=20 > >> *) For 'basic' RFC 3320 implementations locally available state is > >> - not mapped to compartments > >> - is local to the endpoint and persists for the duration of the=20 > >> compartment > >> - does not impact compartment SMS > >>=20 >=20 > > I agree with this. Though I see it as a correction rather than a=20 > > clarification. The concept of mapping locally available=20 > state items to=20 > > a compartment is to my mind a mistake by the authors of RFC3320, a=20 > > confusion of a possible private implementation strategies with=20 > > definitions of externally visible behaviours. >=20 > It would certainly be nice if the storage of all locally=20 > available state could be considered an implementation issue=20 > at the decompressor. In fact this was exactly how early=20 > versions of RFC3320 were intended to work. >=20 > However, an objection was raised that memory-intensive=20 > mechanisms such as shared mode would be throwing away a large=20 > amount of memory advertising states that the remote endpoint=20 > might not even want to use. In response, we added to RFC3320=20 > a mechanism for storing locally available state inside the=20 > UDVM's own per-compartment memory. This allowed=20 > implementations to use mechanisms like shared mode without=20 > worrying about wasting memory unnecessarily. I think this is unneccessary. An implementation would (even in the absence of such a mechanism) be free to use spare per-compartment memory for any purpose it sees fit, including shared-mode state items, so long as it makes this usage transparent to the other end of the conversation. Just because (for example) a SIGCOMP endpoint advertises 8K of SMS it does not necessarily mean that it needs to allocate 8K of memory permanently for each compartment and dedicate it exclusively to storing state items at the request of the remote. I would in fact guess that most implementations will choose to use a "new" or "malloc" for each state item and manage the SMS limits by summing their sizes. >=20 > I don't think we can put the above into the implementer's=20 > guide as a "clarification", as it would be a technical change=20 > to RFC3320 to delete the ability to use the per-compartment=20 > memory to store locally available states. But nothing stops=20 > us from getting rid of this mechanism in the next version of=20 > RFC3320 if it is determined that implementers do not wish to=20 > make use of it. >=20 > >> Finally, if this clarification is made in the implementer's guide,=20 > >> then it is only addressing general SigComp behaviour. > >> If a stronger promise of keeping state is wanted (e.g.=20 > beyond the end=20 > >> of the compartment) then this can be specified in 'Sigcomp=20 > for SIP'=20 > >> or other equivalent documents in the same way as the=20 > minimum DMS or=20 > >> support of a dictionary is specified. >=20 > > Going a bit off topic here, I'd just add that the authors of such=20 > > documents should not only specify requirements as to state=20 > items which=20 > > must mandatorily be made available for specific environments, but=20 > > should also make it clear whether or not those state items=20 > need to be=20 > > advertised. E.g. "Sigcomp for SIP" says the SIP/SDP dictionary must=20 > > always be available but it isn't stated whether or not it=20 > also needs=20 > > to be advertised or whether its presence should just be assumed. >=20 > If an item of state is mandatory in a particular environment,=20 > its presence can by definition be assumed by the compressor.=20 > So there's no need to advertise the state - you can advertise=20 > it anyway but I can't see any benefit to doing this. I agree with this interpretation but would like to see it made explicit in the relevant documents since I believe the contrary interpretation is also possible and this could cause difficulties in interoperability. >=20 > Cheers, >=20 > Richard >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Sep 19 02:40:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPZHO-0007DZ-9s; Tue, 19 Sep 2006 02:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GNutF-0007T2-8q for rohc@ietf.org; Thu, 14 Sep 2006 13:20:41 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GNutD-0003B4-QU for rohc@ietf.org; Thu, 14 Sep 2006 13:20:41 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id k8EH87Q04693 for ; Thu, 14 Sep 2006 18:08:08 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Sep 2006 18:19:42 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002D468BB@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Local state advertisements and the implementer's guide thread-index: AcbMMntX/6yF4222QlGcs8CbsV+G2gL7U87g From: "John Barber" To: "Surtees, Abigail" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Tue, 19 Sep 2006 02:40:25 -0400 Cc: jdrosen@dynamicsoft.com, zhigang.c.liu@nokia.com, richard.price@cogent-dsn.com, Gonzalo.Camarillo@ericsson.com, hans.hannu@ericsson.com, "Lajos Zaccomer \(IJ/ETH\)" , jan.christoffersson@ericsson.com, cabo@tzi.org Subject: [rohc] RE: Local state advertisements and the implementer's guide X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi, > My proposal for the implementer's guide is to clarify that: >=20 > *) For 'basic' RFC 3320 implementations locally available state is > - not mapped to compartments > - is local to the endpoint and persists for the duration=20 > of the compartment > - does not impact compartment SMS >=20 I agree with this. Though I see it as a correction rather than a clarification. The concept of mapping locally available state items to a compartment is to my mind a mistake by the authors of RFC3320, a confusion of a possible private implementation strategies with definitions of externally visible behaviours. > *) SigComp 'extended' mechanisms may use state advertisements=20 > provided that their use > is clearly defined and does not conflict with any other usage >=20 > - shared-mode is one such well-defined usage > (although its definition in a non-standards-track=20 > document is still rather odd!) >=20 > - endpoint initiated acknowledgements should be further clarified. >=20 > The suggested clarification for the advertisement semantics=20 > with respect to endpoint-initiated acks is as follows (this=20 > merges interpretations > ii) and iv); interpretation i) must always be valid): >=20 > "Where Endpoint A requests state creation at Endpoint B,=20 > Endpoint B may subsequently advertise the hash of the created=20 > state item to Endpoint A. > This conveys to Endpoint A (i) that the state has been=20 > successfully created within the compartment; and (ii) that=20 > the state will be available for *at least* the lifetime of=20 > the state as defined by RFC 3320. If the state is available=20 > at Endpoint B after it would be deleted from the compartment=20 > according to RFC 3320, then the state no longer counts=20 > towards the SMS of the compartment. Since there is no=20 > guarantee of such state being available beyond its normally=20 > defined lifetime, endpoints should only attempt to access the=20 > state where NACK is available." I'm happy with all of this. > Finally, if this clarification is made in the implementer's=20 > guide, then it is only addressing general SigComp behaviour. =20 > If a stronger promise of keeping state is wanted (e.g. beyond=20 > the end of the compartment) then this can be specified in=20 > 'Sigcomp for SIP' or other equivalent documents in the same=20 > way as the minimum DMS or support of a dictionary is specified. Going a bit off topic here, I'd just add that the authors of such documents should not only specify requirements as to state items which must mandatorily be made available for specific environments, but should also make it clear whether or not those state items need to be advertised. E.g. "Sigcomp for SIP" says the SIP/SDP dictionary must always be available but it isn't stated whether or not it also needs to be advertised or whether its presence should just be assumed. Regards, John _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Sep 19 02:40:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPZHO-0007Dh-Er; Tue, 19 Sep 2006 02:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPJDs-00007E-D9 for rohc@ietf.org; Mon, 18 Sep 2006 09:31:44 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPJDr-0001rk-6D for rohc@ietf.org; Mon, 18 Sep 2006 09:31:44 -0400 Received: by wx-out-0506.google.com with SMTP id t4so4464294wxc for ; Mon, 18 Sep 2006 06:31:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=Yo0Fu5O/Y6VYR9GDN9hW+eXz75R10PQCB1zpbgqXYKj6H9tbGLLY5BRC2wK6+VFxpj4WEG1e32/ZuOGCd9EDGAhduT7VLX4zTFN+6gp6Zmq2TcMWiMiIVckcAkXdqsNRsKM74WARvqakd5Ow9QxxzEzurtIPt89sb/YYLJG02ik= Received: by 10.70.83.4 with SMTP id g4mr20110389wxb; Mon, 18 Sep 2006 06:31:42 -0700 (PDT) Received: by 10.70.14.13 with HTTP; Mon, 18 Sep 2006 06:31:42 -0700 (PDT) Message-ID: <81d920d0609180631y78642389u909c2f07a9f14eff@mail.gmail.com> Date: Mon, 18 Sep 2006 19:01:42 +0530 From: "Rama Pradyumna" To: gganga@npd.hcltech.com, raghavendra.dp@globaledgesoft.com MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Tue, 19 Sep 2006 02:40:25 -0400 Cc: "rohc@ietf.org" , "rohc@DOMAIN.HIDDEN" Subject: [rohc] SigComp: Implementing SIP dictionary and UDVM bytecode X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2060551641==" Errors-To: rohc-bounces@ietf.org --===============2060551641== Content-Type: multipart/alternative; boundary="----=_Part_171028_1258308.1158586302452" ------=_Part_171028_1258308.1158586302452 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, This is Rama and I'm currently working on the SigComp module and my task is to implement the SIP dictionary, UDVM bytecode and the related interface functions. I do not have the clear idea of what functions these 2 tasks have got? While going through the ROHC mailing list, i got to know that you guys are also working on a similar task. Could you please help me with whatever information you can provide on this (Implementation of SIP dictionary and UDVM bytecode) ? Thank you very much in advance. Regards, -Rama ------=_Part_171028_1258308.1158586302452 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
This is Rama and I'm currently working on the SigComp module and my task is to implement the SIP dictionary, UDVM bytecode and the related interface functions.
 
I do not have the clear idea of what functions these 2 tasks have got? While going through the ROHC mailing list, i got to know that you guys are also working on a similar task. Could you please help me with whatever information you can provide on this (Implementation of SIP dictionary and UDVM bytecode) ?
 
Thank you very much in advance.
 
Regards,
-Rama
 
 
------=_Part_171028_1258308.1158586302452-- --===============2060551641== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============2060551641==-- From rohc-bounces@ietf.org Tue Sep 19 06:07:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPcVZ-0000vA-TA; Tue, 19 Sep 2006 06:07:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPcVY-0000uz-UG for rohc@ietf.org; Tue, 19 Sep 2006 06:07:16 -0400 Received: from smarthost.yourcomms.net ([195.8.160.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPcVX-0003QD-BJ for rohc@ietf.org; Tue, 19 Sep 2006 06:07:16 -0400 Received: from svr-exchange.avocado.emccsoft.com ([212.248.196.12]) by smarthost.yourcomms.net (8.11.7p3+Sun/8.11.6) with ESMTP id k8J9sjQ01399 for ; Tue, 19 Sep 2006 10:54:45 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Sep 2006 11:06:20 +0100 Message-ID: <22C8A0D5D5E095449AB509FE777B5F8002DA8CE0@svr-exchange.avocado.emccsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Local state advertisements and the implementer's guide Thread-Index: AcbMMntX/6yF4222QlGcs8CbsV+G2gL7U87gALqmt6AACsntEAAjpsVAAAJB2/A= From: "John Barber" To: "Richard Price" , "Surtees, Abigail" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Subject: [rohc] RE: Local state advertisements and the implementer's guide X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org =20 > -----Original Message----- > From: Richard Price [mailto:Richard.Price@eads.com]=20 > Sent: 19 September 2006 10:01 > To: John Barber; Surtees, Abigail; rohc@ietf.org > Cc: Lajos Zaccomer (IJ/ETH); cabo@tzi.org;=20 > zhigang.c.liu@nokia.com; Gonzalo.Camarillo@ericsson.com;=20 > jan.christoffersson@ericsson.com; hans.hannu@ericsson.com;=20 > jdrosen@dynamicsoft.com > Subject: RE: Local state advertisements and the implementer's guide >=20 > >> It would certainly be nice if the storage of all locally available=20 > >> state could be considered an implementation issue at the=20 > >> decompressor. In fact this was exactly how early versions=20 > of RFC3320=20 > >> were intended to work. > >>=20 > >> However, an objection was raised that memory-intensive mechanisms=20 > >> such as shared mode would be throwing away a large amount=20 > of memory=20 > >> advertising states that the remote endpoint might not even want to=20 > >> use. In response, we added to RFC3320 a mechanism for=20 > storing locally=20 > >> available state inside the UDVM's own per-compartment memory. This=20 > >> allowed implementations to use mechanisms like shared mode without=20 > >> worrying about wasting memory unnecessarily. >=20 > > I think this is unneccessary. An implementation would (even in the=20 > > absence of such a mechanism) be free to use spare per-compartment=20 > > memory for any purpose it sees fit, including shared-mode=20 > state items,=20 > > so long as it makes this usage transparent to the other end=20 > of the conversation. > > Just because (for example) a SIGCOMP endpoint advertises 8K=20 > of SMS it=20 > > does not necessarily mean that it needs to allocate 8K of memory=20 > > permanently for each compartment and dedicate it exclusively to=20 > > storing state items at the request of the remote. I would in fact=20 > > guess that most implementations will choose to use a "new"=20 > or "malloc"=20 > > for each state item and manage the SMS limits by summing=20 > their sizes. >=20 > The problem with this approach is that once a locally=20 > available state item is offered, in general it must remain=20 > available for the duration of the compartment. This is fine=20 > for items like the static dictionary, which are shared=20 > between many compartments, but in the case of shared mode=20 > there is a large amount of per-compartment state that might=20 > end up just lying around in the memory. We need a method for=20 > bounding the total per-compartment memory that the=20 > decompressor must make available, otherwise it will end up=20 > needing to store the full 8K SMS, plus all of the shared mode=20 > states as well (which could easily dwarf the 8K SMS if left=20 > unbounded). > OK. I think you've just explained the true purpose of the distinction between per-compartment mapping and non-per-compartment mapping of state items. It's a distinction in the lifetime for which the state item is guaranteed to remain available and hence is indeed a part of the contract between the endpoints and not just an implementation detail. Unfortunately, this is not actually stated in the SIGCOMP RFC: 1) You state that a locally available state item must in general remain available for the duration of the compartment. I don't think the RFC actually states this. It could equally be assumed that locally available state items are permanently available, even surviving the closing of the compartment (greater persistence than stated by you) or that they are available only for the current message (less persistence than stated by you.) 2) The SIGCOMP RFC itself does not provide a means for an endpoint to know which lifetime applies to any given locally available state item advertised by the remote. This makes it essential for the whichever document specifies the usage of the locally available state item to state which type of mapping must be used. I believe this is well-defined for shared mode operation in RFC3321. But the SIP/SIGCOMP document for example needs to explicitly state that the SIP/SIGCOMP static dictionary must be mapped on a non-per-compartment basis and therefore not risk being pushed out of state memory by state items created at the request of the UDVM code running in the decompressor. This area has caused considerable confusion in interpretation. See for example the following thread: http://www1.ietf.org/mail-archive/web/rohc/current/msg04176.html =20 > > I agree with this interpretation but would like to see it made=20 > > explicit in the relevant documents since I believe the contrary=20 > > interpretation is also possible and this could cause=20 > difficulties in interoperability. >=20 > I don't see any problems with this - it costs nothing to=20 > clarify that a particular locally available state item is=20 > mandatory and therefore does not need to be advertised. >=20 > Cheers, >=20 > Richard >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Sep 19 12:08:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPi8h-0007xF-HA; Tue, 19 Sep 2006 12:08:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPi8f-0007x6-Sl for rohc@ietf.org; Tue, 19 Sep 2006 12:08:01 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPi8d-00068U-LG for rohc@ietf.org; Tue, 19 Sep 2006 12:08:01 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k8JG7M7X027488; Tue, 19 Sep 2006 17:07:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Sep 2006 17:07:22 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Local state advertisements and the implementer's guide Thread-Index: AcbMMntX/6yF4222QlGcs8CbsV+G2gO4yoBQADjX//A= From: "Surtees, Abigail" To: "Richard Price" , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: John Barber Subject: [rohc] RE: Local state advertisements and the implementer's guide X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi Richard, Thanks for your response. I've replied to your orignal response, and probably won't reply directly to your exchange with John, but some of the information in it has been useful in writing this reply :-) =20 > -----Original Message----- > From: Richard Price [mailto:Richard.Price@eads.com]=20 > Sent: 18 September 2006 16:04 > Subject: RE: Local state advertisements and the implementer's guide >=20 > > 2) Section 6.2 of RFC 3320 discusses mapping locally=20 > available state=20 > > to a compartment. I believe that this concept (as specified in RFC=20 > > 3320 > > only) is not well-defined (e.g. does it count towards SMS,=20 > if so, how=20 > > does the I-bit work? If not, why define the use of minimum retention > > priority?) >=20 > If locally available state is defined as being mapped to a=20 > compartment, then it does indeed count towards the SMS of the=20 > compartment. I believe that this is clear from point 5.) of=20 > Section 6.2 - as you noted, the state could not have a=20 > minimum retention priority otherwise. >=20 > I don't see how Section 6.2 contradicts the definition of the=20 > I-bit, could you expand on this one? >=20 If you map state to the compartment, then it follows the normal deletion rules (according to SMS). In which case surely it should only be deleted according to those rules, so what does receiving the I-bit set mean/do? I guess, given a state model with Malloc as mentioned by John, you could delete the state and reclaim the memory if you received the I-bit set, but then you have two ways of deleting state which seems a bit dangerous to me. > > Can anyone (authors?) explain to me the intention of this=20 > for a basic=20 > > (RFC 3320) implementation? >=20 > The reason for providing this mechanism is purely to give=20 > implementers of shared mode the ability to optimise their=20 > memory usage, by allowing them to store their locally=20 > available state items in the same memory as is reserved for=20 > the compartment. If we did not have this mechanism then=20 > implementers of shared mode would need to store their locally=20 > available state items in separate memory, which could=20 > potentially be very inefficient as the total size of the=20 > locally available state items created by shared mode is equal=20 > to the uncompressed size of all messages transmitted in one direction. >=20 OK. > For a basic implementation of RFC3320 (not implementing=20 > shared mode), there is no impact save for the fact that the=20 > special state retention priority of 65535 is reserved and=20 > causes a decompression failure if the bytecode tries to use it. >=20 Almost (see below), but I agree that whatever you do, as a UDVM and as a compressor creating state you have to obey the rules of minimum retention priority. >=20 > > A locally available state item that is advertised can be=20 > assumed to be=20 > > available for the lifetime of the compartment. >=20 > Yes, given the caveat that if it is defined to be mapped to a=20 > compartment as in shared mode, then it can be pushed out of=20 > the compartment's memory by other states. >=20 But how does a base 3320 implementation receiving an advertisement know whether it's a piece of state that is available for the lifetime of a compartment or for less than that (as in shared mode). Conduct a (albeit slightly warped) thought experiment - an implementation receives an advert for state it knows nothing about and decides to find out what's in it, by requesting it in 128 byte chunks as requested feedback. The implementation knows the state is there (because it was advertised), but actually has no knowledge of its lifetime. Based on the information in your email and your email exchange with John, I think I would update my original proposal to be: *) For 'basic' RFC 3320 implementations the lifetime of locally available state is not defined; however, the implementation must take account of the rules for use of minimum retention priority. =20 *) If an implementation chooses to access a piece of state for which it received an advertisement that it doesn't recognise (where recognition can include determining that it's shared-mode state) must do so only with extreme caution (or NACK). *) Any use of locally available state must be clearly defined and not conflict with any other usage. *) The most basic use is the advertisement of a dictionary or piece of bytecode. These pieces of state are in general assumed to: - not be mapped to compartments - be local to the endpoint - persist for the duration of the compartment - not impact compartment SMS However, for a given piece of state the exact lifetime must be defined e.g. in public specifications such as SigComp for SIP or PoC to mandate SIP/SDP static dictionary or in implementation/operator documentation e.g. for advertisements of implementation/operator specific dictionaries/bytecode. *) SigComp 'extended' mechanisms may use state advertisements provided that their use is clearly defined and does not conflict with any other usage - shared-mode is one such well-defined usage (as defined in 3321 AND section 5.3 in the implementer's guide) - endpoint initiated acknowledgements should be further clarified. The suggested clarification for the advertisement semantics with respect to endpoint-initiated acks is as follows (this merges interpretations ii) and iv) from ; interpretation i) must always be valid): "Where Endpoint A requests state creation at Endpoint B, Endpoint B may subsequently advertise the hash of the created state item to Endpoint A. This conveys to Endpoint A (i) that the state has been successfully created within the compartment; and (ii) that the state will be available for *at least* the lifetime of the state as defined by RFC 3320. If the state is available at Endpoint B after it would be deleted from the compartment according to RFC 3320, then the state no longer counts towards the SMS of the compartment. Since there is no guarantee of such state being available beyond its normally defined lifetime, endpoints should only attempt to access the state where NACK is available." This seems to allow for all currently proposed behaviours and does not conflict with the basic RFC 3320 definition. What do you think? =20 It feels like we're getting closer. If we can conclude this, then I'll propose some text for the implementer's guide. Best regards, Abbie _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Sep 20 04:43:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPxfz-0004DP-AB; Wed, 20 Sep 2006 04:43:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPxfy-0004DK-MR for rohc@ietf.org; Wed, 20 Sep 2006 04:43:26 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPxfq-0005rB-27 for rohc@ietf.org; Wed, 20 Sep 2006 04:43:26 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 24D588E0001 for ; Wed, 20 Sep 2006 10:43:07 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 10:43:06 +0200 Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Sep 2006 10:43:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Sep 2006 10:43:04 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC050384D558@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0503165D65@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-rohc-rfc3095bis-framework thread-index: AcaYrFhjJb5z6OxhSom5EpWcRoxD7xD3yYTg From: "Lars-Erik Jonsson \(LU/EAB\)" To: X-OriginalArrivalTime: 20 Sep 2006 08:43:06.0445 (UTC) FILETIME=[CAEB2FD0:01C6DC90] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [rohc] Updating draft-ietf-rohc-rfc3095bis-framework X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org ROHCers, I'm in the process of updating the ROHC Framework draft, with the purpose of finalizing this document and making it ready for WGLC. We will probably keep the document within the WG at least until we feel comfortable with it in relation to the ROHCv2 profiles, but we should try to complete the formalities and reviews so that we can consider it "ready for submission to the IESG". The -01 revision included a proposed optional ROHC channel parameter with the purpose of communicating ooo depth.=20 > MAX_R_DEPTH: Nonnegative integer. Maximum reordering depth expected > between the compressor and the decompressor, when the link =B4 > supporting the RoHC channel cannot guarantee in-order delivery. If > MAX_R_DEPTH is negotiated to be 0, the channel is assumed not to > deliver packets to the decompressor in an order that differs for > the order the compressor sent them, per compressed flow (CID). > This parameter is optional. =20 This parameter has been questioned both because it makes an addition to the ROHC Framework, which we have said we will keep unchanged, and because it is unclear how the parameter can really be useful. Since it is not supposed to *negotiate* anything between compressor and decompressor, it seems to be more like the implementation parameters RFC 3095 defines for the compressor in its section 6.3.1. It is thus suggested not to keep this proposed channel parameter in the Framework draft for rev -02. However, in the same way as we have feedback options for LOSS and JITTER, it might be a good idea to discuss whether something similar should be added for observed reordering. But this is then a question for the profiles draft... Apart from the MAX_R_DEPTH option, I am not aware of any issues raised regarding the Framework draft, so now is time to speak up if you have any concerns. Rgds, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Sep 20 12:52:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ5JO-0004gI-PZ; Wed, 20 Sep 2006 12:52:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQ5JM-0004g8-Pc for rohc@ietf.org; Wed, 20 Sep 2006 12:52:37 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQ5JL-00055G-Qo for rohc@ietf.org; Wed, 20 Sep 2006 12:52:36 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k8KGpx3g011412; Wed, 20 Sep 2006 17:51:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Sep 2006 17:51:59 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Local state advertisements and the implementer's guide Thread-Index: AcbMMntX/6yF4222QlGcs8CbsV+G2gO4yoBQADjX//AAJW8NkAAQHEyA From: "Surtees, Abigail" To: "Richard Price" , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: John Barber Subject: [rohc] RE: Local state advertisements and the implementer's guide X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi Richard,=20 >=20 > Actually there are at least three - the compressor can also=20 > use STATE-FREE to explicitly delete individual state items=20 > that it no longer requires. >=20 > But remember that all of the lifetime control mechanisms=20 > (I-bit, compartment SMS, STATE-FREE etc.) just serve to offer=20 > hints to the decompressor that particular state items are no=20 > longer required. How these states are removed from physical=20 > memory is entirely up to the implementation. >=20 True.=20 > > But how does a base 3320 implementation receiving an advertisement=20 > > know whether it's a piece of state that is available for=20 > the lifetime=20 > > of a compartment or for less than that (as in shared mode). >=20 > It does not know, and nor should it care! It does need to know if it wants to access the state. >=20 > Shared mode has been carefully designed so that the states=20 > which it creates and saves have no impact on a compressor=20 > that does not implement shared mode. If the compressor=20 > receives advertisements for states that it doesn't recognise,=20 > it just assumes that they are for an optional mechanism that=20 > it doesn't support, and ignores the states completely. Yes, that's the assumption, but there's nothing that explicitly states that. >=20 > > Conduct a (albeit slightly warped) thought experiment - an=20 > > implementation receives an advert for state it knows=20 > nothing about and=20 > > decides to find out what's in it, by requesting it in 128=20 > byte chunks=20 > > as requested feedback. The implementation knows the state is there=20 > > (because it was advertised), but actually has no knowledge of its=20 > > lifetime. >=20 > Well, if the implementation wants to access a locally=20 > available state it doesn't understand, then it is perfectly=20 > able to do so. It will be rewarded with exactly what it=20 > should expect - some bytes it doesn't understand. >=20 > If it tries to access a locally available state that no=20 > longer exists, it will get a decompression failure - what=20 > else could it expect? >=20 Indeed. However, I think an explicit statement of this would be useful. > > Based on the information in your email and your email exchange with=20 > > John, I think I would update my original proposal to be: >=20 > > *) For 'basic' RFC 3320 implementations the lifetime of locally=20 > > available state is not defined; however, the implementation=20 > must take=20 > > account of the rules for use of minimum retention priority. >=20 > Yes. But in fact, all a basic implementation needs to do is=20 > to reserve the special state retention priority of 65535. If=20 > it hasn't implemented shared mode then at the decompressor it=20 > will never save any shared mode states so there is nothing=20 > else to do, and at the compressor it just needs to ignore any=20 > advertised shared mode states. It needs to ignore advertised states that it doesn't recognise (because it has no way of knowing whether they're shared mode or anything else!) >=20 > > *) If an implementation chooses to access a piece of state=20 > for which=20 > > it received an advertisement that it doesn't recognise (where=20 > > recognition can include determining that it's shared-mode=20 > state) must=20 > > do so only with extreme caution (or NACK). >=20 > Or we could just tell implementers not to do this! Why would=20 > they want to access states from mechanisms that they haven't=20 > implemented? I don't know (apart from my warped thought experiment of trying to find out what's in the state to use it in future, but it is somewhat cumbersome). However, there's nothing in RFC 3320 that explicitly states that an implementation shouldn't access state that has been advertised but about which it know nothing. >=20 > > *) Any use of locally available state must be clearly=20 > defined and not=20 > > conflict with any other usage. >=20 > Yes. >=20 > > *) The most basic use is the advertisement of a dictionary=20 > or piece of=20 > > bytecode. These pieces of state are in general assumed to: > > - not be mapped to compartments > > - be local to the endpoint > > - persist for the duration of the compartment > > - not impact compartment SMS >=20 > Yes. Note that if the state happens to be mandatory for all=20 > endpoints, its lifetime is infinite and it does not need to=20 > be advertised. Agreed. >=20 > > However, for a given piece of state the exact lifetime must=20 > be defined=20 > > e.g. in public specifications such as SigComp for SIP or PoC to=20 > > mandate SIP/SDP static dictionary or in implementation/operator=20 > > documentation e.g. for advertisements of implementation/operator=20 > > specific dictionaries/bytecode. >=20 > Yes. >=20 > > *) SigComp 'extended' mechanisms may use state=20 > advertisements provided=20 > > that their use > > is clearly defined and does not conflict with any other usage >=20 > Yes. >=20 > > - shared-mode is one such well-defined usage (as defined in 3321=20 > > AND section 5.3 in the implementer's guide) >=20 > Yes. >=20 > > - endpoint initiated acknowledgements should be further=20 > clarified. > >=20 > > The suggested clarification for the advertisement semantics with=20 > > respect to endpoint-initiated acks is as follows (this merges=20 > > interpretations > > ii) and iv) from > > ; > > interpretation i) must always be valid): > > > > > > "Where Endpoint A requests state creation at Endpoint B, Endpoint B=20 > > may subsequently advertise the hash of the created state=20 > item to Endpoint A. > > This conveys to Endpoint A (i) that the state has been successfully=20 > > created within the compartment; and (ii) that the state will be=20 > > available for *at least* the lifetime of the state as=20 > defined by RFC=20 > > 3320. If the state is available at Endpoint B after it would be=20 > > deleted from the compartment according to RFC 3320, then=20 > the state no=20 > > longer counts towards the SMS of the compartment. Since=20 > there is no=20 > > guarantee of such state being available beyond its normally defined=20 > > lifetime, endpoints should only attempt to access the state=20 > where NACK=20 > > is available." >=20 > Yes. Endpoint initiated acknowledgements do not change the=20 > lifetime of the state they advertise. No, your sentence above contradicts the clarification. An ack should not be assumed to change the lifetime of the state item but this is not precluded because it is a mechanism which is being considered for the SigComp for SIP draft. However, unless an implementation knows that the extended lifetime is in use then it can only assume that the advertisement is an ack that doesn't change the lifetime of the state item. >=20 > > This seems to allow for all currently proposed behaviours=20 > and does not=20 > > conflict with the basic RFC 3320 definition. > >=20 > > What do you think? =20 >=20 > Looking good so far. >=20 > > It feels like we're getting closer. If we can conclude this, then=20 > > I'll propose some text for the implementer's guide. >=20 > We'll also need to ensure that the upcoming SIP/SigComp draft=20 > contains all of the required normative text regarding the=20 > lifetime of the SIP- specific states (static dictionary!). >=20 And the lifetime extension use of the advertisement/endpoint initiated ack (if the authors decide to use this mechanism). Best regards, Abbie > Cheers, >=20 > Richard >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Sep 21 08:32:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQNjS-0002NE-VJ; Thu, 21 Sep 2006 08:32:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQNjR-0002Mc-L4 for rohc@ietf.org; Thu, 21 Sep 2006 08:32:45 -0400 Received: from rose.ctd.hcltech.com ([202.54.64.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQNjM-00030M-Ve for rohc@ietf.org; Thu, 21 Sep 2006 08:32:45 -0400 X-MessageTextProcessor: DisclaimIt (2.50.252) [HCL Technologies Limited] Content-Class: urn:content-classes:message Received: from Ganesh.ctd.hcltech.com ([202.54.64.2]) by rose.ctd.hcltech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Sep 2006 18:02:38 +0530 Received: by Ganesh.ctd.hcltech.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Sep 2006 18:02:38 +0530 Message-ID: <012301731C23DE4DBFE035647C68F1CC03F42413@sindhu.ctd.hcltech.com> From: "Gangadharan G - TLS,Chennai" To: Date: Thu, 21 Sep 2006 18:02:35 +0530 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-OriginalArrivalTime: 21 Sep 2006 12:32:38.0639 (UTC) FILETIME=[0632F7F0:01C6DD7A] X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [rohc] Compartment ID for SIP messages X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0602938719==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============0602938719== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6DD7A.0466F2C8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6DD7A.0466F2C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi All, =20 Is there any common procedure to generate Compartment-ID = for SIP Messages w.r.t Dialog/Transaction? =20 Thanks, Gangadharan. DISCLAIMER=20 The contents of this e-mail and any attachment(s) are confidential and = intended for the=20 named recipient(s) only. It shall not attach any liability on the = originator or HCL or its=20 affiliates. Any views or opinions presented in this email are solely = those of the author and=20 may not necessarily reflect the opinions of HCL or its affiliates. Any = form of reproduction,=20 dissemination, copying, disclosure, modification, distribution and / or = publication of this=20 message without the prior written consent of the author of this e-mail = is strictly=20 prohibited. If you have received this email in error please delete it = and notify the sender=20 immediately. Before opening any mail and attachments please check them = for viruses and=20 defect. ------_=_NextPart_001_01C6DD7A.0466F2C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
Hi=20 All,
 
       &nbs= p;    =20 Is there any common procedure to generate Compartment-ID for SIP = Messages w.r.t=20 Dialog/Transaction?
 
Thanks,
Gangadharan.
------_=_NextPart_001_01C6DD7A.0466F2C8-- --===============0602938719== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============0602938719==-- From rohc-bounces@ietf.org Thu Sep 21 09:16:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOPr-0003wl-OY; Thu, 21 Sep 2006 09:16:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQOPq-0003qo-Fi for rohc@ietf.org; Thu, 21 Sep 2006 09:16:34 -0400 Received: from web8712.mail.in.yahoo.com ([203.84.221.133]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GQOPh-0000X0-M7 for rohc@ietf.org; Thu, 21 Sep 2006 09:16:34 -0400 Received: (qmail 8743 invoked by uid 60001); 21 Sep 2006 13:16:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dcAjQVqlAZ0e3CBEC7JyhPVRtS0NJK11a5xCAm+pxRWpGGPWPDnbINKS30Zxh0xYuhNhJbVJ2by0isw/+U5Jf7plC6nNvM853l3EI3ZdjZxGGkxDzNHLWqNR44ob+IJkc992TL9pHFKKl94vTVU1uSttVq5lCQeUK3r5A0LTFVQ= ; Message-ID: <20060921131622.8741.qmail@web8712.mail.in.yahoo.com> Received: from [61.95.205.93] by web8712.mail.in.yahoo.com via HTTP; Thu, 21 Sep 2006 14:16:22 BST Date: Thu, 21 Sep 2006 14:16:22 +0100 (BST) From: gopal krishna To: rohc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [rohc] hi X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi This is krishna,i want to do project on "sigcomp". Any one can suggest me for implementation of "sigcomp" of "sip" messages ,what are the RFC's i have to go thoroughly (I studied 3320,3321,3485,3486) Thanks in advance, Regards krishna. __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Sep 22 19:04:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQu3i-0007Ar-FO; Fri, 22 Sep 2006 19:03:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GQu3h-00077u-BC for rohc@ietf.org; Fri, 22 Sep 2006 19:03:49 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GQu3e-0000RF-TK for rohc@ietf.org; Fri, 22 Sep 2006 19:03:49 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8MN3h8n006276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Sep 2006 16:03:44 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8MN3gGx024856; Fri, 22 Sep 2006 16:03:43 -0700 (PDT) Received: from NAEX09.na.qualcomm.com ([10.46.56.84]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Sep 2006 15:58:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] RoHCv2 and Timer-based compression of RTP Timestamp Date: Fri, 22 Sep 2006 15:58:11 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [rohc] RoHCv2 and Timer-based compression of RTP Timestamp Thread-Index: AcbYu0uMg+fhLSZZRlKwM0WY8ezqpQABI/5gAWxS5iAACjzVgA== From: "Kapoor, Rohit" To: "Ghyslain Pelletier \(LU/EAB\)" , X-OriginalArrivalTime: 22 Sep 2006 22:58:12.0242 (UTC) FILETIME=[94620720:01C6DE9A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: teemu.savolainen@nokia.com X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Ghyslain, RoHCers, Over the last few weeks, we have been doing simulations and analysis to evaluate the impact of not having timer-based compression on VoIP capacity of 3GPP2 systems. Our results show that for current 3GPP2 systems, VoIP capacity loss can be as much as 5%, while for future 3GPP2 systems (currently being standardized), the capacity loss is as much as 10% or higher. The main reason for such VoIP capacity loss comes from the fact that physical layer payloads are discrete, meaning sometimes even a single byte increment in size of compressed header can lead to a significant increase in the size of the physical layer payload used (with the spare octets being padded). On another note, RoHC v2 profiles do have advantages over RoHC v1 profiles for future 3GPP2 systems. Graceful handling of multiple IP headers is one example which can make v2 profiles very useful for future 3GPP2 systems. Given this, it seems like not having timer-based compression is just reducing the "usefulness" of v2 profiles. It is likely that for 3GPP2 to migrate to RoHC v2 profiles in the future, timer-based compression would be a big factor, since VoIP capacity loss of 10% is considered extremely significant. Thus, we strongly support the inclusion of timer-based compression in RoHC v2 profiles. Thanks, Rohit > -----Original Message----- > From: Ghyslain Pelletier (LU/EAB) [mailto:ghyslain.pelletier@ericsson.com] > Sent: Friday, September 15, 2006 5:22 AM > To: teemu.savolainen@nokia.com; rohc@ietf.org > Subject: RE: [rohc] RoHCv2 and Timer-based compression of RTP Timestamp >=20 > Teemu, >=20 > The technical merits of timer-based compression, and whether to include > it or not in RoHCv2, have already been discussed on the list and at the > Montreal meeting. >=20 > As you know, everything sent to the list gets archived! >=20 > The last mail on this thread is found at the following link: > http://www1.ietf.org/mail-archive/web/rohc/current/msg04408.html > You can start from there and make your way back through the discussion. >=20 > I have also summarized pros and cons of having timer-based compression > in RoHCv2 in my presentation at the MTL meeting: > http://www3.ietf.org/proceedings/06jul/slides/rohc-2/sld41.htm >=20 > My understanding is that so far the consensus leans towards not to > support tbc in RoHCv2. Personnally, based on the technical discussion, I > am happy with this consensus. In our original individual submission, > which later got accepted as a wg document, we consciously made the > proposal wihtout supporting tbc so it is not something that was > "forgotten". >=20 > Regards, >=20 > ///Ghyslain >=20 > teemu.savolainen@nokia.com wrote: > > Hi, > > > > I looked at draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt > > and I couldn't find any mention about "Timer-based > > compression of RTP Timestamp" (as in chapter 4.5.4 in RFC3095). > > > > I wonder why it is not there? > > > > Thanks, > > > > Teemu > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc >=20 >=20 > _______________________________________________ > 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 rohc-bounces@ietf.org Mon Sep 25 02:44:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRkBw-0005Mb-H0; Mon, 25 Sep 2006 02:43:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRkBv-0005MT-Sh for rohc@ietf.org; Mon, 25 Sep 2006 02:43:47 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRkBp-00022O-EL for rohc@ietf.org; Mon, 25 Sep 2006 02:43:47 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F1E168E0001; Mon, 25 Sep 2006 08:43:05 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 08:41:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] RoHCv2 and Timer-based compression of RTP Timestamp Date: Mon, 25 Sep 2006 08:41:54 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0503889A38@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] RoHCv2 and Timer-based compression of RTP Timestamp thread-index: AcbYu0uMg+fhLSZZRlKwM0WY8ezqpQABI/5gAWxS5iAACjzVgAB0YXsA From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Kapoor, Rohit" , X-OriginalArrivalTime: 25 Sep 2006 06:41:55.0655 (UTC) FILETIME=[B1416D70:01C6E06D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Rohit, > Ghyslain, RoHCers, >=20 > Over the last few weeks, we have been doing simulations and > analysis to evaluate the impact of not having timer-based > compression on VoIP capacity of 3GPP2 systems.=20 Thanks for doing these studies, it is indeed good to get some concrete arguments in favor of TBC, up until now I think all arguments pro-TBC have been without backing. Your input is thus of great value. > Our results show that for current 3GPP2 systems, VoIP > capacity loss can be as much as 5%, while for future 3GPP2 > systems (currently being standardized), the capacity loss > is as much as 10% or higher. The main reason for such VoIP > capacity loss comes from the fact that physical layer > payloads are discrete, meaning sometimes even a single > byte increment in size of compressed header can lead to a > significant increase in the size of the physical layer > payload used (with the spare octets being padded). I will not question your results, just conclude that this is rather depressing news. It means systems are still not built for true IP networking, but with a circuit-based approach, optimizing for voice. I really thought that way of building network links was becoming history. Anyway, let's hear what others have to say about TBC for v2. Cheers, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Sep 25 03:13:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRkf5-0002jF-Ex; Mon, 25 Sep 2006 03:13:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRkf4-0002j7-3A for rohc@ietf.org; Mon, 25 Sep 2006 03:13:54 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRkex-00059L-Dn for rohc@ietf.org; Mon, 25 Sep 2006 03:13:54 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 868C48E0002; Mon, 25 Sep 2006 09:13:42 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 09:13:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] RoHCv2 and Timer-based compression of RTP Timestamp Date: Mon, 25 Sep 2006 09:13:46 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0503889AFF@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] RoHCv2 and Timer-based compression of RTP Timestamp thread-index: AcbYu0uMg+fhLSZZRlKwM0WY8ezqpQABI/5gAWxS5iAACjzVgAB1kcOg From: "Ghyslain Pelletier \(LU/EAB\)" To: "Kapoor, Rohit" , X-OriginalArrivalTime: 25 Sep 2006 07:13:41.0888 (UTC) FILETIME=[21758000:01C6E072] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: teemu.savolainen@nokia.com X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Rohit, Thanks for the input, much appreciated! As said before, I am not against adding support for TBC, it needed a motivation and you seem to have provided it. Assuming that no one is against adding support for TBC to RoHCv2, we will then include it in the next update of the draft, as in my understanding many have raised this question and there seems to be a consensus shifting that way. Best regards, ///Ghyslain Kapoor, Rohit wrote: > Ghyslain, RoHCers, >=20 > Over the last few weeks, we have been doing simulations and > analysis to evaluate the impact of not having timer-based > compression on VoIP capacity of 3GPP2 systems. >=20 > Our results show that for current 3GPP2 systems, VoIP > capacity loss can be as much as 5%, while for future 3GPP2 > systems (currently being standardized), the capacity loss is > as much as 10% or higher. The main reason for such VoIP > capacity loss comes from the fact that physical layer > payloads are discrete, meaning sometimes even a single byte > increment in size of compressed header can lead to a > significant increase in the size of the physical layer > payload used (with the spare octets being padded). >=20 > On another note, RoHC v2 profiles do have advantages over > RoHC v1 profiles for future 3GPP2 systems. Graceful handling > of multiple IP headers is one example which can make v2 > profiles very useful for future > 3GPP2 systems. Given this, it seems like not having > timer-based compression is just reducing the "usefulness" of v2 > profiles.=20 >=20 > It is likely that for 3GPP2 to migrate to RoHC v2 profiles in > the future, timer-based compression would be a big factor, > since VoIP capacity loss of 10% is considered extremely > significant. Thus, we strongly support the inclusion of > timer-based compression in RoHC v2 profiles. >=20 > Thanks, > Rohit >=20 >> -----Original Message----- >> From: Ghyslain Pelletier (LU/EAB) > [mailto:ghyslain.pelletier@ericsson.com] >> Sent: Friday, September 15, 2006 5:22 AM >> To: teemu.savolainen@nokia.com; rohc@ietf.org >> Subject: RE: [rohc] RoHCv2 and Timer-based compression of RTP >> Timestamp=20 >>=20 >> Teemu, >>=20 >> The technical merits of timer-based compression, and whether to >> include it or not in RoHCv2, have already been discussed on the list >> and at the Montreal meeting.=20 >>=20 >> As you know, everything sent to the list gets archived! >>=20 >> The last mail on this thread is found at the following link: >> http://www1.ietf.org/mail-archive/web/rohc/current/msg04408.html >> You can start from there and make your way back through the >> discussion.=20 >>=20 >> I have also summarized pros and cons of having timer-based >> compression in RoHCv2 in my presentation at the MTL meeting: >> http://www3.ietf.org/proceedings/06jul/slides/rohc-2/sld41.htm >>=20 >> My understanding is that so far the consensus leans towards not to >> support tbc in RoHCv2. Personnally, based on the technical > discussion, > I >> am happy with this consensus. In our original individual submission, >> which later got accepted as a wg document, we consciously made the >> proposal wihtout supporting tbc so it is not something that was >> "forgotten".=20 >>=20 >> Regards, >>=20 >> ///Ghyslain >>=20 >> teemu.savolainen@nokia.com wrote: >>> Hi, >>>=20 >>> I looked at draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt >>> and I couldn't find any mention about "Timer-based compression of >>> RTP Timestamp" (as in chapter 4.5.4 in RFC3095). >>>=20 >>> I wonder why it is not there? >>>=20 >>> Thanks, >>>=20 >>> Teemu >>>=20 >>> _______________________________________________ >>> Rohc mailing list >>> Rohc@ietf.org >>> https://www1.ietf.org/mailman/listinfo/rohc >>=20 >>=20 >> _______________________________________________ >> 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 rohc-bounces@ietf.org Mon Sep 25 08:12:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRpKF-00068H-MV; Mon, 25 Sep 2006 08:12:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRpKE-000688-6r for rohc@ietf.org; Mon, 25 Sep 2006 08:12:42 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRpK8-0008Rn-F2 for rohc@ietf.org; Mon, 25 Sep 2006 08:12:42 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F204D8E0001 for ; Mon, 25 Sep 2006 14:12:17 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 14:12:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Sep 2006 14:12:14 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC050388A062@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPsec Processing & HCoIPsec thread-index: AcbddQic7TPTglhFSRqJFieJIp3gBAAzZ4XgAJY5ivA= From: "Lars-Erik Jonsson \(LU/EAB\)" To: X-OriginalArrivalTime: 25 Sep 2006 12:12:15.0047 (UTC) FILETIME=[D688A570:01C6E09B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Subject: [rohc] FW: IPsec Processing & HCoIPsec X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Forwarded from the hcoipsec mail list. Please direct also further discussions of these issues to the ROHC WG mail list. /L-E ----Original Message---- From: owner-hcoipsec@mail.vpnc.org [mailto:owner-hcoipsec@mail.vpnc.org] On Behalf Of Jasani Rohan Sent: den 22 september 2006 19:41 To: hcoipsec@vpnc.org; Stephen Kent; Tero Kivinen Cc: Ertekin Emre Subject: RE: IPsec Processing & HCoIPsec All: I should have started this discussion on the HCoIPsec mailer list, so I'm now including it on the list. To get others up to speed on the discussion I've included a brief synopsis of previous emails. Synopsis: I originally emailed Stephen and Tero, to gather their thoughts on leveraging a generic IANA value to indicate whether a packet contains compressed headers. Stephen expressed that it is going to be hard to get an IANA value allocated from the Protocol ID registry and that this could cause delays. Subsequently, other approaches to achieve the same functionality started to be discussed (approaches described below). Currently, we are discussing Approaches 3 & 4. Note that Approach 4 has already been debated early on during initial development of HCoIPsec and was not pursued. Stephen and Tero, do you have any concerns with Approach 3 ? If so, could you explain some of you thoughts. I have some concerns with Approach 4. The first being the additional overhead of having to establish an additional SA for each HC-enabled SA. This can be a problem for resource constrained devices (i.e. 6lowPAN), that want to minimize the number of SAs they have to establish. The second being that now SAs are being generated not solely based on security policy, but now partly based on the capabilities of the compressor/decompressor (i.e. based on which types of traffic the compressor/decompressor supports). APPROACH 1: Allocation of a Generic Compressed Headers IANA Value + A generic Compressed Headers IANA value will be allocated from the Protocol ID Registry and will be used to indicate that payload contains compressed headers. + The main drawback is the hurdle of getting a IANA value, which can cause delays and may not even get allocated. APPROACH 2: Leverage the "uncompressed" profile as a marker + For ROHC, currently a packet that is ROHC compressed has a ROHC header with a Profiles field. This field will have a value, known as the "uncompressed" profile, that indicates that the payload of the ROHC compressed packet is not compressed. Therefore, this value could be used to signal to the decompressor that it should not decompress the packet.=20 + For ECRTP, currently a 1-byte shim header will need to be inserted to identify the different ECRTP packet types. The 1-byte header will be extended to contain a value, which we will call the "uncompressed" profile. This functions exactly as the ROHC "uncompressed" profile value. + The main drawback is that packets traversing an HC-enabled SA that are uncompressed will now have an additional few bytes used to indicate that the packet is uncompressed. + In the past, HCoIPsec community members have debated this approach against Approach 1 due to the efficiency tradeoffs. Due to concerns of efficiency voiced by ROHC WG & 6lowPAN WG members, through consensus Approach 1 became the preferred approach. =20 APPROACH 3: Negotiate a Compressed Headers Protocol ID value local to each SA=20 + When each SA is established, a value agreed upon by the peers is negotiated. This value will be analogous to the "Compressed Headers" value and will provide the same functionality and will be used in the similarly during processing. + Since, the ESP/AH next header value is "local to the IPsec devices", meaning that no intermediate nodes rely on the contents of this field, it should be fine to use a negotiated value. APPROACH 4: Leverage 2 SAs, 1 for uncompressed traffic and one for compressed traffic If ROHC is negotiated for the IPsec SA then all packets MUST be compressed and decompressed when sent over that IPsec SA. For those packets that do not compress at all we create another IPsec SA with identical selectors, but without ROHC, and that will be used to send those packets which cannot be compressed. This will add overhead of one extra SA, but this could be used to allow running those profiles which do not have special "uncompressed" profile defined without any modification, i.e. no need to add extra 1-byte shim header or anything like that. I.e. that is variation of the Approach 2, but in such way that there is no need to add extra headers and using extra bytes to indicate that traffic is uncompressed. If the profile already has some other header which can be used to indicate whether the packet is compressed or not (i.e. the profile field in the ROHC header) then there is no need to create that extra IPsec SA.=20 Rohan Jasani Booz | Allen | Hamilton 703.984.0337 (office) 832.452.3241 (mobile) =20 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@safenet-inc.com]=20 > Sent: Wednesday, September 20, 2006 10:45 AM > To: Jasani Rohan > Cc: Stephen Kent; Ertekin Emre > Subject: RE: IPsec Processing & HCoIPsec >=20 > Jasani Rohan writes: > > Stephen: > > Thanks for clarifying some of the "undocumented" aspects of the=20 > > allocation process :) I definitely understand your concerns, as we=20 > > too would like to prevent any delays in HCoIPsec development. We=20 > > definitely want bring consensus on the HCoIPsec approaches with you=20 > > and the various other community members. I've reiterated the=20 > > approaches we've discussed below to make sure we are on the=20 > same page=20 > > and added a new approach that provides similar=20 > functionality, however, through an alternate mechanism. > > What are your thoughts on Approach 3 ? >=20 > I have one more option: >=20 > Approach 4: If ROHC is negotiated for the IPsec SA then all=20 > packets MUST be compressed and decompressed when sent over=20 > that IPsec SA. For those packets that do not compress at all=20 > we create another IPsec SA with identical selectors, but=20 > without ROHC, and that will be used to send those packets=20 > which cannot be compressed. This will add overhead of one=20 > extra SA, but this could be used to allow running those=20 > profiles which do not have special "uncompressed" profile=20 > defined without any modification, i.e. no need to add extra=20 > 1-byte shim header or anything like that. >=20 > I.e. that is variation of the Approach 2, but in such way=20 > that there is no need to add extra headers and using extra=20 > bytes to indicate that traffic is uncompressed. If the=20 > profile already has some other header which can be used to=20 > indicate whether the packet is compressed or not (i.e. the=20 > profile field in the ROHC header) then there is no need to=20 > create that extra IPsec SA.=20 > -- > kivinen@safenet-inc.com >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Sep 25 08:14:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRpLV-0006qc-4W; Mon, 25 Sep 2006 08:14:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRpLT-0006nU-As for rohc@ietf.org; Mon, 25 Sep 2006 08:13:59 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRpLS-0000Bz-Kn for rohc@ietf.org; Mon, 25 Sep 2006 08:13:59 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0CE4B8E0002 for ; Mon, 25 Sep 2006 14:13:58 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 14:13:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Sep 2006 14:13:56 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC050388A06A@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: IPsec Processing & HCoIPsec thread-index: AcbgjIqeoB13slcLQ2irc5a+vcZSrQAD1New From: "Lars-Erik Jonsson \(LU/EAB\)" To: X-OriginalArrivalTime: 25 Sep 2006 12:13:57.0653 (UTC) FILETIME=[13B11450:01C6E09C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Subject: [rohc] FW: RE: IPsec Processing & HCoIPsec X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Forwarded from the hcoipsec mail list. Please direct also further discussions of these issues to the ROHC WG mail list. /L-E ----Original Message---- From: owner-hcoipsec@mail.vpnc.org [mailto:owner-hcoipsec@mail.vpnc.org] On Behalf Of Tero Kivinen Sent: den 25 september 2006 12:22 To: Jasani Rohan Cc: hcoipsec@vpnc.org; Stephen Kent; Ertekin Emre Subject: RE: IPsec Processing & HCoIPsec Jasani Rohan writes: > Synopsis: > I originally emailed Stephen and Tero, to gather their thoughts on > leveraging a generic IANA value to indicate whether a packet contains > compressed headers. Stephen expressed that it is going to be hard to > get an IANA value allocated from the Protocol ID registry and that this > could cause delays. Subsequently, other approaches to achieve the same > functionality started to be discussed (approaches described below). > Currently, we are discussing Approaches 3 & 4. Note that Approach 4 has > already been debated early on during initial development of HCoIPsec and > was not pursued. >=20 > Stephen and Tero, do you have any concerns with Approach 3 ? If so, > could you explain some of you thoughts. >=20 > I have some concerns with Approach 4. The first being the additional > overhead of having to establish an additional SA for each HC-enabled SA. > This can be a problem for resource constrained devices (i.e. 6lowPAN), > that want to minimize the number of SAs they have to establish. The > second being that now SAs are being generated not solely based on > security policy, but now partly based on the capabilities of the > compressor/decompressor (i.e. based on which types of traffic the > compressor/decompressor supports). Actually now after thinking about the issue a bit, I do not think the Approach 4 fits at all on the IPsec architecture. The problem there is that the architecture with IPsec and ROHC is like this: Unprotected Interface ^ | (nested SAs)+----------+ ------------|Forwarding|<---------------------------+ | +----------+ | | ^ | | | BYPASS | V +-----+ +=3D=3DPROCESS = AH/ESP=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D+ +-------+ | SPD | | +------+ +--------+ +-------+ | .| SPD-I |.........|Cache|..|..|Tunnel|..| ROCH |..| ESP |..|..IPsec | (*) | | (*) |---->|encaps|->|compress|->|Encrypt| | boundary +-------+ +-----+ | +------+ +--------+ +-------+ | | +-------+ / ^ = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | |DISCARD|<--/ | | +-------+ | | | | +-------------+ |--------->|SPD Selection| +-------------+ ^ | +------+ | -->| ICMP | | / +------+ |/ | | Protected Interface I.e. after the SPD Cache is used to select the SA we go through the ROHC processing, and then ESP encryption. The problem is that we have already selected SA when we enter the ROCH processing, so we cannot change it anymore. So I think the approach 4 does not really fit the architecture and should be rejected because of that. There is no problem on the inbound case, only in this outbound case.=20 > APPROACH 1: Allocation of a Generic Compressed Headers IANA Value > + A generic Compressed Headers IANA value will be allocated from the > Protocol ID Registry and will be used to indicate that payload contains > compressed headers. > + The main drawback is the hurdle of getting a IANA value, which can > cause delays and may not even get allocated. I actually still think this is the best approach, even when it means that we need to one protocol ID number from IANA. > APPROACH 2: Leverage the "uncompressed" profile as a marker > + For ROHC, currently a packet that is ROHC compressed has a ROHC header > with a Profiles field. This field will have a value, known as the > "uncompressed" profile, that indicates that the payload of the ROHC > compressed packet is not compressed. Therefore, this value could be > used to signal to the decompressor that it should not decompress the > packet.=20 > + For ECRTP, currently a 1-byte shim header will need to be inserted to > identify the different ECRTP packet types. The 1-byte header will be > extended to contain a value, which we will call the "uncompressed" > profile. This functions exactly as the ROHC "uncompressed" profile > value. > + The main drawback is that packets traversing an HC-enabled SA that are > uncompressed will now have an additional few bytes used to indicate that > the packet is uncompressed. > + In the past, HCoIPsec community members have debated this approach > against Approach 1 due to the efficiency tradeoffs. Due to concerns of > efficiency voiced by ROHC WG & 6lowPAN WG members, through consensus > Approach 1 became the preferred approach. =20 >=20 > APPROACH 3: Negotiate a Compressed Headers Protocol ID value local to > each SA=20 > + When each SA is established, a value agreed upon by the peers is > negotiated. This value will be analogous to the "Compressed Headers" > value and will provide the same functionality and will be used in the > similarly during processing. > + Since, the ESP/AH next header value is "local to the IPsec devices", > meaning that no intermediate nodes rely on the contents of this field, > it should be fine to use a negotiated value. The problem this approach is that it is complicated and can cause some problems as it will always limit one protocol value from the SA. i.e. if the SA has traffic selectors of the any protocol <-> any protocol, then we need to pick one protocol number which is reserved for this "compressed headers" value, and how we make sure we do not pick some number that might actually be used by the traffic. The easiest way to make sure of that would be to reserve number from IANA, i.e. back to approach 1... > APPROACH 4: Leverage 2 SAs, 1 for uncompressed traffic and one for > compressed traffic > If ROHC is negotiated for the IPsec SA then all packets MUST be > compressed and decompressed when sent over that IPsec SA. For those > packets that do not compress at all we create another IPsec SA with > identical selectors, but without ROHC, and that will be used to send > those packets which cannot be compressed. This will add overhead of one > extra SA, but this could be used to allow running those profiles which > do not have special "uncompressed" profile defined without any > modification, i.e. no need to add extra 1-byte shim header or anything > like that. I.e. that is variation of the Approach 2, but in such way > that there is no need to add extra headers and using extra bytes to > indicate that traffic is uncompressed. If the profile already has some > other header which can be used to indicate whether the packet is > compressed or not (i.e. the profile field in the ROHC header) then there > is no need to create that extra IPsec SA.=20 As I explained earlier, that this does not really fit to the IPsec architecture.=20 --=20 kivinen@safenet-inc.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Sep 25 08:24:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRpVl-000356-6R; Mon, 25 Sep 2006 08:24:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRpVj-0002zb-Ic for rohc@ietf.org; Mon, 25 Sep 2006 08:24:35 -0400 Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRpVh-00010y-0e for rohc@ietf.org; Mon, 25 Sep 2006 08:24:35 -0400 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id F1EE9205ED for ; Mon, 25 Sep 2006 17:49:48 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id D2C50205E3 for ; Mon, 25 Sep 2006 17:49:48 +0530 (IST) Received: from blr-itp-msg.wipro.com ([10.185.50.99]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 17:54:18 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Sep 2006 17:54:06 +0530 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Interoperability Event Thread-Index: AcbgnX6V/GSKUvTXRmmIJJkY0ETnrw== From: To: X-OriginalArrivalTime: 25 Sep 2006 12:24:18.0125 (UTC) FILETIME=[858597D0:01C6E09D] X-Spam-Score: 1.7 (+) X-Scan-Signature: 23336e92cd9b2f166f17126afcdd84ec Subject: [rohc] Interoperability Event X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1385905613==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============1385905613== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C6E09D.7E931AD1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E09D.7E931AD1 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C6E09D.7E931AD1" ------_=_NextPart_002_01C6E09D.7E931AD1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I would like to know whether there us any IOT Event planed for ROHC in the near future. Please let me know the details. =20 Sajeev Ramachandran Wipro Technologies Ltd., Bangalore. Mobile : (+91)-944-845-9717 Office : (+91)-(80)-28411990 Ext 1517 VoIP : 806-4259=20 =20 =20 ------_=_NextPart_002_01C6E09D.7E931AD1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nature
Hi=20 all,
 
I would like=20 to know whether there us any IOT Event planed for ROHC in the near = future.=20 Please let me know the details.
 
Sajeev=20 Ramachandran
Wipro Technologies Ltd., = Bangalore.
Mobile :=20 (+91)-944-845-9717
Office : (+91)-(80)-28411990 = Ext=20 1517
VoIP=20 : 806-4259 
 

------_=_NextPart_002_01C6E09D.7E931AD1-- ------_=_NextPart_001_01C6E09D.7E931AD1 Content-Type: image/gif; name="anabnr2.gif" Content-Transfer-Encoding: base64 Content-ID: <906442212@25092006-1B3A> Content-Description: anabnr2.gif Content-Location: anabnr2.gif R0lGODlhWAI8ANX/AMDAwP//zP//mf//Zv//M//M///MzP/Mmf/MZv/MM//MAP+ZzP+ZZv+ZM8z/ /8z/zMz/mcz/Zsz/M8zM/8zMzMzMmczMZszMM8zMAMyZ/8yZzMyZmcyZZsyZM8yZAMxmZsxmM8xm AJn/zJn/mZnM/5nMzJnMmZnMZpnMM5mZ/5mZzJmZmZmZZpmZM5mZAJlmZplmM5lmAGaZmWaZZgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAAAALAAAAABYAjwAQAb/QIBw SCwajwDBQclcOpsCpnQ5jVKp1ezVys1Gv+CwGByIlgXnshrNXrvbcLUcLQ/Y7/i8fs/v+/+AgYKD AQB3hoV2houJjI6NkIuShZNIlpeYmZqbnJ2en6ChoqOkpZpSSk5PT1oIFwOpXUt5WFplWwG1tWNs vQdpAgbBZnHFbmttdclzBgHNv87Rzc500dB504Taf9l23X2PeIbZ5Irm54iMkJHs6ZSUj0Lv8vRC BkIFDwAT+A4GDhMmBOBHIWDBggAKTlCoMKDDgBlUPCxIYkKJCRkmVDQYUEVDjhMdkvj4cALAfSYn PFjYUUMJFSpKHPQo06NFjR8rXqQw0mBM/5cAbBYsUJKgSZgeKbjUQNMlhZ9PmcJ8WsIphZ0LKVxl qvSpVo8el9ZUKlNDV61m03ZVy3YthaAlSlRQUaHEiqp1N5TYwIHFBhaAN1AwocHEVQ4WEiu2gPhX hcWLL1iQjEKy4seI6TygEICzgQePQ1uogDhxaciPE29QXBoz49EcRK9eLZrDCdgnSI9WbWH1it27 RQOvEDp34gon/iJXbgJzhQ2haRMfXYHF9OYVTMQOjZ06dejTn+cmbt1C8+7ZiadXv5449uYbmq9Q byI+8fnY2UOnwP6++//zZWdfBStgB0EFEAy2AQQMEsfggeo1iKCDAcx3IIMUCFBgZzIVuP9BgHZV MJgh/OwTAEADDeRAAQCtpBVLC/nDEkApHcQRQ0XlyNBIKmjgEAU0rvQQQDQaBJCNQy5EAldgHbTP ikeapNBLVN6kJE9QzRjQA0Ttg1RVP8Hkkk0TIDWVlEQ+tORLJDHEU0NafZUBBXNWpZRZbuWpVpwa pMUWAHXFlZ0JBc63wnx0qWCCCiyc0ChggMnQwQUdoDDpaaUdMA1nEBgw2aeTflpBZ7mQyhlnpHqa WmqLlRYbb309B9trpDnHGKuvrdZbcI+tFturugV73HTBFasedRxo9xwL26kXAYLUhRcae6NZ19xo 461q7LCk1becBQH2Bx57Ab5HH4Hrxbf/XbjoeosfdB/291655fpHqIAXQhCfAA4eCB2EyPkHXgne UlAufwYTF59eKwDgAAD6TMBiQFCqdGOMWxp5pZVRXozTRCnQCRKcJJSQAZhUeUUTSA+BKZHDTwq0 Ij8rwizEwwHFnJJDbMZk00AF+czmjyFdtBNYZKaZUpEWIeUSjUAaJFPISOOZFUtofXVW1m21pScA BMdpAsFyyUXYYHINNtgJJkDKAqUXcHBBAh10YEHdk046KmcCPFDqAQ8IQMEBj3ljqjMPNMMZaMPa ceodfnvm2quMWccBX7XuNhutwQGLWOayijZda9aVfhxtyTZL2m0TWsBvhMT2591j1hEI/9xrkHl+ XHmhi6uwegMOWF9+55HLHqQWMMtBbON6O+Fz+a0XPXjQ/dpXX4B10Fqtv/aqmui8gnveYNnxR+ii FQzBJZcVP1yQAzYWScFKm7kIo41vXpXSSvBbbBJRBuEJS0aypJGkYGgO6dj9WEKlMQltBXDiB81Y BEAaReklX+LKRZoWEy3pw2FG+siU3rezGllwIUkJyEaUdBOjzYlHT+lRXMRiMPzFiU8vOouftmYW QJWtLiIS0dgMYxjiyGR8Isqe9i5VN0rV7W6TkkwFDtCpvv2iigHoVOL4E4BRgaYzfQtA5DqjRcVx qla42pxtlveazyFmjawaHXG696rN0f+mN9P5zQliw4LjIGYDG7jNbPZ4nAPt5kDPchC1ngWBep3m Aq5QjGVYg5pZ8WpatcvcecJVoEyqx0PQI43ylNeXxTzmNrlJ0AZewAJWMouVrmSB9lrAghb0xZa2 PM6u2giZ3PUyMQiowAAsEExTjmY+ZptL+oTAJZhFzX0Ss1//NmMx+mHMmkDSn/5kQrEaWUkkO8If R6LUMRjeLGcDlMpF7LdABgbkIj0h4JtSQAKJWOSAMFmBCkvQkzdRDCU7SUGZ3vcRlEgwainUGJIU ApaqDC1oXsGTWQpwQxzeaS19ytNb0tM21jgqeYtxlKNq2Ue2nQBub7tAC5zIAcIZIEH/Bxgcv7rY xWaM6qXCyFDiEgc4A7y0M57pTOK05SpcGfUyfzTNrSyXmN/oZgWfcx2CCCcA11ngAM/i167AF61j hWdbihQNwLr6n2MCD1fEXAwCKGka0UWPPc16q3vs8xfsXc9tzBpp8k7A1+q8klmABQwHVuBK7Am2 sLjsQAsWq1i8ORZucmMrB+xmmWEOUzGXnRaB5vMhg9mHLhAkkKI0UCDS6mVh8oFACQ70ACIaLEEq WAFpVyAYEyQIYYFLwNwugAEPJAABA/AADFzggg7EoAUeqJsHWhAC5k7KAxeA7gWmWzfkTtcDMYhi AnSLt+ROirvTpS4LTmaB5LogvHSz/1sFfGQRnlQgihjYbQIg0EKNWAC5HSiueTVAAnrCJAUp0EAL osjbDniAA2LyCAdckNwKEO1NtQyBC+pykAALdFQCgNtug9kVrLllT1nDoQYSMh+xyYR8MklbdVAJ mNuY4KSgohQK7hu3lV4qbig4zX13zNbUGCA1g9tMZz5TASJ/xjM7/TGmOMeY3LwxNMuL1RvBpUsL DGAAELAABBJJnETqajzbASv4pDW70ACMPmUG1nPkSC24/ic75oHzm3tnrwGpjrPoIo9t8qxIgB2I tpCC5WEFHcsBEcgE8ikevQ5Vr9ToGDFr1bFi1qqYha2ALjUUDHEG4yFklpi2jE4UYf/qoyhFFWov jOasoq6iF8PIdlEW2kyhGL1MUyBhwQIYQAIEgIDHNsMQd0NAFAiQayfiNzbyiK727gZdeNgDbxeI At0GLGxLGECx6N11hptr4LntOgEtsIAQLJBdA+e3AwhwxhHK8Ji6xSC76ba1ra2wilVAYQta6IIV vIEKJdyiC8IYhr+lgIwxAIMYAR/GLc4Q8Dc4HA5xUMYdqhEIOkBjGs0IhuHyQPFteDwPiBCEOwJQ gDuQAxH3OEQi1hGPdjQiHJKohMzh4ex1y/vmOM+5znfO854XYQMHiHcm7E1vVOD7AAcgpmTAwAo6 IKLkXzi6LP5N8Kjz4uC/GDgaqFD/qod73esUp4PYo4EGYWy8GWZHe9mpYTiKf2Mb33i7IOT+h5BH Y+MA6EbI956OvrfcEYBvBz3mUQ/Al9xhEzvRP/JB0f4phH8BMYDHchSSAZJkgT3CkUJoVJF+hsTx /ZsIQBw6Jm4WhaBW2iBF2tteGeKo8lpyGVd89BWnYO0mpWcKjIpyEZcM9Cd2kiFXdMhD4mf0+GjB U1AOnZ2qoA8t8sGro1YAKcmchtKv+TG7JTndyURxMQdSnDPEL+Qx72bKfhQOG/vYmqTeynOg2+Wv epOcrfYxfF/V1qpER1dwpWc7WfY8ZNVm0qIw5uF/+1cr0BFnygIenoQu4NEc2fI7/+nBLtgRgWfF HolmH/jhH6BhL+1yMIbyOheCIH6mIRPiZ9BRRPXRaR8SW/diPh9SIPswBBOweCiCJgFkMeJEQC9R JhoQEWTSEFXREx2BQT5jFgmkEReBFFThMylDQhhTQibhABXzJB5Rgw+jhWmiNGBCJR2UMUuTEgkx Tj9SEUGzFABAFFzRhVFTEC8xJkiyMfxEAVSzJG/BIjZCemthJxfFFl3DQwDgWoj2HHKBaXHifCYw A23TKHx1UqEyXZNlN8s2GjQlDH5DRcJQAdRliYlTKj+FZMIwHFN0Vc+TKkL1Y5NDO230KtvhRsKh K9MRSOExWO+nG9zSR6LhSZozK//EUVVZBiHhszloRGb+YUyVBBwBkjrQMy4CUmf9MWfYwS5+tUeD woFr1h7mMlcrqI1CBCDRSGV35FTlcUfwNzyIZj4KIh/kM2IP00wUQEErsQ8rQRRucjXZJDXtVTKm RzEF4SJQAyNMI08kYEAvsSa+N4ZzCBKkRyVzaDNDUCQzc1ADRHph2BBCcFAfsRM6cSVksoREQSTy UyZgchOPFxBM4VAwEXxLcRV34mG0d0N74jUiBihEVBdjcxUiojaCQjZCVDly40R541hDORq/kHUZ kguOkUXiNziHAzhQ6Tef0Qx+I0bT4De4eBmWxBjaoZXVsVW7wjy7g0ZJ5T2pwzv/u/IbsKEutWId CGBIXVYBEYBVAahlFaBVdlmAaDQZrhBJbKVUYKlZvIIe40KLHNUuCxNnnEQg10NLUXZ/1JEg/pGN AUJ9sSRYzEJLsrSZxcIaukE5vbRkUpV0vQJEhlIXyHQzKSJBCVGD10Q0PNg/RwI/2TQSRmMR/PVM 7tMxUWN6EqECS6ICc5IxoUc0BLQyRRIXMYEkxblQFjQxaFgyCwGGCYaESeOPKBE1LBFb7dN4IZmP AKFPBmGEl/cjMwQVMtQkGXUQcUJRxbdDEhUnYNMcZTMY23gtqGQbLlYBI7ACJ7BYkwhFS3Q3cqM9 lnGXSTkqUWkAGdKgpjINN4U4/2bHU3HUmachi7xUR7TyOXN0K75BK1hmgsZSHGU2LLAxR18piw5S SKHxLBbAZamRAMRkN5P2KZD0KX/pGqIzLXgUjXMEKaWEmUEKL8sTWHi1V48yUm7zAqxkV4CFPbQE A9eTla6CO5IGmL+EABGQVhGgpUa1MOWDKNlRGNlhKJ51LxC0GfeCIKCxGRDwAB+4WibwAIfCHxBQ RKBhWxTAWhegX90llBzgbBYAAwPWAXUxAcxWN4IREAUAADElQV2UAAPQa8JlqFIBEJzoRCzgTgIE TyyUFAHFh7J0bv1okhYxWdl1IE1jQQixe1RBHNXlYAwhAIrFATzBFfVkFQkxJ/82RCchFogyyTUb VWLzg2hFdEqK8Yh8lax81X2SQSkntVKUAkVx80QIglPBUEVT+QAxJaFHdjhTua1TWRu+hBjspxu6 Yj1t2UakEVUCwEhzeWbFknSkKTuCOWbSApewMzu1kyxuph/rES1l1i6a9Va8E44oeoE+Wh220WKN 0jYnAFVQZaSG1ReFxQLUd1iBFkszACl5M62/ZKWLYVkhqxqHAkQqcFr1wR+IUh974WofMmqI0mrx USDowmiEcijx4hGh1RwGg2h2kTCeNiKg0EUVMGC7JV/TFV/PFV7RlmsGtlKwQF3JtV1zk1zK1l3m FgMugFzbpVvRlbUuAAOTslb/HVpdvuVExfVd0kU30MVdjiV0eUeURkmU1ZVdx5Vd3uVEF3AAGiap Mjqp6aZkrtNzRRcLiIt097a4ROcEE7cFR7dwAxdwVJBwWHC5ZsB1mstwFmcHxvC5cxBxc+C5hJBx GLd2Gnd32oB20tC6rMu6d4dxZwdyKqcOdscHeycOK+cO8vByLvd3wEt4NIcJNTcEhOdzyJu8yru8 zHtzi5tv9vYEa/W8leu5+CYL2FsFkmt0bJB1TJAGS5BwnttwoEsMozt2yyB2shu7bUe600AH3UB3 Hze/fTANeYcH2VBy64C7K6dyu/u7ANx3Lzdz9XC8Q3APa2gPJiKPFORhMWKP/wsBwZS3kJT3IwZV wRjcTRr8JBPzIxVVUVlRnpXXq+z5IiV0Eh58Q7eXQyr8wSEcwiDMwjD8wTRcwzZcwzinuNRrddEr o327w3agv/92BVRHuVyQC/vGdFa3vUbMueZrvmCHDKN7DBKXdtUAu2UQd3jQcd3QcYGgxfiLDbMr xvh7u3enDnpwuyMXwH8XwMcbCTInc/fgDziDgzj4jxwxEBLjPyKkI2dohxixQppnegL0ehyxQUyD xyKMQj5TJnqhPzcSkPBUECFzEz2xagoheYwqMRWTEkyRkhnxFLiJQXLohDvxhBtUNFIhfD3DJBIV fBilJ8KafEqhCV2EdEh3Cf9NBwVcEL1KN731Zga/1r+6gMRSYMQC57278L1al3VZl8VfQL5RXAxj d76kqwbva3a0kMVsZ7phjA1eHMbhvHEmR8b1ew78q79mDA60iw6C53Lw3Lu+W3hFAAkswkxruCL8 8w//kI+bFz8RBHvlSRJoeD/Dt3un13kss3kaLIWNnDRW+McxYTRY4RAeoROkJRH5WBJKE0OfDCZL 4TOXlpA5MQFjMsEP8dFg0ZKZpxaZN8sf9ocUYABqQWI/azBBaxixxR9GCliIUgKStRiJIwAQgH2f MmNO20uj4gx7wxlFRgFeiVSQcUd+REjyx6545H5R5YphCWVOpUscUJfa4h3/iXEgghQtl4MfvSEd qqOL1DIu1HGwmvUbC0iWARNn0QIeXdWN+QEevzE8/+HX/1E8eWYoBcNnAnKy7SE8xLEZBFKCoAEB WQQ7JoggdroCDZIgJlAhm6azLRgfx9owb7GG7DMQ/8DHjrdAFLyQC2WbKK1CEGUQMMNAHRRO4iQk ZChB/TMmUIJ4Y2iFDVGdcEiS7HV7FDMxMWQ0BwFDMFEIHBQ1kIcj9eRQD8ZAJ5ObY3EjLV0WZCHT OxTTfwKq6fjIdzFqOO2wncQCHUspKyWao7EpXTQZznoBlQFM7y1G3jA/zqBFAVBl56djwuIrn2kB 1rg8q/JkJ4oY9ccbv6Gh/+VRpWMtHAkYLNWROWypSJH5GPr6HROoWRG4LatxgchyjBWOLrGxjQ9I V+sRIAMIIJv0Sc/zZ6FEKOYzmelxZnfpZq/zi8fCH0ZUgZ/EaiUmH+VjAvzwQUdOQS0SeSGkJfKz Qam8ekbjEZUsEhrBXxqtgzDShKWc3B4Repd3EjjjmjRCBI062yisNCQp0o0nkFX4Tv4Dm8stFUjC wUKSnGJS0YNsmx49jxR1NXayFF4DiOCNJ7WMNoOtYjX0E4TisI34NtimUipViYnhODnVRWiQGBdw AqFCHHe3OGSHKlqp1LfSoyISDeQKUmFpSRhKf7qEoQLuf3AEPsZBZV51f/8hPn9Upks8uqPQEy3E Ixz+PS3jgTkVjmcw/mbxYS2HCYKKLY1zho3dqIHyci6DHY35wS/z8R3J3qHAYy6cNi/lEx8PQwns kw8HtQ/ayccx4s8f43mSDCMF3RNBIu9XziPEHYeqxzLyLocqMTHPuYUwM+ZScsKwjUEVnTMk4o8j zKlC0e4mRIS4CROeNyalrO9iMRU5ZNJxwvHDaXzFp0MJIROHpjZjg5NAZPIsALEjFTdwQ4l8q15C JnYZgolJJxmdQpVWKUZObQcPcDvUgd9SmWTxna5h6SvKEixRVddg6YvmASy3kh1vVDtoCWWP4VRh NiHBxEhhtaO7cS0lfrD/JSvhmmXgvEON0Nho3U4u3SFLI8VZtPVmtOWzQRQ9HUjttgOwjHE9pW71 vME9vKIVm0XkhXgX0OEwAwExSq7b6P6GDmw/WpHayy0TAYkxDQF5ABGdDNGEwdkQS95OPLMVQmMm DgGREkSF/SMT053x9v4+AB8SAoQ1ttnBO0NONhImFd0TmjyerhwmW2EnMHyDcbIAVxOf8bkWgFLk aKOTarNphhEXGQsY4EJdBTqUk2itdjAqCqqgOiU4NbXzQxZGRObzVDmV+D0/P+aZuwQblzPquBgd 3/P0tp48AT4aGGrh9P8qUAU6cgkEFUtlAKlEKsZjUlhxOodP1nNjsSKs/1kLR7ttDi2bE+dUdW6o 0dXZ5GybNu+KnPrmsFh3zh0Pb7srVv4C5wCd1lb48O5a+PagtsaEqsKszLy0hLgO30o2SuZU5gAA HgAoABwACh4KHFwpXh8mJmZpbWNjaXNrJyhIKCZKhCmCHYJnU4N9hXeBgVUmSDJKNEqWdWm1g7mF VVSwVUrEl28nHJgnANRpj9Fpx8cpVKx158U1yGnX1fl9388FA/fOlrte53xF08Zs2MJhw4JVq0ZP Ij0KGqxpMFCgWDFfF30Z0FBsJMaLFwuMRGWCQqcKoGC+ZPmyxExQFViM6WChQ4cLPX/2BAr0gIAD Dw4YEKD0gYAAAioYCP9AAYKBqg8CQAjQlMJRARQMPJBKIcBUAxWwQspShUsWDhXagqkE98SkuZWq 5K0UxgQXNJbAfJlUZYoXFlmgIrEAQcDiIRCsKIb8pEJduEJ2XsBi4ULbzhY2W3krF1MZKJTRUGZT IQ6aOJTbvIbLosMe23ysHHbygPfZszhf5FkUXI/wOx1a1LYiZAvpuKKhi2aeqa2QlhQEFVqjypQB Vee8r4OFjlevZbMI/sNG4hqFa9cOngK4DNhFica2ISy3yxeJCeTWWccWEvIhwRb+yGMGP278a+aX eUhQAZgJrPlGnG8e3AUdUhAiLx953kFHxGDWyYWacgBSR0T+3MPoGnD/wBmnpJM+6ggsj04qacYZ iwHAjet+NAEmmyhAq6MVkFzBp9o6u+AnDnzi4KfOfLrAgqO8quApqsJSigIBHuhKLLGmKiupMrEy gCy4smDOLi82gY4Sv/aKAi+86rJihUjAWCOwIeJizbIw6LSgMCc4GCCJ5SyAyk4jFnNDNCs52ykB Cy5tq63QolvurUNTe2KNQlQbtZBBWHuiuOIa2QKPEyyA1QQ8aH3hhTuCywMG2vLgAIbaeA2Mi7ie 02JYY0EbAIEIlg0tAk8tuE7IT+ZYgyVrX8tOkCIhMCJMCB7wFq0HQHmgAmlbYmmEJP6AgCoKHjDB XHGcuCCGDioQQN8E/zrwYCct/3sxEQ/O1aYEVwJcxYEEibjAAxggYCbBCSr4KdpmGnqGwQklJDAe ZyroaQNaGvQPomcSCrGdAiZgBSEKITqIv5mDqQ8c91i+CBxmeOxoR5N2zPGkAHKC9TArTjjsBFhj 5XNpLfBwkrNKoZTSigMqOEDrA8rUsqqrjrLKy6/KJEssstA0QKoH9mizuk4pqeStYS+r5GhB5z7N CqiEYOxKJe5CVAgkmviiUTMEK9yxyZToWy2rsdAsiwauyILTNsFAXLUznKhLNsoWUWTVVfFo4bCi F0laOBaIM671XG/VbW63uji2C+g2a9uKASq3gHctEKiWNRPaEGWFIv8ROff45LELRINzqZqpSJba aEkAlrBbIzkP/MWg31a3CKonfz0IyskEgiq/AxfWh8FfJ5HjYIVoSJmq4gvQR9+nczUggYPkLuAC EPjrAN0YRn2EkIADDKAnLYhRBuYRsg7wywPoqwA8FlIBD7TAX/3CV4ZKAI0JBAABCYgBB6dkAISc QoMwOGEHwsQOBVUMKMVwgAo/oiAdkqQaFzGJjWw0Ix+BYgRtuAnTYEUGpD0tC0mbAXKqFMUWWEko j9EaUpDyJTFhyVxl0WIAxkKWsIBxKmARCyTYdDvqgGE0YMgDXPpCKEDtTQCMSQJUDgCBA0QAa8HD 49ZO07fAFI4ycqH/zGQKGchAvOUyqomCG0LlSDf9aXM4ccIUnlCXN6TmBKaajSJoxQITNG0MRisD 6zgQOz6sIDi5ohUoWefK5PAqikKpZWa6gAVl7c5yz8pC80ShAUTAoQKiEIUJNIBMQQiTEEhCHhwg UJMHbGuaJVjeBpa3AlCYAAIriGYJwrQGd2lzT66Ckk/4lT8CXGAA6CthCc9HgCrBLwHwRJ+TOrhB D9zrfOhrgMOQU74ElOUp/GJnAryHP/zlDwEYuIAAEIDP86HTJwEAwFNKqCyH5a+iFiXFRyXYL/x5 NAAh2yACPorRBPxKSx8FwFmQgwCPujQAB4hoPp0kUwFE8QAudWlL/7bVknMZMV2GWqIWVCeUKbXA Ao3oTHJQIKWqPYmp+SqS1p6ghZJqiSxiHNNYvlo2NhELE3RrTnNYA6gybKEvUECCoiADAUU9xnBZ TeQg9VZJQkoSEICqTGpY8BfNZdIQQhjEHzD5hjDARq+CC5WpPNkG1eXkCUbYgCJgxzpUanZ1ofSs Z1+QJFPZjnagOasaTasJ1ixTmc1LpvGwwxJRFAmbJphfMbX5CThYc7fFfEkgsJPM4xWjDeQsl7mQ VJMNYOUBqvDpc6Eb3Y+ic6EIWKf+8IecAQBAAO2coD470FOXDuCh5E2AAGiagA72JAHYRahMpevS /02wvejkF/vKh//PnuB3fAD1iXc9wL4l/cQpFzUwdBHQkwrEN74vWYE1fjs9crnnXE7Y5tIwTBsU WOkCU+wACjpwgg6woMMd5skYSsuT5sStCQbYgu5UNZ3TLierKyYNG8/ahNn5JU5WkKsJ5ipIHUeB kXcVDKP09pfGQmGUUMhLnkQ1BCgfQjV3uCSVLdnkzaEKNYGYAhlSc9jNGaFxqx3VBjYQSlfiAXa5 +pwnsLwGIBWpWsVVVYrVWJ3sYLm405sDBTYwzg1gxxOiTaYnbItbZMKhJa8NxHCT9AZR1CQ74OLN VniDCgZvmtM05Un59HUAnoxvSSjUn1NmalGCGgUBWEAAqjvdaQP/jO8tRnEYB3w601jvmte97nRR Qq0vowgb2MM2NrCRHexjozrZy3Z2s5WyFKPUlNpcs3a1sa0UpVhb2tzWtrS/HW5wLwWM5A43tbWN 7Wuvm9rkJne5yRhvqci7LPO2N0HxnW9975vf/e73RVVt4IAPXOD1I3hZAJ5whB+84ASv38MPTNKG TzzgEff1xTGecY1vnOMd9/jHPa41Yo9c2c9WdrOLUhSCJjvZNT35y11eFHGLe936are0n8K1abOb 59k2t7rLLZWe91wp+Ub1vlF9b3ov3d9Nd7pF7/3Sek+djApv+MIHTlCra13VDPf6wx0u8QNbnOE0 hbjZxw5yta+d/+1td/vbNV7slAd77nJ/OQJQPvdVG6XuwXb5sXPulL7PfOfjvra+vq3zoI/73Oye OdC5VnSdS/4pRZfKvJ9CxqMXnYxK9zzVP7/0e4de6VznusD5TXGAez3rqv+62LsOcdifPexjn72u 0Q533e+e9733/a+HjfKSCx+iVyI5slUd7bqrHPnTHna1C094bzul8E8hd8ohD/TGoxvcixd6Waif +fCH//KZp/q7K59+0YOe/euPN9UJivn4r17r8sd3AfDt+rLgH/Vbj/3rCw7sDE72CJDsTqEUWEE+ UKEWXEZBugFFFiI/1oMCUmA/JnCHUiBmHnCHcqgbZmEDjyECI//CQiwkH/6DBCEiItyjIxxEYyxk eb4hIDiQGUhQQr5hHGrQQiKkGiLkHr6hAnPwBoUwCL8hH/LBh3IEaIQmaJjwIkAu1Owu+KTQ2UDj 1V5u2FZPCv8O5QJv2CSP8QzP5ShP5myO57ot+67t+xwPDKUi/OAt/LgG/DjPTDov6dqP9OAvD99P D/kN/+6P3+aN/gDw//pv4QrR9QiQEFOtABfxAFvhompBPryjG0KwG9RhP2ZGBCNQGzLAQZpBGmpm Z8rBEnWoFMtjIZYhQXBwHjTAG4pQhAzIE4kBY2hBBR5sAlYAGNBhFngxHbjhY3wBB0kwIoCwIvIh BluxP6IhGnD/sASA8ASPMSPAQRrtQwmX8Bp5ZCQYrKaSotNGbu6Ojfh+59X6Lvj0DRybD9iUL/Bi jg3PkAypTQwRD/oSDw257/sI7/LcDd7aTfzizSmKzg47z/zcDw/xzf4Qst/kj/5W76WuLhAPbuH8 kOKwrusGsezKrgDTLgFvCAED4BUM4gN9oQHNIUUyMR02sUEwKEPSIUJ0URv8AxtQUkFMEhX/gQZL EDv0gRIjsCF+IRhrZhnG4T+yoTw2MGAuxD1O8EI+pBVjJmYmBGbqoQSGskLmYSLoAUN6iBWRMGhI AglPIgm/ctO4UWtw77mkUOToThyr8ALAEQo3b+WmMB2VLdq2/w3nzHD6nI/byk3w3DEfry/70i3y qA/zKO/oCDLf5rD84u8OHVMxIfMgp87+DvKipELq8g8iEfEiGzL/WM8QxS6lDNDhUsoBAmCEEtA7 XME7EIIjdEiFVmQTSRETN/EhZlIZ4UM/ZvAoIVAGLdBC5mED0UMb3sEnY1IpJ4Q9YoQ4cyFBRvFC mpEH90NCRtE/PmRnKhElf6EeCKQIJWIkJiIjvrIJw1IlekYkACBJYmKbVGBaPMsPjkdIBKF2MgG1 rMBJ8JNStOBZooJMvMrFMMFNRqMtzIBuhoUD8iJvEGWO/iJzMAHNeExu2AIv4iRx7ASvJmEwACUv LgNBPwU2iv/MyaIAkzaBrxYrCsSAQzmUEEIFDUwlNdagNQghVVyDCmz0Rg8Bm2o0RgMBm3rUNVZA R/csCZqHCSpLNbLiSJGLzNylm5LAXIDr0YrrD9ThNE/TEVczO2XSI17mJDdRNm3SEtdDHsoBF0pR h6LyHUiRITBEHDqEZdYBIGTkG6gBgw6oGCykPeC0Q8KhGS/kBjEmI3JTApURHCakBBIkJtUUK1uk hwRVCSGVPIPoJNLTBNrzOlrCmq7DmhZBOJDEUuEgOopFKWTsPuGnSYCHxtBm3tCmMbrgTTqUOTZh WAiDEi5BVjFnrTgUQctgE94IMG6VkhTnkRrJTpRsD+LAAvb/5FDeKJA4oA0GCZOWbJT2pDKcrMue IDb+YAiIic9qlHOwDMtclBD8IDXoDEZ7tFvPpTWIKdDqiAnEyV2ItFuowgj4pknpVZzyhVwgAJv6 NZtsCw6sBTvqZ4TW4UrR4TTFgjyckyfP1EvBdDe1QRzg4xVcU0O0AT3wA0y5ITaF4UPilGVegUNQ kSLcNIS4gRr0oSFaQQbJoQYrAkMmNjg1sT+KYSJO5h38w2SAoSFiEEecMiPE84e80hq9Mj1hIoKo R5iqR5vyIBHkJydE6TCK5ayOAoymg8M44wJOQD/lYivGqCneT8bipGzTaMVmlU3q5sgAI3MkYQwI IzBkB04M/wnJ7CSRUpRqm6wS9gSRIGXJDkWvUuORpKxzBCdV/MCwSEWyUmV4AMEyRAVxu2xUglTM IjdVeJQN0CwOYtQPjCA7zIUqmEAJyMwJuqVbdsOb5kAA4iC2BCEOdguoYBdJVC0STXOEEvYST8E3 Q5ADlZIqNcYmCWQaqDIV4YEqrdIXOMQHi9AWh5El5yNBQvYdvoFDFCZACsAf9IMpIyRgsKEcDtBL 1wMebvA7JOIk0eEhsnIYJgYVnwFG2OEBszEJVUJoxhMbUYEqjwcchGQOQKHRriERAiuUZmUFAGgn 1EhLyKQxpAY/t7YLwMRL0qRMyg217GJCXwwT7uRtAqcSYP/FLuAizbxAEu6kWBlFWAuJxoYsreBo rxolUu7WWhWJyQopVNtqyoiVy+yKeEoFEFAlNmbUzk6FVMC1sJBEVP6AzhiLiM2Fm0aXXU5XDN41 EPIoceMTm1qiPbE4XZ4H0TYAEq1UFlzmSptTYszDFB9iFGcGZWImRj4kYl8EB4+xTXeGRZT3IBYQ JNWBZUrgo87ho7I3ey/RIbIyIwAiQVTIFT7xTPfjY8jDJ22SBnFQGpoBIGKyAotRdx1wJKbxfq8R f8ESABINe1ZQm2xEm7yMBVaAVmaFNjwMxJBlMchm2EzVJx54CJziq8S2S8qiVAVjbjQFc9yiQ/9k NGLVQeH/Yk/Mqpzypi/21k0sdA4Coy++TIYDg3CySo+uZAq2dXPeYlQsoK3mJHG44A8gd69G5Q/U 9XKBuIfRING0g7Fg93O8lbZ0mMuc2Ei7xZtKqm8/13TfuTXcY1sOKztqoiXi4KKyFxVawRRiQTWb qxcYlhso2mAYeSGisgV/YVDnIyaHVxhr0Bry4yPiAV7YIUC0IUCci0NENk5bRk0/tnlNEh1cgSMG ImNvk3znAaY3FhlokNAwSEP84xm1khZO0zmPkDyL9pORcIj8dwUHmsKahyX6QJVZYAZKB4Bow2Kg w6rqKNpqamudBAWWoyyw4kvGgoKpwoKh4C1QTDqeoEhm/1U6GCVvGNRT1HaDLSltKWmQLrQJXsOY lbUtSJcJiDWvTsMMtNVwjJmRMAFaG6kJZiVbOaGx6JkyKjdy/8BaqIyHU6PM2FnO8JmI54ADPhcq 1oAFQFtxOSfReMvClEdanAD/dLcVPnISBWQ8uMEWzFSHKlYGd1aNfxJ6SSZDHoQEdvAYV5E4fRMe KuSlFfmlSWQVsHcfzkFkb3IXSnBQ4QN8e7cbMpp8l/OQKSC6v/tPi4E92INkosE/YgQftnKTyxOI fAaUzRMVpOU91nO4AsG2SoBWsHpqK0V8lkQLZlkrikIsoAI/yRogzxpsxwhtKOCE6TNEteTyikRu 7Loy/v+aEthEydjCLu7AQe/CkAipx3BiXO/CXvWocaB2r9CoWo9MVnXsNBIhNZ71rsR5DlLUcX10 nSvpdcsAWzjHWtq1nQ2Bh5UY0cKVsCyJm4fAT5pAxqVVsZNpXS21sgsBdl9KFlQkFsZDPY6Bt5sb j+3YHWiTQT5xQVjkQYoxT2VyRYzSFeXBFzdEkBUGTlWmQ9IBOKNBTVUBYYxXzenjQchBREJkGURW KJVbjWEGRryzKXuIHjjCRiCoI9Skfj2ZaMeyWt7DJhxs0LJ4oJOmgHMiP6WEigq8UUi1pL7CKapi wWHlanWZVcFILIR5Oc6kS77qLIDVUFQrUB4UOho7r0P/fC7oggv85ISHjFHS7K8eIwK6JY/ySFGy hq9oOJAGIZa/AA3oxJL0agoot7VzHBAiKVs8iVYad4iD1HFVQ52JWA7SOVUARcsSacn0KnFngnoG TVtNAP+ytxVut6EngDUjejjJvIx90Xt5Yc+Fsh3KvBn6Jzih80x5uhRJULljBMxJYUNSoUS+A6MF YgfpYUSYQWHy40Awnih3kR0iOhv44UX0AR4G3RukUR5gxEU0naIp4NI/Qk3u1yQopCN8JFNBPWmx R0iop5VZOT9VnUmgxAtCDSm0xGuKbgjCNvK2gmuwYipEDTG0xIvURE3ESi4uoS1Q7FgmaUIvwQza fjm+/6wNiqxBC2c0CvTKdKMJlAAqVjuy9eqR4qaucVXE2aQNCuMS0lk2LrvJ4/kMECGUGGmz1314 5IDO4F0O7nk0PMuxZ5w5grVwqmd4kGfQsnWEVIQVxlg9rLsXe/sghkEEbLY+dFEXUmRFdncbDrUZ 4HtnRBJjJxAYUuAGjZAieFKlP74dVPMTo4EChdEW3kNDarpjCXUXKrB3k8EYotsVd9IBHUQpJ14r dZ4efkhNOEIlLp0kgH5+wxIVZIJ6igQmriHpa8J/RekETGAMqIirhwJVhQ0IKoEDJFA8PARDISXw CBiKzYch0DxUiAZqoMutbisVy9hiJls4p3OFY9mYx//wNtn9Jo/lbE5evRHP8ZHN3Y2ZcLBYsFQI QAwwQlRAWEyORYqhiYmZaGaemSF8io65tZng5R1WnFRwmmycwqJqav5V2HK2arLw8rrx3r62rlQQ RxJzUtAKt8IWK7IgtnC0JL7loWVnkyrSqWmWiKncNiubrABQABQ4FDxMPLhPULTTTzhQwNvn58/j 48MjQUHghBLzVNybl/CeAQcAJ0Ds168EBRUUDKpQ8XCfQogkJghMUVGFhhIkVazg5wBixwkA7uF7 CXElRIsoVZhMCbGEhowGO7YD8HIlUXs7Wb6Dx3JmP5wD+XXMZzMfRYQkSmIlmZWCBgpeKRSgkIGC gXn/XL927XpWrVcNAMJRLGGCgglOJVbMrUBXrhi6anp1QNDhQgIOHTpYGNyBw4XGAQQIEQLZiBED AqpwofKEghIuTaBk3oLZQBMDZQjZqWNHD59SaVKXKVQHT50ytjkcinVNkKAVZKw1kkSrQqhLEVCh cYbnVGwzdlJ/il1KkKZXmZAVaxZrOC1im5yJQRTNl6801YfX5X5rxYpevqa9j4aNUHM4nlZry5RL GV5nr9KtA4ADZb3zTz4PvZNgPu/swyBNUFF0ET0PzsRSP1F9ZJCEJYi01FBQKTRQRgcCdFI/DylE YYUv0VORQib9tBNOPfFEAkD0yIQjRAKyVIJMMhG1/5RLFKRAUYgERVRQiCBpMMGMJmFVUZRmlUUa W2K1ddZaaKmjTFx62WXCXXpVEA6YeOFlhgkXDGZYmxcwZphhF1ASRRQBMPLAAQJQcIATftoJARZ4 EirEFo9RwSdmUJhmBhyCZLPBInG0lsl0cZxB3xrZ+EYbbW3MNyltj25zSSS0nTpcJifMccoZjDl3 AQLQQeccqI7q8QcxxLBqwiLgYafeJru4x0s1sK7BSiTKAEJmMSy80Eu04sHASwfjyWceGrVW+gkh ZwhgAWSOvvFKLq+UAEsBAbDzUgADrtRiPfEauFJSD3hFrz/8UFUQVOo8iM9H/ZBgUkYWzYOkS0wB RP8QTwgtTNMEJSF8z4kXLnSgxRcpqcFHL+I0lU0attQOTURBSU9YDrHDUpA7/ZtkgUvmk0EJD/PE U1cmWkRaWGFxZRZbahHNZTp2wSXmXEuDGc5cFJV5iBuNJYbYYlZfPZgFfxqBhJ+RRUHE13geYNpl pUHRxaFWdAEFN3DYhyl9g5B72hsnXLoKNnuzYWsdqnAA9yq7HYLHJGSEW0nis4hbQQR5YOJbAhZM bsEFDFiAAJyZi/IcGsS8Icgi2jWDnrB4nadLL+IlssYYrpPxQBaAQBstLy8gYns0L8A3HiLbvKqt G6nxJorxkZq7QbrhoKMOO/GoM0EA+67U0L4QJSj/84HbE/SUQRT9w6NKTxFpZEUrDZWQxtYnaZJL 60g8j0kXvmyPQANHpeRTIHmVMEZSmm8n3WNJOpx0s4pEz2TysNjCDqI+euXILN+TEVYetrMKkOQr YNngxLhStKFpqSsAKBNdLnIzuXipaa24C3vqQpE1JIBNiplT1q5GJwtogU9f69MQJnOAPkWmC6VB ghPStjY8YcM80KED5IAXm1uk4Q6Y0ptrkhMp5AxnUuRgFaswgY1UTaISh7uEF/lQATpNLhShQAxj BGM8UtXGUrmpwCK806zSLYM7roCFNDjAul5YwDfPScTuOPAC3EHLF4hEhHg4AAM/RjFTkYzi8CZJ /8njmWEAoOBGdlYAi7mwJ5SiHKUoOQEBvoyALhUQwQpGUBcXKu0ceJElLV3RCk6gRAaijJGECNKG FngAAf2zmGEs4KKg6CsfAsmgFTLGP/z9hCrKfIpABqKhgVCMYwlTRgfigsD7UVMj7IAX9hKSI/dd KB85otDDbIKQtlgkS1+Zx8+2lCUQ3nOEFEmlCy+ytLzYMj25YE8HWqCYw1hNhgjVmtb2ZBrLcMYy jOAMENnGtiZQ4AmaqUJGIeONS8ZxNnsTHRM3gDdPWGpvoKLDo8LTCjJAgDp44JUtCGkJmApHOJTg m31umMYbcg6ooQheHLwYOVosYhHm4gB27Nid6v+cAC++890v4POb9jDykOPRqiNZMA1GfnUaqsGU c4JXyU+kBgHHydxxhqpG2+yKArDYlQZMoIEVjGMcy9uACjiBlwfIzpSygwAEKHAJ2YXjAaibCwTy gq/Hyk52Y/BADDwwDXUAwADU4MABAFDNFTgSoY3RnOVIKCChCMUBLLKc5gZDGAEwhDASSEAM9QKS hPnrJ99rkgqqSYIRzSMxHuhmQRympNu2RUPtYgeJklQRI/2EQUNi50gopoF4mW+ebUlLWrR0Ty59 JQDs0cUJclFeC5zgBNZIlhlYoN70nsBqKBDtQdtUCjEM6oeXERSeBKBDPXkGT6KxghK2UJpIeI7/ kn04jTX4JrfZkLWskojDI2AaR1rYhziqwKLeMhGJx+1UVSE2Hp1aqzlZHW+JmHIDc7pBC1bkQj3Y Yh0j/1jjqSbid+pFb1b/qLtoLYaqeyBq50CKSQtoUq2cY+tQzeBJE6CEP52kQEpWkC5QUnlXxUCd GAabl0uYQLwBuEtfuywJZUj2AjHowHA94GZgdsAFCAiAUATAAct2IAHDxcBh2DTcMkGtoAJArQMO QBg2u0AxB7RcnhtjWdta6EhPyRwBWqC8+xVkBQa9gAfoNJHjpqvTjr7swFQQj4V04TAuaMGaEVCB pegpzjDowKuxmxHrIoS57wyRBjXQ3Sv9OoRc/xmhr9CL3vSaIVnuNbY1jL2KNcWXTZuW4ezKBgED D6oCEh3Ctfmkw9J4hjRK8EoXkKCMB9uKD4tQt7a0gQ07wC2KsUEABAQQgXBF4BGRICwk6EjWkWZC DqoSQyUs4UUQXyJT5Hj3GSoHVKLyzRDLEYN3Yswdp9IRx4wczxkAmQb1ssBXiyRPIg2ZyBn/zo/R GB4kaXXJBJ8BAZpk65LVGAe5nuMVF8FgMUA5JryoYK6ghHLUJAEByUqW4FbG6zlK0FgLrPrPuqia C6rO5sO0mc0XGIB/GxNDhLqAA1IZRwW+7vUEFNQDESAYlQfTado2pgMmsNAA4H4BAugZBi64gP+G MlSBPjua1pH2FwvoK6thgvrOcZchDKoxGLQn+rIY84dgYLBmvZBMIk2KmQaF5t2x/NrXZyH2V3yF 7NMj+xPKBiSd4MQmFsT9MDgUwg/xRFEfdjui2r4o20gDBcOCgQqcNKs3QJU3chWP3Sh13AEeB5kI 7FsSj4sEFjzRiSd2Ag+jI/invEiGx4GYEOBBBTH+8IcjT7H7ZGBFIIcFCIunoqYax1YZ3KOINWDV PYbcOAs2gEjbAeC0FB41FFR9KZTh0VcmKWAozNySkcE/2QUGOcOumEl/AF0obVlKxJhinVlKFMNd 3MU5VMADgBIErEBkcQI1wNmhDQYCnJgMydD/cHXAmg0X3L0dbdWdn8HZcLEJBsTQD2ZdCHgdYQyA YHRAZ6FWEgLAAfzgBTTA1QVGEtoZm3xdDNGZEgpFACBU1oFAol1hAODZQgkBahlAQfmJEj5GDP3Z F6IdniEAFsJhHMJhzy2NV8jFe6FXs50BfOFBY0ibYrRAYrQAm1QNrWVBn/QJgHmNnvweaPwQI9oJ aYQGF4QH8hlfEjWHbJSBG2RYHKQKGTyC44ji9EHGnnyKu3VfxHmKiF3f9eXC6MQYH7Cf+7WCGQ2c GGyfBcAfLpKDLejCH8TYKxRLsfjbe+HN7iAStpDc/kVLeyRjItlOC7TAfC0Um2wOkWHSzBVh/8yR gZbNEs95xzjY1TnQxV1BGXsEXc7xVTFsAJWVCc9F2dJh4AmqQGG54zuaRDDghY/IYRbS2QBoHULR lg1qHWGgHW35F9rl2UAOQA7SFt4plDXGXQI0JNf5IQEkpETWINbJCt7pWZ7JXA/G0AVgAGFcIQA8 BkceBp91AEoKwHC5AAiwQGtxGptxwEmO0GJ0ARYeANZpHUtCIdz94ABkIRImIaDdkoQ8gFy8wo6p XnpFA7L5oeVI5CBSjTUqRlF5xWXgCxLRgmlYAUeJxrVlVNlslJ4w0YUV1fBhwjdUEm7ARgUMwCSE CxZEQPM1n0e1gRk5kfdZn/Wp1OHQwix0wv+knAtuuJT56c1wsMJKxRh4bJ8u8GJ25IIvVhx4aAKY jY57URUHfEDJuUd7SIt7RIukzAALnOYMpCYvpJglmUGJgYK4pIHMOSAumUt29FU42maZsMdd3NV4 7coGWNkf5KZerUBJ8CZK9KaVJY1XfCDPARa+VEA/UidP9plQ1qRPBlNDCkbWGeSoDRdENqGshIub HEYLuAAMKMB3EoZBtg1KKmFPuhnc8ZmfwYAHfB0UQqGfyVCiyaBAEkBN/ucRopZ/GYac4WQX/F2i XYBRxmEdigm+1MXOuQJ7RSV8pdcFzNcgBqJrdQAKXADscagM2cFiUMcmUhKzQNSKBtgWmOX/gM3H fbybg22LEm0LEVCCbErCXNKGLXoKYE6RUQXpKX7KiUamUdXiZHqRxQ3CcNhiea2CLxqVd2CcJlwm thAmGdGRVo2m/t0OybmHep3mQFWmqpwVNsbmrBzPcy7WB8YVBg1dXaFEuozDeM2VrhAnPGIQleVm XeGFXMFFzwEWV6ALY2FWdSIqFg4AnVFkG+7gYexeFjYk2jUGAWiOQqZNYshK3SXASeLJFmqdDOLQ oMnhAWxaAuBdnx1GDClABwxAgEKhB9ynSrZg2whAdzZeYGTBe8ohTiYqnOYcXYiJKoXJLqyee/nh BcRXtH1o3MXXfM1XWb0GnSCGWW0NHeCB/35lAVqeomkwgR6gaPHEaB/cjX20lCW42iPM3Ow42aqo okoFnPrZBofVwgMGA1wKC3PQIuTkAejoii5qQhfVgvvhAhxg1WM25ixEX4yJpjIOo6TwAsadS3ZQ bHWwByyAR1qhVSS5HJncIzKAkl6YgzuOSV/V6TkI5zjSlcqGQ15RhCypkl5VgAboxRMU0aCWUKLq rBz+3ePd3UK1mTSGwKoKQBtaABneGUL5qhoihq/a6gEcgAW0QAgYlK+iVtKWJBEiwH/GHQIQwNFm IQIY1HTW2U7u7NnCYZSJSV+YwCkRqyqlUGJJyMYeWa1Iq2vWKBJg61tSEqS0FMdqAydeUqEe/G0U wUEikMJKBZxr8GuEpV+HXV+8el8TccdvEO71RSYnPKC9Tt3kDiwULRzGPsMujEH5xVj7vZ8p5RSZ oof5sccw6g5qPlnFtYI5AAKX2RXFfYcmnKnL3RwJDZ1eIIMGFgPO8UWWzQVdPFlFsAeVFaryxFWw YlAptZAoSYIA2OwDoO32xmEZcoAUCgCnOYd+5pmlWi33bi+eoO/6sm8QAAA7 ------_=_NextPart_001_01C6E09D.7E931AD1 Content-Type: image/jpeg; name="Nature Bkgrd.jpg" Content-Transfer-Encoding: base64 Content-ID: <906442212@25092006-1B41> Content-Description: Nature Bkgrd.jpg Content-Location: Nature%20Bkgrd.jpg /9j/4AAQSkZJRgABAgEAYABgAAD/7QY8UGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAAYAAAAAEA AQBgAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB AAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA MgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////// //////////////////8D6AAAAAD/////////////////////////////A+gAAAAA//////////// /////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQIAAAAAAAQ AAAAAQAAAkAAAAJAAAAAADhCSU0ECQAAAAAEywAAAAEAAACAAAAAYAAAAYAAAJAAAAAErwAYAAH/ 2P/gABBKRklGAAECAQBIAEgAAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0 LjAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwM DAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAYACAAwEiAAIRAQMR Af/dAAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAA AQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVS wWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSl tcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFR YXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOE w9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A 9LDTMd04rKK3lThG1ggEQrUw2FIkDlRNjfiha6gF0kg4FOkpiUx1TkhMSEUMDWPgo+l5qcpSkjRT WhuimIQ5SlJVpZCYuChKSVJtdxJQy1ymkkgi3//Q9RbyFMmBKYDVJ/0SkgbI3OLgZ+5RT9lEnukg lcOgyp7pEhBJTtcI1KKLZkpKJeAobjJg6FJFpEkOToe4Sk8+PKSrSJ0MSNEi5wiSkpInUWuMweOJ U2w4SEkrJKUJQkqn/9H1SEjqIPCSg7yMFJCN2hhQJ0T2l0a/IhAc5x0OiKwlkXjsma4nTkKHPCky ZSWs04SHwUg0FJKwHgpAJwD8U8SkuAWjxUXjgKeoTP1A7eSCqRifgiMsgweCdVDjX705GqSmyIcJ HBTwgUvgweOwVhJcH//S9UPCC46yjO4KrkyiFslnQeUNwjQ6qadFjQFnhonY1wdCnsIGpTgcd0FU oAqQBTgJSgvpUlKQmJKb4pKtnu+aZ4BHwUdFKDGhhJVsPxCQ4+CbX4ppI18EFJK/pI9ZPHggVlsn XngI1fJRXB//0/U7DDVXHKsPEhV+CiFk91OEFIIgAcIKXpoo4VgFL0+/CdohSQXAIUxRHubED8EF 8/moIKimUHbhzKbc4d0lqQFSBKg1wPx7hTCSQs9p5HzUIJRgkGNnjVJcxqrDwQR8PgrDWhogJNaA 0acKSSX/1PUHvgIRdKcukFQTgxSKRhRQZQGorUCuiWai5v7v3KSSS5CmPwRXNB17oTgRyEFpYOAJ 118lAt00MnwRCmKKGLGO3jjzKIAYB8eEqmncTMfBGCSQGAYdR4aojGRqU4ToLlEpiUxKG5yKCX// 2QA4QklNBAYAAAAAAAcABAEBAAEBAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9w qCA0LjAA/+4AIUFkb2JlAGQAAAAAAQMAEAMCAwYAAAAAAAAAAAAAAAD/2wCEAAYEBAQFBAYFBQYJ BgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBBwcH DQwNGBAQGBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDP/CABEIAJYAyAMBEQACEQEDEQH/xACOAAADAQEBAAAAAAAAAAAAAAABAgMABAgBAQEBAQEA AAAAAAAAAAAAAAABAgMEEAACAgEEAgICAgMAAAAAAAAAARECAxAgIRIwMUATUDJBImAjBBEAAQMD AwQCAQUBAAAAAAAAAQARIRAxQSBRYTCBkQJxEkChscEiQtESAQAAAAAAAAAAAAAAAAAAAID/2gAM AwEBAhEDEQAAAPTXk0aw+pTR9xqIAAgSzicihL2tY+hrCwmLPKeFNq7EOowawDAhYEuBACY1ENCB GACG0puNWFEkMr1gQsCBKARjGjUQBCasYr0hqcQkBisri5ogQDGMYJjGohMatVdzVzZgBCxotNaB ACAFYIQ1ghNWMNqU0U5pBCwIXNpK4hNBGogDWFK1a1qJjJTQ0pzZiQM2eSwQmMGsNRNWs54dKW9e q5jU1YWI5QyTKMJmGrLqNNTGsNGsQkFEc7daeiYERyllzYShJANXRa1NWprGt1mNUMzGAVru1omp co86sc2ZGEgIa6bW0Nj0awawKhmY1Y0dm7e3E8I8qsLEhEAidG61ho0DRqI1TkmCmMdVtrXqPOx5 BACRNYafUbTAgQpg1qUkhBVi9t7Xrn42eCxghoaCw6hoQIWNKA2GjUEUUpV7ezVY5eFTNaxMiPo+ x1ERRYXISgBhrDopFAX1e/VY0cvGzxbdIIENo+pTRScQzIZCFGKWtYdGoGOvVcwIli8/JTau41AJ qQjmLCRDJYBSr6Gm0aqF7cAnix5kzTZbopqGiIQkELAhJVSUNXRa2o9NV7cCBEedlirDFOkruNox hCGYkCFBKBq67TqPRrAhMlzY8yyiGqm5TZ9xjAEiGZOBKDFavqvY1atCQmLPL//aAAgBAgABBQAg gVRIXjS2tjYxnUVSCCCCPFJJJI3sjRbJJ8E+RaTskkkn4C3ST8JD2ST8CNr0nWSfBHjZOk+GNkb2 MbHtWkEEeFbGNj+Itbb4+AtLvfAvKtFpcW2CN86LatWWENaoSI8y2WWiHUgSFsZJO+CBbLaLSCNZ 0ZGxeGRskTF4HpBHhkkeiExbX4ELY2To9EIW571sYxn/2gAIAQMAAQUA/Lz/AIzOyfyE/KX45+Bf JX45fBn8pHyV8leH/9oACAEBAAEFAOSBVYqFalULYx+rY0y2Kx9dxYbMrTqkhaSh2LWLNjHjU1xq FjQqI6IhEDWrWzjTsdjudx21hDrXSi40+yo86K5pckkobRKG1pJJPip+pfKk8jbspRJiyMdh2Gyd y2LZBX9buK+3bljJ5raat6SplCsm3dJ2vWr7VhOsKyekbYF6y/oN82fMppsx2Sq7cfbUtZu02G2x t2EpF7hxVyVyW7dl2gggggXq6mr4H6bJL3itMqa7WQ+SHECbIhxDiT+Oa2V7J1yKa2rZwQQQNpKU ZqjZayVb3Y7NlVVuEcoTQkQdWhQJDTiynR+8Wa+N4r96QRoy9ObXypXbq73dlEqGirt2TFB1FUTa FDTqcolMaizUOJr/ABgs65K2VlpdwO3LZejQ8VWOtqtMo1KgSQuBEECtoyzsmnKrwyst47dXM6ZR +2y1VYvVKzrI8VWfX/sVRVOqOqOTtY7iskTJlSmJOzQ2UT7GFvoZXy2SSJF63tZ1shptKBEjbHZn 9mQQQZO6Xax2TVbQ8Ks7sw/oZnyh+9Eh4m7dWhLV7UWTdWmhtDhmP7bPHkva2OrrV+sjl193rxpV CR9aZkpWr4HA3y2Ns5E2cnJkx9jk6s/5Kt2pjrXRmSvK915VsYqNCRVCOlZzKbZGq1eSzbvc+26K 5ZIJFo8VWLDRGPHRU0bMik9OlhMhHU9H2Um+VjaZasn10Mi/tAzFkbEhCQjFRWZJI7F8nLtJVlWJ 6IyU7JpobY5JP61Hiq30s74sWT7lSzuqtuuNu1cTZWta6NjsOxf9hFGLZeisWq6nJEjSGkODA79k lNKpCSQhjY2OxyP2IqIWy8dbKmj04P8AniUL1raRyW7H/9oACAECAgY/AG3/AP/aAAgBAwIGPwBt /wD/2gAIAQEBBj8A6myhWoAOjFvyLafZ4+t1AUwo/DFGElOc3U0Y+SfwwiafIU3FIQLvzVsrlEZC AOcoPlO8J3UY6ARh6fon81n27J1KJGLeEPZ3K+2U5ui/hciafUmclAmwjsh65M6yAtmoFFCGk5Ra n7qFNt06dfsmynGVKfIKYF863HwaOYZEdlvwntzTdSuKR4TWKZRfC23C5CBRID/KBNzpJ9SyYh1/ XwuAuQnGUG7KRWLqax4KYwVxlPR0CMfynGpzI3UQuHZM10AZ41QmPmnKLymTYNkQgBlcG+qUwEMt 2WyAxzS2mQoMUcBlyp7FP5TDe9J1kgfCYmRdWnFLK1bst6RCgxtS3ZN/kpxAFz8L5TtfoEjKY9Jh +tOVEFA+rgi7f8Te3q3NkxvocaXKYKehdPlNQvDsx8p876WUaXIlDAUXUYV7K78pjd4pFGyuVuvU NselZwmdf180bFG5T+VOF9T2NI81L2GltfOiygJ3RDMB/pACwMlfUSUwuvr57L24UZv1XacJjpuo 9fs3akJ9/wAAvZFjGBOk79H/2Q== ------_=_NextPart_001_01C6E09D.7E931AD1-- --===============1385905613== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1385905613==-- From rohc-bounces@ietf.org Mon Sep 25 08:27:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRpZ0-000452-9m; Mon, 25 Sep 2006 08:27:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRpYz-00044x-78 for rohc@ietf.org; Mon, 25 Sep 2006 08:27:57 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRpYw-0001Lx-M8 for rohc@ietf.org; Mon, 25 Sep 2006 08:27:57 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 177639003B; Mon, 25 Sep 2006 08:27:51 -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 24670-07; Mon, 25 Sep 2006 08:27:49 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP; Mon, 25 Sep 2006 08:27:49 -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); Mon, 25 Sep 2006 08:27:49 -0400 Content-Class: urn:content-classes:message Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Sep 2006 17:57:46 +0530 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Message-ID: <69FADB84C90B1248A7DE59422771FA0C2F8AE3@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] FW: IPsec Processing & HCoIPsec thread-index: AcbddQic7TPTglhFSRqJFieJIp3gBAAzZ4XgAJY5ivAAAHAz4A== From: "Sarkar, Biplab" To: Importance: normal Priority: normal X-OriginalArrivalTime: 25 Sep 2006 12:27:49.0738 (UTC) FILETIME=[03A72CA0:01C6E09E] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org ROHCers, I believe APPROACH-1 is the most generic and neat. We can have ROHC pkts sent as payloads in different type of packets and having a unique IANA number would make it easy and explicit. Currently even for ROHC over GRE for HRPD Rev-A calls, we don't have any number assigned. So soon we would come across more and more cases where we need to get a generic simple solution. Thanks Biplab -----Original Message----- From: Lars-Erik Jonsson (LU/EAB) [mailto:lars-erik.jonsson@ericsson.com] Sent: Monday, September 25, 2006 5:42 PM To: rohc@ietf.org Subject: [rohc] FW: IPsec Processing & HCoIPsec Forwarded from the hcoipsec mail list. Please direct also further discussions of these issues to the ROHC WG mail list. /L-E ----Original Message---- From: owner-hcoipsec@mail.vpnc.org [mailto:owner-hcoipsec@mail.vpnc.org] On Behalf Of Jasani Rohan Sent: den 22 september 2006 19:41 To: hcoipsec@vpnc.org; Stephen Kent; Tero Kivinen Cc: Ertekin Emre Subject: RE: IPsec Processing & HCoIPsec All: I should have started this discussion on the HCoIPsec mailer list, so I'm now including it on the list. To get others up to speed on the discussion I've included a brief synopsis of previous emails. Synopsis: I originally emailed Stephen and Tero, to gather their thoughts on leveraging a generic IANA value to indicate whether a packet contains compressed headers. Stephen expressed that it is going to be hard to get an IANA value allocated from the Protocol ID registry and that this could cause delays. Subsequently, other approaches to achieve the same functionality started to be discussed (approaches described below). Currently, we are discussing Approaches 3 & 4. Note that Approach 4 has already been debated early on during initial development of HCoIPsec and was not pursued. Stephen and Tero, do you have any concerns with Approach 3 ? If so, could you explain some of you thoughts. I have some concerns with Approach 4. The first being the additional overhead of having to establish an additional SA for each HC-enabled SA. This can be a problem for resource constrained devices (i.e. 6lowPAN), that want to minimize the number of SAs they have to establish. The second being that now SAs are being generated not solely based on security policy, but now partly based on the capabilities of the compressor/decompressor (i.e. based on which types of traffic the compressor/decompressor supports). APPROACH 1: Allocation of a Generic Compressed Headers IANA Value + A generic Compressed Headers IANA value will be allocated from the Protocol ID Registry and will be used to indicate that payload contains compressed headers. + The main drawback is the hurdle of getting a IANA value, which can cause delays and may not even get allocated. APPROACH 2: Leverage the "uncompressed" profile as a marker + For ROHC, currently a packet that is ROHC compressed has a ROHC header with a Profiles field. This field will have a value, known as the "uncompressed" profile, that indicates that the payload of the ROHC compressed packet is not compressed. Therefore, this value could be used to signal to the decompressor that it should not decompress the packet.=20 + For ECRTP, currently a 1-byte shim header will need to be inserted to identify the different ECRTP packet types. The 1-byte header will be extended to contain a value, which we will call the "uncompressed" profile. This functions exactly as the ROHC "uncompressed" profile value. + The main drawback is that packets traversing an HC-enabled SA that are uncompressed will now have an additional few bytes used to indicate that the packet is uncompressed. + In the past, HCoIPsec community members have debated this approach against Approach 1 due to the efficiency tradeoffs. Due to concerns of efficiency voiced by ROHC WG & 6lowPAN WG members, through consensus Approach 1 became the preferred approach. =20 APPROACH 3: Negotiate a Compressed Headers Protocol ID value local to each SA=20 + When each SA is established, a value agreed upon by the peers is negotiated. This value will be analogous to the "Compressed Headers" value and will provide the same functionality and will be used in the similarly during processing. + Since, the ESP/AH next header value is "local to the IPsec devices", meaning that no intermediate nodes rely on the contents of this field, it should be fine to use a negotiated value. APPROACH 4: Leverage 2 SAs, 1 for uncompressed traffic and one for compressed traffic If ROHC is negotiated for the IPsec SA then all packets MUST be compressed and decompressed when sent over that IPsec SA. For those packets that do not compress at all we create another IPsec SA with identical selectors, but without ROHC, and that will be used to send those packets which cannot be compressed. This will add overhead of one extra SA, but this could be used to allow running those profiles which do not have special "uncompressed" profile defined without any modification, i.e. no need to add extra 1-byte shim header or anything like that. I.e. that is variation of the Approach 2, but in such way that there is no need to add extra headers and using extra bytes to indicate that traffic is uncompressed. If the profile already has some other header which can be used to indicate whether the packet is compressed or not (i.e. the profile field in the ROHC header) then there is no need to create that extra IPsec SA.=20 Rohan Jasani Booz | Allen | Hamilton 703.984.0337 (office) 832.452.3241 (mobile) =20 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@safenet-inc.com]=20 > Sent: Wednesday, September 20, 2006 10:45 AM > To: Jasani Rohan > Cc: Stephen Kent; Ertekin Emre > Subject: RE: IPsec Processing & HCoIPsec >=20 > Jasani Rohan writes: > > Stephen: > > Thanks for clarifying some of the "undocumented" aspects of the=20 > > allocation process :) I definitely understand your concerns, as we=20 > > too would like to prevent any delays in HCoIPsec development. We=20 > > definitely want bring consensus on the HCoIPsec approaches with you=20 > > and the various other community members. I've reiterated the=20 > > approaches we've discussed below to make sure we are on the=20 > same page=20 > > and added a new approach that provides similar=20 > functionality, however, through an alternate mechanism. > > What are your thoughts on Approach 3 ? >=20 > I have one more option: >=20 > Approach 4: If ROHC is negotiated for the IPsec SA then all=20 > packets MUST be compressed and decompressed when sent over=20 > that IPsec SA. For those packets that do not compress at all=20 > we create another IPsec SA with identical selectors, but=20 > without ROHC, and that will be used to send those packets=20 > which cannot be compressed. This will add overhead of one=20 > extra SA, but this could be used to allow running those=20 > profiles which do not have special "uncompressed" profile=20 > defined without any modification, i.e. no need to add extra=20 > 1-byte shim header or anything like that. >=20 > I.e. that is variation of the Approach 2, but in such way=20 > that there is no need to add extra headers and using extra=20 > bytes to indicate that traffic is uncompressed. If the=20 > profile already has some other header which can be used to=20 > indicate whether the packet is compressed or not (i.e. the=20 > profile field in the ROHC header) then there is no need to=20 > create that extra IPsec SA.=20 > -- > kivinen@safenet-inc.com >=20 _______________________________________________ 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 From rohc-bounces@ietf.org Mon Sep 25 09:23:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqQY-00030L-Qb; Mon, 25 Sep 2006 09:23:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRqQX-00030G-SO for rohc@ietf.org; Mon, 25 Sep 2006 09:23:17 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRqQX-0006GO-8v for rohc@ietf.org; Mon, 25 Sep 2006 09:23:17 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A8EE04F00AF; Mon, 25 Sep 2006 15:23:16 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 15:23:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec Date: Mon, 25 Sep 2006 15:23:15 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC050388A193@esealmw109.eemea.ericsson.se> In-Reply-To: <69FADB84C90B1248A7DE59422771FA0C2F8AE3@exchindia3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] FW: IPsec Processing & HCoIPsec thread-index: AcbddQic7TPTglhFSRqJFieJIp3gBAAzZ4XgAJY5ivAAAHAz4AABxY4g From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Sarkar, Biplab" , X-OriginalArrivalTime: 25 Sep 2006 13:23:16.0250 (UTC) FILETIME=[C2689FA0:01C6E0A5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Biplab and others, I also think this could be a nice solution, but I believe an explicit ROHC PROTOOL NUMBER would be preferable over an identifier that would require negotiation before its meaning can be known.=20 >From the point of view of this WG, I believe we should strive for a ROHC PROTOCOL NUMBER and develop a ROHC solution based on that.=20 /L-E ----Original Message---- From: Sarkar, Biplab [mailto:bsarkar@starentnetworks.com] Sent: den 25 september 2006 14:28 To: rohc@ietf.org Cc: Lars-Erik Jonsson (LU/EAB) Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec > ROHCers, >=20 > I believe APPROACH-1 is the most generic and neat. We can have ROHC > pkts sent as payloads in different type of packets and having a unique > IANA number would make it easy and explicit. Currently even for ROHC > over GRE for HRPD Rev-A calls, we don't have any number assigned. So > soon we would come across more and more cases where we need to get a > generic simple solution.=20 >=20 > Thanks > Biplab >=20 > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB) > [mailto:lars-erik.jonsson@ericsson.com] >=20 > Sent: Monday, September 25, 2006 5:42 PM > To: rohc@ietf.org > Subject: [rohc] FW: IPsec Processing & HCoIPsec >=20 > Forwarded from the hcoipsec mail list. Please direct also further > discussions of these issues to the ROHC WG mail list. >=20 > /L-E >=20 >=20 > ----Original Message---- > From: owner-hcoipsec@mail.vpnc.org > [mailto:owner-hcoipsec@mail.vpnc.org] On Behalf Of Jasani Rohan Sent: > den 22 september 2006 19:41 To: hcoipsec@vpnc.org; Stephen Kent; Tero > Kivinen Cc: Ertekin Emre Subject: RE: IPsec Processing & HCoIPsec >=20 >=20 > All: > I should have started this discussion on the HCoIPsec mailer list, so > I'm now including it on the list. To get others up to speed on the > discussion I've included a brief synopsis of previous emails. >=20 > Synopsis: > I originally emailed Stephen and Tero, to gather their thoughts on > leveraging a generic IANA value to indicate whether a packet contains > compressed headers. Stephen expressed that it is going to be hard to > get an IANA value allocated from the Protocol ID registry and > that this > could cause delays. Subsequently, other approaches to > achieve the same > functionality started to be discussed (approaches described below). > Currently, we are discussing Approaches 3 & 4. Note that > Approach 4 has > already been debated early on during initial development of > HCoIPsec and > was not pursued. >=20 > Stephen and Tero, do you have any concerns with Approach 3 ? If so, > could you explain some of you thoughts. >=20 > I have some concerns with Approach 4. The first being the additional > overhead of having to establish an additional SA for each > HC-enabled SA. > This can be a problem for resource constrained devices (i.e. 6lowPAN), > that want to minimize the number of SAs they have to establish. The > second being that now SAs are being generated not solely based on > security policy, but now partly based on the capabilities of the > compressor/decompressor (i.e. based on which types of traffic the > compressor/decompressor supports). >=20 > APPROACH 1: Allocation of a Generic Compressed Headers IANA Value > + A generic Compressed Headers IANA value will be allocated from the > Protocol ID Registry and will be used to indicate that > payload contains > compressed headers. > + The main drawback is the hurdle of getting a IANA value, which can > cause delays and may not even get allocated. >=20 > APPROACH 2: Leverage the "uncompressed" profile as a marker > + For ROHC, currently a packet that is ROHC compressed has a > ROHC header > with a Profiles field. This field will have a value, known as the > "uncompressed" profile, that indicates that the payload of the ROHC > compressed packet is not compressed. Therefore, this value could be > used to signal to the decompressor that it should not decompress the > packet. + For ECRTP, currently a 1-byte shim header will need to be > inserted to > identify the different ECRTP packet types. The 1-byte header will be > extended to contain a value, which we will call the "uncompressed" > profile. This functions exactly as the ROHC "uncompressed" profile > value. + The main drawback is that packets traversing an HC-enabled > SA that are > uncompressed will now have an additional few bytes used to > indicate that > the packet is uncompressed. > + In the past, HCoIPsec community members have debated this approach > against Approach 1 due to the efficiency tradeoffs. Due to > concerns of > efficiency voiced by ROHC WG & 6lowPAN WG members, through consensus > Approach 1 became the preferred approach. >=20 > APPROACH 3: Negotiate a Compressed Headers Protocol ID value local > to each SA + When each SA is established, a value agreed upon by the > peers is negotiated. This value will be analogous to the "Compressed > Headers" value and will provide the same functionality and will be > used in the similarly during processing. + Since, the ESP/AH next > header value is "local to the IPsec devices", meaning that no > intermediate nodes rely on the contents of this field, it should be > fine to use a negotiated value.=20 >=20 > APPROACH 4: Leverage 2 SAs, 1 for uncompressed traffic and one for > compressed traffic If ROHC is negotiated for the IPsec SA then all > packets MUST be compressed and decompressed when sent over that IPsec > SA. For those packets that do not compress at all we create another > IPsec SA with identical selectors, but without ROHC, and that will be > used to send those packets which cannot be compressed. This will add > overhead of one > extra SA, but this could be used to allow running those profiles which > do not have special "uncompressed" profile defined without any > modification, i.e. no need to add extra 1-byte shim header or anything > like that. I.e. that is variation of the Approach 2, but in such way > that there is no need to add extra headers and using extra bytes to > indicate that traffic is uncompressed. If the profile already has some > other header which can be used to indicate whether the packet is > compressed or not (i.e. the profile field in the ROHC header) > then there > is no need to create that extra IPsec SA. >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Sep 25 11:09:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRs5d-0001Hs-9Y; Mon, 25 Sep 2006 11:09:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRs5b-0001Hk-Dn for rohc@ietf.org; Mon, 25 Sep 2006 11:09:47 -0400 Received: from mclniron02-ext.bah.com ([156.80.1.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRs5Y-0002OQ-6A for rohc@ietf.org; Mon, 25 Sep 2006 11:09:47 -0400 Received: from mclnexbh01.resource.ds.bah.com ([156.80.7.151]) by mclniron02-ext.bah.com with ESMTP; 25 Sep 2006 11:09:20 -0400 x-SBRS: None X-REMOTE-IP: 156.80.7.151 X-IronPort-AV: i="4.09,215,1157342400"; d="scan'208"; a="67352495:sNHT24950384" Received: from MCLNEXVS05.resource.ds.bah.com ([156.80.7.123]) by mclnexbh01.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 11:09:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Sep 2006 11:09:17 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPsec Processing & HCoIPsec Thread-Index: AcbgskuQJMcObPaIQF+YizAwF/JuhAAAj95g From: "Jasani Rohan" To: X-OriginalArrivalTime: 25 Sep 2006 15:09:19.0835 (UTC) FILETIME=[9366A2B0:01C6E0B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: hcoipsec@vpnc.org Subject: [rohc] FW: IPsec Processing & HCoIPsec X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org FYI Rohan Jasani Booz | Allen | Hamilton 703.984.0337 (office) 832.452.3241 (mobile) -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Monday, September 25, 2006 10:26 AM To: Tero Kivinen Cc: Jasani Rohan; hcoipsec@vpnc.org; Ertekin Emre Subject: RE: IPsec Processing & HCoIPsec The concern Jasani cited is not a valid one, i.e., we already allow a sender to establish multiple SAs with the same traffic selectors so that the sender can use different SAs for different classes of traffic. The receiver need not be aware of this distinction.=20 However, Tero's observation is correct; we have already selected an outbound SA before we would know whether a given packet can be compressed, so it is not feasible to use two pairs of SAs to accommodate compressed vs. uncompressed traffic on a per-packet basis. So, despite my concerns about getting a new protocol ID assigned for this purpose, I agree that it is the simplest and cleanest approach. Steve _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Sep 25 11:09:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRs5j-0001Ir-MB; Mon, 25 Sep 2006 11:09:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRs5h-0001Im-Rq for rohc@ietf.org; Mon, 25 Sep 2006 11:09:53 -0400 Received: from mclniron01-ext.bah.com ([156.80.1.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRs5e-0002Os-Ff for rohc@ietf.org; Mon, 25 Sep 2006 11:09:53 -0400 Received: from mclnexbh03.resource.ds.bah.com ([156.80.7.153]) by mclniron01-ext.bah.com with ESMTP; 25 Sep 2006 11:08:57 -0400 x-SBRS: None X-REMOTE-IP: 156.80.7.153 X-IronPort-AV: i="4.09,215,1157342400"; d="scan'208"; a="78193470:sNHT65864168" Received: from MCLNEXVS05.resource.ds.bah.com ([156.80.7.123]) by mclnexbh03.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 11:08:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Sep 2006 11:08:54 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPsec Processing & HCoIPsec Thread-Index: AcbgjHGmQJkHLwwQQ/OYDjnc8IOj1gAKAESA From: "Jasani Rohan" To: X-OriginalArrivalTime: 25 Sep 2006 15:08:57.0445 (UTC) FILETIME=[860E3150:01C6E0B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: hcoipsec@vpnc.org Subject: [rohc] FW: IPsec Processing & HCoIPsec X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org FYI Rohan Jasani Booz | Allen | Hamilton 703.984.0337 (office) 832.452.3241 (mobile) -----Original Message----- From: Tero Kivinen [mailto:kivinen@safenet-inc.com]=20 Sent: Monday, September 25, 2006 6:22 AM To: Jasani Rohan Cc: hcoipsec@vpnc.org; Stephen Kent; Ertekin Emre Subject: RE: IPsec Processing & HCoIPsec Jasani Rohan writes: > Synopsis: > I originally emailed Stephen and Tero, to gather their thoughts on=20 > leveraging a generic IANA value to indicate whether a packet contains=20 > compressed headers. Stephen expressed that it is going to be hard to=20 > get an IANA value allocated from the Protocol ID registry and that=20 > this could cause delays. Subsequently, other approaches to achieve=20 > the same functionality started to be discussed (approaches described below). > Currently, we are discussing Approaches 3 & 4. Note that Approach 4=20 > has already been debated early on during initial development of=20 > HCoIPsec and was not pursued. >=20 > Stephen and Tero, do you have any concerns with Approach 3 ? If so,=20 > could you explain some of you thoughts. >=20 > I have some concerns with Approach 4. The first being the additional=20 > overhead of having to establish an additional SA for each HC-enabled SA. > This can be a problem for resource constrained devices (i.e. 6lowPAN), > that want to minimize the number of SAs they have to establish. The=20 > second being that now SAs are being generated not solely based on=20 > security policy, but now partly based on the capabilities of the=20 > compressor/decompressor (i.e. based on which types of traffic the=20 > compressor/decompressor supports). Actually now after thinking about the issue a bit, I do not think the Approach 4 fits at all on the IPsec architecture. The problem there is that the architecture with IPsec and ROHC is like this: Unprotected Interface ^ | (nested SAs)+----------+ ------------|Forwarding|<---------------------------+ | +----------+ | | ^ | | | BYPASS | V +-----+ +=3D=3DPROCESS = AH/ESP=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D+ +-------+ | SPD | | +------+ +--------+ +-------+ | .| SPD-I |.........|Cache|..|..|Tunnel|..| ROCH |..| ESP |..|..IPsec | (*) | | (*) |---->|encaps|->|compress|->|Encrypt| | boundary +-------+ +-----+ | +------+ +--------+ +-------+ | | +-------+ / ^ = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | |DISCARD|<--/ | | +-------+ | | | | +-------------+ |--------->|SPD Selection| +-------------+ ^ | +------+ | -->| ICMP | | / +------+ |/ | | Protected Interface I.e. after the SPD Cache is used to select the SA we go through the ROHC processing, and then ESP encryption. The problem is that we have already selected SA when we enter the ROCH processing, so we cannot change it anymore. So I think the approach 4 does not really fit the architecture and should be rejected because of that. There is no problem on the inbound case, only in this outbound case.=20 > APPROACH 1: Allocation of a Generic Compressed Headers IANA Value > + A generic Compressed Headers IANA value will be allocated from the > Protocol ID Registry and will be used to indicate that payload=20 > contains compressed headers. > + The main drawback is the hurdle of getting a IANA value, which can > cause delays and may not even get allocated. I actually still think this is the best approach, even when it means that we need to one protocol ID number from IANA. > APPROACH 2: Leverage the "uncompressed" profile as a marker > + For ROHC, currently a packet that is ROHC compressed has a ROHC=20 > + header > with a Profiles field. This field will have a value, known as the=20 > "uncompressed" profile, that indicates that the payload of the ROHC=20 > compressed packet is not compressed. Therefore, this value could be=20 > used to signal to the decompressor that it should not decompress the=20 > packet. > + For ECRTP, currently a 1-byte shim header will need to be inserted=20 > + to > identify the different ECRTP packet types. The 1-byte header will be=20 > extended to contain a value, which we will call the "uncompressed" > profile. This functions exactly as the ROHC "uncompressed" profile=20 > value. > + The main drawback is that packets traversing an HC-enabled SA that=20 > + are > uncompressed will now have an additional few bytes used to indicate=20 > that the packet is uncompressed. > + In the past, HCoIPsec community members have debated this approach > against Approach 1 due to the efficiency tradeoffs. Due to concerns=20 > of efficiency voiced by ROHC WG & 6lowPAN WG members, through=20 > consensus Approach 1 became the preferred approach. >=20 > APPROACH 3: Negotiate a Compressed Headers Protocol ID value local to > each SA > + When each SA is established, a value agreed upon by the peers is > negotiated. This value will be analogous to the "Compressed Headers" > value and will provide the same functionality and will be used in the=20 > similarly during processing. > + Since, the ESP/AH next header value is "local to the IPsec devices", > meaning that no intermediate nodes rely on the contents of this field, > it should be fine to use a negotiated value. The problem this approach is that it is complicated and can cause some problems as it will always limit one protocol value from the SA. i.e. if the SA has traffic selectors of the any protocol <-> any protocol, then we need to pick one protocol number which is reserved for this "compressed headers" value, and how we make sure we do not pick some number that might actually be used by the traffic. The easiest way to make sure of that would be to reserve number from IANA, i.e. back to approach 1... > APPROACH 4: Leverage 2 SAs, 1 for uncompressed traffic and one for=20 > compressed traffic If ROHC is negotiated for the IPsec SA then all=20 > packets MUST be compressed and decompressed when sent over that IPsec=20 > SA. For those packets that do not compress at all we create another=20 > IPsec SA with identical selectors, but without ROHC, and that will be=20 > used to send those packets which cannot be compressed. This will add=20 > overhead of one extra SA, but this could be used to allow running=20 > those profiles which do not have special "uncompressed" profile=20 > defined without any modification, i.e. no need to add extra 1-byte=20 > shim header or anything like that. I.e. that is variation of the=20 > Approach 2, but in such way that there is no need to add extra headers > and using extra bytes to indicate that traffic is uncompressed. If the > profile already has some other header which can be used to indicate=20 > whether the packet is compressed or not (i.e. the profile field in the > ROHC header) then there is no need to create that extra IPsec SA. As I explained earlier, that this does not really fit to the IPsec architecture.=20 -- kivinen@safenet-inc.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Sep 25 11:14:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsAM-0002K5-Pl; Mon, 25 Sep 2006 11:14:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsAL-0002Jq-Pt for rohc@ietf.org; Mon, 25 Sep 2006 11:14:41 -0400 Received: from mclniron01-ext.bah.com ([156.80.1.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRsAG-0005Bp-K8 for rohc@ietf.org; Mon, 25 Sep 2006 11:14:41 -0400 Received: from mclnexbh03.resource.ds.bah.com ([156.80.7.153]) by mclniron01-ext.bah.com with ESMTP; 25 Sep 2006 11:13:33 -0400 x-SBRS: None X-REMOTE-IP: 156.80.7.153 X-IronPort-AV: i="4.09,215,1157342400"; d="scan'208"; a="78195153:sNHT2974790478" Received: from MCLNEXVS05.resource.ds.bah.com ([156.80.7.123]) by mclnexbh03.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 11:13:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Sep 2006 11:13:30 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPsec Processing & HCoIPsec Thread-Index: AcbgjHGmQJkHLwwQQ/OYDjnc8IOj1gAKI2hA From: "Jasani Rohan" To: "Tero Kivinen" , X-OriginalArrivalTime: 25 Sep 2006 15:13:32.0910 (UTC) FILETIME=[2A3ED0E0:01C6E0B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: Stephen Kent , hcoipsec@vpnc.org Subject: [rohc] RE: IPsec Processing & HCoIPsec X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Tero: I agree with your explanation on Approach 4 and seems Approach 1 is the preferred approach. Rohan Jasani Booz | Allen | Hamilton 703.984.0337 (office) 832.452.3241 (mobile) =20 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@safenet-inc.com]=20 > Sent: Monday, September 25, 2006 6:22 AM > To: Jasani Rohan > Cc: hcoipsec@vpnc.org; Stephen Kent; Ertekin Emre > Subject: RE: IPsec Processing & HCoIPsec >=20 > Jasani Rohan writes: > > Synopsis: > > I originally emailed Stephen and Tero, to gather their thoughts on=20 > > leveraging a generic IANA value to indicate whether a=20 > packet contains=20 > > compressed headers. Stephen expressed that it is going to=20 > be hard to=20 > > get an IANA value allocated from the Protocol ID registry and that=20 > > this could cause delays. Subsequently, other approaches to achieve=20 > > the same functionality started to be discussed (approaches=20 > described below). > > Currently, we are discussing Approaches 3 & 4. Note that=20 > Approach 4=20 > > has already been debated early on during initial development of=20 > > HCoIPsec and was not pursued. > >=20 > > Stephen and Tero, do you have any concerns with Approach 3=20 > ? If so,=20 > > could you explain some of you thoughts. > >=20 > > I have some concerns with Approach 4. The first being the=20 > additional=20 > > overhead of having to establish an additional SA for each=20 > HC-enabled SA. > > This can be a problem for resource constrained devices=20 > (i.e. 6lowPAN),=20 > > that want to minimize the number of SAs they have to=20 > establish. The=20 > > second being that now SAs are being generated not solely based on=20 > > security policy, but now partly based on the capabilities of the=20 > > compressor/decompressor (i.e. based on which types of traffic the=20 > > compressor/decompressor supports). >=20 > Actually now after thinking about the issue a bit, I do not=20 > think the Approach 4 fits at all on the IPsec architecture.=20 > The problem there is that the architecture with IPsec and=20 > ROHC is like this: >=20 > Unprotected Interface > ^ > | > (nested SAs)+----------+ > ------------|Forwarding|<---------------------------+ > | +----------+ | > | ^ | > | | BYPASS | > V +-----+ +=3D=3DPROCESS = AH/ESP=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D+ > +-------+ | SPD | | +------+ +--------+ +-------+ | > .| SPD-I |.........|Cache|..|..|Tunnel|..| ROCH |..| ESP =20 > |..|..IPsec > | (*) | | (*)=20 > |---->|encaps|->|compress|->|Encrypt| | boundary > +-------+ +-----+ | +------+ +--------+ +-------+ | > | +-------+ / ^ = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > | |DISCARD|<--/ | > | +-------+ | > | | > | +-------------+ > |--------->|SPD Selection| > +-------------+ > ^ > | +------+ > | -->| ICMP | > | / +------+ > |/ > | > | > Protected Interface >=20 >=20 > I.e. after the SPD Cache is used to select the SA we go=20 > through the ROHC processing, and then ESP encryption. The=20 > problem is that we have already selected SA when we enter the=20 > ROCH processing, so we cannot change it anymore. So I think=20 > the approach 4 does not really fit the architecture and=20 > should be rejected because of that. >=20 > There is no problem on the inbound case, only in this outbound case.=20 >=20 > > APPROACH 1: Allocation of a Generic Compressed Headers IANA Value > > + A generic Compressed Headers IANA value will be allocated from the > > Protocol ID Registry and will be used to indicate that payload=20 > > contains compressed headers. > > + The main drawback is the hurdle of getting a IANA value, which can > > cause delays and may not even get allocated. >=20 > I actually still think this is the best approach, even when=20 > it means that we need to one protocol ID number from IANA. >=20 > > APPROACH 2: Leverage the "uncompressed" profile as a marker > > + For ROHC, currently a packet that is ROHC compressed has a ROHC=20 > > + header > > with a Profiles field. This field will have a value, known as the=20 > > "uncompressed" profile, that indicates that the payload of the ROHC=20 > > compressed packet is not compressed. Therefore, this value=20 > could be=20 > > used to signal to the decompressor that it should not=20 > decompress the=20 > > packet. > > + For ECRTP, currently a 1-byte shim header will need to be=20 > inserted=20 > > + to > > identify the different ECRTP packet types. The 1-byte=20 > header will be=20 > > extended to contain a value, which we will call the "uncompressed" > > profile. This functions exactly as the ROHC "uncompressed" profile=20 > > value. > > + The main drawback is that packets traversing an=20 > HC-enabled SA that=20 > > + are > > uncompressed will now have an additional few bytes used to indicate=20 > > that the packet is uncompressed. > > + In the past, HCoIPsec community members have debated this approach > > against Approach 1 due to the efficiency tradeoffs. Due to=20 > concerns=20 > > of efficiency voiced by ROHC WG & 6lowPAN WG members, through=20 > > consensus Approach 1 became the preferred approach. > >=20 > > APPROACH 3: Negotiate a Compressed Headers Protocol ID=20 > value local to=20 > > each SA > > + When each SA is established, a value agreed upon by the peers is > > negotiated. This value will be analogous to the=20 > "Compressed Headers" > > value and will provide the same functionality and will be=20 > used in the=20 > > similarly during processing. > > + Since, the ESP/AH next header value is "local to the=20 > IPsec devices", > > meaning that no intermediate nodes rely on the contents of=20 > this field,=20 > > it should be fine to use a negotiated value. >=20 > The problem this approach is that it is complicated and can=20 > cause some problems as it will always limit one protocol=20 > value from the SA. i.e. > if the SA has traffic selectors of the any protocol <-> any=20 > protocol, then we need to pick one protocol number which is=20 > reserved for this "compressed headers" value, and how we make=20 > sure we do not pick some number that might actually be used=20 > by the traffic. The easiest way to make sure of that would be=20 > to reserve number from IANA, i.e. back to approach 1... >=20 > > APPROACH 4: Leverage 2 SAs, 1 for uncompressed traffic and one for=20 > > compressed traffic If ROHC is negotiated for the IPsec SA then all=20 > > packets MUST be compressed and decompressed when sent over=20 > that IPsec=20 > > SA. For those packets that do not compress at all we create another=20 > > IPsec SA with identical selectors, but without ROHC, and=20 > that will be=20 > > used to send those packets which cannot be compressed. This=20 > will add=20 > > overhead of one extra SA, but this could be used to allow running=20 > > those profiles which do not have special "uncompressed" profile=20 > > defined without any modification, i.e. no need to add extra 1-byte=20 > > shim header or anything like that. I.e. that is variation of the=20 > > Approach 2, but in such way that there is no need to add=20 > extra headers=20 > > and using extra bytes to indicate that traffic is=20 > uncompressed. If the=20 > > profile already has some other header which can be used to indicate=20 > > whether the packet is compressed or not (i.e. the profile=20 > field in the=20 > > ROHC header) then there is no need to create that extra IPsec SA. >=20 > As I explained earlier, that this does not really fit to the=20 > IPsec architecture.=20 > -- > kivinen@safenet-inc.com >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Sep 25 11:19:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsEb-00039D-SM; Mon, 25 Sep 2006 11:19:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsEa-000390-Ku for rohc@ietf.org; Mon, 25 Sep 2006 11:19:04 -0400 Received: from mclniron01-ext.bah.com ([156.80.1.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRsEZ-0005ib-6O for rohc@ietf.org; Mon, 25 Sep 2006 11:19:04 -0400 Received: from mclnexbh03.resource.ds.bah.com ([156.80.7.153]) by mclniron01-ext.bah.com with ESMTP; 25 Sep 2006 11:18:21 -0400 x-SBRS: None X-REMOTE-IP: 156.80.7.153 X-IronPort-AV: i="4.09,215,1157342400"; d="scan'208"; a="78197293:sNHT36690452" Received: from MCLNEXVS05.resource.ds.bah.com ([156.80.7.123]) by mclnexbh03.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 11:18:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec Date: Mon, 25 Sep 2006 11:18:20 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] FW: IPsec Processing & HCoIPsec Thread-Index: AcbddQic7TPTglhFSRqJFieJIp3gBAAzZ4XgAJY5ivAAAHAz4AABxY4gAAQ+H6A= From: "Jasani Rohan" To: "Lars-Erik Jonsson \(LU/EAB\)" , "Sarkar, Biplab" , X-OriginalArrivalTime: 25 Sep 2006 15:18:21.0587 (UTC) FILETIME=[D64F6E30:01C6E0B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org All: Just to be clear, Approach 1 will allocate a "generic" compressed headers IANA protocol ID value (not specific to a particular header compression scheme). Therefore, some other mechanism will need to identify whether the compressed headers where compressed by ROHC, ECRTP, etc. Rohan Jasani Booz | Allen | Hamilton 703.984.0337 (office) 832.452.3241 (mobile) =20 > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB)=20 > [mailto:lars-erik.jonsson@ericsson.com]=20 > Sent: Monday, September 25, 2006 9:23 AM > To: Sarkar, Biplab; rohc@ietf.org > Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec >=20 > Biplab and others, >=20 > I also think this could be a nice solution, but I believe an=20 > explicit ROHC PROTOOL NUMBER would be preferable over an=20 > identifier that would require negotiation before its meaning=20 > can be known.=20 >=20 > >From the point of view of this WG, I believe we should strive > for a ROHC PROTOCOL NUMBER and develop a ROHC solution based on that.=20 >=20 > /L-E >=20 >=20 > ----Original Message---- > From: Sarkar, Biplab [mailto:bsarkar@starentnetworks.com] > Sent: den 25 september 2006 14:28 > To: rohc@ietf.org > Cc: Lars-Erik Jonsson (LU/EAB) > Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec >=20 > > ROHCers, > >=20 > > I believe APPROACH-1 is the most generic and neat. We can=20 > have ROHC=20 > > pkts sent as payloads in different type of packets and=20 > having a unique=20 > > IANA number would make it easy and explicit. Currently even=20 > for ROHC=20 > > over GRE for HRPD Rev-A calls, we don't have any number=20 > assigned. So=20 > > soon we would come across more and more cases where we need=20 > to get a=20 > > generic simple solution. > >=20 > > Thanks > > Biplab > >=20 > > -----Original Message----- > > From: Lars-Erik Jonsson (LU/EAB) > > [mailto:lars-erik.jonsson@ericsson.com] > >=20 > > Sent: Monday, September 25, 2006 5:42 PM > > To: rohc@ietf.org > > Subject: [rohc] FW: IPsec Processing & HCoIPsec > >=20 > > Forwarded from the hcoipsec mail list. Please direct also further=20 > > discussions of these issues to the ROHC WG mail list. > >=20 > > /L-E > >=20 > >=20 > > ----Original Message---- > > From: owner-hcoipsec@mail.vpnc.org > > [mailto:owner-hcoipsec@mail.vpnc.org] On Behalf Of Jasani=20 > Rohan Sent: > > den 22 september 2006 19:41 To: hcoipsec@vpnc.org; Stephen=20 > Kent; Tero=20 > > Kivinen Cc: Ertekin Emre Subject: RE: IPsec Processing & HCoIPsec > >=20 > >=20 > > All: > > I should have started this discussion on the HCoIPsec=20 > mailer list, so=20 > > I'm now including it on the list. To get others up to speed on the=20 > > discussion I've included a brief synopsis of previous emails. > >=20 > > Synopsis: > > I originally emailed Stephen and Tero, to gather their thoughts on=20 > > leveraging a generic IANA value to indicate whether a=20 > packet contains=20 > > compressed headers. Stephen expressed that it is going to=20 > be hard to=20 > > get an IANA value allocated from the Protocol ID registry and that=20 > > this could cause delays. Subsequently, other approaches to achieve=20 > > the same functionality started to be discussed (approaches=20 > described=20 > > below). > > Currently, we are discussing Approaches 3 & 4. Note that=20 > Approach 4=20 > > has already been debated early on during initial development of=20 > > HCoIPsec and was not pursued. > >=20 > > Stephen and Tero, do you have any concerns with Approach 3=20 > ? If so,=20 > > could you explain some of you thoughts. > >=20 > > I have some concerns with Approach 4. The first being the=20 > additional=20 > > overhead of having to establish an additional SA for each=20 > HC-enabled=20 > > SA. > > This can be a problem for resource constrained devices=20 > (i.e. 6lowPAN),=20 > > that want to minimize the number of SAs they have to=20 > establish. The=20 > > second being that now SAs are being generated not solely based on=20 > > security policy, but now partly based on the capabilities of the=20 > > compressor/decompressor (i.e. based on which types of traffic the=20 > > compressor/decompressor supports). > >=20 > > APPROACH 1: Allocation of a Generic Compressed Headers IANA Value > > + A generic Compressed Headers IANA value will be allocated from the > > Protocol ID Registry and will be used to indicate that payload=20 > > contains compressed headers. > > + The main drawback is the hurdle of getting a IANA value, which can > > cause delays and may not even get allocated. > >=20 > > APPROACH 2: Leverage the "uncompressed" profile as a marker > > + For ROHC, currently a packet that is ROHC compressed has a > > ROHC header > > with a Profiles field. This field will have a value, known as the=20 > > "uncompressed" profile, that indicates that the payload of the ROHC=20 > > compressed packet is not compressed. Therefore, this value=20 > could be=20 > > used to signal to the decompressor that it should not=20 > decompress the=20 > > packet. + For ECRTP, currently a 1-byte shim header will need to be=20 > > inserted to identify the different ECRTP packet types. The 1-byte=20 > > header will be extended to contain a value, which we will call the=20 > > "uncompressed" > > profile. This functions exactly as the ROHC "uncompressed" profile=20 > > value. + The main drawback is that packets traversing an=20 > HC-enabled SA=20 > > that are uncompressed will now have an additional few bytes used to=20 > > indicate that the packet is uncompressed. > > + In the past, HCoIPsec community members have debated this approach > > against Approach 1 due to the efficiency tradeoffs. Due to=20 > concerns=20 > > of efficiency voiced by ROHC WG & 6lowPAN WG members, through=20 > > consensus Approach 1 became the preferred approach. > >=20 > > APPROACH 3: Negotiate a Compressed Headers Protocol ID=20 > value local to=20 > > each SA + When each SA is established, a value agreed upon by the=20 > > peers is negotiated. This value will be analogous to the=20 > "Compressed=20 > > Headers" value and will provide the same functionality and will be=20 > > used in the similarly during processing. + Since, the ESP/AH next=20 > > header value is "local to the IPsec devices", meaning that no=20 > > intermediate nodes rely on the contents of this field, it should be=20 > > fine to use a negotiated value. > >=20 > > APPROACH 4: Leverage 2 SAs, 1 for uncompressed traffic and one for=20 > > compressed traffic If ROHC is negotiated for the IPsec SA then all=20 > > packets MUST be compressed and decompressed when sent over=20 > that IPsec=20 > > SA. For those packets that do not compress at all we create another=20 > > IPsec SA with identical selectors, but without ROHC, and=20 > that will be=20 > > used to send those packets which cannot be compressed. This=20 > will add=20 > > overhead of one extra SA, but this could be used to allow running=20 > > those profiles which do not have special "uncompressed" profile=20 > > defined without any modification, i.e. no need to add extra 1-byte=20 > > shim header or anything like that. I.e. that is variation of the=20 > > Approach 2, but in such way that there is no need to add=20 > extra headers=20 > > and using extra bytes to indicate that traffic is=20 > uncompressed. If the=20 > > profile already has some other header which can be used to indicate=20 > > whether the packet is compressed or not (i.e. the profile=20 > field in the=20 > > ROHC header) then there is no need to create that extra IPsec SA. > >=20 >=20 > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www1.ietf.org/mailman/listinfo/rohc >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Sep 25 11:23:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsJ1-00040n-3E; Mon, 25 Sep 2006 11:23:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrnk-0001rD-8B; Mon, 25 Sep 2006 10:51:20 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRrmT-0002RG-VS; Mon, 25 Sep 2006 10:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id E5785328A9; Mon, 25 Sep 2006 14:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GRrmT-0005IU-PM; Mon, 25 Sep 2006 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 25 Sep 2006 10:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-rfc3095bis-improvements-03.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org --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 : Improvements for the ROHC Profile Set Update Author(s) : L. Jonsson Filename : draft-ietf-rohc-rfc3095bis-improvements-03.txt Pages : 10 Date : 2006-9-25 RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles. Now with 5 years of ROHC experience, it has been decided to revise RFC 3095 through the development of an updated profile set. This document collects all improvements that have been agreed to be addressed by this updated and improved ROHC revision. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rfc3095bis-improvements-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-rohc-rfc3095bis-improvements-03.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-ietf-rohc-rfc3095bis-improvements-03.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: <2006-9-25065121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rfc3095bis-improvements-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rfc3095bis-improvements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-25065121.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Mon Sep 25 11:23:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsJ2-000415-Qb; Mon, 25 Sep 2006 11:23:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrnk-0001rD-A5; Mon, 25 Sep 2006 10:51:20 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRrmT-0002RF-V9; Mon, 25 Sep 2006 10:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id E51B526E28; Mon, 25 Sep 2006 14:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GRrmT-0005IR-Ol; Mon, 25 Sep 2006 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 25 Sep 2006 10:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-rtp-impl-guide-20.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org --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 : RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095 Author(s) : L. Jonsson, et al. Filename : draft-ietf-rohc-rtp-impl-guide-20.txt Pages : 29 Date : 2006-9-25 RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP, UDP, RTP, and ESP. Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UPD-Lite profiles) are also provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-guide-20.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-rohc-rtp-impl-guide-20.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-ietf-rohc-rtp-impl-guide-20.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: <2006-9-25064856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-20.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rtp-impl-guide-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-25064856.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Mon Sep 25 11:23:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsJ1-00040n-3E; Mon, 25 Sep 2006 11:23:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrnk-0001rD-8B; Mon, 25 Sep 2006 10:51:20 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRrmT-0002RG-VS; Mon, 25 Sep 2006 10:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id E5785328A9; Mon, 25 Sep 2006 14:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GRrmT-0005IU-PM; Mon, 25 Sep 2006 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 25 Sep 2006 10:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-rfc3095bis-improvements-03.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org --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 : Improvements for the ROHC Profile Set Update Author(s) : L. Jonsson Filename : draft-ietf-rohc-rfc3095bis-improvements-03.txt Pages : 10 Date : 2006-9-25 RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles. Now with 5 years of ROHC experience, it has been decided to revise RFC 3095 through the development of an updated profile set. This document collects all improvements that have been agreed to be addressed by this updated and improved ROHC revision. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rfc3095bis-improvements-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-rohc-rfc3095bis-improvements-03.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-ietf-rohc-rfc3095bis-improvements-03.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: <2006-9-25065121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rfc3095bis-improvements-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rfc3095bis-improvements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-25065121.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Mon Sep 25 11:23:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsJ2-000415-Qb; Mon, 25 Sep 2006 11:23:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRrnk-0001rD-A5; Mon, 25 Sep 2006 10:51:20 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRrmT-0002RF-V9; Mon, 25 Sep 2006 10:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id E51B526E28; Mon, 25 Sep 2006 14:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GRrmT-0005IR-Ol; Mon, 25 Sep 2006 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 25 Sep 2006 10:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-rtp-impl-guide-20.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org --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 : RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095 Author(s) : L. Jonsson, et al. Filename : draft-ietf-rohc-rtp-impl-guide-20.txt Pages : 29 Date : 2006-9-25 RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP, UDP, RTP, and ESP. Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) and RFC 4109 (ROHC UPD-Lite profiles) are also provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rtp-impl-guide-20.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-rohc-rtp-impl-guide-20.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-ietf-rohc-rtp-impl-guide-20.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: <2006-9-25064856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-rtp-impl-guide-20.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-rtp-impl-guide-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-25064856.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Mon Sep 25 12:05:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsxe-00021E-21; Mon, 25 Sep 2006 12:05:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRsxc-000218-Bq for rohc@ietf.org; Mon, 25 Sep 2006 12:05:36 -0400 Received: from mclniron02-ext.bah.com ([156.80.1.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRsxa-000409-4M for rohc@ietf.org; Mon, 25 Sep 2006 12:05:36 -0400 Received: from mclnexbh03.resource.ds.bah.com ([156.80.7.153]) by mclniron02-ext.bah.com with ESMTP; 25 Sep 2006 12:05:34 -0400 x-SBRS: None X-REMOTE-IP: 156.80.7.153 X-IronPort-AV: i="4.09,215,1157342400"; d="scan'208"; a="67374439:sNHT20797808" Received: from MCLNEXVS05.resource.ds.bah.com ([156.80.7.123]) by mclnexbh03.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Sep 2006 12:05:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Sep 2006 12:05:32 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPsec Processing & HCoIPsec Thread-Index: AcbgskuQJMcObPaIQF+YizAwF/JuhAAAMT8Q From: "Jasani Rohan" To: "Stephen Kent" , "Tero Kivinen" , X-OriginalArrivalTime: 25 Sep 2006 16:05:34.0037 (UTC) FILETIME=[6E950050:01C6E0BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: hcoipsec@vpnc.org Subject: [rohc] RE: IPsec Processing & HCoIPsec X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Stephen: I've included my comments inline. Thanks Rohan Jasani Booz | Allen | Hamilton 703.984.0337 (office) 832.452.3241 (mobile) > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com]=20 > Sent: Monday, September 25, 2006 10:26 AM > To: Tero Kivinen > Cc: Jasani Rohan; hcoipsec@vpnc.org; Ertekin Emre > Subject: RE: IPsec Processing & HCoIPsec >=20 >=20 > The concern Jasani cited is not a valid one, i.e., we already=20 > allow a sender to establish multiple SAs with the same=20 > traffic selectors so that the sender can use different SAs=20 > for different classes of traffic. The receiver need not be=20 > aware of this distinction.=20 I understand what you are saying now. > However, Tero's observation is correct; we have already=20 > selected an outbound SA before we would know whether a given=20 > packet can be compressed, so it is not feasible to use two=20 > pairs of SAs to accommodate compressed vs. uncompressed=20 > traffic on a per-packet basis. Correct, I agree. > So, despite my concerns about getting a new protocol ID=20 > assigned for this purpose, I agree that it is the simplest=20 > and cleanest approach. Looks like you, Tero, Emre and I prefer Approach 1, which is to allocate a generic compressed headers IANA value. Thanks for the input. > Steve >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Mon Sep 25 16:17:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRwsq-0008JY-33; Mon, 25 Sep 2006 16:16:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GRwsp-0008Hl-9j for rohc@ietf.org; Mon, 25 Sep 2006 16:16:55 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GRwsm-00071n-Vt for rohc@ietf.org; Mon, 25 Sep 2006 16:16:55 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 25 Sep 2006 13:16:52 -0700 X-IronPort-AV: i="4.09,215,1157353200"; d="scan'208"; a="325104855:sNHT33824636" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8PKGqr5005983; Mon, 25 Sep 2006 13:16:52 -0700 Received: from [10.32.241.25] ([10.32.241.25]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8PKGpML010804; Mon, 25 Sep 2006 13:16:51 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jan Vilhuber Date: Mon, 25 Sep 2006 13:16:50 -0700 To: Jasani Rohan X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1840; t=1159215412; x=1160079412; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vilhuber@cisco.com; z=From:Jan=20Vilhuber=20 |Subject:Re=3A=20IPsec=20Processing=20&=20HCoIPsec; X=v=3Dcisco.com=3B=20h=3DZBO4R+xscLKSCUZPiFlRzV9yd5o=3D; b=UdJarchKY2bfSvd51I4SOV6ls9n6g8LL5yoNfAujZHhSJ8CEc7nzEC2pCzA1w7uLe+XlocAb 8emk1XZABeQ2U92d3v74w6E5zrh2PPcbBdINCRd3JQeT967NxgiGplU7; Authentication-Results: sj-dkim-6.cisco.com; header.From=vilhuber@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: rohc@ietf.org, Tero Kivinen , Stephen Kent , hcoipsec@vpnc.org Subject: [rohc] Re: IPsec Processing & HCoIPsec X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org On Sep 25, 2006, at 9:05 AM, Jasani Rohan wrote: > > Stephen: > I've included my comments inline. Thanks > > Rohan Jasani > Booz | Allen | Hamilton > 703.984.0337 (office) > 832.452.3241 (mobile) > >> -----Original Message----- >> From: Stephen Kent [mailto:kent@bbn.com] >> Sent: Monday, September 25, 2006 10:26 AM >> To: Tero Kivinen >> Cc: Jasani Rohan; hcoipsec@vpnc.org; Ertekin Emre >> Subject: RE: IPsec Processing & HCoIPsec >> >> >> The concern Jasani cited is not a valid one, i.e., we already >> allow a sender to establish multiple SAs with the same >> traffic selectors so that the sender can use different SAs >> for different classes of traffic. The receiver need not be >> aware of this distinction. > > I understand what you are saying now. > >> However, Tero's observation is correct; we have already >> selected an outbound SA before we would know whether a given >> packet can be compressed, so it is not feasible to use two >> pairs of SAs to accommodate compressed vs. uncompressed >> traffic on a per-packet basis. > > Correct, I agree. > >> So, despite my concerns about getting a new protocol ID >> assigned for this purpose, I agree that it is the simplest >> and cleanest approach. > > Looks like you, Tero, Emre and I prefer Approach 1, which is to > allocate > a generic compressed headers IANA value. Thanks for the input. > I'm still not convinced this is needed. Since the protocol ID is relevant ONLY to the two IPsec endpoints, it should be entirely feasible to just pick a random one out of a hat (making sure it doesn't conflict with any actual traffic on the ipsec-'link') and use that. There's quite a few IANA protocol numbers that are latent, not used, or whatever. Pick one and use it. No need to trouble IANA about it. jan _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Sep 26 02:03:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS62J-0000C1-DQ; Tue, 26 Sep 2006 02:03:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS62I-00009b-8D for rohc@ietf.org; Tue, 26 Sep 2006 02:03:18 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS62G-0002m4-Uf for rohc@ietf.org; Tue, 26 Sep 2006 02:03:18 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 626FE8E0001 for ; Tue, 26 Sep 2006 08:03:16 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 08:03:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Sep 2006 08:03:14 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC05038C7E3C@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC05025F6D17@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last-call for the RFC 3095 Implementer's Guide - Again thread-index: AcWBfpiBH7q6bmijRtOCPRbgqYOyTgXeCICQKBXJ2eAozcmO8A== From: "Lars-Erik Jonsson \(LU/EAB\)" To: X-OriginalArrivalTime: 26 Sep 2006 06:03:16.0075 (UTC) FILETIME=[75175BB0:01C6E131] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [rohc] WG last-call for the RFC 3095 Implementer's Guide - Again X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org ROHCers, =20 Since the previous WGLC attempt for this draft, the draft has been through a significant re-work, mainly editorial but also some additional technical issues with RFC 3095 have been discovered and resolved. This document is important to ensure RFC 3095 implementations can be made interoperable, and we believe it should now be taken further for RFC publication. We are therefore now issuing a third working group last-call on the following document: =20 draft-ietf-rohc-rtp-impl-guide-20.txt (for publication as Proposed Standard) =20 This will be the usual two-week WG last-call as suggested in RFC 2418. Please direct last-call comments to the ROHC mailing list rohc@ietf.org before Tue, 2006-10-10, 18:00 UTC. =20 Rgds, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Sep 26 03:43:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS7bK-0003AV-Gq; Tue, 26 Sep 2006 03:43:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GS7bJ-0003AQ-ML for rohc@ietf.org; Tue, 26 Sep 2006 03:43:33 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GS7bD-0000Ob-2M for rohc@ietf.org; Tue, 26 Sep 2006 03:43:33 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7CD654F0057; Tue, 26 Sep 2006 09:42:29 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 09:42:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec Date: Tue, 26 Sep 2006 09:42:27 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC05038C8062@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] FW: IPsec Processing & HCoIPsec thread-index: AcbddQic7TPTglhFSRqJFieJIp3gBAAzZ4XgAJY5ivAAAHAz4AABxY4gAAQ+H6AAH9q5YA== From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Jasani Rohan" , X-OriginalArrivalTime: 26 Sep 2006 07:42:28.0813 (UTC) FILETIME=[513317D0:01C6E13F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org > All: > Just to be clear, Approach 1 will allocate a "generic" compressed > headers IANA protocol ID value (not specific to a particular header > compression scheme).=20 This I think is an open question. If a PROTOCOL NUMBER is assigned, its usage scope will not necessarily be limited to HCoIPsec. Having a "generic" identifier for "header compressed packet" means the identifier itself says nothing without some negotiated state. I believe that would be unfortunate. We need to see the whole picture here, the discussion about "APPROACH 1-4" has not been very clear about which problem is addressed. I believe we are mixing different problems and various approaches solved these problems more or less completely. Applying header compression over anything requires two things: 1) a logical channel for the header-compressed packets only, for some schemes a set of such logical channels is needed since the schemes can not identify their own different packet types (as they are actually designed for HDLC encapsulation). 2) a mechanism for negotiation of the header compression channel state. While 2) is solved through the IKEv2 extension, 1) is not completely solved by any of the suggested approaches. Let's look at the first problem in detail, what is it about? 1a) Identify compressed header packets * all packets sent over the link can be one option. * otherwise a mechanism to create logical channels is needed. * for ROHC, only one such logical channel would be needed, while other schemes require a set of logical channels. 1b) What if both compressed and uncompressed traffic is to be multiplexed? * with ROHC this can be handled in a ROHC-only channel,=20 by making use of the uncompressed profile. * in an IP tunnel, one single additional protocol identifier would be enough to solve the whole problem for ROHC, while having support also for other schemes would mean multiple identifiers or additional mechanism are needed. So, we need to address the question whether we should really cover also non-ROHC schemes? If so, we will have to face the fact that all the suggested approaches provides incomplete solutions, as ECRTP et. al requires additional functionality to identify their different packet formats. Further, in an IP-tunnel, I assume reordering is a reality, and what does that mean for IP-HC/CRTP/ECRTP? For ROHC, reordering has been investigated, key problem areas identified and solutions provided by RFC 4224. Enhanced ROHC profiles are also on their way with built-in robustness to reordering. For IP-HC/CRTP/ECRTP, we know there are problems, but there is no guidance for how to handle those problems. If we had been able to easily include support for the old schemes along with ROHC, and if there had been convincing arguments supporting the usefulness of those schemes in an environment where reordering can occur, I had supported that. However, as I see it now, this is not the case. By "only" addressing ROHC, which is the general header compression platform, the solution becomes more straight- forward and we will not have to invent additional mechanisms to support schemes that we do not even know for sure if/how they can be made to work in these scenarios. Rgds, /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Tue Sep 26 15:47:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSItM-0005sb-B3; Tue, 26 Sep 2006 15:46:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSItK-0005qd-Pj for rohc@ietf.org; Tue, 26 Sep 2006 15:46:54 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSItJ-0005Py-G8 for rohc@ietf.org; Tue, 26 Sep 2006 15:46:54 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k8QJkmoK023673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Sep 2006 12:46:50 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k8QJkfg3010408; Tue, 26 Sep 2006 12:46:46 -0700 (PDT) Received: from NAEX09.na.qualcomm.com ([10.46.56.84]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 12:46:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] RoHCv2 and Timer-based compression of RTP Timestamp Date: Tue, 26 Sep 2006 12:46:43 -0700 Message-ID: In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0503889A38@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] RoHCv2 and Timer-based compression of RTP Timestamp Thread-Index: AcbYu0uMg+fhLSZZRlKwM0WY8ezqpQABI/5gAWxS5iAACjzVgAB0YXsAAE4U3ZA= From: "Kapoor, Rohit" To: "Lars-Erik Jonsson \(LU/EAB\)" , X-OriginalArrivalTime: 26 Sep 2006 19:46:43.0585 (UTC) FILETIME=[7E431710:01C6E1A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Lars-Erik, >=20 > I will not question your results, just conclude that this > is rather depressing news. It means systems are still not > built for true IP networking, but with a circuit-based > approach, optimizing for voice. I really thought that way > of building network links was becoming history. >=20 > Anyway, let's hear what others have to say about TBC for v2. Your point is definitely valid that systems are still being built such that they are optimized for voice. The reality is that voice capacity is still a very important factor in the design of cellular systems, and hence optimizing systems for VoIP capacity is key. Thanks, Rohit _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Sep 27 04:03:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSUO3-0004uI-DP; Wed, 27 Sep 2006 04:03:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSUO2-0004uD-Qw for rohc@ietf.org; Wed, 27 Sep 2006 04:03:22 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSUO1-0007AD-Br for rohc@ietf.org; Wed, 27 Sep 2006 04:03:22 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k8R82fv6024824; Wed, 27 Sep 2006 09:02:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Sep 2006 09:02:41 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcbiC05bY6dJOcMGR024N1KsLwT/Kg== From: "Surtees, Abigail" To: X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 1.6 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Richard Price , John Barber Subject: [rohc] (no subject) X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi All, The SigComp implementer's guide has expired again. I have put a new version here: http://sigcomp.srmr.co.uk/~ahs/draft-ietf-rohc-sigcomp-impl-guide-07.txt I have proposed some text that I think covers the recent locally available state discussion (see http://www1.ietf.org/mail-archive/web/rohc/current/msg04466.html). Please have a look at section 10.3 and let me know what you think. Are there other comments, issues that should be addressed before submission of the draft? If I don't hear anything by Friday (and the text for 10.3 is agreed by then), I will submit the draft on Monday. Best regards, Abbie -- Abbie Surtees Consultant Engineer Roke Manor Research Ltd Tel: +44 (0)1794 833131=20 Fax: +44 (0)1794 833433 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Sep 27 09:51:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSZpK-0006aR-DX; Wed, 27 Sep 2006 09:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSZpJ-0006YE-2L for rohc@ietf.org; Wed, 27 Sep 2006 09:51:53 -0400 Received: from mclniron02-ext.bah.com ([156.80.1.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSZpF-00036a-MK for rohc@ietf.org; Wed, 27 Sep 2006 09:51:53 -0400 Received: from bahmail.bah.com (HELO mclnexbh02.resource.ds.bah.com) ([156.80.7.152]) by mclniron02-ext.bah.com with ESMTP; 27 Sep 2006 09:51:49 -0400 x-SBRS: None X-REMOTE-IP: 156.80.7.152 X-IronPort-AV: i="4.09,225,1157342400"; d="scan'208"; a="68135934:sNHT19343232" Received: from MCLNEXVS05.resource.ds.bah.com ([156.80.7.123]) by mclnexbh02.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Sep 2006 09:51:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec Date: Wed, 27 Sep 2006 09:51:48 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] FW: IPsec Processing & HCoIPsec Thread-Index: AcbddQic7TPTglhFSRqJFieJIp3gBAAzZ4XgAJY5ivAAAHAz4AABxY4gAAQ+H6AAH9q5YAA+fjIw From: "Jasani Rohan" To: "Lars-Erik Jonsson \(LU/EAB\)" , X-OriginalArrivalTime: 27 Sep 2006 13:51:49.0156 (UTC) FILETIME=[1434D640:01C6E23C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Lars: I've provided my comments inline below. Rohan Jasani Booz | Allen | Hamilton 703.984.0337 (office) 832.452.3241 (mobile) > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB)=20 > [mailto:lars-erik.jonsson@ericsson.com]=20 > Sent: Tuesday, September 26, 2006 3:42 AM > To: Jasani Rohan; rohc@ietf.org > Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec >=20 > > All: > > Just to be clear, Approach 1 will allocate a "generic" compressed=20 > > headers IANA protocol ID value (not specific to a particular header=20 > > compression scheme). >=20 > This I think is an open question. If a PROTOCOL NUMBER is=20 > assigned, its usage scope will not necessarily be limited to=20 > HCoIPsec. Having a "generic" identifier for "header=20 > compressed packet" means the identifier itself says nothing=20 > without some negotiated state. I believe that would be unfortunate. Actually, the "generic" identifier would indicate whether the packet contains compressed headers, however it does not indicate which HC scheme (e.g. ROHC, ECRTP, etc.) was used. Therefore, it does communicate something, however it would also need the negotiated state to indicate which HC scheme was used. =20 In the HCoIPsec case, the SA state will indicate the HC scheme. For other cases where HC can be applied, at some point prior to operation state needs to be negotiated as both ROHC and ECRTP require this before operation. In addition, based on your comment below "2) a mechanism for negotiation...", you agree that applying HC in any case will always require state to be negotiated. Therefore, the HC scheme of choice can always be indicated via negotiated state. Therefore, I see no issue with using the generic HC value. > We need to see the whole picture here, the discussion about=20 > "APPROACH 1-4" has not been very clear about which problem is=20 > addressed. I believe we are mixing different problems and=20 > various approaches solved these problems more or less completely. >=20 > Applying header compression over anything requires two things: > 1) a logical channel for the header-compressed packets only, for > some schemes a set of such logical channels is needed since > the schemes can not identify their own different packet types > (as they are actually designed for HDLC encapsulation). > 2) a mechanism for negotiation of the header compression channel > state. >=20 > While 2) is solved through the IKEv2 extension, 1) is not=20 > completely solved by any of the suggested approaches. >=20 > Let's look at the first problem in detail, what is it about? > 1a) Identify compressed header packets > * all packets sent over the link can be one option. > * otherwise a mechanism to create logical channels is needed. > * for ROHC, only one such logical channel would be needed, > while other schemes require a set of logical channels. > 1b) What if both compressed and uncompressed traffic is to be > multiplexed? > * with ROHC this can be handled in a ROHC-only channel,=20 > by making use of the uncompressed profile. This was already discussed previously and it was concluded that leveraging the "uncompressed" profile to multiplex uncompressed and compressed packets would add unnecessary overhead to uncompressed traffic. Therefore, we opted to use the Next Header field approach, which is currently being debated. I understand there might be situations where the "uncompressed" profile will be used (i.e. when the number of compressed flows supported by the compressor/decompressor is exceeded) and it can be used in these scenarios. For cases where a compressor receives traffic it cannot compress due to an unsupported profile (I imagine this would occur more often than previous case) this would be inefficient. > * in an IP tunnel, one single additional protocol identifier > would be enough to solve the whole problem for ROHC, > while having support also for other schemes would mean > multiple identifiers or additional mechanism are needed. >=20 > So, we need to address the question whether we should really=20 > cover also non-ROHC schemes? If so, we will have to face the=20 > fact that all the suggested approaches provides incomplete=20 > solutions, as ECRTP et. al requires additional functionality=20 > to identify their different packet formats. This additional functionality of identifying packet types for ECRTP has no effect on ROHC and is only used when ECRTP is used. The ECRTP over MPLS RFC defines a similar mechanism that would be used to support ECRTP in HCoIPsec. It is independent of ROHC. > Further, in an=20 > IP-tunnel, I assume reordering is a reality, and what does=20 > that mean for IP-HC/CRTP/ECRTP? For ROHC, reordering has been=20 > investigated, key problem areas identified and solutions=20 > provided by RFC 4224. Enhanced ROHC profiles are also on=20 > their way with built-in robustness to reordering. For=20 > IP-HC/CRTP/ECRTP, we know there are problems, but there is no=20 > guidance for how to handle those problems. This dives into the ROHC vs. ECRTP debate. By independently supporting both ROHC and ECRTP, this gives the vendors the flexibility to choose which HC scheme they would like to implement. In addition to technical merits of an HC scheme, vendors also use inputs that are not technical in nature to decide whether they want to implement one scheme over the other. Therefore, they should be given the flexibility to choose. If ROHC is better than ECRTP from a technical point of view, than by putting them on a level playing (as we are suggesting), I think vendors will easily be able to see that as well. Are folks concerned that by supporting both ECRTP and ROHC, vendors may only implement ECRTP ? If so, then why do you feel vendors may do this (i.e. what are the reasons vendors may do so) ? If not, then what are the concerns with supporting both HC schemes ? > If we had been able to easily include support for the old=20 > schemes along with ROHC, and if there had been convincing=20 > arguments supporting the usefulness of those schemes in an=20 > environment where reordering can occur, I had supported that.=20 > However, as I see it now, this is not the case. By "only"=20 > addressing ROHC, which is the general header compression=20 > platform, the solution becomes more straight- forward and we=20 > will not have to invent additional mechanisms to support=20 > schemes that we do not even know for sure if/how they can be=20 > made to work in these scenarios. What additional mechanisms are you referring to ? The only additional mechanism that I see is a mechanism to identify packet types for ECRTP. However, this mechanism is only used if ECRTP is used. If ROHC is used, this mechanism is not used. =20 > Rgds, > /L-E >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Wed Sep 27 09:56:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSZtP-0008PB-DW; Wed, 27 Sep 2006 09:56:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSZtO-0008Oq-Fb for rohc@ietf.org; Wed, 27 Sep 2006 09:56:06 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSZtL-0003nO-GI for rohc@ietf.org; Wed, 27 Sep 2006 09:56:06 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k8RDsqIt029752; Wed, 27 Sep 2006 14:54:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Sep 2006 14:54:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcbiC05bY6dJOcMGR024N1KsLwT/KgAJb2IQAAKwKyU= References: From: "Surtees, Abigail" To: "Richard Price" , X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: abigail.surtees@roke.co.uk X-Spam-Score: 0.1 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: John Barber Subject: [rohc] RE: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1528891042==" Errors-To: rohc-bounces@ietf.org This is a multi-part message in MIME format. --===============1528891042== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6E23C.81464B59" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6E23C.81464B59 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Richard, Thanks for the comments. I mostly agree with your rephrasing - I don't = think it needs the 'if advertised' though, because all the bullets are = 'if advertised'. Cheers, Abbie -----Original Message----- From: Richard Price [mailto:Richard.Price@eads.com] Sent: Wed 27/09/2006 13:45 To: Surtees, Abigail; rohc@ietf.org Cc: John Barber Subject: RE: =20 Hi Abbie, Just one small comment where you give the general lifetime of a "dictionary" item of state: "persist for the duration of the compartment" I'd rephrase this as "if advertised, are available for at least the duration of the compartment". Because the state itself may be available for longer (although of course we can't guarantee this unless it is defined somewhere). There's also a typo "avaiable", and you mention the UDVM instruction "SIGCOMP-FREE" which I believe should be "STATE-FREE". Cheers, Richard -----Original Message----- From: Surtees, Abigail [mailto:abigail.surtees@roke.co.uk] Sent: 27 September 2006 09:03 To: rohc@ietf.org Cc: Richard Price; John Barber Subject:=20 Hi All, The SigComp implementer's guide has expired again. I have put a new version here: http://sigcomp.srmr.co.uk/~ahs/draft-ietf-rohc-sigcomp-impl-guide-07.txt I have proposed some text that I think covers the recent locally available state discussion (see http://www1.ietf.org/mail-archive/web/rohc/current/msg04466.html). Please have a look at section 10.3 and let me know what you think. Are there other comments, issues that should be addressed before submission of the draft? If I don't hear anything by Friday (and the text for 10.3 is agreed by then), I will submit the draft on Monday. Best regards, Abbie -- Abbie Surtees Consultant Engineer Roke Manor Research Ltd Tel: +44 (0)1794 833131=20 Fax: +44 (0)1794 833433 ------_=_NextPart_001_01C6E23C.81464B59 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE:

Hi Richard,

Thanks for the comments.  I mostly agree with your rephrasing - I = don't think it needs the 'if advertised' though, because all the bullets = are 'if advertised'.

Cheers,

Abbie

-----Original Message-----
From: Richard Price [mailto:Richard.Price@eads.com]=
Sent: Wed 27/09/2006 13:45
To: Surtees, Abigail; rohc@ietf.org
Cc: John Barber
Subject: RE:

Hi Abbie,

Just one small comment where you give the general lifetime of a
"dictionary" item of state:

"persist for the duration of the compartment"

I'd rephrase this as "if advertised, are available for at least = the
duration of the compartment". Because the state itself may be = available
for longer (although of course we can't guarantee this unless it is
defined somewhere).

There's also a typo "avaiable", and you mention the UDVM = instruction
"SIGCOMP-FREE" which I believe should be = "STATE-FREE".

Cheers,

Richard

-----Original Message-----
From: Surtees, Abigail [mailto:abigail.surtees@roke.co= .uk]
Sent: 27 September 2006 09:03
To: rohc@ietf.org
Cc: Richard Price; John Barber
Subject:


Hi All,

The SigComp implementer's guide has expired again.  I have put a = new
version here:
http://sigcomp.srmr.co.uk/~ahs/draft-ietf-rohc-sigcomp-impl-guid= e-07.txt

I have proposed some text that I think covers the recent locally
available state discussion (see
http://www1.ietf.org/mail-archive/web/rohc/current/msg04466.html). Please have a look at section 10.3 and let me know what you think.

Are there other comments, issues that should be addressed before
submission of the draft?  If I don't hear anything by Friday (and = the
text for 10.3 is agreed by then), I will submit the draft on Monday.

Best regards,

Abbie



--
Abbie Surtees
Consultant Engineer
Roke Manor Research Ltd
Tel: +44 (0)1794 833131
Fax: +44 (0)1794 833433

------_=_NextPart_001_01C6E23C.81464B59-- --===============1528891042== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --===============1528891042==-- From rohc-bounces@ietf.org Thu Sep 28 03:55:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSqjX-00061W-BM; Thu, 28 Sep 2006 03:55:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSqjW-00061R-9E for rohc@ietf.org; Thu, 28 Sep 2006 03:55:02 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSqjP-0003g0-Ja for rohc@ietf.org; Thu, 28 Sep 2006 03:55:02 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9EACD4F013E; Thu, 28 Sep 2006 09:54:40 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 09:54:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec Date: Thu, 28 Sep 2006 09:54:38 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC05038FE635@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] FW: IPsec Processing & HCoIPsec thread-index: AcbddQic7TPTglhFSRqJFieJIp3gBAAzZ4XgAJY5ivAAAHAz4AABxY4gAAQ+H6AAH9q5YAA+fjIwACdJqLA= From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Jasani Rohan" , X-OriginalArrivalTime: 28 Sep 2006 07:54:40.0013 (UTC) FILETIME=[59DADBD0:01C6E2D3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org >>> Just to be clear, Approach 1 will allocate a "generic" compressed >>> headers IANA protocol ID value (not specific to a particular header >>> compression scheme). >>=20 >> This I think is an open question. If a PROTOCOL NUMBER is >> assigned, its usage scope will not necessarily be limited to >> HCoIPsec. Having a "generic" identifier for "header >> compressed packet" means the identifier itself says nothing >> without some negotiated state. I believe that would be unfortunate. >=20 > Actually, the "generic" identifier would indicate whether the packet > contains compressed headers, however it does not indicate which HC > scheme (e.g. ROHC, ECRTP, etc.) was used. Therefore, it does > communicate something, however it would also need the negotiated state > to indicate which HC scheme was used. >=20 > In the HCoIPsec case, the SA state will indicate the HC scheme. For > other cases where HC can be applied, at some point prior to operation > state needs to be negotiated as both ROHC and ECRTP require > this before operation. In addition, based on your comment below "2) a > mechanism for negotiation...", you agree that applying HC in any > case will always require state to be negotiated. Therefore, the HC > scheme of choice can always be indicated via negotiated state.=20 > Therefore, I see no issue with using the generic HC value. Yes, each header compression scheme needs a channel state to be negotiated, specific to that scheme. However, to use this generic identifier, you need to add another level of negotiation to=20 negotiate the meaning of "compressed header", so that these can be delivered to the correct decompression module. The packets with compressed headers will thus not be self-describing. >> We need to see the whole picture here, the discussion about >> "APPROACH 1-4" has not been very clear about which problem is >> addressed. I believe we are mixing different problems and >> various approaches solved these problems more or less completely. >>=20 >> Applying header compression over anything requires two things: >> 1) a logical channel for the header-compressed packets only, for >> some schemes a set of such logical channels is needed since >> the schemes can not identify their own different packet types >> (as they are actually designed for HDLC encapsulation). >> 2) a mechanism for negotiation of the header compression channel =20 >> state.=20 >>=20 >> While 2) is solved through the IKEv2 extension, 1) is not >> completely solved by any of the suggested approaches. >>=20 >> Let's look at the first problem in detail, what is it about? >> 1a) Identify compressed header packets >> * all packets sent over the link can be one option. >> * otherwise a mechanism to create logical channels is needed. >> * for ROHC, only one such logical channel would be needed, >> while other schemes require a set of logical channels. >> 1b) What if both compressed and uncompressed traffic is to be =20 >> multiplexed? * with ROHC this can be handled in a ROHC-only >> channel, by making use of the uncompressed profile. >=20 > This was already discussed previously and it was concluded that > leveraging the "uncompressed" profile to multiplex uncompressed and > compressed packets would add unnecessary overhead to uncompressed > traffic. Therefore, we opted to use the Next Header field approach, > which is currently being debated.=20 Yes, as should be clear from the rest of the text, I just listed all options, to make clear that ROHC is easy to fit in compared to having the other schemes supported. =20 > If ROHC is better than ECRTP from a technical point of view, > than by putting them on a level playing (as we are suggesting), > I think vendors will easily be able to see that as well. > Are folks concerned that by supporting both ECRTP and ROHC, > vendors may only implement ECRTP? If not, then what are the > concerns with supporting both HC schemes ? Alternatives are bad for interoperability. Alternatives are bad for complexity. Multiple solutions means increased burden for implementers. Let me cite Randy Bush: "The vendor/market approach has engendered a 'let the market decide' culture. Instead of hard-thought, rigorous designs,=20 every possible feature gets added and many competing proposals are approved. This last is like throwing spaghetti at the wall to see what sticks, an amusing tactic to everyone but the wall." By always keeping all the old stuff, the backpack just gets heavier... >> If we had been able to easily include support for the old >> schemes along with ROHC, and if there had been convincing >> arguments supporting the usefulness of those schemes in an >> environment where reordering can occur, I had supported that. >> However, as I see it now, this is not the case. By "only" >> addressing ROHC, which is the general header compression >> platform, the solution becomes more straight- forward and we >> will not have to invent additional mechanisms to support >> schemes that we do not even know for sure if/how they can be >> made to work in these scenarios. >=20 > What additional mechanisms are you referring to? The only > additional mechanism that I see is a mechanism to identify > packet types for ECRTP. > However, this mechanism is only used if ECRTP is used. If > ROHC is used, this mechanism is not used. Still, you need the negotiation of the meaning of "compressed". We will also provide multiple solutions for one problem, which is not necessarily a feature. Why I bring all this up is to make people aware we do have=20 some choices to make here. The problem space differs depending on our intensions when it comes to what schemes we are targeting, and the solution space of course differs similarly. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Sep 28 04:00:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSqpA-0000wq-UG; Thu, 28 Sep 2006 04:00:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSqp9-0000wl-PN for rohc@ietf.org; Thu, 28 Sep 2006 04:00:51 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSqp8-0004IL-FS for rohc@ietf.org; Thu, 28 Sep 2006 04:00:51 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D5E288E0002; Thu, 28 Sep 2006 10:00:49 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 10:00:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Sep 2006 10:00:48 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC05038FE651@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPsec Processing & HCoIPsec thread-index: Acbg35RbmgAuQ5TcSomc+dJFYDgUoAB9EUGQ From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Jan Vilhuber" , "Jasani Rohan" X-OriginalArrivalTime: 28 Sep 2006 08:00:48.0926 (UTC) FILETIME=[35BE83E0:01C6E2D4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: rohc@ietf.org, Tero Kivinen , Stephen Kent , hcoipsec@vpnc.org Subject: [rohc] RE: IPsec Processing & HCoIPsec X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org >> Looks like you, Tero, Emre and I prefer Approach 1, which is to >> allocate a generic compressed headers IANA value. Thanks for the >> input.=20 >=20 > I'm still not convinced this is needed. Since the protocol ID is > relevant ONLY to the two IPsec endpoints, it should be entirely > feasible to just pick a random one out of a hat (making sure it > doesn't conflict with any actual traffic on the ipsec-'link') > and use that. There's quite a few IANA protocol numbers that > are latent, not used, or whatever. Pick one and use it. No need > to trouble IANA about it. I do not know enough about this specific scenario to say whether this is feasible, but if it is, it sounds like an appealing idea. /L-E _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Thu Sep 28 08:57:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSvRk-0007y8-0S; Thu, 28 Sep 2006 08:57:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSvRi-0007y3-67 for rohc@ietf.org; Thu, 28 Sep 2006 08:56:58 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSvRY-0001re-JQ for rohc@ietf.org; Thu, 28 Sep 2006 08:56:58 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0416021; Thu, 28 Sep 2006 14:56:48 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 14:56:47 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Sep 2006 14:56:47 +0200 Message-ID: <451BC68F.7000600@ericsson.com> Date: Thu, 28 Sep 2006 14:56:47 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Lars-Erik Jonsson (LU/EAB)" Subject: Re: [rohc] RE: IPsec Processing & HCoIPsec References: <026F8EEDAD2C4342A993203088C1FC05038FE651@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC05038FE651@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2006 12:56:47.0066 (UTC) FILETIME=[8E6BA3A0:01C6E2FD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: rohc@ietf.org, Stephen Kent , Tero Kivinen , hcoipsec@vpnc.org, Jan Vilhuber X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Lars-Erik Jonsson (LU/EAB) skrev: >>> Looks like you, Tero, Emre and I prefer Approach 1, which is to >>> allocate a generic compressed headers IANA value. Thanks for the >>> input. >> I'm still not convinced this is needed. Since the protocol ID is >> relevant ONLY to the two IPsec endpoints, it should be entirely >> feasible to just pick a random one out of a hat (making sure it >> doesn't conflict with any actual traffic on the ipsec-'link') >> and use that. There's quite a few IANA protocol numbers that >> are latent, not used, or whatever. Pick one and use it. No need >> to trouble IANA about it. > > I do not know enough about this specific scenario to say whether > this is feasible, but if it is, it sounds like an appealing idea. > I would caution against this. The issue is that you will need a dynamic collision handler in that case. You must be able to switch that number if you get incoming traffic with that protocol ID you where using. If you don't, you will prevent some other protocol being deployed. And if this is a configurable matter, it will make some protocol fail in some environment depending on the configuration. Please do remember that new protocol ID are handed out and will continue to be. Thus by do an assignment you at least protect the world from yourself. If the header compression solution gets in trouble by needing to do dynamic negotiation about meaning per flow, or adds another generic header and loose some efficiency to determine what protocol really is used that is at least only affecting your own protocols. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Sep 29 00:14:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT9lM-0003k5-3F; Fri, 29 Sep 2006 00:14:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT9lL-0003jr-Bt for rohc@ietf.org; Fri, 29 Sep 2006 00:14:11 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT9lJ-00006y-UH for rohc@ietf.org; Fri, 29 Sep 2006 00:14:11 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 28 Sep 2006 21:14:09 -0700 X-IronPort-AV: i="4.09,233,1157353200"; d="scan'208"; a="326478452:sNHT61774940" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8T4E9ub026744; Thu, 28 Sep 2006 21:14:09 -0700 Received: from [10.32.241.25] ([10.32.241.25]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8T4E6ML023528; Thu, 28 Sep 2006 21:14:06 -0700 (PDT) In-Reply-To: <451BC68F.7000600@ericsson.com> References: <026F8EEDAD2C4342A993203088C1FC05038FE651@esealmw109.eemea.ericsson.se> <451BC68F.7000600@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jan Vilhuber Subject: Re: [rohc] RE: IPsec Processing & HCoIPsec Date: Thu, 28 Sep 2006 21:14:11 -0700 To: Magnus Westerlund X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=4528; t=1159503249; x=1160367249; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vilhuber@cisco.com; z=From:Jan=20Vilhuber=20 |Subject:Re=3A=20[rohc]=20RE=3A=20IPsec=20Processing=20&=20HCoIPsec; X=v=3Dcisco.com=3B=20h=3DvWtlLVesn45ibxIm+CYRVXy/HaY=3D; b=jsbDnxHw+H0iVvb3VwCZKf43Ha3FByJcJRdt1vrW7iOz3eUtjrrgEHdA6ZU95mbT0AiZlFj7 uXrOhjAz+Wb8g4jEfy8aKOpzVCFyIw3I8JhlxDrx+EaoTQ8ntESYyZRH; Authentication-Results: sj-dkim-5.cisco.com; header.From=vilhuber@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: rohc@ietf.org, Stephen Kent , Tero Kivinen , hcoipsec@vpnc.org, "Lars-Erik Jonsson \(LU/EAB\)" X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org On Sep 28, 2006, at 5:56 AM, Magnus Westerlund wrote: > Lars-Erik Jonsson (LU/EAB) skrev: >>>> Looks like you, Tero, Emre and I prefer Approach 1, which is to >>>> allocate a generic compressed headers IANA value. Thanks for the >>>> input. >>> I'm still not convinced this is needed. Since the protocol ID is >>> relevant ONLY to the two IPsec endpoints, it should be entirely >>> feasible to just pick a random one out of a hat (making sure it >>> doesn't conflict with any actual traffic on the ipsec-'link') >>> and use that. There's quite a few IANA protocol numbers that >>> are latent, not used, or whatever. Pick one and use it. No need >>> to trouble IANA about it. >> I do not know enough about this specific scenario to say whether >> this is feasible, but if it is, it sounds like an appealing idea. > > I would caution against this. The issue is that you will need a > dynamic collision handler in that case. You must be able to switch > that number if you get incoming traffic with that protocol ID you > where using. Perhaps so, but like I said, there's a ton of numbers assigned by IANA that are no longer realistically in use. I've never even seen a CHAOS packet, nor a SWIPE packet (or KRYPTOLAN, IPPC, etc..). Granted, I don't run a large networ (heck.. other than my own home network, I don't administer ANY networks). I'd love to hear from some operators. They can no doubt tell us what typesof packets they see, and which they NEVER see (ever). I would also argue that administrators should know what types of packet are likely to appear in their network, and can configure some protocol number they know won't appear. I don't think adding, say, CHAOSnet (or whatever it's called) to an existing network can be done just by accident, so presumably an administrator will know and be able to adjust. Then there's a few others we probably can use safely: 63 any local network [IANA] 99 any private encryption scheme [IANA] 131 PIPE Private IP Encapsulation within IP [Petri] 253 Use for experimentation and testing [RFC3692] 254 Use for experimentation and testing [RFC3692] Personally, I was going to use 99 or 131, if only initially to prove the technology works before going to IANA with some better arguments than "we think this'll work". > If you don't, you will prevent some other protocol being deployed. > And if this is a configurable matter, it will make some protocol > fail in some environment depending on the configuration. Please do > remember that new protocol ID are handed out and will continue to > be. Thus by do an assignment you at least protect the world from > yourself. Agreed, I'm not AGAINST getting IANA to assign one. Last time I asked some folks at the IETF about it, I was told there wasn't a chance in hell we'd get a new protocol number (or at least they are incredibly hard to come by). I certainly am not made out for political wrangling (as you can no doubt tell), so at that point I devised an alternate way, which I think is perfectly legitimate (with minimal risk). > If the header compression solution gets in trouble by needing to do > dynamic negotiation about meaning per flow, or adds another generic > header and loose some efficiency to determine what protocol really > is used that is at least only affecting your own protocols. > All you need to do is kick IKE with a new proposed number. Heck... negotiate 3 of them to start with, and in case of emergency, skip to the next one! An IKE notify can be used for that (or ikev2... I'm a little behind the curve; if you don't use IKE or v2, then I'm sure whatever protocol you're using has some means to send a notify. If not, you need to rethink your connection establishment protocol), and maybe a few packets get lost (don't forget to dutifuly syslog the error so the administrator can reconfigure boxes to exclude the new packet we just saw (CHAOS NET! ABORT ABORT ABORT!). jan > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Sep 29 00:17:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT9oD-00066Q-3C; Fri, 29 Sep 2006 00:17:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT9oB-000640-OK for rohc@ietf.org; Fri, 29 Sep 2006 00:17:07 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT9oA-0000fg-F5 for rohc@ietf.org; Fri, 29 Sep 2006 00:17:07 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 28 Sep 2006 21:17:06 -0700 X-IronPort-AV: i="4.09,233,1157353200"; d="scan'208"; a="326478678:sNHT54941482" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8T4H5A6026276; Thu, 28 Sep 2006 21:17:05 -0700 Received: from [10.32.241.25] ([10.32.241.25]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k8T4H4id025314; Thu, 28 Sep 2006 21:17:04 -0700 (PDT) In-Reply-To: References: <026F8EEDAD2C4342A993203088C1FC05038FE651@esealmw109.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <649B1C5C-2261-4C56-82E4-07F8265F8FFF@cisco.com> Content-Transfer-Encoding: 7bit From: Jan Vilhuber Date: Thu, 28 Sep 2006 21:17:09 -0700 To: Stephen Kent X-Mailer: Apple Mail (2.752.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1651; t=1159503425; x=1160367425; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vilhuber@cisco.com; z=From:Jan=20Vilhuber=20 |Subject:Re=3A=20IPsec=20Processing=20&=20HCoIPsec; X=v=3Dcisco.com=3B=20h=3DZBO4R+xscLKSCUZPiFlRzV9yd5o=3D; b=nm8gz1XzqzCeZA35XGyGFsdYiAJWaAWTzrtDOzhk3MmcHo+P1zHZB8ru/UDqUiOrrXZam2yL LsYwUrP9ulPW0UP1nTJ12v1++Bhcs9TpNBkiAkRgEpY1V7tdq0ocpVnl; Authentication-Results: sj-dkim-8.cisco.com; header.From=vilhuber@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: rohc@ietf.org, Tero Kivinen , "Lars-Erik Jonsson \(LU/EAB\)" , hcoipsec@vpnc.org Subject: [rohc] Re: IPsec Processing & HCoIPsec X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org On Sep 28, 2006, at 9:19 AM, Stephen Kent wrote: > At 10:00 AM +0200 9/28/06, Lars-Erik Jonsson \(LU/EAB\) wrote: >> >> Looks like you, Tero, Emre and I prefer Approach 1, which is to >>>> allocate a generic compressed headers IANA value. Thanks for the >>>> input. >>> >>> I'm still not convinced this is needed. Since the protocol ID is >>> relevant ONLY to the two IPsec endpoints, it should be entirely >>> feasible to just pick a random one out of a hat (making sure it >>> doesn't conflict with any actual traffic on the ipsec-'link') >>> and use that. There's quite a few IANA protocol numbers that >>> are latent, not used, or whatever. Pick one and use it. No need >>> to trouble IANA about it. >> >> I do not know enough about this specific scenario to say whether >> this is feasible, but if it is, it sounds like an appealing idea. >> >> /L-E > > There is an obvious danger to reusing an assigned but dormant > protocol number, i.e., if we think it's a valid thing to do, then > others who think similarly may trigger collisions. If we really > believe that a candidate protocol number is dormant (and I agree > that there are several such assignments) then we ought to work > through the process to reclaim one of these numbers and have it > reassigned for this purpose. I know this will take time, but I > think it is worth it. > Believe it or not, I do agree :) I just don't like going through so much trouble. If I wanted bureaucracy, I'd go get a visa for some obscure foreign country. It sounds easier and much more appealing (since I'd presumably go VISIT said obscure foreign country). jan _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Sep 29 03:13:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTCZ7-0007j1-Uc; Fri, 29 Sep 2006 03:13:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GSygj-0004qh-An for rohc@ietf.org; Thu, 28 Sep 2006 12:24:41 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GSygh-0001Ry-3N for rohc@ietf.org; Thu, 28 Sep 2006 12:24:41 -0400 Received: from col-dhcp33-244-173.bbn.com ([128.33.244.173]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1GSygc-0007eX-3k; Thu, 28 Sep 2006 12:24:34 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <026F8EEDAD2C4342A993203088C1FC05038FE651@esealmw109.eemea.ericsson.se> References: <026F8EEDAD2C4342A993203088C1FC05038FE651@esealmw109.eemea.ericsson.se> Date: Thu, 28 Sep 2006 12:19:13 -0400 To: "Lars-Erik Jonsson \(LU/EAB\)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Fri, 29 Sep 2006 03:13:44 -0400 Cc: rohc@ietf.org, Jan Vilhuber , Tero Kivinen , hcoipsec@vpnc.org Subject: [rohc] RE: IPsec Processing & HCoIPsec X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org At 10:00 AM +0200 9/28/06, Lars-Erik Jonsson \(LU/EAB\) wrote: > >> Looks like you, Tero, Emre and I prefer Approach 1, which is to >>> allocate a generic compressed headers IANA value. Thanks for the >>> input. >> >> I'm still not convinced this is needed. Since the protocol ID is >> relevant ONLY to the two IPsec endpoints, it should be entirely >> feasible to just pick a random one out of a hat (making sure it >> doesn't conflict with any actual traffic on the ipsec-'link') >> and use that. There's quite a few IANA protocol numbers that >> are latent, not used, or whatever. Pick one and use it. No need >> to trouble IANA about it. > >I do not know enough about this specific scenario to say whether >this is feasible, but if it is, it sounds like an appealing idea. > >/L-E There is an obvious danger to reusing an assigned but dormant protocol number, i.e., if we think it's a valid thing to do, then others who think similarly may trigger collisions. If we really believe that a candidate protocol number is dormant (and I agree that there are several such assignments) then we ought to work through the process to reclaim one of these numbers and have it reassigned for this purpose. I know this will take time, but I think it is worth it. Steve _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Sep 29 04:30:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTDl8-0003Vl-8S; Fri, 29 Sep 2006 04:30:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTDl7-0003Vg-B6 for rohc@ietf.org; Fri, 29 Sep 2006 04:30:13 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTDkx-0005d7-JK for rohc@ietf.org; Fri, 29 Sep 2006 04:30:13 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 99C018E0001; Fri, 29 Sep 2006 10:28:34 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 10:28:34 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 10:28:34 +0200 Message-ID: <451CD932.20106@ericsson.com> Date: Fri, 29 Sep 2006 10:28:34 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Jan Vilhuber Subject: Re: [rohc] RE: IPsec Processing & HCoIPsec References: <026F8EEDAD2C4342A993203088C1FC05038FE651@esealmw109.eemea.ericsson.se> <451BC68F.7000600@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 08:28:34.0369 (UTC) FILETIME=[40D6B310:01C6E3A1] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Tero Kivinen , rohc@ietf.org, Stephen Kent , hcoipsec@vpnc.org X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi, I think you should float your idea(s) with a larger group of people after you considered what the pro and cons of each approach is. I would recommend posting to relevant area mailing lists. That way you will get more feedback on what ever you consider before spending to much time on them. Cheers Magnus Jan Vilhuber skrev: > On Sep 28, 2006, at 5:56 AM, Magnus Westerlund wrote: > >> Lars-Erik Jonsson (LU/EAB) skrev: >>>>> Looks like you, Tero, Emre and I prefer Approach 1, which is to >>>>> allocate a generic compressed headers IANA value. Thanks for the >>>>> input. >>>> I'm still not convinced this is needed. Since the protocol ID is >>>> relevant ONLY to the two IPsec endpoints, it should be entirely >>>> feasible to just pick a random one out of a hat (making sure it >>>> doesn't conflict with any actual traffic on the ipsec-'link') >>>> and use that. There's quite a few IANA protocol numbers that >>>> are latent, not used, or whatever. Pick one and use it. No need >>>> to trouble IANA about it. >>> I do not know enough about this specific scenario to say whether >>> this is feasible, but if it is, it sounds like an appealing idea. >> I would caution against this. The issue is that you will need a >> dynamic collision handler in that case. You must be able to switch >> that number if you get incoming traffic with that protocol ID you >> where using. > > Perhaps so, but like I said, there's a ton of numbers assigned by > IANA that are no longer realistically in use. I've never even seen a > CHAOS packet, nor a SWIPE packet (or KRYPTOLAN, IPPC, etc..). > Granted, I don't run a large networ (heck.. other than my own home > network, I don't administer ANY networks). I'd love to hear from some > operators. They can no doubt tell us what typesof packets they see, > and which they NEVER see (ever). > > I would also argue that administrators should know what types of > packet are likely to appear in their network, and can configure some > protocol number they know won't appear. I don't think adding, say, > CHAOSnet (or whatever it's called) to an existing network can be done > just by accident, so presumably an administrator will know and be > able to adjust. > > Then there's a few others we probably can use safely: > 63 any local network [IANA] > 99 any private encryption scheme [IANA] > 131 PIPE Private IP Encapsulation within IP [Petri] > 253 Use for experimentation and testing [RFC3692] > 254 Use for experimentation and testing [RFC3692] > > Personally, I was going to use 99 or 131, if only initially to prove > the technology works before going to IANA with some better arguments > than "we think this'll work". > >> If you don't, you will prevent some other protocol being deployed. >> And if this is a configurable matter, it will make some protocol >> fail in some environment depending on the configuration. Please do >> remember that new protocol ID are handed out and will continue to >> be. Thus by do an assignment you at least protect the world from >> yourself. > > Agreed, I'm not AGAINST getting IANA to assign one. Last time I asked > some folks at the IETF about it, I was told there wasn't a chance in > hell we'd get a new protocol number (or at least they are incredibly > hard to come by). I certainly am not made out for political wrangling > (as you can no doubt tell), so at that point I devised an alternate > way, which I think is perfectly legitimate (with minimal risk). > > >> If the header compression solution gets in trouble by needing to do >> dynamic negotiation about meaning per flow, or adds another generic >> header and loose some efficiency to determine what protocol really >> is used that is at least only affecting your own protocols. >> > > All you need to do is kick IKE with a new proposed number. Heck... > negotiate 3 of them to start with, and in case of emergency, skip to > the next one! An IKE notify can be used for that (or ikev2... I'm a > little behind the curve; if you don't use IKE or v2, then I'm sure > whatever protocol you're using has some means to send a notify. If > not, you need to rethink your connection establishment protocol), and > maybe a few packets get lost (don't forget to dutifuly syslog the > error so the administrator can reconfigure boxes to exclude the new > packet we just saw (CHAOS NET! ABORT ABORT ABORT!). > > jan > > >> Cheers >> >> Magnus Westerlund >> >> Multimedia Technologies, Ericsson Research EAB/TVA/A >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 8 4048287 >> Torshamsgatan 23 | Fax +46 8 7575550 >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Sep 29 08:41:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTHft-0007fe-V7; Fri, 29 Sep 2006 08:41:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTHfs-0007eL-OT for rohc@ietf.org; Fri, 29 Sep 2006 08:41:04 -0400 Received: from mclniron01-ext.bah.com ([156.80.1.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTHfq-0005oz-9t for rohc@ietf.org; Fri, 29 Sep 2006 08:41:04 -0400 Received: from bahmail.bah.com (HELO mclnexbh02.resource.ds.bah.com) ([156.80.7.152]) by mclniron01-ext.bah.com with ESMTP; 29 Sep 2006 08:40:15 -0400 x-SBRS: None X-REMOTE-IP: 156.80.7.152 X-IronPort-AV: i="4.09,236,1157342400"; d="scan'208"; a="80095327:sNHT32464956" Received: from MCLNEXVS05.resource.ds.bah.com ([156.80.7.123]) by mclnexbh02.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 08:40:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec Date: Fri, 29 Sep 2006 08:40:17 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] FW: IPsec Processing & HCoIPsec Thread-Index: AcbddQic7TPTglhFSRqJFieJIp3gBAAzZ4XgAJY5ivAAAHAz4AABxY4gAAQ+H6AAH9q5YAA+fjIwACdJqLAADcjPQA== From: "Jasani Rohan" To: "Lars-Erik Jonsson \(LU/EAB\)" , X-OriginalArrivalTime: 29 Sep 2006 12:40:14.0617 (UTC) FILETIME=[6949B090:01C6E3C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Lars: Seems like we can go back and forth on this for a while :) So, let me think about all the email exchanges with some of my colleagues for few days to come up with a way to resolve this. I've included my comments inline below. Thanks Rohan Jasani Booz | Allen | Hamilton 703.984.0337 (office) 832.452.3241 (mobile) > -----Original Message----- > From: Lars-Erik Jonsson (LU/EAB)=20 > [mailto:lars-erik.jonsson@ericsson.com]=20 > Sent: Thursday, September 28, 2006 3:55 AM > To: Jasani Rohan; rohc@ietf.org > Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec >=20 > >>> Just to be clear, Approach 1 will allocate a "generic" compressed=20 > >>> headers IANA protocol ID value (not specific to a=20 > particular header=20 > >>> compression scheme). > >>=20 > >> This I think is an open question. If a PROTOCOL NUMBER is=20 > assigned,=20 > >> its usage scope will not necessarily be limited to=20 > HCoIPsec. Having a=20 > >> "generic" identifier for "header compressed packet" means the=20 > >> identifier itself says nothing without some negotiated state. I=20 > >> believe that would be unfortunate. > >=20 > > Actually, the "generic" identifier would indicate whether=20 > the packet=20 > > contains compressed headers, however it does not indicate which HC=20 > > scheme (e.g. ROHC, ECRTP, etc.) was used. Therefore, it does=20 > > communicate something, however it would also need the=20 > negotiated state=20 > > to indicate which HC scheme was used. > >=20 > > In the HCoIPsec case, the SA state will indicate the HC=20 > scheme. For=20 > > other cases where HC can be applied, at some point prior to=20 > operation=20 > > state needs to be negotiated as both ROHC and ECRTP require this=20 > > before operation. In addition, based on your comment below "2) a=20 > > mechanism for negotiation...", you agree that applying HC=20 > in any case=20 > > will always require state to be negotiated. Therefore, the=20 > HC scheme=20 > > of choice can always be indicated via negotiated state. > > Therefore, I see no issue with using the generic HC value. >=20 > Yes, each header compression scheme needs a channel state to=20 > be negotiated, specific to that scheme. However, to use this=20 > generic identifier, you need to add another level of=20 > negotiation to negotiate the meaning of "compressed header",=20 > so that these can be delivered to the correct decompression=20 > module. The packets with compressed headers will thus not be=20 > self-describing. I don't see it as another level of negotiation, since you can use the same mechanism that is negotiating the HC scheme specific parameters. You would just have to negotiate the HC scheme first, then based on that you can negotiate the approriate HC scheme parameters. I'm unclear on why "another level of negotiation" would complicate things ? > >> We need to see the whole picture here, the discussion about > >> "APPROACH 1-4" has not been very clear about which problem is > >> addressed. I believe we are mixing different problems and > >> various approaches solved these problems more or less completely. > >>=20 > >> Applying header compression over anything requires two things: > >> 1) a logical channel for the header-compressed packets only, for > >> some schemes a set of such logical channels is needed since > >> the schemes can not identify their own different packet types > >> (as they are actually designed for HDLC encapsulation). > >> 2) a mechanism for negotiation of the header compression channel =20 > >> state.=20 > >>=20 > >> While 2) is solved through the IKEv2 extension, 1) is not > >> completely solved by any of the suggested approaches. > >>=20 > >> Let's look at the first problem in detail, what is it about? > >> 1a) Identify compressed header packets > >> * all packets sent over the link can be one option. > >> * otherwise a mechanism to create logical channels is needed. > >> * for ROHC, only one such logical channel would be needed, > >> while other schemes require a set of logical channels. > >> 1b) What if both compressed and uncompressed traffic is to be =20 > >> multiplexed? * with ROHC this can be handled in a ROHC-only > >> channel, by making use of the uncompressed profile. > >=20 > > This was already discussed previously and it was concluded that > > leveraging the "uncompressed" profile to multiplex uncompressed and > > compressed packets would add unnecessary overhead to uncompressed > > traffic. Therefore, we opted to use the Next Header field approach, > > which is currently being debated.=20 >=20 > Yes, as should be clear from the rest of the text, I just listed > all options, to make clear that ROHC is easy to fit in compared > to having the other schemes supported. >=20 > =20 > > If ROHC is better than ECRTP from a technical point of view, > > than by putting them on a level playing (as we are suggesting), > > I think vendors will easily be able to see that as well. > > Are folks concerned that by supporting both ECRTP and ROHC, > > vendors may only implement ECRTP? If not, then what are the > > concerns with supporting both HC schemes ? >=20 > Alternatives are bad for interoperability. Alternatives are > bad for complexity. Multiple solutions means increased burden > for implementers. Let me cite Randy Bush: > "The vendor/market approach has engendered a 'let the market > decide' culture. Instead of hard-thought, rigorous designs,=20 > every possible feature gets added and many competing proposals > are approved. This last is like throwing spaghetti at the wall > to see what sticks, an amusing tactic to everyone but the wall." I see where you are coming for certain cases where there are many competing protocols. However, in the HC case, we are only trying to support 2 HC schemes, not 10 HC schemes. I'm unclear on what the burden is to vendors, as they don't necessarily have to implement both schemes ? =20 > By always keeping all the old stuff, the backpack just gets > heavier... We aren't mandating vendors to implement either HC scheme its up to them, so I'm not clear on how this makes things "heavier" ? > >> If we had been able to easily include support for the old > >> schemes along with ROHC, and if there had been convincing > >> arguments supporting the usefulness of those schemes in an > >> environment where reordering can occur, I had supported that. > >> However, as I see it now, this is not the case. By "only" > >> addressing ROHC, which is the general header compression > >> platform, the solution becomes more straight- forward and we > >> will not have to invent additional mechanisms to support > >> schemes that we do not even know for sure if/how they can be > >> made to work in these scenarios. > >=20 > > What additional mechanisms are you referring to? The only > > additional mechanism that I see is a mechanism to identify > > packet types for ECRTP. > > However, this mechanism is only used if ECRTP is used. If > > ROHC is used, this mechanism is not used. >=20 > Still, you need the negotiation of the meaning of "compressed". > We will also provide multiple solutions for one problem, which > is not necessarily a feature. My point earlier was that you already have to conduct negotiation for HC to work. When you negotiate the meaning of "compressed", all you are doing is negotiating 1 additional parameter via the same mechanism. =20 > Why I bring all this up is to make people aware we do have=20 > some choices to make here. The problem space differs depending > on our intensions when it comes to what schemes we are > targeting, and the solution space of course differs similarly. >=20 > /L-E >=20 _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Sep 29 09:25:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTIN8-00064k-Ki; Fri, 29 Sep 2006 09:25:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTIN6-00064f-VH for rohc@ietf.org; Fri, 29 Sep 2006 09:25:44 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTIN0-000456-CA for rohc@ietf.org; Fri, 29 Sep 2006 09:25:44 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A92314F0132; Fri, 29 Sep 2006 15:25:35 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 15:25:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec Date: Fri, 29 Sep 2006 15:25:34 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC05039333AF@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] FW: IPsec Processing & HCoIPsec thread-index: AcbddQic7TPTglhFSRqJFieJIp3gBAAzZ4XgAJY5ivAAAHAz4AABxY4gAAQ+H6AAH9q5YAA+fjIwACdJqLAADcjPQAAxScLQ From: "Lars-Erik Jonsson \(LU/EAB\)" To: "Jasani Rohan" , X-OriginalArrivalTime: 29 Sep 2006 13:25:35.0520 (UTC) FILETIME=[BF128A00:01C6E3CA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Ok, let me then summarize my main point here. I did think the idea of registering a PROTOCOL NUMBER was ok as long as we talked about registering an unambiguous identifier for the ROHC header compression platform. However, I do not like the idea with a "generic", as I see it ambiguous, identifier.=20 Based on that, I think it is a good idea to investigate the approach Jan is proposing, avoiding registrations. I'm of course also open to new ideas...=3D) /L-E >> Yes, each header compression scheme needs a channel state to >> be negotiated, specific to that scheme. However, to use this >> generic identifier, you need to add another level of >> negotiation to negotiate the meaning of "compressed header", >> so that these can be delivered to the correct decompression >> module. The packets with compressed headers will thus not be >> self-describing. >=20 > I don't see it as another level of negotiation, since you can use the > same mechanism that is negotiating the HC scheme specific parameters. > You would just have to negotiate the HC scheme first, then > based on that > you can negotiate the appropriate HC scheme parameters. I'm unclear on > why "another level of negotiation" would complicate things ? Conceptually there is another level of negotiation, but it might not be in implementation. As often is the case... >>> If ROHC is better than ECRTP from a technical point of view, >>> than by putting them on a level playing (as we are suggesting), >>> I think vendors will easily be able to see that as well. >>> Are folks concerned that by supporting both ECRTP and ROHC, >>> vendors may only implement ECRTP? If not, then what are the >>> concerns with supporting both HC schemes ? >>=20 >> Alternatives are bad for interoperability. Alternatives are >> bad for complexity. Multiple solutions means increased burden >> for implementers. Let me cite Randy Bush: >> "The vendor/market approach has engendered a 'let the market >> decide' culture. Instead of hard-thought, rigorous designs, >> every possible feature gets added and many competing proposals >> are approved. This last is like throwing spaghetti at the wall >> to see what sticks, an amusing tactic to everyone but the wall." >=20 > I see where you are coming for certain cases where there are many > competing protocols. However, in the HC case, we are only trying to > support 2 HC schemes, not 10 HC schemes. I'm unclear on what > the burden is to vendors, as they don't necessarily have to > implement both schemes? Both sides need to support the same protocol, which means alternatives either increases complexity of reduces to chances for interoperability. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc From rohc-bounces@ietf.org Fri Sep 29 10:51:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTJhc-0000vy-DA; Fri, 29 Sep 2006 10:51:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTJhE-0008Gs-Se; Fri, 29 Sep 2006 10:50:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTJhE-0007Ax-Pg; Fri, 29 Sep 2006 10:50:36 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GTJhB-0002qF-3I; Fri, 29 Sep 2006 10:50:36 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id D97202ACA1; Fri, 29 Sep 2006 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GTJgg-0000bV-KV; Fri, 29 Sep 2006 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 29 Sep 2006 10:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: rohc@ietf.org Subject: [rohc] I-D ACTION:draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org --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 : Extensions to IKEv2 to Support Header Compression over IPsec (HCoIPsec) Author(s) : R. Jasani, et al. Filename : draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt Pages : 15 Date : 2006-9-29 When using Header Compression (HC) schemes in conjunction with IPsec (i.e., [HCOIPSEC]) a mechanism is needed to negotiate both the HC scheme and any associated configuration parameters between end-points prior to operation. Internet Key Exchange (IKE) is a mechanism which can be leveraged to handle these negotiations. This document specifies extensions to Internet Key Exchange (IKEv2) that will allow header compression schemes and their associated configuration parameters to be negotiated for IPsec security associations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ietf-rohc-ikev2-extensions-hcoipsec-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-ietf-rohc-ikev2-extensions-hcoipsec-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: <2006-9-29052645.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-9-29052645.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc --NextPart-- From rohc-bounces@ietf.org Sat Sep 30 04:18:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTa2t-0000Ta-5a; Sat, 30 Sep 2006 04:18:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTa2r-0000Ss-Ih for rohc@ietf.org; Sat, 30 Sep 2006 04:18:01 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTZmt-0003eR-JY for rohc@ietf.org; Sat, 30 Sep 2006 04:01:34 -0400 Received: from mailgate.qd.lucent.com (h135-252-40-221.lucent.com [135.252.40.221]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k8U81PKn000779 for ; Sat, 30 Sep 2006 03:01:26 -0500 (CDT) Received: from exch01.qd.lucent.com ([135.252.44.195]) by mailgate.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 30 Sep 2006 16:00:53 +0800 Received: from [135.252.137.36] ([135.252.137.36]) by exch01.qd.lucent.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 30 Sep 2006 16:00:52 +0800 Message-ID: <451E2434.8000909@lucent.com> Date: Sat, 30 Sep 2006 16:00:52 +0800 From: Carrie Zhang User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rohc@ietf.org References: <44DAF102.3070402@lucent.com> <44DBEAD5.7030500@lucent.com> In-Reply-To: <44DBEAD5.7030500@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Sep 2006 08:00:52.0798 (UTC) FILETIME=[8CE0D5E0:01C6E466] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [rohc] how to send uncompressed SIP request over TCP? X-BeenThere: rohc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Robust Header Compression List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rohc-bounces@ietf.org Hi experts, When the client needs to send uncompressed SIP request over TCP for some reasons, should the comp=sigcomp be included in topmost Via header? If the comp=sigcomp is included, then the server will send compressed SIP response in the same TCP connection (RFC3261, the same TCP connection should be used within one transaction) which violates the following statement in "draft-ietf-rohc-sigcomp-sip-02.txt" that "Applications MUST NOT mix SIP messages and SigComp messages on a single TCP connection." We are considering the following rules for clients to address this: 1) if client wants to receive compressed SIP response, it can include comp=sigcomp in the topmost Via header in the SIP request, but the client MUST use the well-known shim header mechanism to send the uncompressed SIP request, otherwise 2) client should not include comp=sigcomp in the topmost Via header in the SIP request if it does not use shim header to send uncompressed message, so that server won't mix the compressed SigComp response and uncompressed SIP request in a signal TCP connection. Does this sound reasonable? Any suggestions? Is there any plan to add some statement in "draft-ietf-rohc-sigcomp-sip-02.txt" about this? Regards, Carrie _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc