[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 rfc2689                                  
INTERNET-DRAFT                                           Carsten Bormann
Expires: December 1996                               Universitaet Bremen
                                                               June 1996


          Providing integrated services over low-bitrate links
                     draft-ietf-issll-isslow-00.txt


Status of this memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.

Abstract

   This document describes an architecture for providing integrated
   services over low-bitrate links, such as modem lines, ISDN B-
   channels, and sub-T1 links.  It covers only the lower parts of the
   Internet Multimedia Conferencing Architecture [1]; additional
   components required for application services such as Internet
   Telephony (e.g., a session initiation protocol) are outside the scope
   of this document.  The main components of the architecture are: a
   real-time encapsulation format for asynchronous and synchronous low-
   bitrate links, a header compression architecture optimized for real-
   time flows, elements of negotiation protocols used between routers
   (or between hosts and routers), and announcement protocols used by
   applications to allow this negotiation to take place.

   Annexes contain initial strawman proposals for the elements of the
   architecture, complemented by a list of issues that need to be
   resolved to proceed.

   This document is a submission to the IETF ISSLL working-group-in-
   creation.
   Comments are solicited and should be addressed to the working group's
   mailing list at issll@mercury.lcs.mit.edu and/or the author.


Bormann                                                         [Page 1]


INTERNET-DProviding integrated services over low-bitrate links June 1996

1.  Introduction

   As an extension to the ``best-effort'' services the Internet is well-
   known for, additional types of services (``integrated services'')
   that support the transport of real-time multimedia information are
   being developed for and deployed in the Internet.  Important elements
   of this development are:

   -    parameters for forwarding mechanisms that are appropriate for
        real-time information (in the intserv working group of the IETF)

   -    a setup protocol that allows establishing special forwarding
        treatment for real-time information flows (RSVP [4], in the rsvp
        working group of the IETF)

   -    a transport protocol for real-time information (RTP/RTCP, in the
        avt working group of the IETF)[1].

   Up to now, the newly developed services could not (or only very
   inefficiently) be used over forwarding paths that include low-bitrate
   links such as 14.4 and 28.8 kbit/s modems, 56 and 64 kbit/s ISDN B-
   channels, or even sub-T1 links.  The encapsulation formats used on
   these links are not appropriate for the simultaneous transport of
   arbitrary data and real-time information that has to meet stringent
   delay requirements.  A 1500 byte packet on a 28.8 kbit/s modem link
   makes this link unavailable for the transmission of real-time
   information for about 400 ms.  This adds a worst-case delay that
   causes real-time applications to operate with round-trip delays on
   the order of at least a second -- unacceptable for real-time
   conversation.  In addition, the header overhead associated with the
   protocol stacks used is prohibitive on low-bitrate links, where
   compression down to a few dozen bytes per real-time information
   packet is often desirable.  E.g., the overhead of at least 44
   (4+20+8+12) bytes for HDLC/PPP, IP, UDP, and RTP completely
   overshadows the 19.75 bytes needed for a G.723.1 ACELP audio frame --
   a 14.4 kbit/s link is completely consumed by this header overhead
   alone at 40 real-time frames per second (i.e., at 25 ms packetization
   delay for one stream or 50 ms for two streams, with no space left for
   data, yet).  While the header overhead can be reduced by combining
   several real-time information frames into one packet, this increases
   the delay incurred while filling that packet and further detracts
   from the goal of real-time transfer of multi-media information over
   the Internet.

   This document describes an approach for addressing these problems.
_________________________
  [1] Note  that  this document only is concerned with the network
and transport parts of the Internet Multimedia Conferencing Archi-
tecture  [1].   To  define  application  services such as Internet
Telephony, additional components are required, e.g., protocols for
session  initiation and control.  These components are outside the
scope of this document.


Bormann                                                         [Page 2]


INTERNET-DProviding integrated services over low-bitrate links June 1996

   The main components of the architecture are:

   -    a real-time encapsulation format for asynchronous and
        synchronous low-bitrate links,

   -    a header compression architecture optimized for real-time flows,

   -    elements of negotiation protocols used between routers (or
        between hosts and routers), and

   -    announcement protocols used by applications to allow this
        negotiation to take place.


2.  Design Considerations


   The main design goal for an architecture that addresses real-time
   multimedia flows over low-bitrate links is that of minimizing the
   end-to-end delay.  More specifically, the worst case delay (after
   removing possible outliers, which are equivalent to packet losses
   from an application point of view) is what determines the playout
   points selected by the applications and thus the delay actually
   perceived by the user.

   In addition, any such architecture should obviously undertake every
   attempt to maximize the bandwidth actually available to media data;
   overheads must be minimized.

   An important component of the integrated services architecture is the
   provision of reservations for real-time flows.  One of the problems
   that systems on low-bitrate links (routers or hosts) face when
   performing admission control for such reservations is that they must
   translate the bandwidth requested in the reservation to the one
   actually consumed on the link.  Methods such as data compression
   and/or header compression can reduce the requirements on the link,
   but admission control can only make use of the reduced requirements
   in its calculations if it has enough information about the data
   stream to know how effective the compression will be.  One goal of
   the architecture therefore is to provide the integrated services
   admission control with this information.  A beneficial side effect
   may be to allow the systems to perform better compression than would
   be possible without this information.  This may make it worthwhile to
   provide this information even when it is not intended to make a
   reservation for a real-time flow.



3.  The Need for a Concerted Approach

   Given that there are so many technical approaches to addressing the
   problem, one wonders whether maybe one of these techniques could
   suffice or whether maybe they could be applied independently of each

Bormann                                                         [Page 3]


INTERNET-DProviding integrated services over low-bitrate links June 1996

   other, reducing the need for synchronization between IETF working
   groups and the need for verbose architecture papers such as the
   present one.  This section therefore examines the opportunities of
   using each of a number of these techniques in isolation.


3.1.  Defining a Real-Time Encapsulation Only

   The purpose of defining a real-time link-layer encapsulation protocol
   is to be able to introduce newly arrived real-time packets in the
   link-layer data stream without having to wait for the currently
   transmitted (possibly large) packet to end.  To be able to do this in
   an interface driver, it is first necessary to identify packets that
   belong to these flows.  If one does not want to resort to a heuristic
   approach (e.g., favor the transmission of highly periodic flows of
   small packets transported in IP/UDP[2]), one should make use of the
   protocol defined for identifying flows that require special
   treatment, i.e. RSVP.  Of the two service types defined for use with
   RSVP now, the guaranteed service, will only be available in certain
   environments.  For this and various other reasons, the obvious
   service type for most adaptive audio/video applications will be the
   controlled-load service.  Controlled-load does not provide control
   parameters for target delay; this makes it very hard to identify
   those packet streams that would benefit most of being transported in
   a real-time encapsulation format.

   Obviously, a real-time encapsulation must be part of any complete
   solution as the problem of delays induced by large frames on the link
   can only be solved on this layer.  It is not sufficient on its own,
   however: Even if the relevant flows can be appropriately identified
   for real-time treatment, most applications simply are not possible on
   low-bitrate links with the header overhead implied by the combination
   of HDLC/PPP, IP, UDP, and RTP, i.e. they absolutely require header
   compression.


3.2.  Using Application Header Compression Only


   For the internet telephone vendors, the approach that comes to mind
   immediately is to reduce overhead by building header compression into
   the applications[3].

   Generally, header compression operates by installing state at both
   ends of a link that allows the receiving end to reconstruct
   information omitted at the sending end.  Many good techniques for
_________________________
  [2] Which could turn out to be a DNS implementation gone wild or
a malicious attempt to gain preferential access to an Internet re-
source.
  [3] or actually by using a non-standard, efficiently coded head-
er in the first place.


Bormann                                                         [Page 4]


INTERNET-DProviding integrated services over low-bitrate links June 1996

   header compression (RFC 1144, [2]) operate on the assumption that the
   link will not reorder the frames generated.  This assumption does not
   hold for end-to-end compression; therefore additional overhead is
   required for resequencing state changes and compressed packets making
   use of these state changes.

   Assume that a very good application level header compression solution
   for RTP flows could be able to save 11 out of the 12 bytes of an RTP
   header [3].  Even this perfect solution only reduces the total header
   overhead by 1/4.  It would have to be deployed in all applications,
   even those that operate on systems that are attached to higher-
   bitrate links.


3.3.  Using Hop-By-Hop Header Compression Only


   For router vendors, the obvious approach is to define header
   compression that can be negotiated between peer routers.

   Advanced header compression techniques now being defined in the IETF
   [2] certainly can relieve the link from significant parts of the
   IP/UDP overhead (i.e., of 28 of the 44 bytes mentioned above).

   One of the design principles of the header compression contemplated
   for IPv6 is that it stops at layers the semantics of which cannot be
   inferred from information in lower layer (outer) headers.  Therefore,
   IPv6 header compression cannot compress the data within UDP packets.

   Any additional header compression technique runs into a difficult
   problem: If it assumes specific application semantics (i.e., those of
   RTP and a payload data format) based on heuristics, it runs the risk
   of being triggered falsely and (e.g. in case of packet loss)
   reconstructing packets that are catastrophically incorrect for the
   application actually being used.  If it does not presume application
   semantics, it will only be able to achieve limited compression, as it
   needs to carry sufficient information in each packet that, even in
   the presence of packet loss on the link, only packets are ever
   reconstructed that are correct bit-by-bit.  Together with link layer
   overheads, it is likely that more than half of the 19.75 bytes used
   for a G.723.1 ACELP frame would be needed for header overhead.


4.  A Real-Time Encapsulation Format 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.  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

Bormann                                                         [Page 5]


INTERNET-DProviding integrated services over low-bitrate links June 1996

   into parts between which the real-time packets can be transferred.

   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.

   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.

   A real-time encapsulation with these (and other) functions is
   described in ITU-T H.223.  It may be desirable to strive for
   compatibility 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), it may be desirable to define a superset or a more
   general encapsulation.  It may also be desirable to rely on a PPP-
   style negotiation protocol instead of using (and necessarily
   extending) ITU-T H.245 for setting the parameters of the multiplex.
   The interactions with the encapsulations for data compression and
   link layer encryption need to be defined (including operation in the
   presence of padding).  Finally, 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; additional flexibility is needed here.

   Annex A provides further considerations about real-time

