Subject: [rohc] What will the next header field of IPX header indicates, there own type or there subsequent following header, in RFC3095 IPX list compression

From: Suneeta Rao <[email-masked]>
Date: Mon, 16 Nov 2009 03:28:19 -0800 (PST)

Hi ROHCers,

I have a doubt regarding the next header field in the IPX header in RFC3095 IPX list compression.

My doubt iswhat 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)
Ref: RFC3095 sec.5.8.4.4

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