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

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 4896

Robust Header Compression                                     A. Surtees
Internet-Draft                                                   M. West
Expires: April 5, 2007                                Siemens/Roke Manor
                                                                A. Roach
                                                        Estacado Systems
                                                         October 2, 2006


                    Implementer's Guide for SigComp
               draft-ietf-rohc-sigcomp-impl-guide-07.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 April 5, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes common misinterpretations and some
   ambiguities in the Signalling Compression Protocol (SigComp), and
   offers guidance to developers to clarify any resultant problems.
   SigComp defines a scheme for compressing messages generated by
   application protocols such as the Session Initiation Protocol (SIP).




Surtees, et al.           Expires April 5, 2007                 [Page 1]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   This document does not address compression specific issues such as
   different compressor types and bytecode.  This information can be
   found in a separate document.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Decompression Memory Size  . . . . . . . . . . . . . . . . .   3
     2.1  Bytecode within Decompression Memory Size  . . . . . . . .   3
     2.2  Default Decompression Memory Size  . . . . . . . . . . . .   3
   3.   UDVM Instructions  . . . . . . . . . . . . . . . . . . . . .   4
     3.1  Data Input Instructions  . . . . . . . . . . . . . . . . .   4
     3.2  MULTILOAD  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.3  STATE-FREE . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.4  Using the stack  . . . . . . . . . . . . . . . . . . . . .   5
   4.   Byte Copying Rules . . . . . . . . . . . . . . . . . . . . .   6
     4.1  Instructions That Use Byte Copying Rules . . . . . . . . .   6
   5.   State Retention Priority . . . . . . . . . . . . . . . . . .   7
     5.1  Priority Values  . . . . . . . . . . . . . . . . . . . . .   7
     5.2  Multiple State Retention Priorities  . . . . . . . . . . .   7
     5.3  Retention Priority 65535 (or -1) . . . . . . . . . . . . .   8
   6.   Duplicate State  . . . . . . . . . . . . . . . . . . . . . .  10
   7.   State Identifier Clashes . . . . . . . . . . . . . . . . . .  10
   8.   Message re-ordering  . . . . . . . . . . . . . . . . . . . .  12
   9.   Requested Feedback . . . . . . . . . . . . . . . . . . . . .  12
     9.1  Feedback when SMS is zero  . . . . . . . . . . . . . . . .  12
     9.2  Updating feedback requests . . . . . . . . . . . . . . . .  12
   10.  Advertising resources  . . . . . . . . . . . . . . . . . . .  13
     10.1   The I-bit and local state items  . . . . . . . . . . . .  13
     10.2   Dynamic Update of Resources  . . . . . . . . . . . . . .  13
     10.3   Advertisement of locally available state items . . . . .  14
       10.3.1   Basic SigComp  . . . . . . . . . . . . . . . . . . .  14
       10.3.2   Dictionaries . . . . . . . . . . . . . . . . . . . .  15
       10.3.3   SigComp Extended Mechanisms  . . . . . . . . . . . .  15
   11.  Uncompressed bytecode  . . . . . . . . . . . . . . . . . . .  16
   12.  RFC 3485 SIP/SDP Static Dictionary . . . . . . . . . . . . .  17
   13.  Security Considerations  . . . . . . . . . . . . . . . . . .  18
   14.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  18
   15.  References . . . . . . . . . . . . . . . . . . . . . . . . .  18
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  19
   A.   Dummy Application Protocol (DAP) . . . . . . . . . . . . . .  20
     A.1  Introduction . . . . . . . . . . . . . . . . . . . . . . .  20
     A.2  Processing a DAP message . . . . . . . . . . . . . . . . .  20
     A.3  DAP message format in ABNF . . . . . . . . . . . . . . . .  22
     A.4  An example of a DAP message  . . . . . . . . . . . . . . .  22
        Intellectual Property and Copyright Statements . . . . . . .  23





Surtees, et al.           Expires April 5, 2007                 [Page 2]


Internet-Draft       Implementer's Guide for SigComp        October 2006


1.  Introduction

   SigComp [1] defines the Universal Decompressor Virtual Machine (UDVM)
   for decompressing messages sent by a compliant compressor.  SigComp
   further describes mechanisms to deal with state handling, message
   structure, and other details.  While the behavior of the decompressor
   is specified in great detail, the behavior of the compressor is left
   as a choice for the implementer.  During implementation and
   interoperability tests, some areas of SigComp that require
   clarification have been identified.  The sections that follow
   enumerate the problem areas identified in the specification, and
   attempt to provide clarification.

2.  Decompression Memory Size