Bormann                                                         [Page 6]


INTERNET-DProviding integrated services over low-bitrate links June 1996

   encapsulations.


5.  A Header Compression Architecture for Real-Time Flows


   A good baseline for a discussion about header compression is in the
   IPv6 header compression draft [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 IPv6 header compression, the present
   document assumes the existence of a full-duplex PPP link and thus can
   rely on negotiation where IPv6 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.)

   Additional design effort is required for RTP header compression.
   Applying the concepts of IPv6 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.; for encodings such as G.723.1, a seven-bit
   (leaving space for the marker bit) field that conveys both would
   provide security against +- 2 seconds of delay jitter for G.723.1
   (the compressor would need to drop or more expensively code all
   packets outside that jitter window).  For a certain subset of these
   cases, the encoding of these fields is essentially optional as errors
   caused by incorrect decompression after single packet loss on the
   link are of minor significance in the playout process; the compressor
   would have to reorder or drop misordered packets (the RTP marker bit
   could be inserted into one of the two unused bits for a G.723.1 ACELP
   payload data format).

   Annex C provides further considerations about RTP header compression.


6.  Announcement Protocols Used by Applications

   It should be obvious from the discussion of header compression that
   the compressor can operate best if it can make use of information

Bormann                                                         [Page 7]


INTERNET-DProviding integrated services over low-bitrate links June 1996

   that clearly identifies real-time streams and provides information
   about the payload data format in use.  For the more aggressive
   compression methods that in certain cases can induce information
   loss, the systems on the low-bitrate link should have consent from
   the application to actually go this far.

   If these systems are routers, this consent must be installed as
   router state; if these systems are hosts, it must be known to their
   networking kernels.  Sources of real-time information flows are
   already describing characteristics of these flows to their kernels
   and to the routers in the form of TSpecs in RSVP PATH messages [4].
   Since these messages make use of the router alert option, they are
   seen by all routers on the path; path state about the packet stream
   is normally installed at each of these routers that implement RSVP.
   Additional RSVP objects could be defined that are included in PATH
   messages by those applications that desire good performance over low-
   bitrate links; these objects would be coded to be ignored by routers
   that are not interested in them (class number 11bbbbbb).

   Note that the path state is available in the routers even when no
   reservation is made; this allows informed compression of best-effort
   traffic.  It is not quite clear to the author how path state could be
   teared down quickly when a source ceases to transmit.

   To be able do deploy informed header compression before RSVP, an
   additional form of application announcements could be defined that do
   not require RSVP to be available at the transmitting host; it would
   be advisable to use the router alert option on these messages, too.
   Alternatively, UDP encapsulation of RSVP could be used (note that a
   way needs to be available to inform the local kernel if the system is
   directly on a low-bitrate link).

   Annex D provides further considerations about announcement protocols.


