Network Working Group A. Surtees
Internet-Draft M. West
Expires: January 17, 2005 Siemens/Roke Manor
A. Roach
dynamicsoft
July 19, 2004
Implementer's Guide for SigComp
draft-ietf-rohc-sigcomp-impl-guide-03.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.
This Internet-Draft will expire on January 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). 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 January 17, 2005 [Page 1]
Internet-Draft Implementer's Guide for SigComp July 2004
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
4.1 Instructions That Use Byte Copying Rules . . . . . . . . . . . 5
5. State Retention Priority . . . . . . . . . . . . . . . . . . . 6
5.1 Priority Values . . . . . . . . . . . . . . . . . . . . . . . 6
5.2 Multiple State Retention Priorities . . . . . . . . . . . . . 6
6. Duplicate State . . . . . . . . . . . . . . . . . . . . . . . 7
7. The I-bit in Requested Feedback . . . . . . . . . . . . . . . 7
8. Feedback when SMS is zero . . . . . . . . . . . . . . . . . . 7
9. Dynamic Update of Resources . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
A. Dummy Application Protocol (DAP) . . . . . . . . . . . . . . . 10
A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 10
A.2 Processing a DAP message . . . . . . . . . . . . . . . . . . . 10
A.3 DAP message format in ABNF . . . . . . . . . . . . . . . . . . 12
A.4 An example of a DAP message . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
Surtees, et al. Expires January 17, 2005 [Page 2]
Internet-Draft Implementer's Guide for SigComp July 2004
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 January 17, 2005 [Page 3]
Internet-Draft Implementer's Guide for SigComp July 2004
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 January 17, 2005 [Page 4]
Internet-Draft Implementer's Guide for SigComp July 2004
free state either from another compartment or that is not associated
with a compartment has no effect.
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
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
Surtees, et al. Expires January 17, 2005 [Page 5]
Internet-Draft Implementer's Guide for SigComp July 2004
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
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.)
Surtees, et al. Expires January 17, 2005 [Page 6]
Internet-Draft Implementer's Guide for SigComp July 2004
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.
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. 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.
8. 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. 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
Surtees, et al. Expires January 17, 2005 [Page 7]
Internet-Draft Implementer's Guide for SigComp July 2004
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
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. 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].
11. 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.,
Surtees, et al. Expires January 17, 2005 [Page 8]
Internet-Draft Implementer's Guide for SigComp July 2004
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.
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications (ABNF)", RFC 2234, November 1997.
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 January 17, 2005 [Page 9]
Internet-Draft Implementer's Guide for SigComp July 2004
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) [5]. 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
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
Surtees, et al. Expires January 17, 2005 [Page 10]
Internet-Draft Implementer's Guide for SigComp July 2004
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
example, it could be either assigned per compartment or per endpoint.
This has no impact on the receiving side.
Surtees, et al. Expires January 17, 2005 [Page 11]
Internet-Draft Implementer's Guide for SigComp July 2004
A.3 DAP message format in ABNF
(Note: see (ABNF) [5] 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 January 17, 2005 [Page 12]
Internet-Draft Implementer's Guide for SigComp July 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 January 17, 2005.
Surtees, et al. Expires January 17, 2005 [Page 13]
