Network Working Group Zhigang Liu
INTERNET-DRAFT Nokia
Expires: May 2003 November 1, 2002
A Recovery Mechanism for Signaling Compression
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 document is a submission to the IETF ROHC WG. Comments should be
directed to its mailing list, rohc@ietf.org.
Abstract
This document defines a recovery mechanism for signaling compression
(SigComp). It allows a decompressor to signal to its peer compressor
in case it has lost synchronization with the compressor. The
compressor can thereafter take appropriate recovery actions. The
signals are carried using the state announcement mechanism as defined
in SigComp.
Liu [Page 1]
INTERNET-DRAFT SigComp Recovery November 1, 2002
1. Introduction
[SIGCOMP] defines a solution for compressing messages generated by
application protocols such as SIP [RFC-3261] and RTSP [RFC-2326]. To
guarantee successful decompression, the compressor and decompressor
must maintain synchronization on states. [SIGCOMP-EXT] describes a
few mechanisms (e.g. acknowledgments, checkpoint state) that can be
used for this purpose. However, there are still certain scenarios
that cannot be handled by current SigComp specification. For example,
if a decompressor loses some or all of its states due to a sudden
shortage of memory, memory corruption or even crash, there is no
standardized mechanism in SigComp that allows the decompressor to
inform the loss of synchronization to its peer compressor. This
document introduces a solution to address the problem.
2. Discussions in the Past
The issue has been discussed during the development of SigComp. A
few solutions were proposed which did not require work within
SigComp.
1) Sender timeout and retransmission. Usually, a signaling protocol
has the request-response message sequence. If the sender has not
received a response to a compressed message sent earlier after
certain timeout period, it may assume the compressed message was
lost or corrupted and retransmit the compressed message. It
repeats this for N timeout periods. After that, it may assume the
reason of not receiving a response is decompression failure due to
loss of synchronization. It can then start resynchronization
procedure (e.g. re-upload states). Before the procedure is
finished, it can either compresses subsequent messages by using
only static dictionary [SIP-DICT], or it can send them
uncompressed.
One fundamental problem with above solution is that there are many
possible reasons for the sender not to receive the expected
response: a) the compressed message sent by the sender is lost; b)
the compressed message is corrupted and thus causes decompression
failure; c) decompressor loses synchronization and therefore
cannot decompress; and d) the response message is lost. The sender
simply cannot tell which case it is dealing with. In the case when
a loss of synchronization indeed happened, the sender still
blindly performs N retransmissions of compressed messages which
are deemed to be discarded by the receiver. This leads to
unnecessary delay. Note that setting N to 1 does not solve the
problem either as that means all the other cases will be
incorrectly treated as loss of synchronization. The consequence is
Liu [Page 2]
INTERNET-DRAFT SigComp Recovery November 1, 2002
lower compression ratio and higher transmission latency.
2) Signal the loss of synchronization outside of SigComp, e.g. at
application layer. This simplifies SigComp. However, it means
extra standardization work at application layer. In particular, it
may require modifications to existing specifications. Since the
synchronization problem is introduced at SigComp layer, it would
be good to have the problem resolved within SigComp. This will
ease the deployment of SigComp into various application
environments.
3. Solution Within SigComp
Essentially, all we need is an in-band (i.e. within SigComp layer)
signaling mechanism that allows decompressor to inform its peer
compressor when a loss of synchronization has happened. This can be
done by using the state announcement mechanism that already exists in
current SigComp specification.
3.1. Sending Signals Using State Announcement
[SIGCOMP] defines a state announcement mechanism that allows a
SigComp endpoint to announce its locally available states to any
remote endpoints. Basically, the announcing endpoint can encode a
list of partial state identifiers for those locally available states
as part of the returned SigComp parameters ([SIGCOMP], section
9.4.9). A state identifier is the (SHA-1) cryptographic hash
calculated over the state. When a remote endpoint receives such an
announcement, it can use those locally available states to compress
messages sent to the announcing endpoint. This makes it possible to
improve compression efficiency without the need of actually uploading
those states, assuming that the content of those states are known by
the receiving endpoint out of band, e.g. pre-defined in a published
document.
We can use the above mechanism to send signals as follows.
- For each signal, define a locally available state that maps to
it. Details will be given below.
- To send a signal, a SigComp endpoint simply announces the
corresponding state following the state announcement procedure.
- When receiving a state announcement, the receiving SigComp
endpoint will check the (partial) state identifier received
against those of known states that are defined for signaling
Liu [Page 3]
INTERNET-DRAFT SigComp Recovery November 1, 2002
purpose. If a match is found, the endpoint will translate the
state announcement back to the signal semantics it carries.
The definition of a state for signaling purpose can be quite
arbitrary. However, one key requirement is that it must be globally
unique and cannot be easily generated by accident. This is to
guarantee the interoperability with those SigComp endpoints that are
unaware of this document. Namely, they simply discard the received
state announcement since they cannot find the corresponding state.
The uniqueness of a state can be achieved by adding a "random salt"
to the state value. In general, the length of a random salt should be
at least 20 bytes (the length of a state identifier).
Note: a SigComp endpoint does not need to store the states themselves
defined for signaling purpose. That is because only state identifier
is of significance to derive the corresponding signal.
The advantages of this approach:
- It does not require any changes to current SigComp
specification.
- There are no interoperability issues (see above). Of course, if
a SigComp endpoint is not aware of a particular state, the
signals embedded in the state announcement will be discarded.
- The signal can be either piggybacked on a compressed
application message or sent in a standalone SigComp message
(i.e. without application message). The former is required
under the generic security model of [SIGCOMP]. The latter is
allowed if the receiving endpoint has means to authenticate the
standalone message, e.g. when SigComp runs over IPsec as in the
case of 3GPP.
- Extensibility. New signals can be easily added by defining new
states.
Disadvantages:
- Slight overhead at SigComp endpoints. An endpoint needs to
store 20 bytes state identifier for each signal. However, the
overhead is negligible in practice, considering that a mobile
phone nowadays can easily store 200 entries in its "phone book"
and each entry can be tens of characters long.
- Overhead on the wire. This depends on how the state
announcement is implemented. A simple implementation that
sends the (partial) state identifiers explicitly in a SigComp
Liu [Page 4]
INTERNET-DRAFT SigComp Recovery November 1, 2002
message will cost 6 - 20 bytes per signal. However, a smarter
implementation may upload a byte code that can parse some bit
flags in a SigComp message and generate the state announcement
locally according to the bit flags. In that case, the overhead
on the wire is 1 bit per signal plus the one time cost of
uploading the byte code. Either way, the signals are only sent
for abnormal situations that should not occur frequently.
Therefore, the overhead on the wire is an insignificant factor.
3.2. Proposed Recovery Mechanism
To address the loss of synchronization problem, we propose to
standardize a RESET signal that can be carried by state announcement
as described in previous section.
Specifically, we define the following two states for RESET signal.
One is to signal RESET at endpoint level and another one at
compartment level.
1) "RESET-endpoint" state
- State definition. The state_value consists of a 22-byte text
string "SigComp-RESET-endpoint" followed a random salt of 34 bytes
long. The state_length is chosen such that the total size of the
state (for the purpose of state identifier calculation) is 64
bytes - the block size of SHA-1[PUB-180-1]. This avoids the
padding.
Name: Value:
===================== ========================
state_identifier 0x4B7ECDE7DA493EB3430C67ACA230B99F58FE9DB3
state_length 0x0038
state_address 0x0000 (not relevant for the dictionary)
state_instruction 0x0000 (not relevant for the dictionary)
minimum_access_length 0x0006
state_value see below
0000 5369 6743 6F6D 702D 5245 5345 542D 656E SigComp-RESET-en
0010 6470 6F69 6E74 88C3 B6D1 A3AB 09A0 373C dpoint........7<
0020 4BBA 30DC 729C 91E9 B3C3 F0E5 DD40 52B6 K.0.r........@R.
0030 B746 844F EBE5 55C2 .F.O..U.
- Signal semantics. The signal indicates that the sending SigComp
endpoint has lost all states except the following: a) any
mandatory static states; and b) any locally available states that
are announced together in the same message that carries this
Liu [Page 5]
INTERNET-DRAFT SigComp Recovery November 1, 2002
signal. The SigComp endpoint that receives the signal should take
appropriate recovery actions accordingly. For example, it may re-
upload dynamic states and in the meanwhile it should send
application messages uncompressed or compressed only using those
states as described in a) and b).
2) "RESET-compartment" state
- State definition. The state_value consists of a 25-byte text
string "SigComp-RESET-compartment" followed by a random salt of 31
bytes long.
Name: Value:
===================== ========================
state_identifier 0x0A7DC62D273EB06020AC06AD7DA9CFCB61D9AD6E
state_length 0x0038
state_address 0x0000 (not relevant for the dictionary)
state_instruction 0x0000 (not relevant for the dictionary)
minimum_access_length 0x0006
state_value see below
0000 5369 6743 6F6D 702D 5245 5345 542D 636F SigComp-RESET-co
0010 6D70 6172 746D 656E 747F 1ABB 6011 C4BE mpartment...`...
0020 86D7 E632 7BC8 1BB7 768B 746C C203 FE95 ...2{...v.tl....
0030 EDD1 D31C 718F 860B ....q...
- Signal semantics. The signal has the same meaning as that of
RESET-endpoint with one important exception: it indicates the
sending SigComp endpoint has only lost states saved in the
compartment from which the announcement is sent. In other words,
it does not carry any information about states that have been
saved in other compartments. The SigComp endpoint that receives
the signal can identify the announcing compartment in the same way
as described in [SIGCOMP]. Namely, if the signal is piggybacked on
a (compressed) application message, the compartment identifier
will be provided by the application. If the signal is sent in a
standalone SigComp message, that means there already exists other
means (e.g. IPsec) that can authenticate the message and provide
the compartment identifier. Otherwise, a standalone SigComp
message would not have been allowed in the first place.
Note: which level of RESET signal to use depends on the particular
scenario where synchronization of states is lost. Obviously, it does
not make sense for a SigComp endpoint to signal RESET at both levels
simultaneously. In case that happens, the RESET-compartment signal
will be ignored by the receiving endpoint.
Liu [Page 6]
INTERNET-DRAFT SigComp Recovery November 1, 2002
Note: even though the explicit RESET signal allows a SigComp endpoint
to indicate a loss of synchronization, it is still recommended that
the sender timeout and retransmission as described in previous
section be implemented as a fallback. That is needed when a SigComp
endpoint aware of this document communicates with a SigComp endpoint
unaware of this document.
Note: the recovery mechanism defined here is complementary to the
synchronization mechanisms already described in [SIGCOMP] and
[SIGCOMP-EXT].
Note: if needed, more signals can be defined under the same
framework.
4. Security Considerations
The mechanism described in this document is believed not to add any
security risks to those mentioned in [SIGCOMP].
5. IANA Considerations
This document does not require any IANA involvement.
6. Intellectual Property Right Notice
On IPR related issues, Nokia refers to its statement on patent
licensing. Please see http://www.ietf.org/ietf/IPR/NOKIA.
7. References
[SIGCOMP] Price, et al., "Signaling Compression", <draft-ietf-
rohc-sigcomp-07.txt> (work in progress), Internet
Engineering Task Force, June 2002.
[SIGCOMP-EXT] Hannu, et al., "SigComp - Extended Operations", <draft-
ietf-rohc-sigcomp-extended-04.txt> (work in progress),
Internet Engineering Task Force, June 2002.
[RFC-3261] Rosenberg, et al., "SIP: Session Initiation Protocol",
RFC 3261, Internet Engineering Task Force, June 2002.
[RFC-2326] H. Schulzrinne, A. Rao and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, Internet
Liu [Page 7]
INTERNET-DRAFT SigComp Recovery November 1, 2002
Engineering Task Force, April 1998.
[SIP-DICT] Garcia, et al., "The Session Initiation Protocol (SIP)
and Session Description Protocol (SDP) static
dictionary for Signaling Compression (SigComp)",
<draft-ietf-sipping-sigcomp-sip-dictionary-04.txt>
(work in progress), Internet Engineering Task Force,
August 2002.
[PUB-180-1] NIST, "FIPS PUB 180-1: Secure Hash Standard", April
1995.
8. Authors' Addresses
Zhigang Liu
Nokia Research Center Phone: +1 972 894-5935
6000 Connection Drive Fax: +1 972 894-4589
Irving, TX 75039 E-mail: zhigang.c.liu@nokia.com
USA
9. Full copyright statement
Copyright (C) The Internet Society (2002). 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
Liu [Page 8]
INTERNET-DRAFT SigComp Recovery November 1, 2002
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires May 1, 2003.
Liu [Page 9]