rfc3095.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,375 行 · 第 1/5 页

   A.1.  General classification......................................153
   A.1.1.  IPv6 header fields........................................153
   A.1.2.  IPv4 header fields........................................155



Bormann, et al.             Standards Track                     [Page 5]

RFC 3095               Robust Header Compression               July 2001


   A.1.3.  UDP header fields.........................................157
   A.1.4.  RTP header fields.........................................157
   A.1.5.  Summary for IP/UDP/RTP....................................159
   A.2.  Analysis of change patterns of header fields................159
   A.2.1.  IPv4 Identification.......................................162
   A.2.2.  IP Traffic-Class / Type-Of-Service........................163
   A.2.3.  IP Hop-Limit / Time-To-Live...............................163
   A.2.4.  UDP Checksum..............................................163
   A.2.5.  RTP CSRC Counter..........................................164
   A.2.6.  RTP Marker................................................164
   A.2.7.  RTP Payload Type..........................................164
   A.2.8.  RTP Sequence Number.......................................164
   A.2.9.  RTP Timestamp.............................................164
   A.2.10.  RTP Contributing Sources (CSRC)..........................165
   A.3.  Header compression strategies...............................165
   A.3.1.  Do not send at all........................................165
   A.3.2.  Transmit only initially...................................165
   A.3.3.  Transmit initially, but be prepared to update.............166
   A.3.4.  Be prepared to update or send as-is frequently............166
   A.3.5.  Guarantee continuous robustness...........................166
   A.3.6.  Transmit as-is in all packets.............................167
   A.3.7.  Establish and be prepared to update delta.................167
   Full Copyright Statement..........................................168

1.  Introduction

   During the last five years, two communication technologies in
   particular have become commonly used by the general public: cellular
   telephony and the Internet.  Cellular telephony has provided its
   users with the revolutionary possibility of always being reachable
   with reasonable service quality no matter where they are.  The main
   service provided by the dedicated terminals has been speech.  The
   Internet, on the other hand, has from the beginning been designed for
   multiple services and its flexibility for all kinds of usage has been
   one of its strengths.  Internet terminals have usually been general-
   purpose and have been attached over fixed connections.  The
   experienced quality of some services (such as Internet telephony) has
   sometimes been low.

   Today, IP telephony is gaining momentum thanks to improved technical
   solutions.  It seems reasonable to believe that in the years to come,
   IP will become a commonly used way to carry telephony.  Some future
   cellular telephony links might also be based on IP and IP telephony.
   Cellular phones may have become more general-purpose, and may have IP
   stacks supporting not only audio and video, but also web browsing,
   email, gaming, etc.





Bormann, et al.             Standards Track                     [Page 6]

RFC 3095               Robust Header Compression               July 2001


   One of the scenarios we are envisioning might then be the one in
   Figure 1.1, where two mobile terminals are communicating with each
   other.  Both are connected to base stations over cellular links, and
   the base stations are connected to each other through a wired (or
   possibly wireless) network.  Instead of two mobile terminals, there
   could of course be one mobile and one wired terminal, but the case
   with two cellular links is technically more demanding.

   Mobile            Base                      Base            Mobile
   Terminal          Station                   Station         Terminal


         |  ~   ~   ~  \ /                       \ /  ~   ~   ~   ~  |
         |              |                         |                  |
      +--+              |                         |               +--+
      |  |              |                         |               |  |
      |  |              |                         |               |  |
      +--+              |                         |               +--+
                        |                         |
                        |=========================|

            Cellular              Wired               Cellular
            Link                  Network             Link

        Figure 1.1 : Scenario for IP telephony over cellular links

   It is obvious that the wired network can be IP-based.  With the
   cellular links, the situation is less clear.  IP could be terminated
   in the fixed network, and special solutions implemented for each
   supported service over the cellular link.  However, this would limit
   the flexibility of the services supported.  If technically and
   economically feasible, a solution with pure IP all the way from
   terminal to terminal would have certain advantages.  However, to make
   this a viable alternative, a number of problems have to be addressed,
   in particular problems regarding bandwidth efficiency.

   For cellular phone systems, it is of vital importance to use the
   scarce radio resources in an efficient way.  A sufficient number of
   users per cell is crucial, otherwise deployment costs will be
   prohibitive.  The quality of the voice service should also be as good
   as in today's cellular systems.  It is likely that even with support
   for new services, lower quality of the voice service is acceptable
   only if costs are significantly reduced.








Bormann, et al.             Standards Track                     [Page 7]

