Robust Header Compression (rohc)

headers Clark Peng (彭冠仁 | 23 May 2013 04:07

_______________________________________________
Rohc mailing list
Rohc <at> ietf.org
https://www.ietf.org/mailman/listinfo/rohc

Just FYI for anyone still reading this list, the ROHC-TCP update was published last month, 
obsoleting RFC4996. Hopefully, we managed to iron out the bugs that were left.

https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=934&k2=11613&tid=1360920357 

http://www.rfc-editor.org/rfc/rfc6846.txt

BR,
   Kristofer

Hello everybody,

I think, the msn_lsb() encoding method could be improved:

msn_lsb(k)
{
...
   COMPRESSED none {
     ENFORCE(reorder_ratio.UVALUE == REORDERING_NONE);
     master =:= lsb(k, 1);
   }
...
}

For reorder ratio REORDERING_NONE the
     master =:= lsb(k, -1);

is sufficient. That is, offset_param = -1,
If there is no reordering, there is no need to have a lower bound -1 
before the ref_value.
If the msn increase by +1, the lower bound could be ref_value +1.

See also rfc3095:

    a) For field values that are expected always to increase, p can be
       set to -1.  The interpretation interval becomes
       [v_ref + 1, v_ref + 2^k].

Any comments?

Regards,
Klaus

--

-- 
Klaus Warnke		klaus.warnke <at> acticom.de
http://www.acticom.de
Tel +49-30-4849.6891

acticom GmbH
Schwedter Str. 9b, 10119 Berlin, Germany
Managing Directors:  Olaf Kehrer, Gerrit Schulte
Commercial Register: Berlin-Charlottenburg HRB 73245
VAT-ID DE205131766

Hello everybody,

if the ip-id has a random behavior, it is sent in the irregular chain
as defined in ipv4() encoding method and ipv4_innermost_irregular format.
This encoding method has a DEFAULT section, which also defines that
tos_tc is encoded static (and other).
If I understand den ROHC FN right, the format
ipv4_innermost_irregular could not be used,
if the tos_tc could not encoded by the static encoding method.
But then I can not use co_common format to transmit tos_tc changes,
because the ip_id is not included in co_common if the behavior is random.
Is this correct?

Regards,
Klaus

--

-- 
Klaus Warnke		klaus.warnke <at> acticom.de
http://www.acticom.de
Tel +49-30-4849.6891

acticom GmbH
Schwedter Str. 9b, 10119 Berlin, Germany
Managing Directors:  Olaf Kehrer, Gerrit Schulte
Commercial Register: Berlin-Charlottenburg HRB 73245
VAT-ID DE205131766

The following errata report has been submitted for RFC5857,
"IKEv2 Extensions to Support Robust Header Compression over IPsec".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5857&eid=3320

--------------------------------------
Type: Editorial
Reported by: Nikolai Malykh <nmalykh <at> gmail.com>

Section: 3.1.2

Original Text
-------------
   This section describes five ROHC Attribute Types: MAX_CID,
   ROHC_PROFILE, ROHC_INTEG, ROHC_ICV_LEN, and MRRU.  The value
   allocated for each ROHC Attribute Type is specified in Section 4.

Corrected Text
--------------
   This section describes five ROHC Attribute Types: MAX_CID,
   ROHC_PROFILE, ROHC_INTEG, ROHC_ICV_LEN, and MRRU.  The value
   allocated for each ROHC Attribute Type is specified in Section 5.

Notes
-----
Section 4 of RFC 5857 is "Security Considerations". Values of ROHC Attribute Types listed in Section 5.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5857 (draft-ietf-rohc-ikev2-extensions-hcoipsec-12)
--------------------------------------
Title               : IKEv2 Extensions to Support Robust Header Compression over IPsec
Publication Date    : May 2010
Author(s)           : E. Ertekin, C. Christou, R. Jasani, T. Kivinen, C. Bormann
Category            : PROPOSED STANDARD
Source              : Robust Header Compression
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

As you may be aware, the authors of RFC 4996 have been working
on an update that's currently held up in the IESG Review based
on the following DISCUSS comment from Russ:

"""
  The issue below is the same as the one raised in the Gen-ART Review
  by Joel Halpern on 16-July-2012.

  Section 5.2.2.2 on negative acknowledgments includes the following:
  >
  > ... unless it has confidence that information sent after the packet
  > being acknowledged already provides a suitable response ...
  >
  This deals with a specific response to the NACK, it is unclear what
  constitutes confidence.  Other places in this document that refer to
  gaining confidence provide specific descriptions of how it is gained.
  The primary methods for gaining confidence are receiving acks or
  sufficient transmissions.  If all that is meant here is sufficient
  transmissions, please say so.
"""

There seems to be disagreement about whether additional text
would be useful in this regard.

We'd like to hear from people on this ROHC mailing list who
either have implemented or might implement this specification
as to whether or not more clarity is needed here, or if it's
really not useful or a good idea to add such text.

