[rohc] SigComp Message and (extended) Returned feedback.

["Hans Hannu (EPL)" <[e-mail]>]

Hi,

As I indicated in a previous mail the two drafts are not fully compliant yet. This is a proposal for solving this.

In my comments to Miguel I explained why we need to signaling the state identifier length (ID length) in each SigComp message, and how the remaining bits can be used for a new basic SigComp message format. 

The reasons for having the ID-length in each SigComp message are the following:
* SigComp do not know the length of the state identifier prior to the capability announcement.
* As SigComp does not separate flows, SigComp needs to carry the hash length (ID length) for each SigComp message.  

The remaining 4-bits can be used for something else, and below is a proposal for the new SigComp basic Message format:

  0   1   2   3   4   5   6   7 
+---+---+---+---+---+---+---+---+ 
|  MT   |Reserv.|    ID length  | 
+---+---+---+---+---+---+---+---+ 
|                               | 
:   state_identifier (n-bytes)  :  
|                               | 
+---+---+---+---+---+---+---+---+ 
|                               | 
:    Remaining UDVM bytecode    : 
|                               | 
+---+---+---+---+---+---+---+---+ 

Instead of reserving a state_identifier for indication of what type of message this is, a Message Type is included. 

To avoid making changes to the UDVM instructions according to message:
http://www.cdt.luth.se/rohc/msg03674.html
and to make use of shared compression it is necessary for an endpoint to know whether its remote endpoint understands the format of the Returned feedback as depicted in Figure 7 of draft-ietf-rohc-sigcomp-extended-01.txt or not. 

Therefore I propose the following changes to the two sigcomp-drafts.

******** changes to draft-ietf-rohc-sigcomp-04.txt *******

Section 4.2. 

The basic SigComp message format is changed to the format above.

* Message Type
MT = '00' --- "ordinary compressed message"
MT = '01' --- "SigComp request message"
MT = '10' --- "SigComp Capability announcement message"
MT = '11' --- "Reserved"

* Reserv.
Bits 2 and 3 is reserved and is set to '00'

* Id length
The length of the state_identifier for this SigComp message
'0000' - 1 byte state_identifier
'0001' - 2 bytes state_identifier
...
'1111' - 16 bytes state_identifier

******** Changes to draft-ietf-rohc-sigcomp-extended-01.txt *******

Section 6.1.

The basic SigComp message format is changed to the format above.

The reserved bit 2, is used to indicate to the remote endpoint the understanding of the Returned feedback format as depicted in Figure 7.  Thus, an endpoint sets bit 2, in every sent SigComp message to indicate the understanding of the Returned feedback format. If two communicating end-points both sets bit 2. They MUST use the Returned feedback format as depicted in Figure 7. In any other case must no assumption be drawn about the format of the Returned feedback format.

Note: Setting bit 2 does not mandate an endpoint to use SigComp-extended, but only that it understands the Returned feedback format and will use the 'r' and 'b' etc. bits accordingly.
 
Figure 7, is changed to:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |r|b|        n              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        id_length 1        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           |
   :        id_value_1         :
   |                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        id_length 2        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           |
   :        id_value_2         :
   |                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            :         :
            :         :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        id_length n        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           |
   :        id_value_n         :
   |                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           |
   :    Additional feedback    :
   |                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Additional feedback is an item of feedback data that has successfully returned from the remote endpoint.

****************

BR
/Hans H

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