doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc4163.txt b/doc/rfc/rfc4163.txt
new file mode 100644
index 0000000..2803b61
--- /dev/null
+++ b/doc/rfc/rfc4163.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                       L-E. Jonsson
+Request for Comments: 4163                                      Ericsson
+Category: Informational                                      August 2005
+
+
+                   RObust Header Compression (ROHC):
+               Requirements on TCP/IP 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 (2005).
+
+Abstract
+
+   This document contains requirements on the TCP/IP header compression
+   scheme (profile) to be developed by the RObust Header Compression
+   (ROHC) Working Group.  The document discusses the scope of TCP
+   compression, performance considerations, assumptions about the
+   surrounding environment, as well as Intellectual Property Rights
+   concerns.  The structure of this document is inherited from RFC 3096,
+   which defines IP/UDP/RTP requirements for ROHC.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Header Compression Requirements .................................2
+      2.1. Impact on Internet Infrastructure ..........................2
+      2.2. Supported Headers and Kinds of TCP Streams .................3
+      2.3. Performance Issues .........................................4
+      2.4. Requirements Related to Link Layer Characteristics .........6
+      2.5. Intellectual Property Rights (IPR) .........................7
+   3. Security Consideration ..........................................7
+   4. IANA Considerations .............................................7
+   5. Acknowledgements ................................................7
+   6. Informative References ..........................................7
+
+
+
+
+
+
+
+
+
+
+Jonsson                      Informational                      [Page 1]
+
+RFC 4163              Requirements on ROHC TCP/IP            August 2005
+
+
+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 roundtrip
+   times.  The schemes must perform well for cellular links that use
+   technologies such as Wideband Code Division Multiple Access (W-CDMA),
+   Enhanced Data rates for GSM Evolution (EDGE), and CDMA2000.  However,
+   the schemes should also be applicable to other link technologies with
+   high loss and long roundtrip times.
+
+   The main objective for ROHC has been robust compression of IP/UDP/RTP
+   [5], but the WG is also chartered to develop new header compression
+   solutions for IP/TCP [1], [2].  Because TCP traffic, in contrast to
+   RTP, has usually been sent over reliable links, existing schemes for
+   TCP, [3] and [4], have not experienced the same robustness problems
+   as RTP compression.  However, there are still many scenarios where
+   TCP header compression will be implemented over less reliable links
+   [11], [12], making robustness an important objective for the new TCP
+   compression scheme.  Other, equally important, objectives for ROHC
+   TCP compression are: improved compression efficiency, enhanced
+   capabilities for compression of header fields including TCP options,
+   and finally incorporation of TCP compression into the ROHC framework
+   [6].
+
+2.  Header Compression Requirements
+
+   The following requirements have, more or less arbitrarily, been
+   divided into five groups.  The first group deals with requirements
+   concerning the impact of a header compression scheme on the rest of
+   the Internet infrastructure.  The second group defines what kind of
+   headers must be compressed efficiently.  The third and fourth groups
+   concern performance requirements and capability requirements that
+   stem from the properties of link technologies where ROHC TCP is
+   expected to be used.  Finally, the fifth section discusses
+   Intellectual Property Rights related to ROHC TCP compression.
+
+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.
+
+
+
+
+
+Jonsson                      Informational                      [Page 2]
+
+RFC 4163              Requirements on ROHC TCP/IP            August 2005
+
+
+       Note: The ROHC WG has not found a case where "semantically
+       identical" is not the same as "bitwise identical".
+
+   2.  Ubiquity: Must not require modifications to existing IP (v4 or
+       v6) or TCP implementations.
+
+       Justification: Ease of deployment.
+
+       Note: The ROHC WG may recommend changes that would increase the
+       compression efficiency for the TCP streams emitted by
+       implementations.  However, ROHC cannot assume such
+       recommendations will be followed.
+
+       Note: Several TCP variants are currently in use on the Internet.
+       This requirement implies that the header compression scheme must
+       work efficiently and correctly for all expected TCP variants.
+
+2.2.  Supported Headers and Kinds of TCP Streams
+
+   1.  IPv4 and IPv6: Must support both IPv4 and IPv6.  This means that
+       all expected changes in the IP header fields must be handled by
+       the compression scheme, and commonly changing fields should be
+       compressed efficiently.  Compression must still be possible when
+       IPv6 Extensions are present in the header.  When designing the
+       compression scheme, the usage of Explicit Congestion Notification
+       (ECN) [10] should be considered as a common behavior.  Therefore,
+       the scheme must also compress efficiently in the case when the
+       ECN bits are used.
+
+       Justification: IPv4 and IPv6 will both be around for the
+       foreseeable future, and Options/Extensions are expected to be
+       more commonly used.  ECN is expected to have a breakthrough and
+       be widely deployed, especially in combination with TCP.
+
+   2.  Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be
+       supported and should be compressed efficiently.  For IPv4 these
+       include headers of tunneled packets.  For IPv6 they include
+       headers containing the Routing Header and the Home Address
+       Option.
+
+       Justification: It is very likely that Mobile IP will be used by
+       cellular devices.
+
+   3.  Generality: Must handle all headers from arbitrary TCP streams.
+
+       Justification: There must be a generic scheme that can compress
+       reasonably well for any TCP traffic pattern.  This does not
+       preclude optimizations for certain traffic patterns.
+
+
+
+Jonsson                      Informational                      [Page 3]
+
+RFC 4163              Requirements on ROHC TCP/IP            August 2005
+
+
+   4.  IPSEC: The scheme should be able to compress headers containing
+       IPSEC subheaders where the NULL encryption algorithm is used.
+
+       Justification: IPSEC is expected to be used to provide necessary
+       end-to-end security.
+
+       Note: It is not possible to compress the encrypted part of an ESP
+       header, nor the cryptographic data in an AH header.
+
+   5.  TCP: All fields supported by [4] should be handled with efficient
+       compression, as should be the cases when the SYN, FIN or TCP ECN
+       [10] bits are set.
+
+       Justification: These bits are expected to be commonly used.
+
+   6.  TCP options: The scheme must support compression of packets with
+       any TCP option present, even if the option itself is not
+       compressed.  Further, for some commonly used options the scheme
+       should also provide compression mechanisms for the options.
+
+       Justification: Because various TCP options are commonly used,
+       applicability of the compression scheme would be significantly
+       reduced if packets with options could not be compressed.
+
+       Note: Options that should be compressed are:
+                     - Selective Acknowledgement (SACK), [8], [9]
+                     - Timestamp, [7]
+
+2.3.  Performance Issues
+
+   1.  Performance/Spectral Efficiency: The scheme must provide low
+       relative overhead under expected operating conditions;
+       compression efficiency should be better than for RFC 2507 [4]
+       under equivalent operating conditions.
+
+       Justification: Spectrum efficiency is a primary goal.
+
+       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.  Losses between compressor and decompressor: The scheme should
+       make sure losses between compressor and decompressor do not
+       result in losses of subsequent packets, or cause damage to the
+       context that results in incorrect decompression of subsequent
+       packet headers.
+
+
+
+
+Jonsson                      Informational                      [Page 4]
+
+RFC 4163              Requirements on ROHC TCP/IP            August 2005
+
+
+       Justification: Even though link layer retransmission in most
+       cases is expected to almost eliminate losses between compressor
+       and decompressor, there are still many scenarios where TCP header
+       compression will be implemented over less reliable links [11],
+       [12].  In such cases, loss propagation due to header compression
+       could affect certain TCP mechanisms that are capable of handling
+       some losses; loss propagation could also have a negative impact
+       on the performance of TCP loss recovery.
+
+   3.  Residual errors in compressed headers: Residual errors in
+       compressed headers may result in delivery of incorrectly
+       decompressed headers not only for the damaged packet itself, but
+       also for subsequent packets, because errors may be saved in the
+       context state.  For TCP, the compression scheme is not required
+       to implement explicit mechanisms for residual error detection,
+       but the compression scheme must not affect TCP's end-to-end
+       mechanisms for error detection.
+
+       Justification: For links carrying TCP traffic, the residual error
+       rate is expected to be insignificant.  However, residual errors
+       may still occur, especially in the end-to-end path.  Therefore,
+       it is crucial that TCP is not prevented from handling these.
+
+       Note: This requirement implies that the TCP checksum must be
+       carried unmodified in all compressed headers.
+
+       Note: The error detection mechanism in TCP may be able to detect
+       residual bit errors, but the mechanism is not designed for this
+       purpose, and might actually provide rather weak protection.
+       Therefore, although it is not a requirement of the compression
+       scheme, it should be possible for the decompressor to detect
+       residual errors and discard such packets.
+
+   4.  Short-lived TCP transfers: The scheme should provide mechanisms
+       for efficient compression of short-lived TCP transfers,
+       minimizing the size of context initiation headers.
+
+       Justification: Many TCP transfers are short-lived.  This may lead
+       to a low gain for header compression schemes that, for each new
+       packet stream, requires full headers to be sent initially and
+       allows small compressed headers only after the initialization
+       phase.
+
+       Note: This requirement implies that mechanisms for building new
+       contexts that are based on information from previous contexts or
+       for concurrent packet streams to share context information should
+       be considered.
+
+
+
+
+Jonsson                      Informational                      [Page 5]
+
+RFC 4163              Requirements on ROHC TCP/IP            August 2005
+
+
+   5a. Moderate Packet Misordering: The scheme should efficiently handle
+       moderate misordering (2-3 packets) in the packet stream reaching
+       the compressor.
+
+       Justification: This kind of misordering is common.
+
+   5b. Packet Misordering: The scheme must be able to correctly handle
+       packet misordering and preferably compress when misordered
+       packets are in the TCP stream reaching the compressor.
+
+       Justification: Misordering happens regularly in the Internet.
+       However, because the Internet is engineered to run TCP reasonably
+       well, excessive misordering will not be common and need not be
+       handled with optimum efficiency.
+
+   6.  Processing delay: The scheme should not contribute significantly
+       to the system delay budget.
+
+2.4.  Requirements Related to Link Layer Characteristics
+
+   1.  Unidirectional links: Must be possible to implement (possibly
+       with less efficiency) without explicit feedback messages from
+       decompressor to compressor.
+
+       Justification: There are links that do not provide a feedback
+       channel or where feedback is not desirable for other reasons.
+
+   2.  Link delay: Must operate under all expected link delay
+       conditions.
+
+   3.  Header compression coexistence: The scheme must fit into the ROHC
+       framework together with other ROHC profiles (e.g., [6]).
+
+   4.  Note on misordering between compressor and decompressor:
+
+       When compression is applied over tunnels, misordering often
+       cannot be completely avoided.  The header compression scheme
+       should not prohibit misordering between compressor and
+       decompressor, as it would therefore not be applicable in many
+       tunneling scenarios.  However, in the case of tunneling, it is
+       usually possible to get misordering indications.  Therefore, the
+       compression scheme does not have to support detection of
+       misordering, but can assume that such information is available
+       from lower layers when misordering occurs.
+
+
+
+
+
+
+
+Jonsson                      Informational                      [Page 6]
+
+RFC 4163              Requirements on ROHC TCP/IP            August 2005
+
+
+2.5.  Intellectual Property Rights (IPR)
+
+   The ROHC WG must spend effort to achieve a high degree of confidence
+   that there are no known IPR claims that cover the final compression
+   solution for TCP.
+
+   Justification: Currently there is no TCP header compression scheme
+   available that can efficiently compress the packet headers of modern
+   TCP, e.g., with SACK, ECN, etc.  ROHC is expected to fill this gap by
+   providing a ROHC TCP scheme that is applicable in the wide area
+   Internet, not only over error-prone radio links.  It must thus
+   attempt to be as future-proof as possible, and only unencumbered
+   solutions, or solutions where the terms of any IPR are such that
+   there is no hindrance on implementation and deployment, will be
+   acceptable to the Internet at large.
+
+3.  Security Consideration
+
+   A protocol specified to meet these requirements 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.
+
+4.  IANA Considerations
+
+   A protocol that meets these requirements will require the IANA to
+   assign various numbers.  This document by itself, however, does not
+   require any IANA involvement.
+
+5.  Acknowledgements
+
+   This document has evolved through fruitful discussions with and input
+   from Gorry Fairhurst, Carsten Bormann, Mikael Degermark, Mark West,
+   Jan Kullander, Qian Zhang, Richard Price, and Aaron Falk.  The
+   document quality was significantly improved thanks to Peter Eriksson,
+   who made a thorough linguistic review.
+
+   Last, but not least, Ghyslain Pelletier and Kristofer Sandlund served
+   as committed working group document reviewers.
+
+6.  Informative References
+
+   [1]  Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
+
+   [2]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
+        September 1981.
+
+
+
+
+Jonsson                      Informational                      [Page 7]
+
+RFC 4163              Requirements on ROHC TCP/IP            August 2005
+
+
+   [3]  Jacobson, V., "Compressing TCP/IP headers for low-speed serial
+        links", RFC 1144, February 1990.
+
+   [4]  Degermark, M., Nordgren, B., and S. Pink, "IP Header
+        Compression", RFC 2507, February 1999.
+
+   [5]  Degermark, M., "Requirements for robust IP/UDP/RTP header
+        compression", RFC 3096, July 2001.
+
+   [6]  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.
+
+   [7]  Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for
+        High Performance", RFC 1323, May 1992.
+
+   [8]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
+        Selective Acknowledgement Options", RFC 2018, October 1996.
+
+   [9]  Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
+        Extension to the Selective Acknowledgement (SACK) Option for
+        TCP", RFC 2883, July 2000.
+
+   [10] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
+        Explicit Congestion Notification (ECN) to IP", RFC 3168,
+        September 2001.
+
+   [11] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-
+        end Performance Implications of Slow Links", BCP 48, RFC 3150,
+        July 2001.
+
+   [12] Fairhurst, G. and L. Wood, "Advice to link designers on link
+        Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
+
+Author's Address
+
+   Lars-Erik Jonsson
+   Ericsson AB
+   Box 920
+   SE-971 28 Lulea
+   Sweden
+
+   Phone: +46 8 404 29 61
+   Fax:   +46 920 996 21
+   EMail: lars-erik.jonsson@ericsson.com
+
+
+
+Jonsson                      Informational                      [Page 8]
+
+RFC 4163              Requirements on ROHC TCP/IP            August 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Jonsson                      Informational                      [Page 9]
+