2.1  Bytecode within Decompression Memory Size

   SigComp [1] states that the default Decompression Memory Size (DMS)
   is 2K. The UDVM memory size is defined in section 7 to be (DMS -
   sizeof (sigcomp_msg)) for messages transported over UDP and (DMS / 2)
   for those transported over TCP.  This means that when the message
   contains the bytecode (as it will for at least the first message)
   there will actually be two copies of the bytecode within the
   decompressor memory (see Figure 1).  It is correct that there are two
   copies of the bytecode within the decompressor memory, in this case.



    |<----------------------------DMS--------------------------------->|
    |<-----sigcomp message---->|<------------UDVM memory size--------->|
    +-+----------+-------------+-----+----------+----------------------+
    | | bytecode |  comp msg   |     | bytecode | circular buffer      |
    +-+----------+-------------+-----+----------+----------------------+
     ^                            ^
     |                            |
    Sigcomp header          Low bytes of UDVM


            Figure 1: Bytecode and UDVM memory size within DMS


2.2  Default Decompression Memory Size

   For many implementations, the length of decompression bytecode sent
   is in the range of three to four hundred bytes.  Because SigComp
   specifies a default DMS of 2K, the described scheme seriously
   restricts the size of the circular buffer, and of the compressed
   message itself.  In some cases, this set of circumstances has a



Surtees, et al.           Expires April 5, 2007                 [Page 3]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   damaging effect on the compression ratio; for others, it makes it
   completely impossible to send certain messages compressed.

   To address this problem, those mandating the use of Sigcomp should
   also provide further specification for their application that
   mandates the use of an appropriately sized DMS.

3.  UDVM Instructions

3.1  Data Input Instructions

   When inputting data from the compressed message, the INPUT-BYTES
   (section 9.4.2) and INPUT-BITS (section 9.4.3) instructions both have
   the paragraph:

   "If the instruction requests data that lies beyond the end of the
   SigComp message, no data is returned.  Instead the UDVM moves program
   execution to the address specified by the address operand."

   The intent is that if n bytes/bits are requested but only m are left
   in the message (where m < n) then no bytes/bits should be returned to
   the UDVM and the m bytes/bits that are there should remain in the
   message unchanged.

   For example, the remaining bytes of message are: 0x01 0x02 0x03 and
   the UDVM encounters an INPUT-BYTES (6, a, b) instruction.  The
   decompressor dispatcher returns no bytes and jumps to the instruction
   specified by b.  This contains an INPUT-BYTES (2, c, d) instruction
   so the decompressor dispatcher successfully returns the bytes 0x01
   and 0x02.

   In the case where an INPUT-BYTES instruction follows an INPUT-BITS
   instruction that has left a partial byte in the message, the partial
   byte should still be thrown away even if there are not enough bytes
   to input.

   INPUT-BYTES (0, a, b) can be used to flush out a partial byte.

3.2  MULTILOAD

   The MULTILOAD instruction is explicitly not allowed to be self
   modifying in order to make step-by-step implementation simpler.
   Therefore, any other implementation technique (e.g. decode all
   operands then execute, which is the model of all other instructions)
   must yield the same result as a step-by-step implementation would.
   That is, if there is any indirection of parameters, the indirection
   must be done at execution time.  For example:




Surtees, et al.           Expires April 5, 2007                 [Page 4]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   at (64)

   :location_a                     pad (2)
   :location_b                     pad (2)
   :location_c                     pad (2)
   pad (30)
   :udvm_memory_size               pad (2)
   :circular_buffer                pad (2)

   align (64)

   MULTILOAD (location_a, 3, circular_buffer,
                   udvm_memory_size, $location_a)


   The step-by-step implementation would: write the address of
   circular_buffer into location_a (memory address 64); write the
   address of udvm_memory_size into location_a + 2 (memory address 66);
   write the value stored in location_a (accessed using indirection -
   that is now the address of circular_buffer) into location_a + 4
   (memory address 68).  Therefore, at the end of the execution by a
   correct implementation, location_c must contain the address of
   circular_buffer.

3.3  STATE-FREE

   The STATE-FREE instruction does not check the minimum_access_length.
   This is correct because the state cannot be freed until the
   application has authenticated the message.  The lack of checking does
   not pose a security risk because, if the sender has enough
   information to create authenticated messages, then sending messages
   that save state can push previous state out of storage anyway.

   The STATE-FREE instruction can only free state in the compartment
   that corresponds to the message being decompressed.  Attempting to
   free state either from another compartment or that is not associated
   with a compartment has no effect.

3.4  Using the stack

   The instructions PUSH, POP, CALL and RETURN make use of a stack which
   is set up using the well known memory address stack_location to
   define where in memory the stack is located.  Use of the stack is
   defined in section 8.3 of SigComp [1] which states that: '"Pushing" a
   value on the stack is an abbreviation for copying the value to
   stack[stack_fill] and then increasing stack_fill by 1.' and
   'stack_fill is an abbreviation for the 2-byte word at stack_location
   and stack_location + 1'.  In the very rare case that the value of



Surtees, et al.           Expires April 5, 2007                 [Page 5]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   stack_fill is 0xFFFF, the new value pushed onto the stack will be
   written to stack [0xFFFF] = stack_location.  Stack_fill must then be
   increased by 1, however, the value at stack_location and
   stack_location + 1 has just been updated.  To maintain the integrity
   of the stack with regard to over and underflow, stack_fill MUST not
   be re-read.  The original stack_fill value of 0xFFFF should be
   increased by 1 to 0x0000 and written back to stack_location and
   stack_location + 1 (which will overwrite the value that has been
   pushed onto the stack).