RFC 3095               Robust Header Compression               July 2001


   A problem with IP over cellular links when used for interactive voice
   conversations is the large header overhead.  Speech data for IP
   telephony will most likely be carried by RTP [RTP].  A packet will
   then, in addition to link layer framing, have an IP [IPv4] header (20
   octets), a UDP [UDP] header (8 octets), and an RTP header (12 octets)
   for a total of 40 octets.  With IPv6 [IPv6], the IP header is 40
   octets for a total of 60 octets.  The size of the payload depends on
   the speech coding and frame sizes being used and may be as low as
   15-20 octets.

   From these numbers, the need for reducing header sizes for efficiency
   reasons is obvious.  However, cellular links have characteristics
   that make header compression as defined in [IPHC,CRTP] perform less
   than well.  The most important characteristic is the lossy behavior
   of cellular links, where a bit error rate (BER) as high as 1e-3 must
   be accepted to keep the radio resources efficiently utilized.  In
   severe operating situations, the BER can be as high as 1e-2.  The
   other problematic characteristic is the long round-trip time (RTT) of
   the cellular link, which can be as high as 100-200 milliseconds.  An
   additional problem is that the residual BER is nontrivial, i.e.,
   lower layers can sometimes deliver frames containing undetected
   errors.  A viable header compression scheme for cellular links must
   be able to handle loss on the link between the compression and
   decompression point as well as loss before the compression point.

   Bandwidth is the most costly resource in cellular links.  Processing
   power is very cheap in comparison.  Implementation or computational
   simplicity of a header compression scheme is therefore of less
   importance than its compression ratio and robustness.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

   BER

      Bit Error Rate.  Cellular radio links can have a fairly high BER.
      In this document BER is usually given as a probability, but one
      also needs to consider the error distribution as bit errors are
      not independent.









Bormann, et al.             Standards Track                     [Page 8]

RFC 3095               Robust Header Compression               July 2001


   Cellular links

      Wireless links between mobile terminals and base stations.

   Compression efficiency

      The performance of a header compression scheme can be described
      with three parameters: compression efficiency, robustness and
      compression transparency.  The compression efficiency is
      determined by how much the header sizes are reduced by the
      compression scheme.

   Compression transparency

      The performance of a header compression scheme can be described
      with three parameters: compression efficiency, robustness, and
      compression transparency.  The compression transparency is a
      measure of the extent to which the scheme ensures that the
      decompressed headers are semantically identical to the original
      headers.  If all decompressed headers are semantically identical
      to the corresponding original headers, the transparency is 100
      percent.  Compression transparency is high when damage propagation
      is low.

   Context

      The context of the compressor is the state it uses to compress a
      header.  The context of the decompressor is the state it uses to
      decompress a header.  Either of these or the two in combination
      are usually referred to as "context", when it is clear which is
      intended.  The context contains relevant information from previous
      headers in the packet stream, such as static fields and possible
      reference values for compression and decompression.  Moreover,
      additional information describing the packet stream is also part
      of the context, for example information about how the IP
      Identifier field changes and the typical inter-packet increase in
      sequence numbers or timestamps.

   Context damage

      When the context of the decompressor is not consistent with the
      context of the compressor, decompression may fail to reproduce the
      original header.  This situation can occur when the context of the
      decompressor has not been initialized properly or when packets
      have been lost or damaged between compressor and decompressor.






Bormann, et al.             Standards Track                     [Page 9]

RFC 3095               Robust Header Compression               July 2001


      Packets which cannot be decompressed due to inconsistent contexts
      are said to be lost due to context damage.  Packets that are
      decompressed but contain errors due to inconsistent contexts are
      said to be damaged due to context damage.

   Context repair mechanism

      Context repair mechanisms are mechanisms that bring the contexts
      in sync when they were not.  This is needed to avoid excessive
      loss due to context damage.  Examples are the context request
      mechanism of CRTP, the NACK mechanisms of O- and R-mode, and the
      periodic refreshes of U-mode.

      Note that there are also mechanisms that prevent (some) context
      inconsistencies from occurring, for example the ACK-based updates
      of the context in R-mode, the repetitions after change in U- and
      O-mode, and the CRCs which protect context updating information.

   CRC-DYNAMIC

      Opposite of CRC-STATIC.

   CRC-STATIC

      A CRC over the original header is the primary mechanism used by
      ROHC to detect incorrect decompression.  In order to decrease
      computational complexity, the fields of the header are
      conceptually rearranged when the CRC is computed, so that it is
      first computed over octets which are static (called CRC-STATIC in
      this document) and then over octets whose values are expected to
      change between packets (CRC-DYNAMIC).  In this manner, the
      intermediate result of the CRC computation, after it has covered
      the CRC-STATIC fields, can be reused for several packets.  The
      restarted CRC computation only covers the CRC-DYNAMIC octets.  See
      section 5.9.

   Damage propagation

      Delivery of incorrect decompressed headers, due to errors in
      (i.e., loss of or damage to) previous header(s) or feedback.