[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-price-rohc-sigcomp-torture-tests) 00 01 02 03 RFC 4465

Robust Header Compression                                     A. Surtees
Internet-Draft                                                   M. West
Expires: January 19, 2006                    Siemens/Roke Manor Research
                                                           July 18, 2005


                         SigComp Torture Tests
              draft-ietf-rohc-sigcomp-torture-tests-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 19, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document provides a set of "torture tests" for implementers of
   the SigComp protocol.  The torture tests check each of the SigComp
   Universal Decompressor Virtual Machine instructions in turn, focusing
   in particular on the boundary and error cases that are not generally
   encountered when running well-behaved compression algorithms.  Tests
   are also provided for other SigComp entities such as the dispatcher
   and the state handler.




Surtees & West          Expires January 19, 2006                [Page 1]


Internet-Draft            SigComp Torture Tests                July 2005


Change history

   Changes relative to <draft-ietf-rohc-sigcomp-torture-tests-00.txt>:
   1.  Modified COPY, COPY-LITERAL and COPY-OFFSET, state creation,
       state access and input beyond message tests.
   2.  Added extra explanation of tests
   3.  Added new infinite loop test.

   Changes relative to <draft-price-rohc-sigcomp-torture-tests-02.txt>:
   1.  Changed name to draft-ietf-rohc-sigcomp-torture-tests-00.txt
   2.  Addition of test for state creation and self modifying code.
   3.  Addition of test for reference of static dictionary RFC-3485 [3].

   Changes relative to <draft-price-rohc-sigcomp-torture-tests-01.txt>:
   1.  Added a test for the SigComp dispatcher (covering the case where
       input is requested that lies beyond the end of a message).
   2.  Fixed a typo in the input for Section 2.16.

   Changes relative to <draft-price-rohc-sigcomp-torture-tests-00.txt>:
   1.  Added tests for the SigComp dispatcher (covering the SigComp
       Useful Values, the SigComp header for message-based transports,
       and the record marking scheme for stream-based transports).
   2.  Added tests for the SigComp state handler (covering the SigComp
       feedback mechanism, the state memory management and the
       interaction between multiple compartments).
   3.  Updated the cost of the sorting instructions based on the new
       values used in SigComp RFC-3320 [2].
   4.  Updated the stack manipulation test to work correctly when the
       decompression_memory_size is only 2048 bytes.






















Surtees & West          Expires January 19, 2006                [Page 2]


Internet-Draft            SigComp Torture Tests                July 2005


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.   Torture tests for UDVM . . . . . . . . . . . . . . . . . . .   5
     2.1  Bit manipulation . . . . . . . . . . . . . . . . . . . . .   5
     2.2  Arithmetic . . . . . . . . . . . . . . . . . . . . . . . .   7
     2.3  Sorting  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     2.4  SHA-1  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     2.5  LOAD and MULTILOAD . . . . . . . . . . . . . . . . . . . .  11
     2.6  COPY . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     2.7  COPY-LITERAL and COPY-OFFSET . . . . . . . . . . . . . . .  14
     2.8  MEMSET . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     2.9  CRC  . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
     2.10   INPUT-BITS . . . . . . . . . . . . . . . . . . . . . . .  18
     2.11   INPUT-HUFFMAN  . . . . . . . . . . . . . . . . . . . . .  19
     2.12   INPUT-BYTES  . . . . . . . . . . . . . . . . . . . . . .  21
     2.13   Stack manipulation . . . . . . . . . . . . . . . . . . .  23
     2.14   Program flow . . . . . . . . . . . . . . . . . . . . . .  25
     2.15   State creation . . . . . . . . . . . . . . . . . . . . .  26
     2.16   STATE-ACCESS . . . . . . . . . . . . . . . . . . . . . .  29
   3.   Torture tests for dispatcher . . . . . . . . . . . . . . . .  31
     3.1  Useful Values  . . . . . . . . . . . . . . . . . . . . . .  31
     3.2  Cycles checking  . . . . . . . . . . . . . . . . . . . . .  34
     3.3  Message-based transport  . . . . . . . . . . . . . . . . .  35
     3.4  Stream-based transport . . . . . . . . . . . . . . . . . .  37
     3.5  Input past the end of a message  . . . . . . . . . . . . .  39
   4.   Torture tests for state handler  . . . . . . . . . . . . . .  41
     4.1  SigComp feedback mechanism . . . . . . . . . . . . . . . .  41
     4.2  State memory management  . . . . . . . . . . . . . . . . .  44
     4.3  Multiple compartments  . . . . . . . . . . . . . . . . . .  48
     4.4  Accessing RFC 3485 State . . . . . . . . . . . . . . . . .  52
     4.5  Bytecode state creation  . . . . . . . . . . . . . . . . .  53
   5.   Security considerations  . . . . . . . . . . . . . . . . . .  56
   6.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  56
   7.   References . . . . . . . . . . . . . . . . . . . . . . . . .  56
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  57
   A.   UDVM bytecode for the torture tests  . . . . . . . . . . . .  57
     A.1  Instructions . . . . . . . . . . . . . . . . . . . . . . .  57
       A.1.1  Bit manipulation . . . . . . . . . . . . . . . . . . .  57
       A.1.2  Arithmetic . . . . . . . . . . . . . . . . . . . . . .  58
       A.1.3  Sorting  . . . . . . . . . . . . . . . . . . . . . . .  58
       A.1.4  SHA-1  . . . . . . . . . . . . . . . . . . . . . . . .  59
       A.1.5  LOAD and MULTILOAD . . . . . . . . . . . . . . . . . .  59
       A.1.6  COPY . . . . . . . . . . . . . . . . . . . . . . . . .  60
       A.1.7  COPY-LITERAL and COPY-OFFSET . . . . . . . . . . . . .  60
       A.1.8  MEMSET . . . . . . . . . . . . . . . . . . . . . . . .  61
       A.1.9  CRC  . . . . . . . . . . . . . . . . . . . . . . . . .  61
       A.1.10   INPUT-BITS . . . . . . . . . . . . . . . . . . . . .  61



Surtees & West          Expires January 19, 2006                [Page 3]


Internet-Draft            SigComp Torture Tests                July 2005


       A.1.11   INPUT-HUFFMAN  . . . . . . . . . . . . . . . . . . .  61
       A.1.12   INPUT-BYTES  . . . . . . . . . . . . . . . . . . . .  62
       A.1.13   Stack Manipulation . . . . . . . . . . . . . . . . .  62
       A.1.14   Program Flow . . . . . . . . . . . . . . . . . . . .  62
       A.1.15   State creation . . . . . . . . . . . . . . . . . . .  63
       A.1.16   STATE-ACCESS . . . . . . . . . . . . . . . . . . . .  64
     A.2  Dispatcher tests . . . . . . . . . . . . . . . . . . . . .  65
       A.2.1  Useful Values  . . . . . . . . . . . . . . . . . . . .  65
       A.2.2  Cycles Checking  . . . . . . . . . . . . . . . . . . .  65
       A.2.3  Message-based transport  . . . . . . . . . . . . . . .  66
       A.2.4  Stream-based transport . . . . . . . . . . . . . . . .  66
       A.2.5  Input past the end of a message  . . . . . . . . . . .  67
     A.3  State handler tests  . . . . . . . . . . . . . . . . . . .  68
       A.3.1  SigComp feedback mechanism . . . . . . . . . . . . . .  68
       A.3.2  State memory management  . . . . . . . . . . . . . . .  68
       A.3.3  Multiple compartments  . . . . . . . . . . . . . . . .  70
       A.3.4  Accessing RFC 3485 State . . . . . . . . . . . . . . .  71
       A.3.5  Bytecode state creation  . . . . . . . . . . . . . . .  71
        Intellectual Property and Copyright Statements . . . . . . .  73
































Surtees & West          Expires January 19, 2006                [Page 4]


Internet-Draft            SigComp Torture Tests                July 2005


1.  Introduction

   This document provides a set of torture tests for implementers of the
   SigComp protocol RFC-3320 [2].  The idea behind SigComp is to
   standardize a Universal Decompressor Virtual Machine (UDVM) that can
   be programmed to understand the output of many well-known compressors
   including DEFLATE and LZW.  The bytecode for the chosen decompressor
   is uploaded to the UDVM as part of the SigComp message flow.

   The SigComp User Guide [1] offers a number of different algorithms
   that can be used by the SigComp protocol.  However, the bytecode for
   the corresponding decompressors is relatively well behaved and does
   not test the boundary and error cases that may potentially be
   exploited by malicious SigComp messages.

   This document is divided into a number of sections, each containing a
   piece of code designed to test a particular function of one of the
   SigComp entities (UDVM, dispatcher and state handler).  The specific
   boundary and error cases tested by the bytecode are also listed, as
   are the output the code should produce and the number of UDVM cycles
   that should be used.

2.  Torture tests for UDVM

   The following sections each provide code to test one or more UDVM
   instructions.  In the interests of readability the code is given
   using the SigComp assembly language: a description of how to convert
   this assembly code into UDVM bytecode can be found in the SigComp
   User Guide [1].

   The raw UDVM bytecode for each torture test is given in Appendix A.

   Each section also lists the number of UDVM cycles required to execute
   the code.  Note that this figure only takes into account the cost of
   executing each UDVM instruction (in particular it ignores the fact
   that the UDVM can gain extra cycles as a result of inputting more
   data).

2.1  Bit manipulation

   This section gives assembly code to test the AND, OR, NOT, LSHIFT and
   RSHIFT instructions.  When the instructions have a multitype operand
   the code tests the case where the multitype contains a fixed integer
   value, and the case where it contains a memory address at which the
   2-byte operand value can be found.  In addition the code is designed
   to test that the following boundary cases have been correctly
   implemented:




Surtees & West          Expires January 19, 2006                [Page 5]


Internet-Draft            SigComp Torture Tests                July 2005


   1.  The instructions overwrite themselves with the result of the bit
   manipulation operation, in which case execution continues normally.

   2.  The LSHIFT or RSHIFT instructions shift bits beyond the 2-byte
   boundary, in which case the bits must be discarded.

   3.  The UDVM registers byte_copy_left and byte_copy_right are used to
   store the results of the bit manipulation operations.  Since no byte
   copying is taking place these registers should behave in exactly the
   same manner as ordinary UDVM memory addresses.


   at (64)

   :a                              pad (2)
   :b                              pad (2)

   at (128)

   JUMP (start)            ; Jump to address 255

   at (255)

   :start

   ; The multitypes are values
                           ; $start = 448 (first 2 bytes of AND instr)
   AND ($start, 21845)     ; 448 & 21845 = 320 = 0x0140
   OR ($a, 42)             ; 0 | 42 = 42 = 0x002a
   NOT ($b)                ; ~0 = 65535 = 0xffff
   LSHIFT ($a, 3)          ; 42 << 3 = 336 = 0x0150
   RSHIFT ($b, 65535)      ; 65535 >> 65535 = 0 = 0x0000

   OUTPUT (64, 4)          ; Output 0x0150 0000

   ; The multitypes are references

   AND ($a, $start)        ; 336 & 320 = 320 = 0x0140
   OR ($a, $a)             ; 320 | 320 = 320 = 0x0140
   NOT ($a)                ; ~320 = 65215 = 0xfebf
   LSHIFT ($b, $a)         ; 0 << 65215 = 0 = 0x0000
   RSHIFT ($a, $b)         ; 65215 >> 0 = 65215 = 0xfebf

   OUTPUT (64, 4)          ; Output 0xfebf 0000

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)





Surtees & West          Expires January 19, 2006                [Page 6]


Internet-Draft            SigComp Torture Tests                July 2005


   The output of the code is 0x0150 0000 febf 0000.  Executing the code
   costs a total of 22 UDVM cycles.

2.2  Arithmetic

   This section gives assembly code to test the ADD, SUBTRACT, MULTIPLY,
   DIVIDE and REMAINDER instructions.  The code is designed to test that
   the following boundary cases have been correctly implemented:

   1.  The instructions overwrite themselves with the result of the
   arithmetic operation, resulting in continuation as if the bytes were
   not bytecode.

   2.  The result does not lie between 0 and 2^16 - 1 inclusive, in
   which case it must be taken modulo 2^16.

   3.  The divisor in the DIVIDE or REMAINDER instructions is 0 (in
   which case decompression failure must occur).


   at (64)

   :a                              pad (2)
   :b                              pad (2)
   :type                           pad (1)
   :type_lsb                       pad (1)

   at (128)

   INPUT-BYTES (1, type_lsb, !)
   SUBTRACT ($type, 1)
   JUMP (start)

   ; Now the value in $type should be 0xffff, 0x0000 or 0x0001 according
   ; to whether the input was 0x00, 0x01 or 0x02.

   at (255)

   :start

   ; The multitypes are values
                           ; For all three messages
                           ; $start = 1728 (first 2 bytes of ADD instr)
   ADD ($start, 63809)     ; 1728 + 63809 = 1 = 0x0001
   SUBTRACT ($a, 1)        ; 0 - 1 = 65535 = 0xffff
   MULTIPLY ($a, 1001)     ; 65535 * 1001 = 64535 = 0xfc17
   DIVIDE ($a, 101)        ; 64535 / 101 = 638 = 0x027e
   REMAINDER ($a, 11)      ; 638 % 11 = 0 = 0x0000



Surtees & West          Expires January 19, 2006                [Page 7]


