Robust Header Compression C. Bormann
Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track February 26, 2007
Expires: August 30, 2007
A ROHC Profile for RTCP (ROHC-RTCP)
draft-bormann-rohc-avt-rtcp-profile-00
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
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document specifies a ROHC (Robust Header Compression) profile
for compression of RTCP packets. The profile, called ROHC-RTCP,
provides efficient and robust compression of RTCP packets, including
frequently used RTCP features.
ROHC-RTCP is intended to be used in conjunction with ROHC profiles
for the compression of RTP headers such as RFC 3905 and ROHCv2,
making use of context replication (RFC 4164) where appropriate. In
Bormann Expires August 30, 2007 [Page 1]
Internet-Draft ROHC-RTCP February 2007
particular, ROHC-RTCP is intended to remove the need for
standardization of special-purpose variants of RTCP for applications
just because these also need to work over low-speed links.
$Id: draft-bormann-rohc-avt-rtcp-profile.xml,v 1.11 2007/02/26
13:36:24 cabo Exp $
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Creating Contexts . . . . . . . . . . . . . . . . . . . . 4
3.2. Creating State . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Using State . . . . . . . . . . . . . . . . . . . . . . . 4
4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Base Packet Formats . . . . . . . . . . . . . . . . . . . 5
4.2. CR Format . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. ROHC-RTCP Body Format . . . . . . . . . . . . . . . . . . 6
4.4. Delta Format . . . . . . . . . . . . . . . . . . . . . . . 7
5. TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Bit-level Worked Example . . . . . . . . . . . . . . 11
Appendix B. Reference Implementation . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Bormann Expires August 30, 2007 [Page 2]
Internet-Draft ROHC-RTCP February 2007
1. Introduction
When the RTP profiles were defined for the ROHC framework, it was
considered unnecessary to provide compression for RTP's often
neglected child, RTCP. RTCP is designed to use only a small fraction
of the session bandwidth; any improvements from compressing it would
only occur within this small fraction. In addition, properly
compressing RTCP raised many questions that the ROHC designers were
not ready to answer in 2000.
Meanwhile, many creative uses for RTCP have been invented
[RFC4585][I-D.ietf-avt-rtcpxr-video]. Also, with the development of
context replication [RFC4164], the separation of the ROHC framework
[I-D.ietf-rohc-rfc3095bis-framework], and the development of ROHCv2
profiles [I-D.ietf-rohc-rfc3095bis-rohcv2-profiles], the time may be
ripe to address RTCP header compression.
This document defines a ROHC profile for compression of RTCP packets.
Note that there is little that could be called an RTCP header;
instead, for the purposes of this document, the entire RTCP packet
will be considered header information.
The profile indeed is not specific to RTCP: It could theoretically be
used to compress other recurring control information transmitted via
UDP. However, where design decisions have been made based on the
characteristics of this control information, this specification
focuses on RTCP.
2. Terminology
o State Item
Sequence of bytes that is established as a common state between
compressor and decompressor using ROHC methods. Within an RTCP
compression context, there may be multiple state items, which are
indexed by a state identifier.
o State Identifier
8-bit identifier for one of the state items that is part of the
current context.
3. Protocol Operation
This section gives an overview of the operation of ROHC-RTCP.
Bormann Expires August 30, 2007 [Page 3]
Internet-Draft ROHC-RTCP February 2007
The ROHC-RTCP protocol behaves exactly like the ROHCv2 UDP protocol,
with the exceptions listed below.
3.1. Creating Contexts
A ROHC-RTCP context is created using an IR (initialization/refresh)
or a CR (context replication) packet (the latter is particularly
useful where an RTP HC context already exists for the RTP session).
For IR packets, the context created contains exactly the information
a ROHCv2 UDP context would contain, with the addition of a delta
format (see below). For CR packets, the provisions of [RFC4164] are
an integral part of this specification; again, the replicated context
is enhanced by a delta format.
When the context is created, a delta format is established for this
context; to minimize the change to the ROHCv2 headers, this is
specified in the Initial Byte of the Body Format, which replaces the
payload in all packet formats derived from ROHCv2.
3.2. Creating State
Every ROHC-RTCP packet supplies an 8-bit target state identifier.
The result of decompressing the packet is kept for future reference
under the state identifier supplied; any previous state item under
this state identifier is replaced.
Normal ROHC considerations apply about when a compressor can start to
rely on a state item to be present at the decompressor. As it is
based on ROHCv2, ROHC-RTCP supports the equivalent of unidirectional
and optimistic establishment of state items.
3.3. Using State
CO-type ROHC-RTCP packets reference an 8-bit state identifier and
supply a delta to the state item referenced as well as an 8-bit CRC.
The packet is decompressed by applying the supplied delta to the
state item referenced. If no state item exists at the decompressor
under the state identifier given or if checking the 8-bit CRC against
the decompressed packet fails, negative feedback is sent back to the
compressor (as described in the base ROHCv2 specification) and the
decompressed packet is discarded.
4. Packet Formats
This section defines the packet formats used in ROHC-RTCP.
Bormann Expires August 30, 2007 [Page 4]
Internet-Draft ROHC-RTCP February 2007
4.1. Base Packet Formats
The ROHC-RTCP base packet format is exactly like the ROHCv2 UDP
format [I-D.ietf-rohc-rfc3095bis-rohcv2-profiles] with the following
exceptions:
1. There is a CR format, defined below.
2. Instead of the payload as defined in ROHCv2-UDP, the ROHC-RTCP
body format, defined below, is carried in ROHC-RTCP packets.
4.2. CR Format
A ROHC-RTCP CR header that references a ROHCv2 UDP context replicates
it as the basis for the ROHC-RTCP context.
A ROHC-RTCP CR header that references a [RFC3095] UDP context
replicates it as the basis for the ROHC-RTCP context, converting the
[RFC3095] UDP state to a ROHCv2 UDP state by discarding mode
information and converting the SN to an MSN.
A ROHC-RTCP CR header that references a ROHCv2 RTP context or a
[RFC3095] RTP context replicates/converts it as the basis for the
ROHC-RTCP context, removing the RTP specific information (and
creating an MSN out of the RTP SN for RFC3095).
The UDP part of the static chain of the context is then modified by
the port number pair given in the ROHC-RTCP CR header; all other
fields of the IP and the UDP headers are replicated from the base
context.
Bormann Expires August 30, 2007 [Page 5]
Internet-Draft ROHC-RTCP February 2007
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 x | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| y | CRC-7 | 1 octet
+---+---+---+---+---+---+---+---+
: :
/ 1-2 octets of base CID / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
: src port : 2 octets
+---+---+---+---+---+---+---+---+
: dst port : 2 octets
+---+---+---+---+---+---+---+---+
| |
/ ROHC-RTCP Body / variable length
| |
- - - - - - - - - - - - - - - -
For this version of the specification, x == 0 and y == 0.
4.3. ROHC-RTCP Body Format
ROHC-RTCP packets contain a ROHC-RTCP Body.
For CO packets, the ROHC-RTCP Body references a state item, the
identifier of which is given by the Initial Byte. For IR and CR
packets, the referenced state item is empty (a string of zero bytes).
(TBD: For CR, switching from ROHC-UDP to ROHC-RTCP may actually make
sense; in this case it may be useful to construct a different state
item, but this would assume there is information about a payload
available in a ROHC-UDP context.)
For IR and CR packets, the Initial Byte instead specifies the Delta
Format that is to be used for this context.
For the decompressed packet, the payload is reconstructed from the
state item and the payload delta using the delta format given (for IR
and CR packets) or established for this context (for CO packets).
Bormann Expires August 30, 2007 [Page 6]
Internet-Draft ROHC-RTCP February 2007
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Initial Byte | 1 octet
+---+---+---+---+---+---+---+---+
| Target State Id | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ Payload Delta / variable length
| |
- - - - - - - - - - - - - - - -
4.4. Delta Format
This specification only defines Delta Format 0x00. Additional Delta
Formats can be defined later; see Section 7 below.
Delta Format 0x00 is a sequence of byte codes, each of which
contributes to the output and/or modifies the interpretation state in
one of the following ways::
1. Supplies additional bits to operands of subsequent byte codes.
2. Copies a specified number of bytes from the current state item to
the output and moves the current position in the current state
item forward by this number.
3. Copies a specified number of bytes from the Body itself to the
output, which are then skipped during interpretation
("arguments"). The specified number of bytes must follow the
bytecode in the Body; an underrun causes decompression failure.
4. Modifies a specified number (m) of bytes from the state item in a
specified way: the m bytes are interpreted as a MSB-first binary
number and a number n is added to that number modulo 256^m; the
resulting number is copied in MSB-first form to the output.
5. Selects a different state item as the current state item.
6. Modifies the current position in the current state item in a
specified way, e.g., skips a specified number of bytes in the
state item (this position is only relevant for the purposes of
this single instance of delta format interpretation -- the
referenced state item is not itself modified).
The interpretation of bytecodes is finished (and the resulting output
processed as a payload) when the end of the Body is reached during
interpretation.
During interpretation of the byte codes, the decompressor maintains a
current position in each referenced state item.
If a byte code cannot be meaningfully interpreted, e.g. when the
Bormann Expires August 30, 2007 [Page 7]
Internet-Draft ROHC-RTCP February 2007
bytes in the state item or the body run out prematurely, this causes
decompression failure, i.e. is treated like a CRC failure.
In the following table, some operations make use of a number n. The
number n is computed by appending the nnn bits in the current
bytecode to any accumulated prefix and adding one to the result. The
accumulated prefix starts out as an empty bitstring and is appended
to by one specific bytecode. If the concatenation of the accumulated
prefix and the nnn bits exceeds 16 bits, this is treated as
decompression failure. If there is an s bit in the bytecode, n is
negated (n = -n) if s == 1. Computing n always clears the
accumulated prefix value, if any. All bit operations are performed
most significant bit first.
Some operations make use of a number m. This number is computed from
mm as follows: m = mm+1.
Operations that use the "CSI" use the current state item, at the
current position noted for the current state item. The interpreter
maintains a separate position for the each state item that is used in
the bytecode; all positions are initialized to zero at the start of
interpreting each Body. Operations on the CSI number are modulo 256
(i.e., the CSI number is an 8-bit number). Operations on the
position in the CSI are modulo the size of the CSI in bytes.
Bytecode Arguments Semantics
000nnnnn (none) Append nnnnn to the accumulated prefix.
001nnnnn (none) Copy n bytes from CSI to output.
010nnnnn n bytes Copy n bytes from Body to output.
011mmsnn (none) Take m bytes from CSI, add n, output as m bytes.
10snnnnn (none) Add n to the CSI number, use as new CSI number.
11snnnnn (none) Change position in CSI by n, modulo size(CSI).
Note that implementations can represent n (including the accumulated
prefix) as a 16-bit value, as operations that would need more bits
are not meaningful or would even cause decompression failure.
Interpreting the change to the CSI position modulo the size of the
CSI (in bytes) means that all possible bit patterns are meaningful
(e.g., going beyond the end starts at the beginning again); to
simplify implementation of this case, accumulating large (more than
16-bit) values of n is simply disallowed (causes decompression
failure).
5. TBD
The following issues should be resolved for -01:
Bormann Expires August 30, 2007 [Page 8]
Internet-Draft ROHC-RTCP February 2007
1. Delta formats are not yet subject to negotiation.
2. Is it entirely clear from the text that state items are per
context? Is that the right decision?
3. There probably needs to be some text about static/dynamic chains
in the packet formats.
4. Delta Format 0: It should be possible to refer to the packet
under construction as if it were a state item. (Another copy-n
instruction? And a goto instruction? Or clearing out the target
state ID? State ID 0?)
5. Do we really need two CRCs for CR?
6. Appendix A needs to be written.
6. Security considerations
The security considerations of [RFC3095] apply. An additional
denial-of-service attack is possible in ROHC-RTCP by filling up the
receiver with state items. The decompressor must be careful about
range-checking the Delta Format bytecode operations. As with all
compression protocols, the expansion that is likely to occur in
decompression can be used to amplify a denial-of-service attack.
(Note that bytecode interpretation is linear or sublinear to the
length of the bytecode -- there is no attack vector of overloading
the decompressor's CPU by sending looping or otherwise malformed
bytecode.)
7. IANA Considerations
The ROHC profile identifier 0x00XX [# Editor's Note: To be replaced
before publication #] has been reserved by the IANA for the profile
defined in this document.
The ROHC-RTCP delta format identifier 0x00 has been reserved by the
IANA for the ROHC-RTCP delta format 0x00 defined in this document.
[# Editor's Note: rest of this section to be removed before
publication: #]
A ROHC profile identifier must be reserved by the IANA for the new
profile defined in this document. A suggested registration in the
"RObust Header Compression (ROHC) Profile Identifiers" name space
would then be:
Profile Usage Reference
0x0009 ROHC RTCP [RFC XXXX (this)]
Author's note: This suggestion must be updated before sending to
Bormann Expires August 30, 2007 [Page 9]
Internet-Draft ROHC-RTCP February 2007
IANA.
A new IANA registry "ROHC-RTCP delta formats" is established by this
specification under the regime "Standards Action required".
Initially, the value 0x00 is defined by this specification; further
values to be defined later need to be 8-bit numbers (values between
0x01 and 0xFF) and the pertinent standard needs to define the
semantics of the delta format to a similar effect as in Section 4.4
of this specification.
8. Contributors
The author would like to thank Joerg Ott, who noticed that this
profile was finally needed and supplied some sample data to be used
in appendix A.
Ghyslain Pelletier supplied comments that significantly shaped this
specification. Kristofer Sandlund's comments also pointed me in the
right direction.
9. Acknowledgements
A number of important concepts and ideas have been borrowed from ROHC
[RFC3095] and the ROHCv2 Internet-Drafts.
10. References
10.1. Normative References
[I-D.ietf-rohc-rfc3095bis-framework]
Jonsson, L., "The RObust Header Compression (ROHC)
Framework", draft-ietf-rohc-rfc3095bis-framework-01 (work
in progress), July 2006.
[I-D.ietf-rohc-rfc3095bis-rohcv2-profiles]
Pelletier, G. and K. Sandlund, "RObust Header Compression
Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP and
UDP Lite", draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00
(work in progress), September 2006.
[RFC4164] Pelletier, G., "RObust Header Compression (ROHC): Context
Replication for ROHC Profiles", RFC 4164, August 2005.
Bormann Expires August 30, 2007 [Page 10]
Internet-Draft ROHC-RTCP February 2007
10.2. Informative References
[I-D.ietf-avt-rtcpxr-video]
Clark, A. and A. Pendleton, "RTCP XR - IP Video Metrics
Report Blocks", draft-ietf-avt-rtcpxr-video-00 (work in
progress), December 2006.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
Appendix A. Bit-level Worked Example
This appendix gives a worked example at the bit level, showing how
various forms of RTCP packets are compressed by ROHC-RTCP.
TBD
Appendix B. Reference Implementation
This appendix gives a reference implementation of the delta format
decompressor. This appendix is intended to elucidate the normative
definition in Section 4.4
#!/usr/bin/env ruby
#
# $Id: decomp.rb,v 1.10 2007/02/25 13:27:48 cabo Exp $
#
class DecompressionFailure < StandardError
end
class ROHC_RTCP
def initialize(delta_format = 0)
@delta_format = delta_format
@state_items = Hash.new { |h, k| h[k] = '' }
end
def state_item_is(n, si)
raise "Bad state item number #{n}" unless n >= 0 && n < 256
Bormann Expires August 30, 2007 [Page 11]
Internet-Draft ROHC-RTCP February 2007
@state_items[n] = si
end
def pos
@state_pos[@csinum]
end
def pos=(np)
@state_pos[@csinum] = np
end
def csi
@state_items[@csinum]
end
def read_csi(nb)
out = csi[pos, nb]
self.pos += nb
raise DecompressionFailure unless out.size == nb
out
end
def n(op, bits, s = 0)
out = (@accum << bits) | (op & ((1 << bits) - 1))
@accum = 0
raise DecompressionFailure unless out < 0x10000 # 16 bits
out += 1
out = -out if s[bits] != 0
out
end
def decompress(bo, refsi)
raise DecompressionFailure unless @delta_format == 0
out = ''
@accum = 0
@csinum = refsi
@state_pos = Hash.new(0)
i = 0
while i < bo.size
op = bo[i]; i += 1
case op >> 5
when 0b000
@accum = (@accum << 5) | (op & ((1 << 5) - 1))
when 0b001
out << read_csi(n(op, 5))
when 0b010
nb = n(op, 5)
out << bo[i, nb]
i += nb
raise DecompressionFailure unless i <= bo.size
when 0b011
delta = n(op, 2, op)
nb = ((op >> 3) & 3) + 1
val = read_csi(nb)
Bormann Expires August 30, 2007 [Page 12]
Internet-Draft ROHC-RTCP February 2007
val = ("\0" * (4-nb)) + val
val = val.unpack('N')[0] + delta
out << [val].pack('N')[4-nb, nb]
when 0b100, 0b101
@csinum += n(op, 5, op)
@csinum &= 0xff
when 0b110, 0b111
self.pos += n(op, 5, op)
self.pos %= csi.size
end
end
out
end
end
if $0 == __FILE__ # test harness
def decode(s) # allow binary and character input
out = ''
s.scan(/\s*([01]{8}\s*)|(.)/) do |b, c|
out << (b ? b.to_i(2).chr : c)
end
out
end
r = ROHC_RTCP.new
expect = ''
DATA.each do |l|
l.chomp!
case l
when /^s (\d+) (.*)$/ # init state item
r.state_item_is($1.to_i, $2)
when /^e (.*)$/ # expect result
expect = decode($1)
when /^f$/ # expect failure
expect = nil
when /^d (\d+) (.*)$/ # decompress
refsi = $1.to_i
testdata = decode($2)
begin
out = r.decompress(testdata, refsi)
rescue DecompressionFailure
out = nil
end
puts "#{testdata.inspect} => #{out.inspect} -- " +
(expect == out ? 'OK' : "ERROR: Expecting #{expect.inspect}")
when /^\s*$/, /^#.*$/ # space, comments
else
raise "Bad test line #{l}"
end
Bormann Expires August 30, 2007 [Page 13]
Internet-Draft ROHC-RTCP February 2007
end
end
Author's Address
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28334
Germany
Phone: +49 421 218 7024
Fax: +49 421 218 7000
Email: cabo@tzi.org
Bormann Expires August 30, 2007 [Page 14]
Internet-Draft ROHC-RTCP February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Bormann Expires August 30, 2007 [Page 15]