Subject: [rohc] RE: Outer IP-ID field

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 12 May 2004 10:49:33 +0200

Vick (and others),

See page 75, "IP-ID":

"IP-ID fields in compressed base headers carry the compressed IP-ID
of the innermost IPv4 header whose corresponding RND flag is not 1."

This means for two IP headers (IP-ID field means the field in compressed headers):

IPv6/IPv6/UDP/RTP : No IP-ID field in compressed headers.
IPv6/IPv4(RND=1)/UDP/RTP : No IP-ID field in compressed headers.
IPv6/IPv4(RND=0)/UDP/RTP : The IP-ID field corresponds to the inner header.
IPv4(RND=1)/IPv6/UDP/RTP : No IP-ID field in compressed headers.
IPv4(RND=0)/IPv6/UDP/RTP : The IP-ID field corresponds to the outer header.
IPv4(RND=1)/IPv4(RND=1)/UDP/RTP: No IP-ID field in compressed headers.
IPv4(RND=1)/IPv4(RND=0)/UDP/RTP: The IP-ID field corresponds to the inner header.
IPv4(RND=0)/IPv4(RND=0)/UDP/RTP: The IP-ID field corresponds to the inner header.
                                 This last case would only work if the outer IP-ID
                                 is totally sequential N, N+1, N+2...etc.
                                 (previous config should be used instead)

Crystal clear from RFC3095...=)

/L-E 

> -----Original Message-----
> From: Vicknesan Ayadurai (KI/EAB) 
> Sent: den 4 maj 2004 17:38
> To: Lars-Erik Jonsson (LU/EAB)
> Subject: Outer IP-ID field
> 
> 
> Hi L-E,
> 
> Regarding our brief chat regarding the outer IP-ID field, there
> doesn't seem to be too much detail in the RFC regarding this. Page 75
> describes the compressed IP-ID field, but mainly focus on how IP-ID is
> encoded, and not what happens with the outer IP-ID. It says:
> 
> "... 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."
> 
> which doesn't really clarify things up (to me anyway).
> 
> The simplest thing I think, as we talked, would be to send the
> complete outer IP-ID in full all the time. This means that RND2 is
> always set whenever there's an outer IP-ID, but I didn't find any
> clear text saying this.
> 
> Would this be the correct interpretation of how to handle the outer
> IP-ID field?
> 
> Regards,
> vick
> 

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

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 14 May 2004 09:08:27 +0200

The discussion continued offline, see below, but the conclusion is
that IP-ID is always sent offset-IPID-encoded if it is not RND
(sent at the end of the compressed base header), and this applies
to both inner and outer IP-ID bits.

/L-E

-----Original Message-----
From: Kristofer Sandlund [mailto:[email-masked]]
Sent: den 14 maj 2004 08:25
To: Vicknesan Ayadurai (KI/EAB)
Cc: Lars-Erik Jonsson (LU/EAB); Karl Norrman; Karl Norrman (KI/EAB)
Subject: Re: Outer IP-ID field

Hi,

comments inlined.

Vicknesan Ayadurai wrote:
> Hi LE,
> 
> I vaguely recall having a discussion during one of the interops where
> the meaning of "Identity" and "IP-ID" was clarified, and documented in
> the implementers guide (which I now can't find on the ROHC IETF page).
> 
> I think "Identity" was meant to be the entire (verbatim) 16-bits of IP
> ID field, as transmitted in an IRDYN for e.g., while "IP-ID" is meant
> to be the bits of an *encoded* IP-ID field (IP-ID - SN).
> 
> Hence, my question below was what happens when a UO-1-ID packet is
> generated for the situation where:
> 
> 
> i.e., what are the IP-ID bits in the UO-1-ID packets?
> 
> More generally, I understand the ID-bits in a UO-1-ID packet to always
> be the *encoded* IP-ID bits. What is the encoding process when the
> tunnel header has an IP-ID field, but the inner IP header has no IP-ID
> field (IPv6 or RND IP-ID for e.g.)?
> 

Isn't it simply so that if we don't send the IP-ID uncompressed (all 16 bits), 
then we always send it offset-IPID-encoded, even if it is the outer header. 
Sure, we might not have AS strong a correlation to SN, so we'll have to send 
more bits, but we'll probably still be sending less than 16 bits. And there's 
always the choice for the compressor to set RND2 in this case, if the offset 
encoding isn't good enough. With ROHC, everything and then some is possible, 
even the most silly things, like sending ext3 on a UO-1-ID packet ;)

/Kristofer