Internet-Draft            SigComp Torture Tests                July 2005


   OUTPUT (64, 4)          ; output 0x0000 0000

   ; The multitypes are references
   ADD ($b, $start)        ; 0 + 1 = 1 = 0x0001

                           ; If the message is 0x00
   SUBTRACT ($b, $type)    ; 1 - 65535 = 2 = 0x0002
   MULTIPLY ($b, $b)       ; 2 * 2 = 4 = 0x0004
   DIVIDE ($a, $b)         ; 0 / 4 = 0 = 0x0000
   REMAINDER ($b, $type)   ; 4 % 65535 = 4 = 0x0004

   OUTPUT (64, 4)          ; output 0x0000 0004

                           ; If the message is 0x01, $type = 0
                           ; so decompression failure occurs at
                           ; REMAINDER ($b, $type)

                           ; If the message is 0x02, $type = 1 so
                           ; $b becomes 0 and decompression failure
                           ; occurs at DIVIDE ($a, $b)

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)


   If the compressed message is 0x00 then the output of the code is
   0x0000 0000 0000 0004 and the execution cost should be 25 UDVM
   cycles.  However, if the compressed message is 0x01 or 0x02 then
   decompression failure occurs.

2.3  Sorting

   This section gives assembly code to test the SORT-ASCENDING and SORT-
   DESCENDING instructions.  The code is designed to test that the
   following boundary cases have been correctly implemented:

   1.  The sorting instructions sort integers with the same value, in
   which case the original ordering of the integers must be preserved.














Surtees & West          Expires January 19, 2006                [Page 8]


Internet-Draft            SigComp Torture Tests                July 2005


   at (128)

   SORT-DESCENDING (256, 2, 23)
   SORT-ASCENDING (256, 2, 23)

   OUTPUT (302, 45)
   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)

   at (256)

   word (10, 10, 17, 7, 22, 3, 3, 3, 19, 1, 16, 14, 8, 2, 13, 20, 18,
   23, 15, 21, 12, 6, 9)

   word (28263, 8297, 30057, 8308, 26996, 11296, 31087, 29991, 8275,
   18031, 28263, 24864, 30066, 29284, 28448, 29807, 28206, 11776, 28773,
   28704, 28276, 29285, 28265)


   The output of the code is 0x466f 7264 2c20 796f 7527 7265 2074 7572
   6e69 6e67 2069 6e74 6f20 6120 7065 6e67 7569 6e2e 2053 746f 7020 6974
   2e, and the number of cycles required is 371.

2.4  SHA-1

   This section gives assembly code to test the SHA-1 instruction.  The
   code performs four tests on the SHA-1 algorithm itself, and
   additionally checks the following boundary cases specific to the
   UDVM:

   1.  The input string for the SHA-1 hash is obtained by byte copying
   over an area of the UDVM memory.

   2.  The SHA-1 hash overwrites its own input string.


   at (64)

   :byte_copy_left                 pad (2)
   :byte_copy_right                pad (2)
   :hash_value                     pad (20)

   at (128)

   SHA-1 (test_one, 3, hash_value)
   OUTPUT (hash_value, 20)

   SHA-1 (test_two, 56, hash_value)
   OUTPUT (hash_value, 20)



Surtees & West          Expires January 19, 2006                [Page 9]


Internet-Draft            SigComp Torture Tests                July 2005


   ; Set up a 1 byte buffer
   LOAD (byte_copy_left, test_three)
   LOAD (byte_copy_right, test_four)

   ; Perform SHA-1 over a 1 byte buffer
   SHA-1 (test_three, 65535, hash_value)
   OUTPUT (hash_value, 20)

   ; Set up an 8 byte buffer
   LOAD (byte_copy_left, test_four)
   LOAD (byte_copy_right, test_end)

   ; Perform SHA-1 over an 8 byte buffer
   SHA-1 (test_four, 640, test_four)
   OUTPUT (test_four, 20)

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)

   :test_one

   byte (97, 98, 99)

   :test_two

   byte (97, 98, 99, 100, 98, 99, 100, 101, 99, 100, 101, 102, 100, 101,
   102, 103, 101, 102, 103, 104, 102, 103, 104, 105, 103, 104, 105, 106,
   104, 105, 106, 107, 105, 106, 107, 108, 106, 107, 108, 109, 107, 108,
   109, 110, 108, 109, 110, 111, 109, 110, 111, 112, 110, 111, 112, 113)

   :test_three

   byte (97)

   :test_four

   byte (48, 49, 50, 51, 52, 53, 54, 55)

   :test_end


   The output of the code is as follows:


   0xa999 3e36 4706 816a ba3e 2571 7850 c26c 9cd0 d89d
   0x8498 3e44 1c3b d26e baae 4aa1 f951 29e5 e546 70f1
   0xe1d0 a18d 43d3 a689 af08 8e15 6bd0 434a a0c8 31fc
   0x4f46 0452 ebb5 6393 4f46 0452 ebb5 6393 4f46 0452




Surtees & West          Expires January 19, 2006               [Page 10]


Internet-Draft            SigComp Torture Tests                July 2005


   Executing the code costs a total of 66327 UDVM cycles.

2.5  LOAD and MULTILOAD

   This section gives assembly code to test the LOAD and MULTILOAD
   instructions.  The code is designed to test the following boundary
   cases:

   1.  The MULTILOAD instruction overwrites itself or any of its
   operands, in which case decompression failure occurs.

   2.  The memory references of MULTILOAD instruction operands are
   evaluated step-by-step rather than all at once before starting to
   copy data.


   at (64)

   :start                          pad (1)
   :start_lsb                      pad (1)

   at (128)

   set (location_a, 128)
   set (location_b, 132)

   LOAD (128, 132)                 ; address 128 contains 132 = 0x0084
   LOAD (130, $location_a)         ; address 130 contains 132 = 0x0084
   LOAD ($location_a, 134)         ; address 132 contains 134 = 0x0086
   LOAD ($location_b, $location_b) ; address 134 contains 134 = 0x0086
   OUTPUT (128, 8)                 ; output 0x0084 0084 0086 0086

   INPUT-BYTES (1, start_lsb, !)
   MULTIPLY ($start, 2)
   ADD ($start, 60)
   MULTILOAD ($start, 3, overlap_start, overlap_end, 128)

   :position

   set (overlap_start, (position - 7))

   MULTILOAD ($start, 4, 42, 128, $location_a, $location_b)

   :end

   set (overlap_end, (end - 1))

   OUTPUT (128, 8)



Surtees & West          Expires January 19, 2006               [Page 11]


Internet-Draft            SigComp Torture Tests                July 2005


   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)


   The INPUT-BYTES, MULTIPLY and ADD instructions give the following
   values for $start = $64 just before the MULTILOADs begin:


   Input     $start before 1st MULTILOAD
   0x00            60
   0x01            62
   0x02            64


   Consequently after the first MULTILOAD the values of $start are:


   Input     $start before 2nd MULTILOAD
   0x00      128
   0x01      overlap_end = 178 = last byte of 2nd MULTILOAD instruction
   0x02      overlap_start = 163 = 7 bytes before 2nd MULTILOAD
             instruction


   Consequently execution of the 2nd MULTILOAD (and any remaining code
   gives):


   Input   Outcome
   0x00    MULTILOAD reads and writes operand by operand. The output is
           0x0084 0084 0086 0086 002a 0080 002a 002a, and the cost of
           executing the code is 36 UDVM cycles.

   0x01    The first write of the MULTILOAD instruction would overwrite
           the last byte of the final MULTILOAD operand, so
           decompression failure occurs.

   0x02    The last write of the MULTILOAD would overwrite the MULTILOAD
           opcode so decompression failure occurs.



2.6  COPY

   This section gives assembly code to test the COPY instruction.  The
   code is designed to test that the following boundary cases have been
   correctly implemented:

   1.  The COPY instruction copies data from both outside the circular



Surtees & West          Expires January 19, 2006               [Page 12]


Internet-Draft            SigComp Torture Tests                July 2005


   buffer and inside the circular buffer within the same operation.

   2.  The COPY instruction performs byte-by-byte copying (i.e. some of
   the later bytes to be copied are themselves written into the UDVM
   memory by the COPY instruction currently being executed).

   3.  The COPY instruction overwrites itself and continues executing.

   4.  The COPY instruction overwrites the UDVM registers byte_copy_left
   and byte_copy_right.

   5.  The COPY instruction writes to and reads from the right of the
   buffer beginning at byte_copy_right.

   6.  The COPY instruction implements byte copying rules when the
   destination wraps around the buffer.



































Surtees & West          Expires January 19, 2006               [Page 13]


Internet-Draft            SigComp Torture Tests                July 2005


   at (64)

   :byte_copy_left                 pad (2)
   :byte_copy_right                pad (2)

   at (128)
                           ; Set up buffer between addresses 64 & 128
   LOAD (32, 16384)
   LOAD (byte_copy_left, 64)
   LOAD (byte_copy_right, 128)

   COPY (32, 128, 33)      ; Copy byte by byte starting to left of
                           ; buffer, into buffer and wrapping round
                           ; the buffer (inc overwriting boundaries)

   LOAD (64, 16640)        ; Change start of buffer to be beyond
                           ; bytecode

   COPY (64, 85, 65)       ; Copy to the left of the buffer,
                           ; overwriting this instruction

   OUTPUT (32, 119)        ; Output 32 * 0x40 + 86 * 0x41 + 0x55
                           ; which is 32 * '@' + 86 'A' + 'U'

                           ; Set a new small buffer
   LOAD (byte_copy_left, 32)
   LOAD (byte_copy_right, 48)

   MEMSET (32, 4, 65, 1)   ; Set first 4 bytes of buffer to be "ABCD"
   COPY (32, 4, 48)        ; Copy from byte_copy_right (i.e. not
                           ; in buffer)

   OUTPUT (48, 4)          ; Output 0x4142 4344 which is 'ABCD'

   COPY (48, 4, 46)        ; Copy from two before byte_copy_right to
                           ; wrap around the buffer
   OUTPUT (32, 2)          ; Output 0x4344 which is 'CD'

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)


   The output is above and executing the code costs a total of 365 UDVM
   cycles.

2.7  COPY-LITERAL and COPY-OFFSET

   This section gives assembly code to test the COPY-LITERAL and COPY-
   OFFSET instructions.  The code is designed to test similar boundary



Surtees & West          Expires January 19, 2006               [Page 14]


Internet-Draft            SigComp Torture Tests                July 2005


   cases to the code for the COPY instruction, as well as the following
   condition specific to COPY-LITERAL and COPY-OFFSET:

   1.  The COPY-LITERAL or COPY-OFFSET instruction overwrites the value
   of its destination.

   2.  The COPY-OFFSET instruction reads from an offset that wraps
   around the buffer (i.e. the offset is larger than the distance
   between byte_copy_left and the destination).


   at (64)

   :byte_copy_left                 pad (2)
   :byte_copy_right                pad (2)
   :destination                    pad (2)
   :offset                         pad (2)

   at (128)
                                   ; Set up circular buffer, source and
                                   ; destination
   LOAD (32, 16640)
   LOAD (byte_copy_left, 64)
   LOAD (byte_copy_right, 128)
   LOAD (destination, 33)

   COPY-LITERAL (32, 128, $destination)    ; Copy from the left of the
                           ; overwriting bcl, bcr and destination
                           ; wrapping round the buffer
   OUTPUT (64, 8)          ; Check destination has been updated
                           ; Output 0x4141 4141 0061 4141

   LOAD (destination, copy)

   :copy                   ; Overwrite the copy instruction
   COPY-LITERAL (32, 2, $destination)
   OUTPUT (copy, 2)        ; Output 0x4141


   LOAD (byte_copy_left, 72)       ; Set up new circular buffer
   LOAD (byte_copy_right, 82)
   LOAD (destination, 82)          ; Set destination to byte_copy_right

   MEMSET (72, 10, 65, 1)          ; Fill buffer with 0x41 - 4A

   COPY-OFFSET (2, 6, $destination)    ; Copy from within circular
                                       ; buffer to outside buffer




Surtees & West          Expires January 19, 2006               [Page 15]


Internet-Draft            SigComp Torture Tests                July 2005


   LOAD (offset, 6)
   COPY-OFFSET ($offset, 4, $destination)
                                   ; Copy from byte_copy_right
                                   ; so reading outside buffer
   OUTPUT ($byte_copy_right, 10)   ; Output 0x494A 4142 4344 494A 4142
                                   ; which is 'IJABCDIJAB'

   LOAD (destination, 80)              ; Put destination within the
                                       ; buffer
   COPY-OFFSET (4, 4, $destination)    ; Copy where destination wraps
   OUTPUT (destination, 2)             ; Output 0x004A

   COPY-OFFSET (5, 4, $destination)    ; Copy where offset wraps from
                                       ; left back round to right
   OUTPUT (destination, 2)             ; Output 0x004E
   OUTPUT ($byte_copy_left, 10)        ; Output the circular buffer
                                       ; 0x4748 4845 4647 4748 4546
                                       ; which is 'GHHEFGGHEF'

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)


   The output of the code is above and the cost of execution is 216 UDVM
   cycles.

2.8  MEMSET

   This section gives assembly code to test the MEMSET instruction.  The
   code is designed to test that the following boundary cases have been
   correctly implemented:

   1.  The MEMSET instruction overwrites the registers byte_copy_left
   and byte_copy_right.

   2.  The output values of the MEMSET instruction do not lie between 0
   and 255 inclusive (in which case they must be taken modulo 2^8).















Surtees & West          Expires January 19, 2006               [Page 16]


