Re: One DOubt Regarding the ROHC-TCP
"Robert Stangarone" <[email protected]> Mon, 27 Jul 2009 07:47:16 -0700
| Newsgroups | gmane.ietf.rohc |
|---|---|
| Message-ID | <001b01ca0ec9$227c7e80$67757b80$@com> |
You may want to review these draft documents to see how ROHC Channel parameters are signaled over IKE and used in IPSEC as it may provide insight into the questions you are asking. http://www.ietf.org/internet-drafts/draft-ietf-rohc-hcoipsec-10.txt http://www.ietf.org/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipse c-08.txt http://www.ietf.org/internet-drafts/draft-ietf-rohc-ipsec-extensions-hcoipse c-04.txt Bob -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Klaus Warnke Sent: Monday, July 27, 2009 4:56 AM To: Ganesh Cc: [email protected] Subject: Re: [rohc] One DOubt Regarding the ROHC-TCP Ganesh wrote: > Klaus Warnke, > so ur mentioning that when the negotiation is happening between > compressor and decompressor, it has to be done based on each profile, > not on version based, > i.e it can be only RTP profile (0x101) for version 1 and all other > profiles,UDP, ESP can be version 0 etc?? Yes, I think so. Maybe it makes no sense to mix profile versions, but I think the "server" version should offer both versions, and the "client" version maybe support the RFC3095 or RoHCv2 versions of the profiles. > is it the efficient way of doing that one, for mobile implementation > for 3gpp based things, as their is constrains on memory and processing > resources.. > In my opinion, if both versions are activated but for different > profiles, there wont be problem for Network nodes, as there is not > constraint on memory or processing resources. Sorry, but I can't make a statement about that. > > Pls comment on the doubts i have. > > > Thanks & Regards > Ganesh br Klaus Warnke > . > > > > > > 2009/7/27 Klaus Warnke <[email protected] > <mailto:[email protected]>> > > Ganesh, > > the version of profile used, is negotiated for every profile > independent, not for all profiles together. For the TCP profile > only one version exist (yet). Therefore the profile has the > identifier 0x0006. For IP/UDP/RTP two version exist: > > RFC3905: 0x0001 > RFC5225: 0x0101 > > The upper octet is the version number, the lower the profile > number itself. Because while compression and de-compression only > one lower octet is send, the version has to be negotiation first. > It is a little bit confusing, that for the TCP profile the > version number is 0, but for the TCP profile only a on the RoHC > FN definition exists. If it makes sense to mix profiles, using > the RTP profile version 0 from RFC3095 and UPD version 1 defined > in RoHC FN, I don't know. But it is possible from my point of view. > > br > Klaus Warnke > > Ganesh wrote: > > Hi all, THe RFC 4996, is more inclined to ROHCV2 profiles, but > the profile number is defined as 0x006 (version 1), as per the > RFC 5225, if we have multiple variants of ROHC versions, then > the ROHC compressor and decompressor after negotiation has to > use only one version, if version 2 is selected, then how the > TCP packets will be compressed?? > Can any one please reply to the Question?? > > > > Thanks & Regards, > Ganesh Babu Kamma > > ------------------------------------------------------------------------ > > _______________________________________________ > Rohc mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/rohc > > _______________________________________________ Rohc mailing list [email protected] https://www.ietf.org/mailman/listinfo/rohc