7.  Elements of Hop-By-Hop Negotiation Protocols


   The IPv6 header compression draft attempts to account for simplex and
   multicast links by providing information about the compressed streams
   only in the forward direction.  E.g., a full IP/UDP header must be
   sent after F_MAX_TIME (currently 3 seconds), which is a negligible
   total overhead (e.g. one full header every 150 G.723.1 packets), but
   must be considered carefully in scheduling the real-time
   transmissions.  Both simplex and multicast links are not prevailing
   in the low-bitrate environment (although multicast functionality may
   become more important with wireless systems); in this document, we
   therefore assume full-duplex capability.

   As compression techniques will improve, a negotiation between the two
   peers on the link would provide the best flexibility in
   implementation complexity and potential for extensibility.  The peer
   routers/hosts can decide which real-time packet streams are to be

Bormann                                                         [Page 8]


INTERNET-DProviding integrated services over low-bitrate links June 1996

   compressed, which header fields are not to be sent at all, which
   multiplexing information should be used on the link, and how the
   remaining header fields should be encoded.  PPP, a well-tried suite
   of negotiation protocols, is already used on most of the low-bitrate
   links and seems to provide the obvious approach.  Cooperation from
   PPP is also needed to negotiate the use of real-time encapsulations
   between systems that are not configured to automatically do so.