4.  Byte Copying Rules

   Section 8.4 of SigComp [1] states that "The string of bytes is copied
   in ascending order of memory address, respecting the bounds set by
   byte_copy_left and byte_copy_right."  This is misleading in that it
   is perfectly legitimate to copy bytes outside of the bounds set by
   byte_copy_left and byte_copy_right.  Byte_copy_left and
   byte_copy_right provide the ability to maintain a circular buffer as
   follows:

   For moving to the right

   if current_byte == ((byte_copy_right - 1) mod 2 ^ 16):
       next_byte = byte_copy_left
   else:
       next_byte = (current_byte + 1) mod 2 ^ 16

   which is equivalent to the algorithm given in section 8.4.

   For moving to the left

   if current_byte == byte_copy_left:
       previous_byte = (byte_copy_right - 1) mod 2 ^ 16
   else:
       previous_byte = (current_byte - 1) mod 2 ^ 16

   Moving to the left is only used for COPY_OFFSET.

   Consequently, copying may begin to the left of byte_copy_left and
   continue across it (and jump back to it according to the given
   algorithm if necessary) and may begin at or to the right of
   byte_copy_right (though care must be taken to prevent decompression
   failure due to writing to / reading from beyond the UDVM memory).

4.1  Instructions That Use Byte Copying Rules

   Section 8.4 specifies the byte copying rules and includes a list of
   the instructions that obey them.  STATE-CREATE is not in this list



Surtees, et al.           Expires April 5, 2007                 [Page 6]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   but END-MESSAGE is.  This caused confusion due to the fact that
   neither instruction actually does any byte copying, rather both
   instructions give information to the state-handler to create state.
   Logically both instructions should have the same information about
   byte copying.

   When state is created by the state-handler (whether the instruction
   was from END-MESSAGE or STATE-CREATE), the byte copying rules of
   section 8.4 apply.

   Note that if the contents of the UDVM changes between the occurrence
   of the STATE-CREATE instruction and the state being created the bytes
   that are stored are those in the buffer at the time of creation
   (i.e. when the message has been decompressed and authenticated).

   CRC is not mentioned in the list of instructions in Section 8.4 that
   obey byte copying rules but its description in Section 9.3.5 states
   that these rules should be obeyed.  When reading data over which to
   perform the crc check byte copying rules apply as specified in
   Section 8.4.

   When the partial identifier is read for a STATE-FREE instruction
   (during the execution of END-MESSAGE) byte copying rules as per
   Section 8.4 apply.

   Given that reading the buffer for creating and freeing state within
   the END-MESSAGE instruction obeys byte copying rules, there may be
   some confusion as to whether reading feedback items should also obey
   byte copying rules.  Byte copying rules do not apply for reading
   feedback items.

5.  State Retention Priority

5.1  Priority Values

   For state_retention_priority, 65535 < 0 < 1 < ... < 65534.  This is
   slightly counter intuitive but is correct.

5.2  Multiple State Retention Priorities

   There may be confusion when the same piece of state is created at two
   different retention priorities.  The following clarifies this:
      The retention priority should be associated with the compartment
      and not with the piece of state.  For example, if endpoint A
      creates a piece of state with retention priority 1 and endpoint B
      creates exactly the same state with retention priority 2, there
      should be one copy (assuming the model of state management
      suggested in SigComp [1]) of the actual state but each compartment



Surtees, et al.           Expires April 5, 2007                 [Page 7]


Internet-Draft       Implementer's Guide for SigComp        October 2006


      should keep a record of this piece of state with its own priority.
      (If this does not happen then the state may be kept for longer
      than A anticipated or less time than B anticipated depending on
      which priority is used.  This could cause Decompression Failure to
      occur.)

      If the same piece of state is created within a compartment with a
      different priority, then one copy of it should be stored with the
      new priority and it should count only once against SMS.  That is,
      the state creation updates the priority rather than creates a new
      piece of state.

5.3  Retention Priority 65535 (or -1)

   There is potentially a problem with storing multiple pieces of state
   with the minimum retention priority (65535) as defined in SigComp
   [1].  This can be shown by considering the following examples, which
   are of shared mode SigComp Extended [2].  The key thing about state
   with retention priority 65535 is that it can be created by an
   endpoint in the decompressor compartment without the knowledge of the
   remote compressor (which controls state creation in the decompressor
   compartment).

   Example 1:

       [SMn state is shared mode state (priority 65535),
        BC is bytecode state (priority 1),
        BFn is buffer state (priority 0)]

       Endpoint A                  Endpoint B
       [decomp cpt]                [comp cpt]

       [SM1]
       ------------------------------->
                                   [SM1]

       [SM1, SM2]
       --------------------X (message lost)

                                   [SM1, BC, BF1]
       <------------ref SM1------------
       [SM2, BC, BF1]
                                   endpoint B still believes SM1
                                   is at endpoint A

                                   [BC, BF1, BF2]
       <------------ref SM1------------




