doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc3096.txt b/doc/rfc/rfc3096.txt
new file mode 100644
index 0000000..c6464c8
--- /dev/null
+++ b/doc/rfc/rfc3096.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                               M. Degermark, Editor
+Request for Comments: 3096                         University of Arizona
+Category: Informational                                        July 2001
+
+
+         Requirements for robust IP/UDP/RTP header 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 (2001).  All Rights Reserved.
+
+Abstract
+
+   This document contains requirements for robust IP/UDP/RTP (Internet
+   Protocol/User Datagram Protocol/Real-Time Transport Protocol) header
+   compression to be developed by the ROHC (Robust Header Compression)
+   WG.  It is based on the ROHC charter, discussions in the WG, the 3GPP
+   document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as
+   contributions from 3G.IP.
+
+1.  Introduction
+
+   The goal of the ROHC WG is to develop header compression schemes that
+   perform well over links with high error rates and long link round
+   trip times.  The schemes must perform well for cellular links built
+   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 round trip times.
+
+   The following requirements have, more or less arbitrarily, been
+   divided into three groups.  The first group deals with requirements
+   concerning the impact of an header compression scheme on the rest of
+   the Internet infrastructure.  The second group concerns what kind of
+   headers that must be compressed efficiently.  The final group
+   concerns efficiency requirements and requirements which stem from the
+   properties of the anticipated link technologies.
+
+2. Header compression requirements
+
+   Several current standardization efforts in the cellular arena aim at
+   supporting voice over IP and other real-time services over IP, e.g.,
+   GERAN (specified by the ETSI SMG2 standards group), and UTRAN
+
+
+
+Degermark                    Informational                      [Page 1]
+
+RFC 3096            Requirements for IP/UDP/RTP ROHC           July 2001
+
+
+   (specified by the 3GPP standards organization).  It is critical for
+   these standardization efforts that a suitable header compression
+   scheme is developed before completion of the Release 2000 standards.
+   Therefore, it is imperative that the ROHC WG keeps its schedule.
+
+2.1 Impact on Internet infrastructure
+
+   1. Transparency: When a header is compressed and then decompressed,
+   the resulting header must be semantically identical to the original
+   header.  If this cannot be achieved, the packet containing the
+   erroneous header must be discarded.
+
+   Justification: The header compression process must not produce
+   headers that might cause problems for any current or future part of
+   the Internet infrastructure.
+
+   2. Ubiquity: Must not require modifications to existing IP (v4 or
+   v6), UDP, or RTP implementations.
+
+   Justification: Ease of deployment.
+
+   Note: The ROHC WG may recommend changes that would increase the
+   compression efficiency for the RTP streams emitted by
+   implementations.  However, ROHC cannot rely on such recommendations
+   being followed.
+
+2.2 Supported headers and kinds of RTP streams
+
+   1. IPv4 and IPv6: Must support both IPv4 and IPv6.
+
+   Justification: IPv4 and IPv6 will both be around during the
+   foreseeable future.
+
+   2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} should be
+   compressed efficiently.  For IPv4 these include headers of tunneled
+   packets.  For IPv6 these include headers containing the Routing
+   Header, the Binding Update Destination Option, and the Home Address
+   option.
+
+   Justification: It is very likely that Mobile IP will be used by
+   cellular devices.
+
+   3. Genericity: Must support compression of headers of arbitrary RTP
+   streams.
+
+
+
+
+
+
+
+Degermark                    Informational                      [Page 2]
+
+RFC 3096            Requirements for IP/UDP/RTP ROHC           July 2001
+
+
+   Justification: There must be a generic scheme which can compress
+   reasonably well for any payload type and traffic pattern.  This does
+   not preclude optimizations for certain media types where the traffic
+   pattern is known, e.g., for low-bandwidth voice and low-bandwidth
+   video.
+
+   Note: This applies to the RTP stream before as well as after it has
+   passed through an internet.
+
+   4. IPSEC: ROHC should be able to compress headers containing IPSEC
+   subheaders.
+
+   Note: It is of course not possible to compress the encrypted part of
+   an ESP header, nor the cryptographic data in an AH header.
+
+2.3 Efficiency
+
+   1. Performance/Spectral Efficiency: Must provide low relative
+   overhead under expected operating conditions; compression efficiency
+   should be better than for RFC 2508 under equivalent operating
+   conditions.  The error rate should only marginally increase the
+   overhead under expected operating conditions.
+
+   Justification: Spectrum efficiency is a primary goal.  RFC 2508 does
+   not perform well enough.
+
+   Note: The relative overhead is the average header overhead relative
+   to the payload.  Any auxiliary (e.g., control or feedback) channels
+   used by the scheme should be taken into account when calculating the
+   header overhead.
+
+   2. Error propagation: Error propagation due to header compression
+   should be kept at an absolute minimum.  Error propagation is defined
+   as the loss or damage of headers subsequent to headers lost or
+   damaged by the link, even if those subsequent headers are not lost or
+   damaged.
+
+   Justification: Error propagation reduces spectral efficiency and
+   reduces quality.  CRTP suffers severely from error propagation.
+
+   Note: There are at least two kinds of error propagation; loss
+   propagation, where an error causes subsequent headers to be lost, and
+   damage propagation, where an error causes subsequent headers to be
+   damaged.
+
+
+
+
+
+
+
+Degermark                    Informational                      [Page 3]
+
+RFC 3096            Requirements for IP/UDP/RTP ROHC           July 2001
+
+
+   3a. Handover loss events: There must be a way to run ROHC where loss
+   events of length 150 milliseconds are handled efficiently and where
+   loss or damage propagation is not introduced by ROHC during such
+   events.
+
+   Justification: Such loss events can be introduced by handover
+   operations in a (radio) network between compressor and decompressor.
+   Handover operations can be frequent in cellular systems.  Failure to
+   handle handover well can adversely impact spectrum efficiency and
+   quality.
+
+   3b. Handover context recreation: There must be a way to run ROHC that
+   deals well with events where the route of an RTP conversation changes
+   such that either the compressor or the decompressor of the
+   conversation is relocated to another node, where the context needs to
+   be recreated.  ROHC must not introduce erroneous headers during such
+   events, and should not introduce packet loss during such events.
+
+   Justification: Such events can be frequent in cellular systems where
+   the compressor/decompressor on the network side is close to the radio
+   base stations.
+
+   Note: In order to aid developers of context recreation schemes where
+   context is transfered to the new node, the specification shall
+   outline what parts of the context is to be transfered, as well as
+   conditions for its use.  Procedures for context recreation (and
+   discard) without such context transfer will also be provided.
+
+   4. Link delay: Must operate under all expected link delay conditions.
+
+   5. Processing delay: The scheme must not contribute significantly to
+   system delay budget.
+
+   6. Multiple links: The scheme must perform well when there are two or
+   more cellular links in the end-to-end path.
+
+   Justification: Such paths will occur.
+
+   Note: loss on previous links will cause irregularities in the RTP
+   stream reaching the compressor.  Such irregularities should only
+   marginally affect performance.
+
+   7a. Packet Misordering: The scheme should be able to compress when
+   there are misordered packets in the RTP stream reaching the
+   compressor.  No misordering is expected on the link between
+   compressor and decompressor.
+
+
+
+
+
+Degermark                    Informational                      [Page 4]
+
+RFC 3096            Requirements for IP/UDP/RTP ROHC           July 2001
+
+
+   Justification: Misordering happens regularly in the Internet.
+   However, since the Internet is engineered to run TCP reasonably well,
+   excessive misordering will not be common and need not be handled with
+   optimum efficiently.
+
+   7b. Moderate Packet Misordering: The scheme should efficiently handle
+   moderate misordering (2-3 packets) in the packet stream reaching the
+   compressor.
+
+   Note: This kind of reordering is common.
+
+   8. Unidirectional links/multicast: Must operate (possibly with less
+   efficiency) over links where there is no feedback channel or where
+   there are several receivers.
+
+   9. Configurable frame size fluctuation: It should be possible to
+   restrict the number of different frame sizes used by the scheme.
+
+   Justification: Some radio technologies support only a limited number
+   of frame sizes efficiently.
+
+   Note: Somewhat degraded performance is to be expected when such
+   restrictions are applied.
+
+   Note: This implies that a list of "good" frame sizes must be made
+   available and that ROHC may pick a suitable header format to utilize
+   available space as well as possible.
+
+   10. Delay: ROHC should not noticeably add to the end-to-end delay.
+
+   Justification: RTP packets carrying data for interactive voice or
+   video have a limited end-to-end delay budget.
+
+   Note: This requirement is intended to prevent schemes that achieve
+   robustness at the expense of delay, for example schemes that require
+   that header i+x, x>0, is received before header i can be
+   decompressed.
+
+   Note: Together with 2.3.5, this requirement implies that ROHC will
+   not noticeably add to the jitter of the RTP stream, other than what
+   is caused by variations in header size.
+
+   Note: This requirement does not prevent a queue from forming upstream
+   a bottleneck link.  Nor does it prevent a compressor from utilizing
+   information from more than one header in such a queue.
+
+   11. Residual errors: For a residual bit-error rate of at most 1e-5,
+   the ROHC scheme must not increase the error rate.
+
+
+
+Degermark                    Informational                      [Page 5]
+
+RFC 3096            Requirements for IP/UDP/RTP ROHC           July 2001
+
+
+   Justification: Some target links have a residual error rate, i.e,
+   rate of undetected errors, of this magnitude.
+
+   Note: In the presence of residual bit-errors, ROHC will need error
+   detection mechanisms to prevent damage propagation.  These mechanisms
+   will catch some residual errors, but those not caught might cause
+   damage propagation.  This requirement states that the reduction of
+   the damage rate due to the error detection mechanisms must not be
+   less than the increase in error rate due to damage propagation.
+
+3.  IANA Considerations
+
+   A protocol which meets these requirements, e.g., [ROHC], will require
+   the IANA to assign various numbers.  This document by itself,
+   however, does not require any IANA involvement.
+
+4.  Security Considerations
+
+   A protocol specified to meet these requirements, e.g., [ROHC], must
+   be able to compress packets containing IPSEC headers according to the
+   IPSEC requirement, 2.2.4.  There may be other security aspects to
+   consider in such protocols.  This document by itself, however, does
+   not add any security risks.
+
+5.  Editor's Address
+
+   Mikael Degermark
+   Dept. of Computer Science
+   University of Arizona
+   P.O. Box 210077
+   Tucson, AZ 85721-0077
+   USA
+
+   Phone: (May-July): +46 70 833-8933
+   Phone: +1 520 621-3489
+   Fax:   +1 520 621-4246
+   EMail: micke@cs.arizona.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degermark                    Informational                      [Page 6]
+
+RFC 3096            Requirements for IP/UDP/RTP ROHC           July 2001
+
+
+6.  References
+
+   [TR]      3GPP TR 23.922 version 1.0.0, 3rd Generation partnership
+             Project; Technical Specification Group Services and Systems
+             Aspects; Architecture for an All IP network.
+
+   [TS]      TS 22.101 version 3.6.0: Service Principles
+
+   [RFC768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+             August 1980.
+
+   [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
+             1981.
+
+   [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
+             Serial Links", RFC 1144, February 1990.
+
+   [CRTP]    Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers
+             for Low-Speed Serial Links", RFC 2508, February 1999.
+
+   [OHC]    Bormann, C., Editor, "Robust Header Compression (ROHC)", RFC
+             3095, June 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degermark                    Informational                      [Page 7]
+
+RFC 3096            Requirements for IP/UDP/RTP ROHC           July 2001
+
+
+7.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Degermark                    Informational                      [Page 8]
+