Internet-Draft            SigComp Torture Tests                July 2005


   at (64)

   :byte_copy_left                 pad (2)
   :byte_copy_right                pad (2)

   at (128)

   LOAD (byte_copy_left, 128)  ; sets up a circular buffer
   LOAD (byte_copy_right, 129) ; of 1 byte between 0x0080 and 0x0081

   MEMSET (64, 129, 0, 1)  ; fills up the memory in the range
                        ; 0x0040-0x007f with 0x00, ... 0x3f;
                        ; then it writes sucessively at
                        ; 0x0080 the following values 0x40, ... 0x80
                        ; as a side effect, the values of
                        ; bcl and bcr are modified.
                        ; before an during the MEMSET:
                        ; byte_copy_left: 0x0080 byte_copy_right: 0x0081
                        ; after the memset:
                        ; byte_copy_left: 0x0001 byte_copy_right: 0x0203

   MEMSET (129, 15, 64, 15)     ; fills the memory range  0x0080-0x008f
                         ; with values 0x40, 0x4f, ... 0xf4, 0x03, 0x12.
                         ; as a side effect, it overwrites a
                         ; part of the code including itself

   OUTPUT (128, 16)      ; outputs 0x8040 4f5e 6d7c 8b9a
                         ; a9b8 c7d6 e5f4 0312

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)


   The output of the code is 0x8040 4f5e 6d7c 8b9a a9b8 c7d6 e5f4 0312.
   Executing the code costs 166 UDVM cycles.

2.9  CRC

   This section gives assembly code to test the CRC instruction.  The
   code does not test any specific boundary cases (as there do not
   appear to be any) but focuses instead on verifying the CRC algorithm.











Surtees & West          Expires January 19, 2006               [Page 17]


Internet-Draft            SigComp Torture Tests                July 2005


   at (64)

   :byte_copy_left                 pad (2)
   :byte_copy_right                pad (2)
   :crc_value                      pad (2)
   :crc_string_a                   pad (24)
   :crc_string_b                   pad (20)

   at (128)

   MEMSET (crc_string_a, 24, 1, 1)  ; sets up between 0x0046 and 0x005d
                                    ; a byte string containing 0x01,
                                    ; 0x02, ... 0x18

   MEMSET (crc_string_b, 20, 128, 1) ; sets up between 0x005e and 0x0071
                                     ; a byte string containing 0x80,
                                     ; 0x81, ... 0x93

   INPUT-BYTES (2, crc_value, !)    ; reads in 2 bytes representing
                                    ; the CRC value of the byte string
                                    ; of 44 bytes starting at 0x0046

   CRC ($crc_value, crc_string_a, 44, !) ; computes the CRC value of the
                                      ; byte string crc_string_a
                                      ; concatenated with byte string
                                      ; crc_string_b (with a total
                                      ; length of 44 bytes).
                                      ; if the computed value does
                                      ; not match the 2 byte value read
                                      ; previously the program ends
                                      ; with DECOMPRESSION-FAILURE
   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)


   If the compressed message is 0x62cb then the code should successfully
   terminate with no output, and with a total execution cost of 95 UDVM
   cycles.  For different 2-byte compressed messages the code should
   terminate with a decompression failure.

2.10  INPUT-BITS

   This section gives assembly code to test the INPUT-BITS instruction.
   The code is designed to test that the following boundary cases have
   been correctly implemented:

   1.  The INPUT-BITS instruction changes between any of the four
   possible bit orderings defined by the input_bit_order register.




Surtees & West          Expires January 19, 2006               [Page 18]


Internet-Draft            SigComp Torture Tests                July 2005


   2.  The INPUT-BITS instruction inputs 0 bits.

   3.  The INPUT-BITS instruction requests data that lies beyond the end
   of the compressed message.


   at (64)

   :byte_copy_left                 pad (2)
   :byte_copy_right                pad (2)
   :input_bit_order                pad (2)
   :result                         pad (2)

   at (128)

   :start

   INPUT-BITS ($input_bit_order, result, end_of_message) ; reads in
                                 ; exactly as many bits as the 2 byte
                                 ; value written in the input_bit_order
                                 ; register. get out of the loop when
                                 ; no more bits are available at input.

   OUTPUT (result, 2) ; outputs as a 2 byte integer
                      ; the previously read bits

   ADD ($input_bit_order, 1)      ; if at the begining of this loop the
                                  ; register input_bit_order is 0,
   REMAINDER ($input_bit_order, 7) ; then its value varies periodically
                                  ; like this: 2, 4, 6, 1, 3, 5, 7.
   ADD ($input_bit_order, 1)      ; that gives for the FHP bits: 010,
                                  ; 100, 110, 001, 011, 101, 111

   JUMP (start)                    ; run the loop once more

   :end_of_message

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)


   An example compressed message is 0x932e ac71, which decompresses to
   give the output 0x0000 0002 0002 0013 0000 0003 001a 0038.  Executing
   the code costs 66 UDVM cycles.

2.11  INPUT-HUFFMAN

   This section gives assembly code to test the INPUT-HUFFMAN
   instruction.  The code is designed to test that the following



Surtees & West          Expires January 19, 2006               [Page 19]


Internet-Draft            SigComp Torture Tests                July 2005


   boundary cases have been correctly implemented:

   1.  The INPUT-HUFFMAN instruction changes between any of the four
   possible bit orderings defined by the input_bit_order register.

   2.  The INPUT-HUFFMAN instruction inputs 0 bits.

   3.  The INPUT-HUFFMAN instruction requests data that lies beyond the
   end of the compressed message.


   at (64)

   :byte_copy_left                 pad (2)
   :byte_copy_right                pad (2)
   :input_bit_order                pad (2)
   :result                         pad (2)

   at (128)

   :start

   INPUT-HUFFMAN (result, end_of_message, 2, $input_bit_order, 0,
   $input_bit_order, $input_bit_order, $input_bit_order, 0, 65535, 0)
   OUTPUT (result, 2)

   ADD ($input_bit_order, 1)
   REMAINDER ($input_bit_order, 7)
   ADD ($input_bit_order, 1)

   JUMP (start)

   :end_of_message

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)


   An example compressed message is 0x932e ac71 66d8 6f, which
   decompresses to give the output 0x0000 0003 0008 04d7 0002 0003 0399
   30fe.  Executing the code costs 84 UDVM cycles.

   As the code is run, the input_bit_order changes through all possible
   values to check usage of the H and P bits.  The number of bits to
   input each time is taken from the value of input_bit_order.  The
   sequence is the following:






Surtees & West          Expires January 19, 2006               [Page 20]


Internet-Draft            SigComp Torture Tests                July 2005


   Input_bit_order (bin)   Total bits input by Huffman             Value
   000                     0                                       0
   010                     2                                       3
   100                     4                                       8
   110                     12                                      1239
   001
   P-bit changed, throw away 6 bits
   001                     1                                       2
   011                     3                                       3
   101                     10                                      921
   111                     14                                      12542
   010
   P-bit changed, throw away 4 bits
   010                     0 - not enough bits so terminate



2.12  INPUT-BYTES

   This section gives assembly code to test the INPUT-BYTES instruction.
   The code is designed to test that the following boundary cases have
   been correctly implemented:

   1.  The INPUT-BYTES instruction inputs 0 bytes.

   2.  The INPUT-BYTES instruction requests data that lies beyond the
   end of the compressed message.

   3.  The INPUT-BYTES instruction is used after part of a byte has been
   input (e.g. by the INPUT-BITS instruction).





















Surtees & West          Expires January 19, 2006               [Page 21]


Internet-Draft            SigComp Torture Tests                July 2005


   at (64)

   :byte_copy_left                 pad (2)
   :byte_copy_right                pad (2)
   :input_bit_order                pad (2)
   :result                         pad (2)
   :output_start                   pad (4)
   :output_end

   at (128)

   LOAD (byte_copy_left, output_start)
   LOAD (byte_copy_right, output_end)

   :start

   INPUT-BITS ($input_bit_order, result, end_of_message)
   OUTPUT (result, 2)

   ADD ($input_bit_order, 2)
   REMAINDER ($input_bit_order, 7)

   INPUT-BYTES ($input_bit_order, output_start, end_of_message)
   OUTPUT (output_start, $input_bit_order)

   ADD ($input_bit_order, 1)
   JUMP (start)

   :end_of_message

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)


   An example compressed message is 0x932e ac71 66d8 6fb1 592b dc9a 9734
   d847 a733 874e 1bcb cd51 b5dc 9659 9d6a, which decompresses to give
   the output 0x0000 932e 0001 b166 d86f b100 1a2b 0003 9a97 34d8 0007
   0001 3387 4e00 08dc 9651 b5dc 9600 599d 6a.  Executing the code costs
   130 UDVM cycles.

   As the code is run, the input_bit_order changes through all possible
   values to check usage of the F and P bits.  The number of bits or
   bytes to input each time is taken from the value of input_bit_order.
   For each INPUT-BYTES instruction the remaining bits of the byte are
   thrown away.  The P-bit always changes on the byte boundary so no
   bits are thrown away.  The sequence is the following:






Surtees & West          Expires January 19, 2006               [Page 22]


Internet-Draft            SigComp Torture Tests                July 2005


   Input_bit_order (bin)   Input bits  Input bytes   Output
   000                     0                         0x0000
   010                                 2             0x932e
   011                     3                         0x0001
   101                                 5             0xb166 d866 b1
   110                     6                         0x001a
   001                                 1             0x2b
   010                     2                         0x0003
   100                                 4             0x9a97 34d8
   101                     5                         0x0007
   000                                 0
   001                     1                         0x0001
   011                                 3             0x3384 4e
   100                     4                         0x0008
   110                                 6             0xdc96 51b5 dc96
   111                     7                         0x0059
   010                                 2             0x9d6a
   011                     3 - no bits left so terminate



2.13  Stack manipulation

   This section gives assembly code to test the PUSH, POP, CALL and
   RETURN instructions.  The code is designed to test that the following
   boundary cases have been correctly implemented:

   1.  The stack manipulation instructions overwrite the UDVM register
   stack_location.

   2.  The CALL instruction specifies a reference operand rather than an
   absolute value.

   3.  The PUSH instruction pushes the value contained in stack_fill
   onto the stack.

   4.  The stack_location register contains an odd integer.


   at (64)

   :byte_copy_left                 pad (2)
   :byte_copy_right                pad (2)
   :input_bit_order                pad (2)
   :stack_location                 pad (2)
   :next_address                   pad (2)

   at (128)



Surtees & West          Expires January 19, 2006               [Page 23]


Internet-Draft            SigComp Torture Tests                July 2005


   LOAD (stack_location, 64)
   PUSH (2)
   PUSH ($64)
   PUSH (66)               ; Stack now contains 2, 1, 66
                           ; so $stack_location = 66

   OUTPUT (64, 8)          ; Output 0x0003 0002 0001 0042

   POP (64)                ; Pop value 66 from address 70 to address 64
   POP ($stack_location)   ; Pop value 1 from address 68 to address 66
                           ; so stack_fill is overwritten to be 1
   POP (stack_location)    ; Pop value 1 from address 68 to address 70

   OUTPUT (64, 8)          ; Output 0x0042 0000 0001 0001
   JUMP (address_a)

   at (192)

   :address_a

   LOAD (stack_location, 32)
   LOAD (next_address, address_c)
   SUBTRACT ($next_address, address_b)  ; next_address = 64
   CALL (address_b)                     ; push 204 on stack

   at (256)

   :address_b

   CALL ($next_address)                 ; push 256 on stack

   at (320)

   :address_c

   LOAD (stack_location, 383)
   LOAD (383, 26)                   ; overwrite $stack_location with 26
   MULTILOAD (432, 3, 1, 49153, 32768)

                                    ; write bytes so that 433 and 434
                                    ; contain 0x01c0 = 448 and
                                    ; 435 and 436 contain 0x0180 = 384

   RETURN                           ; pop 383 from the stack and jump
                                    ; there = 384 which is lsb of
                                    ; stack_fill which now contains 25
                                    ; which is UDVM instruction RETURN
                                    ; pop 448 from the stack and jump



Surtees & West          Expires January 19, 2006               [Page 24]


Internet-Draft            SigComp Torture Tests                July 2005


                                    ; there
   at (448)

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)


   The output of the code is 0x0003 0002 0001 0042 0042 0000 0001 0001,
   and a total of 40 UDVM cycles are used.

2.14  Program flow

   This section gives assembly code to test the JUMP, COMPARE and SWITCH
   instructions.  The code is designed to test that the following
   boundary cases have been correctly implemented:

   1.  The address operands are specified as references to memory
   addresses rather than as absolute values.


   at (64)

   :next_address                   pad (2)
   :counter                        pad (1)
   :counter_lsb                    pad (1)
   :switch_counter                 pad (2)

   at (128)

   LOAD (switch_counter, 4)

   :address_a

   LOAD (next_address, address_c)
   SUBTRACT ($next_address, address_b)     ; address_c - address_b
   OUTPUT (counter_lsb, 1)

   :address_b

   JUMP ($next_address)                    ; Jump to address_c

   :address_c

   ADD ($counter, 1)
   LOAD (next_address, address_a)
   SUBTRACT ($next_address, address_d)     ; address_a - address_d
   OUTPUT (counter_lsb, 1)

   :address_d



Surtees & West          Expires January 19, 2006               [Page 25]


Internet-Draft            SigComp Torture Tests                July 2005


   COMPARE ($counter, 6, $next_address, address_c, address_e)
                                   ; counter < 6, $next_address gives
                                   ; jump to address_a

   :address_e

   SUBTRACT ($switch_counter, 1)           ; switch_counter = 3
   LOAD (next_address, address_a)
   SUBTRACT ($next_address, address_f)     ; address_a - address_f
   OUTPUT (counter_lsb, 1)

   :address_f

   SWITCH (4, $switch_counter, address_g, $next_address, address_c,
   address_e)
                                   ; when $switch_counter = 1,
                                   ; $next_address gives jump to
                                   ; address_a

   :address_g

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)


   The output of the code is 0x0001 0102 0203 0304 0405 0506 0707 0708
   0808 0909, and a total of 131 UDVM cycles are used.