Surtees, et al.           Expires April 5, 2007                 [Page 8]


Internet-Draft       Implementer's Guide for SigComp        October 2006


       decompression failure at A
       because SM1 has already been deleted

   Example 2:

       Endpoint A                  Endpoint B
       [decomp cpt]                [comp cpt]

       [SM1]
       ------------------------------->
                                   [SM1]

                                   [SM1, BC, BF1]
       (message lost)X------ref SM1-----

       [SM1, SM2]
       ------------------------------->
                                   endpoint B does not create SM2
                                   because there is no space
                                   [SM1, BC, BF1]

                                   [SM1, BC, BF1, BF2]
       <------------ref SM1------------
       [SM2, BC, BF2]
                                   endpoint B still believes SM1
                                   is at endpoint A

                                   [BC, BF1, BF2, BF3]
       <------------ref SM1------------

       decompression failure at A
       because SM1 has already been deleted

                Figure 2: Retention priority 65535 examples

   Once there is more than one piece of state of minimum priority state
   created in a decompressor compartment, the corresponding compressor
   cannot be certain about which pieces of state are present in that
   (decompressor) compartment.  If there is only one piece of state,
   then no such ambiguity exists.

   The problem is a consequence of the different rules for the creation
   of minimum priority state.  In particular, the creation of the second
   piece of state without the knowledge of the compressor may mean that
   the first piece is pushed out earlier than the compressor expects
   (despite the fact that the state processing rules from SigComp [1]
   are being implemented correctly).




Surtees, et al.           Expires April 5, 2007                 [Page 9]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   SigComp [1] also states that a compressor MUST be certain that all of
   the data needed to decompress a SigComp message is available at the
   receiving endpoint.  Thus it should not reference any state unless it
   can be sure that the state exists.  The fact that the compressor at B
   has no way of knowing how much state has been created at A can lead
   to loss of synchronisation between the endpoints which is not
   acceptable.

   One observation is that it is always safe to reference a piece of
   minimum priority state following receipt of the advertisement of the
   state.

   If it is known that both endpoints are running SigComp version 2 as
   defined in NACK [3], then it may be reasonable to assume that the
   likelihood of loss of synchronisation is very small and rely on the
   NACK mechanism for recovery.

   However, for a compressor to try and avoid causing the generation of
   NACKs, it has to be able to make some assumptions about the behaviour
   of the peer compressor.  Also if one of the endpoints does not
   support NACK, then some other solution is needed.

   Consequently, where NACK is not supported or for NACK averse
   compressors, the recommendation is that only one piece of minimum
   priority state should be present in a compartment at any one time.
   If both endpoints support NACK [3], then this recommendation may be
   relaxed, but implementers should think carefully about the
   consequences of creating multiple pieces of minimum priority state.
   In either case, if the behaviour of the application restricts the
   message flow, this fact could be exploited to allow safe creation of
   multiple minimum priority states; however, care must still be taken.

   Note that if a compressor wishes the remote endpoint to be able to
   create a new piece of minimum priority state, it can use the STATE-
   FREE instruction to remove the existing piece of state.

6.  Duplicate State

   If a piece of state is created in a compartment in which it already
   exists, the time of its creation should be updated as if it had just
   been created, irrespective of the new state retention priority.

7.  State Identifier Clashes

   Section 6.2 of SigComp [1] states that when creating a piece of
   state, the full 20 byte hash should be checked to see whether or not
   another piece of state with this identifier exists.  If it does, and
   the state item is not identical, then the new creation must fail.  It