8.  A Plan for Further Work


   This section proposes a rough work plan to develop and deploy this
   architecture.  This plan obviously needs to be discussed between the
   parties involved.

   The overall responsibility for this work could be in the domain of
   the newly created IETF issll (Integrated Services over Specific Link
   Layers) working group.  The pppext working group would be the logical
   place to discuss the real-time encapsulation and pertinent
   negotiation protocols.  Work on RTP compression, including
   compression methods specific to particular payload data formats
   should be done within the avt working group; this should include
   media-specific input for the negotiation protocols (a format for
   describing information about media flows has been defined in the
   mmusic working group).  The rsvp working group should agree to the
   way PATH messages are used and provide a code point for the new RSVP
   object.

   Initial deployment of the real-time encapsulation could be in network
   access servers and access routers, with IP stacks on hosts following.
   Outreach activities are probably required to receive timely input
   from application vendors.

   In addition to the work described in this document, additional work
   is required to define the service mappings for controlled-load and
   guaranteed services on serial links; the latter also requires
   techniques to find out about the delay of the link.  The following
   schedule is suggested:

                           Item                              Draft    WG last
                                                             date    call date
1: Realtime Header-compression and packet framing protocol    8/96        2/97
2: Controlled Load Service over ISSLOW                        8/96         TBD
3: Link Delay Measurement Protocol                             TBD
4: Guaranteed Service over ISSLOW                              TBD

   Obviously, item 1 requires particularly close coordination with
   pppext (for the framing format) and avt (for RTP header compression),
   as well as with the group working on IPv6 header compression, ipngwg.




Bormann                                                         [Page 9]


INTERNET-DProviding integrated services over low-bitrate links June 1996

9.  Security Considerations

   Header compression protocols that make use of assumptions about
   application protocols need to be carefully analyzed whether it is
   possible to subvert other applications by maliciously or
   inadvertently enabling their use.

   It is generally not possible to do significant hop-by-hop header
   compression on encrypted streams.  With certain security policies, it
   may be possible to run an encrypted tunnel to a network access server
   that does header compression on the decapsulated packets and sends
   them over an encrypted link encapsulation; see also the short mention
   of interactions between real-time encapsulation and encryption in
   section 4 above.

10.  Author's Address


   Carsten Bormann
   Universitaet Bremen FB3 MZH 5180
   Postfach 330440
   D-28334 Bremen
   GERMANY
   cabo@informatik.uni-bremen.de
   phone +49.421.218-7024


Acknowledgements

   Much of the discussion in this document is based on discussions with
   Scott Petrack of IBM Israel and Cary Fitzgerald of Cisco Systems.

11.  References


   [1]  Mark Handley, Jon Crowcroft, Carsten Bormann, ``The Internet
        Multimedia Conferencing Architecture,'' Internet-Draft draft-
        ietf-mmusic-confarch-00.txt, Work in Progress, February 1996.

   [2]  M. Degermark, B. Nordgren, S. Pink, ``Header Compression for
        IPv6,'' Internet-Draft draft-degermark-ipv6-hc-00.txt, Work in
        Progress, February 1996.

   [3]  Scott Petrack, Ed Ellesson, ``Framework for C/RTP: Compressed
        RTP Using Adaptive Differential Header Compression'',
        contribution to the mailing list rem-conf@es.net, February 1996.

   [4]  R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin,
        Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
        Specification, Internet-Draft draft-ietf-rsvp-spec-10.txt, Work
        in Progress, February 1996.

   [5]  K. Sklower, B. Lloyd, G. McGregor, D. Carr, The PPP Multilink

Bormann                                                        [Page 10]


INTERNET-DProviding integrated services over low-bitrate links June 1996

        Protocol (MP), RFC 1717, November 1994.





















































Bormann                                                        [Page 11]


INTERNET-DProviding integrated services over low-bitrate links June 1996