--

-- 
Wes Eddy
MTI Systems

The following errata report has been submitted for RFC5225,
"RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5225&eid=3248

--------------------------------------
Type: Technical
Reported by: FWX <rohc_team <at> dialine.fr>

Section: 6.8.2.4

Original Text
-------------
page 67:

  COMPRESSED udp_lite_endpoint_dynamic {
    ENFORCE(profile_value == PROFILE_UDPLITE_0108);
    reserved =:= compressed_value(4, 0)                      [  4 ];
    coverage_behavior =:= irregular(2)                       [  2 ];
    reorder_ratio     =:= irregular(2)                       [  2 ];
    checksum_coverage =:=
      checksum_coverage_dynchain(coverage_behavior.UVALUE)   [ 16 ];
    checksum          =:= irregular(16)                      [ 16 ];
    msn               =:= irregular(16)                      [ 16 ];
  }

page 68:

  COMPRESSED udp_lite_regular_dynamic {
    ENFORCE(profile_value == PROFILE_RTP_0107);
    coverage_behavior =:= irregular(2)                       [  2 ];
    reserved =:= compressed_value(6, 0)                      [  6 ];
    checksum_coverage =:=
        checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 16 ];
    checksum =:= irregular(16)                               [ 16 ];
  }

Corrected Text
--------------
page 67:

  COMPRESSED udp_lite_endpoint_dynamic {
    ENFORCE(profile_value == PROFILE_UDPLITE_0108);
    reserved =:= compressed_value(4, 0)                      [  4 ];
    coverage_behavior =:= irregular(2)                       [  2 ];
    reorder_ratio     =:= irregular(2)                       [  2 ];
    checksum_coverage =:=
      checksum_coverage_dynchain(coverage_behavior.UVALUE)   [ 0, 16 ];  <===
    checksum          =:= irregular(16)                      [ 16 ];
    msn               =:= irregular(16)                      [ 16 ];
  }

page 68:

  COMPRESSED udp_lite_regular_dynamic {
    ENFORCE(profile_value == PROFILE_RTP_0107);
    coverage_behavior =:= irregular(2)                       [  2 ];
    reserved =:= compressed_value(6, 0)                      [  6 ];
    checksum_coverage =:=
        checksum_coverage_dynchain(coverage_behavior.UVALUE) [ 0, 16 ];  <====
    checksum =:= irregular(16)                               [ 16 ];
  }

Notes
-----
checksum_coverage_dynchain(behavior) compression method (page 66) may compress the
checksum_coverage field to 0 bits if behavior is set to UDP_LITE_COVERAGE_INFERRED.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5225 (draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06)
--------------------------------------
Title               : RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite
Publication Date    : April 2008
Author(s)           : G. Pelletier, K. Sandlund
Category            : PROPOSED STANDARD
Source              : Robust Header Compression
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

_______________________________________________
Rohc mailing list
Rohc <at> ietf.org
https://www.ietf.org/mailman/listinfo/rohc

_______________________________________________
Rohc mailing list
Rohc <at> ietf.org
https://www.ietf.org/mailman/listinfo/rohc

Hello

In the encoding method ipv4() in the format ipv4_outer_irregular{}:

   COMPRESSED ipv4_outer_irregular {
     ENFORCE(is_innermost == 0);
     ip_id    =:=
       ip_id_enc_irreg(ip_id_behavior_outer.UVALUE)      [ 0, 16 ];
     tos_tc   =:= static_or_irreg(outer_ip_flag, 8)      [ 0, 8 ];
     ttl_hopl =:= static_or_irreg(outer_ip_flag, 8)      [ 0, 8 ];
   }

I could not determine how the value of the IP-ID in case of
ip_id_behavior_outer is either IP_ID_BEHAVIOR_SEQUENTIAL or
IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED is computed.

The encoding method ip_id_enc_irreg() is used to handle the IP-ID here.
But for the IP-ID behavior cases stated above I can not figure out,
how it is computed.

Did I oversee something?

Maybe the line
     ip_id         =:= inferred_sequential_ip_id       [ 0 ];
is absent here?

But it could not be, because the English text definition talks
about ip_id_behavior_innermost.

ip_id_enc_irreg(behavior)
{
   UNCOMPRESSED {
     ip_id [ 16 ];
   }

   COMPRESSED ip_id_seq {
     ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL);
+++    ip_id         =:= inferred_sequential_ip_id       [ 0 ];
   }

   COMPRESSED ip_id_seq_swapped {
     ENFORCE(behavior == IP_ID_BEHAVIOR_SEQUENTIAL_SWAPPED);
+++    ip_id         =:= inferred_sequential_ip_id       [ 0 ];
   }

   COMPRESSED ip_id_rand {
     ENFORCE(behavior == IP_ID_BEHAVIOR_RANDOM);
     ip_id =:= irregular(16) [ 16 ];
   }

   COMPRESSED ip_id_zero {
     ENFORCE(behavior == IP_ID_BEHAVIOR_ZERO);
     ip_id =:= uncompressed_value(16, 0) [ 0 ];
   }
}

