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

Hi Klaus,

Thanks for your response.
Please see my queries inline.

-----Original Message-----
From: Klaus Warnke [mailto:[email protected]]
Sent: Monday, November 30, 2009 8:42 PM
To: Anil Maguluri
Cc: [email protected]; [email protected]
Subject: Re: [rohc] Compression of AH/NULL-ESP headers in ROHCv1

Anil,

find my response inline.

At Mon, 30 Nov 2009 16:28:02 +0530,
Anil Maguluri wrote:
> Hi All,
>
> I would like to know how to compress AH/NULL ESP header using list
> compression in ROHCv1.
>
> Please clarify me if my understanding is wrong.
>
> è AH (RFC 3095, 5.8.4.2)
>
> RFC is talking about how to check whether the list is changed or not
> by comparing SPI value of the ref_list with the current_list. If the
> list not changes, then check the relation between SN with the SN in
> AH header. If the relationship is understood by the decompressor, no
> need to send the AH SN value otherwise send the compressed AH SN
> value using UOR-2 packet with EXT-3 (by enabling Aseq bit) and send
> the Authentication Data for all packets based on the section 5.7 in
> RFC 3095.
>
> Please clarify me the below queries.
>
> 1. How to send the initial AH information (SPI, SN, Next Header,
>    Payload Length) to the decompressor? On which packet?

The extension headers are handled with the list compression. See 3095
5.8. The inital data are sent within the dynamic part of the
corresponding header, for IPv4 see 5.7.7.3.

   Dynamic part:
...
      +---+---+---+---+---+---+---+---+
      / Generic extension header list /   variable length
      +---+---+---+---+---+---+---+---+
...
   Extras:

      Generic extension header list: Encoded according to section
      5.8.6.1, with all header items present in uncompressed form.

The generic scheme can also appear in a extension-3. The uncompressed
form is described in 5.8.4.2. For AH, the next header field is
changed.

The AH/GRE/ESP header must transformed into a form, that makes it
easy/possible to re-assemble them from the list/table. The GRE, for
example must transformed into the Uncompressed GRE list item. See
5.8.4.4. This uncompressed item is sent with the generic scheme to the
de-compressor. The de-compressor re-construct the header chain from
this item list. The next header field is taken from the previous item,
because the own next header points to itself. This makes the list
robust against header removal/insertion. The item does not changes, if
a header disappears/is ins2erted after/before them.

[ANIL]
Q1. what are the fields are part of dynamic context for AH/ESP NULL headers?
Q2. For AH, there is no uncompressed format specified in the RFC 3095. Can
you please let me know uncompressed format of the AH header?
Q3. What is the use of "AH data for inner/outer list" field in the general
format for a RTP header as specified in the RFC (section 5.7, page 77)?


> 2. How to send the new SPI information if the list changes? On which
>    packet?

In extension-3 with generic scheme. See the IPX flag:

   Inner IP header fields
...
    ..... ..... ..... ..... ..... ..... ..... .....
   /         IP extension headers                  /  variable,
    ..... ..... ..... ..... ..... ..... ..... .....   if IPX = 1

See 5.8.5.1. about the format. If the SPI has changed, the ASeq is set
to 0 and the AH header is sent with the changed next haeder field and
with ah data as an uncompressed header item. Set XI for the AH in list
to 1 and send the whole header (in the CL, "compressed header list").
The compressed header list has the same format as the compressed CSRC
list, see 5.8.6.

From my point of view, the terms are confusing. There exists no
compressed header item. Either an extension header is sent
uncompressed, but changed, as and list item, or not. The sequence no
can sent compressed (7/31 bit) separated.

[ANIL]
Q1. I did not see the above information in RFC. Can you please let me know
In which section it is specified?
Q2. Please clarify whether my understanding is right or wrong.
For AH: Assume list has only AH packet (IPv4/AH/UDP/RTP). This packet
Should compress using Profile-1 (IPv4/UDP/RTP) with List compression for AH.
Initially compressor will send the uncompressed packet format using the
Generic scheme using IR/IR-DYN/UOR-2 with EXT-3. After setting the context,
compressor make reference list using the uncompressed packet. After that,
compressor will compare the received list item with the reference list item to
check whether the list has changed or not (by checking SPI value). If the list
is not changed, and AH SN can be derived from SN (assume RTP), then no need to
sending AH SN by using EXT-3 packet (setting the Aseq bit). If the list has
not changed and AH SN cannot derivable from SN (RTP), then compressor has
to send the compressed AH SN value using EXT-3 header (setting the Aseq bit).
If the list changes, use Generic Scheme to send the new header information
to the decompressor.


> 3. What is the uncompressed list item format? How to send that item
>    to decompressor?

The uncompressed list item format is the format, where every extension
header must changed into:

5.8.4.2.  Authentication Header (AH)
5.8.4.3.  Encapsulating Security Payload Header (ESP)
5.8.4.4.  GRE Header [RFC 2784, RFC 2890]

The other extension headers have the next header field as first, so
they can leave unchanged (as AH). ESP and GRE must be changed
accordingly. They are encoded into the generic scheme of the list
compression.

> è NULL ESP (RFC 3095, 5.8.4.3)
>
> RFC 3095, specifies the Uncompressed ESP list item in section
> 5.8.4.3. Also it specifies the procedure of the SN compression as
> same as AH.
>
> Please clarify me the below queries.
>
> 1. How to send uncompressed list item to decompressor? On which
>    packet?

See above.

> Thanks for your support.
>
> Regards,
> Anil Kumar Maguluri

br
Klaus

Regards,
Anil Kumar Maguluri


______________________________________________________________________



  ________________________________
This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

______________________________________________________________________

_______________________________________________
Rohc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rohc