A.  Strawman for a real-time encapsulation

   This annex provides one possible design for a real-time encapsulation
   (RTE).  The approach chosen here is to be close to H.223 in spirit,
   but not necessarily be fully compliant to it.  Several reasons can be
   given for this:

   1)   It is not clear that many serial chips used in current router
        products can turn off the per-frame CRC as is required by H.223.
        Being compatible may thus simply be impossible.

   2)   Full compliance to H.223 requires H.245, which in turn requires
        X.691 (ASN.1 packed encoding rules or PER).  Very few products
        are available for generating PER ASN.1 encoding.  H.245 is a
        complex standard that is changing rapidly already only a few
        months after being standardized.

   3)   H.223 is limited to 15 simultaneous table indices (see below),
        which may be to small for even 56 kbit/s links.  Extending this
        limit would lose compliance in the general case (an extension
        mechanism that allows compliance in the basic case is possible,
        though).

   4)   H.223 is intended to be used over synchronous links.  Much
        initial use of RTE will be over links that are used with
        asynchronous protocols.  There is little incentive to be
        compatible with H.223 in this case.

   5)   H.223 is standardized in the H.324 context, i.e. for use
        directly over synchronous modem links.  Today's modems generally
        require the use of V.42 to enable HDLC-style synchronous
        operation while connecting to asynchronous PC interfaces.  It is
        not clear to the author that consumer modems will offer a way to
        interface to their synchronous data pumps in a way that H.223
        can be part of a mass-market product.

   Obviously, for each of these reasons there are quite plausible
   counter-arguments; the author of this draft is open to suggestions.

A.1.  Terminology

   This document uses the following terms as in RFC 1662:

   datagram
        The unit of transmission in the network layer (such as IP).  A
        datagram may be encapsulated in one or more packets passed to
        the data link layer.

   frameThe unit of transmission at the data link layer.  A frame may
        include a header and/or a trailer, along with some number of
        units of data.

   packetThe basic unit of encapsulation, which is passed across the

Bormann                                                        [Page 12]


INTERNET-DProviding integrated services over low-bitrate links June 1996

        interface between the network layer and the data link layer.  A
        packet is usually mapped to a frame; the exceptions are when
        data link layer fragmentation is being performed, or when
        multiple packets are incorporated into a single frame.

   In addition, we use the following terms (better suggestions are
   welcome):

   segment
        A part of a packet that is encapsulated as part of a frame.

   blockA part of a frame that is used to carry a segment.

   final block
        A block carrying the last or only segment of a packet.

   continued block
        A block carrying any but the final segment of a packet.

A.2.  Principles

   RTE should be as close as possible to generic PPP encapsulation.
   Frames are delimited by HDLC flags.  For asynchronous operation, we
   retain the octet-stuffing method defined in RFC1662; for synchronous
   operation we retain bit-stuffing.

   As an additional requirement, a PPP LCP frame (that could be sent in
   RFC 1662 form when one peer returns to the PPP Starting state) must
   not be confused with a valid RTE frame.  Therefore, RTE is designed
   such that no RTE frame can start with a 0xff byte (or the equivalent
   octet-stuffed sequence).  (Note that there is no need to
   simultaneously cope with address/control field compressed packets, as
   RTE is intended as an alternative to that PPP feature.)

   Since on many synchronous HDLC chips the CRC generation/checking
   cannot be switched off, a frame end imposes an overhead of at least
   24 bits (32 if single-flag delimiting is not possible).  As many
   blocks will be very small, this is significant overhead; therefore,
   RTE provides for more than one block to be carried in a frame.

   To achieve maximum compression, we distinguish three types of blocks:

   1)   ``Small'' constant-size blocks from real-time flows,

   2)   ``Small'' variable-size blocks, e.g. from real-time flows, and

   3)   ``Large'' variable-size blocks, e.g. from non-real-time flows.

   To achieve small delays, type 3 blocks can be preempted by type 1 and
   type 2 blocks, i.e. transmission of a type 3 block can be suspended
   to make way for a type 1 or 2 block with real-time requirements.
   Since the need for this is generally not known at the time the type 3
   block is started, a way is needed to unambiguously signify the end of

Bormann                                                        [Page 13]


INTERNET-DProviding integrated services over low-bitrate links June 1996

   the block during its transmission; the end of the frame is used as
   this indication.  The information whether this end-of-frame condition
   signifies the end of the final block of the packet or just the end of
   a continued block, can be represented in one bit; this bit is packed
   into additional header information at the start of the next frame[4].
   A CRC is added to packets transported in one or more type 3 blocks so
   that incorrect reception of the continuation status can be detected.

   The header information at the start of a frame contains an index into
   a frame composition table.  The table entry identifies the PPP
   protocol identifiers of the blocks that are to be sent in this frame.
   It also contains length information for the type 1 blocks.  The frame
   header is protected by a short CRC:

   1)   For links that can switch off the CRC generation (including most
        asynchronous links), it is useful to have some protection of the
        table index.

   2)   Even if the frame level CRC generation cannot be switched off,
        it minimizes delay to release the contents of blocks to the
        network layer before the end of the frame has been reached; the
        frame header must be verified early for this to be safe.

   The coding of the continuation bit, table index, and header CRC is
   chosen to reserve a 0xff initial header byte to signify that the HDLC
   frame contains RFC1662 encapsulated data instead of RTE data.