2.15  State creation

   This section gives assembly code to test the STATE-CREATE and STATE-
   FREE instructions.  The code is designed to test that the following
   boundary cases have been correctly implemented:

   1.  An item of state is created that duplicates an existing state
   item.

   2.  An item of state is freed when the state has not been created.

   3.  An item of state is created and then freed by the same message.

   4.  The STATE-FREE instruction frees a state item by sending fewer
   bytes of state_identifier than the minimum_access_length.

   5.  The STATE-FREE instruction has partial_identifer_length operand
   shorter than 6 or longer than 20.

   6.  The STATE-FREE instruction specifies a partial_identifier that
   matches with two state items in the compartment.



Surtees & West          Expires January 19, 2006               [Page 26]


Internet-Draft            SigComp Torture Tests                July 2005


   7.  Write the bytes of the identifier to the position specified in
   the STATE-FREE instruction after the STATE-FREE instruction has been
   run (and before END-MESSAGE).


   at (64)

   :byte_copy_left                 pad (2)
   :byte_copy_right                pad (2)
   :states                         pad (1)
   :states_lsb                     pad (1)
   :min_len                        pad (1)
   :min_len_lsb                    pad (1)

   :state_identifier       pad (20)

   set (state_length, 10)

   at (128)

   INPUT-BYTES (1, states_lsb, !)

   :test_one
   LSHIFT ($states, 11)
   COMPARE ($states, 32768, test_two, create_state_a2, create_state_a2)

   :create_state_a2
   STATE-CREATE (state_length, state_address2, 0, 20, 0)

   :test_two
   LSHIFT ($states, 1)
   COMPARE ($states, 32768, test_three, create_state_a, create_state_a)

   :create_state_a
   STATE-CREATE (state_length, state_address, 0, 20, 0)

   :test_three
   LSHIFT ($states, 1)
   COMPARE ($states, 32768, test_four, free_state, free_state)

   :free_state
   INPUT-BYTES (1, min_len_lsb, !)
   STATE-FREE (state_identifier, $min_len)
   COPY (identifier1, $min_len, state_identifier)

   :test_four
   LSHIFT ($states, 1)
   COMPARE ($states, 32768, test_five, free_state2, free_state2)



Surtees & West          Expires January 19, 2006               [Page 27]


Internet-Draft            SigComp Torture Tests                July 2005


   :free_state2
   STATE-FREE (identifier1, 6)

   :test_five
   LSHIFT ($states, 1)
   COMPARE ($states, 32768, end, create_state_b, create_state_b)

   :create_state_b
   END-MESSAGE (0, 0, state_length, state_address, 0, 20, 0)

   :end
   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)

   :identifier1
   byte (67, 122, 232, 10, 15, 220, 30, 106, 135, 193, 182, 42, 118,
   118, 185, 115, 49, 140, 14, 245)

   at (256)
   :state_address
   byte (192, 204, 63, 238, 121, 188, 252, 143, 209, 8)

   :state_address2
   byte (101, 232, 3, 82, 238, 41, 119, 23, 223, 87)


   Upon reaching the END-MESSAGE instruction the UDVM does not output
   any decompressed data, but instead may make one or more state
   creation or state free requests to the state handler.  Assuming that
   the application does not veto the state creation request (and that
   sufficient state memory is available) the code results in 0, 1 or 2
   state items being present in the compartment.

   The following table lists ten different compressed messages, the
   states created and freed by each, the number of states left after
   each message and the number of UDVM cycles used.  There are 3 state
   creation instructions:

      create state_a which has hash identifier1
      create state_b (in END-MESSAGE) which is identical to state_a
      create state_a2 which has a different identifier, but the first 6
      bytes are the same as those of identifier1.










Surtees & West          Expires January 19, 2006               [Page 28]


Internet-Draft            SigComp Torture Tests                July 2005


   Message:   Effect:                           # state items:  #cycles:
   0x01       create state_b                             1           23
   0x02       free (id1, 6) = state_b                    0           14
   0x03       free (id1, 6) = state_b; create state_b    1           24

   0x0405     free (id1, 0)                       Decompression failure
   0x0415     free (id1, 21)                      Decompression failure

   0x0406     free (id1, 6) = state_b                    0           23

   0x09       create state_a; create state_b             1           34

   0x1e06     create state_a2; create state_a;
              free (id1, 6) = matches both so no free;
              free (id1, 6) = matches both so no free;   2           46

   0x1e07     create state_a2; create state_a;
              free (id1, 7) = state_a;
              free (id1, 6) = state_a2                   0           47

   0x1e14     create state_a2; create state_a;
              free (id1, 20) = state_a;
              free (id1, 6) = state_a2                   0           60



2.16  STATE-ACCESS

   This section gives assembly code to test the STATE-ACCESS
   instruction.  The code is designed to test that the following
   boundary cases have been correctly implemented:

   1.  A subset of the bytes contained in a state item is copied to the
   UDVM memory.

   2.  Bytes are copied from beyond the end of the state value.

   3.  The state_instruction operand is set to 0.

   4.  The state cannot be accessed because the partial state identifier
   is too short.

   5.  The state identifier is overwritten by the state item being
   accessed.

   The following bytecode needs to be run first to set up the state for
   the rest of the test.




Surtees & West          Expires January 19, 2006               [Page 29]


Internet-Draft            SigComp Torture Tests                July 2005


   at (12)

   END-MESSAGE (0, 0, state_length, state_start, 0, 20, 0)

   ;at (512)
   ;OUTPUT (data, 4)
   ;END-MESSAGE (0,0,0,0,0,0,0)
   ;:data
   ;byte (116, 101, 115, 116)

   :state_start
   byte (34, 162, 12,4, 35, 0, 0, 0, 0, 0, 0, 0, 116, 101, 115, 116)
   :state_end

   set (state_length, (state_end - state_start))


   This is the bytecode for the rest of the test.


   at (64)

   :byte_copy_left                 pad (2)
   :byte_copy_right                pad (2)
   :type                           pad (1)
   :type_lsb                       pad (1)
   :state_value                    pad (4)

   at (128)

   INPUT-BYTES (1, type_lsb, !)
   COMPARE ($type, 1, execute_state, extract_state, error_conditions)

   :execute_state

   STATE-ACCESS (state_identifier, 20, 0, 0, 0, 512)

   :extract_state

   STATE-ACCESS (state_identifier, 20, 12, 4, state_value, 0)
   OUTPUT (state_value, 4)
   JUMP (end)

   :error_conditions

   COMPARE ($type, 3, state_not_found, id_too_short, state_too_short)

   :state_not_found



Surtees & West          Expires January 19, 2006               [Page 30]


Internet-Draft            SigComp Torture Tests                July 2005


   STATE-ACCESS (128, 20, 0, 0, 0, 0)
   JUMP (end)

   :id_too_short

   STATE-ACCESS (state_identifier, 19, 6, 4, state_value, 0)
   JUMP (end)

   :state_too_short

   STATE-ACCESS (state_identifier, 20, 12, 5, state_value, 0)
   JUMP (end)

   at (484)

   :end

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)

   at (512)

   :state_identifier

   byte (0x5d, 0xf8, 0xbc, 0x3e, 0x20, 0x93, 0xb5, 0xab, 0xe1, 0xf1,
   0x70, 0x13, 0x42, 0x4c, 0xe7, 0xfe, 0x05, 0xe0, 0x69, 0x39)


   If the compressed message is 0x00 then the output of the code is
   0x7465 7374 and a total of 21 UDVM cycles are be used.  If the
   compressed message is 0x01 then the output of the code is also 0x7465
   7374 but in this case using a total of 15 UDVM cycles.  If the
   compressed message is 0x02, 0x03 or 0x04 then decompression failure
   occurs.

3.  Torture tests for dispatcher

   The following sections give code to test the various functions of the
   SigComp dispatcher.

3.1  Useful Values

   This section gives assembly code to test that the SigComp "Useful
   Values" are correctly initialized in the UDVM memory.  It also tests
   that the UDVM is correctly terminated if the bytecode uses too many
   UDVM cycles or tries to write beyond the end of the available memory.

   The code tests that the following boundary cases have been correctly
   implemented:



Surtees & West          Expires January 19, 2006               [Page 31]


Internet-Draft            SigComp Torture Tests                July 2005


   1.  The bytecode uses exactly as many UDVM cycles as are available
   (in which case no problems should arise) or one cycle too many (in
   which case decompression failure should occur).  A liberal
   implementation could allow more cycles to be used than are strictly
   available, in which case decompression failure will not occur.  This
   is an implementation choice.  If this choice is made, the implementer
   must be sure that the cycles are checked eventually and that
   decompression failure does occur when bytecode uses an excessive
   number of cycles.  This is tested in Section 3.2.

   2.  The bytecode writes to the highest memory address available (in
   which case no problems should arise) or to the memory address
   immediately following the highest available address (in which case
   decompression failure must occur).


   :udvm_memory_size               pad (2)
   :cycles_per_bit                 pad (2)
   :sigcomp_version                pad (2)
   :partial_state_id_length        pad (2)
   :state_length                   pad (2)

   at (64)

   :byte_copy_left                 pad (2)
   :byte_copy_right                pad (2)
   :remaining_cycles               pad (2)
   :check_memory                   pad (1)
   :check_memory_lsb               pad (1)
   :check_cycles                   pad (1)
   :check_cycles_lsb               pad (1)

   at (128)
                               ; Set up a 1 byte buffer
   LOAD (byte_copy_left, 32)
   LOAD (byte_copy_right, 33)

   :test_version

   COMPARE ($sigcomp_version, 1, !, test_state_access, !)

   :test_state_access

   COMPARE ($partial_state_id_length, 0, !, test_length_equals_zero,
   test_state_length)

   :test_length_equals_zero
                               ; No state was accessed so state_length



Surtees & West          Expires January 19, 2006               [Page 32]


Internet-Draft            SigComp Torture Tests                July 2005


                               ; should be zero (first message)
   COMPARE ($state_length, 0, !, end, !)

   :test_state_length
                               ; State was accessed so state_length
                               ; should be 960
   COMPARE ($state_length, 960, !, test_udvm_memory, !)

   :test_udvm_memory
                               ; Copy one byte to
                               ; udvm_memory_size + input - 1
                               ; Succeed when input byte is 0x00
                               ; Fail when input byte is 0x01

   INPUT-BYTES (1, check_memory_lsb, !)
   ADD ($check_memory, $udvm_memory_size)
   SUBTRACT ($check_memory, 1)
   COPY (32, 1, $check_memory)

   :test_udvm_cycles

   INPUT-BYTES (1, check_cycles_lsb, !)

   ; Work out the total number of cycles available to the UDVM
   ; total_UDVM_cycles = cycles_per_bit * (8 * message_size + 1000)
   ;
   ;       = cycles_per_bit * (8 * (partial_state_id_length + 3) + 1000)

   LOAD (remaining_cycles, $partial_state_id_length)
   ADD ($remaining_cycles, 3)
   MULTIPLY ($remaining_cycles, 8)
   ADD ($remaining_cycles, 1000)
   MULTIPLY ($remaining_cycles, $cycles_per_bit)

   ADD ($remaining_cycles, $check_cycles)

   set (cycles_used_by_bytecode, 982)

   SUBTRACT ($remaining_cycles, cycles_used_by_bytecode)
   COPY (32, $remaining_cycles, 32)
                   ; Copy to use up all cycles available + input byte
                   ; Succeeds when input byte = 0x00
                   ; Fail when input byte = 0x01

   :end
                               ; Create 960 bytes of state for future
                               ; reference
   END-MESSAGE (0, 0, 960, 64, 128, 6, 0)



Surtees & West          Expires January 19, 2006               [Page 33]


Internet-Draft            SigComp Torture Tests                July 2005


   The bytecode must be executed a total of four times in order to fully
   test the SigComp Useful Values.  In the first case the bytecode is
   uploaded as part of the SigComp message (no compressed data is
   required in this case).  This causes the UDVM to request creation of
   a new state item, and uses a total of 966 UDVM cycles.

   Subsequent tests access this state by uploading the state identifier
   as part of the SigComp message.  Note that the SigComp message should
   not contain a returned feedback item (as this would cause the
   bytecode to calculate the total number of available UDVM cycles
   incorrectly).

   A 2-byte compressed message is required for the second and subsequent
   cases: if the message is 0x0000 then the UDVM should successfully
   terminate using exactly the number of available UDVM cycles.
   However, if the message is 0x0001 then the UDVM should use too many
   cycles and hence terminate with decompression failure.  Furthermore
   if the message is 0x0100 then decompression failure must occur
   because the UDVM attempts to write beyond its available memory.

3.2  Cycles checking

   As discussed in Section 3.1, it is possible to write an
   implementation which takes a liberal approach to checking the cycles
   used and allow some extra cycles.  The implementer must be sure that
   decompression failure does not occur too early and that in the case
   of excessive use of cycles, decompression failure does eventually
   occur.  This test checks that:

   1.  Decompression failure occurs eventually when there is an infinite
   loop.




















Surtees & West          Expires January 19, 2006               [Page 34]


Internet-Draft            SigComp Torture Tests                July 2005


   at (64)
   :byte_copy_left           pad (2)
   :byte_copy_right          pad (2)
   :value                    pad (2)
   :copy_next                pad (2)

   at(128)
   MULTILOAD (byte_copy_left, 4, 32, 41, 0, 34)
                                   ; Set up a 10 byte buffer

                                   ; Set the value to copy
                                   ; Copy it 100 times,
                                   ; output the value,
                                   ; increment the counter
   :loop
   COPY (value, 2, $byte_copy_left)
   COPY-OFFSET (2, 100, $copy_next)
   OUTPUT (value, 2)
   ADD ($value, 1)
   JUMP (loop)


   If the cycles are counted exactly and cpb = 16 then decompression
   failure will occur at COPY-OFFSET when value = 180 = 0xB4.  If they
   are not counted exactly, then decompression failure MUST occur
   eventually.