If not, could please someone explain, how the IP-ID is computed for the 
outer headers?

Or in other words: If I receive an ipv4_outer_irregular{} format, how I 
get the IP-ID,
if its behavior is sequential or sequential swapped, i.e. no IP-ID bits 
are received
within the irregular chain.

Thanks and regards,
Klaus

--

-- 
Klaus Warnke		klaus.warnke <at> acticom.de
http://www.acticom.de
Tel +49-30-4849.6891

acticom GmbH
Schwedter Str. 9b, 10119 Berlin, Germany
Managing Directors:  Olaf Kehrer, Gerrit Schulte
Commercial Register: Berlin-Charlottenburg HRB 73245
VAT-ID DE205131766

The following errata report has been submitted for RFC5225,
"RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5225&eid=3185

--------------------------------------
Type: Editorial
Reported by: FWX <rohc_team <at> dialine.fr>

Section: page 64

Original Text
-------------
rtp(profile_value, ts_stride_value, time_stride_value,
    reorder_ratio_value)
{
  UNCOMPRESSED {
    ENFORCE((profile_value == PROFILE_RTP_0101) ||
            (profile_value == PROFILE_RTP_0107));
    rtp_version =:= uncompressed_value(2, 0) [  2 ];

Corrected Text
--------------
rtp(profile_value, ts_stride_value, time_stride_value,
    reorder_ratio_value)
{
  UNCOMPRESSED {
    ENFORCE((profile_value == PROFILE_RTP_0101) ||
            (profile_value == PROFILE_RTP_0107));
    rtp_version =:= uncompressed_value(2, 2) [  2 ];

Notes
-----
rtp_version is set to 2, not to zero.

See RTP Header Fields page 115 :

Version

      This field is expected to have the value two and the field is
      therefore classified as STATIC-KNOWN.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5225 (draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06)
--------------------------------------
Title               : RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite
Publication Date    : April 2008
Author(s)           : G. Pelletier, K. Sandlund
Category            : PROPOSED STANDARD
Source              : Robust Header Compression
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

1	May 2013
1	April 2013
1	February 2013
3	September 2012
2	August 2012
3	July 2012
2	June 2012
4	May 2012
6	April 2012
4	March 2012
1	February 2012
2	April 2011
2	March 2011
16	February 2011
4	January 2011
1	November 2010
1	October 2010
3	September 2010
7	June 2010
9	May 2010
6	April 2010
16	March 2010
24	February 2010
2	January 2010
5	December 2009
20	November 2009
8	October 2009
52	September 2009
17	August 2009
33	July 2009
12	June 2009
48	May 2009
24	April 2009
32	March 2009
13	February 2009
8	January 2009
5	December 2008
10	November 2008
6	October 2008
38	September 2008
8	August 2008
8	July 2008
1	June 2008
10	May 2008
5	April 2008
5	March 2008
4	February 2008
25	January 2008
38	December 2007
39	November 2007
38	October 2007
30	September 2007
29	August 2007
31	July 2007
21	June 2007
43	May 2007
9	April 2007
20	March 2007
14	February 2007
27	January 2007
37	December 2006
152	November 2006
110	October 2006
70	September 2006
53	August 2006
22	July 2006
37	June 2006
45	May 2006
27	April 2006
77	March 2006
40	February 2006
32	January 2006
45	December 2005
45	November 2005
59	October 2005
94	September 2005
96	August 2005
36	July 2005
66	June 2005
45	May 2005
139	April 2005
85	March 2005
72	February 2005
28	January 2005
89	December 2004
80	November 2004
156	October 2004
180	September 2004
43	August 2004
72	July 2004
101	June 2004
62	May 2004
98	April 2004
90	March 2004
46	February 2004
8	January 2004
71	December 2003
58	November 2003
40	October 2003
73	September 2003
17	August 2003
58	July 2003
98	June 2003
41	May 2003
74	April 2003
82	March 2003
86	February 2003
77	January 2003
59	December 2002
140	November 2002
108	October 2002
49	September 2002
67	August 2002
51	July 2002
63	June 2002
95	May 2002
163	April 2002

Query regarding the LSB encoding in TCP Profile

FYI: ROHC-TCP update => RFC6846

rfc5225 msn_lsb improvement

RFC5225 IP-ID with co_common and Random behavior and tos_tc changes

[Editorial Errata Reported] RFC5857 (3320)

RFC4996bis

[Technical Errata Reported] RFC5225 (3248)

Statefull SIGCOMP

Question regarding SIGCOMP

rfc5225 RoHCv2 ipv4_outer_irregular format question

[Editorial Errata Reported] RFC5225 (3185)

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31