A.3.  Example

   This section presents a simple example scenario and some frames taken
   from that scenario.

   An RTE link is being used by an Internet videophone attached to an
   asynchronous serial line.  Two real-time flows have been identified
   via RSVP: A G.723.1 audio stream of 20 byte audio units and a H.263
   video stream of variable size video units, both encapsulated in
   RTP/UDP/IP.

   For this application, the data link layer peers agree to set the
   frame composition table for this direction as follows:

    Index                            Sequence
    -------------------------------------------------------------------


_________________________
  [4] Note that it also would be possible to define an alternative
closing delimiter for HDLC frames that are suspended.  This  would
be  very  hard  to implement with most chips for synchronous HDLC,
but in many cases quite easy for asynchronous HDLC.  Since diverg-
ing  encapsulations for synchronous and asynchronous HDLC would be
a bad thing, this is not pursued further.


Bormann                                                        [Page 14]


INTERNET-DProviding integrated services over low-bitrate links June 1996

    n0      type 3 block, protocol ID 0x21.
    -------------------------------------------------------------------
    n1      type 1 block, compression table index 1, length 20 bytes;
            type 3 block, protocol ID 0x21.
    -------------------------------------------------------------------
    n2      type 2 block, frame delimited, compression table index 2.
    -------------------------------------------------------------------
    n3      type 1 block, compression table index 1, length 20 bytes;
            type 2 block, frame delimited, compression table index 2.
    -------------------------------------------------------------------

   Note that the compression table is defined by the combined RTP and
   UDP/IP/PPP header compression, this in turn includes a protocol ID
   and other information about the flow being compressed.

   All IP packets from flows other than the two specifically reserved
   are sent with index n0.  As the frame CRC is elided, the additional
   type 3 per-packet CRC generates no additional overhead compared to a
   normal, address and control field compressed PPP frame.

   Each time an audio frame needs to be sent, a frame is sent with
   header index n1.  A type 3 block containing information from any
   other IP packet can (but need not) be attached to this frame;
   including a continuation block of a type 3 packet that was
   interrupted to make way for the audio frame.  Assuming that no CRC is
   needed for the audio frame itself, the overhead for transmitting the
   audio frame is at most one flag byte and one header byte; if no frame
   needed to be interrupted, the encapsulation overhead is zero.

   A similar procedure is used for transmitting the video packets.

   Note that this example assumes that both type 2 and type 3 blocks are
   terminated by a frame delimiter; for certain cases on synchronous
   links where the CRC cannot be switched off, it may be advantageous to
   precede type 2 blocks by a length indication.  In this case, a number
   of combinations of type 1 and type 2 blocks followed by a single type
   3 block could be expressed by appropriate table entries without
   additional overhead.

A.4.  Encapsulation issues


   1)   What is the degree of H.223 compatibility required?

   2)   Are type 2 blocks really useful?

   3)   What is the stacking level of preemption that is actually
        required?  H.223 only provides for one level (the H.223
        equivalent of a type 3 block terminates or continues the last
        block of this type).

   4)   Are there implementations that would have trouble handing up a
        type 1 block immediately that is followed in the same frame by a

Bormann                                                        [Page 15]


INTERNET-DProviding integrated services over low-bitrate links June 1996

        long type 3 block?  Are there enough implementations that would
        not have trouble doing that that the concatenation feature is
        worthwhile?

   5)   Would it be useful to pursue a to-be-suspended indication at the
        end of a frame modeled on self-describing padding, i.e. using
        special end-of-frame bytes with escapes (maybe just for
        synchronous PPP, in combination with an alternative delimiter
        style mechanism with asynchronous PPP)?













































Bormann                                                        [Page 16]


INTERNET-DProviding integrated services over low-bitrate links June 1996

A.5.  A simple approach: SRTE

   The previous subsections outlined a way to define an encapsulation
   similar to H.223.  This section attempts to define a simpler
   encapsulation with less functionality.

A.5.1.  Suspending frames

   The suspension flag is contained in the last byte of each frame
   information field.  If the byte has the value SUSPEND (TBD), the
   frame is suspended; the byte is not part of the frame.  If the byte
   has the value TERMINATE (TBD), the frame is terminated; the byte is
   not part of the frame.  If the byte has any other value, the frame is
   terminated; the byte is part of the fragment.  (Assuming an equal
   distribution of final bytes, the average overhead of this scheme for
   non-suspended frames is 1/128 byte; the overhead for suspended frames
   is 1 byte.)

