draft-ietf-rohc-sigcomp-user-guide-04.txt   rfc4464.txt 
Robust Header Compression A. Surtees Network Working Group A. Surtees
Internet-Draft M. West Request for Comments: 4464 M. West
Expires: April 27, 2006 Siemens/Roke Manor Research Category: Informational Siemens/Roke Manor Research
October 24, 2005 Signaling Compression (SigComp) Users' Guide
SigComp Users' Guide
draft-ietf-rohc-sigcomp-user-guide-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2006. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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 Signaling Compression (SigComp) protocol. The aim of the document is
making SigComp implementation decisions; for example the choice of to assist users when making SigComp implementation decisions, for
compression algorithm and the level of robustness against lost or example, the choice of compression algorithm and the level of
misordered packets. robustness against lost or misordered packets.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Overview of the User Guide . . . . . . . . . . . . . . . . . . 3 2. Overview of the User Guide ......................................3
3. UDVM assembly language . . . . . . . . . . . . . . . . . . . . 4 3. UDVM Assembly Language ..........................................4
3.1 Lexical level . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Lexical Level ..............................................4
3.2 Syntactic level . . . . . . . . . . . . . . . . . . . . . 5 3.2. Syntactic Level ............................................5
3.2.1 Expressions . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Expressions .........................................7
3.2.2 Instructions . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. Instructions ........................................8
3.2.3 Directives . . . . . . . . . . . . . . . . . . . . . . 9 3.2.3. Directives ..........................................9
3.2.4 Labels . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.4. Labels .............................................10
3.3 Uploading the bytecode to the UDVM . . . . . . . . . . . . 10 3.3. Uploading the Bytecode to the UDVM ........................11
4. Compression algorithms . . . . . . . . . . . . . . . . . . . . 12 4. Compression Algorithms .........................................12
4.1 Well-known Compression Algorithms . . . . . . . . . . . . 12 4.1. Well-known Compression Algorithms .........................12
4.1.1 Simplified LZ77 . . . . . . . . . . . . . . . . . . . 12 4.1.1. LZ77 ...............................................12
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 . . . . . . . . . . . . . 35 5.4. Announcing Additional Resources ...........................35
5.5 Shared compression . . . . . . . . . . . . . . . . . . . . 37 5.5. Shared Compression ........................................37
6. Security considerations . . . . . . . . . . . . . . . . . . . 38 6. Security Considerations ........................................38
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 7. Acknowledgements ...............................................38
8. Intellectual Property Right Considerations . . . . . . . . . . 38 8. Intellectual Property Right Considerations .....................38
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 9. Informative References .........................................38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39 Appendix A. UDVM Bytecode for the Compression Algorithms ..........40
A. UDVM bytecode for the compression algorithms . . . . . . . . . 39 A.1. Well-known Algorithms .....................................40
A.1 Well-known Algorithms . . . . . . . . . . . . . . . . . . 40 A.1.1. LZ77 ..............................................40
A.1.1 Simplified LZ77 . . . . . . . . . . . . . . . . . . . 40 A.1.2. LZSS ..............................................40
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 ..............................................41
A.1.5 LZJH . . . . . . . . . . . . . . . . . . . . . . . . . 40 A.2. Adapted Algorithms ........................................41
A.2 Adapted Algorithms . . . . . . . . . . . . . . . . . . . . 41 A.2.1. Modified DEFLATE ...................................41
A.2.1 Modified DEFLATE . . . . . . . . . . . . . . . . . . . 41
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 [2]. 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 [8] and LZW [7]. The bytecode for the chosen
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 gives examples of a number of different compressors This document gives examples of a number of different compressors
that can be used by the SigComp protocol. It also gives examples of that can be used by the SigComp protocol. It also gives examples of
how to use some of the mechanisms (such as acknowledgements) how to use some of the mechanisms (such as acknowledgements)
described in RFC 3321 [5]. described in RFC 3321 [3].
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 suitable bytecode has been
for the corresponding decompressor. written for the corresponding decompressor.
This document provides example bytecode for the following algorithms: This document provides example bytecode for the following algorithms:
1. Simplified LZ77
1. LZ77
2. LZSS 2. LZSS
3. LZW 3. LZW
4. DEFLATE 4. DEFLATE
5. LZJH 5. LZJH
Any of the above algorithms may be useful depending on the desired Any of the above algorithms may be useful depending on the desired
compression ratio, processing and memory requirements, code size, compression ratio, processing and memory requirements, code size,
implementation complexity and Intellectual Property (IPR) implementation complexity, and Intellectual Property (IPR)
considerations. considerations.
As well as encoding the application messages using the chosen As well as encoding the application messages using the chosen
algorithm, the SigComp compressor is responsible for ensuring that algorithm, the SigComp compressor is responsible for ensuring that
messages can be correctly decompressed even if packets are lost or messages can be correctly decompressed even if packets are lost or
misordered during transmission. The SigComp feedback mechanism can misordered during transmission. The SigComp feedback mechanism can
be used to acknowledge successful decompression at the remote be used to acknowledge successful decompression at the remote
endpoint. endpoint.
The following robustness techniques and other mechanisms specific to The following robustness techniques and other mechanisms specific to
skipping to change at page 4, line 8 skipping to change at page 4, line 9
As well as encoding the application messages using the chosen As well as encoding the application messages using the chosen
algorithm, the SigComp compressor is responsible for ensuring that algorithm, the SigComp compressor is responsible for ensuring that
messages can be correctly decompressed even if packets are lost or messages can be correctly decompressed even if packets are lost or
misordered during transmission. The SigComp feedback mechanism can misordered during transmission. The SigComp feedback mechanism can
be used to acknowledge successful decompression at the remote be used to acknowledge successful decompression at the remote
endpoint. endpoint.
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. Cyclic redundancy code (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. An example subroutine of UDVM with the chosen compression algorithm. An example subroutine of UDVM
bytecode is provided for each of the mechanisms; these subroutines bytecode is provided for each of the mechanisms; these subroutines
can be added to the bytecode for one of the basic compression can be added to the bytecode for one of the basic compression
algorithms. (NB. The subroutine or the basic algorithm may require algorithms. (Note: The subroutine or the basic algorithm may require
minor modification to ensure they work together correctly.) 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.
The syntax of the UDVM assembly language uses the customary two-level The syntax of the UDVM assembly language uses the customary two-level
description technique, partitioning the grammar into a lexical and a description technique, partitioning the grammar into a lexical and a
syntactical level. syntactic level.
3.1 Lexical level 3.1. Lexical Level
On a lexical level, a string of assembly consists of zero or more On a lexical level, a string of assembly consists of zero or more
tokens optionally separated by whitespace. Each token can be a text tokens optionally separated by whitespace. Each token can be a text
name, an instruction opcode, a delimiter, or an integer (specified as name, an instruction opcode, a delimiter, or an integer (specified as
decimal, binary or hex). decimal, binary, or hex).
The following ABNF description RFC-2234 [3] specifies the syntax of a The following ABNF description, RFC 4234 [1], specifies the syntax of
token: a token:
token = (name / opcode / delimiter / dec / bin / hex) token = (name / opcode / delimiter / dec / bin / hex)
name = (lowercase / "_") 0*(lowercase / digit / "_") name = (lowercase / "_") 0*(lowercase / digit / "_")
opcode = uppercase *(uppercase / digit / "-") opcode = uppercase *(uppercase / digit / "-")
delimiter = "." / "," / "!" / "$" / ":" / "(" / ")" / delimiter = "." / "," / "!" / "$" / ":" / "(" / ")" /
operator operator
dec = 1*(digit) dec = 1*(digit)
bin = "0b" 1*("0" / "1") bin = "0b" 1*("0" / "1")
hex = "0x" 1*(hex_digit) hex = "0x" 1*(hex-digit)
hex_digit = digit / %x41-46 / %x61-66 hex-digit = digit / %x41-46 / %x61-66
digit = %x30-39 digit = %x30-39
uppercase = %x41-5a uppercase = %x41-5a
lowercase = %x61-7a lowercase = %x61-7a
operator = "+" / "-" / "*" / "/" / "%" / "&" / "|" / operator = "+" / "-" / "*" / "/" / "%" / "&" / "|" /
"^" / "~" / "<<" / ">>" "^" / "~" / "<<" / ">>"
When parsing for tokens a longest match is applied, i.e. a token is When parsing for tokens, the longest match is applied, i.e., a token
the longest string that matches the <token> rule specified above. is the longest string that matches the <token> rule specified above.
The syntax of whitespace and comments is specified by the following The syntax of whitespace and comments is specified by the following
ABNF: ABNF:
ws = *(%x09 / %x0a / %x0d / %x20 / comment) ws = *(%x09 / %x0a / %x0d / %x20 / comment)
comment = ";" *(%x00-09 / %x0b-0c / %x0e-ff) comment = ";" *(%x00-09 / %x0b-0c / %x0e-ff)
(%x0a / %x0d) (%x0a / %x0d)
Whitespace that matches <ws> is skipped between tokens, but serves to Whitespace that matches <ws> is skipped between tokens, but serves to
terminate the longest match for a token. terminate the longest match for a token.
Comments are specified by the symbol ";" and are terminated by the Comments are specified by the symbol ";" and are terminated by the
end of the line, for example: end of the line, for example:
LOAD (temp, 1) ; This is a comment. LOAD (temp, 1) ; This is a comment.
Any other input is a syntax error. Any other input is a syntax error.
When parsing on the lexical level the string of assembly should be When parsing on the lexical level, the string of assembly should be
divided up into a list of successive tokens. The whitespace and divided up into a list of successive tokens. The whitespace and
comments should also be deleted. The assembly should then be parsed comments should also be deleted. The assembly should then be parsed
on the syntactic level as explained in Section 3.2. on the syntactic level as explained in Section 3.2.
3.2 Syntactic level 3.2. Syntactic Level
Once the string of assembly has been divided into tokens as per Once the string of assembly has been divided into tokens as per
Section 3.1, the next step is to convert the assembly into a string Section 3.1, the next step is to convert the assembly into a string
of UDVM bytecode. of UDVM bytecode.
On a syntactic level, a string of assembly consists of zero or more On a syntactic level, a string of assembly consists of zero or more
instructions, directives or labels, each of which is itself built up instructions, directives, or labels, each of which is itself built up
from one or more lexical tokens. from one or more lexical tokens.
The following ABNF description specifies the syntax of the assembly The following ABNF description specifies the syntax of the assembly
language. Note that the lexical parsing step is assumed to have been language. Note that the lexical parsing step is assumed to have been
carried out, so in particular the boundaries between tokens are carried out; so in particular, the boundaries between tokens are
already known and the comments and whitespace have been deleted: already known, and the comments and whitespace have been deleted:
assembly = *(instruction / directive / label) assembly = *(instruction / directive / label)
instruction = opcode ["(" operand *("," operand) ")"] instruction = opcode ["(" operand *("," operand) ")"]
operand = [["$"] expression] operand = [["$"] expression]
; Operands can be left blank if they can ; Operands can be left blank if they can
; be automatically inferred by the ; be automatically inferred by the
; compiler, e.g. a literal operand ; compiler, e.g., a literal operand
; that specifies the total number of ; that specifies the total number of
; operands for the instruction. ; operands for the instruction.
; When "$" is prepended to an operand, ; When "$" is prepended to an operand,
; the corresponding integer is an ; the corresponding integer is an
; address rather than the actual operand ; address rather than the actual operand
; value. This symbol is mandatory for ; value. This symbol is mandatory for
; reference operands, optional for ; reference operands, optional for
; multitypes and addresses, and ; multitypes and addresses, and
; disallowed for literals. ; disallowed for literals.
label = ":" name label = ":" name
directive = padding / data / set / readonly / directive = padding / data / set / readonly /
unknown_directive unknown-directive
unknown_directive = name ["(" expression *("," expression) ")"] unknown-directive = name ["(" expression *("," expression) ")"]
; The parser can ignore unknown ; The parser can ignore unknown
; directives. The resulting bytecode ; directives. The resulting bytecode
; may or may not generate the expected ; may or may not generate the expected
; results. ; results.
padding = ("pad" / "align" / "at") "(" expression ")" padding = ("pad" / "align" / "at") "(" expression ")"
data = ("byte" / "word") "(" expression *("," data = ("byte" / "word") "(" expression *(","
expression) ")" expression) ")"
readonly = "readonly" "(" "0" / "1" ")" readonly = "readonly" "(" "0" / "1" ")"
set = "set" "(" name "," expression ")" set = "set" "(" name "," expression ")"
expression = value / "(" expression operator expression ")" expression = value / "(" expression operator expression ")"
value = dec / bin / hex / name / "." / "!" value = dec / bin / hex / name / "." / "!"
; "." is the location of this ; "." is the location of this
; instruction/directive, whereas "!" is ; instruction/directive, whereas "!" is
; the location of the closest ; the location of the closest
; DECOMPRESSION-FAILURE ; DECOMPRESSION-FAILURE
The following sections define how to convert the instructions, labels The following sections define how to convert the instructions, labels
and directives into UDVM bytecode: and directives into UDVM bytecode:
3.2.1 Expressions 3.2.1. Expressions
The operand values needed by particular instructions or directives The operand values needed by particular instructions or directives
can be given in the form of expressions. An expression can include can be given in the form of expressions. An expression can include
one or more values specified as decimal, binary or hex (binary values one or more values specified as decimal, binary, or hex (binary
are preceded by "0b" and hex values are preceded by "0x"). The values are preceded by "0b" and hex values are preceded by "0x").
expression may also include one or more of the following operators: The expression may also include one or more of the following
operators:
"+" Addition "+" Addition
"-" Subtraction "-" Subtraction
"*" Multiplication "*" Multiplication
"/" Integer division "/" Integer division
"%" Modulo arithmetic (a%b := a modulo b) "%" Modulo arithmetic (a%b := a modulo b)
"&" Binary AND "&" Binary AND
"|" Binary OR "|" Binary OR
"^" Binary XOR "^" Binary XOR
"~" Binary XNOR "~" Binary XNOR
skipping to change at page 7, line 35 skipping to change at page 7, line 36
The operands for each operator must always be surrounded by The operands for each operator must always be surrounded by
parentheses so that the order in which the operators should be parentheses so that the order in which the operators should be
evaluated is clear. For example: evaluated is clear. For example:
((1 + (2 * 3)) & (0xabcd - 0b00101010)) gives the result 3. ((1 + (2 * 3)) & (0xabcd - 0b00101010)) gives the result 3.
Expressions can also include the special values "." and "!". When Expressions can also include the special values "." and "!". When
the symbol "." is encountered, it is replaced by the location in the the symbol "." is encountered, it is replaced by the location in the
bytecode of the current instruction/directive. When the symbol "!" bytecode of the current instruction/directive. When the symbol "!"
is encountered it is replaced by the location in the bytecode of the is encountered it is replaced by the location in the bytecode of the
closest DECOMPRESSION-FAILURE instruction (i.e. the closest zero closest DECOMPRESSION-FAILURE instruction (i.e., the closest zero
byte). This can be useful when writing UDVM instructions that call a byte). This can be useful when writing UDVM instructions that call a
decompression failure, for example: decompression failure, for example:
INPUT-BYTES (1, temp, !) INPUT-BYTES (1, temp, !)
The above instruction causes a decompression failure to occur if it The above instruction causes a decompression failure to occur if it
tries to input data from beyond the end of the compressed message. tries to input data from beyond the end of the compressed message.
N.B. When using "!" in the assembly language to generate bytecode, Note: When using "!" in the assembly language to generate bytecode,
care must be taken to ensure that the address of the zero used at care must be taken to ensure that the address of the zero used at
bytecode generation time will still contain zero when the bytecode is bytecode generation time will still contain zero when the bytecode is
run. The readonly directive (see Section 3.2.3) can be used to do run. The readonly directive (see Section 3.2.3) can be used to do
this. this.
It is also possible to assign integer values to text names: when a It is also possible to assign integer values to text names: when a
text name is encountered in an expression it is replaced by the text name is encountered in an expression, it is replaced by the
integer value assigned to it. Section 3.2.3 explains how to assign integer value assigned to it. Section 3.2.3 explains how to assign
integer values to text names. integer values to text names.
3.2.2 Instructions 3.2.2. Instructions
A UDVM instruction is specified by the instruction opcode followed by A UDVM instruction is specified by the instruction opcode followed by
zero or more operands. The instruction operands are enclosed in zero or more operands. The instruction operands are enclosed in
parentheses and separated by commas, for example: parentheses and separated by commas, for example:
ADD (3, 4) ADD ($3, 4)
When generating the bytecode the parser should replace the When generating the bytecode, the parser should replace the
instruction opcode with the corresponding 1-byte value as per Figure instruction opcode with the corresponding 1-byte value as per Figure
11 of SigComp [4]. 11 of SigComp [2].
Each operand consists of an expression which evaluates to an integer, Each operand consists of an expression that evaluates to an integer,
optionally preceded by the symbol "$". This symbol indicates that optionally preceded by the symbol "$". This symbol indicates that
the supplied integer value must be interpreted as the memory address the supplied integer value must be interpreted as the memory address
at which the operand value can be found, rather than the actual at which the operand value can be found, rather than the actual
operand value itself. operand value itself.
When converting each instruction operand to bytecode, the parser When converting each instruction operand to bytecode, the parser
first determines whether the instruction expects the operand to be a first determines whether the instruction expects the operand to be a
literal, a reference, a multitype or an address. If the operand is a literal, a reference, a multitype, or an address. If the operand is
literal then as per Figure 8 of SigComp, the parser inserts bytecode a literal, then, as per Figure 8 of SigComp, the parser inserts
(usually the shortest) capable of encoding the supplied operand bytecode (usually the shortest) capable of encoding the supplied
value. operand value.
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 (usually 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.
If the operand is an address then the parser checks whether the If the operand is an address, then the parser checks whether the
symbol "$" is present. If so then the supplied integer is encoded as symbol "$" is present. If so, then the supplied integer is encoded
a memory address, just as for the multitype instruction above. If as a memory address, just as for the multitype instruction above. If
not then the byte position of the opcode is subtracted from the not, then the byte position of the opcode is subtracted from the
supplied integer modulo 16, and the result is encoded as an operand supplied integer modulo 16, and the result is encoded as an operand
value as per Figure 10 of SigComp. value as per Figure 10 of SigComp.
The length of the resulting bytecode is dependent on the parser in The length of the resulting bytecode is dependent on the parser in
use. There can be several correct and useable representations of the use. There can be several correct and usable representations of the
same instruction. same instruction.
3.2.3 Directives 3.2.3. Directives
The assembly language provides a number of directives for evaluating The assembly language provides a number of directives for evaluating
expressions, moving instructions to a particular memory address etc. expressions, moving instructions to a particular memory address, etc.
The directives "pad", "align" and "at" can be used to add padding to The directives "pad", "align", and "at" can be used to add padding to
the bytecode. the bytecode.
The directive "pad (n)" appends n consecutive padding bytes to the The directive "pad (n)" appends n consecutive padding bytes to the
bytecode. The actual value of the padding bytes is unimportant, so bytecode. The actual value of the padding bytes is unimportant, so
when the bytecode is uploaded to the UDVM the padding bytes can be when the bytecode is uploaded to the UDVM, the padding bytes can be
set to the initial values contained in the UDVM memory (this helps to set to the initial values contained in the UDVM memory (this helps to
reduce the size of a SigComp message). reduce the size of a SigComp message).
The directive "align (n)" appends the minimum number of padding bytes The directive "align (n)" appends the minimum number of padding bytes
to the bytecode such that the total bytecode generated so far is to the bytecode such that the total number of bytes of bytecode
aligned to a multiple of n bytes. If the bytecode is already aligned generated so far is a multiple of n bytes. If the bytecode is
to a multiple of n bytes then no padding bytes are added. already aligned to a multiple of n bytes, then no padding bytes are
added.
The directive "at (n)" appends enough padding bytes to the bytecode The directive "at (n)" appends enough padding bytes to the bytecode
such that the total bytecode generated so far is exactly n bytes. If such that the total number of bytes of bytecode generated so far is
more than n bytes have already been generated before the "at" exactly n bytes. If more than n bytes have already been generated
directive is encountered then the assembly code contains an error. before the "at" directive is encountered then the assembly code
contains an error.
The directives "byte" and "word" can be used to add specific data The directives "byte" and "word" can be used to add specific data
strings to the bytecode. strings to the bytecode.
The directive "byte (n[0],..., n[k-1])" appends k consecutive bytes The directive "byte (n[0],..., n[k-1])" appends k consecutive bytes
to the bytecode. The byte string is supplied as expressions which to the bytecode. The byte string is supplied as expressions that
evaluate to give integers n[0],..., n[k-1] from 0 to 255. evaluate to give integers n[0],..., n[k-1] from 0 to 255.
The directive "word (n[0],..., n[k-1])" appends k consecutive 2-byte The directive "word (n[0],..., n[k-1])" appends k consecutive 2-byte
words to the bytecode. The word string is supplied as expressions words to the bytecode. The word string is supplied as expressions
which evaluate to give integers n[0],..., n[k-1] from 0 to 65535. that evaluate to give integers n[0],..., n[k-1] from 0 to 65535.
The directive "set (name, n)" assigns an integer value n to a The directive "set (name, n)" assigns an integer value n to a
specified text name. The integer value can be supplied in the form specified text name. The integer value can be supplied in the form
of an expression. of an expression.
The directive "readonly (n)" where n is 0 or 1 can be used to The directive "readonly (n)" where n is 0 or 1 can be used to
indicate that an area of memory could be changed (0) or will not be indicate that an area of memory could be changed (0) or will not be
changed (1) during the execution of the UDVM. This directive could changed (1) during the execution of the UDVM. This directive could
be used, for example, in conjunction with "!" to ensure that the be used, for example, in conjunction with "!" to ensure that the
address of the zero used will still contain zero when the bytecode is address of the zero used will still contain zero when the bytecode is
executed. If no readonly directive is used, then any address executed. If no readonly directive is used, then any address
containing zero can be used by "!" (i.e. by default there is assumed containing zero can be used by "!" (i.e., by default, there is
to be readonly(1) directive at address 0) and it is up to the author assumed to be a readonly (1) directive at Address 0) and it is up to
of the assembly code to ensure that the address in question will the author of the assembly code to ensure that the address in
still contain zero when the bytecode is executed. If the readonly question will still contain zero when the bytecode is executed. If
directive is used, then bytes between a readonly (0) and readonly (1) the readonly directive is used, then bytes between a readonly (0) and
pair are NOT to be used by "!". When a readonly directive has been readonly (1) pair are NOT to be used by "!". When a readonly
used, the bytes obey that directive from that address to either directive has been used, the bytes obey that directive from that
another readonly directive or the end of UDVM memory, whichever comes address to either another readonly directive or the end of UDVM
first. memory, whichever comes first.
3.2.4 Labels 3.2.4. Labels
A label is a special directive used to assign memory addresses to A label is a special directive used to assign memory addresses to
text names. text names.
Labels are specified by giving a single colon followed by the text Labels are specified by a single colon followed by the text name to
name to be defined. The (absolute) position of the byte immediately be defined. The (absolute) position of the byte immediately
following the label is evaluated and assigned to the text name. For following the label is evaluated and assigned to the text name. For
example: example:
:start :start
LOAD (temp, 1) LOAD (temp, 1)
Since the label "start" occurs at the beginning of the bytecode, it Since the label "start" occurs at the beginning of the bytecode, it
is assigned the integer value 0. is assigned the integer value 0.
Note that writing the label ":name" has exactly the same behavior as Note that writing the label ":name" has exactly the same behavior as
writing the directive "set (name, .)". writing the directive "set (name, .)".
3.3 Uploading the bytecode to the UDVM 3.3. Uploading the Bytecode to the UDVM
Once the parser has converted a string of assembly into the Once the parser has converted a string of assembly into the
corresponding bytecode, it must be copied to the UDVM memory corresponding bytecode, it must be copied to the UDVM memory
beginning at Address 0 and then executed beginning from the first beginning at Address 0 and then executed, beginning from the first
UDVM instruction in the bytecode. UDVM instruction in the bytecode.
SigComp provides the following message format for uploading bytecode SigComp provides the following message format for uploading bytecode
to the UDVM: to the UDVM:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | T | 0 | | 1 1 1 1 1 | T | 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
skipping to change at page 11, line 32 skipping to change at page 11, line 38
: uploaded UDVM bytecode : : uploaded UDVM bytecode :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: remaining SigComp message : : remaining SigComp message :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
The destination field should be set to the memory address of the The destination field should be set to the memory address of the
first UDVM instruction. Note that if this address cannot be first UDVM instruction. Note that if this address cannot be
represented by the destination field then the bytecode cannot be represented by the destination field, then the bytecode cannot be
uploaded to the UDVM using the standard SigComp header. In uploaded to the UDVM using the standard SigComp header. In
particular, the memory address of the first UDVM instruction must particular, the memory address of the first UDVM instruction must
always be a multiple of 64 bytes or the standard SigComp header always be a multiple of 64 bytes or the standard SigComp header
cannot be used. Of course, there may be other ways to upload the cannot be used. Of course, there may be other ways to upload the
bytecode to the UDVM, such as retrieving the bytecode directly via bytecode to the UDVM, such as retrieving the bytecode directly via
the INPUT-BYTES instruction. the INPUT-BYTES instruction.
Additionally, all memory addresses between Address 0 and Address 31 Additionally, all memory addresses between Address 0 and Address 31
inclusive are initialized to endpoint-specific values by the UDVM, so inclusive are initialized to endpoint-specific values by the UDVM, so
they must be specified as padding in the bytecode or the standard they must be specified as padding in the bytecode, or the standard
SigComp header cannot be used. Memory addresses from Address 32 to SigComp header cannot be used. Memory addresses from Address 32 to
Address (destination - 1) inclusive are initialized to 0, so they Address (destination - 1) inclusive are initialized to 0, so they
must be specified either as padding or as 0s if the bytecode is to be must be specified either as padding or as 0s if the bytecode is to be
successfully uploaded using the standard SigComp header. successfully uploaded using the standard SigComp header.
The code_len field should be set to the smallest value such that all The code_len field should be set to the smallest value such that all
memory addresses beginning at Address (destination + code_len) are memory addresses beginning at Address (destination + code_len) are
either padding, set to 0 by the bytecode, or are beyond the total either as initialised by the UDVM (to 0) or as set by the bytecode at
length of the bytecode. runtime.
The "uploaded UDVM bytecode" should be set to contain the segment of The "uploaded UDVM bytecode" should be set to contain the segment of
bytecode that lies between Address (destination) and Address bytecode that lies between Address (destination) and Address
(destination + code_len - 1) inclusive. (destination + code_len - 1) inclusive.
4. Compression algorithms 4. Compression Algorithms
This chapter describes a number of compression algorithms that can be This section describes a number of compression algorithms that can be
used by a SigComp compressor. In each case the document provides used by a SigComp compressor. In each case, the document provides
UDVM bytecode for the corresponding decompression algorithm, which UDVM bytecode for the corresponding decompression algorithm, which
can be uploaded to the receiving endpoint as part of a SigComp can be uploaded to the receiving endpoint as part of a SigComp
message. Each algorithm (as written in this chapter) assumes that message. Each algorithm (as written in this section) assumes that
there is 16K decompression memory size, 16 cycles per bit and 8K there is a 16K decompression memory size, there are 16 cycles per
state memory size. Decompression will succeed with a smaller value bit, and there is an 8K state memory size. Decompression will
for state memory size, however, the full state will not be created. succeed with a smaller value for state memory size; however, the full
state will not be created.
Section 4.1.1 covers a simple algorithm in some detail, including the Section 4.1.1 covers a simple algorithm in some detail, including the
steps required to compress and decompress a SigComp message. The steps required to compress and decompress a SigComp message. The
remaining sections cover well-known compression algorithms that can remaining sections cover well-known compression algorithms that can
be adapted for use in SigComp with minimal modification. be adapted for use in SigComp with minimal modification.
4.1 Well-known Compression Algorithms 4.1. Well-known Compression Algorithms
4.1.1 Simplified LZ77 4.1.1. LZ77
This section describes how to implement a very simple compression This section describes how to implement a very simple compression
algorithm based on LZ77 [7]. algorithm based on LZ77 [5].
A compressed message generated by the simplified LZ77 scheme consists A compressed message generated by the simplified LZ77 scheme consists
of a sequence of 4-byte characters, where each character contains a of a sequence of 4-byte characters, where each character contains a
2-byte position value followed by a 2-byte length value. Each pair 2-byte position value followed by a 2-byte length value. Each pair
of integers identifies a byte string in the UDVM memory; when of integers identifies a byte string in the UDVM memory; when
concatenated these byte strings form the decompressed message. concatenated, these byte strings form the decompressed message.
When implementing a bytecode decompressor for the simplified LZ77 When implementing a bytecode decompressor for the simplified LZ77
scheme, the UDVM memory is partitioned into five distinct areas as scheme, the UDVM memory is partitioned into five distinct areas, as
shown below: shown below:
0 64 128 256 512 0 64 128 256 512
| scratch-pad | variables | bytecode | dictionary | circular buffer | | scratch-pad | variables | bytecode | dictionary | circular buffer |
+-------------+-----------+----------+------------+-----------------+ +-------------+-----------+----------+------------+-----------------+
<-----------> <---------> <--------> <----------> <---------------> <-----------> <---------> <--------> <----------> <--------------->
64 bytes 64 bytes 128 bytes 256 bytes 512+ bytes 64 bytes 64 bytes 128 bytes 256 bytes 512+ bytes
The first 128 bytes are used to hold the 2-byte variables needed by The first 128 bytes are used to hold the 2-byte variables needed by
the LZ77 decompressor. Within this memory the first 64 bytes is used the LZ77 decompressor. Within this memory, the first 64 bytes are
as a scratch-pad, holding the 2-byte variables that can be discarded used as a scratch-pad, holding the 2-byte variables that can be
between SigComp messages. In contrast the next 64 bytes (and in fact discarded between SigComp messages. In contrast, the next 64 bytes
all of the UDVM memory starting from Address 64) should be saved (and in fact all of the UDVM memory starting from Address 64) should
after decompressing a SigComp message to improve the compression be saved after decompressing a SigComp message to improve the
ratio of subsequent messages. compression ratio of subsequent messages.
The bytecode for the LZ77 decompressor is stored beginning at Address The bytecode for the LZ77 decompressor is stored beginning at Address
128. A total of 128 bytes are reserved for the bytecode although the 128. A total of 128 bytes are reserved for the bytecode although the
LZ77 decompressor requires less; this allows room for adding LZ77 decompressor requires less; this allows room for adding
additional features to the decompressor at a later stage. additional features to the decompressor at a later stage.
The next 256 bytes are initialized by the bytecode to contain the The next 256 bytes are initialized by the bytecode to contain the
integers 0 to 255 inclusive. The purpose of this memory area is to integers 0 to 255 inclusive. The purpose of this memory area is to
provide a dictionary of all possible uncompressed characters; this is provide a dictionary of all possible uncompressed characters; this is
important to ensure that the compressor can always generate a important to ensure that the compressor can always generate a
skipping to change at page 13, line 34 skipping to change at page 13, line 34
compressed character 0x0141 0001 will decompress to give this ASCII compressed character 0x0141 0001 will decompress to give this ASCII
character. Note that encoding each byte in the application message character. Note that encoding each byte in the application message
as a separate 4-byte compressed character is not recommended, as a separate 4-byte compressed character is not recommended,
however, as the resulting "compressed" message is four times as large however, as the resulting "compressed" message is four times as large
as the original uncompressed message. as the original uncompressed message.
The compression ratio of LZ77 is improved by the remaining UDVM The compression ratio of LZ77 is improved by the remaining UDVM
memory, which is used to store a history buffer containing the memory, which is used to store a history buffer containing the
previously decompressed messages. Compressed characters can point to previously decompressed messages. Compressed characters can point to
strings that have previously been decompressed and stored in the strings that have previously been decompressed and stored in the
buffer; so the overall compression ratio of the LZ77 algorithm buffer, so the overall compression ratio of the LZ77 algorithm
improves as the decompressor "learns" more text strings and is able improves as the decompressor "learns" more text strings and is able
to encode longer strings using a single compressed character. The to encode longer strings using a single compressed character. The
buffer is circular, so older messages are overwritten by new data buffer is circular, so older messages are overwritten by new data
when the buffer becomes full. when the buffer becomes full.
The steps required to implement an LZ77 compressor and decompressor The steps required to implement an LZ77 compressor and decompressor
are similar, although compression is more processor-intensive as it are similar, although compression is more processor-intensive as it
requires a searching operation to be performed. Assembly for the requires a searching operation to be performed. Assembly for the
simplified LZ77 decompressor is given below: simplified LZ77 decompressor is given below:
; Variables that do not need to be stored after decompressing each ; Variables that do not need to be stored after decompressing each
; SigComp message are stored here: ; SigComp message are stored here:
at (32) at (32)
:index pad (2)
:length_value pad (2)
:position_value pad (2)
:length_value pad (2)
at (42) at (42)
set (requested_feedback_location, 0) set (requested_feedback_location, 0)
; The UDVM registers must be stored beginning at Address 64: ; The UDVM registers must be stored beginning at Address 64:
at (64) at (64)
; Variables that should be stored after decompressing a message are ; Variables that should be stored after decompressing a message are
; stored here. These variables will form part of the SigComp state ; stored here. These variables will form part of the SigComp state
skipping to change at page 14, line 50 skipping to change at page 14, line 47
; the values 0 to 255 inclusive: ; the values 0 to 255 inclusive:
MEMSET (static_dictionary, 256, 0, 1) MEMSET (static_dictionary, 256, 0, 1)
:decompress_sigcomp_message :decompress_sigcomp_message
:next_character :next_character
; The next character in the compressed message is read by the UDVM ; The next character in the compressed message is read by the UDVM
; and the position and length integers are stored in the variables ; and the position and length integers are stored in the variables
; position_value and length_value respectively. If no more ; position_value and length_value, respectively. If no more
; compressed data is available the decompressor jumps to the ; compressed data is available, the decompressor jumps to the
; "end_of_message" subroutine: ; "end_of_message" subroutine:
INPUT-BYTES (4, index, end_of_message) INPUT-BYTES (4, position_value, end_of_message)
; The position_value and length_value point to a byte string in the ; The position_value and length_value point to a byte string in the
; UDVM memory, which is copied into the circular buffer at the ; UDVM memory, which is copied into the circular buffer at the
; position specified by decompressed_pointer. This allows the string ; position specified by decompressed_pointer. This allows the string
; to be referenced by later characters in the compressed message: ; to be referenced by later characters in the compressed message:
COPY-LITERAL ($index, $length_value, $decompressed_pointer) COPY-LITERAL ($position_value, $length_value, $decompressed_pointer)
; The byte string is also outputted onto the end of the decompressed ; The byte string is also outputted onto the end of the decompressed
; message: ; message:
OUTPUT ($index, $length_value) OUTPUT ($position_value, $length_value)
; The decompressor jumps back to consider the next character in the ; The decompressor jumps back to consider the next character in the
; compressed message: ; compressed message:
JUMP (next_character) JUMP (next_character)
:end_of_message :end_of_message
; The decompressor saves the UDVM memory and halts: ; The decompressor saves the UDVM memory and halts:
skipping to change at page 15, line 41 skipping to change at page 15, line 37
decompress_sigcomp_message, 6, 0) decompress_sigcomp_message, 6, 0)
at (256) at (256)
; Memory for the dictionary and the circular buffer are reserved by ; Memory for the dictionary and the circular buffer are reserved by
; the following statements: ; the following statements:
:static_dictionary pad (256) :static_dictionary pad (256)
:circular_buffer :circular_buffer
The task of an LZ77 compressor is simply to discover a sequence of 4- The task of an LZ77 compressor is simply to discover a sequence of
byte compressed characters which the above bytecode will decompress 4-byte compressed characters that the above bytecode will decompress
to give the desired application message. As an example, a message to give the desired application message. As an example, a message
compressed using the simplified LZ77 algorithm is given below: compressed using the simplified LZ77 algorithm is given below:
0x0154 0001 0168 0001 0165 0001 0120 0001 0152 0001 0165 0001 0173 0x0154 0001 0168 0001 0165 0001 0120 0001 0152 0001 0165 0001 0173
0x0002 0161 0001 0175 0001 0172 0001 0161 0001 016e 0001 0174 0001 0x0002 0161 0001 0175 0001 0172 0001 0161 0001 016e 0001 0174 0001
0x0120 0001 0161 0001 020d 0002 0174 0001 0201 0003 0145 0001 016e 0x0120 0001 0161 0001 020d 0002 0174 0001 0201 0003 0145 0001 016e
0x0001 0164 0001 0120 0001 016f 0001 0166 0001 0211 0005 0155 0001 0x0001 0164 0001 0120 0001 016f 0001 0166 0001 0211 0005 0155 0001
0x016e 0001 0169 0001 0176 0001 0165 0001 0172 0002 0165 0001 010a 0x016e 0001 0169 0001 0176 0001 0165 0001 0172 0002 0165 0001 010a
0x0001 0x0001
The uncompressed message is "The Restaurant at the End of the The uncompressed message is "The Restaurant at the End of the
Universe\n". Universe\n".
The bytecode for the LZ77 decompressor can be uploaded as part of the The bytecode for the LZ77 decompressor can be uploaded as part of the
compressed message as specified in Section 3.3. However, in order to compressed message, as specified in Section 3.3. However, in order
improve the overall compression ratio it is important to avoid to improve the overall compression ratio, it is important to avoid
uploading bytecode in every compressed message. For this reason uploading bytecode in every compressed message. For this reason,
SigComp allows the UDVM to save an area of its memory as a state item SigComp allows the UDVM to save an area of its memory as a state item
between compressed messages. Once a state item has been created it between compressed messages. Once a state item has been created, it
can be retrieved by sending the corresponding state identifier using can be retrieved by sending the corresponding state identifier using
the following SigComp message format: the following SigComp message format:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | T | 1 | | 1 1 1 1 1 | T | 1 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: returned feedback item : if T = 1 : returned feedback item : if T = 1
| | | |
skipping to change at page 16, line 37 skipping to change at page 16, line 32
| | | |
: partial state identifier : : partial state identifier :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: remaining SigComp message : : remaining SigComp message :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
The partial_state_identifier field must contain the first 6 bytes of The partial_state_identifier field must contain the first 6 bytes of
the state identifier for the state item to be accessed (see [4] for the state identifier for the state item to be accessed (see [2] for
details of how state identifiers are derived). details of how state identifiers are derived).
4.1.2 LZSS Note that the partial_state_identifier field could be 9 or 12 bytes
and that in these cases, bits 6 and 7 of the first byte of the
message would be 10 or 11, respectively.
4.1.2. LZSS
This section provides UDVM bytecode for the simple but effective LZSS This section provides UDVM bytecode for the simple but effective LZSS
compression algorithm [8]. compression algorithm [6].
The principal improvement offered by LZSS over LZ77 is that each The principal improvement offered by LZSS over LZ77 is that each
compressed character begins with a 1-bit indicator flag to specify compressed character begins with a 1-bit indicator flag to specify
whether the character is a literal or an offset/length pair. A whether the character is a literal or an offset/length pair. A
literal value is simply a single uncompressed byte that is appended literal value is simply a single uncompressed byte that is appended
directly to the decompressed message. directly to the decompressed message.
An offset/length pair contains a 12-bit offset value from 1 to 4096 An offset/length pair contains a 12-bit offset value from 1 to 4096
inclusive, followed by a 4-bit length value from 3 to 18 inclusive. inclusive, followed by a 4-bit length value from 3 to 18 inclusive.
Taken together these values specify one of the previously received Taken together, these values specify one of the previously received
text strings in the circular buffer, which is then appended to the text strings in the circular buffer, which is then appended to the
end of the decompressed message. end of the decompressed message.
Assembly for an LZSS decompressor is given below: Assembly for an LZSS decompressor is given below:
at (32) at (32)
readonly (0) readonly (0)
:index pad (2) :index pad (2)
:length_value pad (2) :length_value pad (2)
skipping to change at page 18, line 32 skipping to change at page 18, line 26
:end_of_message :end_of_message
END-MESSAGE (requested_feedback_location, END-MESSAGE (requested_feedback_location,
returned_parameters_location, state_length, 64, returned_parameters_location, state_length, 64,
decompress_sigcomp_message, 6, 0) decompress_sigcomp_message, 6, 0)
readonly (0) readonly (0)
:circular_buffer :circular_buffer
An example message compressed using the LZSS algorithm is given An example of a message compressed using the LZSS algorithm is given
below: below:
0x279a 0406 e378 b200 6074 1018 4ce6 1349 b842 0x279a 0406 e378 b200 6074 1018 4ce6 1349 b842
The uncompressed message is "Oh no, not again!". The uncompressed message is "Oh no, not again!".
4.1.3 LZW 4.1.3. LZW
This section provides UDVM bytecode for the well-known LZW This section provides UDVM bytecode for the well-known LZW
compression algorithm LZW [9]. This algorithm is used in a number of compression algorithm LZW [7]. This algorithm is used in a number of
standards including the GIF image format. standards including the GIF image format.
LZW compression operates in a similar manner to LZ77 in that it LZW compression operates in a similar manner to LZ77 in that it
maintains a circular buffer of previously received decompressed data, maintains a circular buffer of previously received decompressed data,
and each compressed character references exactly one byte string from and each compressed character references exactly one byte string from
the circular buffer. However, LZW also maintains a "codebook" the circular buffer. However, LZW also maintains a "codebook"
containing 1024 position/length pairs that point to byte strings containing 1024 position/length pairs that point to byte strings that
which LZW believes are most likely to occur in the uncompressed data. LZW believes are most likely to occur in the uncompressed data.
The byte strings stored in the LZW codebook can be referenced by The byte strings stored in the LZW codebook can be referenced by
sending a single 10-bit value from 0 to 1023 inclusive. The UDVM sending a single 10-bit value from 0 to 1023 inclusive. The UDVM
extracts the corresponding text string from the codebook and appends extracts the corresponding text string from the codebook and appends
it to the end of the decompressed message. It then creates a new it to the end of the decompressed message. It then creates a new
codebook entry containing the current text string plus the next codebook entry containing the current text string and the next
character to occur in the decompressed message. character to occur in the decompressed message.
Assembly for an LZW decompressor is given below: Assembly for an LZW decompressor is given below:
at (32) at (32)
:length_value pad (2) :length_value pad (2)
:position_value pad (2) :position_value pad (2)
:index pad (2) :index pad (2)
skipping to change at page 20, line 12 skipping to change at page 20, line 4
set (index_lsb, (index + 1)) set (index_lsb, (index + 1))
set (current_length_lsb, (current_length + 1)) set (current_length_lsb, (current_length + 1))
COPY-LITERAL (current_length_lsb, 3, $codebook_next) COPY-LITERAL (current_length_lsb, 3, $codebook_next)
COPY-LITERAL (index_lsb, 1, $decompressed_pointer) COPY-LITERAL (index_lsb, 1, $decompressed_pointer)
ADD ($index, 1) ADD ($index, 1)
COMPARE ($index, 256, initialize_codebook, next_character, 0) COMPARE ($index, 256, initialize_codebook, next_character, 0)
:decompress_sigcomp_message :decompress_sigcomp_message
:next_character :next_character
; The following INPUT-BITS instruction extracts 10 bits from the ; The following INPUT-BITS instruction extracts 10 bits from the
; compressed message: ; compressed message:
INPUT-BITS (10, index, end_of_message) INPUT-BITS (10, index, end_of_message)
; The following instructions interpret the received bits as an index ; The following instructions interpret the received bits as an index
; into the LZW codebook, and extract the corresponding ; into the LZW codebook and extract the corresponding
; position/length pair: ; position/length pair:
set (length_value_lsb, (length_value + 1)) set (length_value_lsb, (length_value + 1))
MULTIPLY ($index, 3) MULTIPLY ($index, 3)
ADD ($index, codebook) ADD ($index, codebook)
COPY ($index, 3, length_value_lsb) COPY ($index, 3, length_value_lsb)
; The following instructions append the selected text string to the ; The following instructions append the selected text string to the
; circular buffer and create a new codebook entry pointing to this ; circular buffer and create a new codebook entry pointing to this
skipping to change at page 21, line 9 skipping to change at page 21, line 4
END-MESSAGE (requested_feedback_location, END-MESSAGE (requested_feedback_location,
returned_parameters_location, state_length, 64, returned_parameters_location, state_length, 64,
decompress_sigcomp_message, 6, 0) decompress_sigcomp_message, 6, 0)
:static_dictionary pad (256) :static_dictionary pad (256)
:circular_buffer :circular_buffer
at (4492) at (4492)
:codebook :codebook
An example of a message compressed using the LZW algorithm is given
below:
An example message compressed using the LZW algorithm is given below:
0x14c6 f080 6c1b c6e1 9c20 1846 e190 201d 0684 206b 1cc2 0198 6f1c 0x14c6 f080 6c1b c6e1 9c20 1846 e190 201d 0684 206b 1cc2 0198 6f1c
0x9071 b06c 42c6 8195 111a 4731 a021 02bf f0 0x9071 b06c 42c6 8195 111a 4731 a021 02bf f0
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 [10] with the following modifications: format [8] 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:
at (32) at (32)
readonly (0) readonly (0)
:index pad (2) :index pad (2)
:extra_length_bits pad (2) :extra_length_bits pad (2)
skipping to change at page 23, line 4 skipping to change at page 22, line 48
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)
:literal :literal
skipping to change at page 24, line 4 skipping to change at page 24, line 4
JUMP (next_character) JUMP (next_character)
:end_of_message :end_of_message
END-MESSAGE (requested_feedback_location, END-MESSAGE (requested_feedback_location,
returned_parameters_location, state_length, 64, returned_parameters_location, state_length, 64,
decompress_sigcomp_message, 6, 0) decompress_sigcomp_message, 6, 0)
readonly (0) readonly (0)
:circular_buffer :circular_buffer
An example message compressed using the DEFLATE algorithm is given An example of a message compressed using the DEFLATE algorithm is
below: given below:
0xf3c9 4c4b d551 28c9 4855 08cd cb2c 4b2d 2a4e 5548 cc4b 5170 0532 0xf3c9 4c4b d551 28c9 4855 08cd cb2c 4b2d 2a4e 5548 cc4b 5170 0532
0x2b4b 3232 f3d2 b900 0x2b4b 3232 f3d2 b900
The uncompressed message is "Life, the Universe and Everything\n". The uncompressed message is "Life, the Universe and Everything\n".
4.1.5 LZJH 4.1.5. LZJH
This section provides UDVM bytecode for the LZJH compression This section provides UDVM bytecode for the LZJH compression
algorithm. LZJH is the algorithm adopted by the International algorithm. LZJH is the algorithm adopted by the International
Telecommunication Union (ITU-T) Recommendation V.44 LZJH [11]. Telecommunication Union (ITU-T) Recommendation V.44 [9].
Assembly for the LZJH decompressor is given below: Assembly for the LZJH decompressor is given below:
at (32) at (32)
readonly (0) readonly (0)
; The following 2-byte variables are stored in the scratch-pad memory ; The following 2-byte variables are stored in the scratch-pad memory
; area because they do not need to be saved after decompressing a ; area because they do not need to be saved after decompressing a
; SigComp message: ; SigComp message:
skipping to change at page 25, line 37 skipping to change at page 25, line 42
MULTILOAD (64, 8, circular_buffer, udvm_memory_size, 7, 0, MULTILOAD (64, 8, circular_buffer, udvm_memory_size, 7, 0,
circular_buffer, min_ordinal_length, min_codeword_length, circular_buffer, min_ordinal_length, min_codeword_length,
codebook_start) codebook_start)
:decompress_sigcomp_message :decompress_sigcomp_message
:standard_prefix :standard_prefix
; The following code decompresses the standard 1-bit LZJH prefix ; The following code decompresses the standard 1-bit LZJH prefix
; which specifies whether the next character is an ordinal or a ; that specifies whether the next character is an ordinal or a
; codeword/control value: ; codeword/control value:
INPUT-BITS (1, index, end_of_message) INPUT-BITS (1, index, end_of_message)
COMPARE ($index, 1, ordinal, codeword_control, codeword_control) COMPARE ($index, 1, ordinal, codeword_control, codeword_control)
:prefix_after_codeword :prefix_after_codeword
; The following code decompresses the special LZJH prefix that only ; The following code decompresses the special LZJH prefix that only
; occurs after a codeword. It specifies whether the next character is ; occurs after a codeword. It specifies whether the next character
; an ordinal, a codeword/control value, or a string extension: ; is an ordinal, a codeword/control value, or a string extension:
INPUT-HUFFMAN (index, end_of_message, 2, 1, 1, 1, 2, 1, 0, 1, 0) INPUT-HUFFMAN (index, end_of_message, 2, 1, 1, 1, 2, 1, 0, 1, 0)
COMPARE ($index, 1, ordinal, string_extension, codeword_control) COMPARE ($index, 1, ordinal, string_extension, codeword_control)
:ordinal :ordinal
; The following code decompresses an ordinal character, and creates ; The following code decompresses an ordinal character and creates
; a new codebook entry consisting of the ordinal character plus the ; a new codebook entry consisting of the ordinal character and the
; next character to be decompressed: ; next character to be decompressed:
set (index_lsb, (index + 1)) set (index_lsb, (index + 1))
set (current_length_lsb, (current_length + 1)) set (current_length_lsb, (current_length + 1))
INPUT-BITS ($ordinal_length, index, !) INPUT-BITS ($ordinal_length, index, !)
OUTPUT (index_lsb, 1) OUTPUT (index_lsb, 1)
LOAD (current_length, 2) LOAD (current_length, 2)
COPY-LITERAL (current_length_lsb, 3, $codebook_next) COPY-LITERAL (current_length_lsb, 3, $codebook_next)
COPY-LITERAL (index_lsb, 1, $decompressed_pointer) COPY-LITERAL (index_lsb, 1, $decompressed_pointer)
skipping to change at page 26, line 32 skipping to change at page 26, line 39
; The following code decompresses a codeword/control value: ; The following code decompresses a codeword/control value:
INPUT-BITS ($codeword_length, index, !) INPUT-BITS ($codeword_length, index, !)
COMPARE ($index, 3, control_code, initialize_memory, codeword) COMPARE ($index, 3, control_code, initialize_memory, codeword)
:codeword :codeword
; The following code interprets a codeword as an index into the LZJH ; The following code interprets a codeword as an index into the LZJH
; codebook. It extracts the position/length pair from the specified ; codebook. It extracts the position/length pair from the specified
; codebook entry; the position/length pair points to a byte string ; codebook entry; the position/length pair points to a byte string
; in the circular buffer which is then copied to the end of the ; in the circular buffer, which is then copied to the end of the
; decompressed message. The code also creates a new codebook entry ; decompressed message. The code also creates a new codebook entry
; consisting of the byte string plus the next character to be ; consisting of the byte string plus the next character to be
; decompressed: ; decompressed:
set (length_value_lsb, (length_value + 1)) set (length_value_lsb, (length_value + 1))
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)
skipping to change at page 28, line 21 skipping to change at page 28, line 29
:end_of_message :end_of_message
END-MESSAGE (requested_feedback_location, END-MESSAGE (requested_feedback_location,
returned_parameters_location, state_length, 64, returned_parameters_location, state_length, 64,
decompress_sigcomp_message, 6, 0) decompress_sigcomp_message, 6, 0)
readonly (0) readonly (0)
:circular_buffer :circular_buffer
An example message compressed using the LZJH algorithm is given An example of a message compressed using the LZJH algorithm is given
below: below:
0x5c09 e6e0 cadc c8d2 dcce 40c2 40f2 cac2 e440 c825 c840 ccde 29e8 0x5c09 e6e0 cadc c8d2 dcce 40c2 40f2 cac2 e440 c825 c840 ccde 29e8
0xc2f0 40e0 eae4 e0de e6ca e65c 1403 0xc2f0 40e0 eae4 e0de e6ca e65c 1403
The uncompressed message is "...spending a year dead for tax The uncompressed message is "...spending a year dead for tax
purposes.\n". purposes.\n".
4.2 Adapted Algorithms 4.2. Adapted Algorithms
4.2.1 Modified DEFLATE 4.2.1. Modified DEFLATE
Alternative algorithms can also be used with SigComp. This section Alternative algorithms can also be used with SigComp. This section
shows a modified version of the DEFLATE [10] algorithm. The two- shows a modified version of the DEFLATE [8] algorithm. The two-stage
stage encoding of DEFLATE is replaced by a single step with a encoding of DEFLATE is replaced by a single step with a discrete
discrete Huffman code for each symbol. The literal/length symbol Huffman code for each symbol. The literal/length symbol
probabilities are dependent upon whether the previously symbol was a probabilities are dependent upon whether the previous symbol was a
literal or a match. Bit-handling is also simpler, in that all bits literal or a match. Bit handling is also simpler, in that all bits
are input using the INPUT-HUFFMAN instruction and the value of the H are input using the INPUT-HUFFMAN instruction and the value of the H
bit does not change so all bits are input, read and interpreted in bit does not change so all bits are input, read, and interpreted in
the same order. the same order.
Assembly for the algorithm is given below. String matching rules are Assembly for the algorithm is given below. String matching rules are
the same as for the other LZ-based algorithms, with the alternative the same as for the other LZ-based algorithms, with the alternative
encoding of the literals and length/distance pairs. encoding of the literals and length/distance pairs.
at (32) at (32)
readonly (0) readonly (0)
:index pad (2) :index pad (2)
skipping to change at page 31, line 20 skipping to change at page 31, line 25
:end_of_message :end_of_message
END-MESSAGE (requested_feedback_location, END-MESSAGE (requested_feedback_location,
returned_parameters_location, state_length, 64, returned_parameters_location, state_length, 64,
decompress_sigcomp_message, 6, 0) decompress_sigcomp_message, 6, 0)
readonly (0) readonly (0)
:circular_buffer :circular_buffer
An example message compressed using the modified DEFLATE algorithm is An example of a message compressed using the modified DEFLATE
given below: algorithm is given below:
0xd956 b132 cd68 5424 c5a9 6215 8a70 a64d af0a 5499 3621 509b 3e4c 0xd956 b132 cd68 5424 c5a9 6215 8a70 a64d af0a 5499 3621 509b 3e4c
0x28b4 a145 b362 653a d0a6 498b 5a6d 2970 ac4c 930a a4ca 74a4 c268 0x28b4 a145 b362 653a d0a6 498b 5a6d 2970 ac4c 930a a4ca 74a4 c268
0x0c 0x0c
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 This section covers the additional mechanisms that can be employed by
employed by SigComp to improve the overall compression ratio; SigComp to improve the overall compression ratio, including the use
including the use of acknowledgements, dictionaries and sharing state of acknowledgements, dictionaries, and sharing state between two
between two directions of a compressed message flow. directions of a compressed message flow.
Example assembly code is provided for these mechanisms. Depending on An example of assembly code is provided for these mechanisms.
the mechanism and basic algorithm in use, the assembly code for Depending on the mechanism and basic algorithm in use, the assembly
either the mechanism or the basic algorithm may require modification code for either the mechanism or the basic algorithm may require
(e.g. if the algorithm uses 'no more input' to jump to modification (e.g., if the algorithm uses 'no more input' to jump to
end_of_message, following end_of_message with an input instruction end_of_message, following end_of_message with an input instruction
for CRC will not work). In any case, these are examples and there for CRC will not work). In any case, these are examples and there
may be alternative ways to make use of the mechanisms. may be alternative ways to make use of the mechanisms.
When each of the compression algorithms described in Section 4 has 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
remote endpoint, the compressor also maintains a flag for each state remote endpoint, the compressor also maintains a flag for each state
item indicating whether the state can safely be accessed or not. item indicating whether or not the state can safely be accessed.
State items should not be accessed until they have been acknowledged State items should not be accessed until they have been acknowledged
(e.g. by using the SigComp feedback mechanism as per Section 5.1). (e.g., by using the SigComp feedback mechanism as per Section 5.1).
State items are deleted from the list when the total State items are deleted from the list when adding a new piece of
state_memory_size for the compartment is used up by states of a state when the total state_memory_size for the compartment is full.
higher priority. The SigComp compressor should not attempt to access The state to be deleted is determined according to age and retention
any state items that have been deleted in this manner, as they may no priority as discussed in SigComp [2]. The SigComp compressor should
longer be available at the receiving endpoint. not attempt to access any state items that have been deleted in this
manner, as they may no longer be available at the receiving endpoint.
5.1 Acknowledging a state item 5.1. Acknowledging a State Item
SigComp [4] defines a feedback mechanism to allow the compressor to SigComp [2] defines a feedback mechanism to allow the compressor to
request feedback from the decompressor, to give the compressor request feedback from the decompressor, to give the compressor
indication that a message has been received, correctly decompressed indication that a message has been received and correctly
and state storage attempted. (Note, this mechanism cannot convey the decompressed and that state storage has been attempted. (Note: This
success or failure of individual state creation requests.) In order mechanism cannot convey the success or failure of individual state
to invoke the feedback mechanism the following fields must be creation requests.) In order to invoke the feedback mechanism, the
reserved in the UDVM memory: 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
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| reserved | Q | S | I | requested_feedback_location | reserved | Q | S | I | requested_feedback_location
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 | requested_feedback_length | if Q = 1 | 1 | requested_feedback_length | if Q = 1
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: requested_feedback_field : if Q = 1 : requested_feedback_field : if Q = 1
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
These fields can be reserved in any of the algorithms of Section 4 by
These fields can be reserved in any of the algorithms of Chapter 4 by
replacing the line "set (requested_feedback_location, 0)" with the replacing the line "set (requested_feedback_location, 0)" with the
following assembly: following assembly:
:requested_feedback_location pad (1) :requested_feedback_location pad (1)
:requested_feedback_length pad (1) :requested_feedback_length pad (1)
:requested_feedback_field pad (12) :requested_feedback_field pad (12)
:hash_start pad (8) :hash_start pad (8)
When a SigComp message is successfully decompressed and saved as When a SigComp message is successfully decompressed and saved as
state, the following bytecode instructs the receiving endpoint to state, the following bytecode instructs the receiving endpoint to
return the first 6 bytes of the corresponding state identifier. The return the first 6 bytes of the corresponding state identifier. The
bytecode can be added to any of the compression algorithms of Chapter bytecode can be added to any of the compression algorithms of Section
4 immediately following the ":end_of_message" label: 4 immediately following the ":end_of_message" label:
:end_of_message :end_of_message
set (hash_length, (state_length + 8)) set (hash_length, (state_length + 8))
LOAD (requested_feedback_location, 1158) LOAD (requested_feedback_location, 1158)
MULTILOAD (hash_start, 4, state_length, 64, MULTILOAD (hash_start, 4, state_length, 64,
decompress_sigcomp_message, 6) decompress_sigcomp_message, 6)
SHA-1 (hash_start, hash_length, requested_feedback_field) SHA-1 (hash_start, hash_length, requested_feedback_field)
The receiving endpoint then returns the state identifier in the The receiving endpoint then returns the state identifier in the
"returned feedback field" of the next SigComp message to be "returned feedback field" of the next SigComp message to be
transmitted in the reverse direction. transmitted in the reverse direction.
When the state identifier is returned, the compressor can set the When the state identifier is returned, the compressor can set the
availability flag for the corresponding state to 1. availability flag for the corresponding state to 1.
5.2 Static dictionary 5.2. Static Dictionary
Certain protocols that can be compressed using SigComp offer a fixed, Certain protocols that can be compressed using SigComp offer a fixed,
mandatory state item known as a static dictionary. This dictionary mandatory state item known as a static dictionary. This dictionary
contains a number of text strings that commonly occur in messages contains a number of text strings that commonly occur in messages
generated by the protocol in question. The overall compression ratio generated by the protocol in question. The overall compression ratio
can often be improved by accessing the text phrases from this static can often be improved by accessing the text phrases from this static
dictionary rather than by uploading them as part of the compressed dictionary rather than by uploading them as part of the compressed
message. message.
As an example, a static dictionary is provided for the protocols SIP As an example, a static dictionary is provided for the protocols SIP
and SDP RFC-3485 [6]. This dictionary is designed for use by a wide and SDP, RFC 3485 [4]. 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. Section 4.
In any of the compression algorithms of Chapter 4, the static In any of the compression algorithms of Section 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 The parameters of STATE-ACCESS instruction will depend on the
compression algorithm in use. 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 load only 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 [4].
5.3 CRC checksum 5.3. CRC Checksum
The acknowledgement scheme of Section 5.1 is designed to indicate the The acknowledgement scheme of Section 5.1 is designed to indicate the
successful decompression of a message. However, it does not successful decompression of a message. However, it does not
guarantee that the decompressed message is identical to the original guarantee that the decompressed message is identical to the original
message, since decompression of a corrupted message could succeed but message, since decompression of a corrupted message could succeed but
with some characters being incorrect. This could lead to an with some characters being incorrect. This could lead to an
incorrect message being passed to the application or unexpected incorrect message being passed to the application or unexpected
contents of state to be stored. In order to prevent this happening a contents of state to be stored. In order to prevent this happening,
CRC check could be used. 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.
A definition of the CRC polynomial used by the CRC instruction can be A definition of the CRC polynomial used by the CRC instruction can be
found in SigComp [4]. found in SigComp [2].
5.4 Announcing additional resources 5.4. Announcing Additional Resources
If a particular endpoint is able to offer more processing or memory If a particular endpoint is able to offer more processing or memory
resources than the mandatory minimum, the SigComp feedback mechanism resources than the mandatory minimum, the SigComp feedback mechanism
can be used to announce that these resources are available to the can be used to announce that these resources are available to the
remote endpoint. This may help to improve the overall compression remote endpoint. This may help to improve the overall compression
ratio between the two endpoints. ratio between the two endpoints.
Additionally, if an endpoint has any pieces of state that may be Additionally, if an endpoint has any pieces of state that may be
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), for
dictionary or shared mode state (see Section 5.5). example, a 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
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| SigComp_version | | SigComp_version |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_1 | | length_of_partial_state_ID_1 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
skipping to change at page 36, line 26 skipping to change at page 36, line 28
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
: : : :
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_n | | length_of_partial_state_ID_n |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: partial_state_identifier_n : : partial_state_identifier_n :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
These fields can be reserved in any of the algorithms of Chapter 4 by These fields can be reserved in any of the algorithms of Section 4 by
replacing the line "set (returned_parameters_location, 0)" with the replacing the line "set (returned_parameters_location, 0)" with the
following piece of assembly: following piece of assembly:
:adverts_len pad (1) :adverts_len pad (1)
:adverts_len_lsb pad (1) :adverts_len_lsb pad (1)
:returned_parameters_location pad (1) :returned_parameters_location pad (1)
:returned_sigcomp_version pad (1) :returned_sigcomp_version pad (1)
:state_ids pad (x) :state_ids pad (x)
where x is enough space for the number state identifiers that the where x is enough space for the number state identifiers that the
skipping to change at page 37, line 12 skipping to change at page 37, line 12
INPUT-BYTES (1, adverts_len_lsb, done) INPUT-BYTES (1, adverts_len_lsb, done)
INPUT-BYTES ($adverts_len, state_ids, done) INPUT-BYTES ($adverts_len, state_ids, done)
:done :done
Note that the integer value "N" should be set equal to the amount of Note that the integer value "N" should be set equal to the amount of
resources available at the sending endpoint. N should be expressed resources available at the sending endpoint. N should be expressed
as a 2-byte integer with the most significant bits corresponding to as a 2-byte integer with the most significant bits corresponding to
the cycles_per_bit parameter and the least significant bits the cycles_per_bit parameter and the least significant bits
corresponding to the SigComp_version parameter. corresponding to the SigComp_version parameter.
The length of the state identifiers, followed by the state The length of the state identifiers followed by the state identifiers
identifiers in the format shown are appended to the end of the in the format shown are appended to the end of the compressed
compressed message. message.
5.5 Shared compression 5.5. Shared Compression
This section provides bytecode for implementing the SigComp shared This section provides bytecode for implementing the SigComp shared
compression mechanism RFC-3321 [5]. If two endpoints A and B are compression mechanism, RFC 3321 [3]. If two endpoints A and B are
communicating via SigComp, shared compression allows the messages communicating via SigComp, shared compression allows the messages
sent from Endpoint A to Endpoint B to be compressed relative to the sent from Endpoint A to Endpoint B to be compressed relative to the
messages sent from Endpoint B to Endpoint A (and vice versa). This messages sent from Endpoint B to Endpoint A (and vice versa). This
may improve the overall compression ratio by reducing the need to may improve the overall compression ratio by reducing the need to
transmit the same information in both directions. transmit the same information in both directions.
As described in RFC-3321 [5], two steps must be taken to implement As described in RFC 3321 [3], two steps must be taken to implement
shared compression at an endpoint. shared compression at an endpoint.
Firstly, it is necessary to announce to the remote endpoint that First, it is necessary to announce to the remote endpoint that shared
shared compression is available. This is done by announcing the compression is available. This is done by announcing the state
state identifier as an available piece of state. This can be done identifier as an available piece of state. This can be done using
using the returned_parameters_location announcement as in the returned_parameters_location announcement as in Section 5.4.
Section 5.4.
Secondly, assuming that such an announcement is received from the Second, 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 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
This document describes implementation options for the SigComp This document describes implementation options for the SigComp
protocol [4]. Consequently the security considerations for this protocol [2]. Consequently, the security considerations for this
document match those of SigComp. document match those of SigComp.
7. Acknowledgements 7. Acknowledgements
Thanks to Richard Price, Carsten Bormann, Adam Roach, Lawrence Thanks to Richard Price, Carsten Bormann, Adam Roach, Lawrence
Conroy, Christian Schmidt, Max Riegel, Lars-Erik Jonsson, Jonathan Conroy, Christian Schmidt, Max Riegel, Lars-Erik Jonsson, Jonathan
Rosenberg, Stefan Forsgren, Krister Svanbro, Miguel Garcia, Rosenberg, Stefan Forsgren, Krister Svanbro, Miguel Garcia,
Christopher Clanton, Khiem Le, Ka Cheong Leung, Zoltan Barczikay for Christopher Clanton, Khiem Le, Ka Cheong Leung, and Zoltan Barczikay
valuable input and review. for valuable input and review.
Special thanks to Pekka Pessi and Cristian Constantin who served as Special thanks to Pekka Pessi and Cristian Constantin, who served as
committed working group document reviewers. committed working group document reviewers.
8. Intellectual Property Right Considerations 8. Intellectual Property Right Considerations
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
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.
9. References 9. Normative References
[1] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Basic Call Flow
Examples", RFC 3665, December 2003.
[2] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 3667, February 2004.
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax [1] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 4234, October 2005.
[4] Price, R., Borman, C., Christoffersson, J., Hannu, H., Liu, Z., [2] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu,
and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC
January 2003. 3320, January 2003.
[5] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K., Liu, [3] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K.-C.,
Z., and R. Price, "Signaling Compression (SigComp) - Extended Liu, Z., and R. Price, "Signaling Compression (SigComp) -
Operations", RFC 3321, January 2003. Extended Operations", RFC 3321, January 2003.
[6] Garcia-Martin, M., Borman, C., Ott, J., Price, R., and A. [4] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and A.B.
Roach, "The Session Initiation Protocol (SIP) and Session Roach, "The Session Initiation Protocol (SIP) and Session
Description Protocol (SDP) Static Dictionary for Signaling Description Protocol (SDP) Static Dictionary for Signaling
Compression (SigComp)", RFC 3485, February 2003. Compression (SigComp)", RFC 3485, February 2003.
[7] Ziv, J. and A. Lempel, "A universal algorithm for sequential [5] Ziv, J. and A. Lempel, "A universal algorithm for sequential
data compression", IEEE 23:337-343, 1977. data compression", IEEE 23:337-343, 1977.
[8] Storer, J., "Data Compression: Methods and Theory", Computer [6] Storer, J., "Data Compression: Methods and Theory", Computer
Science Press ISBN 0-88175-161-8, 1998. Science Press ISBN 0-88175-161-8, 1998.
[9] Nelson, M., "LZW Data Compression", Dr Dobb's Journal, [7] Nelson, M., "LZW Data Compression", Dr Dobb's Journal,
October 1989. October 1989.
[10] Deutsch, P., "DEFLATE Compressed Data Format Specification [8] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996. version 1.3", RFC 1951, May 1996.
[11] "Data Compression Procedures", ITU-T Recommendation V.44, [9] "Data Compression Procedures", ITU-T Recommendation V.44,
November 2000. November 2000.
Authors' Addresses Appendix A. UDVM Bytecode for the Compression Algorithms
Abigail Surtees
Siemens/Roke Manor Research
Roke Manor Research Ltd.
Romsey, Hants SO51 0ZN
UK
Phone: +44 (0)1794 833131
Email: abigail.surtees@roke.co.uk
URI: http://www.roke.co.uk
Mark A. West
Siemens/Roke Manor Research
Roke Manor Research Ltd.
Romsey, Hants SO51 0ZN
UK
Phone: +44 (0)1794 833311
Email: mark.a.west@roke.co.uk
URI: http://www.roke.co.uk
Appendix A. UDVM bytecode for the compression algorithms
The following sections list the UDVM bytecode generated for each The following sections list the UDVM bytecode generated for each
compression algorithm of Section 4. compression algorithm of Section 4.
Note that the different assemblers can output different bytecode for Note that the different assemblers can output different bytecode for
the same piece of assembly code, so a valid assembler can produce the same piece of assembly code, so a valid assembler can produce
results different from those presented below. However, the following results different from those presented below. However, the following
bytecode should always generate the same decompressed messages on any bytecode should always generate the same decompressed messages on any
UDVM. UDVM.
A.1 Well-known Algorithms A.1. Well-known Algorithms
A.1.1 Simplified LZ77 A.1.1. LZ77
0x0f86 0389 8d89 1588 8800 011c 0420 0d13 5051 2222 5051 16f5 2300 0x0f86 0389 8d89 1588 8800 011c 0420 0d13 5051 2222 5051 16f5 2300
0x00bf c086 a08b 06 0x00bf c086 a08b 06
A.1.2 LZSS A.1.2. LZSS
0x0f86 04a0 c48d 00a0 c41e 2031 0209 00a0 ff8e 048c bfff 0117 508d 0x0f86 04a0 c48d 00a0 c41e 2031 0209 00a0 ff8e 048c bfff 0117 508d
0x0f23 0622 2101 1321 0123 16e5 1d04 22e8 0611 030e 2463 1450 5123 0x0f23 0622 2101 1321 0123 16e5 1d04 22e8 0611 030e 2463 1450 5123
0x2252 5116 9fd2 2300 00bf c086 a089 06 0x2252 5116 9fd2 2300 00bf c086 a089 06
A.1.3 LZW A.1.3. LZW
0x0f86 06a1 ce8d 00b1 8f01 a0ce 13a0 4903 2313 2501 2506 1201 1752 0x0f86 06a1 ce8d 00b1 8f01 a0ce 13a0 4903 2313 2501 2506 1201 1752
0x88f4 079f 681d 0a24 2508 1203 0612 b18f 1252 0321 0ea0 4801 0624 0x88f4 079f 681d 0a24 2508 1203 0612 b18f 1252 0321 0ea0 4801 0624
0x5013 a049 0323 1351 5025 2251 5016 9fde 2300 00bf c086 a09f 06 0x5013 a049 0323 1351 5025 2251 5016 9fde 2300 00bf c086 a09f 06
A.1.4 DEFLATE A.1.4. DEFLATE
0x0f86 7aa2 528d 05a2 5200 0300 0400 0500 0600 0700 0800 0900 0a01 0x0f86 7aa2 528d 05a2 5200 0300 0400 0500 0600 0700 0800 0900 0a01
0x0b01 0d01 0f01 1102 1302 1702 1b02 1f03 2303 2b03 3303 3b04 a043 0x0b01 0d01 0f01 1102 1302 1702 1b02 1f03 2303 2b03 3303 3b04 a043
0x04a0 5304 a063 04a0 7305 a083 05a0 a305 a0c3 05a0 e300 a102 0001 0x04a0 5304 a063 04a0 7305 a083 05a0 a305 a0c3 05a0 e300 a102 0001
0x0002 0003 0004 0105 0107 0209 020d 0311 0319 0421 0431 05a0 4105 0x0002 0003 0004 0105 0107 0209 020d 0311 0319 0421 0431 05a0 4105
0xa061 06a0 8106 a0c1 07a1 0107 a181 08a2 0108 a301 09a4 0109 a601 0xa061 06a0 8106 a0c1 07a1 0107 a181 08a2 0108 a301 09a4 0109 a601
0x0aa8 010a ac01 0bb0 010b b801 0c80 2001 0c80 3001 0d80 4001 0d80 0x0aa8 010a ac01 0bb0 010b b801 0c80 2001 0c80 3001 0d80 4001 0d80
0x6001 1d03 229f b41e 20a0 6504 0700 1780 4011 0130 a0bf 0000 a0c0 0x6001 1d03 229f b41e 20a0 6504 0700 1780 4011 0130 a0bf 0000 a0c0
0xa0c7 8040 2901 a190 a1ff a090 1750 8040 1109 a046 1322 2101 1321 0xa0c7 8040 2901 a190 a1ff a090 1750 8040 1109 a046 1322 2101 1321
0x0123 169f d108 1004 1250 0422 1d51 229f d706 1251 1e20 9fcf 0105 0x0123 169f d108 1004 1250 0422 1d51 229f d706 1251 1e20 9fcf 0105
0x001f 2f08 1004 1250 0426 1d53 26f6 0614 530e 2063 1454 5223 2250 0x001f 2f08 1004 1250 0426 1d53 26f6 0614 530e 2063 1454 5223 2250
0x5216 9f9e 2300 00bf c086 a1de 06 0x5216 9f9e 2300 00bf c086 a1de 06
A.1.5 LZJH A.1.5. LZJH
0x0f86 08a1 5b8d 0700 a15b 0706 b18f 1d01 24a0 c317 5201 1a31 311e 0x0f86 08a1 5b8d 0700 a15b 0706 b18f 1d01 24a0 c317 5201 1a31 311e
0x24a0 b802 0101 0102 0100 0100 1752 0107 a04e 1e1d 6524 f822 2501 0x24a0 b802 0101 0102 0100 0100 1752 0107 a04e 1e1d 6524 f822 2501
0x0ea0 4602 13a0 4703 2713 2501 2416 9fcd 1d66 24e1 1752 03a0 639f 0x0ea0 4602 13a0 4703 2713 2501 2416 9fcd 1d66 24e1 1752 03a0 639f
0xb808 0812 0306 12b1 8312 5203 210e a046 0106 2350 0e28 6713 a047 0xb808 0812 0306 12b1 8312 5203 210e a046 0106 2350 0e28 6713 a047
0x0327 1351 5024 2251 5016 9fa8 1e24 9fb1 0401 0101 0102 0103 0201 0x0327 1351 5024 2251 5016 9fa8 1e24 9fb1 0401 0101 0102 0103 0201
0x0101 0d03 0007 0517 520d 0d06 061d 0826 f706 1253 1351 5011 1351 0x0101 0d03 0007 0517 520d 0d06 061d 0826 f706 1253 1351 5011 1351
0x5224 2251 5206 1250 1225 0154 169f 6617 5201 9fdb 070f 1c00 009e 0x5224 2251 5206 1250 1225 0154 169f 6617 5201 9fdb 070f 1c00 009e
0xce16 9f57 1d01 24fa 1752 0107 0d9e c206 2501 169f 6506 2601 169f 0xce16 9f57 1d01 24fa 1752 0107 0d9e c206 2501 169f 6506 2601 169f
0x7623 0000 bfc0 86a0 8e06 0x7623 0000 bfc0 86a0 8e06
A.2 Adapted Algorithms A.2. Adapted Algorithms
A.2.1 Modified DEFLATE A.2.1. Modified DEFLATE
0x0f86 04a1 d38d 00a1 d31e 20a1 4010 0500 0b2e 000c 0c88 011a 20a1 0x0f86 04a1 d38d 00a1 d31e 20a1 4010 0500 0b2e 000c 0c88 011a 20a1
0x0101 a042 a044 2000 a045 a05e a061 00a0 5fa0 66a1 0800 a067 a067 0x0101 a042 a044 2000 a045 a05e a061 00a0 5fa0 66a1 0800 a067 a067
0xa1ff 02a1 a0a1 aa23 00a1 aba1 d13a 00a1 d2a1 e1a1 1001 a3c4 a3e3 0xa1ff 02a1 a0a1 aa23 00a1 aba1 d13a 00a1 d2a1 e1a1 1001 a3c4 a3e3
0xa120 03bf 20bf 34a0 7b00 bf35 bfb3 a180 0180 3f68 803f 8700 0080 0xa120 03bf 20bf 34a0 7b00 bf35 bfb3 a180 0180 3f68 803f 8700 0080
0x3f88 803f c7a1 4001 807f 9080 7fff a090 1750 88a0 79a0 83a0 831e 0x3f88 803f c7a1 4001 807f 9080 7fff a090 1750 88a0 79a0 83a0 831e
0x20a0 c810 0400 00a1 ff01 0209 8801 1416 2000 171e a108 013e a049 0x20a0 c810 0400 00a1 ff01 0209 8801 1416 2000 171e a108 013e a049
0x2e00 a04a a059 a110 02a1 68a1 81a0 6100 a182 a1a1 a120 01a3 44a3 0x2e00 a04a a059 a110 02a1 68a1 81a0 6100 a182 a1a1 a120 01a3 44a3
0x6a3a 00a3 6ba3 aaa1 4001 a756 a760 2300 a761 a7df a180 01af c0af 0x6a3a 00a3 6ba3 aaa1 4001 a756 a760 2300 a761 a7df a180 01af c0af
0xd4a0 7b01 bfaa bfc9 0001 803f 9480 3ffb a090 0180 7ff8 807f ffa0 0xd4a0 7b01 bfaa bfc9 0001 803f 9480 3ffb a090 0180 7ff8 807f ffa0
0xf817 5088 0610 1022 2101 1321 0123 169f 1107 10a0 fd1e 229f d909 0xf817 5088 0610 1022 2101 1321 0123 169f 1107 10a0 fd1e 229f d909
0x0900 0709 0008 3fa0 8101 87a0 8701 00a0 88a0 f711 00a0 f8a1 3fa0 0x0900 0709 0008 3fa0 8101 87a0 8701 00a0 88a0 f711 00a0 f8a1 3fa0
0xb901 a280 a57f a101 02b6 00b9 ffa4 0101 8034 0080 3bff a801 0290 0xb901 a280 a57f a101 02b6 00b9 ffa4 0101 8034 0080 3bff a801 0290
0x00ff b001 0e24 6314 5150 2322 5250 169f 3b23 0000 bfc0 86a0 8906 0x00ff b001 0e24 6314 5150 2322 5250 169f 3b23 0000 bfc0 86a0 8906
Intellectual Property Statement Authors' Addresses
Abigail Surtees
Siemens/Roke Manor Research
Roke Manor Research Ltd.
Romsey, Hants SO51 0ZN
UK
Phone: +44 (0)1794 833131
EMail: abigail.surtees@roke.co.uk
URI: http://www.roke.co.uk
Mark A. West
Siemens/Roke Manor Research
Roke Manor Research Ltd.
Romsey, Hants SO51 0ZN
UK
Phone: +44 (0)1794 833311
EMail: mark.a.west@roke.co.uk
URI: http://www.roke.co.uk
Full 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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 42, line 29 skipping to change at page 43, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
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 (2005). 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.
This Internet-Draft will expire on April 27, 2006. Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 174 change blocks. 
367 lines changed or deleted 341 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/