doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc3322.txt b/doc/rfc/rfc3322.txt
new file mode 100644
index 0000000..665c703
--- /dev/null
+++ b/doc/rfc/rfc3322.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                           H. Hannu
+Request for Comments: 3322                                      Ericsson
+Category: Informational                                     January 2003
+
+
+       Signaling Compression (SigComp) Requirements & Assumptions
+
+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 (2003).  All Rights Reserved.
+
+Abstract
+
+   The purpose of this document is to outline requirements and
+   motivations for the development of a scheme for compression and
+   decompression of messages from signaling protocols.  In wireless
+   environments and especially in cellular systems, e.g., GSM (Global
+   System for Mobile communications) and UMTS (Universal Mobile
+   Telecommunications System), there is a need to maximize the transport
+   efficiency for data over the radio interface.  With the introduction
+   of SIP/SDP (Session Initiation Protocol/Session Description Protocol)
+   to cellular devices, compression of the signaling messages should be
+   considered in order to improve both service availability and quality,
+   mainly by reducing the user idle time, e.g., at call setup.
+
+Table of Contents
+
+   1.  Introduction....................................................2
+   1.1.  Protocol Characteristics......................................2
+   1.2.  Cellular System Radio Characteristics.........................3
+   2.  Motivation for Signaling Reduction..............................4
+   2.1.  Estimation of Call Setup Delay Using SIP/SDP..................4
+   3.  Alternatives for Signaling Reduction............................6
+   4.  Assumptions.....................................................7
+   5.  Requirements....................................................8
+   5.1.  General Requirements..........................................8
+   5.2.  Performance Requirements......................................9
+   6. Security Considerations.........................................11
+   7. IANA Considerations.............................................11
+   8. References......................................................11
+   9. Author's Address................................................12
+   10. Full Copyright Statement.......................................13
+
+
+
+Hannu                        Informational                      [Page 1]
+
+RFC 3322           SigComp Requirements & Assumptions       January 2003
+
+
+1. Introduction
+
+   In wireless environments, and especially in cellular systems, such as
+   GSM/GPRS, there is a need to maximize the transport efficiency of
+   data over the radio interface.  The radio spectrum is rather
+   expensive and must be carefully used.  Therefore, the cellular
+   systems must support a sufficient number of users to make them
+   economically feasible.  Thus, there is a limitation in the per user
+   bandwidth.
+
+   Compressing the headers of the network and transport protocols used
+   for carrying user data is one way to make more efficient use of the
+   scarce radio resources [ROHC].  However, compression of the messages
+   from signaling protocols, such as SIP/SDP, should also be considered
+   to increase the radio resource usage even further.  Compression will
+   also improve the service quality by reducing the user idle time at
+   e.g., call setup.  When IP is used end-to-end, new applications, such
+   as streaming, will be brought to tiny end-hosts, such as cellular
+   devices.  This will introduce additional traffic in cellular systems.
+   Compression of signaling messages, such as RTSP [RTSP], should also
+   be considered to improve both the service availability and quality.
+
+   New services with their corresponding signaling protocols make it
+   reasonable to consider a scheme that is generic.  The scheme should
+   be generic in the meaning that the scheme can efficiently be applied
+   to arbitrary protocols with certain characteristics, such as the
+   ASCII based protocols SIP and RTSP.
+
+1.1. Protocol Characteristics
+
+   The following application signaling protocols are examples of
+   protocols that are expected to be commonly used in the future.  Some
+   of their characteristics are described below.
+
+1.1.1 SIP
+
+   The Session Initiation Protocol [SIP] is an application layer
+   protocol for establishing, modifying and terminating multimedia
+   sessions or calls.  These sessions include Internet multimedia
+   conferences, Internet telephony and similar applications.  SIP can be
+   used over either TCP [TCP] or UDP [UDP].  SIP is a text based
+   protocol, using ISO 10646 in UTF-8 encoding.
+
+
+
+
+
+
+
+
+
+Hannu                        Informational                      [Page 2]
+
+RFC 3322           SigComp Requirements & Assumptions       January 2003
+
+
+1.1.2 SDP
+
+   The Session Description Protocol [SDP] is used to advertise
+   multimedia conferences and communicate conference addresses and
+   conference tool specific information.  It is also used for general
+   real-time multimedia session description purposes.  SDP is carried in
+   the message body of SIP and RTSP messages.  SDP is text based using
+   the ISO 10646 character set in UTF-8 encoding.
+
+1.1.3 RTSP
+
+   The Real Time Streaming Protocol [RTSP] is an application level
+   protocol for controlling the delivery of data with real-time
+   properties, such as audio and video.  RTSP may use UDP or TCP (or
+   other) as a transport protocol.  RTSP is text based using the ISO
+   10646 character set in UTF-8 encoding.
+
+1.1.4 Protocol Similarities
+
+   The above protocols have many similarities.  These similarities will
+   have implications on solutions to the problems they create in
+   conjunction with e.g., cellular radio access.  The similarities
+   include:
+
+   -  Requests and reply characteristics.  When a sender sends a
+      request, it stays idle until it has received a response.  Hence,
+      it typically takes a number of round trip times to conclude e.g.,
+      a SIP session.
+
+   -  They are ASCII based.
+
+   -  They are generous in size in order to provide the necessary
+      information to the session participants.
+
+   -  SIP and RTSP share many common header field names, methods and
+      status codes.  The traffic patterns are also similar.  The
+      signaling is carried out primarily under the set up phase.  For
+      SIP, this means that the majority of the signaling is carried out
+      to set up a phone call or multimedia session.  For RTSP, the
+      majority of the signaling is done before the transmission of
+      application data.
+
+1.2. Cellular System Radio Characteristics
+
+   Partly to enable high utilization of cellular systems, and partly due
+   to the unreliable nature of the radio media, cellular links have
+   characteristics that differ somewhat from a typical fixed link, e.g.,
+
+
+
+
+Hannu                        Informational                      [Page 3]
+
+RFC 3322           SigComp Requirements & Assumptions       January 2003
+
+
+   copper or fiber.  The most important characteristics are the lossy
+   behavior of cellular links and the large round trip times.
+
+   The quality in a radio system typically changes from one radio frame
+   to another due to fading in the radio channel.  Due to the nature of
+   the radio media and interference from other radio users, the average
+   bit error rate (BER) can be 10e-3 with a variation roughly between
+   10e-2 to 10e-4.  To be able to use the radio media with its error
+   characteristics, methods such as forward error correction (FEC) and
+   interleaving are used.  If these methods were not used, the BER of a
+   cellular radio channel would be around 10 %.  Thus, radio links are,
+   by nature, error prone.  The final packet loss rate may be further
+   reduced by applying low level retransmissions (ARQ) over the radio
+   channel; however, this trades decreased packet loss rate for a larger
+   delay.  By applying methods to decrease BER, the system delay is
+   increased.  In some cellular systems, the algorithmic channel round
+   trip delay is in the order of 80 ms. Other sources of delays are
+   DSP-processing, node-internal delay and transmission.  A general
+   value for the RTT is difficult to state, but it might be as high as
+   200 ms.
+
+   For cellular systems it is of vital importance to have a sufficient
+   number of users per cell; otherwise the system cost would prohibit
+   deployment.  It is crucial to use the existing bandwidth carefully;
+   hence the average user bit rate is typically relatively low compared
+   to the average user bit rate in wired line systems.  This is
+   especially important for mass market services like voice.
+
+2. Motivation for Signaling Reduction
+
+   The need for solving the problems caused by the signaling protocol
+   messages is exemplified in this chapter by looking at a typical
+   SIP/SDP Call Setup sequence over a narrow band channel.
+
+2.1 Estimation of Call Setup Delay Using SIP/SDP
+
+   Figure 2.1 shows an example of SIP signaling between two termination
+   points with a wireless link between, and the resulting delay under
+   certain system assumptions.
+
+   It should be noted that the used figures represent a very narrow band
+   link.  E.g., a WCDMA system can provide maximum bit rates up to 2
+   Mbits/s in ideal conditions, but that means one single user would
+   consume all radio resources in the cell.  For a mass market service
+   such as voice, it is always crucial to reduce the bandwidth
+   requirements for each user.
+
+
+
+
+
+Hannu                        Informational                      [Page 4]
+
+RFC 3322           SigComp Requirements & Assumptions       January 2003
+
+
+   Client                  Network-Proxy     Size [bytes]   Time [ms]
+     |                            |
+     |---------- INVITE --------->|               620      517+70=587
+     |                            |
+     |<-- 183 Session progress ---|               500      417+70=487
+     |                            |
+     |---------- PRACK ---------->|               250      208+70=278
+     |                            |
+     |<----- 200 OK (PRACK) ------|               300      250+70=320
+     :                            :
+     |<...... RSVP and SM .......>|
+     :                            :
+     |---------- COMET ---------->|               620      517+70=587
+     |                            |
+     |<----- 200 OK (COMET) ------|               450
+     |                            |                +
+     |<------ 180 Ringing --------|               230      567+70=637
+     |                            |
+     |---------- PRACK ---------->|               250      208+70=278
+     |                            |
+     |<----- 200 OK (PRACK) ------|               300
+     |                            |                +
+     |<--------- 200 OK ----------|               450      625+70=695
+     |                            |
+     |----------- ACK ----------->|               230      192+70=262
+
+   Figure 2.1. SIP signaling delays assuming a link speed of 9600
+   bits/sec and a RTT of 140 ms.
+
+   The one way delay is calculated according to the following equation:
+
+   OneWayDelay =
+        MessageSize[bits]/LinkSpeed[bits/sec] + RTT[sec]/2       (eq. 1)
+
+   The following values have been used:
+
+   RTT/2:                     70 ms
+   LinkSpeed                  9.6 kbps
+
+   The delay formula is based on an approximation of a WCDMA radio
+   access method for speech services.  The approximation is rather
+   crude.  For instance, delays caused by possible retransmissions due
+   to errors are ignored. Further, these calculations also assume that
+   there is only one cellular link in the path and take delays in an
+   eventual intermediate IP-network into account.  Even if this
+   approximation is crude, it is still sufficient to provide
+   representative numbers and enable comparisons.  The message size
+   given in Figure 2.1, is typical for a SIP/SDP call setup sequence.
+
+
+
+Hannu                        Informational                      [Page 5]
+
+RFC 3322           SigComp Requirements & Assumptions       January 2003
+
+
+2.1.1 Delay Results
+
+   Applying equation 1 to each SIP/SDP message shown in the example of
+   Figure 2.1 gives a total delay of 4131 ms from the first SIP/SDP
+   message to the last.  The RSVP and Session Management (Radio Bearer
+   setup), displayed in Figure 2.1, will add approximately 1.5 seconds
+   to the total delay, using equation 1.  However, there will also be
+   RSVP and SM signaling prior to the SIP INVITE message to establish
+   the radio bearer, which would add approximately another 1.5 seconds.
+
+   In [TSG] there is a comparison between GERAN call setup using SIP and
+   ordinary GSM call setup.  For a typical GSM call setup, the time is
+   about 3.6 seconds, and for the case when using SIP, the call setup is
+   approximately 7.9 seconds.
+
+   Another situation that would benefit from reduced signaling is
+   carrying signaling messages over narrow bandwidth links in mid-call.
+   For GERAN, this will result in frame stealing with degraded speech
+   quality as a result.
+
+   Thus, solutions are needed to reduce the signaling delay and the
+   required bandwidth when considering both system bandwidth
+   requirements and service setup delays.
+
+3. Alternatives for Signaling Reduction
+
+   More or less attractive solutions to the previously mentioned
+   problems can be outlined:
+
+   -  Increase the user bit rate
+
+      An increase of the bit rate per user will decrease the number of
+      users per cell.  There exist systems (for example WCDMA) which can
+      provide high bit rates and even variable rates, e.g., at the setup
+      of new sessions.  However, there are also systems, e.g., GSM/EDGE,
+      where it is not possible to reach these high bit rates in all
+      situations.  At the cell borders, for example, the signal strength
+      to noise ratio will be lower and result in a lower bit rate.  In
+      general, an unnecessary increase of the bit rate should be avoided
+      due to the higher system cost introduced and the possibility of
+      denial of service.  The latter could, for example, be caused by
+      lack of enough bandwidth to support the sending of the large setup
+      message within a required time period, which is set for QoS
+      reasons.
+
+
+
+
+
+
+
+Hannu                        Informational                      [Page 6]
+
+RFC 3322           SigComp Requirements & Assumptions       January 2003
+
+
+   -  Decrease the RTT of the cellular link
+
+      Decreasing the RTT would require substantial system changes and is
+      thus not feasible in the short term.  Further, the RTT-delay
+      caused by interleaving and FEC will always have to be present
+      regardless of which system is used.  Otherwise the BER will be too
+      high for the received data to be useful, or alternatively trigger
+      retransmissions giving an average total delay of the same or
+      higher magnitude.
+
+   -  Optimize message sequence for the protocols
+
+      If the request/response pattern could be eased up, then "keeping
+      the pipe full" could be a way forward.  Thus, instead of following
+      the message sequence described in Figure 4.2, more than one
+      message would be sent in a row, even though no response has been
+      received.  However, this would entail protocol changes and may be
+      difficult at the current date.
+
+   -  Protocol stripping
+
+      Removing fields from a message would decrease the size of the
+      messages to some extent.  However, this would cause the loss of
+      transparency and thus violate the End-to-End principle and is thus
+      not desirable.
+
+   -  Compression
+
+      By compressing messages, the impact of the mentioned problems
+      could be decreased.  Compared to the other possible solutions
+      compression can be made, and must be, transparent to the end-user
+      application.  Thus, compression seems to be the most attractive
+      way forward.
+
+4. Assumptions
+
+   -  Negotiation
+
+      How the usage of compression is negotiated is out of the scope for
+      this compression solution and must be handled by e.g., the
+      protocol the messages of which are to be compressed.
+
+   -  Reliable transport
+
+      With reliable transport, it is assumed that a transport recovered
+      from data that is damaged, lost, duplicated, or delivered out of
+      order, e.g., [TCP].
+
+
+
+
+Hannu                        Informational                      [Page 7]
+
+RFC 3322           SigComp Requirements & Assumptions       January 2003
+
+
+   -  Unreliable transport
+
+      With unreliable transport, it is assumed that a transport does not
+      have the capabilities of a reliable transport, e.g., [UDP].
+
+5. Requirements
+
+   This chapter states requirements for a signaling compression scheme
+   to be developed in the IETF ROHC WG.
+
+   The requirements are divided into two parts.  Section 5.1 sets
+   general requirements concerning the Internet infrastructure, while
+   Section 5.2 sets requirements on the scheme itself.
+
+5.1. General Requirements
+
+   1.  Transparency: When a message is compressed and then decompressed,
+       the result must be bitwise identical to the original message.
+
+       Justification: This is to ensure that the compression scheme will
+       not cause problems for any current or future part of the Internet
+       infrastructure.
+
+       Note: See also requirement 9.
+
+   2.  Header compression coexistence: The compression scheme must be
+       able to coexist with header compression, especially the ROHC
+       protocol.
+
+       Justification: Signaling compression is used because there is a
+       need to conserve bandwidth usage.  In that case, header
+       compression will likely be needed too.
+
+   3a. Compatibility: The compression scheme must be constructed in such
+       a way that it allows the above protocols' mechanisms to negotiate
+       whether the compression scheme is to be applied or not.
+
+       Justification: Two entities must be able to communicate
+       regardless if the signaling compression scheme is implemented at
+       both entities or not.
+
+   3b. Ubiquity: Modifications to the protocols generating the messages
+       that are to be compressed, must not be required for the
+       compression scheme to work.
+
+       Justification: This will simplify deployment of the compression
+       scheme.
+
+
+
+
+Hannu                        Informational                      [Page 8]
+
+RFC 3322           SigComp Requirements & Assumptions       January 2003
+
+
+       Note: This does not preclude making extensions, which are related
+       to the signaling compression scheme, to existing protocols, as
+       long as the extensions are backward compatible.
+
+   4.  Generality: Compression of arbitrary message streams must be
+       supported.  The signaling compression scheme must not be limited
+       to certain protocols, traffic patterns or sessions.  It must not
+       assume any message pattern to be able to perform compression.
+
+       Justification: There might be a future need for compression of
+       different ASCII based signaling protocols.  This requirement will
+       minimize future work.
+
+       Note: This does not preclude optimization for certain streams.
+
+   5.  Unidirectional routes: The compression scheme must be able to
+       operate on unidirectional routes, i.e., without explicit feedback
+       messages from the decompressor.
+
+       Note: Implementations on unidirectional routes might possibly
+       show a degraded performance compared to implementations on bi-
+       directional routes.
+
+   6.  Transport: The solution must work for both unreliable and
+       reliable underlying transport protocols, e.g., UDP and TCP.
+
+       Justification: The protocols, which generate the messages that
+       are to be compressed, may use either an unreliable or a reliable
+       underlying transport.
+
+       Note: This should not be taken to mean that the same set of
+       solution mechanisms must be used over both unreliable and
+       reliable transport.
+
+5.2. Performance Requirements
+
+   The performance requirements in this section and the following
+   subsections are valid for both unreliable and reliable underlying
+   transport.
+
+   7.  Scalability: The scheme must be flexible to accommodate a range
+       of compressors/decompressors with varying memory and processor
+       capabilities.
+
+       Justification: A primary target for the signaling compression
+       scheme is cellular systems, where the mobile terminals have
+       varying capabilities.
+
+
+
+
+Hannu                        Informational                      [Page 9]
+
+RFC 3322           SigComp Requirements & Assumptions       January 2003
+
+
+   8.  Delay: The signaling compression must not noticeably add to the
+       delay experienced by the end user.
+
+       Justification: Reduction of the user experienced delay is the
+       main purpose of signaling compression.
+
+       Note: This requirement is intended to prevent schemes that
+       achieve compression efficiency at the expense of delay, i.e.,
+       queuing of messages to improve the compression efficiency should
+       be avoided.
+
+   The following requirements are grouped into two subsections, a
+   robustness section and a compression efficiency section.
+
+5.2.1. Robustness
+
+   The requirements in this section concern the issue of when compressed
+   messages should be correctly decompressed.  The transparency
+   requirement (first requirement) covers the issue with faulty
+   decompressed messages.
+
+   9.  Residual errors: The compression scheme must be resilient against
+       errors undetected by lower layers, i.e., the probability of
+       incorrect decompression caused by such undetected errors must be
+       low.
+
+       Justification: A primary target for the signaling compression
+       scheme is cellular systems, where undetected errors might be
+       introduced on the cellular link.
+
+   10. Error propagation: Propagation of errors due to signaling
+       compression should be kept at an absolute minimum.  Loss or
+       damage to a single or several messages, between compressor and
+       decompressor should not prevent compression and decompression of
+       later messages.
+
+       Justification: Error propagation reduces resource utilization and
+       quality.
+
+   11. Delay: The compression scheme must be able to perform compression
+       and decompression of messages under all expected delay
+       conditions.
+
+
+
+
+
+
+
+
+
+Hannu                        Informational                     [Page 10]
+
+RFC 3322           SigComp Requirements & Assumptions       January 2003
+
+
+5.2.2. Compression Efficiency
+
+   This section states requirements related to compression efficiency.
+
+   12. Message loss: Loss or damage to a single or several messages, on
+       the link between compressor and decompressor, should not prevent
+       the usage of later messages in the compression and decompression
+       process.
+
+   13. Moderate message misordering: The scheme should allow for the
+       correct decompression of messages, that have been moderately
+       misordered (1-2 messages) between compressor and decompressor.
+       The scheme should not prevent the usage of later messages in the
+       compression and decompression process.
+
+       Justification: Misordering is frequent on the Internet, and this
+       kind of misordering is common.
+
+6. Security Considerations
+
+   A protocol specified to meet these requirements must be able to cope
+   with packets that have undergone security measures, such as
+   encryption, without adding any security risks.  This document, by
+   itself however, does not add any security risks.
+
+7. IANA Considerations
+
+   A protocol which meets these requirements may require the IANA to
+   assign various numbers.  This document by itself however, does not
+   require any IANA involvement.
+
+8. References
+
+   [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): Framework and four profiles: RTP, UDP, ESP, and
+          uncompressed", RFC 3095, July 2001.
+
+   [RTSP] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
+          Protocol (RTSP)", RFC 2326, April 1998.
+
+   [SDP]  Handley, H. and V. Jacobson, "SDP: Session Description
+          Protocol", RFC 2327, April 1998.
+
+
+
+
+
+
+Hannu                        Informational                     [Page 11]
+
+RFC 3322           SigComp Requirements & Assumptions       January 2003
+
+
+   [SIP]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+          Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
+          Session Initiation Protocol", RFC 3261, June 2002.
+
+   [UDP]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
+          1980.
+
+   [TCP]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
+          September 1981.
+
+   [TSG]  Nortel Networks, "A Comparison Between GERAN Packet-Switched
+          Call Setup Using SIP and GSM Circuit-Switched Call Setup Using
+          RIL3-CC, RIL3-MM, RIL3-RR, and DTAP", 3GPP TSG GERAN #2, GP-
+          000508, 6-10 November 2000.
+
+9. Author's Address
+
+   Hans Hannu
+   Box 920
+   Ericsson AB
+   SE-971 28 Lulea, Sweden
+
+   Phone:  +46 920 20 21 84
+   EMail: hans.hannu@epl.ericsson.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hannu                        Informational                     [Page 12]
+
+RFC 3322           SigComp Requirements & Assumptions       January 2003
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hannu                        Informational                     [Page 13]
+