A.5.2.  Resuming frames

   A special protocol identifier and header is used for identifying
   blocks that resume packets.  Two problems need to be solved:

   1)   Of possibly multiple suspended packets, the correct packet needs
        to be resumed.

   2)   Loss of frames should be detected reliably.

   The first problem can be solved by giving a ``stream number'' to each
   packet.  Only packets with different stream numbers can overtake each
   other.  A small number of streams (three or four) should be
   sufficient.  As the stream number composed of all one bits is never
   used to reliably exclude a 0xFF first header byte, three bits are
   reserved to carry the stream number in the SRTE header.

   The second problem can be made less likely by sequentially numbering
   the blocks in each stream.  A high degree of safety requires a long
   serial number or a checksum over the packet.  In this subsection, we
   will assume that a 3-bit sequence number is sufficient.

   Together, serial and stream number will fit in slightly less than one
   byte.

A.5.3.  Reducing insertion overhead

   The resumption header has one optional additional byte that indicates
   the length of a block that is inserted in front of the packet to be
   resumed, as well as two bits to indicate a stream number between 0
   and 3.  This reduces the overhead of insertion to the size of an SRTE
   header.  The inserted packet may be delivered immediately to the
   network layer if the stream was negotiated to not require frame CRC
   protection.


Bormann                                                        [Page 17]


INTERNET-DProviding integrated services over low-bitrate links June 1996

A.5.4.  Reducing RTE header overhead

   An option can be negotiated that instructs the receiver to prepend a
   certain byte string to each packet of a particular stream.  This can
   e.g. be used to encode the PPP protocol identifier.

A.5.5.  Resulting frame format


             0   1   2   3   4   5   6   7
           +---+---+---+---+---+---+---+---+
           | R | I |  sequence |  stream   |
           +---+---+---+---+---+---+---+---+
           :    length L  (if I)   | stream:
           +.......................+.......+
           :                               :
           :        Inserted packet        :
           :          (length L)           :
           :                               :
           +---+---+---+---+---+---+---+---+
           |            data               |
           :                               :
           +...............................+
           :       SUSPEND/TERMINATE       :
           +---+---+---+---+---+---+---+---+
           |             Frame             |
           |              CRC              |
           +---+---+---+---+---+---+---+---+


A.5.6.  Information to be negotiated

   For each of the seven streams, the following information may be
   negotiated:

   1)   Implicitly prepended header bytes.

   2)   Immediate delivery before frame end.

   For the whole link, SRTE needs to be negotiated before SRTE frames
   can be sent.  The use of frames starting with 0xFF indicates that the
   peer has switched back to LCP.












Bormann                                                        [Page 18]


INTERNET-DProviding integrated services over low-bitrate links June 1996

A.6.  Other approaches: The PPP multilink approach

   One way to achieve fragmentation with the PPP suite of standards as
   defined today is the PPP multilink protocol [5].  The multilink
   protocol provides for sequence numbering and begin/end bits, allowing
   big packets to be split into fragments.  While the serial sequence
   numbering does not allow suspension of a fragment being sent, it is
   possible to send intervening packets that are not encapsulated in
   multilink headers.

   This is not the ideal solution for a number of reasons.  First,
   because of the single monotonically increasing serial number, there
   is only one level of suspension:  ``Big'' packets that are sent via
   multilink can be suspended by ``small'' packets sent outside of
   multilink; the latter are not suspendable.

   Second, the begin/end bits are in the multilink header.  To make a
   big packet suspendable, it must be sent with the ``end'' bit off, and
   (unless the packet was suspended a small number of bytes before its
   end) an empty fragment has to be sent afterwards to ``close'' the
   packet.  The minimum overhead for sending a big packet thus is twice
   the multilink header size (six bytes, including a compressed
   multilink protocol field) plus one PPP framing (three bytes).  Each
   suspension costs another six bytes (not counting the overhead of the
   framing for the intervening packet).

   On the other hand, the multilink approach can be built using existing
   standards; multilink capability is now widely deployed and only the
   sending side needs to be aware that they are using this for giving
   priority to real-time packets.
























Bormann                                                        [Page 19]


INTERNET-DProviding integrated services over low-bitrate links June 1996

B.  Interactions between real-time encapsulation and higher layers

   It is not possible to just plug in real-time encapsulation into any
   working PPP system.  Real-time encapsulation and the ability to
   preempt frames causes the link to no longer be strictly sequence-
   preserving.  Appropriate precautions are required for those higher-
   layer protocols that require sequence-preserving semantics.

B.1.  Link layer compression protocols that assume sequence-preserving
semantics

   Most header and data compression protocols assume sequence-preserving
   transmission of their frames by the PPP encapsulation.  This includes
   RFC1144 TCP/IP header compression.

   One solution is to simply send all frames that are subject to a
   specific kind of compression within one priority group.  For RFC1144,
   this implies using the same priority for all TCP traffic.

   Another solution is to set up one instance of the compression
   mechanism per priority group.  This, obviously, requires cooperation
   from the receiving end (it also has to set up multiple instances and
   has to map priority groups to those instances).  It also generally
   requires related information to remain in one priority group; e.g.,
   for RFC1144, it will not be possible to prioritize ACKs over data.

   A third way of handling the problem is similar to the first way, but
   keeps track of the number of frames in transit.  It is then possible
   to increase the priority as soon as no frames from a lower priority
   are in transit any longer.  The priority can be decreased at any
   time.