3.3  Message-based transport

   This section provides a set of messages to test the SigComp header
   over a message-based transport such as UDP.  The messages test that
   the following boundary cases have been correctly implemented:

   1.  The UDVM bytecode is copied to different areas of the UDVM
   memory.

   2.  The decompression memory size is set to an incorrect value.

   3.  The SigComp message is too short.

   4.  The destination address is invalid.

   The basic version of the code used in the test is given below.  Note
   that the code is designed to calculate the decompression memory size
   based on the Useful Values provided to the UDVM:






Surtees & West          Expires January 19, 2006               [Page 35]


Internet-Draft            SigComp Torture Tests                July 2005


   :udvm_memory_size               pad (2)

   :cycles_per_bit                 pad (2)
   :sigcomp_version                pad (2)
   :partial_state_id_length        pad (2)
   :state_length                   pad (2)

   at (128)

   :code_start

   ; udvm_memory_size for message based transport
   ;    = DMS - total_message_size

   ADD ($udvm_memory_size, total_message_size)
   OUTPUT (udvm_memory_size, 2)
   END-MESSAGE (0, 0, 0, 0, 0, 0, 1)

   :code_end

   set (header_size, 3)
   set (code_size, (code_end - code_start))
   set (total_message_size, (header_size + code_size))


   A number of complete SigComp messages are given below, each
   containing some or all of the above code.  In each case it is
   indicated whether the message will successfully output the
   decompression memory size or whether it will cause a decompression
   failure to occur (together with the reason for the failure):



   SigComp message:                Effect:

   0xf8                            Fails (message too short)

   0xf800                          Fails (message too short)

   0xf800 e106 0011 2200 0223      Outputs the decompression_memory_size
   0x0000 0000 0000 01

   0xf800 f106 0011 2200 0223      Fails (message too short)
   0x0000 0000 0000 01

   0xf800 e006 0011 2200 0223      Fails (invalid destination address)
   0x0000 0000 0000 01




Surtees & West          Expires January 19, 2006               [Page 36]


Internet-Draft            SigComp Torture Tests                July 2005


   0xf800 ee06 0011 2200 0223      Outputs the decompression_memory_size
   0x0000 0000 0000 01


   The messages should be decompressed in the order given to check that
   an error in one message does not interfere with the successful
   decompression of subsequent messages.

   The two messages that successfully decompress each use a total of 5
   UDVM cycles.

3.4  Stream-based transport

   This section provides a byte stream to test the SigComp header and
   delimiters over a stream-based transport such as TCP.  The byte
   stream tests all of the boundary cases covered in Section 3.2, as
   well as the following cases specific to stream-based transports:

   1.  Quoted bytes are used by the record marking scheme.

   2.  Multiple delimiters are used between the same pair of messages.

   3.  Unnecessary delimiters are included at the start of the stream.

   The basic version of the code used in the test is given below.  Note
   that the code is designed to calculate the decompression memory size
   based on the Useful Values provided to the UDVM:


   :udvm_memory_size               pad (2)
   :cycles_per_bit                 pad (2)
   :sigcomp_version                pad (2)
   :partial_state_id_length        pad (2)
   :state_length                   pad (2)

   at (128)

   ; udvm_memory_size for stream based transport = DMS / 2

   MULTIPLY ($udvm_memory_size, 2)
   OUTPUT (udvm_memory_size, 2)
   OUTPUT (test_record_marking, 5)
   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)

   :test_record_marking

   byte (255, 255, 255, 255, 255)




Surtees & West          Expires January 19, 2006               [Page 37]


Internet-Draft            SigComp Torture Tests                July 2005


   The above assembly code has been compiled and used to generate the
   following byte stream:

   0xffff f801 7108 0002 2200 0222 a092 0523 0000 0000 0000 00ff 00ff
   0x03ff ffff ffff ffff f801 7e08 0002 2200 0222 a3d2 0523 0000 0000
   0x0000 00ff 04ff ffff ffff ffff ffff ff

   Note that this byte stream can be divided into five distinct portions
   (two SigComp messages and three sets of delimiters) as illustrated
   below:



   Portion of byte stream:                                Meaning:

   0xffff                                                 Delimiter

   0xf801 7108 0002 2200 0222 a092 0523                   First message
   0x0000 0000 0000 00ff 00ff 03ff ffff

   0xffff ffff                                            Delimiter

   0xf801 7e08 0002 2200 0222 a3d2 0523                   Second message
   0x0000 0000 0000 00ff 04ff ffff ff

   0xffff ffff ffff                                       Delimiter


   When the complete byte stream is supplied to the decompressor
   dispatcher, the record marking scheme must use the delimiters to
   partition the stream into two distinct SigComp messages.  Both of
   these messages successfully output the decompression memory size (as
   a 2-byte value), followed by five consecutive 0xff bytes to test that
   the record marking scheme is working correctly.  A total of 11 UDVM
   cycles are used in each case.

   It must also be checked that the dispatcher can handle the same error
   cases as covered in Section 3.2.  Each of the following byte streams
   should cause a decompression failure to occur for the reason stated:












Surtees & West          Expires January 19, 2006               [Page 38]


Internet-Draft            SigComp Torture Tests                July 2005


   Byte stream:                                      Reason for failure:

   0xf8ff ff                                         Message too short

   0xf800 ffff                                       Message too short

   0xf801 8108 0002 2200 0222 a092 0523 ffff         Message too short
   0x0000 0000 0000 00ff 00ff 03ff ffff

   0xf801 7008 0002 2200 0222 a092 0523 ffff         Invalid destination
   0x0000 0000 0000 00ff 04ff ffff ff


   Note that when a decompression failure occurs it is an implementation
   decision whether to close the entire stream or whether to ignore the
   error and attempt to decompress subsequent messages in the stream.

3.5  Input past the end of a message

   This section gives assembly code to test that the implementation
   correctly handles input past the end of a SigComp message.  The code
   is designed to test that the following boundary cases have been
   correctly implemented:

   1.  An INPUT instruction requests data that lies beyond the end of
   the message.  In this case the dispatcher should not return any data
   to the UDVM.  Moreover, the message bytes held by the dispatcher
   should still be available for retrieval by subsequent INPUT
   instructions.

   2.  The INPUT-BYTES instruction is used after part of a byte has been
   input (e.g. by the INPUT-BITS instruction).  In this case the
   remaining partial byte must be discarded, even if the INPUT-BYTES
   instruction requests data that lies beyond the end of the message.


   at (64)

   :byte_copy_left                 pad (2)
   :byte_copy_right                pad (2)
   :input_bit_order                pad (2)
   :result                         pad (1)
   :result_lsb                     pad (6)
   :right

   at (128)

   LOAD (byte_copy_left, result)



Surtees & West          Expires January 19, 2006               [Page 39]


Internet-Draft            SigComp Torture Tests                July 2005


   LOAD (byte_copy_right, right)

   :start

   ; Input bits to ensure that the remaining message is not byte aligned

   INPUT-BITS (9, result, !)           ; Input 0x1FF (9 bits)

   ; Attempt to read 7 bytes

   INPUT-BYTES (7, result, next_bytes) ; This should fail, throw away
                                       ; 7 bits with value Ox7a and
                                       ; jump to next_bytes

   DECOMPRESSION-FAILURE               ; This instruction is never
                                       ; executed but is used to
                                       ; separate success and failure
                                       ; to input bytes.

   :next_bytes

   ; Read 7 bits - this removes the byte alignment of the message

   ; If the bits have not been thrown away where they should then the
   ; message will be 1 byte longer than necessary and the output will
   ; be incorrect.

   INPUT-BITS (7, result, !)           ; Input 0x00 (7 bits)

   ; Read 2 bytes

   INPUT-BYTES (2, result, !)          ; Throw away 1 bit value 0
                                       ; Input 0x6869
   OUTPUT (result, 2)                  ; Output 0x6869

                                       ; Attempt to read more bits than
   INPUT-BITS (16, result, bits)       ; there are to ensure they
                                       ; remain available

   DECOMPRESSION-FAILURE               ; This instruction is never
                                       ; executed but is used to
                                       ; separate success and failure
                                       ; to input bits.

   :bits

   ; Read 8 bits




Surtees & West          Expires January 19, 2006               [Page 40]


Internet-Draft            SigComp Torture Tests                July 2005


   INPUT-BITS (8, result, !)           ; Input 0x21 or fail
   OUTPUT (result_lsb, 1)              ; Output 0x21

   :end_message

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)


   If the compressed message is 0xfffa 0068 6921 then the code
   terminates successfully with the output 0x6869 21, and a total of 23
   UDVM cycles are used.  However, if the compressed message is 0xfffa
   0068 69 then decompression failure occurs (at the final INPUT-BITS).

4.  Torture tests for state handler

   The following sections give code to test the various functions of the
   SigComp state handler.

4.1  SigComp feedback mechanism

   This section gives assembly code to test the SigComp feedback
   mechanism.  The code is designed to test that the following boundary
   cases have been correctly implemented:

   1.  Both the short and the long versions of the SigComp feedback item
   are used.

   2.  The chain of returned SigComp parameters is terminated by a non-
   zero value.


   at (64)

   :type                           pad (1)
   :type_lsb                       pad (1)

   :requested_feedback_location    pad (1)
   :requested_feedback_length      pad (1)
   :requested_feedback_bytes       pad (127)

   :returned_parameters_location   pad (2)
   :length_of_partial_state_id_a   pad (1)
   :partial_state_identifier_a     pad (6)
   :length_of_partial_state_id_b   pad (1)
   :partial_state_identifier_b     pad (12)
   :length_of_partial_state_id_c   pad (1)
   :partial_state_identifier_c     pad (20)
   :terminate_returned_parameters  pad (1)



Surtees & West          Expires January 19, 2006               [Page 41]


Internet-Draft            SigComp Torture Tests                July 2005


   align (128)

   set (q_bit, 1)
   set (s_bit, 0)
   set (i_bit, 0)
   set (flags, (((4 * q_bit) + (2 * s_bit)) + i_bit))

   INPUT-BYTES (1, type_lsb, !)
   COMPARE ($type, 1, short_feedback_item, long_feedback_item, !)

   :short_feedback_item

   set (requested_feedback_data, 127)
   set (short_feedback_value, ((flags * 256) + requested_feedback_data))

   LOAD (requested_feedback_location, short_feedback_value)
   JUMP (return_sigcomp_parameters)

   :long_feedback_item

   set (requested_feedback_field, 255)
   set (long_feedback_value, ((flags * 256) + requested_feedback_field))

   LOAD (requested_feedback_location, long_feedback_value)
   MEMSET (requested_feedback_bytes, 127, 1, 1)

   :return_sigcomp_parameters

   set (cpb, 0)
   set (dms, 1)
   set (sms, 0)
   set (sigcomp_version, 1)

   set (parameters_msb, (((64 * cpb) + (8 * dms)) + sms))
   set (sigcomp_parameters, ((256 * parameters_msb) + sigcomp_version))

   LOAD (returned_parameters_location, sigcomp_parameters)

   LOAD (length_of_partial_state_id_a, 1536)   ; length 6 first byte 0
   LOAD (length_of_partial_state_id_b, 3072)   ; length 12 first byte 0
   LOAD (length_of_partial_state_id_c, 5120)   ; length 20 first byte 0
   LOAD (terminate_returned_parameters, 5376)  ; length 21
                                               ; used to terminate

   MEMSET (partial_state_identifier_a, 6, 0, 1)
   MEMSET (partial_state_identifier_b, 12, 0, 1)
   MEMSET (partial_state_identifier_c, 20, 0, 1)




Surtees & West          Expires January 19, 2006               [Page 42]


Internet-Draft            SigComp Torture Tests                July 2005


   END-MESSAGE (requested_feedback_location,
   returned_parameters_location, 0, 0, 0, 0, 0)


   When the above code is executed it supplies a requested feedback item
   to the state handler.  If the compressed message is 0x00 then the
   short (1-byte) version of the feedback is used.  Executing the
   bytecode in this case costs a total of 52 UDVM cycles.  Assuming that
   the feedback request is successful the feedback item should be
   returned in the first SigComp message to be sent in the reverse
   direction.  The SigComp message returning the feedback should begin
   as follows:


   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1   1 |   X   |   first header byte
   +---+---+---+---+---+---+---+---+
   | 0 |            127            |   returned feedback field
   +---+---+---+---+---+---+---+---+

   So the first 2 bytes of the returning SigComp message should be
   0xfn7f where n = c, d, e or f (the choice of n is determined by the
   compressor generating the returning SigComp message, which is not
   under the control of the above code).

   If the compressed message is 0x01 then the long version of the
   feedback item is used.  Executing the bytecode in this case costs a
   total of 179 UDVM cycles and the SigComp message returning the
   feedback should begin as follows:


   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1   1 |   X   |   first header byte
   +---+---+---+---+---+---+---+---+
   | 1 |            127            |   returned feedback length
   +---+---+---+---+---+---+---+---+
   |               1               |              ^
   +---+---+---+---+---+---+---+---+              |
   |               2               |              |
   +---+---+---+---+---+---+---+---+
   |               3               |   returned feedback field
   +---+---+---+---+---+---+---+---+

   So the first 129 bytes of the SigComp message should be 0xfnff 0102
   0304 ... 7e7f where n = c, d, e or f.

   As well as testing the requested and returned feedback items, the
   above code also announces values for each of the SigComp parameters.



