Re: RoHC Profile 4 Static chain termination
Carl Knutsson <[email protected]> Mon, 28 Mar 2011 15:43:22 +0200
| Newsgroups | gmane.ietf.rohc |
|---|---|
| Message-ID | <[email protected]> |
Hi Vivek,
I guess you are referring to profile 0x0004 in RFC 3843 section 3.1.
I don't think I understand exactly what you are trying to change or
clarify with your suggestion.
The version field MSB is used to terminate the static chain when it
isn't implicitly given by the next header/protocol field. For example if
you want to compress only the IPv4 header for an IPv4/IPv6 packet. Or do
you want to disqualify the use of the version field static chain
termination in those cases were the end is implicitly given by the
protocol field? In that case the MSB in the IP version field may be
redundant but the compression will function correctly.
In any case I can't really see that this requires a correction or
clarification to the RFC.
Note that this RFC that was published some years ago, so we are not
likely to change it for smaller editorial fixes. We could file an
errata, but at this point I can't see anything in the static chain
termination section that needs a clarification or correction.
cheers,
/Calle
On 03/28/2011 04:24 AM, Vivek Soni wrote:
> Hello,
>
> I understand that the compressor can terminate the static chain at any
> header by explicity setting the MSB of version field. But I am not clear
> when exactly should compressor do this.
>
> My understanding is that it is applicable only when there are multiple
> IP headers and compressor decides to compress only few of them.
>
> Whereas in other cases for example
> 1. The packet has only one IP header ("Protocol"/"next header" field is
> other than IPinIP or IPv6)
> 2. The packet has multiple IP headers and the compressor compresses all
> of them.
>
> In both these cases, the static chain termination is implicit. Therefore
> the compressor need not (SHOULD NOT)
> indicate the end of static chain explicitly by setting MSB of version field.
>
> Is this understanding of mine correct. In that case, would be it be
> better if RFC is more clear about it by using
> stronger text like "SHOULD NOT" instead of "Alternatively".
>
> Regards,
> Vivek
>
>
>
> _______________________________________________
> Rohc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rohc