One document matched: draft-ietf-issll-isslow-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 12:25:26 |