Surtees, et al.           Expires April 5, 2007                [Page 10]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   is stated that the probability of this occurring is vanishingly small
   (and so it is, see below).

   However, when state is accessed, only the first n bytes of the state
   identifier are used, where n could be as low as 6.  At this point, if
   there are two pieces of state with the same first n bytes of state
   identifier, the STATE-ACCESS instruction will cause decompression
   failure.  The compressor referencing the state will not expect this
   failure mode because the state creation succeeded without a clash.
   At a server endpoint where there may be thousands or millions of
   pieces of state, how likely is this to actually happen?

   Consider the birthday paradox (where there only have to be 23 people
   in a room to have a greater than 50% chance that two of them will
   have the same birthday (Birthday [9]).

   The naive calculation using factorials gives:

                      N!
   Pd(N,s) = 1 - -------------
                 (N - s)! N^s

   where N is the number of possible values and s is the sample size.

   However, due to dealing with large numbers an approximation is
   required:

   Pd(N,s) = 1 - e^( LnFact(N) - LnFact(N-s) - s Ln(N) )

   where LnFact (x) is the log of x!, which can be approximated by:

   LnFact(x) ~ (x + 1/2) Ln(x) - x + Ln(2*Pi)/2 +

                1       1         1           1
               --- - ------- + -------- - --------
               12x   360 x^3   1260 x^5   1680 x^7


   which using N = 2^48 [6 octet partial state identifier] gives:

   s =   1 000 000: Pd (N,s) =  0.018%
   s =  10 000 000: Pd (N,s) =  16.28%
   s = 100 000 000: Pd (N,s) = 100.00%

   so when implementing, thought should be given as to whether or not 6
   octets of state identifier is enough to ensure that state access will
   be successful (particularly at a server).




Surtees, et al.           Expires April 5, 2007                [Page 11]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   The likelihood of a clash when using the full 20 octets of state
   identifier, does indeed have a vanishingly small probability:
   using N = 2^160 [full 20 octet state identifier] gives:

   s =   1 000 000: Pd (N,s) =  3.42E-35%
   s =  10 000 000: Pd (N,s) =  3.42E-33%
   s = 100 000 000: Pd (N,s) =  3.42E-31%

   Consequently, care must be taken when deciding how many octets of
   state identifier should be used to access state at the server.

8.  Message re-ordering

   SigComp [1] makes only one reference to the possibility of misordered
   messages.  However, the statement that the 'compressor MUST ensure
   that the message can be decompressed using the resources available at
   the remote endpoint' puts the onus on the compressor to take account
   of the possibility of misordering occurring.

   Whether misordering can occur and whether that would have an impact
   depends on the compartment definition and the transport protocol in
   use.  Therefore, it is up to the implementer of the compressor to
   take these factors into account.

9.  Requested Feedback

9.1  Feedback when SMS is zero

   If an endpoint receives a request for feedback then it should return
   the feedback even if its SMS is zero.  The storage overhead of the
   requested feedback is NOT part of the SMS.

9.2  Updating feedback requests

   When an endpoint receives a valid message it updates the requested
   feedback data for that compartment.  Section 5 of SigComp [1] states
   that there is no need to transmit any requested feedback item more
   than once.  However, there are cases where it would be beneficial for
   the feeback to be sent more than once (e.g. a retransmitted 200OK to
   an INVITE implies that the original 200OK, and the feedback it
   carried, may not have reached the remote endpoint).  Therefore, an
   endpoint SHOULD transmit feedback repeatedly until it receives
   another valid message that updates the feedback.

   Section 9.4.9 of SigComp [1] states that when
   requested_feedback_location equals zero, no feedback request is made.
   However, there is no indication of whether this means that the
   existing feedback data is left untouched or this means that the



Surtees, et al.           Expires April 5, 2007                [Page 12]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   existing feedback data should be overwritten to be 'no feedback
   data'.  If requested_feedback_location equals zero, the existing
   feedback data should be left untouched and returned in any subsequent
   messages as before.

   Section 9.4.9 of SigComp [1] also makes no statement about what
   happens to existing feedback data when requested_feedback_location
   does not equal zero but the Q flag indicating the presence/absence of
   a requested_feedback_item is zero.  In this case, the existing
   feedback data should be overwritten to be 'no feedback data'.

10.  Advertising resources

10.1  The I-bit and local state items

   The I-bit in requested feedback is a mechanism by which a compressor
   may tell a remote endpoint that it is not going to access any local
   state items.  By doing so, it gives the remote endpoint the option of
   not advertising them in subsequent messages.  Setting the I-bit does
   not obligate the remote endpoint to cease sending advertisements.

   The remote endpoint should still advertise its parameters such as DMS
   and state memory size (SMS).  (This is particularly important; if the
   sender of the first message sets the I-bit, it will still want the
   advertisement of parameters from the receiver.  If it doesn't receive
   these, it has to assume the default parameters which will affect
   compression efficiency.)

   The endpoint receiving an I-bit of 1 can reclaim the memory used to
   store the locally available state items.  However, this has NO impact
   on any state that has been created by the sender using END-MESSAGE or
   STATE-CREATE instructions.

10.2  Dynamic Update of Resources

   Decompressor resources such as SMS and DMS can be dynamically updated
   at the compressor by use of the SMS and DMS bits in returned
   parameters feedback (section 9.4.9).  Changing resources dynamically
   (apart from initial advertisements for each compartment) is not
   expected to happen very often.

   If additional resources are advertised to a compressor then it is up
   to the implementation at the compressor whether or not to make use of
   these resources.  For example, if the decompressor advertises 8k SMS
   but the compressor only has 4k SMS then the compressor may choose not
   to use the extra 4k (e.g. in order to monitor state saved at the
   decompressor).  In this case, there is no synchronisation problem.
   The compressor must not use more than the most recently advertised



Surtees, et al.           Expires April 5, 2007                [Page 13]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   resources.  Note that the compressor SMS is unofficial (enables
   compressor to monitor decompressor state) and is separate from the
   SMS advertised by the decompressor.

   Reducing the resources has potential synchronisation issues and so
   should not be done unless absolutely necessary.  If this is the case
   then the memory should not be reclaimed until the remote endpoint has
   acknowledged the message sent with the advertisement.  If state must
   be deleted to accommodate a reduction in SMS then both endpoints
   should delete it according to the state retention priority (section
   6.2).  The compressor should use up to the amount of resources most
   recently advertised.

10.3  Advertisement of locally available state items

   Section 3.3.3 of SigComp [1] defines locally available state items to
   be the pieces of state that an endpoint has available but that have
   not been uploaded by the SigComp message.  The examples given are
   dictionaries and well known pieces of bytecode; and the advertisement
   mechanism discussed in section 9.4.9 provides a way for the endpoint
   to advertise the pieces of locally available state that it has.

   However, SigComp [1] does not (nor was it ever intended to) fully
   define the use of locally available state items, in particular, the
   length of time for which they will be available.  The use of locally
   available state items is left for definition in other documents.
   However, this fact, coupled with the fact that SigComp does contain
   some hooks for uses of locally available state items and the fact
   that some of the definitions of such uses (in [2]) are incomplete has
   caused some confusion.  Therefore, this section clarifies the
   situation.

   Note that any definitions of uses of locally available state items
   must not conflict with any other uses.

10.3.1  Basic SigComp

   SigComp provides a mechanism for an endpoint to advertise locally
   available state (section 9.4.9).  If the endpoint receiving the
   advertisement does not 'recognise' it and therefore know the
   properties of the state e.g. its length and lifetime, the compressor
   should be consider very carefully whether or not to access the state;
   especially if NACK [3] is not available.

   SigComp provides the following hooks for use in conjunction with
   locally available state items.  Without further definition locally
   available state should not be used.




Surtees, et al.           Expires April 5, 2007                [Page 14]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   Section 6.2 of [1] allows for the possibility to map locally
   available state items to a compartment and states that if this is
   done, the state items must have state retention priority 65535 in
   order to not interfere with state created at the request of the
   remote compressor.  Note that Section 5.3 of this document also
   recommends that only one such piece of state should be created per
   compartment.

   The I-bit in the requested_feedback_location (see section 9.4.9)
   allows a compressor to indicate to the remote endpoint that it will
   not reference any of the previously advertised locally available
   state.  Depending on the implementation model for state handling at
   the remote endpoint, this could allow the remote endpoint to reclaim
   the memory being used by such state items.

10.3.2  Dictionaries

   The most basic use of the local state advertisement is the
   advertisement of a dictionary (e.g. the dictionary specified by SIP/
   SDP Static Dictionary [4]) or a piece of bytecode.  In general, these
   pieces of state:

      are not mapped to compartments
      are local to the endpoint
      are available for at least the duration of the compartment
      do not have any impact on the compartment SMS

   However, for a given piece of state the exact lifetime must be
   defined e.g. in public specifications such as SigComp for SIP [5] or
   3GPP IMS specifications.  Such a specification should also indicate
   whether or not advertisement of the state is needed.

10.3.3  SigComp Extended Mechanisms

   SigComp Extended [2] defines some uses of local state advertisements
   for which additional clarification is provided here.

   Shared-mode (section 5.2 of [2]) is well-defined (when combined with
   the clarification in Section 5.3 of this document).  In particular,
   the states that are created and advertised are mapped into the
   compartment, have the minimum retention priority and persist only
   until they are deleted by the creation of new (non minimum retention
   priority) state.

   The definition of endpoint initiated acknowledgements (section 5.1.2
   of [2]) requires clarification in order to ensure that the definition
   does not preclude advertisements being used to indicate that state
   will be kept beyond the lifetime of the compartment (as discussed in



Surtees, et al.           Expires April 5, 2007                [Page 15]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   [5]).  Thus the clarification is:

   Where Endpoint A requests state creation at Endpoint B, Endpoint B
   may subsequently advertise the hash of the created state item to
   Endpoint A. This conveys to Endpoint A (i) that the state has been
   successfully created within the compartment; and (ii) that the state
   will be available for at least the lifetime of the state as defined
   by the state deletion rules according to age and retention priority
   of SigComp [1].  If the state is available at Endpoint B after it
   would be deleted from the compartment according to [1], then the
   state no longer counts towards the SMS of the compartment.  Since
   there is no guarantee of such state being available beyond its
   normally defined lifetime, endpoints should only attempt to access
   the state after this time where it is known that NACK [3] is
   available.

11.  Uncompressed bytecode

   It is possible to write bytecode that simply instructs the
   decompressor to output the entire message (effectively sending it
   uncompressed but within a SigComp messsage).  This is particularly
   useful if the bytecode is well known (so that decompressors can
   recognise and output the bytes without running a VM if they wish), it
   is documented here.

   The mnemonic code is:

























Surtees, et al.           Expires April 5, 2007                [Page 16]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   at (0)
   :udvm_memory_size         pad (2)
   :cycles_per_bit           pad (2)
   :sigcomp_version          pad (2)
   :partial_state_id_length  pad (2)
   :state_length             pad (2)
   :reserved                 pad (2)
   at (64)
   :byte_copy_left           pad (2)
   :byte_copy_right          pad (2)
   :input_bit_order          pad (2)
   :stack_location           pad (2)

   ; Simple loop
   ;       Read a byte
   ;       Output a byte
   ; Until there are no more bytes!

   at (128)
   :start
   INPUT-BYTES (1, byte_copy_left, end)
   OUTPUT (byte_copy_left, 1)
   JUMP (start)

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

   which translates to give the following SigComp message:

   0xf8, 0x00, 0xa1, 0x1c, 0x01, 0x86, 0x09, 0x22, 0x86, 0x01, 0x16,
   0xf9, 0x23


12.  RFC 3485 SIP/SDP Static Dictionary

   SIP/SDP Static Dictionary [4] provides a dictionary of strings
   frequently used in SIP and SDP messages.  The format of the
   dictionary is the list of strings followed by a table of offset
   references to the strings so that a compressor can choose to
   reference the address of the string or the entry in the table.  Both
   parts of the dictionary are divided into 5 prioritised sections to
   allow compressors to choose how much of it they use (which is
   particularly useful in the case where it has to be downloaded).  If
   only part of the dictionary is used, then the corresponding sections
   of both parts (strings and offset table) are used.

   However, there are some minor bugs in the dictionary.  In a number of
   places, the entry in the offset table refers to an address that is



Surtees, et al.           Expires April 5, 2007                [Page 17]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   not in the corresponding priority section in the list of strings.
   Consequently, if the bytecode uses the offset table and limits use of
   the dictionary to priorities less than 4, then care must be taken not
   to use the following strings in the dictionary:

      'application' at 0x0334 is not at priority 2 (it's priority 4)
      'sdp' at 0x064b is not at priority 2 (it's priority 4)
      'send' at 0x089d is not at priority 2 (it's priority 3)
      'recv' at 0x0553 is not at priority 2 (it's priority 4)
      'phone' at 0x00f2 is not at priority 3 (it's priority 4)

   These are seen to be relatively low cost bugs as only these 5 strings
   are affected and they are only affected under certain conditions.

13.  Security Considerations

   This document provides clarifications to SigComp [1] but does not
   change it.  Consequently the security considerations are the same as
   those for SigComp [1].

14.  Acknowledgements

   Largely through being foolish enough to be authors of, or to have
   implemented, SigComp we would like to thank the following:
      Richard Price (richard.price@roke.co.uk)
      Lajos Zaccomer (lajos.zaccomer@ericsson.se)
      Timo Forsman (timo.forsman@ericsson.se)
      Tor-Erik Malen (tor-erik.malen@ericsson.se)
      Jan Christoffersson (jan.christoffersson@ericsson.se)
      Kwang Mien Chan (chankm@icr.a-star.edu.sg)
      William Kembery (wkember@lts.ncsc.mil)
      Pekka Pessi (pekka.pessi@nokia.com)
   for their confusion, suggestions and comments.

15.  References

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

   [2]  Hannu, H., Christoffersson, J., Forsgren, S., Leung, K., Liu,
        Z., and R. Price, "Signaling Compression (SigComp) - Extended
        Operations", RFC 3321, January 2003.

   [3]  Roach, A., "A Negative Acknowledgement Mechanism for Signaling
        Compression)", RFC XXXX, October 2004.

   [4]  Garcia-Martin, M., Borman, C., Ott, J., Price, R., and A. Roach,



Surtees, et al.           Expires April 5, 2007                [Page 18]


Internet-Draft       Implementer's Guide for SigComp        October 2006


        "The Session Initiation Protocol (SIP) and Session Description
        Protocol (SDP) Statc Dictionary for Signaling Compression
        (SigComp)", RFC 3485, February 2003.

   [5]  Borman, C., Liu, Z., Price, R., and G. Camarillo, "Applying
        Signaling Compression (SigComp) to the Session Initiation
        Protocol (SIP)", RFC XXXX, September 2006.

   [6]  Bradner, S., "The Internet Standards Process -- Revision 3",
        RFC 3667, February 2004.

   [7]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

   [8]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications (ABNF)", RFC 2234, November 1997.

   [9]  Ritter, T., "Estimating Population from Repetitions in
        Accumulated Random Samples", 1994,
        <http://www.ciphersbyritter.com/ARTS/BIRTHDAY.HTM>.


Authors' Addresses

   Abigail Surtees
   Siemens/Roke Manor
   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
   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







Surtees, et al.           Expires April 5, 2007                [Page 19]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   Adam Roach
   Estacado Systems
   US

   Email: adam@estacado.net

Appendix A.  Dummy Application Protocol (DAP)

A.1  Introduction

   This appendix defines a simple dummy application protocol (DAP) that
   can be used for SigComp interoperability testing.  This is handy for
   SigComp implementations that are not integrated with SIP stack.  It
   also provides some features that facilitate the tests of SigComp
   internal operations.

   The message format is quite simple.  Each message consists of a
   8-line message-header, an empty line, and an optional message-body.
   You can see the style resembles that of SIP and HTTP.

   The exact message format is given later in augmented Backus-Naur Form
   (ABNF) [8].  Here are a few notes:
      Each line of message-header must be terminated with CR LF.

      The empty line must be present even if the message-body is not.

      Body-length is the length of the message-body, excluding the CRLF
      which separates the message-body from the message-header.

      All strings in message-header are case-insensitive.

      For implementation according to this appendix, the DAP-version
      must be set to 1.

A.2  Processing a DAP message

   A message with invalid format will be discarded by a DAP receiver

   For testing purpose, a message with valid format will be returned to
   the original sender (IP address, port number) in clear text, i.e.,
   without compression.  This is the case even if the sender requests
   this receiver to reject the message.  Note that the entire DAP
   message (message-header + CRLF + message-body) is returned.  This
   allows the sender to compare what it sent with what the receiver
   decompressed.

   Endpoint-ID is the global identifier of the sending endpoint.  It can
   be used to test the case where multiple SigComp endpoints communicate



Surtees, et al.           Expires April 5, 2007                [Page 20]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   with the same remote SigComp endpoint.  For simplicity, IPv4 address
   is used for this purpose.

   Compartment-ID is the identifier of the *compressor* compartment that
   the *sending* endpoint used to compress this message.  It is assigned
   by the sender and therefore only unique per sending endpoint.  I.e.,
   DAP messages sent by different endpoints may carry same
   compartment-ID.  Therefore, the receiver should use the (endpoint-ID,
   compartment-ID) pair carried in a message to determine the
   decompressor compartment identifier for that message.  The exact
   local representation of the derived compartment identifier is an
   implementation choice.

   To test SigComp feedback [1], peer compartments between two endpoints
   are defined in DAP as those with the same compartment-ID.  For
   example, (endpoint-A, 1) and (endpoint-B, 1) are peer compartments.
   That means, SigComp feedback for a DAP message sent from compartment
   1 of endpoint-A to endpoint-B must be piggybacked on a DAP message
   sent from compartment 1 of endpoint-B to endpoint-A.

   A DAP receiver will follow the instruction carried in header line-5
   to either accept or reject a DAP message.  Note: line-6 and line-7
   will be ignored if the message is rejected.

   A DAP receiver will follow the instruction in line-6 to create or
   close the decompressor compartment that is associated with the
   received DAP message (see above).

   If the header line-7 of a received DAP message carries "TRUE", the
   receiver will send back a response message to the sender.  This
   allows the test of SigComp feedback.  As mentioned above, the
   response message must be compressed by, and sent from, the local
   compressor compartment that is peer of the remote compressor
   compartment.  Other than this constraint, the response message is
   just a regular DAP message that can carry arbitrary message-header
   and message-body.  For example, the "need-response" field of the
   response can also be set to TRUE, which will trigger a response to
   response, and so on.  Note that since either endpoint has control
   over the "need-response" field of its own messages, this does not
   lead to a dead loop.  A sensible implementation of a DAP sender must
   not blindly set this field to TRUE unless a response is desired.  For
   testing, the message-body of a response may contain the message-
   header of the original message that triggered the response.

   Message-seq can be used by a DAP sender to track each message it
   sends, e.g. in case of losses.  Message loss can happen either on the
   path or at the receiving endpoint (i.e. due to decompression
   failure).  The assignment of message-seq is up to the sender.  For



Surtees, et al.           Expires April 5, 2007                [Page 21]


Internet-Draft       Implementer's Guide for SigComp        October 2006


   example, it could be either assigned per compartment or per endpoint.
   This has no impact on the receiving side.

A.3  DAP message format in ABNF

   (Note: see (ABNF) [8] for basic rules.)
      DAP-message = message-header CRLF [ message-body ]

      message-body = *OCTET

      message-header = line-1 line-2 line-3 line-4 line-5 line-6 line-7
      line-8

      line-1 = "DAP-version" ":" 1*DIGIT CRLF
      line-2 = "endpoint-ID" ":" IPv4address CRLF
      line-3 = "compartment-ID" ":" 1*DIGIT CRLF
      line-4 = "message-seq" ":" 1*DIGIT CRLF
      line-5 = "message-auth" ":" ( "ACCEPT" / "REJECT" ) CRLF
      line-6 = "compartment-op" ":" ( "CREATE" / "CLOSE" / "NONE" ) CRLF
      line-7 = "need-response" ":" ( "TRUE" / "FALSE" )
      line-8 = "body-length" ":" 1*DIGIT CRLF

      IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT

A.4  An example of a DAP message
      DAP-version: 1
      endpoint-ID: 123.45.67.89
      compartment-ID: 2
      message-seq: 0
      message-auth: ACCEPT
      compartment-op: CREATE
      need-response: TRUE
      body-length: 228

   This is a DAP message sent from SigComp endpoint at IP address
   123.45.67.89.  This is the first message sent from compartment 2.
   Please accept the message, create the associated compartment, and
   send back a response message.













Surtees, et al.           Expires April 5, 2007                [Page 22]


Internet-Draft       Implementer's Guide for SigComp        October 2006


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 (2006).  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.




Surtees, et al.           Expires April 5, 2007                [Page 23]


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