H.225.0/RAS ICV calculation

Pekka Pessi pekka.pessi at research.nokia.com
Thu Jun 25 08:49:08 EDT 1998

"EXT Jim Toga" <jim.toga at intel.com> writes:
>I'm confused by a couple of your statements.

>The presence of the extention markers is included in the PER encoding (by a
>single bit at the beginning) but the addition of extentions at a later
>time should not change any of the encodings of the 'base' structure.  Any
>extentions that are added, end up following the PER structure and are
>actually encoded as BER 'chunks' so that earlier revisions of the protocol
>may skip over the ones not understood.

        Well, this is slightly incorrect.  A SEQUENCE type with extension
        additions is encoded as follows (see X.691 paragraphs 18.6 - 18.9):

        * extension marker at the beginning of SEQUENCE is encoded as 1 bit

        * the base structure is encoded

        * number of extensions is encoded as "normally small length"

        * a bit field with a bit for each extension is encoded
          (bit is one if the extension is present, zero if not)

        * present extensions are encoded as open type fields, i.e., normal
          PER encoding of the extension addition preceded by its length as

        Here is a concrete example (I hope).  There are two ASN.1 SEQUENCEs
        like this, one from hypothetical version 2, second from version 3:

Byte ::= INTEGER (0 .. 255)

Type-v2 ::= SEQUENCE
  foo Byte,
  bar Byte OPTIONAL

value-v2 Type-v2 ::= { foo 85, bar 170 }

Type-v3 ::= SEQUENCE
  foo Byte,
  bar Byte OPTIONAL,
  baz Byte OPTIONAL

value-v3 Type-v3 ::= { foo 85, bar 170 }

        We encode value-v2 and value-v3 with PER.  Results look like this:

80 55 01 01 aa
80 55 03 00 01 aa

        I'll go through the structure of value-v3:

hex     binary
80      1xxxxxxx        Extension bit (1 means that there are some
                        extensions present) followed by 7 bits for alignment
55      01010101        foo 85
03      0000001         number of extension additions minus 1 = 1
               1        first bit of bitfield, indicating "bar" is present
00      0xxxxxxx        second bit of bitfield, indicating "baz" is not
                        present, followed by 7 bits for alignment
01      00000001        lenght of "bar" in octets
aa      10101010        bar 170

        As you notice, the second addition, baz, changed the encoding even
        if it is not present in the SEQUENCE!

>I'm confused as to your example of encoding - decoding - re-encoding  The
>ICV _will_ have to be recalculated.  The ICV is calculated after the ASN.1
>structure is fully encoded (but excluding the ICV field itself) and just
>before it is sent out 'on the wire'.  The ICV value may in fact change
>value, and even position, but it should always be recognized by rev2 and
>newer implementations.  Rev1 obviously will ignore it and not generate one
>to send out....

        Receiver must decode the PDU, re-encode the PDU without ICV,
        calculate the ICV over the re-encoded PDU and compare the result
        with the ICV from decoded PDU.  If the ASN.1 version that receiver
        has (like Type-v3 above) differs from the version that sender has
        (like Type-v2 above), the re-encoded PDU differs from the PDU over
        which the sender calculated ICV.  Naturally the ICV also differs.

        I hope this cleared some confusion.

                                        Pekka Pessi

More information about the sg16-avd mailing list