draft-ietf-rohc-sigcomp-extended-03.txt   draft-ietf-rohc-sigcomp-extended-04.txt 
Network Working Group H. Hannu, Ericsson Network Working Group H. Hannu, Ericsson
INTERNET-DRAFT J. Christoffersson, Ericsson INTERNET-DRAFT J. Christoffersson, Ericsson
Expires: November 2002 S. Forsgren Expires: December 2002 S. Forsgren
K. Leung K. Leung
Z. Liu, Nokia Z. Liu, Nokia
R. Price, Siemens/Roke Manor R. Price, Siemens/Roke Manor
May 03, 2002 June 03, 2002
SigComp - Extended Operations SigComp - Extended Operations
<draft-ietf-rohc-sigcomp-extended-03.txt> <draft-ietf-rohc-sigcomp-extended-04.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
http://www.ietf.org/ietf/lid-abstracts.txt http://www.ietf.org/ietf/lid-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 document is a submission of the IETF ROHC WG. Comments should be
directed to its mailing list, rohc@ietf.org. directed to its mailing list, rohc@ietf.org.
Abstract Abstract
This document describes mechanisms to be used with Signaling This document describes how to implement certain mechanisms in
Compression (SigComp), RFC XXX, that significantly improve the SigComp (Signaling Compression), RFC XXX, which can significantly
compression efficiency compared to using per-message compression. The improve the compression efficiency compared to using simple per-
mechanisms, such as explicit acknowledgements and shared compression message compression.
are defined and explained in this document.
SigComp uses a UDVM (Universal Decompressor Virtual Machine) for
decompression, and the mechanisms described in this document are
possible to implement using the UDVM instructions defined in RFC XXX.
Table of contents Table of contents
1. Introduction....................................................2 1. Introduction....................................................2
2. Terminology.....................................................2 2. Terminology.....................................................2
3. Architectural View of Feedback..................................4 3. Architectural View of Feedback..................................4
4. State Reference Model...........................................4 4. State Reference Model...........................................4
5. Extended Mechanisms.............................................6 5. Extended Mechanisms.............................................6
6. Implications on SigComp........................................11 6. Implications on SigComp........................................11
7. Security Considerations........................................15 7. Security Considerations........................................15
skipping to change at page 3, line 25 skipping to change at page 3, line 25
into uncompressed data. Decompression functionality is provided by into uncompressed data. Decompression functionality is provided by
the UDVM. the UDVM.
Dynamic compression Dynamic compression
Compression relative to messages sent prior to the current Compression relative to messages sent prior to the current
compressed message. compressed message.
Explicit acknowledgement Explicit acknowledgement
Acknowledgement for a state that is explicitly sent from a Acknowledgement for a state. The acknowledgment is explicitly sent
decompressor to its remote compressor. The acknowledgement should from a decompressor to its remote compressor. The acknowledgement
be piggybacked onto a SigComp message in order not to create should be piggybacked onto a SigComp message in order not to create
additional security risks. additional security risks.
Shared compression Shared compression
Compression relative to messages received by the local endpoint Compression relative to messages received by the local endpoint
prior to the current compressed message. prior to the current compressed message.
Shared state Shared state
A state used for shared compression consists only of an A state used for shared compression consists only of an
skipping to change at page 10, line 54 skipping to change at page 10, line 54
the dictionary. To keep an upper bound of the memory consumption such the dictionary. To keep an upper bound of the memory consumption such
as in the case for a low end mobile terminal, existing content of the as in the case for a low end mobile terminal, existing content of the
dictionary must be deleted to make room for the new content. dictionary must be deleted to make room for the new content.
Instead of explicitly signaling which parts of the dictionary need to Instead of explicitly signaling which parts of the dictionary need to
be deleted on a per message basis, an implicit deletion approach may be deleted on a per message basis, an implicit deletion approach may
be applied. Specifically, some parts of the dictionary are chosen to be applied. Specifically, some parts of the dictionary are chosen to
be deleted according to a well-defined algorithm that is known and be deleted according to a well-defined algorithm that is known and
applied in the same way at both compressor and decompressor. For applied in the same way at both compressor and decompressor. For
instance, the algorithm can be part of the predefined UDVM bytecode instance, the algorithm can be part of the predefined UDVM bytecode
that is agreed between the two SigComp endpoints. As input into to that is agreed between the two SigComp endpoints. As input to the
the algorithm, one provides the total number of bytes to be deleted. algorithm, one provides the total number of bytes to be deleted. The
The algorithm then specifies which parts of dictionary are to be algorithm then specifies which parts of dictionary are to be deleted.
deleted. Since the same algorithm is applied at both SigComp Since the same algorithm is applied at both SigComp endpoints, there
endpoints, there is no need for explicit signaling on a per message is no need for explicit signaling on a per message basis. This may
basis. This may lead to higher compression efficiency due to the lead to higher compression efficiency due to the avoidance of
avoidance of signaling overhead. It also means more robustness as signaling overhead. It also means more robustness as there are no
there are no signaling bit on the wire that are subject to possible signaling bit on the wire that are subject to possible transmission
transmission errors/losses. errors/losses.
6. Implications on SigComp 6. Implications on SigComp
The extended features will have implications on the SigComp messages The extended features will have implications on the SigComp messages
sent between the compressor and its remote decompressor, and on how sent between the compressor and its remote decompressor, and on how
to interpret e.g. returned SigComp parameters [SIGCOMP]. However, to interpret e.g. returned SigComp parameters [SIGCOMP]. However,
except for the mandatory bytes of the SigComp messages [SIGCOMP], the except for the mandatory bytes of the SigComp messages [SIGCOMP], the
final message formats used are implementation issues. final message formats used are implementation issues.
Note that an implementation that does not make use of explicit Note that an implementation that does not make use of explicit
acknowledgements and/or shared compression is not affected, even if acknowledgements and/or shared compression is not affected, even if
skipping to change at page 16, line 23 skipping to change at page 16, line 23
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
12. References 12. References
[SIP] M. Handley et. al., SIP: Session Initiation Protocol, [SIP] M. Handley et. al., SIP: Session Initiation Protocol,
RFC 2543, Internet Engineering Task Force, March 1999 RFC 2543, Internet Engineering Task Force, March 1999
[SIGCOMP] R. Price et. al., Signaling Compression (SigComp), [SIGCOMP] R. Price et. al., Signaling Compression (SigComp),
Internet Draft (work in progress), May 2002. Internet Draft (work in progress), June 2002.
<draft-ietf-rohc-sigcomp-06.txt> <draft-ietf-rohc-sigcomp-07.txt>
This Internet-Draft expires November 03, 2002. This Internet-Draft expires December 03, 2002.
 End of changes. 

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