Re: Compression of AH/NULL-ESP headers in ROHCv1

Jer-ming Lin <[email protected]> Tue, 23 Feb 2010 02:03:08 +0800
Newsgroups gmane.ietf.rohc
Message-ID <[email protected]>
Dear Klaus,

     Thank you for your feedback!!! Both the CORRECTED and INCORRECT
parts in RFC 4815 make me ambiguous on the topic of AH Sequence
number.

Sincerely yours,
Jer-ming

2010/2/22 Klaus Warnke <[email protected]>:
> At Mon, 22 Feb 2010 22:23:03 +0800,
> Jer-ming Lin wrote:
>>
>> Dear ROHCers,
>>
>> "The AH sequence number can be omitted from the compressed header
>> when the offset from the sequence number (SN) of the compressed
>> header is constant, ...."
>>
>> When I read the above lines about the AH sequence number in RFC 4815
>> 5.8, I got the some questions.  Please clarify the following
>> probelms. Thanks
>>
>> 1) Does the SN mean RTP SN or AH SN in the "offset sequence number
>>    (SN) of the compressed header"?
>
> It means the master SN, derived from/compressed to the transmitted,
> compressed SN bits.  And the master SN depends on the profile used. If
> the used profile is RTP, the master SN is the RTP-SN. In UDP profile
> it is a counter. The AH is handled as an extension header and can
> occur in all profiles, I think.
>
>> 2) Does the offset mean the method like "offset IP-ID encoding" or
>>    just calculating the delta respectively(RTP SN and AH SN) and
>>    compare?  Since RTP SN is 2 bytes and AH is 4 bytes, the two
>>    methods will be different at wraparound.
>
> I think, it is "just calculating the delta", because you are not
> transmitting a (compressed) AH-SN offset itself anywhere. If the AH-SN
> is in step with the compressed master SN, it can be omitted. If not,
> you have to transmitt it "compressed" here:
>
> 5.8.5.1.  Format of IP Extension Header(s) field
>
>      +-----+-----+-----+-----+-----+-----+-----+-----+
>      :    compressed AH Seq Number,  1 or 4 octets   :  if ASeq = 1
>      +-----+-----+-----+-----+-----+-----+-----+-----+
>
> "Compressed" means, either 7bit or 31 bits LSB. See below.
>
> I think, if you are using a 4 byte variable for the AH and adding the
> delta (offset) the is no need for a special wraparound handling, from
> my point of view. If the AH SN wraps over before compression, but the
> offset is constant and in step with the master SN, it will be wrap
> over on de-compressor site also when adding the offset.
>
> Gruß, Klaus
>
_______________________________________________
Rohc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rohc