draft-ietf-rohc-sigcomp-user-guide-03.txt   draft-ietf-rohc-sigcomp-user-guide-04.txt 
Robust Header Compression A. Surtees Robust Header Compression A. Surtees
Internet-Draft M. West Internet-Draft M. West
Expires: April 1, 2006 Siemens/Roke Manor Research Expires: April 27, 2006 Siemens/Roke Manor Research
September 28, 2005 October 24, 2005
SigComp Users' Guide SigComp Users' Guide
draft-ietf-rohc-sigcomp-user-guide-03.txt draft-ietf-rohc-sigcomp-user-guide-04.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 34 skipping to change at page 1, line 34
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 April 1, 2006. This Internet-Draft will expire on April 27, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document provides an informational guide for users of the This document provides an informational guide for users of the
SigComp protocol. The aim of the document is to assist users when SigComp protocol. The aim of the document is to assist users when
making SigComp implementation decisions; for example the choice of making SigComp implementation decisions; for example the choice of
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4.1.2 LZSS . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.2 LZSS . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.3 LZW . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1.3 LZW . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.4 DEFLATE . . . . . . . . . . . . . . . . . . . . . . . 21 4.1.4 DEFLATE . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.5 LZJH . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1.5 LZJH . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Adapted Algorithms . . . . . . . . . . . . . . . . . . . . 28 4.2 Adapted Algorithms . . . . . . . . . . . . . . . . . . . . 28
4.2.1 Modified DEFLATE . . . . . . . . . . . . . . . . . . . 28 4.2.1 Modified DEFLATE . . . . . . . . . . . . . . . . . . . 28
5. Additional SigComp mechanisms . . . . . . . . . . . . . . . . 31 5. Additional SigComp mechanisms . . . . . . . . . . . . . . . . 31
5.1 Acknowledging a state item . . . . . . . . . . . . . . . . 32 5.1 Acknowledging a state item . . . . . . . . . . . . . . . . 32
5.2 Static dictionary . . . . . . . . . . . . . . . . . . . . 33 5.2 Static dictionary . . . . . . . . . . . . . . . . . . . . 33
5.3 CRC checksum . . . . . . . . . . . . . . . . . . . . . . . 34 5.3 CRC checksum . . . . . . . . . . . . . . . . . . . . . . . 34
5.4 Announcing additional resources . . . . . . . . . . . . . 34 5.4 Announcing additional resources . . . . . . . . . . . . . 35
5.5 Shared compression . . . . . . . . . . . . . . . . . . . . 36 5.5 Shared compression . . . . . . . . . . . . . . . . . . . . 37
6. Security considerations . . . . . . . . . . . . . . . . . . . 37 6. Security considerations . . . . . . . . . . . . . . . . . . . 38
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
8. Intellectual Property Right Considerations . . . . . . . . . . 37 8. Intellectual Property Right Considerations . . . . . . . . . . 38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
A. UDVM bytecode for the compression algorithms . . . . . . . . . 39 A. UDVM bytecode for the compression algorithms . . . . . . . . . 39
A.1 Well-known Algorithms . . . . . . . . . . . . . . . . . . 39 A.1 Well-known Algorithms . . . . . . . . . . . . . . . . . . 40
A.1.1 Simplified LZ77 . . . . . . . . . . . . . . . . . . . 39 A.1.1 Simplified LZ77 . . . . . . . . . . . . . . . . . . . 40
A.1.2 LZSS . . . . . . . . . . . . . . . . . . . . . . . . . 39 A.1.2 LZSS . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.1.3 LZW . . . . . . . . . . . . . . . . . . . . . . . . . 40 A.1.3 LZW . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.1.4 DEFLATE . . . . . . . . . . . . . . . . . . . . . . . 40 A.1.4 DEFLATE . . . . . . . . . . . . . . . . . . . . . . . 40
A.1.5 LZJH . . . . . . . . . . . . . . . . . . . . . . . . . 40 A.1.5 LZJH . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.2 Adapted Algorithms . . . . . . . . . . . . . . . . . . . . 40 A.2 Adapted Algorithms . . . . . . . . . . . . . . . . . . . . 41
A.2.1 Modified DEFLATE . . . . . . . . . . . . . . . . . . . 40 A.2.1 Modified DEFLATE . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . 42 Intellectual Property and Copyright Statements . . . . . . . . 42
1. Introduction 1. Introduction
This document provides an informational guide for users of the This document provides an informational guide for users of the
SigComp protocol RFC-3320 [4]. The idea behind SigComp is to SigComp protocol RFC-3320 [4]. The idea behind SigComp is to
standardize a Universal Decompressor Virtual Machine (UDVM) that can standardize a Universal Decompressor Virtual Machine (UDVM) that can
be programmed to understand the output of many well-known compressors be programmed to understand the output of many well-known compressors
including DEFLATE [10] and LZW [9]. The bytecode for the choice of including DEFLATE [10] and LZW [9]. The bytecode for the choice of
compression algorithm is uploaded to the UDVM as part of the compression algorithm is uploaded to the UDVM as part of the
compressed data. compressed data.
The basic SigComp RFC describes the actions that an endpoint must The basic SigComp RFC describes the actions that an endpoint must
take upon receiving a SigComp message. However the entity take upon receiving a SigComp message. However the entity
responsible for generating new SigComp messages (the SigComp responsible for generating new SigComp messages (the SigComp
compressor) is left as an implementation decision; any compressor can compressor) is left as an implementation decision; any compressor can
be used provided that it generates SigComp messages that can be be used provided that it generates SigComp messages that can be
successfully decompressed by the receiving endpoint. successfully decompressed by the receiving endpoint.
This document offers a number of different compressors that can be This document gives examples of a number of different compressors
used by the SigComp protocol. It also gives examples of how to use that can be used by the SigComp protocol. It also gives examples of
some of the mechanisms (such as acknowledgements) described in RFC how to use some of the mechanisms (such as acknowledgements)
3321 [5]. described in RFC 3321 [5].
2. Overview of the User Guide 2. Overview of the User Guide
When implementing a SigComp compressor the first step is to choose a When implementing a SigComp compressor the first step is to choose a
compression algorithm that can encode the application messages into a compression algorithm that can encode the application messages into a
(hopefully) smaller form. Since SigComp can upload bytecode for new (hopefully) smaller form. Since SigComp can upload bytecode for new
algorithms to the receiving endpoint, arbitrary compression algorithms to the receiving endpoint, arbitrary compression
algorithms can be supported provided that bytecode has been written algorithms can be supported provided that bytecode has been written
for the corresponding decompressor. for the corresponding decompressor.
skipping to change at page 4, line 15 skipping to change at page 4, line 15
The following robustness techniques and other mechanisms specific to The following robustness techniques and other mechanisms specific to
the SigComp environment are covered in this document: the SigComp environment are covered in this document:
1. Acknowledgements using the SigComp feedback mechanism 1. Acknowledgements using the SigComp feedback mechanism
2. Static dictionary 2. Static dictionary
3. CRC checksum 3. CRC checksum
4. Announcing additional resources 4. Announcing additional resources
5. Shared compression 5. Shared compression
Any or all of the above mechanisms can be implemented in conjunction Any or all of the above mechanisms can be implemented in conjunction
with the chosen compression algorithm. A subroutine of UDVM bytecode with the chosen compression algorithm. An example subroutine of UDVM
is provided for each of the mechanisms; these subroutines can be bytecode is provided for each of the mechanisms; these subroutines
added to the bytecode for one of the basic compression algorithms. can be added to the bytecode for one of the basic compression
algorithms. (NB. The subroutine or the basic algorithm may require
minor modification to ensure they work together correctly.)
3. UDVM assembly language 3. UDVM assembly language
Writing UDVM programs directly in bytecode would be a daunting task, Writing UDVM programs directly in bytecode would be a daunting task,
so a simple assembly language is provided to facilitate the creation so a simple assembly language is provided to facilitate the creation
of new decompression algorithms. The assembly language includes of new decompression algorithms. The assembly language includes
mnemonic codes for each of the UDVM instructions, as well as simple mnemonic codes for each of the UDVM instructions, as well as simple
directives for evaluating integer expressions, padding the bytecode directives for evaluating integer expressions, padding the bytecode
and so forth. and so forth.
skipping to change at page 8, line 42 skipping to change at page 8, line 42
Since literal operands are used to indicate the total number of Since literal operands are used to indicate the total number of
operands for an instruction, it is possible to leave a literal operands for an instruction, it is possible to leave a literal
operand blank and allow its value to be inferred automatically by the operand blank and allow its value to be inferred automatically by the
assembler. For example: assembler. For example:
MULTILOAD (64, , 1, 2, 3, 4) MULTILOAD (64, , 1, 2, 3, 4)
The missing operand should be given the value 4 because it is The missing operand should be given the value 4 because it is
followed by a total of 4 operands. followed by a total of 4 operands.
If the operand is a reference then as per Figure 9 of SigComp, the If the operand is a reference then, as per Figure 9 of SigComp, the
parser inserts bytecode (ususally the shortest) capable of encoding parser inserts bytecode (usually the shortest) capable of encoding
the supplied memory address. Note that reference operands will the supplied memory address. Note that reference operands will
always be preceded by the symbol "$" in assembly because they always always be preceded by the symbol "$" in assembly because they always
encode memory addresses rather than actual operand values. encode memory addresses rather than actual operand values.
If the operand is a multitype then the parser first checks whether If the operand is a multitype then the parser first checks whether
the symbol "$" is present. If so then, as per Figure 10 of SigComp, the symbol "$" is present. If so then, as per Figure 10 of SigComp,
it inserts bytecode (usually the shortest) capable of encoding the it inserts bytecode (usually the shortest) capable of encoding the
supplied integer as a memory address. If not then, as per Figure 10 supplied integer as a memory address. If not then, as per Figure 10
of SigComp, it inserts bytecode (usually the shortest) that encodes of SigComp, it inserts bytecode (usually the shortest) that encodes
the supplied integer as an operand value. the supplied integer as an operand value.
skipping to change at page 21, line 24 skipping to change at page 21, line 23
The uncompressed message is "So long and thanks for all the fish!\n". The uncompressed message is "So long and thanks for all the fish!\n".
4.1.4 DEFLATE 4.1.4 DEFLATE
This section provides UDVM bytecode for the DEFLATE compression This section provides UDVM bytecode for the DEFLATE compression
algorithm. DEFLATE is the algorithm used in the well-known "gzip" algorithm. DEFLATE is the algorithm used in the well-known "gzip"
file format. file format.
The following bytecode will decompress the DEFLATE compressed data The following bytecode will decompress the DEFLATE compressed data
format DEFLATE [10] with the following modifications: format [10] with the following modifications:
1. The DEFLATE compressed data format separates blocks of compressed 1. The DEFLATE compressed data format separates blocks of compressed
data by transmitting 7 consecutive zero bits. Each SigComp data by transmitting 7 consecutive zero bits. Each SigComp
message is assumed to contain a separate block of compressed message is assumed to contain a separate block of compressed
data, so the end-of-block bits are implicit and do not need to be data, so the end-of-block bits are implicit and do not need to be
transmitted at the end of a SigComp message. transmitted at the end of a SigComp message.
2. This bytecode supports only DEFLATE block type 01 (data 2. This bytecode supports only DEFLATE block type 01 (data
compressed with fixed Huffman codes). compressed with fixed Huffman codes).
Assembly for the DEFLATE decompressor is given below: Assembly for the DEFLATE decompressor is given below:
skipping to change at page 23, line 4 skipping to change at page 22, line 50
2, 9, 2, 13, 3, 17, 2, 9, 2, 13, 3, 17,
3, 25, 4, 33, 4, 49, 3, 25, 4, 33, 4, 49,
5, 65, 5, 97, 6, 129, 5, 65, 5, 97, 6, 129,
6, 193, 7, 257, 7, 385, 6, 193, 7, 257, 7, 385,
8, 513, 8, 769, 9, 1025, 8, 513, 8, 769, 9, 1025,
9, 1537, 10, 2049, 10, 3073, 9, 1537, 10, 2049, 10, 3073,
11, 4097, 11, 6145, 12, 8193, 11, 4097, 11, 6145, 12, 8193,
12, 12289, 13, 16385, 13, 24577) 12, 12289, 13, 16385, 13, 24577)
:decompress_sigcomp_message :decompress_sigcomp_message
INPUT-BITS (3, extra_length_bits, !)
INPUT-BITS (3, extra_length_bits, !)
:next_character :next_character
INPUT-HUFFMAN (index, end_of_message, 4, INPUT-HUFFMAN (index, end_of_message, 4,
7, 0, 23, length_table_start, 7, 0, 23, length_table_start,
1, 48, 191, 0, 1, 48, 191, 0,
0, 192, 199, length_table_mid, 0, 192, 199, length_table_mid,
1, 400, 511, 144) 1, 400, 511, 144)
COMPARE ($index, length_table_start, literal, end_of_message, COMPARE ($index, length_table_start, literal, end_of_message,
length_distance) length_distance)
skipping to change at page 27, line 4 skipping to change at page 26, line 49
MULTIPLY ($index, 3) MULTIPLY ($index, 3)
ADD ($index, first_codeword) ADD ($index, first_codeword)
COPY ($index, 3, length_value_lsb) COPY ($index, 3, length_value_lsb)
LOAD (current_length, 1) LOAD (current_length, 1)
ADD ($current_length, $length_value) ADD ($current_length, $length_value)
LOAD (codebook_old, $codebook_next) LOAD (codebook_old, $codebook_next)
COPY-LITERAL (current_length_lsb, 3, $codebook_next) COPY-LITERAL (current_length_lsb, 3, $codebook_next)
COPY-LITERAL ($position_value, $length_value, $decompressed_pointer) COPY-LITERAL ($position_value, $length_value, $decompressed_pointer)
OUTPUT ($position_value, $length_value) OUTPUT ($position_value, $length_value)
JUMP (prefix_after_codeword) JUMP (prefix_after_codeword)
:string_extension
:string_extension
; The following code decompresses a Huffman-encoded string extension: ; The following code decompresses a Huffman-encoded string extension:
INPUT-HUFFMAN (index, !, 4, 1, 1, 1, 1, 2, 1, 3, 2, 1, 1, 1, 13, 3, INPUT-HUFFMAN (index, !, 4, 1, 1, 1, 1, 2, 1, 3, 2, 1, 1, 1, 13, 3,
0, 7, 5) 0, 7, 5)
COMPARE ($index, 13, continue, extra_bits, extra_bits) COMPARE ($index, 13, continue, extra_bits, extra_bits)
:extra_bits :extra_bits
INPUT-BITS (max_extension_length, extra_extension_bits, !) INPUT-BITS (max_extension_length, extra_extension_bits, !)
ADD ($index, $extra_extension_bits) ADD ($index, $extra_extension_bits)
skipping to change at page 28, line 4 skipping to change at page 27, line 50
INPUT-BYTES (0, 0, 0) INPUT-BYTES (0, 0, 0)
JUMP (standard_prefix) JUMP (standard_prefix)
:stepup :stepup
; The STEPUP control character increases the number of bits used to ; The STEPUP control character increases the number of bits used to
; encode an ordinal value or a codeword: ; encode an ordinal value or a codeword:
INPUT-BITS (1, index, !) INPUT-BITS (1, index, !)
COMPARE ($index, 1, stepup_ordinal, stepup_codeword, 0) COMPARE ($index, 1, stepup_ordinal, stepup_codeword, 0)
:stepup_ordinal
:stepup_ordinal
ADD ($ordinal_length, 1) ADD ($ordinal_length, 1)
JUMP (ordinal) JUMP (ordinal)
:stepup_codeword :stepup_codeword
ADD ($codeword_length, 1) ADD ($codeword_length, 1)
JUMP (codeword_control) JUMP (codeword_control)
:end_of_message :end_of_message
skipping to change at page 31, line 38 skipping to change at page 31, line 37
The uncompressed message is "Arthur leapt to his feet like an author The uncompressed message is "Arthur leapt to his feet like an author
hearing the phone ring". hearing the phone ring".
5. Additional SigComp mechanisms 5. Additional SigComp mechanisms
The following chapter covers the additional mechanisms that can be The following chapter covers the additional mechanisms that can be
employed by SigComp to improve the overall compression ratio; employed by SigComp to improve the overall compression ratio;
including the use of acknowledgements, dictionaries and sharing state including the use of acknowledgements, dictionaries and sharing state
between two directions of a compressed message flow. between two directions of a compressed message flow.
When each of the compression algorithms described in Chapter 4 has Example assembly code is provided for these mechanisms. Depending on
the mechanism and basic algorithm in use, the assembly code for
either the mechanism or the basic algorithm may require modification
(e.g. if the algorithm uses 'no more input' to jump to
end_of_message, following end_of_message with an input instruction
for CRC will not work). In any case, these are examples and there
may be alternative ways to make use of the mechanisms.
When each of the compression algorithms described in Section 4 has
successfully decompressed the current SigComp message, the contents successfully decompressed the current SigComp message, the contents
of the UDVM memory are saved as a SigComp state item. Subsequent of the UDVM memory are saved as a SigComp state item. Subsequent
messages can access this state item by uploading the correct state messages can access this state item by uploading the correct state
identifier to the receiving endpoint, which avoids the need to upload identifier to the receiving endpoint, which avoids the need to upload
the bytecode for the compression algorithm on a per-message basis. the bytecode for the compression algorithm on a per-message basis.
However, before a state item can be accessed the compressor must However, before a state item can be accessed the compressor must
first ensure that it is available at the receiving endpoint. first ensure that it is available at the receiving endpoint.
For each SigComp compartment, the receiving endpoint maintains a list For each SigComp compartment, the receiving endpoint maintains a list
of currently available states (where the total amount of state saved of currently available states (where the total amount of state saved
does not exceed the state_memory_size for the compartment). The does not exceed the state_memory_size for the compartment). The
SigComp compressor should maintain a similar list containing the SigComp compressor should maintain a similar list containing the
states that it has instructed the receiving endpoint to save. states that it has instructed the receiving endpoint to save.
As well as tracking the list of state items that it has saved at the As well as tracking the list of state items that it has saved at the
skipping to change at page 33, line 47 skipping to change at page 34, line 7
and SDP RFC-3485 [6]. This dictionary is designed for use by a wide and SDP RFC-3485 [6]. This dictionary is designed for use by a wide
range of compression algorithms including all of the ones covered in range of compression algorithms including all of the ones covered in
Chapter 4. Chapter 4.
In any of the compression algorithms of Chapter 4, the static In any of the compression algorithms of Chapter 4, the static
dictionary can be accessed by inserting the following instruction dictionary can be accessed by inserting the following instruction
immediately after the ":initialize_memory" label: immediately after the ":initialize_memory" label:
STATE-ACCESS (dictionary_id, 6, 0, 0, 1024, 0) STATE-ACCESS (dictionary_id, 6, 0, 0, 1024, 0)
The parameters of STATE-ACCESS instruction will depend on the
compression algorithm in use.
The following lines should also be inserted immediately after the The following lines should also be inserted immediately after the
END-MESSAGE instruction: END-MESSAGE instruction:
:dictionary_id :dictionary_id
byte (0xfb, 0xe5, 0x07, 0xdf, 0xe5, 0xe6) byte (0xfb, 0xe5, 0x07, 0xdf, 0xe5, 0xe6)
The text strings contained in the static dictionary can then be The text strings contained in the static dictionary can then be
accessed in exactly the same manner as the text strings from accessed in exactly the same manner as the text strings from
previously decompressed messages (see Section 5.1 for further previously decompressed messages (see Section 5.1 for further
details). details).
Note that in some cases it is sufficient to only load part of the Note that in some cases it is sufficient to only load part of the
static dictionary into the UDVM memory. Further information on the static dictionary into the UDVM memory. Further information on the
contents of the SIP and SDP static dictionary can be found in the contents of the SIP and SDP static dictionary can be found in the
relevant document RFC-3485 [6]. relevant document RFC-3485 [6].
5.3 CRC checksum 5.3 CRC checksum
Whilst the acknowledgement scheme of Section 5.1 is designed to The acknowledgement scheme of Section 5.1 is designed to indicate the
ensure that SigComp does not propagate errors introduced by the successful decompression of a message. However, it does not
underlying transport layer, in some cases it may be useful to add an guarantee that the decompressed message is identical to the original
extra CRC check over the UDVM memory. For example, if the transport message, since decompression of a corrupted message could succeed but
layer fails to discard a damaged SigComp message then a CRC check can with some characters being incorrect. This could lead to an
ensure that the corresponding decompressed message is not forwarded incorrect message being passed to the application or unexpected
to the application. contents of state to be stored. In order to prevent this happening a
CRC check could be used.
If an additional CRC check is required then the following bytecode If an additional CRC check is required then the following bytecode
can be inserted after the ":end_of_message" label: can be inserted after the ":end_of_message" label:
INPUT-BYTES (2, index, !) INPUT-BYTES (2, index, !)
CRC ($index, 64, state_length, !) CRC ($index, 64, state_length, !)
The bytecode extracts a 2-byte CRC from the end of the SigComp The bytecode extracts a 2-byte CRC from the end of the SigComp
message and compares it with a CRC calculated over the UDVM memory. message and compares it with a CRC calculated over the UDVM memory.
Decompression failure occurs if the two CRC values do not match. Decompression failure occurs if the two CRC values do not match.
skipping to change at page 35, line 16 skipping to change at page 35, line 27
useful for the remote endpoint to reference, it can advertise the useful for the remote endpoint to reference, it can advertise the
identifiers for the states. The remote endpoint can then make use of identifiers for the states. The remote endpoint can then make use of
any that it also knows about (i.e. knows the contents of) e.g. a any that it also knows about (i.e. knows the contents of) e.g. a
dictionary or shared mode state (see Section 5.5). dictionary or shared mode state (see Section 5.5).
The values of the following SigComp parameters can be announced using The values of the following SigComp parameters can be announced using
the SigComp advertisement mechanism: the SigComp advertisement mechanism:
cycles_per_bit cycles_per_bit
decompression_memory_size decompression_memory_size
state_memory_size> state_memory_size
SigComp_version SigComp_version
state identifiers state identifiers
As explained in SigComp, in order to announce the values of these As explained in SigComp, in order to announce the values of these
parameters the following fields must be reserved in the UDVM memory: parameters the following fields must be reserved in the UDVM memory:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| cpb | dms | sms | returned_parameters_location | cpb | dms | sms | returned_parameters_location
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
skipping to change at page 37, line 13 skipping to change at page 37, line 39
Firstly, it is necessary to announce to the remote endpoint that Firstly, it is necessary to announce to the remote endpoint that
shared compression is available. This is done by announcing the shared compression is available. This is done by announcing the
state identifier as an available piece of state. This can be done state identifier as an available piece of state. This can be done
using the returned_parameters_location announcement as in using the returned_parameters_location announcement as in
Section 5.4. Section 5.4.
Secondly, assuming that such an announcement is received from the Secondly, assuming that such an announcement is received from the
remote endpoint, then the state created by shared compression needs remote endpoint, then the state created by shared compression needs
to be accessed by the message sent in the opposite direction. This to be accessed by the message sent in the opposite direction. This
can be done in a similar way to accessing the static dictionary (see can be done in a similar way to accessing the static dictionary (see
Section Section 5.2), but using the appropriate state identifier, for Section 5.2), but using the appropriate state identifier, for
example, by using the INPUT-BYTES instruction as below: example, by using the INPUT-BYTES instruction as below:
:shared_state_id pad (6) :shared_state_id pad (6)
:access_shared_state :access_shared_state
INPUT-BYTES (6, shared_state_id, !) INPUT-BYTES (6, shared_state_id, !)
STATE-ACCESS (shared_state_id, 6, 0, 0, $decompressed_start, 0) STATE-ACCESS (shared_state_id, 6, 0, 0, $decompressed_start, 0)
6. Security considerations 6. Security considerations
skipping to change at page 42, line 50 skipping to change at page 42, line 50
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
This Internet-Draft will expire on April 1, 2006. This Internet-Draft will expire on April 27, 2006.
 End of changes. 23 change blocks. 
37 lines changed or deleted 52 lines changed or added

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