As per Relevance of the word assumptions, we have this rfc below:
Network Working Group L-E.
Request for Comments: 3243
Category: Informational April 2002
RObust Header Compression (ROHC):
Requirements and Assumptions for 0-byte IP/UDP/RTP
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document contains requirements for the 0-byte IP/UDP/
(Internet Protocol/User Datagram Protocol/Real-Time
Protocol) header compression scheme to be developed by the
Header Compression (ROHC) Working Group. It also includes the
assumptions for the typical link layers over which 0-byte
may be implemented, and assumptions about its usage in general
1.
The goal of the Robust Header Compression (ROHC) Working Group is
develop header compression schemes that perform well over links
high error rates and long link roundtrip times. The schemes
perform well for cellular links, using technologies such as WCDMA
EDGE, and CDMA-2000. However, the schemes should also be
to other future link technologies with high loss and long
times
ROHC RTP has become a very efficient, robust and capable
scheme, able to compress the IP/UDP/RTP headers down to a total
of only one octet. This makes ROHC RTP an excellent solution
future cellular environments with new air interfaces, such as WCDMA
making even speech services possible over IP with an
lower spectrum efficiency compared to existing circuit
solutions
Jonsson Informational [Page 1]
RFC 3243 Reqs and Assumptions for 0-byte ROHC RTP April 2002
However, all-IP cellular networks will also be built with
existing air interfaces such as GSM and IS-95, which are
flexible using radio bearers optimized for specific frame
matching the speech codecs used. This means that not a single
of header can be added without switching to the next higher
packet size supported by the link, something which is obviously
costly. In the long term, this drawback should of course
eliminated with new, more flexible air interfaces, but in the
term it would be desirable if an efficiency comparable to the
switched case could also be achieved for already deployed
codecs when used over the existing air interfaces. To achieve that
it must be possible to completely eliminate the headers for
majority of the packets during normal operation, and this is
purpose of 0-byte header compression. All functionality
provided by the 1-octet header must then be provided by some
means, typically by utilizing functionality from the lower layer.
is important to remember that the purpose of 0-byte
compression is to provide optimal efficiency for
matching the link layer characteristics, not efficiency in general
As a starting point for these requirements, the well-
requirements base developed in the ROHC WG has been used. From that
the requirements have evolved through input from the 3GPP2
and from discussions within the WG
2. Assumptions for the Applicability of 0-byte RTP Header
The purpose of 0-byte header compression is to provide optimal
of certain links when the traffic pattern of a packet
completely matches the characteristics of that link. There are
assumptions that only packet streams complying with that pattern
occur, but optimal efficiency cannot of course be provided when
is not the case
To make 0-byte header compression feasible, it is assumed that
layers can provide the necessary functionality needed to replace
1-octet headers and fulfill the requirements defined in section 3.
An example is the synchronized nature of most cellular links,
can provide sequencing and timing information and make packet
detection possible
3. Requirements on 0-byte RTP Header
Since 0-byte header compression for ROHC IP/UDP/RTP is a variant
regular ROHC RTP compression [ROHC], these requirements are
as deltas to those defined in the regular RTP requirements [RTP-REQ].
For simplicity, this section is also separated into the same
subsections as the requirements in [RTP-REQ], where the first
Jonsson Informational [Page 2]
RFC 3243 Reqs and Assumptions for 0-byte ROHC RTP April 2002
with the impact of header compression on the rest of the
infrastructure, the second concerns the headers to be compressed,
the third covers efficiency and link technology related issues
3.1. Impact on Internet
The meaning of header compression is in no way changed by
introduction of 0-byte header compression. No additional impact
the Internet infrastructure is thus allowed. The "Transparency"
"Ubiquity" requirements of [RTP-REQ, section 2.1] therefore
apply to 0-byte RTP compression without any modifications
3.2. Supported Headers and Kinds of RTP
The 0-byte RTP compression scheme in general imposes the
requirements on supported headers and RTP streams as regular ROHC
[RTP-REQ, section 2.2]. However, there are some aspects
the "Genericity" and IPSEC requirements that should be noted
The "Genericity" requirement of [RTP-REQ] states that compression
headers of arbitrary RTP streams must be supported, and this is
true for the 0-byte compression scheme to the extent that it is
allowed to assume certain RTP behavior. However, as also stated
[RTP-REQ], this does not preclude optimizations for certain
types where the traffic pattern is known. For 0-byte RTP, this
that the scheme must be able to handle arbitrary RTP streams in
to fulfill the requirements of section 3.1. However, due to
typical characteristics of 0-byte compression, by requiring a
pattern that suits the link over which it is implemented to be
to compress down to 0-byte headers, it becomes optimized
applications with link-suited traffic patterns. For traffic
does not comply with the link properties, the scheme
automatically and immediately fall back to non-0-byte RTP
and must not have any impact on the packet stream
Regarding IPSEC, it should be noted that 0-byte compression cannot
achieved if parts of the original headers are encrypted or
randomly changing fields. IPSEC and 0-byte RTP header
therefore do not go well together. If IPSEC is used and prevents 0-
byte compression, the scheme must fall back to a less
compression that can handle all present header fields. Of course
this applies not only to IPSEC but to all cases where headers
be compressed down to 0-byte
Jonsson Informational [Page 3]
RFC 3243 Reqs and Assumptions for 0-byte ROHC RTP April 2002
3.3. Performance
All the performance requirements of [RTP-REQ] also apply to 0-
RTP header compression, with the following additions and exceptions
- Performance/Spectral Efficiency: For packet streams with
patterns that match the characteristics of the link over which 0-
byte header compression is implemented, the performance should
such that 0-byte header packets are generated during
operation, most of the time. 0-byte headers would then
most of the 1-octet headers used by regular ROHC RTP [ROHC].
Justification: Spectrum efficiency is a primary goal.
have shown that for certain applications and link technologies
even a single octet of header may result in a significant
in spectrum efficiency, compared to existing circuit
solutions
- Header Compression Coexistence: The scheme must fit into the
framework together with other ROHC profiles
Justification: Implementation simplicity is an important issue
the 0-byte RTP compression scheme should therefore have as much
possible in common with the regular IP/UDP/RTP profile
- Unidirectional links: It is of less importance that the 0-
header compression scheme be able to also work over
links
Justification: 0-byte header compression targets links
typically are bi-directional
4. IANA
A protocol which meets these requirements, e.g., [LLA], will
the IANA to assign various numbers. This document by itself
however, does not require any IANA involvement
5. Security
A protocol specified to meet these requirements, e.g., [LLA],
have a number of security aspects that need to be considered.
document by itself, however, does not add any security risks
Jonsson Informational [Page 4]
RFC 3243 Reqs and Assumptions for 0-byte ROHC RTP April 2002
6.
[RTP-REQ] Degermark, M., "Requirements for robust IP/UDP/RTP
compression", RFC 3096, July 2001.
[ROHC] 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
(ROHC)", RFC 3095, July 2001.
[LLA] Jonsson, L-E. and G. Pelletier, "RObust Header
(ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP",
3242, April 2002.
7. Author's
Lars-Erik
Ericsson
Box 920
SE-971 28
Phone: +46 (920) 20 21 07
Fax: +46 (920) 20 20 99
EMail: lars-erik.jonsson@ericsson.
Jonsson Informational [Page 5]
RFC 3243 Reqs and Assumptions for 0-byte ROHC RTP April 2002
8. Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Jonsson Informational [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
