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

From: Remi Pelland <[email-masked]>
Date: Tue, 2 Sep 2003 09:30:37 -0400

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:[email-masked]]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Remi Pelland <[email-masked]>
Date: Thu, 11 Sep 2003 10:15:57 -0400

My interpretation is as follows:

Because the field is called "IP-ID", and because the definition for that
field (at the bottom of page 84) refers to the beginning of section 5.7, I
believe the swapped/offset should be sent.

I know that the beginning of section 5.7 refers to the "compressed" IP-ID
field and that in this particular case, it does not seem appropriate to
think about the IP-ID field as being compressed since we're sending all 16
bits.  However, the fact that this field is called "IP-ID" and that an
explicit reference to the beginning of section 5.7 is made leads me to think
that the swapped/offset field should be sent.

Remi.

-----Original Message-----
From: Lars-Erik Jonsson (LU/EAB) [mailto:[email-masked]]
Sent: Wednesday, September 10, 2003 3:50 AM
To: ROHC mailing list
Subject: RE: [rohc] query: encoding of IP-ID for RND=0 in extn3

Alan and others,

This observation deserves some attention. Personally, I
do not have any strong opinions on this subject, and I
agree with Alan's PS that it seems like the RFC would
go towards (2). However, to me it looks like (1) had 
been much more straight forward.

Implementer's and others, please speak up!!

/L-E

> Sent: den 30 augusti 2003 12:56
> To: ROHC mailing list