Network Working Group Richard Price, Siemens/Roke Manor
INTERNET-DRAFT Robert Hancock, Siemens/Roke Manor
Expires: August 2001 Stephen McCann, Siemens/Roke Manor
Mark West, Siemens/Roke Manor
Abigail Surtees, Siemens/Roke Manor
Paul Ollis, Siemens/Roke Manor
Christian Schmidt, Siemens
February 23, 2001
Robust SCTP/IP Compression Using EPIC
<draft-price-rohc-epic-sctp-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
http://www.ietf.org/shadow.html.
This document is a submission to the IETF ROHC WG. Comments should be
directed to the mailing list of ROHC, rohc@cdt.luth.se.
Abstract
The Efficient Protocol Independent Compression [EPIC] scheme is a
general mechanism for providing additional profiles for use within
the [ROHC8] framework. The EPIC inputset is a list of fields from the
protocol stack to be compressed, and for each field a choice of
encoding techniques together with the probabilities that they will be
used. The output of EPIC is a set of optimally efficient compressed
header formats for the chosen protocol stack, and an automatic
mechanism for translating between compressed and uncompressed packet
formats.
This document describes an EPIC inputset for the robust compression
of [SCTP].
Price et al. [PAGE 1]
INTERNET-DRAFT SCTP/IP Compression February 23, 2001
Table of contents
1. Introduction.................................................2
2. Sub-Context Control Field....................................2
3. General SCTP/IP Profile......................................4
3.1. Miscellaneous Information fields...........................7
3.2. UNCOMPRESSED encodings.....................................7
3.3. INFERRED encodings.........................................8
4. Security considerations......................................8
5. Acknowledgements.............................................8
6. Intellectual Property Considerations.........................8
7. References...................................................9
8. Authors' Addresses...........................................9
1. Introduction
SCTP is the new reliable transport protocol from the IETF. It offers
a number of features not available in other reliable transport
protocols such as TCP, including multi-streaming (described in
Chapter 2), multi-homing and resistance to flooding and masquerade
attacks. SCTP is designed to transport PSTN signaling messages over
IP networks but its rich feature set makes it capable of many broader
applications.
The [ROHC8] scheme offers an efficient and flexible framework for
robust header compression. The ROHC framework is designed to accept
new "profiles" for the compression of different protocol stacks, and
the [EPIC] scheme is a method for generating these profiles. EPIC is
basically a programmable compressor that can be configured to handle
any protocol stack.
The robust compression of SCTP/IP headers is greatly simplified by
the EPIC scheme. EPIC allows the SCTP field behaviors to be specified
in the form of an inputset, and then uses this information to
automatically build an optimally efficient set of compressed header
formats. This profile slots into the robust header compression
framework specified in [ROHC8].
The following chapter discusses the new features of the SCTP protocol
and how they may be efficiently compressed.
2. Sub-Context Control Field
One of the most important innovations of SCTP is the multi-streaming
function. This feature allows data to be partitioned into multiple
streams where each stream is delivered independently, so in-sequence
delivery can be guaranteed only for packets within a single stream.
The advantage of this technique is that when a packet is lost, only
the data from the corresponding stream is delayed whilst the packet
is retransmitted. Packets from other streams are unaffected by the
loss.
From the header compression point of view the multi-streaming
function raises a host of new issues to solve. Most importantly a
Price et al. [PAGE 2]
INTERNET-DRAFT SCTP/IP Compression February 23, 2001
single SCTP header has two distinct types of fields: the general
fields common to every packet delivered to a given port, and the
stream-specific fields that behave differently depending on the
stream to which they belong. To obtain maximum compression efficiency
it is important to maintain a separate context for the stream-
specific fields from each stream, but to use a shared context for all
general fields. This cannot be accomplished using the techniques
currently offered by [ROHC8] or [EPIC].
The solution is to add a new control field to the EPIC scheme. Recall
from Chapter 7 of [EPIC] that a control field transmits information
from the compressor to the decompressor that is not part of the
uncompressed header - for example the header CRC field. Control
fields are often used by the compressor to switch the decompressor
into a new mode of operation, for example changing from Reliable Mode
to Unidirectional Mode if the feedback channel becomes unavailable.
The new control field is called the Sub-Context field. Its purpose is
to specify the stream to which each header belongs, so that the
header can be decompressed relative to the correct stream.
An example of the Sub-context field in action is given in the
following EPIC input table:
STREAM-SPECIFIC-ENCODING: STREAM("0","1","2","3")
+------------------------+----------------------------+-------------+
| Field Name(s) | Encoding Method | Probability |
+------------------------+----------------------------+-------------+
| Sub-Context | INFERRED | 100% |
| Stream Sequence Number | | |
+------------------------+----------------------------+-------------+
| U Flag | STATIC | 99.9% |
| +----------------------------+-------------+
| | IRREGULAR(1) | 0.1% |
+------------------------+----------------------------+-------------+
| BE Flag | STATIC | 99% |
| +----------------------------+-------------+
| | IRREGULAR(2) | 1% |
+------------------------+----------------------------+-------------+
| Payload Protocol Ident | STATIC | 99.9% |
| +----------------------------+-------------+
| | IRREGULAR(32) | 0.1% |
+------------------------+----------------------------+-------------+
This input table compresses all of the stream-specific fields in an
SCTP data chunk. The compressor and decompressor maintain a separate
context for each stream, and MUST compress and decompress the stream-
specific fields relative to the context selected by the Sub-context
field.
The Sub-Context field covers all of the fields in a single input
table, but not the fields described in different input tables. For
these general fields the compressor and decompressor MUST compress
Price et al. [PAGE 3]
INTERNET-DRAFT SCTP/IP Compression February 23, 2001
and decompress relative to the last packet received regardless of the
stream to which it belongs.
3. General SCTP/IP Profile
The EPIC inputset for a general SCTP/IP profile is given below.
Further information on how to construct and process an inputset can
be found in [EPIC].
SCTP/IPv4-ENCODING:
+------------------------+----------------------------+-------------+
| Field Name(s) | Encoding Method | Probability |
+------------------------+----------------------------+-------------+
| CRC | IRREGULAR(3) | 99% |
| +----------------------------+-------------+
| | IRREGULAR(7) | 1% |
+------------------------+----------------------------+-------------+
| Master Sequence Number | LSB(4,0) | 99% |
| +----------------------------+-------------+
| | LSB(7,112) | 1% |
+------------------------+----------------------------+-------------+
| SCTP Header | SCTP-ENCODING | 100% |
+------------------------+----------------------------+-------------+
| Inner IPv4 Header | IPv4-ENCODING | 100% |
+------------------------+----------------------------+-------------+
| Optional Extensions | EXTENSION-ENCODING | 100% |
+------------------------+----------------------------+-------------+
Notes:
The CRC checksum covers the uncompressed header and ensures that
decompression has occurred successfully for each packet.
The SCTP profile is robust against dropped, retransmitted and
reordered packets. Up to 14 packets may be lost consecutively and
packets may be retransmitted over 100 places out of sequence without
causing a decompression failure.
The IPv4-ENCODING and EXTENSION-ENCODING are the same as for
RTP/UDP/IPv4 compression, and can be found in [EPIC].
The encoding method for the SCTP header itself is described below:
SCTP-ENCODING: CHUNKS{"1"}
+------------------------+----------------------------+-------------+
| Field Name(s) | Encoding Method | Probability |
+------------------------+----------------------------+-------------+
| Source Port | STATIC | 100% |
| Destination Port | | |
+------------------------+----------------------------+-------------+
| Verification Tag | INFERRED | 100% |
+------------------------+----------------------------+-------------+
Price et al. [PAGE 4]
INTERNET-DRAFT SCTP/IP Compression February 23, 2001
+------------------------+----------------------------+-------------+
| Verification Tag Value | UNCOMPRESSED | 100% |
+------------------------+----------------------------+-------------+
| SCTP Checksum | IRREGULAR(32) | 100% |
+------------------------+----------------------------+-------------+
| TSN LSBs | IRREGULAR(0) | 99% |
| +----------------------------+-------------+
| | IRREGULAR(8) | 0.9% |
| +----------------------------+-------------+
| | IRREGULAR(16) | 0.09% |
| +----------------------------+-------------+
| | IRREGULAR(32) | 0.01% |
+------------------------+----------------------------+-------------+
| Chunks Per Packet | STATIC | 99.9% |
| +----------------------------+-------------+
| | WRITE(2,CHUNKS,1) | 0.1% |
+------------------------+----------------------------+-------------+
| Data Chunk | DATA-CHUNK-ENCODING | 100% |
| Sub-Context | | |
+------------------------+----------------------------+-------------+
Notes:
The term "Data Chunk" refers to all of the fields in a Payload Data
Chunk as defined in Section 3.3.1 of [SCTP].
The current SCTP profile only compresses a single data chunk per
packet. If a packet contains more than one chunk, or if it contains a
control chunk, the remaining chunks MUST be transmitted uncompressed
as part of the payload data.
The Transmission Sequence Number (TSN) can be compressed in a very
similar manner to the TCP Sequence Number. It can usually be inferred
by adding one to the previous TSN for every data chunk in the SCTP
packet. The Master Sequence Number increases by one for every
consecutive SCTP packet, and hence indicates whether packets have
been lost between the compressor and decompressor. Any lost packets
are assumed by the decompressor to contain the number of data chunks
specified by the "Chunks Per Packet" field. The only problem occurs
when a packet does not contain the expected number of data chunks,
which can be accommodated by transmitting the TSN in part or in full
to override the 'guess' made by the decompressor.
The SCTP Checksum is transmitted in full to prevent violation of the
end-to-end principle.
The following encoding compresses the fields in a Payload Data Chunk:
Price et al. [PAGE 5]
INTERNET-DRAFT SCTP/IP Compression February 23, 2001
DATA-CHUNK-ENCODING:
+------------------------+----------------------------+-------------+
| Field Name(s) | Encoding Method | Probability |
+------------------------+----------------------------+-------------+
| TSN | INFERRED | 100% |
+------------------------+----------------------------+-------------+
| Length | STATIC | 80% |
| +----------------------------+-------------+
| | LSB(4,8) | 15% |
| +----------------------------+-------------+
| | LSB(8,128) | 4% |
| +----------------------------+-------------+
| | IRREGULAR(16) | 1% |
+------------------------+----------------------------+-------------+
| Type | VALUE("00000000") | 100% |
+------------------------+----------------------------+-------------+
| Reserved | VALUE("00000") | 100% |
+------------------------+----------------------------+-------------+
| Stream Identifier | STATIC | 80% |
| +----------------------------+-------------+
| | READ(STREAM,4) | 19% |
| +----------------------------+-------------+
| | WRITE(16,STREAM,4) | 1% |
+------------------------+----------------------------+-------------+
| Sub-Context | STREAM-SPECIFIC-ENCODING | 100% |
| Stream Sequence Number | | |
| U Flag | | |
| BE Flag | | |
| Payload Protocol Ident | | |
+------------------------+----------------------------+-------------+
Notes:
The TSN can be inferred from the Master Sequence Number as explained
in Section 3.3.
The Length field cannot be inferred from the overall packet size
because the packet may contain more than one chunk. However it can
still be compressed effectively using LSB (Least Significant Bit)
encoding.
The fields that require separate contexts for every SCTP stream are
compressed separately using the STREAM-SPECIFIC-ENCODING table. This
table is given below:
Price et al. [PAGE 6]
INTERNET-DRAFT SCTP/IP Compression February 23, 2001
STREAM-SPECIFIC-ENCODING: STREAM("0","1","2","3")
+------------------------+----------------------------+-------------+
| Field Name(s) | Encoding Method | Probability |
+------------------------+----------------------------+-------------+
| Sub-Context | INFERRED | 100% |
| Stream Sequence Number | | |
+------------------------+----------------------------+-------------+
| U Flag | STATIC | 99.9% |
| +----------------------------+-------------+
| | IRREGULAR(1) | 0.1% |
+------------------------+----------------------------+-------------+
| BE Flag | STATIC | 99% |
| +----------------------------+-------------+
| | IRREGULAR(2) | 1% |
+------------------------+----------------------------+-------------+
| Payload Protocol Ident | STATIC | 99.9% |
| +----------------------------+-------------+
| | IRREGULAR(32) | 0.1% |
+------------------------+----------------------------+-------------+
Notes:
The profile currently handles up to four simultaneous SCTP streams,
although this number can be increased by adding more entries to the
STREAM lookup table at a cost of reduced compression efficiency.
3.1. Miscellaneous Information fields
The Miscellaneous Information fields are used by EPIC to carry
control information from the compressor to the decompressor. These
fields are not present in the decompressed header. The SCTP profile
requires the following Miscellaneous Information fields:
TSN LSBs: This field carries the LSBs (Least Significant Bits) of the
TSN whenever a packet does not contain the expected number of chunks
specified by the "Chunks Per Packet" field. The TSN LSBs ensure that
the TSN is decompressed correctly even if packets are lost.
Verification Tag Value: This field carries the uncompressed value of
the Verification Tag in the two cases that it cannot be inferred. The
first case is when the packet contains a SHUTDOWN-COMPLETE chunk and
the second case is when it contains an ABORT chunk. If neither of
these cases occur then the field is left empty.
Chunks Per Packet: If packets are dropped then the decompressor
infers the Transmission Sequence Number on the assumption that the
dropped packets contain this number of chunks. The TSN LSBs are used
to refine this guess if necessary.
3.2. UNCOMPRESSED encodings
The length of the Verification Tag Value field is inferred at the
decompressor by checking whether the packet contains a SHUTDOWN-
Price et al. [PAGE 7]
INTERNET-DRAFT SCTP/IP Compression February 23, 2001
COMPLETE chunk or an ABORT chunk. If this is the case then the field
is 4 bytes long, otherwise it is empty.
3.3. INFERRED encodings
The Verification Tag is copied directly from the Verification Tag
Value field when the packet contains a SHUTDOWN-COMPLETE chunk or
when it contains an ABORT chunk. If neither of these cases occur then
the Verification Tag field can be inferred from the Initiate Tag
received from the peer endpoint.
The Sub-Context field is inferred from the index of the Stream
Identifier. Note that the Sub-Context field is 2 bits long since the
SCTP profile currently handles at most 4 simultaneous streams.
The TSN field is inferred by adding the number of data chunks
contained in the previous packet to the TSN field value in the
context. Any dropped packets are assumed to contain the number of
chunks specified by the "Chunks Per Packet" field. If TSN LSBs are
sent then they are used to replace the LSBs of the estimated TSN.
The Stream Sequence Number is inferred from the Master Sequence
Number.
4. Security Considerations
EPIC generates compressed header formats for direct use in ROHC
profiles. Consequently the security considerations for EPIC match
those of [ROHC8].
5. Acknowledgements
Header compression schemes from [ROHC8] have been important sources
of ideas and knowledge. Basic Huffman encoding [HUFF] was enhanced
for the specific tasks of robust, efficient header compression.
Thanks to
Carsten Bormann (cabo@tzi.org)
Max Riegel (maximilian.riegel@icn.siemens.de)
for valuable input and review.
6. Intellectual Property Considerations
This proposal in is full conformity with [RFC-2026].
Siemens may have patent rights on technology described in this
document which employees of Siemens contribute for use in IETF
standards discussions. In relation to any IETF standard incorporating
any such technology, Siemens hereby agrees to license on fair,
Price et al. [PAGE 8]
INTERNET-DRAFT SCTP/IP Compression February 23, 2001
reasonable and non-discriminatory terms, based on reciprocity, any
patent claims it owns covering such technology, to the extent such
technology is essential to comply with such standard.
7. References
[SCTP] "Stream Control Transmission Protocol", Stewart et al,
RFC 2960, Internet Engineering Task Force, October 2000
[EPIC] "Efficient Protocol Independent Compression (EPIC)",
Price et al, <draft-price-rohc-epic-01.txt>, Internet
Engineering Task Force, February 23, 2001
[ROHC8] "RObust Header Compression (ROHC)", Carsten Bormann et
al, <draft-ietf-rohc-rtp-08.txt>, Internet Engineering
Task Force, February 7, 2001
[HUFF] "The Data Compression Book", Mark Nelson and Jean-Loup
Gailly, M&T Books, 1995
[IMPL] http://www.roke.co.uk/networks/epic/epic.html
[RFC-2026] "The Internet Standards Process - Revision 3", Scott
Bradner, Internet Engineering Task Force, October 1996
8. Authors' Addresses
Richard Price Tel: +44 1794 833681
Email: richard.price@roke.co.uk
Robert Hancock Tel: +44 1794 833601
Email: robert.hancock@roke.co.uk
Stephen McCann Tel: +44 1794 833341
Email: stephen.mccann@roke.co.uk
Mark A West Tel: +44 1794 833311
Email: mark.a.west@roke.co.uk
Abigail Surtees Tel: +44 1794 833131
Email: abigail.surtees@roke.co.uk
Paul Ollis Tel: +44 1794 833168
Email: paul.ollis@roke.co.uk
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
Price et al. [PAGE 9]
INTERNET-DRAFT SCTP/IP Compression February 23, 2001
Christian Schmidt Tel: +49 89 722 27822
Email: christian.schmidt@icn.siemens.de
Siemens ICM N MR ST1
Munich
Germany
Price et al. [PAGE 10]