Surtees & West          Expires January 19, 2006               [Page 43]


Internet-Draft            SigComp Torture Tests                July 2005


   The supplied version of the code announces only the minimum possible
   values for the cycles_per_bit, decompression_memory_size,
   state_memory_size and SigComp_version (although this can easily be
   adjusted to test different values for these parameters).

   The code should also announce the availability of state items with
   the following partial state identifiers:

   0x0001 0203 0405 0x0001 0203 0405 0607 0809 0a0b 0x0001 0203 0405
   0607 0809 0a0b 0c0d 0e0f 1011 1213

   Note that different implementations may make use of the announcement
   information in different ways.  It is a valid implementation choice
   to simply ignore all of the announcement data and use only the
   minimum resources that are guaranteed to be available to all
   endpoints.  However the above code is useful for checking that an
   endpoint interprets the announcement data correctly (in particular
   ensuring that it does not mistakenly use resources that have not in
   fact been announced).

4.2  State memory management

   The following section gives assembly code to test the memory
   management features of the state handler.  The code checks that the
   correct states are retained by the state handler when insufficient
   memory is available to store all of the requested states.

   The code is designed to test that the following boundary cases have
   been correctly implemented:

   1.  A state item is created that exceeds the total state_memory_size
   for the compartment.

   2.  States are created with a non-zero state_retention_priority.

   3.  A new state item is created that has a lower
   state_retention_priority than existing state items in the
   compartment.

   For the duration of this test it is assumed that all states will be
   saved in a single compartment with a state_memory_size of 2048 bytes.


   at (64)

   :byte_copy_left                 pad (2)
   :byte_copy_right                pad (2)
   :order                          pad (2)



Surtees & West          Expires January 19, 2006               [Page 44]


Internet-Draft            SigComp Torture Tests                July 2005


   :type                           pad (1)
   :type_lsb                       pad (1)
   :state_length                   pad (2)
   :state_retention_priority       pad (2)

   at (128)

   MULTILOAD (byte_copy_left, 2, state_start, order_data)

   INPUT-BYTES (1, type_lsb, !)
   COMPARE ($type, 5, general_test, large_state, verify_state)

   :general_test

   COMPARE ($type, 3, start, state_present, state_not_present)

   :start

   MULTIPLY ($type, 6)
   ADD ($type, order_data)
   LOAD (order, $type)
   ADD ($type, 6)

   ; Finish with the value (order_data + 6*n) in order where
   ; n is the input value 0x00, 0x01 or 0x02
   ; type = order + 6
   ; These values are used to index into the 'order_data'
   ; that is used to work out state retention priorities and lengths

   :loop

   COPY ($order, 2, state_retention_priority)
   COMPARE ($order, $type, continue, end, !)

   :continue

   ;  Set up a state creation each time through the loop

   LOAD (state_length, $state_retention_priority)
   MULTIPLY ($state_length, 256)
   STATE-CREATE ($state_length, state_start, 0, 6,
   $state_retention_priority)

   ADD ($order, 2)
   JUMP (loop)

   :state_present




Surtees & West          Expires January 19, 2006               [Page 45]


Internet-Draft            SigComp Torture Tests                July 2005


   ; Access the states that should be present
   STATE-ACCESS (state_identifier_a, 6, 0, 0, 0, 0)
   STATE-ACCESS (state_identifier_b, 6, 0, 0, 0, 0)
   STATE-ACCESS (state_identifier_c, 6, 0, 0, 0, 0)
   STATE-ACCESS (state_identifier_e, 6, 0, 0, 0, 0)
   JUMP (end)

   :state_not_present

   ; Check that the state that shouldn't be present is not present.
   STATE-ACCESS (state_identifier_d, 6, 0, 0, 0, 0)
   JUMP (end)

   :large_state

   STATE-CREATE (2048, state_start, 0, 6, 0)
   JUMP (end)

   :verify_state

   STATE-ACCESS (large_state_identifier, 6, 0, 0, 0, 0)
   JUMP (end)

   :end

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)

   at (512)

   :state_start

   byte (116, 101, 115, 116)

   :order_data
   ; This data is used to generate the retention priority
   ; and state length of each state creation.

   word (0, 1, 2, 3, 4, 3, 2, 1, 0)

   :state_identifier_a

   byte (142, 234, 75, 67, 167, 135)

   :state_identifier_b

   byte (249, 1, 14, 239, 86, 123)

   :state_identifier_c



Surtees & West          Expires January 19, 2006               [Page 46]


Internet-Draft            SigComp Torture Tests                July 2005


   byte (35, 154, 52, 107, 21, 166)

   :state_identifier_d

   byte (180, 15, 192, 228, 77, 44)

   :state_identifier_e

   byte (212, 162, 33, 71, 230, 10)

   :large_state_identifier

   byte (239, 242, 188, 15, 182, 175)


   The above code must be executed a total of 7 times in order to
   complete the test.  Each time the code is executed a 1-byte
   compressed message should be provided as below.  The effects of the
   messages are given below.  States are described in the form (name, x,
   y) where name corresponds to the name of the identifier in the
   mnemonic code, x is the length of the state and y is the retention
   priority of the state.


   Message:   Effect:                                           #cycles:
   0x00       create states:                                       811
                   (a,0,0),
                   (b,256,1),
                   (c,512,2)
   0x01       create states:                                      2603
                   (d,768,3),
                   (e,1024,4) - deleting a, b, c
   0x02       create states:                                       811
                   (c,512,2), - deleting d
                   (b,256,1),
                   (a,0,0)
   0x03       access states a,b,c,e                               1805
   0x04       access state d - not present so decompression failure
   0x05       create states:                                      2057
                   (large, 2048,0) - deleting a, b, c, e
   0x06       access large state                                  1993


   Note that as new states are created some of the existing states will
   be pushed out of the compartment due to lack of memory.






Surtees & West          Expires January 19, 2006               [Page 47]


Internet-Draft            SigComp Torture Tests                July 2005


4.3  Multiple compartments

   This section gives assembly code to test the interaction between
   multiple SigComp compartments.  The code is designed to test that the
   following boundary cases have been correctly implemented:

   1.  The same state item is saved in more than one compartment.

   2.  A state item stored in multiple compartments has the same state
   identifier but a different state_retention_priority in each case.

   3.  A state item is deleted from one compartment but still belongs to
   a different compartment.

   4.  A state item belonging to multiple compartments is deleted from
   every compartment to which it belongs.

   The test requires a total of three compartments to be available,
   which will be referred to as Compartment 0, Compartment 1 and
   Compartment 2.  Each of the three compartments should have a
   state_memory_size of 2048 bytes.

   The assembly code for the test is given below:


   at (64)

   :byte_copy_left                 pad (2)

   :byte_copy_right                pad (2)
   :type                           pad (1)
   :type_lsb                       pad (1)

   at (128)

   MULTILOAD (byte_copy_left, 2, state_start, state_end)
   INPUT-BYTES (1, type_lsb, !)
   COMPARE ($type, 3, create_state, overwrite_state, temp)

   :temp

   COMPARE ($type, 5, overwrite_state, access_state, error_conditions)

   :create_state
   ; starting byte identified by $type according to input:
   ; Input     0x00        0x01        0x02
   ; $type      512         513         514




Surtees & West          Expires January 19, 2006               [Page 48]


Internet-Draft            SigComp Torture Tests                July 2005


   ADD ($type, state_start)
   STATE-CREATE (448, $type, 0, 6, 0)

   ;create state again, beginning in different place in buffer
   ; starting byte identified by $type according to input:
   ; Input     0x00        0x01        0x02
   ; $type      515         516         517

   ADD ($type, 3)
   STATE-CREATE (448, $type, 0, 6, 0)

   ; create a third time beginning in different place again
   ; starting byte identified by $type according to input:
   ; Input     0x00        0x01        0x02
   ; $type      516         517         515

   SUBTRACT ($type, temp_one)
   REMAINDER ($type, 3)
   ADD ($type, temp_two)
   STATE-CREATE (448, $type, 0, 6, 0)

   :common_state

   STATE-CREATE (448, temp_three, 0, 6, $type)
   JUMP (end)

   :overwrite_state

   STATE-CREATE (1984, 32, 0, 6, 0)
   JUMP (end)

   :access_state

   STATE-ACCESS (state_identifier_c, 6, 0, 0, 0, 0)
   STATE-ACCESS (state_identifier_d, 6, 0, 0, 0, 0)
   STATE-ACCESS (state_identifier_f, 6, 0, 0, 0, 0)
   STATE-ACCESS (state_identifier_g, 6, 0, 0, 0, 0)

   :end

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)

   :error_conditions

   COMPARE ($type, 7, access_a, access_b, access_e)

   :access_a




Surtees & West          Expires January 19, 2006               [Page 49]


Internet-Draft            SigComp Torture Tests                July 2005


   STATE-ACCESS (state_identifier_a, 6, 0, 0, 0, 0)
   JUMP (end)

   :access_b

   STATE-ACCESS (state_identifier_b, 6, 0, 0, 0, 0)
   JUMP (end)

   :access_e

   STATE-ACCESS (state_identifier_e, 6, 0, 0, 0, 0)
   JUMP (end)

   at (512)

   :state_start

   byte (0, 1, 2, 3, 4, 5, 6)

   :state_end

   set (temp_one, (state_start + 2))   ; = 514
   set (temp_two, (state_start + 3))   ; = 515
   set (temp_three, (state_end - 1))   ; = 518

   :state_identifier_a         ; start state at 512

   byte (172, 166, 11, 142, 178, 131)

   :state_identifier_b         ; start state at 513

   byte (157, 191, 175, 198, 61, 210)

   :state_identifier_c         ; start state at 514

   byte (52, 197, 217, 29, 83, 97)

   :state_identifier_d         ; start state at 515

   byte (189, 214, 186, 42, 198, 90)

   :state_identifier_e         ; start state at 516

   byte (71, 194, 24, 20, 238, 7)

   :state_identifier_f         ; start state at 517

   byte (194, 117, 148, 29, 215, 161)



Surtees & West          Expires January 19, 2006               [Page 50]


Internet-Draft            SigComp Torture Tests                July 2005


   :state_identifier_g         ; start state at 518

   byte (72, 135, 156, 141, 233, 14)


   The above code must be executed a total of 9 times in order to
   complete the test.  Each time the code is executed a 1-byte
   compressed message N should be provided, taking the values 0x00 to
   0x08 in ascending order (so the compressed message should be 0x00 the
   first time the code is run, 0x01 the second and so on).

   If the code makes a state creation request then the state must be
   saved in Compartment (N modulo 3).

   When the compressed message is 0x00, 0x01 or 0x02 the code makes four
   state creation requests in compartments 0, 1 and 2 respectively.
   This creates a total of seven distinct state items referred to as
   State a through to state g.  The states should be distributed amongst
   the three compartments as illustrated in Figure 1 (note that some
   states belong to more than one compartment).

   When the compressed message is 0x03 or 0x04 the code overwrites all
   of the states in compartments 0 and 1 respectively.  This means that
   states a, b and e will be unavailable because they are no longer
   present in any of the three compartments.

   When the compressed message is 0x05 the code checks that the states
   c, d, f and g are still available.  Decompression should terminate
   successfully in this case.

   When the compressed message is 0x06, 0x07 or 0x08 the code attempts
   to access states a, b and e respectively.  Decompression failure
   should occur in this case because the relevant states are no longer
   available.

   The cost in UDVM cycles for each compressed message is given below
   (except for messages 0x06, 0x07 and 0x08 where decompression failure
   should to occur):

   Compressed message:  0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08

   Cost in UDVM cycles: 1809 1809 1809 1993 1994 1804  N/A  N/A  N/A









Surtees & West          Expires January 19, 2006               [Page 51]


Internet-Draft            SigComp Torture Tests                July 2005


                     +-----------------------------+
                     |        Compartment 0        |
                     |                             |
                     |                             |
                     |           State a           |
                     |                             |
                     |         +-------------------+---------+
                     |         |                   |         |
                     |         |                   |         |
                     |         |           State d |         |
                     |         |                   |         |
                     |         |                   |         |
           +---------+---------+---------+         |         |
           |         |         |         |         |         |
           |         |         |         |         |         |
           |         | State e | State g |         | State c |
           |         |         |         |         |         |
           |         |         |         |         |         |
           |         +---------+---------+---------+         |
           |                   |         |                   |
           |                   |         |                   |
           |           State b | State f |                   |
           |                   |         |                   |
           |                   |         |   Compartment 2   |
           |                   +---------+-------------------+
           |                             |
           |                             |
           |                             |
           |                             |
           |        Compartment 1        |
           +-----------------------------+

            Figure 1: States created in the three compartments


4.4  Accessing RFC 3485 State

   This section gives assembly code to test accessing SIP-SDP static
   dictionary state [3].  The code first accesses the state and then
   outputs result.











Surtees & West          Expires January 19, 2006               [Page 52]


Internet-Draft            SigComp Torture Tests                July 2005


   at (32)

   :input      pad (1)
   :input2     pad (1)
   :input3     pad (1)

   at (128)

   STATE-ACCESS (sip_dictionary, 20, 0xcfe, 1, input, 0)
   STATE-ACCESS (sip_dictionary, 6, 0xcff, 1, input2, 0)
   STATE-ACCESS (sip_dictionary, 12, 0xd00, 1, input3, 0)

   OUTPUT (input, 3)

   END-MESSAGE (0, 0, 0, 0, 0, 0, 0)

   :sip_dictionary
   byte (0xfb, 0xe5, 0x07, 0xdf, 0xe5, 0xe6)
   byte (0xaa, 0x5a, 0xf2, 0xab, 0xb9, 0x14)
   byte (0xce, 0xaa, 0x05, 0xf9, 0x9c, 0xe6)
   byte (0x1b, 0xa5)


   The output of the code is 0x5349 50, and the cost is 11 UDVM cycles.

