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

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

Network Working Group                                         A. Surtees
Internet-Draft                                                   M. West
Expires: June 21, 2004                                Siemens/Roke Manor
                                                                A. Roach
                                                             dynamicsoft
                                                       December 22, 2003


                    Implementer's Guide for SigComp
               draft-ietf-rohc-sigcomp-impl-guide-02.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

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

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



Surtees, et al.           Expires June 21, 2004                 [Page 1]


Internet-Draft       Implementer's Guide for SigComp       December 2003


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 STATE-FREE . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Byte Copying Rules . . . . . . . . . . . . . . . . . . . . . .  5
   5.  State Retention Priority . . . . . . . . . . . . . . . . . . .  5
   5.1 Priority Values  . . . . . . . . . . . . . . . . . . . . . . .  5
   5.2 Multiple State Retention Priorities  . . . . . . . . . . . . .  5
   6.  The I-bit in Requested Feedback  . . . . . . . . . . . . . . .  6
   7.  Feedback when SMS is zero  . . . . . . . . . . . . . . . . . .  6
   8.  Dynamic Update of Resources  . . . . . . . . . . . . . . . . .  6
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
       References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  8
       Full Copyright Statement . . . . . . . . . . . . . . . . . . .  9






























Surtees, et al.           Expires June 21, 2004                 [Page 2]


Internet-Draft       Implementer's Guide for SigComp       December 2003


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
   damaging effect on the compression ratio; for others, it makes it



Surtees, et al.           Expires June 21, 2004                 [Page 3]


Internet-Draft       Implementer's Guide for SigComp       December 2003


   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 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



Surtees, et al.           Expires June 21, 2004                 [Page 4]


Internet-Draft       Implementer's Guide for SigComp       December 2003


   free state either from another compartment or that is locally
   available has no effect.

4. 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
   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).

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
      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



Surtees, et al.           Expires June 21, 2004                 [Page 5]


Internet-Draft       Implementer's Guide for SigComp       December 2003


      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.


6. The I-bit in Requested Feedback

   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.

7. 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.

8. 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
   resources.  Note that the compressor SMS is unofficial (enables
   compressor to monitor decompressor state) and is separate from the



Surtees, et al.           Expires June 21, 2004                 [Page 6]


Internet-Draft       Implementer's Guide for SigComp       December 2003


   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.

9. 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].

10. 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@eth.ericsson.se)
      Timo Forsman (timo.forsman@xt.etx.ericsson.se)
      Tor-Erik Malen (tor-erik.malen@lmf.ericsson.se)
      Jan Christoffersson (jan.christoffersson@epl.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.

References

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

   [2]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "Session
        Initiation Protocol (SIP)", RFC 3261, June 2002.

   [3]  Bradner, S., "The Internet Standards Process -- Revision 3", RFC
        2026, October 1996.

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



Surtees, et al.           Expires June 21, 2004                 [Page 7]


Internet-Draft       Implementer's Guide for SigComp       December 2003


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


   Adam Roach
   dynamicsoft
   5100 Tennyson Pkwy
   Suite 1200, Plano  TX 75024
   US

   Phone: +1 972 473 2233
   EMail: adam@dynamicsoft.com
   URI:   http://www.dynamicsoft.com


















Surtees, et al.           Expires June 21, 2004                 [Page 8]


Internet-Draft       Implementer's Guide for SigComp       December 2003


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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

This Internet-Draft will expire on June 21, 2004.



















Surtees, et al.           Expires June 21, 2004                 [Page 9]


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