[rohc] RFC4996 IP-ID with co_common and Random behavior

RoHC Team <rohc_team@dialine.fr> Mon, 27 February 2012 16:03 UTC

Return-Path: <rohc_team@dialine.fr>
X-Original-To: rohc@ietfa.amsl.com
Delivered-To: rohc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F33E21F87AF for <rohc@ietfa.amsl.com>; Mon, 27 Feb 2012 08:03:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.552
X-Spam-Level: *
X-Spam-Status: No, score=1.552 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXvquUev7MLK for <rohc@ietfa.amsl.com>; Mon, 27 Feb 2012 08:03:00 -0800 (PST)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) by ietfa.amsl.com (Postfix) with ESMTP id 53F9321F87AE for <rohc@ietf.org>; Mon, 27 Feb 2012 08:02:58 -0800 (PST)
Received: from [127.0.0.1] (unknown [88.185.172.218]) by smtp6-g21.free.fr (Postfix) with ESMTP id B4B3582346 for <rohc@ietf.org>; Mon, 27 Feb 2012 17:02:51 +0100 (CET)
Message-ID: <4F4BA931.8000203@dialine.fr>
Date: Mon, 27 Feb 2012 17:02:57 +0100
From: RoHC Team <rohc_team@dialine.fr>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: rohc@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 120227-0, 27/02/2012), Outbound message
X-Antivirus-Status: Clean
X-Mailman-Approved-At: Mon, 05 Mar 2012 00:27:15 -0800
Subject: [rohc] RFC4996 IP-ID with co_common and Random behavior
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: rohc_team@dialine.fr
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rohc>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Feb 2012 20:51:50 -0000

  Hello everybody,

  We are coding the RFC4996 and we don't understand how to send the 
value of the IPv4 IP-ID field, using the co_common compressed format, 
when the IP-ID has a random behavior.

  With the co_common format, there are :
  ip_id_indicator
  ip_id_behavior
  and ip_id =:= optional_ip_id_lsb( ip_id_behavior.UVALUE,
                                    ip_id_indicator.CVALUE)

  with :

optional_ip_id_lsb(behavior, indicator)
  {
    UNCOMPRESSED {
      ip_id [ 16 ];
    }

    COMPRESSED short {
      ip_id =:= ip_id_lsb(behavior, 8, 3) [ 8 ];
      ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
              (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
      ENFORCE(indicator == 0);
    }

    COMPRESSED long {
      ip_id =:= irregular(16)  [ 16 ];
      ENFORCE((behavior == IP_ID_BEHAVIOR_SEQUENTIAL) ||
              (behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED));
      ENFORCE(indicator == 1);
    }

    COMPRESSED not_present {
      ENFORCE((behavior == IP_ID_BEHAVIOR_RANDOM) ||
              (behavior == IP_ID_BEHAVIOR_ZERO));
    }
  }



  So, if ip_id_behavior is RANDOM, ip_id is not compressed (not present) 
! And we can't send the value ...

  Why not ip_id =:= irregular(16)  [ 16 ]; when behavior is RANDOM ?



  There is a contradiction with the paragraph 8.1 page 44/45 saying :

    All of the compressed base headers transmit LSB-encoded MSN bits, the
    TCP Push flag, and a CRC, and in addition to this, all the base
    headers in the sequential packet format set contain LSB-encoded IP-ID
    bits.

   o  Common header format: The common header format can be used for all
       kinds of IP-ID behavior and should be useful when some of the more
       rarely changing fields in the IP or TCP header change.  Since this
       header format can update control fields that decide how the
       decompressor interprets packets, it carries a 7-bit CRC to reduce
       the probability of context corruption.  This header can basically
       convey changes to any of the dynamic fields in the IP and TCP
       headers, and it uses a large set of flags to provide information
       about which fields are present in the header format.

  Thanks for help,

  Best regards
                    FWX.