4.5  Bytecode state creation

   This section gives assembly code to test storing bytecode using END-
   MESSAGE and later loading the bytecode using a partial state
   identifier within the SigComp header.  The assembly code is designed
   so that it includes testing changing bytes to be stored after the
   state create request, changing the bytes of the bytecode before they
   are executed, loading byte code in special memory areas and correct
   initialization order of the UDVM.

   1.  Four items of bytecode state are created.  The bytes to be saved
   change after the first state create request.  The uploaded bytecode
   is modified before execution.

   2.  The bytecode is loaded using partial state identifier and
   modified before execution.

   3.  The bytecode is loaded before 128 using partial state identifier.

   4.  The bytecode is loaded using partial state identifier.  Part of
   the loaded memory is reserved area, which is overwritten after
   loading the bytecode.




Surtees & West          Expires January 19, 2006               [Page 53]


Internet-Draft            SigComp Torture Tests                July 2005


   5.  The byte loading fails because the partial state identifier is
   too short.


   at (30)
   :save_area1
   set (saved_instr1, (save_area1 + (code_start2 - start_saved))) ; = 33

   at (80)
   :save_area2
   set (saved_instr2, (save_area2 + (code_start2 - start_saved))) ; = 83

   at (128)
   :code_start

   COPY (start_saved, saved_len, save_area1)
                       ; copy 'ok2', OUTPUT (save_area2,3) END-MESSAGE
                       ; to position 30 and create as state
   STATE-CREATE (saved_len, save_area1, saved_instr1, 6, 10)


   set (modify1, (save_area1 + 5)) ; = 35
   LOAD (modify1, 0x1e03)
                       ; modify save_area2 to be save_area1 in the
                       ; created state

   COPY (start_saved, saved_len, save_area2)
   STATE-CREATE (saved_len, save_area2, saved_instr2, 20, 10)
   STATE-CREATE (saved_len, save_area2, saved_instr2, 12, 10)
                       ; copy 'ok2', OUTPUT (save_area2,3) END-MESSAGE
                       ; to position 80 and create as state twice with
                       ; min access len 20 and 12

   JUMP (modify)

   :ok1    byte (0x4f, 0x4b, 0x31)

   :modify
   INPUT-BYTES (1, (after_output - 1), !)
                       ; Input overwrites the next instruction
   OUTPUT (ok1, 3)     ; Now is OUTPUT (ok1, 2) so output is 0x4f4b

   :after_output

   ; Save from ok1 to the opcode of END-MESSAGE
   set (modify_len, ((after_output + 1) - ok1)) ; = 14

   END-MESSAGE (0, 0, modify_len, ok1, modify, 6, 10)



Surtees & West          Expires January 19, 2006               [Page 54]


Internet-Draft            SigComp Torture Tests                July 2005


                       ; Save 'ok1', INPUT-BYTES, OUTPUT as state

   set (saved_len, (end_saved - start_saved)) ; = 8

   :start_saved
   byte (0x4f, 0x4b, 0x32)

   :code_start2

   ; Translated bytecode for OUTPUT (save_area2, 3)
   byte (0x22, 0xa0, 0x50, 0x03)

   ; Translated bytecode for END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
   ; The zeros do not need to be sent because UDVM is initialised to 0
   byte (0x23)

   :end_saved


   The outputs and cycle usages are:



   Message              Output                  Cycles
   1                    0x4f4b                  67
   2                    0x4f4b 31               7
   3                    0x4f4b 32               5
   4                    0x0000 32               5
   5                    None                    Decompression failure


   First message: mnemonic code annotated above

   0xf804 6112 a0be 081e 2008 1e21 060a 0e23 be03 12a0 be08 a050 2008
   0xa050 a053 140a 2008 a050 a053 0c0a 1605 4f4b 311c 01a0 b39f 5522
   0xa0a7 0323 0000 0ea0 a7a0 aa06 0a4f 4b32 22a0 5003 2302

   Second message: access and run last state saved by previous message -
   'ok1', INPUT-BYTES, OUTPUT, END-MESSAGE.

   0xf953 e97f 4afd d203

   Third message: access and run state from save_area2 with 12 bytes of
   state identifier - 'ok2', INPUT-BYTES, OUTPUT, END-MESSAGE.

   0xfb24 63cd ff5c f8c7 6df6 a289 ff

   Fourth message: access and run state from save_area1.  The state is



Surtees & West          Expires January 19, 2006               [Page 55]


Internet-Draft            SigComp Torture Tests                July 2005


   'ok2', INPUT-BYTES, OUTPUT, END-MESSAGE but the first two bytes
   should be overwritten when initialising UDVM memory.

   0xf95b 4b43 d567 83

   Fifth Message: attempt to access state from save_area2 with fewer
   than 20 bytes of state identifier.

   0xf9de 8126 1199 1f

5.  Security considerations

   This draft describes torture tests for the SigComp protocol RFC-3320
   [2].  Consequently the security considerations for this draft match
   those of SigComp.

6.  Acknowledgements

   Thanks to Pekka Pessi and Richard Price for test contributions and to
   Cristian Constantin for valuable input and review.

7.  References

   [1]  Surtees, A. and M. West, "SigComp User Guide",
        draft-ietf-rohc-sigcomp-userguide-01.txt (work in progress),
        February 2004.

   [2]  Price, R., Borman, C., Christoffersson, J., Hannu, H., Liu, Z.,
        and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320,
        January 2003.

   [3]  Garcia-Martin, M., Ott, J., Borman, C., Price, R., and A. Roach,
        "The Session Initiation Protocol (SIP) and Session Description
        Protocol (SDP) Static Dictionary for Signaling Compression
        (SigComp)", RFC 3485, February 2003.

   [4]  Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
        February 2004.

   [5]  Bradner, S., "Intellectual Property Rights in IETF Technology",
        BCP 79, RFC 3668, February 2004.










Surtees & West          Expires January 19, 2006               [Page 56]


Internet-Draft            SigComp Torture Tests                July 2005


Authors' Addresses

   Abigail Surtees
   Siemens/Roke Manor Research
   Roke Manor Research Ltd.
   Romsey, Hants  SO51 0ZN
   UK

   Phone: +44 (0)1794 833131
   Email: abigail.surtees@roke.co.uk
   URI:   http://www.roke.co.uk


   Mark A. West
   Siemens/Roke Manor Research
   Roke Manor Research Ltd.
   Romsey, Hants  SO51 0ZN
   UK

   Phone: +44 (0)1794 833311
   Email: mark.a.west@roke.co.uk
   URI:   http://www.roke.co.uk

Appendix A.  UDVM bytecode for the torture tests

   The following sections list the raw UDVM bytecode generated for each
   test.  The bytecode is presented in the form of a complete SigComp
   message, including the appropriate header.  It is followed by input
   messages, the output they produce and where the decompression
   succeeds the number of cycles used.

   In some cases the test is designed to be run several times with
   different compressed messages appended to the code.  In the cases
   where multiple whole messages are used for a test e.g.
   Appendix A.2.3, these are supplied.

   Note that the different assemblers can output different bytecode for
   the same piece of assembly code, so a valid assembler can produce
   results different from those presented below.  However, the following
   bytecode should always generate the same results on any UDVM.

A.1  Instructions

A.1.1  Bit manipulation







Surtees & West          Expires January 19, 2006               [Page 57]


Internet-Draft            SigComp Torture Tests                July 2005


   0xf80a 7116 a07f 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x01c0 00ff 8055 5502 202a 0321 0420 0305 21ff 2286 0401 20c0 ff02
   0x2060 0320 0421 6005 2061 2286 0423

   Input: None
   Output: 0x0150 0000 febf 0000
   Cycles: 22



A.1.2  Arithmetic


   0xf80a a11c 01a0 459f 9f07 2201 16a0 7600 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x06c0 00ff 9941 0720 0108 20a3 e909 20a0 650a 200b 2286 0406 21c0
   0xff07 2162 0821 6109 2061 0a21 6222 8604 23

   Input: 0x00
   Output: 0x0000 0000 0000 0004
   Cycles: 25

   Input: 0x01
   DECOMPRESSION-FAILURE

   Input: 0x02
   DECOMPRESSION-FAILURE



A.1.3  Sorting













Surtees & West          Expires January 19, 2006               [Page 58]


Internet-Draft            SigComp Torture Tests                July 2005


   0xf80d c10c 8802 170b 8802 1722 a12e 2d23 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0a00 0a00 1100 0700 1600 0300 0300 0300 1300 0100 1000 0e00
   0x0800 0200 0d00 1400 1200 1700 0f00 1500 0c00 0600 096e 6720 6975
   0x6920 7469 742c 2079 6f75 2720 5346 6f6e 6761 2075 7272 646f 2074
   0x6f6e 2e2e 0070 6570 206e 7472 656e 69

   Input: None
   Output: 0x466f 7264 2c20 796f 7527 7265 2074 7572 6e69 6e67
           0x2069 6e74 6f20 6120 7065 6e67 7569 6e2e 2053 746f
           0x7020 6974 2e
   Cycles: 371



A.1.4  SHA-1


   0xf808 710d a0c3 03a0 4422 a044 140d a0c6 38a0 4422 a044 140e 86a0
   0xfe0e a042 a0ff 0da0 feff a044 22a0 4414 0e86 a0ff 0ea0 42a1 070d
   0xa0ff a280 a0ff 22a0 ff14 2300 0000 0000 0000 6162 6361 6263 6462
   0x6364 6563 6465 6664 6566 6765 6667 6866 6768 6967 6869 6a68 696a
   0x6b69 6a6b 6c6a 6b6c 6d6b 6c6d 6e6c 6d6e 6f6d 6e6f 706e 6f70 7161
   0x3031 3233 3435 3637

   Input: None
   Output: 0xa999 3e36 4706 816a ba3e 2571 7850 c26c 9cd0 d89d
           0x8498 3e44 1c3b d26e baae 4aa1 f951 29e5 e546 70f1
           0xe1d0 a18d 43d3 a689 af08 8e15 6bd0 434a a0c8 31fc
           0x4f46 0452 ebb5 6393 4f46 0452 ebb5 6393 4f46 0452
   Cycles: 66327



A.1.5  LOAD and MULTILOAD













Surtees & West          Expires January 19, 2006               [Page 59]


Internet-Draft            SigComp Torture Tests                July 2005


   0xf803 710e 87a0 840e a082 c080 0ec0 80a0 860e c084 c084 2287 081c
   0x01a0 419f 8908 2002 0620 3c0f 6003 a0a3 a0b2 870f 6004 2a87 c080
   0xc084 2287 0823

   Input: 0x00
   Output: 0x0084 0084 0086 0086 002a 0080 002a 002a
   Cycles: 36

   Input: 0x01
   DECOMPRESSION-FAILURE

   Input: 0x02
   DECOMPRESSION-FAILURE



A.1.6  COPY


   0xf803 910e 208e 0e86 860e a042 8712 2087 210e 8680 4100 1286 a055
   0xa041 2220 a077 0e86 200e a042 3015 2004 a041 0112 2004 3022 3004
   0x1230 042e 2220 0223

   Input: None
   Output: 0x4040 4040 4040 4040 4040 4040 4040 4040 4040 4040
           0x4040 4040 4040 4040 4040 4040 4141 4141 4141 4141
           0x4141 4141 4141 4141 4141 4141 4141 4141 4141 4141
           0x4141 4141 4141 4141 4141 4141 4141 4141 4141 4141
           0x4141 4141 4141 4141 4141 4141 4141 4141 4141 4141
           0x4141 4141 4141 4141 4141 4141 4141 4141 4141 5541
           0x4243 4443 44
   Cycles: 365



A.1.7  COPY-LITERAL and COPY-OFFSET


   0xf806 110e 2080 4100 0e86 860e a042 870e a044 2113 2087 2222 8608
   0x0ea0 44a0 9c13 2002 2222 a09c 020e 86a0 480e a042 a052 0ea0 44a0
   0x5215 a048 0aa0 4101 1402 0622 0ea0 4606 1463 0422 2261 0a0e a044
   0xa050 1404 0422 22a0 4402 1405 0422 22a0 4402 2260 0a23

   Input: None
   Output: 0x4141 4141 0061 4141 4141 494A 4142 4344 494A 4142
           0x004A 004E 4748 4845 4647 4748 4546
   Cycles: 216




Surtees & West          Expires January 19, 2006               [Page 60]


Internet-Draft            SigComp Torture Tests                July 2005


A.1.8  MEMSET


   0xf801 810e 8687 0ea0 42a0 8115 86a0 8100 0115 a081 0f86 0f22 8710
   0x23

   Input: None
   Output: 0x8040 4f5e 6d7c 8b9a a9b8 c7d6 e5f4 0312
   Cycles: 166



A.1.9  CRC


   0xf801 a115 a046 1801 0115 a05e 1487 011c 02a0 449f 931b 62a0 462c
   0x9f8d 23

   Input: 0x62cb
   Output: None
   Cycles: 95

   Input: 0xabcd
   DECOMPRESSION FAILURE



A.1.10  INPUT-BITS


   0xf801 511d 62a0 4614 22a0 4602 0622 010a 2207 0622 0116 ee23

   Input: 0x932e ac71
   Output: 0x0000 0002 0002 0013 0000 0003 001a 0038
   Cycles: 66



