draft-ietf-rohc-sigcomp-sip-06.txt   draft-ietf-rohc-sigcomp-sip-07.txt 
Robust Header Compression C. Bormann Robust Header Compression C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track Z. Liu Intended status: Standards Track Z. Liu
Expires: November 15, 2007 Nokia Research Center Expires: January 4, 2008 Nokia Research Center
R. Price R. Price
Cogent Defence and Security EADS Defence and Security Systems
Networks Limited
G. Camarillo, Ed. G. Camarillo, Ed.
Ericsson Ericsson
May 14, 2007 July 3, 2007
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-06.txt draft-ietf-rohc-sigcomp-sip-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. 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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 The list of current Internet-Drafts can be accessed at
http://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 Internet-Draft will expire on November 15, 2007. This Internet-Draft will expire on January 4, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes some specifics that apply when Signaling This document describes some specifics that apply when Signaling
Compression (SigComp) is applied to the Session Initiation Protocol Compression (SigComp) is applied to the Session Initiation Protocol
(SIP), such as default minimum values of SigComp parameters, (SIP), such as default minimum values of SigComp parameters,
compartment and state management, and a few issues on SigComp over compartment and state management, and a few issues on SigComp over
TCP. Any implementation of SigComp for use with SIP must conform to TCP. Any implementation of SigComp for use with SIP must conform to
this document, in addition to SigComp and support of the SIP and this document and SigComp, and in addition support the SIP and
Session Description Protocol (SDP) static dictionary. Session Description Protocol (SDP) static dictionary.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Compliance with this Specification . . . . . . . . . . . . . . 3 3. Compliance with this Specification . . . . . . . . . . . . . . 3
4. Minimum Values of SigComp Parameters for SIP/SigComp . . . . . 3 4. Minimum Values of SigComp Parameters for SIP/SigComp . . . . . 3
4.1. decompression_memory_size (DMS) for SIP/SigComp . . . . . 4 4.1. decompression_memory_size (DMS) for SIP/SigComp . . . . . 4
4.2. state_memory_size (SMS) for SIP/SigComp . . . . . . . . . 4 4.2. state_memory_size (SMS) for SIP/SigComp . . . . . . . . . 4
skipping to change at page 2, line 32 skipping to change at page 2, line 32
5. Delimiting SIP Messages and SigComp Messages on the Same 5. Delimiting SIP Messages and SigComp Messages on the Same
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Continuous Mode over TCP . . . . . . . . . . . . . . . . . . . 6 6. Continuous Mode over TCP . . . . . . . . . . . . . . . . . . . 6
7. Too Large SIP Messages . . . . . . . . . . . . . . . . . . . . 6 7. Too Large SIP Messages . . . . . . . . . . . . . . . . . . . . 6
8. SIP Retransmissions . . . . . . . . . . . . . . . . . . . . . 7 8. SIP Retransmissions . . . . . . . . . . . . . . . . . . . . . 7
9. Compartment and State Management for SIP/SigComp . . . . . . . 7 9. Compartment and State Management for SIP/SigComp . . . . . . . 7
9.1. Remote Application Identification . . . . . . . . . . . . 7 9.1. Remote Application Identification . . . . . . . . . . . . 7
9.2. Identifier Comparison Rules . . . . . . . . . . . . . . . 10 9.2. Identifier Comparison Rules . . . . . . . . . . . . . . . 10
9.3. Compartment Opening and Closure . . . . . . . . . . . . . 10 9.3. Compartment Opening and Closure . . . . . . . . . . . . . 10
9.4. Lack of a Compartment . . . . . . . . . . . . . . . . . . 12 9.4. Lack of a Compartment . . . . . . . . . . . . . . . . . . 12
10. Recommendations for Network Administrators . . . . . . . . . . 12 10. Recommendations for Network Administrators . . . . . . . . . . 13
11. Private Agreements . . . . . . . . . . . . . . . . . . . . . . 13 11. Private Agreements . . . . . . . . . . . . . . . . . . . . . . 13
12. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 13 12. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14
13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 17 14. Security Considerations . . . . . . . . . . . . . . . . . . . 17
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
17.1. Normative References . . . . . . . . . . . . . . . . . . . 18 17.1. Normative References . . . . . . . . . . . . . . . . . . . 18
17.2. Informative References . . . . . . . . . . . . . . . . . . 19 17.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 21
skipping to change at page 6, line 25 skipping to change at page 6, line 25
application with no further effect on the SigComp layer. Note that application with no further effect on the SigComp layer. Note that
SigComp message delimiters MUST NOT be used if the stream contains SigComp message delimiters MUST NOT be used if the stream contains
uncompressed SIP messages. 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 [RFC3320]. in [RFC3320].
Section 11 of [I-D.ietf-rohc-sigcomp-impl-guide] details a simple set Section 11 of [RFC4896] details a simple set of bytecodes, intended
of bytecodes, intended to be "well-known", that implement a null to be "well-known", that implement a null decompression algorithm.
decompression algorithm. These bytecodes effectively allow SigComp These bytecodes effectively allow SigComp peers to send selected
peers to send selected SigComp messages with uncompressed data. If a SigComp messages with uncompressed data. If a SIP implementation has
SIP implementation has reason to send both compressed and reason to send both compressed and uncompressed SIP messages on a
uncompressed SIP messages on a single TCP connection, the compressor single TCP connection, the compressor can be instructed to use these
can be instructed to use these bytecodes to send uncompressed SIP bytecodes to send uncompressed SIP messages that are also valid
messages that are also valid SigComp messages. SigComp messages.
6. Continuous Mode over TCP 6. 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.
Its use requires pre-agreement between the SigComp compressor and Its use requires pre-agreement between the SigComp compressor and
decompressor. Continuous mode is not used with SIP/SigComp. decompressor. Continuous mode is not used with SIP/SigComp.
Reason: continuous mode requires the transport itself to provide a Reason: continuous mode requires the transport itself to provide a
certain level of protection against denial of service attacks. TCP certain level of protection against denial of service attacks. TCP
alone is not considered to provide enough protection. alone is not considered to provide enough protection.
7. Too Large SIP Messages 7. Too Large SIP Messages
SigComp does not support the compression of messages larger than 64k. SigComp does not support the compression of messages larger than 64k.
Therefore, if a SIP application sending compressed SIP messages to Therefore, if a SIP application sending compressed SIP messages to
another SIP application over a transport connection (e.g., a TCP another SIP application over a transport connection (e.g., a TCP
connection) needs to send a SIP message larger than 64k, the SIP connection) needs to send a SIP message larger than 64k, the SIP
application SHOULD establish a new transport connection and send the application MUST NOT send the message over the same TCP connection.
(uncompressed) SIP message over the new connection. The SIP application SHOULD send the message over a different
transport connection (to do this, the SIP application may need to
establish a new transport connection).
8. SIP Retransmissions 8. SIP Retransmissions
SIP retransmissions need to be compressed again before being sent. When SIP messages are retransmitted, they need to be re-compressed,
That is, SIP applications MUST NOT retransmit already-compressed taking into account any SigComp states that may have been created or
information. invalidated since the previous transmission. Implementations MUST
NOT cache the result of compressing the message and retransmit such a
cached result.
The reason for this behavior is that it is impossible to know whether The reason for this behavior is that it is impossible to know whether
the failure causing the retransmission occurred on the message being the failure causing the retransmission occurred on the message being
retransmitted or on the response to that message. If the response retransmitted or on the response to that message. If the response
was lost, any state changes effected by the first instance of the was lost, any state changes effected by the first instance of the
retransmitted message would already have taken place. If these state retransmitted message would already have taken place. If these state
changes removed a state that the previously-transmitted message changes removed a state that the previously-transmitted message
relied upon, then retransmission of the same compressed message would relied upon, then retransmission of the same compressed message would
lead to a decompression failure. lead to a decompression failure.
skipping to change at page 11, line 5 skipping to change at page 11, line 5
previous identifiers. previous identifiers.
9.3. Compartment Opening and Closure 9.3. Compartment Opening and Closure
SIP applications need to know when to open a new compartment and when SIP applications need to know when to open a new compartment and when
to close it. The lifetime of SIP/SigComp compartments is linked to to close it. The lifetime of SIP/SigComp compartments is linked to
registration state. Compartments are opened at SIP registration time registration state. Compartments are opened at SIP registration time
and are typically closed when the registration expires or is and are typically closed when the registration expires or is
canceled. canceled.
Previous revisions of this document also defined compartments Note that linking the lifetime of SIP/SigComp compartments to
valid during a SIP transaction or a SIP dialog. It was decided to registration state limits the applicability of this specification.
eliminate those types of compartments because the complexity they In particular, SIP user agents that do not register but, for
introduced was higher than the benefits they brought in most example, only handle PUBLISH or SUBSCRIBE/NOTIFY transactions are
deployment scenarios. not able create SIP/SigComp compartments following this
specification. Previous revisions of this specification also
defined compartments valid during a SIP transaction or a SIP
dialog. Those compartments covered all possible SIP entities,
including those that do not handle REGISTER transactions.
However, it was decided to eliminate those types of compartments
because the complexity they introduced (e.g., edge proxy servers
were required to keep dialog state) was higher than the benefits
they brought in most deployment scenarios.
Usually, any states created during the lifetime of a compartment will Usually, any states created during the lifetime of a compartment will
be "logically" deleted when the compartment is closed. As described be "logically" deleted when the compartment is closed. As described
in section 6.2 of [RFC3320], a logical deletion can become a physical in section 6.2 of [RFC3320], a logical deletion can become a physical
deletion only when no compartment continues to exist that created the deletion only when no compartment continues to exist that created the
(same) state. (same) state.
A SigComp endpoint may offer to keep a state created upon request A SigComp endpoint may offer to keep a state created upon request
from a SigComp peer endpoint beyond the default lifetime of a from a SigComp peer endpoint beyond the default lifetime of a
compartment (i.e., beyond the duration of its associated compartment (i.e., beyond the duration of its associated
skipping to change at page 12, line 28 skipping to change at page 12, line 36
dialog-creating transactions. Previous revisions of this document dialog-creating transactions. Previous revisions of this document
supported the use of different paths for different types of supported the use of different paths for different types of
traffic. However, for simplicity reasons, this document now traffic. However, for simplicity reasons, this document now
assumes that networks using compression are configured so that assumes that networks using compression are configured so that
subsequent requests follow the same path as the initial REGISTER subsequent requests follow the same path as the initial REGISTER
transaction. Section 10 provides network administrators with transaction. Section 10 provides network administrators with
recommendations so that they can configure they networks properly. recommendations so that they can configure they networks properly.
If, following the rules above, a SIP application is supposed to open If, following the rules above, a SIP application is supposed to open
a compartment for a remote application identifier for which it a compartment for a remote application identifier for which it
already has a compartment, the SIP application MUST use the already already has a compartment (e.g., the SIP application registers
existing compartment. That is, the SIP application MUST NOT open a towards a second registrar using the same edge proxy server as for
new compartment. its registration towards its first registrar), the SIP application
MUST use the already existing compartment. That is, the SIP
application MUST NOT open a new compartment.
9.4. Lack of a Compartment 9.4. Lack of a Compartment
The use of stateless compression (i.e., compression without a The use of stateless compression (i.e., compression without a
compartment) is not typically worthwhile and may even result in compartment) is not typically worthwhile and may even result in
message expansion. Therefore, if a SIP application does not have a message expansion. Therefore, if a SIP application does not have a
compartment for a message it needs to send, it MAY choose not to compartment for a message it needs to send, it MAY choose not to
compress it even in the presence of the comp=sigcomp parameter. Note compress it even in the presence of the comp=sigcomp parameter.
that RFC 3486 [RFC3486] states the following: Section Section 5 describes how a SIP application can send compressed
and uncompressed messages over the same TCP connection. Note that
RFC 3486 [RFC3486] states the following:
"If the next-hop URI contains the parameter comp=sigcomp, the "If the next-hop URI contains the parameter comp=sigcomp, the
client SHOULD compress the request using SigComp" client SHOULD compress the request using SigComp"
Experience since RFC 3486 [RFC3486] was written has shown that Experience since RFC 3486 [RFC3486] was written has shown that
stateless compression is, in most cases, not worthwhile. That is why stateless compression is, in most cases, not worthwhile. That is why
now it is not recommended to use it any longer. now it is not recommended to use it any longer.
10. Recommendations for Network Administrators 10. Recommendations for Network Administrators
skipping to change at page 17, line 41 skipping to change at page 17, line 41
-------------- ----------------- --------- -------------- ----------------- ---------
sigcomp-id No [RFCxxxx] sigcomp-id No [RFCxxxx]
Note to the RFC Editor: please, substitute RFCxxxx with the RFC Note to the RFC Editor: please, substitute RFCxxxx with the RFC
number this document will get. number this document will get.
16. Acknowledgements 16. Acknowledgements
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: Jan Christoffersson, Joerg Ott, Mark West, comments and suggestions: Jan Christoffersson, Joerg Ott, Mark West,
Pekka Pessi, Robert Sugar, Jonathan Rosenberg, Robert Sparks, and Pekka Pessi, Robert Sugar, Jonathan Rosenberg, Robert Sparks, Juergen
Tuukka Karvonen. Abigail Surtees and Adam Roach performed thorough Schoenwaelder, and Tuukka Karvonen. Abigail Surtees and Adam Roach
reviews of this document. performed thorough reviews of this document.
17. References 17. References
17.1. Normative References 17.1. Normative References
[RFC2119] 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.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
skipping to change at page 18, line 47 skipping to change at page 18, line 47
[RFC4077] Roach, A., "A Negative Acknowledgement Mechanism for [RFC4077] Roach, A., "A Negative Acknowledgement Mechanism for
Signaling Compression", RFC 4077, May 2005. Signaling Compression", RFC 4077, May 2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[RFC4896] Surtees, A., West, M., and A. Roach, "Signaling
Compression (SigComp) Corrections and Clarifications",
RFC 4896, June 2007.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-07 (work in progress), draft-ietf-sip-outbound-08 (work in progress), March 2007.
January 2007.
[I-D.ietf-rohc-sigcomp-impl-guide]
Surtees, A., "Implementer's Guide for SigComp",
draft-ietf-rohc-sigcomp-impl-guide-10 (work in progress),
January 2007.
17.2. Informative References 17.2. Informative References
[I-D.ietf-sipping-config-framework] [I-D.ietf-sipping-config-framework]
Petrie, D. and S. Channabasappa, "A Framework for Session Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery", Initiation Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-10 (work in progress), draft-ietf-sipping-config-framework-12 (work in progress),
January 2007. June 2007.
Authors' Addresses Authors' Addresses
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28334 Bremen D-28334
Germany Germany
Phone: +49 421 218 7024 Phone: +49 421 218 7024
skipping to change at page 19, line 40 skipping to change at page 19, line 37
Zhigang Liu Zhigang Liu
Nokia Research Center Nokia Research Center
955 Page Mill Road 955 Page Mill Road
Palo Alto, CA 94304 Palo Alto, CA 94304
USA USA
Phone: +1 650 796 4578 Phone: +1 650 796 4578
Email: zhigang.c.liu@nokia.com Email: zhigang.c.liu@nokia.com
Richard Price Richard Price
Cogent Defence and Security Networks EADS Defence and Security Systems Limited
Queensway Meadows Industrial Estate
Meadows Road Meadows Road
Queensway Meadows
Newport, Gwent NP19 4SS Newport, Gwent NP19 4SS
Phone: +44 (0)1794 833681 Phone: +44 (0)1633 637874
Email: richard.price@cogent-dsn.com Email: richard.price@eads.com
URI: http://www.cogent-dsn.com
Gonzalo Camarillo (editor) Gonzalo Camarillo (editor)
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement Full Copyright Statement
 End of changes. 21 change blocks. 
49 lines changed or deleted 62 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/