RE: [rohc] query: encoding of IP-ID for RND=0 in extn3

Here's my understanding on this:

The IP-ID field in extension 3 follows the same rules as the IP-ID fields in
base headers: it is encoded based on its offset to the RTP SN and based on
its associated NBO setting.  When the base header conveying the extension 3
contains an IP-ID field (i.e. UO-1-ID in your example), then the IP-ID bits
in the base header become irrelevant since all 16-bits are already available
in the extension (based on the rule defined in RFC 3095, section 4.5.7).

Note also that IP-ID can either be the inner or the outer IP Identification
field.  This is based on the version of the inner and outer (if present) IP
headers and on their respective RND settings.

Anyone, 
	is this correct?

Salut,
Remi.

-----Original Message-----
From: Alan Kennington [mailto:ak1.rohc@topology.org]
Sent: Saturday, August 30, 2003 6:56 AM
To: ROHC mailing list
Subject: [rohc] query: encoding of IP-ID for RND=0 in extn3

I am having some difficulty in interpreting RFC 3095, 5.7, page 75.

============================================================
   IP-ID: A compressed IP-ID field.

      IP-ID fields in compressed base headers carry the compressed IP-ID
      of the innermost IPv4 header whose corresponding RND flag is not
      1.  The rules below assume that the IP-ID is for the innermost IP
      header.  If it is for an outer IP header, the RND2 and NBO2 flags
      are used instead of RND and NBO.

      If value(RND) = 0, hdr(IP-ID) is compressed using Offset IP-ID
      encoding (see section 4.5.5) using p = 0 and default-slope(IP-ID
      offset) = 0.

      If value(RND) = 1, IP-ID is the uncompressed hdr(IP-ID).  IP-ID is
      then passed as additional octets at the end of the compressed
      header, after any extensions.

      If value(NBO) = 0, the octets of hdr(IP-ID) are swapped before
      compression and after decompression.  The value of NBO is ignored
      when value(RND) = 1.
=============================================================

Suppose I have RND=0 and I send a UO-1-ID packet with extension 3.
Suppose also that I include the 16-bit IP Identification field in
the extension 3. This is in 5.7.5, p.85.

Then the IP-ID field is clearly not compressed. But RND = 0.
But sometimes the IP-ID field in the IP packets does not follow the
established pattern. Therefore I may have to send all 16 bits even
when RND = 0.

The above rules tell me what happens when RND = 0 and the IP-ID is
compressed. But here the IP-ID is _not_ compressed.

Question:
Now should I swap the bytes of IP-ID according to NBO?
Should I subtract SN from the IP Identification field before I write
it into the type 3 extension?

I think that it is equally credible that the IP-ID is encoded
(1) without SN offset and bytes swap (i.e. verbatim) or
(2) with SN offset and bytes swap.

Can anyone tell me what the majority view on this is?

Cheers,
Alan Kennington.

PS. The ROHC implementer's guide, version 3, 4.8, page 7, says that
the 16-bit IP Identification field in an IR/IR-DYN packet must be
sent verbatim because it is called "Identification", not IP-ID.
This tends to make me think that the extn 3 IP-ID _may_ be the
swapped/offset version of IP-ID. But it is still unclear to me.

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc