rfc2689.txt

RFC 的详细文档！

   technology need only be deployed at bottleneck links; high-speed
   links can transfer the real-time streams without routers or switches
   expending CPU cycles to perform header compression.

4.  Principles of Real-Time Encapsulation for Low-Bitrate Links

   The main design goal for a real-time encapsulation is to minimize the
   delay incurred by real-time packets that become available for sending
   while a long data packet is being sent.  To achieve this, the
   encapsulation must be able to either abort or suspend the transfer of
   the long data packet.  As an additional goal is to minimize the
   overhead required for the transmission of packets from periodic
   flows, this strongly argues for being able to suspend a packet, i.e.
   segment it into parts between which the real-time packets can be
   transferred.



Bormann                      Informational                      [Page 5]

RFC 2689       Integrated Services over Low-bitrate Links September 1999


4.1.  Using existing IP fragmentation

   Transmitting only part of a packet, to allow higher-priority traffic
   to intervene and then resuming its transmission later on, is a kind
   of fragmentation.  Fragmentation is an existing functionality of the
   IP layer: An IPv4 header already contains fields that allow a large
   IP datagram to be fragmented into small parts.  A sender's "real-time
   PPP" implementation might simply indicate a small MTU to its IP stack
   and thus cause all larger datagrams to be fragmented down to a size
   that allows the access delay goals to be met (this assumes that the
   IP stack is able to priority-tag fragments, or that the PPP
   implementation is able to correlate the fragments to the initial one
   that carries the information relevant for prioritizing, or that only
   initial fragments can be high-priority).  (Also, a PPP implementation
   can negotiate down the MTU of its peer, causing the peer to fragment
   to a small size, which might be considered a crude form of
   negotiating an access delay goal with the peer system -- if that
   system supports priority queueing at the fragment level.)

   Unfortunately, a full, 20 byte IP header is needed for each fragment
   (larger when IP options are used).  This limits the minimum size of
   fragments that can be used without too much overhead.  (Also, the
   size of non-final fragments must be a multiple of 8 bytes, further
   limiting the choice.)  With path MTU discovery, IP level
   fragmentation causes TCP implementations to use small MSSs -- this
   further increases the per-packet overhead to 40 bytes per fragment.

   In any case, fragmentation at the IP level persists on the path
   further down to the datagram receiver, increasing the transmission
   overheads and router load throughout the network.  With its high
   overhead and the adverse effect on the Internet, IP level
   fragmentation can only be a stop-gap mechanism when no other
   fragmentation protocol is available in the peer implementation.

4.2.  Link-Layer Mechanisms

   Cell-oriented multiplexing techniques such as ATM that introduce
   regular points where cells from a different packet can be
   interpolated are too inefficient for low-bitrate links; also, they
   are not supported by chips used to support the link layer in low-
   bitrate routers and host interfaces.










Bormann                      Informational                      [Page 6]

RFC 2689       Integrated Services over Low-bitrate Links September 1999


   Instead, the real-time encapsulation should as far as possible make
   use of the capabilities of the chips that have been deployed.  On
   synchronous lines, these chips support HDLC framing; on asynchronous
   lines, an asynchronous variant of HDLC that usually is implemented in
   software is being used.  Both variants of HDLC provide a delimiting
   mechanism to indicate the end of a frame over the link.  The obvious
   solution to the segmentation problem is to combine this mechanism
   with an indication of whether the delimiter terminates or suspends
   the current packet.

   This indication could be in an octet appended to each frame
   information field; however, seven out of eight bits of the octet
   would be wasted.  Instead, the bit could be carried at the start of
   the next frame in conjunction with multiplexing information (PPP
   protocol identifier etc.) that will be required here anyway.  Since
   the real-time flows will in general be periodic, this multiplexing
   information could convey (part of) the compressed form of the header
   for the packet.  If packets from the real-time flow generally are of
   constant length (or have a defined maximum length that is often
   used), the continuation of the suspended packet could be immediately
   attached to it, without expending a further frame delimiter, i.e.,
   the interpolation of the real-time packet would then have zero
   overhead.  Since packets from low-delay real-time flows generally
   will not require the ability to be further suspended, the
   continuation bit could be reserved for the non-real-time packet
   stream.

   One real-time encapsulation format with these (and other) functions
   is described in ITU-T H.223 [13], the multiplex used by the H.324
   modem-based videophone standard [14].  It was investigated whether
   compatibility could be achieved with this specification, which will
   be used in future videophone-enabled (H.324 capable) modems.
   However, since the multiplexing capabilities of H.223 are limited to
   15 schedules (definitions of sequences of packet types that can be
   identified in a multiplex header), for general Internet usage a
   superset or a more general encapsulation would have been required.
   Also, a PPP-style negotiation protocol was needed instead of using
   (and necessarily extending) ITU-T H.245 [15] for setting the
   parameters of the multiplex.  In the PPP context, the interactions
   with the encapsulations for data compression and link layer
   encryption needed to be defined (including operation in the presence
   of padding).  But most important, H.223 requires synchronous HDLC
   chips that can be configured to send frames without an attached CRC,
   which is not possible with all chips deployed in commercially
   available routers; so complete compatibility was unachievable.






