draft-ietf-rohc-sigcomp-user-guide-01.txt		draft-ietf-rohc-sigcomp-user-guide-02.txt
	Robust Header Compression A. Surtees		Robust Header Compression A. Surtees
	Internet-Draft M. West		Internet-Draft M. West
	Expires: August 19, 2005 Siemens/Roke Manor Research		Expires: January 19, 2006 Siemens/Roke Manor Research
	February 18, 2005		July 18, 2005
	SigComp Users' Guide		SigComp Users' Guide
	draft-ietf-rohc-sigcomp-user-guide-01.txt		draft-ietf-rohc-sigcomp-user-guide-02.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, each author represents that any
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		applicable patent or other IPR claims of which he or she is aware
	author represents that any applicable patent or other IPR claims of		have been or will be disclosed, and any of which he or she becomes
	which he or she is aware have been or will be disclosed, and any of		aware will be disclosed, in accordance with Section 6 of BCP 79.
	which he or she become aware will be disclosed, in accordance with
	RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 19, 2005.		This Internet-Draft will expire on January 19, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document provides an informational guide for users of the		This document provides an informational guide for users of the
	SigComp protocol. The aim of the document is to assist users when		SigComp protocol. The aim of the document is to assist users when
	making SigComp implementation decisions; for example the choice of		making SigComp implementation decisions; for example the choice of
	compression algorithm and the level of robustness against lost or		compression algorithm and the level of robustness against lost or
	misordered packets.		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 . . . . . . . . . . . . . . . . . . . . . 6		3.2.1 Expressions . . . . . . . . . . . . . . . . . . . . . 7
	3.2.2 Instructions . . . . . . . . . . . . . . . . . . . . . 7		3.2.2 Instructions . . . . . . . . . . . . . . . . . . . . . 8
	3.2.3 Directives . . . . . . . . . . . . . . . . . . . . . . 8		3.2.3 Directives . . . . . . . . . . . . . . . . . . . . . . 9
	3.2.4 Labels . . . . . . . . . . . . . . . . . . . . . . . . 9		3.2.4 Labels . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.3 Uploading the bytecode to the UDVM . . . . . . . . . . . . 10		3.3 Uploading the bytecode to the UDVM . . . . . . . . . . . . 10
	4. Compression algorithms . . . . . . . . . . . . . . . . . . . . 11		4. Compression algorithms . . . . . . . . . . . . . . . . . . . . 12
	4.1 Simplified LZ77 . . . . . . . . . . . . . . . . . . . . . 11		4.1 Well-known Compression Algorithms . . . . . . . . . . . . 12
	4.2 LZSS . . . . . . . . . . . . . . . . . . . . . . . . . . . 15		4.1.1 Simplified LZ77 . . . . . . . . . . . . . . . . . . . 12
	4.3 LZW . . . . . . . . . . . . . . . . . . . . . . . . . . . 17		4.1.2 LZSS . . . . . . . . . . . . . . . . . . . . . . . . . 16
	4.4 DEFLATE . . . . . . . . . . . . . . . . . . . . . . . . . 20		4.1.3 LZW . . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.5 LZJH . . . . . . . . . . . . . . . . . . . . . . . . . . . 23		4.1.4 DEFLATE . . . . . . . . . . . . . . . . . . . . . . . 21
	4.6 EPIC . . . . . . . . . . . . . . . . . . . . . . . . . . . 27		4.1.5 LZJH . . . . . . . . . . . . . . . . . . . . . . . . . 24
			4.2 Adapted Algorithms . . . . . . . . . . . . . . . . . . . . 28
			4.2.1 Modified DEFLATE . . . . . . . . . . . . . . . . . . . 28
	5. Additional SigComp mechanisms . . . . . . . . . . . . . . . . 31		5. Additional SigComp mechanisms . . . . . . . . . . . . . . . . 31
	5.1 Acknowledging a state item . . . . . . . . . . . . . . . . 31		5.1 Acknowledging a state item . . . . . . . . . . . . . . . . 32
	5.2 Static dictionary . . . . . . . . . . . . . . . . . . . . 33		5.2 Static dictionary . . . . . . . . . . . . . . . . . . . . 33
	5.3 CRC checksum . . . . . . . . . . . . . . . . . . . . . . . 33		5.3 CRC checksum . . . . . . . . . . . . . . . . . . . . . . . 34
	5.4 Announcing additional resources . . . . . . . . . . . . . 34		5.4 Announcing additional resources . . . . . . . . . . . . . 34
	5.5 Shared compression . . . . . . . . . . . . . . . . . . . . 35		5.5 Shared compression . . . . . . . . . . . . . . . . . . . . 36
	6. Security considerations . . . . . . . . . . . . . . . . . . . 38		6. Security considerations . . . . . . . . . . . . . . . . . . . 37
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
	8. Intellectual Property Right Considerations . . . . . . . . . . 38		8. Intellectual Property Right Considerations . . . . . . . . . . 37
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
	A. UDVM bytecode for the compression algorithms . . . . . . . . . 40		A. UDVM bytecode for the compression algorithms . . . . . . . . . 39
	A.1 Simplified LZ77 . . . . . . . . . . . . . . . . . . . . . 40		A.1 Well-known Algorithms . . . . . . . . . . . . . . . . . . 39
	A.2 LZSS . . . . . . . . . . . . . . . . . . . . . . . . . . . 40		A.1.1 Simplified LZ77 . . . . . . . . . . . . . . . . . . . 39
	A.3 LZW . . . . . . . . . . . . . . . . . . . . . . . . . . . 40		A.1.2 LZSS . . . . . . . . . . . . . . . . . . . . . . . . . 39
	A.4 DEFLATE . . . . . . . . . . . . . . . . . . . . . . . . . 41		A.1.3 LZW . . . . . . . . . . . . . . . . . . . . . . . . . 40
	A.5 LZJH . . . . . . . . . . . . . . . . . . . . . . . . . . . 41		A.1.4 DEFLATE . . . . . . . . . . . . . . . . . . . . . . . 40
	A.6 EPIC . . . . . . . . . . . . . . . . . . . . . . . . . . . 41		A.1.5 LZJH . . . . . . . . . . . . . . . . . . . . . . . . . 40
			A.2 Adapted Algorithms . . . . . . . . . . . . . . . . . . . . 40
			A.2.1 Modified DEFLATE . . . . . . . . . . . . . . . . . . . 40
	Intellectual Property and Copyright Statements . . . . . . . . 42		Intellectual Property and Copyright Statements . . . . . . . . 42
	1. Introduction		1. Introduction
	This document provides an informational guide for users of the		This document provides an informational guide for users of the
	SigComp protocol RFC-3320 [4]. The idea behind SigComp is to		SigComp protocol RFC-3320 [4]. The idea behind SigComp is to
	standardize a Universal Decompressor Virtual Machine (UDVM) that can		standardize a Universal Decompressor Virtual Machine (UDVM) that can
	be programmed to understand the output of many well-known compressors		be programmed to understand the output of many well-known compressors
	including DEFLATE DEFLATE [10] and LZW LZW [9]. The bytecode for the		including DEFLATE [10] and LZW [9]. The bytecode for the choice of
	choice of compression algorithm is uploaded to the UDVM as part of		compression algorithm is uploaded to the UDVM as part of the
	the compressed data.		compressed data.
	The basic SigComp RFC describes the actions that an endpoint must		The basic SigComp RFC describes the actions that an endpoint must
	take upon receiving a SigComp message. However the entity		take upon receiving a SigComp message. However the entity
	responsible for generating new SigComp messages (the SigComp		responsible for generating new SigComp messages (the SigComp
	compressor) is left as an implementation decision; any compressor can		compressor) is left as an implementation decision; any compressor can
	be used provided that it generates SigComp messages that can be		be used provided that it generates SigComp messages that can be
	successfully decompressed by the receiving endpoint.		successfully decompressed by the receiving endpoint.
	This document offers a number of different compressors that can be		This document offers a number of different compressors that can be
	used by the SigComp protocol. It also describes how standard stream-		used by the SigComp protocol. It also describes how standard stream-
	skipping to change at page 3, line 42		skipping to change at page 3, line 42
	algorithms to the receiving endpoint, arbitrary compression		algorithms to the receiving endpoint, arbitrary compression
	algorithms can be supported provided that bytecode has been written		algorithms can be supported provided that bytecode has been written
	for the corresponding decompressor.		for the corresponding decompressor.
	This document provides bytecode for the following algorithms:		This document provides bytecode for the following algorithms:
	1. Simplified LZ77		1. Simplified LZ77
	2. LZSS		2. LZSS
	3. LZW		3. LZW
	4. DEFLATE		4. DEFLATE
	5. LZJH		5. LZJH
	6. EPIC
	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
	skipping to change at page 4, line 46		skipping to change at page 5, line 8
	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-2234 [3] specifies the syntax of a
	token:		token:
	token = (name / opcode / delimiter / dec / bin / hex)		token = (name / opcode / delimiter / dec / bin / hex)
	name = (lowercase / "_") 1*(lowercase / digit / "_")		name = (lowercase / "_") 1*(lowercase / digit / "_")
	opcode = uppercase *(uppercase / digit / "-")		opcode = uppercase *(uppercase / digit / "-")
	delimiter = "." / "!" / "$" / ":" / "(" / ")" / operator		delimiter = "." / "," / "!" / "$" / ":" / "(" / ")" /
			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 = "+" / "-" / "*" / "/" / "%" / "&" / "|" /
	"^" / "~" / "<<" / ">>"		"^" / "~" / "<<" / ">>"
	skipping to change at page 6, line 8		skipping to change at page 6, line 15
	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 black 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		directive = padding / data / set / readonly
	; note that directive names are		; note that directive names are
	; syntactically of category <name>; all		; syntactically of category <name>; all
	; directives are intended to syntactically		; directives are intended to syntactically
	; match: name ["(" expression *(","		; match: name ["(" expression *(","
	; expression) ")"]		; expression) ")"]
	padding = ("pad" / "align" / "at") "(" expression ")"		padding = ("pad" / "align" / "at") "(" expression ")"
	data = ("byte" / "word") "(" expression *(","		data = ("byte" / "word") "(" expression *(","
	expression) ")"		expression) ")"
			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:
	skipping to change at page 7, line 32		skipping to change at page 7, line 44
	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,
			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
			run.
	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:
	skipping to change at page 8, line 30		skipping to change at page 8, line 47
	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 the shortest bytecode capable of encoding the supplied		parser inserts the shortest bytecode capable of encoding the supplied
	memory address. Note that reference operands will always be preceded		memory address. Note that reference operands will always be preceded
	by the symbol "$" in assembly because they always encode memory		by the symbol "$" in assembly because they always encode memory
	addresses rather than actual operand values.		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 the shortest bytecode capable of encoding the supplied		it inserts the shortest bytecode capable of encoding the supplied
	integer as a memory address. If not then it inserts the shortest		integer as a memory address. If not then, as per Figure 10 of
	bytecode that encodes the supplied integer as an operand value.		SigComp, it inserts the shortest bytecode that encodes 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 as
	a memory address, just as for the multitype instruction above. If		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.
	3.2.3 Directives		3.2.3 Directives
	skipping to change at page 9, line 33		skipping to change at page 9, line 51
	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.		which 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
			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
			be used, for example, in conjunction with "!" to ensure that the
			address of the nearest zero will still contain zero when the bytecode
			is executed.
	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 giving a single colon followed by the text
	name to be defined. The (absolute) position of the byte immediately		name to 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:
	skipping to change at page 11, line 28		skipping to change at page 12, line 14
	(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 chapter 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.		message.
	Section 4.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 Simplified LZ77		4.1 Well-known Compression Algorithms
			4.1.1 Simplified 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 LZ77 [7].		algorithm based on LZ77 [7].
	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:
	skipping to change at page 12, line 29		skipping to change at page 13, line 17
	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
	sequence of position/length pairs that encode a given message. For		sequence of position/length pairs that encode a given message. For
	example, a byte with value 0x41 (corresponding to the ASCII character		example, a byte with value 0x41 (corresponding to the ASCII character
	"A") can be found at Address 0x0141 of the UDVM memory, so the		"A") can be found at Address 0x0141 of the UDVM memory, so the
	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 however,		as a separate 4-byte compressed character is not recommended,
	as the resulting "compressed" message is four times as large as the		however, as the resulting "compressed" message is four times as large
	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.
	Note that the actual size of this circular buffer depends on the		Note that the actual size of this circular buffer depends on the
	total amount of memory available to the UDVM. The minimum size of		total amount of memory available to the UDVM. The minimum size of
	the		the UDVM memory is 1K, so the circular buffer will always contain at
	UDVM memory is 1K, so the circular buffer will always contain at
	least 512 bytes.		least 512 bytes.
	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:
	skipping to change at page 15, line 16		skipping to change at page 15, line 48
	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
			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 to
	improve the overall compression ratio it is important to avoid		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
	skipping to change at page 15, line 46		skipping to change at page 16, line 35
	+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+
	| |		| |
	: 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 [RFC-		the state identifier for the state item to be accessed (see [RFC-
	3320] for details of how state identifiers are derived).		3320] for details of how state identifiers are derived).
	4.2 LZSS		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 LZSS [8].		compression algorithm [8].
	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
	skipping to change at page 17, line 40		skipping to change at page 18, line 29
	returned_parameters_location, state_length, 64,		returned_parameters_location, state_length, 64,
	decompress_sigcomp_message, 6, 0)		decompress_sigcomp_message, 6, 0)
	:circular_buffer		:circular_buffer
	An example message compressed using the LZSS algorithm is given		An example 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
	4.3 LZW		The uncompressed message is "Oh no, not again!".
			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 [9]. 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
	skipping to change at page 20, line 4		skipping to change at page 20, line 43
	; position/length pair:		; position/length pair:
	OUTPUT ($position_value, $length_value)		OUTPUT ($position_value, $length_value)
	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)
	:static_dictionary pad (256)		:static_dictionary pad (256)
	:circular_buffer		:circular_buffer
	at (4492)		at (4492)
	:codebook		:codebook
	An example 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
	4.4 DEFLATE		The uncompressed message is "So long and thanks for all the fish!\n".
			4.1.4 DEFLATE
	This section provides UDVM bytecode for the DEFLATE compression		This section provides UDVM bytecode for the DEFLATE compression
	algorithm. DEFLATE is the algorithm used in the well-known "gzip"		algorithm. DEFLATE is the algorithm used in the well-known "gzip"
	file format.		file format.
	The following bytecode will decompress the DEFLATE compressed data		The following bytecode will decompress the DEFLATE compressed data
	format DEFLATE [10] with the following modifications:		format DEFLATE [10] with the following modifications:
	1. The DEFLATE compressed data format separates blocks of compressed		1. The DEFLATE compressed data format separates blocks of compressed
	data by transmitting 7 consecutive zero bits. Each SigComp		data by transmitting 7 consecutive zero bits. Each SigComp
	message is assumed to contain a separate block of compressed		message is assumed to contain a separate block of compressed
	data, so the end-of-block bits are implicit and do not need to be		data, so the end-of-block bits are implicit and do not need to be
	transmitted at the end of a SigComp message.		transmitted at the end of a SigComp message.
	2. The bytecode supports only DEFLATE block type 01 (data compressed		2. This bytecode supports only DEFLATE block type 01 (data
	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)
	:index pad (2)		:index pad (2)
	:extra_length_bits pad (2)		:extra_length_bits pad (2)
	:length_value pad (2)		:length_value pad (2)
	:extra_distance_bits pad (2)		:extra_distance_bits pad (2)
	:distance_value pad (2)		:distance_value pad (2)
	skipping to change at page 23, line 7		skipping to change at page 23, line 46
	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)
	:circular_buffer		:circular_buffer
	An example message compressed using the DEFLATE algorithm is given		An example message compressed using the DEFLATE algorithm is given
	below:		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 0000 00ff ff00		0x2b4b 3232 f3d2 b900
	4.5 LZJH		The uncompressed message is "Life, the Universe and Everything\n".
			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 LZJH [11].
	Assembly for the LZJH decompressor is given below:		Assembly for the LZJH decompressor is given below:
	at (32)		at (32)
	; The following 2-byte variables are stored in the scratch-pad memory		; The following 2-byte variables are stored in the scratch-pad memory
	skipping to change at page 27, line 21		skipping to change at page 28, line 16
	decompress_sigcomp_message, 6, 0)		decompress_sigcomp_message, 6, 0)
	:circular_buffer		:circular_buffer
	An example message compressed using the LZJH algorithm is given		An example 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
	4.6 EPIC		The uncompressed message is "...spending a year dead for tax
			purposes.\n".
	This section provides bytecode for a version of the Efficient
	Protocol Independent Compression (EPIC) scheme.
	The basic EPIC scheme is designed to compress protocol headers such
	as TCP/IP, but the underlying algorithm (known as Hierarchical
	Huffman) can be applied to the compression of arbitrary data. In
	particular the compression algorithm used by EPIC obtains a very high
	compression ratio on data with a known structure, so it is ideally
	suited for compressing the messages generated by SIP or other
	signaling protocols.
	Note however that in its basic form the EPIC algorithm does not have
	the ability to detect and adapt to new patterns in the uncompressed
	data; instead it relies on a fixed pre-programmed description of how
	the protocol to be compressed is expected to behave.
	The application messages encountered by SigComp will typically
	contain segments of generic text that cannot be compressed using the
	basic EPIC scheme. Fortunately however, EPIC can easily be upgraded
	to cope with generic data by adding the ability to store a circular
	buffer of previously received text strings as per LZ77 or DEFLATE.
	The resulting hybrid algorithm offers the best of both worlds: a very
	high compression ratio for the "well-behaved" parts of the
	application message, and a good compression ratio even for the
	portions of the message that cannot be pre-programmed into the
	compression algorithm.
	The following bytecode implements a decompressor for a hybrid of EPIC
	and DEFLATE. The tables of compressed characters are generated using
	the Hierarchical Huffman algorithm from EPIC, and are designed to
	give a very high compression ratio for a typical SIP/SDP message.
	The ability to store and retrieve text strings from a buffer of
	previously received messages is taken from DEFLATE.
	To illustrate the performance of the hybrid algorithm, the following		4.2 Adapted Algorithms
	results have been generated for the call flow in Section 3.2.1 of
	"SIP Call Flow Examples" FLOWS [1]. Note that to improve the overall
	compression ratio, all algorithms employ a static dictionary (see
	Section 5.2) and the shared compression mechanism (see Section 5.5):
	Algorithm: Total compressed message size:		4.2.1 Modified DEFLATE
	DEFLATE with static Huffman codes 660 bytes		Alternative algorithms can also be used with SigComp. This section
	DEFLATE with adaptive Huffman codes 625 bytes		shows a modified version of the DEFLATE [10] algorithm. The two-
	EPIC 560 bytes		stage encoding of DEFLATE is replaced by a single step with a
			discrete Huffman code for each symbol. The literal/length symbol
			probabilities are dependent upon whether the previously symbol was a
			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
			bit does not change so all bits are input, read and interpreted in
			the same order.
	Assembly for the EPIC algorithm is given below. A compressor to		Assembly for the algorithm is given below. String matching rules are
	generate messages for this algorithm can be adapted from an ordinary		the same as for the other LZ-based algorithms, with the alternative
	DEFLATE compressor; the string matching rules should be left		encoding of the literals and length/distance pairs.
	unchanged but the tables of Huffman codes used by DEFLATE should be
	replaced by those used in the following assembly:
	at (32)		at (32)
	:index pad (2)		:index pad (2)
	:distance_value pad (2)		:distance_value pad (2)
	:old_pointer pad (2)		:old_pointer pad (2)
	at (42)		at (42)
	set (requested_feedback_location, 0)		set (requested_feedback_location, 0)
	skipping to change at page 30, line 44		skipping to change at page 31, line 4
	LOAD (old_pointer, $decompressed_pointer)		LOAD (old_pointer, $decompressed_pointer)
	COPY-OFFSET ($distance_value, $index, $decompressed_pointer)		COPY-OFFSET ($distance_value, $index, $decompressed_pointer)
	OUTPUT ($old_pointer, $index)		OUTPUT ($old_pointer, $index)
	JUMP (character_after_match)		JUMP (character_after_match)
	: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)
	:circular_buffer		:circular_buffer
	An example message compressed using the EPIC algorithm is given		An example message compressed using the modified DEFLATE algorithm is
	below:		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
			hearing the phone ring".
	5. Additional SigComp mechanisms		5. Additional SigComp mechanisms
	The following chapter covers the additional mechanisms that can be		The following chapter covers the additional mechanisms that can be
	employed by SigComp to improve the overall compression ratio;		employed by SigComp to improve the overall compression ratio;
	including the acknowledgment of SigComp state over an unreliable		including the acknowledgment of SigComp state over an unreliable
	link, sharing state between two directions of a compressed message		link, sharing state between two directions of a compressed message
	flow etc.		flow etc.
	When each of the compression algorithms described in Chapter 4 has		When each of the compression algorithms described in Chapter 4 has
	successfully decompressed the current SigComp message, the contents		successfully decompressed the current SigComp message, the contents
	skipping to change at page 34, line 30		skipping to change at page 34, line 44
	found in SigComp RFC-3320 [4].		found in SigComp RFC-3320 [4].
	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
			useful for the remote endpoing to reference, it can advertise the
			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
			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 feedback mechanism:		the SigComp advertisement mechanism:
	cycles_per_bit decompression_memory_size state_memory_size		cycles_per_bit
			decompression_memory_size
			state_memory_size>
	SigComp_version		SigComp_version
			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 |
			+---+---+---+---+---+---+---+---+
			| |
			: partial_state_identifier_1 :
			| |
			+---+---+---+---+---+---+---+---+
			: :
			+---+---+---+---+---+---+---+---+
			| length_of_partial_state_ID_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 Chapter 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_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)
			where x is enough space for the number state identifiers that the
			endpoint wishes to advertise.
	When a SigComp message is successfully decompressed and saved as		When a SigComp message is successfully decompressed and saved as
	state, the following bytecode announces to the receiving endpoint		state, the following bytecode announces to the receiving endpoint
	that additional resources are available at the sending endpoint:		that additional resources and pieces of state are available at the
			sending endpoint:
	:end_of_message		:end_of_message
	LOAD (returned_parameters_location, N)		LOAD (returned_parameters_location, N)
			INPUT-BYTES (1, adverts_len_lsb, done)
			INPUT-BYTES ($adverts_len, state_ids, 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
			identifiers in the format shown are appended to the end of the
			compressed 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 [5]. 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 [5], two steps must be taken to implement
	shared compression at an endpoint. Firstly, it is necessary to		shared compression at an endpoint.
	announce to the remote endpoint that shared compression is available.
	Secondly, assuming that such an announcement is received from the
	remote endpoint, then the state created by shared compression must be
	accessed to improve the overall compression ratio.
	In order to announce that shared compression is available the
	following fields must be reserved in the UDVM memory:
	0 1 2 3 4 5 6 7		Firstly, it is necessary to announce to the remote endpoint that
	+---+---+---+---+---+---+---+---+		shared compression is available. This is done by announcing the
	| cpb | dms | sms | returned_parameters_location		state identifier as an available piece of state. This can be done
	+---+---+---+---+---+---+---+---+		using the returned_parameters_location announcement as in
	| SigComp_version |		Section 5.4.
	+---+---+---+---+---+---+---+---+
	| length_of_partial_state_ID_1 |
	+---+---+---+---+---+---+---+---+
	| |
	: partial_state_identifier_1 :
	| |
	+---+---+---+---+---+---+---+---+
	: :
	+---+---+---+---+---+---+---+---+
	| length_of_partial_state_ID_n |
	+---+---+---+---+---+---+---+---+
	| |
	: partial_state_identifier_n :
	| |
	+---+---+---+---+---+---+---+---+
	These fields can be reserved in any of the algorithms of Chapter 4 by		Secondly, assuming that such an announcement is received from the
	replacing the line "set (returned_parameters_location, 0)" with the		remote endpoint, then the state created by shared compression needs
	following piece of assembly:		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
			Section Section 5.2), but using the appropriate state identifier, for
			example, by using the INPUT-BYTES instruction as below:
	:returned_parameters_location pad (1)
	:returned_sigcomp_version pad (1)
	:length_of_partial_state_id_a pad (1)
	:partial_state_identifier_a pad (6)
	:length_of_partial_state_id_b pad (1)
	:partial_state_identifier_b pad (20)
	:extended_flags pad (2)
	:shared_state_id pad (6)		:shared_state_id pad (6)
	:padding pad (6)
	:minimum_access_length pad (2)
	:announcement_location pad (2)
	:decompressed_start pad (2)
	:decompressed_length pad (2)
	:shared_hash_length pad (2)
	In Figure 5 of [RFC-3321], an example SigComp message format is
	provided to carry the shared compression information between the two
	endpoints. This message format can be decompressed at the receiving
	endpoint by inserting the following assembly after the label
	":decompress_sigcomp_message" in one of the algorithms of Chapter 4:
	:decompress_sigcomp_message
	INPUT-BYTES (1, extended_flags, !)
	COMPARE ($extended_flags, 32768, initialize_state_announcement,
	access_shared_state, access_shared_state)
	: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)
	:initialize_state_announcement
	MULTILOAD (minimum_access_length, 4, 6, length_of_partial_state_id_a,
	$decompressed_pointer, 5120)
	COPY-LITERAL (padding, 8, $decompressed_pointer)
	LSHIFT ($extended_flags, 1)
	COMPARE ($extended_flags, 32768, algorithm_start,
	announce_acked_state_id, announce_acked_state_id)
	:announce_acked_state_id
	LOAD (length_of_partial_state_id_a, 1536)
	INPUT-BYTES (6, partial_state_identifier_a, !)
	LOAD (announcement_location, length_of_partial_state_id_b)
	:algorithm_start
	Additionally, the following piece of assembly should be inserted
	following the label ":end_of_message" in the chosen algorithm:
	:end_of_message
	LSHIFT ($extended_flags, 1)
	COMPARE ($extended_flags, 32768, end, announce_shared_state,
	announce_shared_state)
	:announce_shared_state
	; The following instructions calculate the shared state identifier:
	COPY-LITERAL (decompressed_length, 1, $announcement_location)
	set (buffer_size, (udvm_memory_size - circular_buffer))
	MULTILOAD (decompressed_length, 2, 65528, $decompressed_pointer)
	SUBTRACT ($shared_hash_length, $decompressed_start)
	REMAINDER ($shared_hash_length, buffer_size)
	ADD ($decompressed_length, $shared_hash_length)
	LOAD ($decompressed_start, $decompressed_length)
	SHA-1 ($decompressed_start, $shared_hash_length,
	$announcement_location)
	:end
	6. Security considerations		6. Security considerations
	This draft describes implementation options for the SigComp protocol		This draft describes implementation options for the SigComp protocol
	RFC-3320 [4]. Consequently the security considerations for this		RFC-3320 [4]. Consequently the security considerations for this
	draft match those of SigComp.		draft match those of SigComp.
	7. Acknowledgements		7. Acknowledgements
	Thanks to		Thanks to
			Richard Price
	Carsten Bormann		Carsten Bormann
	Adam Roach		Adam Roach
	Lawrence Conroy		Lawrence Conroy
	Christian Schmidt		Christian Schmidt
	Max Riegel		Max Riegel
	Lars-Erik Jonsson		Lars-Erik Jonsson
	Jonathan Rosenberg		Jonathan Rosenberg
	Stefan Forsgren		Stefan Forsgren
	Krister Svanbro		Krister Svanbro
	Miguel Garcia		Miguel Garcia
	skipping to change at page 39, line 5		skipping to change at page 38, line 5
	for valuable input and review.		for valuable input and review.
	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. References
	[1] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K.		[1] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
	Summers, "Session Initiation Protocol (SIP) Basic Call Flow		Summers, "Session Initiation Protocol (SIP) Basic Call Flow
	Examples", RFC 3665, December 2003.		Examples", RFC 3665, December 2003.
	[2] Bradner, S., "The Internet Standards Process -- Revision 3",		[2] Bradner, S., "The Internet Standards Process -- Revision 3",
	RFC 3667, February 2004.		RFC 3667, February 2004.
	[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 2234, November 1997.		Specifications: ABNF", RFC 2234, November 1997.
	[4] Price, R., Borman, C., Christoffersson, J., Hannu, H., Liu, Z.		[4] Price, R., Borman, C., Christoffersson, J., Hannu, H., Liu, Z.,
	and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320,		and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320,
	January 2003.		January 2003.
	[5] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K., Liu,		[5] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K., Liu,
	Z. and R. Price, "Signaling Compression (SigComp)", RFC 3321,		Z., and R. Price, "Signaling Compression (SigComp) - Extended
	January 2003.		Operations", RFC 3321, January 2003.
	[6] Garcia-Martin, M., Borman, C., Ott, J., Price, R. and A. Roach,		[6] Garcia-Martin, M., Borman, C., Ott, J., Price, R., and A.
	"The Session Initiation Protocol (SIP) and Session Description		Roach, "The Session Initiation Protocol (SIP) and Session
	Protocol (SDP) Statc Dictionary for Signaling Compression		Description Protocol (SDP) Statc Dictionary for Signaling
	(SigComp)", RFC 3485, February 2003.		Compression (SigComp)", RFC 3485, February 2003.
	[7] Ziv, J. and A. Lempel, "A universal algorithm for sequential		[7] 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		[8] 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, October		[9] Nelson, M., "LZW Data Compression", Dr Dobb's Journal,
	1989.		October 1989.
	[10] Deutsch, P., "DEFLATE Compressed Data Format Specification		[10] 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,		[11] "Data Compression Procedures", ITU-T Recommendation V.44,
	November 2000.		November 2000.
	Authors' Addresses		Authors' Addresses
	Abigail Surtees		Abigail Surtees
	Siemens/Roke Manor Research		Siemens/Roke Manor Research
	Roke Manor Research Ltd.		Roke Manor Research Ltd.
	Romsey, Hants SO51 0ZN		Romsey, Hants SO51 0ZN
	UK		UK
	Phone: +44 (0)1794 833131		Phone: +44 (0)1794 833131
	EMail: abigail.surtees@roke.co.uk		Email: abigail.surtees@roke.co.uk
	URI: http://www.roke.co.uk		URI: http://www.roke.co.uk
	Mark A. West		Mark A. West
	Siemens/Roke Manor Research		Siemens/Roke Manor Research
	Roke Manor Research Ltd.		Roke Manor Research Ltd.
	Romsey, Hants SO51 0ZN		Romsey, Hants SO51 0ZN
	UK		UK
	Phone: +44 (0)1794 833311		Phone: +44 (0)1794 833311
	EMail: mark.a.west@roke.co.uk		Email: mark.a.west@roke.co.uk
	URI: http://www.roke.co.uk		URI: http://www.roke.co.uk
	Appendix A. UDVM bytecode for the compression algorithms		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 Simplified LZ77		A.1 Well-known Algorithms
			A.1.1 Simplified 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.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.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.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.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.6 EPIC		A.2 Adapted Algorithms
			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
	skipping to change at page 42, line 50		skipping to change at page 42, line 50
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
	This Internet-Draft will expire on August 19, 2005.		This Internet-Draft will expire on January 19, 2006.
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/