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