Bormann                      Informational                      [Page 7]

RFC 2689       Integrated Services over Low-bitrate Links September 1999


   Instead of adopting H.223, it was decided to pursue an approach that
   is oriented towards compatibility both with existing hardware and
   existing software (in particular PPP) implementations.  The next
   subsection groups these implementations according to their
   capabilities.

4.3.  Implementation models

   This section introduces a number of terms for types of
   implementations that are likely to emerge.  It is important to have
   these different implementation models in mind as there is no single
   approach that fits all models best.

4.3.1.  Sender types

   There are two fundamental approaches to real-time transmission on
   low-bitrate links:

   Sender type 1
      The PPP real-time framing implementation is able to control the
      transmission of each byte being transmitted with some known,
      bounded delay (e.g., due to FIFOs).  For example, this is
      generally true of PC host implementations, which directly access
      serial interface chips byte by byte or by filling a very small
      FIFO.  For type 1 senders, a suspend/resume type approach will be
      typically used: When a long frame is to be sent, the attempt is to
      send it undivided; only if higher priority packets come up during
      the transmission will the lower-priority long frame be suspended
      and later resumed.  This approach allows the minimum variation in
      access delay for high-priority packets; also, fragmentation
      overhead is only incurred when actually needed.

   Sender type 2
      With type 2 senders, the interface between the PPP real-time
      framing implementation and the transmission hardware is not in
      terms of streams of bytes, but in terms of frames, e.g., in the
      form of multiple (prioritized) send queues directly supported by
      hardware.  This is often true of router systems for synchronous
      links, in particular those that have to support a large number of
      low-bitrate links.  As type 2 senders have no way to suspend a
      frame once it has been handed down for transmission, they
      typically will use a queues-of-fragments approach, where long
      packets are always split into units that are small enough to
      maintain the access delay goals for higher-priority traffic.
      There is a trade-off between the variation in access delay
      resulting from a large fragment size and the overhead that is
      incurred for every long packet by choosing a small fragment size.




Bormann                      Informational                      [Page 8]

RFC 2689       Integrated Services over Low-bitrate Links September 1999


4.3.2.  Receiver types

   Although the actual work of formulating transmission streams for
   real-time applications is performed at the sender, the ability of the
   receiver to immediately make use of the information received depends
   on its characteristics:

   Receiver type 1
      Type 1 receivers have full control over the stream of bytes
      received within PPP frames, i.e., bytes received are available
      immediately to the PPP real-time framing implementation (with some
      known, bounded delay e.g. due to FIFOs etc.).

   Receiver type 2
      With type 2 receivers, the PPP real-time framing implementation
      only gets hold of a frame when it has been received completely,
      i.e., the final flag has been processed (typically by some HDLC
      chip that directly fills a memory buffer).

4.4.  Conclusion

   As a result of the diversity in capabilities of current
   implementations, there are now two specifications for real-time
   encapsulation: One, the multi-class extension to the PPP multi-link
   protocol, is providing the solution for the queues-of-fragments
   approach by extending the single-stream PPP multi-link protocol by
   multiple classes [8].  The other encapsulation, PPP in a real-time
   oriented HDLC-like framing, builds on this specification end extends
   it by a way to dynamically delimit multiple fragments within one HDLC
   frame [9], providing the solution for the suspend/resume type
   approach.

5.  Principles of Header Compression for Real-Time Flows

   A good baseline for a discussion about header compression is in the
   new IP header compression specification that was designed in
   conjunction with the development of IPv6 [2].  The techniques used
   there can reduce the 28 bytes of IPv4/UDP header to about 6 bytes
   (depending on the number of concurrent streams); with the remaining 4
   bytes of HDLC/PPP overhead and 12 bytes for RTP the total header
   overhead can be about halved but still exceeds the size of a G.723.1
   ACELP frame.  Note that, in contrast to IP header compression, the
   environment discussed here assumes the existence of a full-duplex PPP
   link and thus can rely on negotiation where IP header compression
   requires repeated transmission of the same information.  (The use of
   the architecture of the present document with link layer multicasting
   has not yet been examined.)




Bormann                      Informational                      [Page 9]

RFC 2689       Integrated Services over Low-bitrate Links September 1999


   Additional design effort was required for RTP header compression.
   Applying the concepts of IP header compression, of the (at least) 12
   bytes in an RTP header, 7 bytes (timestamp, sequence, and marker bit)
   would qualify as RANDOM; DELTA encoding cannot generally be used
   without further information since the lower layer header does not
   unambiguously identify the semantics and there is no TCP checksum
   that can be relied on to detect incorrect decompression.  Only a more
   semantics-oriented approach can provide better compression (just as
   RFC 1144 can provide very good compression of TCP headers by making
   use of semantic knowledge of TCP and its checksumming method).

   For RTP packets, differential encoding of the sequence number and
   timestamps is an efficient approach for certain cases of payload data
   formats.  E.g., speech flows generally have sequence numbers and
   timestamp fields that increase by 1 and by the frame size in
   timestamp units, resp.; the CRTP (compressed RTP) specification makes