draft-ietf-rohc-sigcomp-sip-01.txt   draft-ietf-rohc-sigcomp-sip-02.txt 
Robust Header Compression C. Bormann, Ed.
Network Working Group Zhigang Liu, Editor, Nokia Internet-Draft Universitaet Bremen TZI
INTERNET-DRAFT Richard Price, Siemens/Roke Manor Expires: August 18, 2006 Z. Liu
Expires: August 12, 2004 Nokia Research Center
February 12, 2004 R. Price
Cogent Defence and Security
Networks
G. Camarillo
Ericsson
February 14, 2006
Applying Signaling Compression (SigComp) to the Session Initiation Applying Signaling Compression (SigComp) to the Session Initiation
Protocol (SIP) Protocol (SIP)
<draft-ietf-rohc-sigcomp-sip-01.txt> draft-ietf-rohc-sigcomp-sip-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, each author represents that any
all provisions of Section 10 of RFC2026. 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a submission of the IETF ROHC WG. Comments should be This Internet-Draft will expire on August 18, 2006.
directed to its mailing list, rohc@ietf.org.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes some specifics when Signaling Compression This document describes some specifics that apply when Signaling
(SigComp) is applied to the Session Initiation Protocol (SIP), such Compression (SigComp) is applied to the Session Initiation Protocol
as default minimum values of SigComp parameters, compartment and (SIP), such as default minimum values of SigComp parameters,
state management, and few issues on SigComp over TCP. Any compartment and state management, and a few issues on SigComp over
implementation of SigComp for use with SIP must conform to this TCP. Any implementation of SigComp for use with SIP must conform to
document, in addition to SigComp and support of the SIP and Session this document, in addition to SigComp and support of the SIP and
Description Protocol (SDP) static dictionary. Session Description Protocol (SDP) static dictionary.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Minimum Values of SigComp Parameters for SIP/SigComp . . . . . 3
3.1. decompression_memory_size (DMS) for SIP/SigComp . . . . . 4
3.2. state_memory_size (SMS) for SIP/SigComp . . . . . . . . . 4
3.3. cycles_per_bit (CPB) for SIP/SigComp . . . . . . . . . . . 5
3.4. SigComp_version (SV) for SIP/SigComp . . . . . . . . . . . 5
3.5. locally available state (LAS) for SIP/SigComp . . . . . . 5
4. Delimiting SIP Messages and SigComp Messages on the Same
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Continuous Mode over TCP . . . . . . . . . . . . . . . . . . . 6
6. Compartment and State Management for SIP/SigComp . . . . . . . 7
6.1. Remote Application Identifiers . . . . . . . . . . . . . . 7
6.2. Compartment Opening and Closure . . . . . . . . . . . . . 7
6.3. Compartment Valid During a Transaction . . . . . . . . . . 9
6.4. Compartment Valid During a Registration . . . . . . . . . 9
6.5. Compartment Valid During a Dialog . . . . . . . . . . . . 10
7. Recommendations for Network Administrators . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Private Agreements . . . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
12. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Shim header for sending uncompressed messages . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
SigComp [RFC-3320] is a solution for compressing messages generated SigComp [RFC3320] is a solution for compressing messages generated by
by application protocols. Although its primary driver is to compress application protocols. Although its primary driver is to compress
SIP messages, the solution itself has been intentionally designed to SIP [RFC3261] messages, the solution itself has been intentionally
be application agnostic so that it can be applied to any application designed to be application agnostic so that it can be applied to any
protocols. (This is denoted as ANY/SigComp.) Consequently, many application protocol. (This is denoted as ANY/SigComp.)
application dependent specifics are left out. It is intended that a Consequently, many application dependent specifics are left out of
separate document will be needed to describe those specifics when the base standard. It is intended that a separate specification is
SigComp is applied to a particular application protocol. used to describe those specifics when SigComp is applied to a
particular application protocol.
This document binds SigComp and SIP (denoted as SIP/SigComp). Any This document binds SigComp and SIP (denoted as SIP/SigComp). Any
SigComp implementation that is used for the compression of SIP SigComp implementation that is used for the compression of SIP
messages must conform to this document, as well as to SigComp messages must conform to this document, as well as to [RFC3320] and
[RFC-3320] and must support the SIP/SDP static dictionary as must support the SIP/SDP static dictionary as specified in [RFC3485].
specified in [RFC-3485].
Note: the mechanism of discovering SigComp support at SIP layer is Note: the mechanism of discovering SigComp support at the SIP layer
specified in [RFC-3486]. is specified in [RFC3486].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14 [RFC2119].
[RFC-2119].
2. Minimum Values of SigComp Parameters for SIP/SigComp 3. Minimum Values of SigComp Parameters for SIP/SigComp
In order to support a wide range of capabilities among endpoints In order to support a wide range of capabilities among endpoints
implementing SigComp, SigComp defines a few parameters to describe implementing SigComp, SigComp defines a few parameters to describe
SigComp behaviour (see section 3.3 of [RFC-3320]). For each SigComp behavior (see section 3.3 of [RFC3320]). For each parameter,
parameter, [RFC-3320] specifies a minimum value that any SigComp [RFC3320] specifies a minimum value that any SigComp endpoint MUST
endpoint MUST support for ANY/SigComp. Those minimum values were support for ANY/SigComp. Those minimum values were determined with
determined with the consideration of all imaginable devices in which the consideration of all imaginable devices in which SigComp may be
SigComp may be implemented. Scalability was also considered as a key implemented. Scalability was also considered as a key factor.
factor.
However, some of the minimum values specified in [RFC-3320] are too However, some of the minimum values specified in [RFC3320] are too
small to allow good performance for SIP message compression. small to allow good performance for SIP message compression.
Therefore, they are increased for SIP/SigComp as specified in the Therefore, they are increased for SIP/SigComp as specified in the
following sections. For completeness, those parameters that are the following sections. For completeness, those parameters that are the
same for SIP/SigComp as they are for ANY/SigComp are also listed. same for SIP/SigComp as they are for ANY/SigComp are also listed.
Note: the new minimum values are specific to SIP/SigComp. They do not Note: the new minimum values are specific to SIP/SigComp. They do
apply to any other application protocols. not apply to any other application protocols.
Note: a SigComp endpoint MAY offer additional resources if available; Note: a SigComp endpoint MAY offer additional resources if available;
these resources can be advertised to remote endpoints as described in these resources can be advertised to remote endpoints as described in
section 9.4.9 of [RFC-3320]. section 9.4.9 of [RFC3320].
2.1. decompression_memory_size (DMS) for SIP/SigComp 3.1. decompression_memory_size (DMS) for SIP/SigComp
Minimum value for ANY/SigComp: 2048 bytes, as specified in section Minimum value for ANY/SigComp: 2048 bytes, as specified in section
3.3.1 of [RFC-3320]. 3.3.1 of [RFC3320].
Minimum value for SIP/SigComp: 8192 bytes. Minimum value for SIP/SigComp: 8192 bytes.
Reason: DMS of 2048 bytes is too small for SIP message compression, Reason: a DMS of 2048 bytes is too small for SIP message compression,
as it seriously limits the compression ratio and even makes as it seriously limits the compression ratio and even makes
compression impossible for certain messages. For example, the compression impossible for certain messages. For example, the
condition set by [RFC-3320] for SigComp over UDP means: C + 2*B + R + condition set by [RFC3320] for SigComp over UDP means: C + 2*B + R +
2*S + 128 < DMS (each term is described below). On the other hand, 2*S + 128 < DMS (each term is described below). On the other hand,
8KB additional memory should not cause any problem for an endpoint 8KB additional memory should not cause any problem for an endpoint
that implements SIP, SigComp, and applications that use SIP. that already implements SIP, SigComp, and applications that use SIP,
as DMS is memory only temporarily needed during decompression of a
SigComp message (the memory can be reclaimed when the message has
been decompressed).
C = size of compressed application message, depending on R. C size of compressed application message, depending on R
B = size of bytecode (note: two copies - one as part of SigComp B size of bytecode (note: two copies -- one as part of the SigComp
message and one in UDVM memory) message and one in UDVM memory)
R = size of ring buffer in UDVM memory R size of ring buffer in UDVM memory
S = any additional state uploaded other than that created from the S any additional state uploaded other than that created from the
content of the ring buffer at the end of decompression. Similar content of the ring buffer at the end of decompression (similar to
to B, two copies of S are needed B, two copies of S are needed)
128 = the smallest address in UDVM memory to copy bytecode 128 the smallest address in UDVM memory to copy bytecode to
Note: DMS is per SigComp message and the memory can be reclaimed
after the message has been decompressed.
2.2. state_memory_size (SMS) for SIP/SigComp 3.2. state_memory_size (SMS) for SIP/SigComp
Minimum value for ANY/SigComp: 0 (zero) bytes, as specified in Minimum value for ANY/SigComp: 0 (zero) bytes, as specified in
section 3.3.1 of [RFC-3320]. section 3.3.1 of [RFC3320].
Minimum value for SIP/SigComp: 2048 bytes. Minimum value for SIP/SigComp: 2048 bytes.
Reason: a non-zero SMS allows an endpoint to upload a state in the Reason: a non-zero SMS allows an endpoint to upload a state in the
first SIP message sent to a remote endpoint without the uncertainty first SIP message sent to a remote endpoint without the uncertainty
of whether or not it can be created in the remote endpoint due to of whether or not it can be created in the remote endpoint. A non-
lack of memory. zero SMS obviously requires the SIP/SigComp implementation to keep
state. Based on the observation that there is little gain from
stateless SigComp compression, the assumption is that purely
stateless SIP implementations are unlikely to provide a SigComp
function. Stateful implementations should have little problem to
keep 2K additional state for each compartment (see Section 6).
Note: SMS is per compartment. An endpoint MAY offer different SMS for Note: SMS is a parameter that applies to each individual compartment.
different compartments as long as the SMS is not less than 2048
bytes.
[Editor's note: this would prevent the use of SigComp in conjunction An endpoint MAY offer different SMS values for different compartments
with stateless SIP proxies. Is this acceptable? Discussions on as long as the SMS value is not less than 2048 bytes.
benefit/cost are ongoing in the ROHC mailing list.]
2.3. cycles_per_bit (CPB) for SIP/SigComp Compressors that make use of initial state memory MUST implement the
SigComp Negative Acknowledgement (NACK) Mechanism [I-D.ietf-rohc-
sigcomp-nack]. (Note that there is no such requirement on
decompressors, but see also Section 6.) For this requirement,
initial state memory is defined as the assumption of a non-zero SMS
value before having received an advertisement of non-zero SMS (e.g.,
via returned parameters as specified in section 9.4.9 of [RFC3320]);
ANY/SigComp as defined in [RFC3320] does not have initial state
memory.
3.3. cycles_per_bit (CPB) for SIP/SigComp
Minimum value for ANY/SigComp: 16, as specified in section 3.3.1 of Minimum value for ANY/SigComp: 16, as specified in section 3.3.1 of
[RFC-3320]. [RFC3320].
Minimum value for SIP/SigComp: 16 (same as above) Minimum value for SIP/SigComp: 16 (same as above)
2.4. SigComp_version (SV) for SIP/SigComp 3.4. SigComp_version (SV) for SIP/SigComp
For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC-3320].
For SIP/SigComp: 0x01 (same as above)
2.5. locally available state (LAS) for SIP/SigComp
Minimum LAS for ANY/SigComp: none, see section 3.3.3 of [RFC-3320]
Minimum LAS for SIP/SigComp: the SIP/SDP static dictionary as defined
in [RFC-3485].
3. Compartment and State Management for SIP/SigComp
When SigComp is applied to SIP, there is a one-to-one relationship For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC3320].
between a SIP dialog (see section 12 of [RFC-3261]) and a pair of
peer SigComp compartments. The mapping is handled by SIP (not
SigComp) as follows:
- When a SIP user agent client (UAC) compresses and sends a request OPEN ISSUE: what SigComp version(s) should be required for SIP/
that can establish a dialog (such as INVITE), it creates a SigComp?
compartment associated with the dialog.
- When a SIP user agent server (UAS) receives a compressed request Version >= 0x01 (i.e. any SigComp)
and decides to respond with a response that establishes a dialog Version >= 0x02 (i.e. at least SigComp + NACK)
(such as a 2xx to INVITE), it creates a compartment associated with Version == 0x01 | 0x02 (base SigComp or SigComp + NACK)
the dialog. Version == 0x02 (only SigComp with NACK)
- Conceptually, the SIP layer of each SigComp endpoint uses the For SIP/SigComp: 0x01 (same as above)
dialog ID as the SigComp compartment ID for the compartment
associated with the dialog. However, the actual representation of
the compartment ID is a local implementation issue. The only
requirement is to maintain a local one-to-one mapping between a
dialog ID and a compartment ID.
- A SigComp compartment will be closed by SIP when the corresponding 3.5. locally available state (LAS) for SIP/SigComp
dialog is terminated.
Usually, any states created during the lifetime of a compartment will Minimum LAS for ANY/SigComp: none, see section 3.3.3 of [RFC3320].
be "logically" deleted when the compartment is closed. A logical
deletion becomes a physical one when all the compartments that
created the (same) state are closed. However, a SigComp endpoint may
offer to keep a state created upon request from its peer endpoint
during a dialog beyond the duration of that dialog. This may improve
compression efficiency of SIP messages generated by the same peer
endpoint in subsequent dialogs. In that case, it can inform its peer
SigComp endpoint by announcing the (partial) state ID in the returned
SigComp parameters at the end of the dialog. That signals the state
will be maintained until the associated timer times out. Since there
is no mechanism in SigComp and SIP to convey the timeout value, a
default value needs to be specified [Editor's note: actual value will
be determined later]. The default value can be overwritten by
different means in a particular SIP configuration so long as the
value is known to and agreed by all SigComp endpoints involved. If
one SigComp endpoint is a SIP registrar server and its peer endpoints
register with it, the lifetime of the state can be specified to be
the same as that of the registration.
[Editor's note: this is more complicated than it appears. Above is Minimum LAS for SIP/SigComp: the SIP/SDP static dictionary as defined
only preliminary text serving as a starting point. There are in [RFC3485].
improvements and alternatives being discussed in the ROHC WG.]
4. Delimiting SIP Messages and SigComp Messages on the Same Port 4. Delimiting SIP Messages and SigComp Messages on the Same Port
In order to limit the number of ports required by a SigComp-aware In order to limit the number of ports required by a SigComp-aware
endpoint, it is possible to multiplex SigComp messages and 'vanilla' endpoint, it is possible to allow both SigComp messages and 'vanilla'
SIP messages (i.e. uncompressed SIP messages with no SigComp header) SIP messages (i.e. uncompressed SIP messages with no SigComp header)
on the same port. to arrive on the same port.
For a message-based transport such as UDP, the receiving endpoint For a message-based transport such as UDP or SCTP, this can be done
checks the first octet of the UDP payload to determine whether the per message. The receiving endpoint checks the first octet of the
message has been compressed using SigComp. If the MSBs of the octet UDP/SCTP payload to determine whether the message has been compressed
are "11111" then the message is considered to be a SigComp message using SigComp. If the MSBs of the octet are "11111" then the message
and is parsed as per [RFC-3320]. If the MSBs of the octet take any is considered to be a SigComp message and is parsed as per [RFC3320].
other value, then the message is assumed to be an uncompressed SIP If the MSBs of the octet take any other value, then the message is
message, and is passed directly to the application with no further assumed to be an uncompressed SIP message, and is passed directly to
effect on the SigComp layer. the application with no further effect on the SigComp layer.
For a stream-based transport such as TCP, the receiving endpoint For a stream-based transport such as TCP, the distinction is per
checks the first octet of the TCP data stream to determine whether connection. The receiving endpoint checks the first octet of the TCP
the stream has been compressed using SigComp. If the MSBs of the data stream to determine whether the stream has been compressed using
octet are "11111" then the stream is considered to contain SigComp SigComp. If the MSBs of the octet are "11111" then the stream is
messages and is parsed as per [RFC-3320]. If the MSBs of the octet considered to contain SigComp messages and is parsed as per
take any other value, then the stream is assumed to contain [RFC3320]. If the MSBs of the octet take any other value, then the
uncompressed SIP messages, and is passed directly to the application stream is assumed to contain uncompressed SIP messages, and is passed
with no further effect on the SigComp layer. Note that SigComp directly to the application with no further effect on the SigComp
message delimiters MUST NOT be used if the stream contains layer. Note that SigComp message delimiters MUST NOT be used if the
uncompressed SIP messages. stream contains uncompressed SIP messages.
Applications MUST NOT mix SIP messages and SigComp messages on a Applications MUST NOT mix SIP messages and SigComp messages on a
single TCP connection. If the TCP connection is used to carry single TCP connection. If the TCP connection is used to carry
SigComp messages then all messages sent over the connection MUST have SigComp messages then all messages sent over the connection MUST have
a SigComp header and be delimited by the use of 0xFFFF as described a SigComp header and be delimited by the use of 0xFFFF as described
in [RFC 3320]. in [RFC 3320].
[Editor's note: there have been discussions on the need of Note: Appendix A shows how to send uncompressed messages in a SigComp
multiplexing SigComp and non-SigComp messages on the same TCP structured TCP connection using a "well-known shim header". Should
connection. However, no conclusion was reached.] it for any reason not be desirable to set up more than one TCP
connection to a SIP implementation, but the flexibility to send both
compressed and uncompressed SIP messages be required, the compressor
can set up a SigComp structured connection and send any uncompressed
SIP messages using the well-known shim header.
5. Continuous Mode over TCP 5. Continuous Mode over TCP
Continuous Mode is a special feature of SigComp, which is designed to Continuous Mode is a special feature of SigComp, which is designed to
improve the overall compression ratio for long-lived connections. improve the overall compression ratio for long-lived connections.
However, it requires the transport itself to provide a certain level Its use requires pre-agreement between the SigComp compressor and
of protection against denial of service attacks. TCP is not decompressor. Continuous mode is not used with SIP/SigComp.
considered to provide enough protection, and so Continuous Mode MUST
NOT be used over TCP.
[Editor's note: is this too restrictive in cases where IPsec is Reason: continuous mode requires the transport itself to provide a
enabled below TCP? There have been no comments on this issue so far.] certain level of protection against denial of service attacks. TCP
alone is not considered to provide enough protection.
6. Security Considerations 6. Compartment and State Management for SIP/SigComp
The same security considerations as described in [RFC-3320] apply to An application exchanging compressed traffic with a remote
application has a compartment that contains state information needed
to compress outgoing messages and to decompress incoming messages.
To increase the compression efficiency, the application must assign
distinct compartments to distinct remote applications.
6.1. Remote Application Identifiers
SIP/SigComp applications identify remote applications by their FQDN
(Fully Qualified Domain Name) or by their IP address. For outgoing
requests, the remote application identifier is the host part of the
URI to which the request is sent. For incoming responses, the remote
application identifier is the same as the one for the previously-sent
request that initiated the transaction the response belongs to. For
incoming requests and outgoing responses, the remote application
identifier is the sent-by parameter of the top-most Via entry.
A given remote application identifier is mapped to a particular
SigComp compartment ID following the rules given in the following
sections.
OPEN ISSUE: this is an implicit way of identifying remote
applications. It assumes that two remote applications are
different if the host parts of their URIs are different. However,
if a proxy farm shares dictionary state among its proxies and
these proxies use different host parts (e.g., proxy1.example.com
and proxy2.example.com), they will be considered like different
remote applications, when they should have been considered a
single remote application. If implementers intend to implement
state sharing this way, we could use explicit application
identifiers instead. These identifiers could be placed in a SIP
URI parameter (e.g., sip:p1.example.net;id="12wsfeQ45") and in a
Via parameter.
6.2. Compartment Opening and Closure
SIP applications need to know when to open a new compartment and when
to close it. The lifetime of a compartment depends on how the SIP
application obtained the remote application identifier (e.g., in a
Record-Route header field of an incoming SIP message). There are
compartments that are valid for the duration of a registration, of a
dialog, and of a single transaction. The following sections specify
how a SIP application decides the lifetime of a particular
compartment.
If following the rules in the following sections, a SIP application
is supposed to open a compartment for a remote application identifier
for which it already has a compartment, the SIP application MUST use
the already existing compartment. That is, the SIP application MUST
NOT open a new compartment. Additionally, the SIP application MUST
adjust the closure time for the compartment so that it is only closed
when the SIP application does not need it any longer.
For example, a SIP application may open a compartment valid for the
duration of a registration for a particular remote application
identifier. At a later point, the application is supposed to open a
new compartment for the duration of a particular dialog for the same
remote application identifier. Following the previous rule, the SIP
application does not open a new compartment but use the already
existing one for that remote application identifier. However, the
SIP application must not close that compartment until both, the
registration and the dialog are over. So, if the registration
finishes before the dialog, the compartment will not be closed
(because the dialog is still active) even though the compartment was
originally open for the registration.
Usually, any states created during the lifetime of a compartment will
be "logically" deleted when the compartment is closed. (As described
in section 6.2 of [RFC3320], a logical deletion can become a physical
deletion only when no compartment continues to exist that created the
(same) state.)
A SigComp endpoint may offer to keep a state created upon request
from a SigComp peer endpoint beyond the default lifetime of a
compartment. This may be used to improve compression efficiency of
subsequent SIP messages generated by the same remote application at
the SigComp peer endpoint. To indicate that such state will continue
to be available, the SigComp endpoint can inform its peer SigComp
endpoint by announcing the (partial) state ID in the returned SigComp
parameters at the end of the registration, dialog, or transaction
that was supposed to limit the lifetime of the SigComp state. That
signals the state will be maintained. As there is no way to signal
any limit to the lifetime of this state, both decompressors that
intend to offer state with possibly limited lifetimes as well as
compressors that make use of such state SHOULD implement the SigComp
Negative Acknowledgement (NACK) Mechanism [I-D.ietf-rohc-sigcomp-
nack].
As an operational concern, bugs in the compartment management
implementation are likely to lead to sporadic, hard to diagnose
failures. Decompressors may therefore want to cache old state and,
if still available, allow access while logging diagnostic
information. Both compressors and decompressors are RECOMMENDED to
implement the SigComp Negative Acknowledgement (NACK) Mechanism
[I-D.ietf-rohc-sigcomp-nack], which facilitates recovery in a
situation where such old state may no longer be available.
6.3. Compartment Valid During a Transaction
A SIP application that needs to send a compressed SIP request SHOULD
open a compartment for the request's remote application identifier.
This compartment will be used to receive compressed responses for the
request. The application can close the compartment when the
transaction is over.
A SIP application receives a compressed SIP request SHOULD open a
compartment for the request's remote application identifier. This
compartment will be used to send compressed responses for the
request. The application SHOULD NOT close the compartment until the
transaction is over.
The previous rules ensure that SIP applications always have an
already existing compartment to send and receive responses.
6.4. Compartment Valid During a Registration
A REGISTER transaction can cause an application to open a new
compartment to be valid for the duration of the registration
established by the REGISTER transaction.
A 200 (OK) response for a register may contain a Path [RFC3327] and a
Service-Route [RFC3308] header field. These header fields indicate
the route future incoming and outgoing requests will follow.
On receiving a 200 (OK) response for a REGISTER, a SIP application
that inserted itself in the Contact (i.e., because it is the user
agent) or in the Path header field of the REGISTER, constructs the
route future incoming requests will follow (using the Contact and the
Path header fields) and the route future outgoing requests will
follow (using the Contact and the Service-Route header fields). The
application checks whether the URIs of its adjacent applications in
both routes have the comp=sigcomp parameter. The application SHOULD
open a new compartment for the remote application identifier of the
URIs with that parameter. The application SHOULD NOT close the
compartments until the registration is over.
Note that the route for incoming requests is typically the same
(although traversed in the opposite direction) as the route for
outgoing requests.
Note that some user agents use several registration in parallel to
improve service reliability. Different registration typically have
different associated route vectors. Messages sent to different
remote application identifiers will use different compartments, even
if those messages are generated by the same user agent. It is
assumed that the remote applications do not share SIP/SigComp state
among them.
6.5. Compartment Valid During a Dialog
A transaction that establishes a dialog can cause an application to
open a new compartment to be valid for the duration of the dialog
established by the transaction.
A SIP message that establishes a dialog (e.g., a 2xx response for an
INVITE) may contain a Record-Route header field. This header field
indicates the route future requests within the dialog will follow.
On receiving such a SIP message, a SIP application that inserted
itself in the Contact (i.e., because it is the user agent) or in the
Record-Route header field of the request, constructs (using the
Contact, and the Record-Route header fields) the route requests
within the dialog will follow. The application checks whether the
URIs of its adjacent applications in that route have the
"comp=sigcomp" parameter. The application SHOULD open a new
compartment for the remote application identifier of the URIs with
that parameter. The application SHOULD NOT close the compartments
until the dialog is over.
7. Recommendations for Network Administrators
Network administrators can configure their networks so that the
compression efficiency achieved is increased. The following
recommendations help network administrators perform their task.
For a given user agent, the route sets for incoming requests (created
by a Path header field) and for outgoing requests (created by a
Service-Route header field) are typically the same. However,
registrars can, if they wish, insert proxies in the latter route that
do not appear in the former route and vice versa. It is RECOMMENDED
that registrars are configured so that proxies performing SigComp
compression appear in both routes.
The routes described previously apply to requests sent outside a
dialog. Requests inside a dialog follow a route constructed using
Record-Route header fields. It is RECOMMENDED that the proxies
performing SigComp that are in the route for requests outside a
dialog are configured to place themselves (by inserting themselves in
the Record-Route header fields) in the routes used for requests
inside dialogs.
8. Security Considerations
The same security considerations as described in [RFC3320] apply to
this document. Note that keeping SigComp states longer than the this document. Note that keeping SigComp states longer than the
duration of a SIP dialog should not pose new security risks for two duration of a SIP dialog should not pose new security risks for two
reasons: a) the state has been allowed to be created in the first reasons: a) the state has been allowed to be created in the first
place; and b) this is on voluntary basis and a SigComp endpoint can place; and b) this is on voluntary basis and a SigComp endpoint can
choose not to offer it. choose not to offer it.
7. Acknowledgements 9. Private Agreements
SIP/SigComp implementations that are subject to private agreements
MAY deviate from this specification, if the private agreements
unambiguously specify so. Plausible candidates for such deviations
include:
o Minimum values (Section 3).
o Compartment definition (Section 6).
o Use of continuous mode (Section 5).
10. IANA Considerations
This specification does not require any actions from the IANA.
11. Acknowledgements
Abigail Surtees provided the code and text for Appendix A.
The authors would like to thank the following people for their The authors would like to thank the following people for their
comments and suggestions: Carsten Bormann, Jan Christoffersson, Pekka comments and suggestions: Abigail Surtees, Jan Christoffersson, Joerg
Pessi, Robert Sugar, Abigail Surtees, and Mark West. Ott, Mark West, Pekka Pessi, Robert Sugar, and Adam Roach.
8. Normative References 12. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M. and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC-3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., [RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer
Liu, Z. and J. Rosenberg, "Signaling Compression Two Tunneling Protocol (L2TP) Differentiated Services
Extension", RFC 3308, November 2002.
[RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H.,
Liu, Z., and J. Rosenberg, "Signaling Compression
(SigComp)", RFC 3320, January 2003. (SigComp)", RFC 3320, January 2003.
[RFC-3485] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
A. Adam, "The Session Initiation Protocol (SIP) and (SIP) Extension Header Field for Registering Non-Adjacent
Session Description Protocol (SDP) Static Dictionary for Contacts", RFC 3327, December 2002.
Signaling Compression (SigComp)", RFC 3485, February
2003.
[RFC-3486] Camarillo, G., "Compressing the Session Initiation [RFC3485] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and A.
Roach, "The Session Initiation Protocol (SIP) and Session
Description Protocol (SDP) Static Dictionary for Signaling
Compression (SigComp)", RFC 3485, February 2003.
[RFC3486] Camarillo, G., "Compressing the Session Initiation
Protocol (SIP)", RFC 3486, February 2003. Protocol (SIP)", RFC 3486, February 2003.
9. Authors' Addresses [I-D.ietf-rohc-sigcomp-nack]
Roach, A., "A Negative Acknowledgement Mechanism for
Signaling Compression", draft-ietf-rohc-sigcomp-nack-02
(work in progress), October 2004.
Appendix A. Shim header for sending uncompressed messages
This appendix presents bytecode that simply instructs the
decompressor to output the entire message (effectively sending it
uncompressed but within a SigComp message).
The mnemonic code is:
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 initial 13 bytes of the
SigComp message (in hexadecimal):
f8 00 a1 1c 01 86 09 22 86 01 16 f9 23
As an implementation optimization, a SigComp implementation MAY
compare the initial 13 bytes of each incoming message with the 13
bytes given (the "well-known shim header"), and, in case of a match,
simply copy the SigComp message data that follow the shim header
without even setting up a UDVM. (Note that, before a SigComp message
is formed from the incoming TCP data, the record marking protocol
defined in section 4.2.2 of [RFC3320] has to be performed.)
To obtain the maximum benefit from this optimization, compressors
SHOULD employ exactly the well-known shim header given (and none of
the other conceivable byte code sequences for just copying input to
output) to send uncompressed data in a SigComp channel.
Authors' Addresses
Carsten Bormann (editor)
Universitaet Bremen TZI
Postfach 330440
Bremen D-28334
Germany
Phone: +49 421 218 7024
Fax: +49 421 218 7000
Email: cabo@tzi.org
Zhigang Liu Zhigang Liu
Nokia Research Center Nokia Research Center
6000 Connection Drive 6000 Connection Drive
Irving, TX 75039 Irving, TX 75039
USA USA
Phone: +1 972 894-5935 Phone: +1 972 894-5935
E-mail: zhigang.c.liu@nokia.com Email: zhigang.c.liu@nokia.com
Richard Price Richard Price
Roke Manor Research Ltd Cogent Defence and Security Networks
Romsey, Hants, SO51 0ZN Queensway Meadows Industrial Estate
United Kingdom Meadows Road
Newport, Gwent NP19 4SS
Phone: +44 1794 833681 Phone: +44 (0)1794 833681
Email: richard.price@roke.co.uk Email: richard.price@cogent-dsn.com
URI: http://www.cogent-dsn.com
10. Full copyright statement Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Copyright (C) The Internet Society (2004). All Rights Reserved. Email: Gonzalo.Camarillo@ericsson.com
This document and translations of it may be copied and furnished to Intellectual Property Statement
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 The IETF takes no position regarding the validity or scope of any
revoked by the Internet Society or its successors or assigns. 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.
This document and the information contained herein is provided on an Copies of IPR disclosures made to the IETF Secretariat and any
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING assurances of licenses to be made available, or the result of an
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING attempt made to obtain a general license or permission for the use of
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION such proprietary rights by implementers or users of this
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF specification can be obtained from the IETF on-line IPR repository at
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. http://www.ietf.org/ipr.
This Internet-Draft will expire on August 12, 2004. 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.
 End of changes. 64 change blocks. 
203 lines changed or deleted 500 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/