[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] ROHCv2: co_repair revisited & coverage
Hi,
although not stated in my mail, we have revised the coverage of
the control_crc3 encoding. The text below is in the draft
right now, so I think we have already adressed your issue.
Let me know if you disagree.
/Kristofer
******************
6.6.11. control_crc3_encoding
The "control_crc3_encoding" method provides a CRC calculated over a
number of control fields. The definition of this encoding method is
the same as for the "crc" encoding method specified in section 4.11.6
of [RFC4997], with the difference that the data that is covered by
the CRC is given by a concatenated list of control fields.
In other words, the definition of the control_crc3_encoding method is
equivalent to the following definition:
control_crc_encoding(data_value, data_length)
{
UNCOMPRESSED {
}
COMPRESSED {
control_crc3 =:=
crc(3, 0x06, 0x07, ctrl_data_value, ctrl_data_length) [ 3 ];
}
}
where the parameter "ctrl_data_value" binds to the concatenated
values of the following control fields, in the order listed below:
o reorder_ratio, 2 bits padded by 6 MSB of zeroes
o ts_stride, 32 bits (applicable only for profiles 0x0101 and
0x0107)
o time_stride, 32 bits (applicable only for profiles 0x0101 and
0x0107)
o msn, 16 bits (not applicable for profiles 0x0101 and 0x0107, since
the RTP Sequence Number is already verified as part of the
uncompressed header)
o coverage_behavior, 2 bits padded by 6 MSB of zeroes, applicable
only to profiles 0x0107 and 0x0108
o ip_id_behavior, one octet for each IP header in the compressible
header chain starting from the outermost header. Each octet
consists of 2 bits padded by 6 MSBs of zeroes
The "ctrl_data_length" binds to the sum of the length of the control
field(s) that are applicable.
A 3-bit CRC is used to validate the control fields that are updated
by the co_common and co_repair packet types; it cannot verify the
outcome of a decompression attempt. The definition of this CRC comes
from the fact that the decompression of a header that carries and
updates control fields does not necessarily make use of these control
fields, and the update to the control fields is thus not protected by
the CRC-7 validation.
For example, without a verification of the updates to the control
fields, there would be a possibility that a decompression attempt
succeeds for a co_common or for a co_repair packet for which the
decompressor would send a positive feedback, even in the case where
one of the control fields had been corrupted on the link between the
compression endpoints.
*********************
> -----Original Message-----
> From: Carl Knutsson [mailto:carl.knutsson at effnet.com]
> Sent: den 26 september 2007 10:35
> To: Kristofer Sandlund
> Cc: rohc
> Subject: Re: [rohc] ROHCv2: co_repair revisited & coverage
>
> Hi Kristofer,
>
> I just want to point out that all not all control fields in dynamic
> chain are covered by a crc for this packet. It differs from how these
> fields are handled in co_common and IR.
>
> - In co_common, they are protected by the crc verification because
> depending fields are covered by the crc.
> - In IR the control fields itself is covered by crc-8.
>
> In this case since there are no crc8 over the field itself
> and depending
> fields are sent irregular(uncompressed). So decompression may be
> successful even with a broken decompressor context. The fields
> 'checksum_coverage' and 'ip_id_behavior' in outer header
> comes to mind.
> I am not sure this will be a problem, in this case the next
> packet will
> fail. Just keep it in mind, so that we don't make the same
> misstakes as
> with the IR-DYN in rfc3095.
>
> /Carl Knutsson
>
> Kristofer Sandlund wrote:
> > Hi all,
> >
> > we're finishing up the next revision of ROHCv2, and I
> > want it to contain a quite large change to how the co_repair
> > format looks. The more I've worked on the draft, the closer this
> > format has become to contining a dynamic chain, so I have decided
> > to change this packet format to be
> > <discriminator, CRC-7, CRC-3-control and a dynamic chain>
> > instead of its current co_common look-alike format.
> >
> > This should simplify implementation of these profiles while not
> > really changing the protocol very much (also, co_common becomes
> > a bit simpler since we can get rid of the repair_flag from it).
> >
> > If you wish to object, let me know ASAP before we submit the new
> > revision (of course, it can be reverted for a later rev. of the
> > draft if the WG objects, but it would be easier to do so now if
> > someone has reasons to object).
> >
> > /Kristofer
> >
> >
> > _______________________________________________
> > Rohc mailing list
> > Rohc at ietf.org
> > https://www1.ietf.org/mailman/listinfo/rohc
> >
>
>
_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc