Re: Compression of AH/NULL-ESP headers in ROHCv1
Klaus Warnke <[email protected]> Mon, 30 Nov 2009 16:12:11 +0100
| Newsgroups | gmane.ietf.rohc |
|---|---|
| Message-ID | <uws18oxmc.wl%[email protected]> |
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 inserted after/before them.
> 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.
> 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