A.1.11  INPUT-HUFFMAN


   0xf801 d11e a046 1c02 6200 6262 6200 ff00 22a0 4602 0622 010a 2207
   0x0622 0116 e623

   Input: 0x932e ac71 66d8 6f
   Output: 0x0000 0003 0008 04d7 0002 0003 0399 30fe
   Cycles: 84




Surtees & West          Expires January 19, 2006               [Page 61]


Internet-Draft            SigComp Torture Tests                July 2005


A.1.12  INPUT-BYTES


   0xf802 710e 86a0 480e a042 a04c 1d62 a046 1d22 a046 0206 2202 0a22
   0x071c 62a0 480e 22a0 4862 0622 0116 e523

   Input: 0x932e ac71 66d8 6fb1 592b dc9a 9734 d847 a733 874e
         0x1bcb cd51 b5dc 9659 9d6a
   Output: 0x0000 932e 0001 b166 d86f b100 1a2b 0003 9a97 34d8
          0x0007 0001 3387 4e00 08dc 9651 b5dc 9600 599d 6a
   Cycles: 130



A.1.13  Stack Manipulation


   0xf814 110e a046 8610 0210 6010 a042 2286 0811 8611 6311 a046 2286
   0x0816 2800 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 000e a046 200e a048 a140 0724
   0x8818 3400 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0018 6400 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 000e a046 a17f 0ea1 7f1a 0fa1 b003
   0x0180 c001 8f19 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0023

   Input: None
   Output: 0x0003 0002 0001 0042 0042 0000 0001 0001
   Cycles: 40



A.1.14  Program Flow


   0xf803 f10e a044 040e 86a0 9207 20a0 9022 a043 0116 6006 2101 0e86
   0xa084 0720 a0a1 22a0 4301 1761 0660 f106 0722 010e 86a0 8407 20a0
   0xb622 a043 011a 0462 0860 9fdc f123

   Input: None
   Output: 0x0001 0102 0203 0304 0405 0506 0707 0708 0808 0909
   Cycles: 131




Surtees & West          Expires January 19, 2006               [Page 62]


Internet-Draft            SigComp Torture Tests                July 2005


A.1.15  State creation


   0xf809 411c 01a0 459f 7f04 220b 1762 8f0d 0606 200a a10a 0014 0004
   0x2201 1762 8f0c 0606 200a 8800 1400 0422 0117 628f 1606 061c 01a0
   0x479f 5121 a048 6312 a0e4 63a0 4804 2201 1762 8f0a 0606 21a0 e406
   0x0422 0117 628f 0e06 0623 0000 0a88 0014 0023 0000 0000 0000 0043
   0x7ae8 0a0f dc1e 6a87 c1b6 2a76 76b9 7331 8c0e f500 0000 0000 0000
   0x00c0 cc3f ee79 bcfc 8fd1 0865 e803 52ee 2977 17df 57

   Input: 0x01
   Output: None
   Cycles: 23

   Input: 0x02
   Output: None
   Cycles: 14

   Input: 0x03
   Output: None
   Cycles: 24

   Input: 0x0405
   DECOMPRESSION-FAILURE

   Input: 0x0415
   DECOMPRESSION-FAILURE

   Input: 0x0406
   Output: None
   Cycles: 23

   Input: 0x09
   Output: None
   Cycles: 34

   Input: 0x1e06
   Output: None
   Cycles: 46

   Input: 0x1e07
   Output: None
   Cycles: 47

   Input: 0x1e14
   Output: None
   Cycles: 60




Surtees & West          Expires January 19, 2006               [Page 63]


Internet-Draft            SigComp Torture Tests                July 2005


A.1.16  STATE-ACCESS


   Set up bytecode:
   0xf819 0123 0000 1089 0014 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0022 a20c
   0x0423 0000 0000 0000 0074 6573 74

   Input: None

   0xf819 411c 01a0 459f 9f17 6201 060d 1c1f 8914 0000 0089 1f89 140c
   0x04a0 4600 22a0 4604 16a1 4517 6203 0610 1b1f 8714 0000 0000 16a1
   0x351f 8913 0604 a046 0016 a12a 1f89 140c 05a0 4600 16a1 1f00 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0023 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 005d f8bc
   0x3e20 93b5 abe1 f170 1342 4ce7 fe05 e069 39

   Input: 0x00
   Output: 0x7465 7374
   Cycles: 26

   Input: 0x01
   Output: 0x7465 7374
   Cycles: 15




Surtees & West          Expires January 19, 2006               [Page 64]


Internet-Draft            SigComp Torture Tests                July 2005


   Input: 0x02
   DECOMPRESSION-FAILURE

   Input: 0x03
   DECOMPRESSION-FAILURE

   Input: 0x04
   DECOMPRESSION-FAILURE



A.2  Dispatcher tests

A.2.1  Useful Values


   0xf805 b10e 8620 0ea0 4221 1742 019f 9808 9f98 1743 009f 9007 0d17
   0x4400 fb3d fb17 44a3 c0fc 07fc 1c01 a047 f506 2340 0723 0112 2001
   0x631c 01a0 49e6 0ea0 4443 0622 0308 2208 0622 a3e8 0822 4106 2264
   0x0722 a3d6 1220 6220 2300 00a3 c086 8706 0000

   Input: None
   Output: None
   Cycles: 966

   0xf996 714B C686 F1

   Input: 0x0000
   Output: None
   Cycles: cycles_per_bit * 1072

   Input: 0x0001
   DECOMPRESSION-FAILURE

   Input: 0x0100
   DECOMPRESSION-FAILURE



A.2.2  Cycles Checking


   0xf801 a10f 8604 2029 0022 12a0 4402 6014 02a0 6423 22a0 4402 0622
   0x0116 ef

   Input: None
   DECOMPRESSION-FAILURE




Surtees & West          Expires January 19, 2006               [Page 65]


Internet-Draft            SigComp Torture Tests                July 2005


A.2.3  Message-based transport


   0xf8

   Input: None
   DECOMPRESSION-FAILURE

   0xf800

   Input: None
   DECOMPRESSION-FAILURE

   0xf800 e106 0011 2200 0223 0000 0000 0000 01

   Input: None
   Output: decompression_memory_size
   Cycles: 5

   0xf800 f106 0011 2200 0223 0000 0000 0000 01

   Input: None
   DECOMPRESSION-FAILURE

   0xf800 e006 0011 2200 0223 0000 0000 0000 01

   Input: None
   DECOMPRESSION-FAILURE

   0xf800 ee06 0011 2200 0223 0000 0000 0000 01

   Input: None
   Output: decompression_memory_size
   Cycles: 5



A.2.4  Stream-based transport













Surtees & West          Expires January 19, 2006               [Page 66]


Internet-Draft            SigComp Torture Tests                July 2005


   0xffff f801 7108 0002 2200 0222 a092 0523 0000 0000 0000 00ff 00ff
   0x03ff ffff ffff ffff f801 7e08 0002 2200 0222 a3d2 0523 0000 0000
   0x0000 00ff 04ff ffff ffff ffff ffff ff

   The above stream contains two messages:

   Output: decompression_memory_size
   Cycles: 11

   Output: decompression_memory_size
   Cycles: 11

   0xf8ff ff

   Input: None
   DECOMPRESSION-FAILURE

   0xf800 ffff

   Input: None
   DECOMPRESSION-FAILURE

   0xf801 8108 0002 2200 0222 a092 0523 ffff 0000 0000 0000 00ff 00ff
   0x03ff ffff

   Input: None
   DECOMPRESSION-FAILURE

   0xf801 7008 0002 2200 0222 a092 0523 ffff 0000 0000 0000 00ff 04ff
   0xffff ff

   Input: None
   DECOMPRESSION-FAILURE



A.2.5  Input past the end of a message


   0xf803 810e 86a0 460e a042 a04d 1d09 a046 9f96 1c07 a046 0716 231d
   0x07a0 469f 891c 02a0 469f 8322 a046 021d 10a0 4607 160c 1d08 a046
   0x9f72 22a0 4701 23

   Input: 0xfffa 0068 6921
   Output: 0x6869 21
   Cycles: 23

   Input: 0xfffa 0068 69



Surtees & West          Expires January 19, 2006               [Page 67]


Internet-Draft            SigComp Torture Tests                July 2005


   DECOMPRESSION-FAILURE



A.3  State handler tests

A.3.1  SigComp feedback mechanism


   0xf805 031c 01a0 419f 1f17 6001 070e 9f19 0ea0 42a4 7f16 0e0e a042
   0xa4ff 15a0 44a0 7f01 010e a0c3 a801 0ea0 c5a6 000e a0cc ac00 0ea0
   0xd9b4 000e a0ee b500 15a0 c606 0001 15a0 cd0c 0001 15a0 da14 0001
   0x23a0 42a0 c3

   Input: 0x00
   Output: None
   Cycles: 52

   Input: 0x01
   Output: None
   Cycles: 179



A.3.2  State memory management


























Surtees & West          Expires January 19, 2006               [Page 68]


Internet-Draft            SigComp Torture Tests                July 2005


   0xf81b a10f 8602 89a2 041c 01a0 479f 9917 6305 08a0 68a0 7017 6303
   0x0734 a056 0823 0606 23a2 040e a044 6306 2306 1262 02a0 4a17 6263
   0x08a0 589f 710e a048 6508 2488 2064 8900 0665 0622 0216 e31f a216
   0x0600 0000 001f a21c 0600 0000 001f a222 0600 0000 001f a22e 0600
   0x0000 0016 1e1f a228 0600 0000 0016 1420 8b89 0006 0016 0c1f a234
   0x0600 0000 0016 0223 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0074 6573
   0x7400 0000 0100 0200 0300 0400 0300 0200 0100 008e ea4b 43a7 87f9
   0x010e ef56 7b23 9a34 6b15 a6b4 0fc0 e44d 2cd4 a221 47e6 0aef f2bc
   0x0fb6 af

   Input: 0x00
   Output: None
   Cycles: 811

   Input: 0x01
   Output: None
   Cycles: 2603

   Input: 0x02
   Output: None
   Cycles: 811

   Input: 0x03
   Output: None
   Cycles: 1805

   Input: 0x04
   DECOMPRESSION-FAILURE

   Input: 0x05
   Output: None
   Cycles: 2057

   Input: 0x06
   Output: None
   Cycles: 1993






Surtees & West          Expires January 19, 2006               [Page 69]


Internet-Draft            SigComp Torture Tests                July 2005


A.3.3  Multiple compartments


   0xf81b 110f 8602 89a2 071c 01a0 459f 9917 6203 0d3d 0617 6205 3786
   0xa068 0622 8920 a1c0 6200 0600 0622 0320 a1c0 6200 0600 0722 a202
   0x0a22 0306 22a2 0320 a1c0 6200 0600 20a1 c0a2 0600 0662 162b 20a7
   0xc020 0006 0016 221f a213 0600 0000 001f a219 0600 0000 001f a225
   0x0600 0000 001f a22b 0600 0000 0023 0000 0000 0000 0017 6207 0610
   0x1a1f a207 0600 0000 0016 ea1f a20d 0600 0000 0016 e01f a21f 0600
   0x0000 0016 9fd6 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
   0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0102
   0x0304 0506 aca6 0b8e b283 9dbf afc6 3dd2 34c5 d91d 5361 bdd6 ba2a
   0xc65a 47c2 1814 ee07 c275 941d d7a1 4887 9c8d e90e

   Input: 0x00
   Output: None
   Cycles: 1809

   Input: 0x01
   Output: None
   Cycles: 1809

   Input: 0x02
   Output: None
   Cycles: 1809

   Input: 0x03
   Output: None
   Cycles: 1993

   Input: 0x04
   Output: None
   Cycles: 1994

   Input: 0x05
   Output: None
   Cycles: 1804

   Input: 0x06
   DECOMPRESSION-FAILURE




Surtees & West          Expires January 19, 2006               [Page 70]


Internet-Draft            SigComp Torture Tests                July 2005


   Input: 0x07
   DECOMPRESSION-FAILURE

   Input: 0x08
   DECOMPRESSION-FAILURE



A.3.4  Accessing RFC 3485 State


   0xf803 a11f a0a6 14ac fe01 2000 1fa0 a606 acff 0121 001f a0a6 0cad
   0x0001 2200 2220 0323 0000 0000 0000 00fb e507 dfe5 e6aa 5af2 abb9
   0x14ce aa05 f99c e61b a5

   Input: None
   Output: 0x5349 50
   Cycles: 11



A.3.5  Bytecode state creation





























Surtees & West          Expires January 19, 2006               [Page 71]


Internet-Draft            SigComp Torture Tests                July 2005


   0xf804 6112 a0be 081e 2008 1e21 060a 0e23 be03 12a0 be08 a050 2008
   0xa050 a053 140a 2008 a050 a053 0c0a 1605 4f4b 311c 01a0 b39f 5522
   0xa0a7 0323 0000 0ea0 a7a0 aa06 0a4f 4b32 22a0 5003 2302

   Input: None
   Output: 0x4f4b
   Cycles: 67

   0xf953 e97f 4afd d203

   Input: None
   Output: 0x4f4b 31
   Cycles: 7

   0xfb24 63cd ff5c f8c7 6df6 a289 ff

   Input: None
   Output: 0x4f4b 32
   Cycles: 5

   0xf95b 4b43 d567 83

   Input: None
   Output: 0x0000 32
   Cycles: 5

   0xf9de 8126 1199 1f

   Input: None
   DECOMPRESSION-FAILURE





















Surtees & West          Expires January 19, 2006               [Page 72]


Internet-Draft            SigComp Torture Tests                July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

This Internet-Draft will expire on January 19, 2006.


Surtees & West          Expires January 19, 2006               [Page 73]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/