Hi ROHCers,
I have a doubt regarding the next header field in the IPX header in RFC3095 IPX list compression.
My doubt is what will the next header field of IPX header indicates, there own type or there subsequent following header.
In relation to the IPX next header field I found two confusing statements in the RFC3095.
1)
Ref: RFC3095 sec.5.8.4.1.
5.8.4.1. Next Header field
The next header field in an IP header or extension header changes whenever the type of the immediately following header changes, e.g.,when a new extension header is inserted after it, when the immediate subsequent extension header is removed from the list, or when the order of extension headers is changed. Thus it may not be uncommon that, for a given header, the next header field changes while the remaining fields do not change.
Therefore, in the case that only the next header field changes, the extension header is considered to be unchanged and rules for special treatment of the change in the next header field are defined below.
All communicated uncompressed extension header items indicate their own type in their Next Header field. Note that the rules below explain how to treat the Next Header fields while showing the conceptual reference list as an exact recreation of the original uncompressed extension header list.
2)
5.8.4.4. GRE Header [RFC 2784, RFC 2890] The GRE header is a set of flags, followed by a mandatory
Protocol Type and optional parts as indicated by the flags.
The sequence number field in the GRE header contains a counter value
for a GRE tunnel. Therefore, when comparing curr_list with ref_list,
if the sequence number in GRE changes, the GRE is not considered as
changed.
If the sequence number in the GRE header linearly increases as the
RTP Sequence Number increases and the compressor is confident that
the decompressor has received the pattern, the sequence number in GRE
need not be sent. The decompressor applies linear extrapolation to
reconstruct the sequence number in the GRE header.
Otherwise, a compressed sequence number is included in the IPX
compression field in an Extension 3 of an UOR-2 header.
The checksum data field in GRE, if present, changes from packet to
packet and is sent as-is. If the uncompressed GRE header is sent,
the checksum data field is sent inside the uncompressed GRE header;
otherwise, if present, it is sent after the compressed IP/UDP/RTP and
IPv6 extension headers and before the payload. See beginning of
section 5.7.
In order to allow simple parsing of lists of items, an uncompressed
GRE header sent as an item in a list is modified from the original
GRE header in the following manner: 1) the 16-bit Protocol Type field
that encodes the type of the subsequent header using Ether types (see
Ether types section in [ASSIGNED]) is removed. 2) A one-octet Next
Header field is inserted as the first octet of the header. The value
of the Next Header field corresponds to GRE (this value is 47
according to the Assigned Internet Protocol Number section of
[ASSIGNED]) when the uncompressed item is to be inserted in a list,
and to the type of the subsequent header when the uncompressed item
is in a Generic list. Note that this implies that only GRE headers
with Ether types that correspond to an IP protocol number can be
compressed.
According to the first statement:
"All communicated uncompressed extension header items indicate their
own type in their Next Header field" and
According to the second statement.
"A one-octet Next Header field is inserted as the first octet of the header. The value
of the Next Header field corresponds to GRE (this value is 47
according to the Assigned Internet Protocol Number section of
[ASSIGNED]) when the uncompressed item is to be inserted in a list,
and to the type of the subsequent header when the uncompressed item
is in a Generic list".
So my confusion is that if the first statement is correct then why in
case of GRE header, Next Header field corresponds to GRE (i.e. own type)
when the uncompressed item is to be inserted in a list(i.e. Encoding type 1,2,3)
and to the type of the subsequent header when the uncompressed item
is in a Generic list(i.e. Encoding type 0).
Thanks and Regards
Suneeta Rao