B.2.  Multilink

   RFC 1717 multilink requires sequence-preserving semantics.  Similar
   considerations apply as with compression protocols.  An additional
   way to handle the issue is available as RFC 1717 allows packets to be
   sent outside the multilink; the multilink itself could be kept at one
   priority level.

B.3.  Network layer protocols that assume sequence-preserving semantics

   For network layer protocols that assume sequence-preserving
   semantics, such as the PPP bridging protocols, similar considerations
   apply as with compression protocols.  Note that the term ``related
   information'' needs to be defined carefully.  Generally, the PPP
   protocol id will suffice to group packets this way, but multiple
   protocol ids may need to be in one group (generally, this is true for
   the network control protocols and the corresponding data transfer
   protocol ids).




Bormann                                                        [Page 20]


INTERNET-DProviding integrated services over low-bitrate links June 1996

C.  Strawman for a combined RTP and UDP/IP/PPP header compression

   A header compression mechanism for ISSLOW should make use of
   mechanisms available in RTE wherever significant performance
   increases can be gained.

   Generally, one would expect all IP packets to be compressed using
   IPv6 header compression [2].  Several levels of additional
   compression are conceivable for RTP data.

   At the UDP/IP level, there is rarely a requirement to transmit the
   IPv4 identification field (saving two bytes).  For many applications,
   it will also not be necessary to transmit the UDP checksum; this
   optimization obviously needs to be selected by the application or by
   manual configuration.

   For regular constant-size audio data (e.g., G.723.1), it may be
   acceptable to entirely compress away all headers for most packets;
   only the RTP payload data for these packets would then be transmitted
   in a type 1 block.  Data from any packets that start a new talkspurt,
   as well as any packets that occur after a packet loss, would be
   preceded by a special block that provides a new value for timestamp
   and sequence number.  The decompressor can reconstruct the RTP
   information by, for each block, incrementing the sequence number by
   one and incrementing the timestamp by a negotiated frame period.
   This requires the compressor to resequence the packets in case of
   misordering.

   If detection of losses on the link is desired or if the compressor
   should not resequence the data, a single-byte modulo of the sequence
   number can be retained[5].

   For video data (e.g., H.263), the RTP marker bit is used to indicate
   end of frame; the next frame carries a different timestamp value.
   Since packets for video generally are variable-size, there is little
   problem in preceding them with a variable-length header that provides
   a short modulo of the sequence number, an end-of-frame bit, and a
   new-timestamp bit that, if on, is followed by a new timestamp value.

   Payload types, synchronization source, contributing sources etc., as
   well as IP/UDP level information can be negotiated in the compression
   table and/or sent as special blocks whenever their values change (and
   at a regular repetition rate [2]).

   For larger multipoint conferences, it may be worthwhile to include a
   number of IP source addresses and RTP source identifiers in the
   compression table and include an index into this table in the
   compressed RTP block.  An equivalent effect can be achieved, at the
_________________________
  [5] Note that this would be similar in effect  to  the  sequence
number  option available for audio (``AL2'') data in H.223, except
that it would be end-to-end.


Bormann                                                        [Page 21]


INTERNET-DProviding integrated services over low-bitrate links June 1996

   cost of a larger frame-composition table, by using multiple
   compression table indices.

   [As an internet-draft on IP/UDP/RTP compression is forthcoming, no
   additional work has been done on this section.]

















































Bormann                                                        [Page 22]


INTERNET-DProviding integrated services over low-bitrate links June 1996

D.  Strawman for an RSVP application announcement format

   The main purpose of the RSVP application announcement object is to
   give consenting peer data link layers license to apply compression
   methods that would be catastrophic for data other than RTP.  In
   addition, any options that influence end-to-end performance aspects
   (e.g., using reordering at compressors to save a sequence number
   byte) should be controlled by the RSVP application announcement.

   For certain scenarios, in particular during initial deployment, it
   may be useful to be able to configure peer data link layer
   implementations to apply certain heuristics to derive information
   that otherwise would be provided in RSVP application announcements.
   This generally should only be done near the user that might suffer if
   these heuristics are chosen incorrectly, e.g. on the data link that
   connects a user's PC to the Internet, giving the user the chance to
   reconfigure the stack in case of trouble.

   One possible way to represent information about the session to be
   compressed beyond that available in RSVP filter specs is provided by
   the SDP syntax.

































Bormann                                                        [Page 23]