draft-ietf-issll-isslow-mcml-00.txt   draft-ietf-issll-isslow-mcml-01.txt 
INTERNET-DRAFT Carsten Bormann INTERNET-DRAFT Carsten Bormann
Expires: March 1997 Universitaet Bremen Expires: September 1997 Universitaet Bremen
September 1996
The Multi-Class Extension to Multi-Link PPP The Multi-Class Extension to Multi-Link PPP
draft-ietf-issll-isslow-mcml-00.txt draft-ietf-issll-isslow-mcml-01.txt
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 1, line 42 skipping to change at page 1, line 40
A companion document describes an architecture for providing A companion document describes an architecture for providing
integrated services over low-bitrate links, such as modem lines, ISDN integrated services over low-bitrate links, such as modem lines, ISDN
B-channels, and sub-T1 links [1]. The main components of the B-channels, and sub-T1 links [1]. The main components of the
architecture are: a real-time encapsulation format for asynchronous architecture are: a real-time encapsulation format for asynchronous
and synchronous low-bitrate links, a header compression architecture and synchronous low-bitrate links, a header compression architecture
optimized for real-time flows, elements of negotiation protocols used optimized for real-time flows, elements of negotiation protocols used
between routers (or between hosts and routers), and announcement between routers (or between hosts and routers), and announcement
protocols used by applications to allow this negotiation to take protocols used by applications to allow this negotiation to take
place. place.
This document proposes the solution for the real-time encapsulation This document proposes the fragment-oriented solution for the real-
format part of the architecture. The general approach is to start time encapsulation format part of the architecture. The general
from the PPP Multilink fragmentation protocol [2] and provide a small approach is to start from the PPP Multilink fragmentation protocol
number of extensions to add functionality and reduce the overhead. [2] and provide a small number of extensions to add functionality and
reduce the overhead.
This document is a product of the IETF ISSLL working group. It is This document is a product of the IETF ISSLL working group.
also a submission to the IETF PPPEXT working group.
Comments are solicited and should be addressed to the two working Comments are solicited and should be addressed to the two working
groups' mailing lists at issll@mercury.lcs.mit.edu and ietf- groups' mailing lists at issll@mercury.lcs.mit.edu and ietf-
ppp@merit.edu and/or the author. ppp@merit.edu and/or the author.
1. Introduction 1. Introduction
As an extension to the ``best-effort'' services the Internet is well- As an extension to the ``best-effort'' services the Internet is well-
known for, additional types of services (``integrated services'') known for, additional types of services (``integrated services'')
that support the transport of real-time multimedia information are that support the transport of real-time multimedia information are
being developed for and deployed in the Internet. being developed for and deployed in the Internet.
skipping to change at page 2, line 22 skipping to change at page 2, line 22
A companion document describes an architecture for providing A companion document describes an architecture for providing
integrated services over low-bitrate links, such as modem lines, ISDN integrated services over low-bitrate links, such as modem lines, ISDN
B-channels, and sub-T1 links [1]. The main components of the B-channels, and sub-T1 links [1]. The main components of the
architecture are: a real-time encapsulation format for asynchronous architecture are: a real-time encapsulation format for asynchronous
and synchronous low-bitrate links, a header compression architecture and synchronous low-bitrate links, a header compression architecture
optimized for real-time flows, elements of negotiation protocols used optimized for real-time flows, elements of negotiation protocols used
between routers (or between hosts and routers), and announcement between routers (or between hosts and routers), and announcement
protocols used by applications to allow this negotiation to take protocols used by applications to allow this negotiation to take
place. place.
The present document defines the real-time encapsulation format part The present document defines the fragment-oriented solution for the
of the architecture. As described in more detail in the architecture real-time encapsulation format part of the architecture, i.e. for the
document, such a format is required as, e.g., a 1500 byte packet on a queues-of-fragments type sender [1]. As described in more detail in
28.8 kbit/s modem link makes this link unavailable for the the architecture document, a real-time encapsulation format is
transmission of real-time information for about 400 ms. This adds a required as, e.g., a 1500 byte packet on a 28.8 kbit/s modem link
worst-case delay that causes real-time applications to operate with makes this link unavailable for the transmission of real-time
round-trip delays on the order of at least a second -- unacceptable information for about 400 ms. This adds a worst-case delay that
for real-time conversation. causes real-time applications to operate with round-trip delays on
the order of at least a second -- unacceptable for real-time
conversation. The PPP extensions defined in this document allow a
sender to fragment the packets of various priorities into multiple
classes of fragments, allowing high-priority packets to be sent
between fragments of lower priorities.
A companion document based on these extensions [5] defines a
suspend/resume-oriented solution for those cases where the best
possible delay is required and the senders are of type 1 [1].
2. Requirements 2. Requirements
The main design goal for the components of an architecture that The main design goal for the components of an architecture that
addresses real-time multimedia flows over low-bitrate links is that addresses real-time multimedia flows over low-bitrate links is that
of minimizing the end-to-end delay. More specifically, the worst of minimizing the end-to-end delay. More specifically, the worst
case delay (after removing possible outliers, which are equivalent to case delay (after removing possible outliers, which are equivalent to
packet losses from an application point of view) is what determines packet losses from an application point of view) is what determines
the playout points selected by the applications and thus the delay the playout points selected by the applications and thus the delay
actually perceived by the user. actually perceived by the user.
skipping to change at page 3, line 13 skipping to change at page 3, line 21
a PPP link is the default MTU of 1500 bytes. The smallest high- a PPP link is the default MTU of 1500 bytes. The smallest high-
priority packets are likely to have on the order of 21 bytes priority packets are likely to have on the order of 21 bytes
(compressed RTP/G.723.1 packets). In the 1:72 range of packet sizes (compressed RTP/G.723.1 packets). In the 1:72 range of packet sizes
to be expected, this translates to a maximum requirement of about to be expected, this translates to a maximum requirement of about
eight levels of suspension (including one level where long real-time eight levels of suspension (including one level where long real-time
packets suspend long non-real-time packets). On 28.8kbit/s modems, packets suspend long non-real-time packets). On 28.8kbit/s modems,
there seems to be a practical requirement for at least two levels of there seems to be a practical requirement for at least two levels of
suspension (i.e., audio suspends any longer packet including video, suspension (i.e., audio suspends any longer packet including video,
video suspends other very long packets). video suspends other very long packets).
An on architectural level, there are several additional requirements On an architectural level, there are several additional requirements
for the fragmentation scheme: for the fragmentation scheme:
a) The scheme must be predictable enough that admission control can a) The scheme must be predictable enough that admission control can
make decisions based on its characteristics. As is argued in make decisions based on its characteristics. As is argued in
[1], this will often only be the case when additional hints [1], this will often only be the case when additional hints
about the characteristics of the flow itself are available about the characteristics of the flow itself are available
(application hints). (application hints).
b) The scheme must be robust against errors, at least with the same b) The scheme must be robust against errors, at least with the same
level of error detection as PPP. level of error detection as PPP.
c) The scheme must in general cooperate nicely with PPP. In c) The scheme must in general cooperate nicely with PPP. In
particular, it should be as compatible to existing PPP standards particular, it should be as compatible to existing PPP standards
as possible. On a link that (based on PPP negotiation) makes as possible. On a link that (based on PPP negotiation) makes
use of the scheme, it should always be possible to fall back to use of the scheme, it should always be possible to fall back to
standard LCP without ambiguity. standard LCP without ambiguity.
d) The scheme must work well with existing chips and router d) The scheme must work well with existing chips and router
systems. For synchronous links this means using HDLC framing; systems. (See [1] for a more extensive discussion of
with much existing hardware, it is also hard to switch off the implementation models.) For synchronous links this means using
HDLC per-frame CRC. For asynchronous links, there is much more HDLC framing; with much existing hardware, it is also hard to
freedom in design; on the other hand, a design that treats them switch off the HDLC per-frame CRC. For asynchronous links,
much different from asynchronous links would lose a number of there is much more freedom in design; on the other hand, a
desirable properties of PPP. design that treats them much different from synchronous links
would lose a number of desirable properties of PPP.
e) The scheme must be future proof. In particular, the emergence e) The scheme must be future proof. In particular, the emergence
of V.80 based modems may significantly change the way PPP is of V.80 based modems may significantly change the way PPP is
used with modems. used with modems.
The current draft does not address additional requirements that may The current draft does not address additional requirements that may
be relevant in conjunction with Frame Relay; however, there seems to be relevant in conjunction with Frame Relay; however, there seems to
be little problem in applying the principles of this draft to ``PPP be little problem in applying the principles of this draft to ``PPP
in Frame Relay'' [3]. in Frame Relay'' [3].
3. Implementation models 3. Using existing mechanisms
This section introduces a number of terms for types of
implementations that are likely to emerge. It is important to have
these different implementation models in mind as there is no single
approach that fits all models best.
3.1. Sender types
There are two fundamental approaches to real-time transmission on
low-bitrate links:
Sender type 1
The PPP real-time framing implementation is able to control the
transmission of each byte being transmitted with some known,
bounded delay (e.g., due to FIFOs). For example, this is
generally true of PC host implementations, which directly access
serial interface chips byte by byte or by filling a very small
FIFO. For type 1 senders, a suspend/resume type approach will
be typically used: When a long frame is to be sent, the attempt
is to send it undivided; only if higher priority packets come up
during the transmission will the lower-priority long frame be
suspended and later resumed. This approach allows the minimum
variation in access delay for high-priority packets; also,
fragmentation overhead is only incurred when actually needed.
Sender type 2
With type 2 senders, the interface between the PPP real-time
framing implementation and the transmission hardware is not in
terms of streams of bytes, but in terms of frames, e.g., in the
form of multiple (prioritized) send queues directly supported by
hardware. This is often true of router systems for synchronous
links, in particular those that have to support a large number
of low-bitrate links. As type 2 senders have no way to suspend
a frame once it has been handed down for transmission, they
typically will use a queues-of-fragments approach, where long
packets are always split into units that are small enough to
maintain the access delay goals for higher-priority traffic.
There is a trade-off between the variation in access delay
resulting from a large fragment size and the overhead that is
incurred for every long packet by choosing a small fragment
size.
3.2. Receiver types
Although the actual work of formulating transmission streams for
real-time applications is performed at the sender, the ability of the
receiver to immediately make use of the information received depends
on its characteristics:
Receiver type 1
Type 1 receivers have full control over the stream of bytes
received within PPP frames, i.e., bytes received are available
immediately to the PPP real-time framing implementation (with
some known, bounded delay e.g. due to FIFOs etc.).
Receiver type 2
With type 2 receivers, the PPP real-time framing implementation
only gets hold of a frame when it has been received completely,
i.e., the final flag has been processed (typically by some HDLC
chip that directly fills a memory buffer).
4. Using existing mechanisms Transmitting only part of a packet to allow higher-priority traffic
to intervene and resuming its transmission later on is a kind of
fragmentation. The purpose of this section is to examine existing
mechanisms that are available for packet fragmentation and, by
relating them to the requirements listed above, to outline their
areas and limits of applicability.
Suspending the transmission of packets and resuming their Fragmentation is existing functionality of the IP layer. As
transmission later on is a kind of fragmentation. Fragmentation is fragmentation and reassembly also are useful in a logical link
existing functionality of the IP layer. As fragmentation and composed of multiple physical links, PPP Multilink (a standards track
reassembly also are useful in a logical link composed of multiple protocol) already defines a fragmentation mechanism [2].
physical links, PPP Multilink (a standards track protocol) already Unfortunately, neither approach, as is, fulfills all the requirements
defines a fragmentation mechanism [2]. Unfortunately, neither listed above.
approach, as is, fulfills all the requirements listed above.
4.1. Using IP fragmentation 3.1. Using IP fragmentation
An IPv4 header already contains fields that allow a large IP datagram An IPv4 header already contains fields that allow a large IP datagram
to be fragmented into small parts. A queues-of-fragments type sender to be fragmented into small parts. A queues-of-fragments type sender
might simply indicate a small MTU to its IP stack and thus cause all [1] might simply indicate a small MTU to its IP stack and thus cause
larger datagrams to be fragmented down to a size that allows the all larger datagrams to be fragmented down to a size that allows the
access delay goals to be met[1]. (Also, a PPP implementation can access delay goals to be met[1]. (Also, a PPP implementation can
negotiate down the MTU of its peer, causing the peer to fragment to a negotiate down the MTU of its peer, causing the peer to fragment to a
small size, which might be considered a crude form of negotiating an small size, which might be considered a crude form of negotiating an
access delay goal with the peer system -- if that system supports access delay goal with the peer system -- if that system supports
priority queueing at the fragment level.) priority queueing at the fragment level.)
Unfortunately, a full, 20 byte IP header is needed for each fragment Unfortunately, a full, 20 byte IP header is needed for each fragment
(larger when IP options are used). This limits the minimum size of (larger when IP options are used). This limits the minimum size of
fragment that can be used without too much overhead. (Also, the size fragment that can be used without too much overhead. (Also, the size
of non-final fragments must be a multiple of 8, further limiting the of non-final fragments must be a multiple of 8 bytes, further
choice.) With path MTU discovery, IP level fragmentation causes TCP limiting the choice.) With path MTU discovery, IP level
implementations to use small MSSs -- this further increases the per- fragmentation causes TCP implementations to use small MSSs -- this
packet overhead to 40 bytes per fragment. further increases the per-packet overhead to 40 bytes per fragment.
In any case, fragmentation at the IP level persists on the path In any case, fragmentation at the IP level persists on the path
further down to the datagram receiver, increasing the transmission further down to the datagram receiver, increasing the transmission
overheads and router load throughout the network. With its high overheads and router load throughout the network. With its high
overhead and the adverse effect on the Internet, IP level overhead and the adverse effect on the Internet, IP level
fragmentation can only be a stop-gap mechanism when no other fragmentation can only be a stop-gap mechanism when no other
fragmentation protocol is available in the peer implementation. fragmentation protocol is available in the peer implementation.
4.2. Using PPP Multilink as-is
The PPP Multilink Protocol (MP) provides for sequence numbering and
begin/end bits, allowing packets to be split into fragments.
_________________________ _________________________
[1] This assumes that the IP stack is able to priority-tag frag- [1] This assumes that the IP stack is able to priority-tag frag-
ments, or that the PPP implementation is able to correlate the ments, or that the PPP implementation is able to correlate the
fragments to the initial one that carries the information relevant fragments to the initial one that carries the information relevant
for prioritizing, or that only initial fragments can be high- for prioritizing, or that only initial fragments can be high-
priority. priority.
3.2. Using PPP Multilink as-is
The PPP Multilink Protocol (MP) provides for sequence numbering and
begin/end bits, allowing packets to be split into fragments.
Figure 1: Multilink Short Sequence Number Fragment Format [2] Figure 1: Multilink Short Sequence Number Fragment Format [2]
+---------------+---------------+ +---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 | PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+ +---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d | | PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-------+---------------+ +-+-+-+-+-------+---------------+
MP Header: |B|E|0|0| sequence number | MP Header: |B|E|0|0| sequence number |
+-+-+-+-+-------+---------------+ +-+-+-+-+-------+---------------+
| fragment data | | fragment data |
skipping to change at page 6, line 37 skipping to change at page 5, line 42
sending a sequence of fragments of one packet for sending another sending a sequence of fragments of one packet for sending another
packet. It is, however, possible to send intervening packets that packet. It is, however, possible to send intervening packets that
are not encapsulated in multilink headers; thus, MP supports two are not encapsulated in multilink headers; thus, MP supports two
levels of priority. levels of priority.
The multilink-as-is approach can be built using existing standards; The multilink-as-is approach can be built using existing standards;
multilink capability is now widely deployed and only the sending side multilink capability is now widely deployed and only the sending side
needs to be aware that they are using this for giving priority to needs to be aware that they are using this for giving priority to
real-time packets. real-time packets.
4.3. Limitations of multilink as-is 3.3. Limitations of multilink as-is
Multilink-as-is is not the ideal solution for a number of reasons. Multilink-as-is is not the complete solution for a number of reasons.
First, because of the single monotonically increasing serial number, First, because of the single monotonically increasing serial number,
there is only one level of suspension: ``Big'' packets that are sent there is only one level of suspension: ``Big'' packets that are sent
via multilink can be suspended by ``small'' packets sent outside of via multilink can be suspended by ``small'' packets sent outside of
multilink; the latter are not suspendable. multilink; the latter are not fragmentable.
Second, the ``end'' bit is in the multilink header, which is the
wrong place for suspend/resume type senders. 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 suspendable 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).
Third, the multi-link header is relatively large; as delay bounds A problem not solved by this specification is that the multi-link
become small (for queues-of-fragments type implementations) or the header is relatively large; as delay bounds become small (for queues-
frequency of small high-priority packets increases (for of-fragments type implementations) the overhead may become
suspend/resume type implementations), the overhead may become
significant. significant.
The general approach of this document is to start from PPP Multilink The general approach of this document is to start from PPP Multilink
and provide a number of extensions to add functionality and reduce and provide a number of extensions to add functionality and reduce
the overhead of using PPP Multilink for real-time transmission. the overhead of using PPP Multilink for real-time transmission.
5. Extending PPP Multilink to multiple classes 4. Extending PPP Multilink to multiple classes
The obvious approach to providing more than one level of suspension The obvious approach to providing more than one level of suspension
with PPP Multilink is to run Multilink multiple times over one link. with PPP Multilink is to run Multilink multiple times over one link.
Multilink as it is defined provides no way for more than one instance Multilink as it is defined provides no way for more than one instance
to be active. Fortunately, a number of bits are unused in the to be active. Fortunately, a number of bits are unused in the
Multilink header: two bits in the short sequence number format (as Multilink header: two bits in the short sequence number format (as
can be seen in Figure 1), six in the long sequence number format. can be seen in Figure 1), six in the long sequence number format.
This document defines (some of the) previously unused bits as a class This document defines (some of the) previously unused bits as a class
number: number:
skipping to change at page 8, line 31 skipping to change at page 7, line 31
PPP FCS: | FCS | PPP FCS: | FCS |
+---------------+---------------+ +---------------+---------------+
Together with the ability to send packets without a multilink header, Together with the ability to send packets without a multilink header,
this provides four levels of suspension with 12-bit headers (probably this provides four levels of suspension with 12-bit headers (probably
sufficient for many practical applications) and sixteen levels with sufficient for many practical applications) and sixteen levels with
24-bit headers (only four of the six free bits are used in this case 24-bit headers (only four of the six free bits are used in this case
-- based on the rationale given above, sixteen levels should -- based on the rationale given above, sixteen levels should
generally be more than sufficient). generally be more than sufficient).
6. Sending the final bit at the end of the packet 5. Prefix elision: Compressing common header bytes
As explained above, having the ``end'' bit within the packet header
causes additional overhead with suspend/resume type senders. This
section defines an alternative way to convey the end bit that allows
deferring the decision whether the fragment is final or needs to be
suspended to the point in time when the fragment is ended.
In this scheme, the value of the end bit is contained in the last
byte of each frame information field. If the byte has the value
SUSPEND (0xC3), the end bit is zero (i.e., the fragment is not the
last one of the packet); the byte is NOT part of the data of the
packet. If the byte has the value END (0xDE), the end bit is one
(i.e., this is the last fragment of the packet); the byte is NOT part
of the data of the packet. If the byte has any other value, the end
bit is one (i.e., this is the last fragment of the packet); the byte
IS part of the data of the fragment. (Assuming an equal distribution
of final bytes[2], the average overhead of this scheme for non-
_________________________
[2] Actually, the distribution is not at all equal: In a trace
of slightly more than a million packets on a busy Ethernet, the
values 0xDE and 0xC3 both occurred only 244 times as the last byte
of a packet. Obviously, the distribution will not be as unequal
when data compression and/or encryption are in use.
suspended frames is 1/128 byte; the overhead for suspended frames is
exactly 1 byte.)
As the end bit is then no longer required in the header, the free bit
can be used as an additional bit for the class number in the short
sequence number fragment format:
Figure 4: Short Sequence Number Fragment Format With Classes and
Trailing End Bit
+---------------+---------------+
PPP Header: | Address 0xff | Control 0x03 |
+---------------+---------------+
| PID(H) 0x00 | PID(L) 0x3d |
+-+-+-+-+-------+---------------+
MP Header: |B|class| sequence number |
+-+-+-+-+-------+---------------+
| fragment data |
| . |
| . |
| . |
| ................+
| . SSP/TRM (opt) :
+---------------+---------------+
PPP FCS: | FCS |
+---------------+---------------+
For the long sequence number fragment format, the freed bit is sent
as zero.
7. Prefix elision: Compressing common header bytes
For some applications, all packets of a certain class will have a For some applications, all packets of a certain class will have a
common protocol identifier (or even more than one common prefix common protocol identifier (or even more than one common prefix
byte). In this case, the following optimization is possible: the byte). In this case, the following optimization is possible: the
class number can be associated with a prefix of bytes that are class number can be associated with a prefix of bytes that are
removed from each packet before transmission and that are implicitly removed from each packet before transmission and that are implicitly
prepended to the reassembled packet after reception. prepended to the reassembled packet after reception.
Note that if only some of the packets to be transmitted at a certain Note that if only some of the packets to be transmitted at a certain
level of priority have the common prefix, it may still be possible to level of priority have the common prefix, it may still be possible to
utilize this method by allocating two class numbers and only utilize this method by allocating two class numbers and only
associating one of them with the prefix. (This is the reason four of associating one of them with the prefix. (This is the reason why
the unused bits in the long sequence number format have been four of the unused bits in the long sequence number format have been
allocated to the class number instead of the three that generally allocated to the class number instead of the three that generally
should suffice.) should suffice.)
Prefix elision is not a replacement for header compression or data Prefix elision is not a replacement for header compression or data
compression: it allows to compress away prefixes that often are not compression: it allows to compress away prefixes that often are not
reachable by these other methods. reachable by these other methods.
8. The compact fragment format 6. Negotiable options
This section describes an optional multilink fragment format that is
more optimized towards single-link operation and frequent suspension
(type 1)/a small fragment size (type 2). This format has been
designed to retain the overall HDLC based format of frames, so that
existing synchronous HDLC chips and async to sync converters can be
used on the link. If the design can be optimized for async only
operation, more design alternatives are available [4]; with the
advent of V.80 style modems, asynchronous communications may decrease
in importance, though.
When operating over a single link, the Multilink sequence number is
used only for loss detection. Even a 12-bit sequence number clearly
is larger than required for this application on most kinds of links.
We therefore define a third, compact multilink header format option.
As, with a compact header, we can expect all packets to be sent over
the multilink, we can provide an additional compression mechanism for
this format: the MP protocol identifier is not sent with the compact
fragment header. This obviously requires prior negotiation (similar
to the way address and control field compression are negotiated), as
well as avoiding the bit combination 0xFF, as the start of a new LCP
negotiation could otherwise not be reliably detected.
9. Normal header:
Figure 5: Compact Fragment Format (Normal Header).
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+...............................+
: SUSPEND/TERMINATE :
+---+---+---+---+---+---+---+---+
| Frame |
| CRC |
+---+---+---+---+---+---+---+---+
Having the last bit always be 1 helps with HDLC chips that operate
specially on least significant bits in HDLC addresses.
The R bit is the inverted equivalent of the B bit in the other
fragment formats, i.e. R = 1 means that this fragment resumes a
packet previous fragments of which have been sent already.
The following trick avoids the case of a header byte of 0xFF: For
class 7, the R bit can never be one. This means that class 7 frames
cannot be suspended/resumed. (This is also the reason the sense of
the B bit is inverted to an R bit in the compact fragment format.)
[[[The sequence number is not particularly useful with class 7 and
could be used to distinguish eight more classes -- this would add
complexity but also increase the usefulness of prefix elision. The
author currently does not see a strong requirement for this.]]]
10. Insertion header:
In many cases, when a frame is suspended, a very short frame is
interspersed and the suspended frame is then immediately continued.
In certain cases, it may be beneficial to further reduce the overhead
associated with this by removing the intermediate flag(s) and
replacing the 16-bit (or larger) CRC by a smaller CRC.
If the compact fragment format with insertion headers is negotiated,
a frame in the compact fragment format can start with the content of
one or more short packets, called ``insertions''. Each of these
packets is protected by an 8-bit CRC, computed over the insertion
header byte and the data part sent in the insertion. At the end of
the insertion, no flag is sent, but another (insertion or normal)
header follows immediately. The frame finally ends in a normal
header, data for this header, and a frame CRC that covers the entire
of all inserted and normal packets. Alternatively, the frame can
simply be ended after an inserted packet by sending the frame CRC and
terminating flag(s).
Figure 6: Compact Fragment Format (Insertion Header).
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| length L | C | 0 |
+---+---+---+---+---+---+---+---+
: :
: Inserted packet :
: (length L) :
: :
+---+---+---+---+---+---+---+---+
| 8-bit CRC |
+---+---+---+---+---+---+---+---+
| next header |
: (insertion or normal) :
: (possibly repeated) :
+---+---+---+---+---+---+---+---+
| Frame CRC (covering all |
| all data between the flags) |
+---+---+---+---+---+---+---+---+
The class number of a packet in the insertion is computed from the C-
bit as ``class = C + 8'', i.e., we reserve classes 8 and 9 for
inserted packets. As an example, one could use class number 8 for
compressed RTP (saving one or two additional bytes with prefix
elision) and 9 for any other packet type. (Note that, as with class
7, classes 8 and 9 cannot be suspended, as there is no way to
indicate suspension or resumption.)
Since not all serial hardware can immediately deliver initial parts
of frames that have not yet completely arrived (see ``type 2
receivers'' in section 3 above), the use of the insertion header may
be counter-productive in achieving latency goals; it therefore can be
negotiated separately from the use of the normal compact header..
Also, because the initial byte of the HDLC frame has a zero LSB, this
format may not be applicable if chips are used that do strange things
with the last bit of address field bytes.
Implementation note: A sender should not send too many insertions
before a normal header fragment in one frame, as the overall
reliability of the actual data part of the frame (as indicated by the
frame CRC) suffers.
11. Negotiable options
The following options are already defined by MP: The following options are already defined by MP:
o Multilink Maximum Received Reconstructed Unit o Multilink Maximum Received Reconstructed Unit
o Multilink Short Sequence Number Header Format o Multilink Short Sequence Number Header Format
o Endpoint Discriminator o Endpoint Discriminator
11.1. Multilink header format option This document defines two new options:
o Multilink Header Format
o Prefix Elision
6.1. Multilink header format option
A summary of the Multilink Header Format Option format is shown A summary of the Multilink Header Format Option format is shown
below. The fields are transmitted from left to right. below. The fields are transmitted from left to right.
Figure 7: Figure 4:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 3 | Code | | Type = TBD | Length = 3 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This option advises the peer that the implementation wishes to This option advises the peer that the implementation wishes to
receive fragments with a format given by the code number. By receive fragments with a format given by the code number. By
default, long sequence number multilink headers without classes and default, long sequence number multilink headers without classes are
the end bit in the header are used. When this option is received, an used. When this option is received, an implementation MUST either
implementation MUST either transmit all subsequent multilink packets transmit all subsequent multilink packets on all links of the bundle
on all links of the bundle with the multilink header format given or with the multilink header format given or configure-NAK or configure-
configure-NAK or configure-Reject the option. Reject the option.
The value defined for code are:
- 0 or option not present: long sequence number fragment format
- 2: long sequence number fragment format with classes
- 3: long sequence number fragment format with classes and
trailing end bit
- 4 or Short Sequence Number Header Format Option (type 18) The values defined for the use of this option are:
present: short sequence number fragment format
- 6: short sequence number fragment format with classes - Neither this option nor the Short Sequence Number Header Format
Option (type 18) [2] is present: long sequence number fragment
format
- 7: short sequence number fragment format with classes and - This option present with code = 2: long sequence number fragment
trailing end bit format with classes
- 11: compact fragment format (always with classes and trailing - Short Sequence Number Header Format Option (type 18) present:
end bit) with normal header only short sequence number fragment format
- 15: compact fragment format (always with classes and trailing - This option present with code = 6: short sequence number
end bit) with normal and insertion headers fragment format with classes
[[[Note for further discussion: The number of alternatives is too An implementation MUST NOT request a combination of both the Short
large. The variations possible should be restricted to have a good Sequence Number Header Format Option and this option.
chance that two peer implementations have one option in common.]]]
11.2. Prefix elision option 6.2. Prefix elision option
This option advises the peer that the implementation wishes to send This option advises the peer that the implementation wishes to send
only packets with a certain prefix in each of the given classes; the only packets with a certain prefix in each of the given classes; the
prefix is not sent as part of the information in the fragment(s) of prefix is not sent as part of the information in the fragment(s) of
this class. By default, this common prefix is empty for all classes. this class. By default, this common prefix is empty for all classes.
When this option is received, an implementation MUST either add the When this option is received, an implementation MUST either add the
prefix given for the class to all subsequently received multilink prefix given for the class to all subsequently received multilink
packets of each of the given classes on all links of the bundle or packets of each of the given classes on all links of the bundle or
configure-NAK or configure-Reject the option. configure-NAK or configure-Reject the option.
If one of the formats with classes has not been negotiated, class 0 If none of the formats with classes has been negotiated, class 0 is
is used to indicate a common prefix for all packets sent within used to indicate a common prefix for all packets sent within
multilink fragments. multilink fragments.
Figure 8: Figure 5:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Option Length | Class | Prefix Length | | Type = TBD | Option Length | Class | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix... | Prefix...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Note that the sense of this option is an indication from the sender
to the receiver, unlike most PPP options that indicate capabilities NOTA BENE: the sense of this option is an indication from the sender
to the receiver, UNLIKE most PPP options that indicate capabilities
of the receiver to the sender. of the receiver to the sender.
12. Acknowledgements 7. Acknowledgements
David Oran suggested using PPP Multilink for real-time framing and David Oran suggested using PPP Multilink for real-time framing and
reminded the author of his earlier attempts of making Multilink more reminded the author of his earlier attempts of making Multilink more
useful for this purpose. The participants in a lunch BOF at the useful for this purpose. The participants in a lunch BOF at the
Montreal IETF gave useful input on the design tradeoffs in various Montreal IETF gave useful input on the design tradeoffs in various
environments. environments. The members of the ISSLL subgroup on low bitrate links
(ISSLOW) have helped reducing the large set of options that initial
versions of this draft had.
13. References 8. References
[1] C. Bormann, Providing integrated services over low-bitrate [1] C. Bormann, Providing integrated services over low-bitrate
links, work in progress (draft-ietf-issll-isslow-00.txt), June links, work in progress (draft-ietf-issll-isslow-01.txt),
1996. February 1997.
[2] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The [2] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The
PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes
RFC1717). RFC1717).
[3] W. Simpson, ``PPP in Frame Relay'', RFC 1973, June 1996. [3] W. Simpson, ``PPP in Frame Relay'', RFC 1973, June 1996.
[4] R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'', [4] R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'',
September 20, 1996, Work in Progress (draft-andrades-framing- September 20, 1996, Work in Progress (draft-andrades-framing-
ext-00.txt). ext-00.txt).
14. Addresses [5] C. Bormann, ``PPP in a real-time oriented HDLC-like framing,
internet Draft draft-ietf-issll-isslow-rtf-00.txt, Work in
Progress, March 1997.
14.1. Working Group 9. Addresses
9.1. Working Group
The ISSLL working group can be contacted via the co-chairs, Eric The ISSLL working group can be contacted via the co-chairs, Eric
Crawley <esc@baynetworks.com> and John Wroclawski <jtw@lcs.mit.edu>, Crawley <esc@baynetworks.com> and John Wroclawski <jtw@lcs.mit.edu>,
or via its WG mailing list <issll@mercury.lcs.mit.edu>. or via its WG mailing list <issll@mercury.lcs.mit.edu>.
14.2. Author's address 9.2. Author's address
Carsten Bormann Carsten Bormann
Universitaet Bremen FB3 TZI Universitaet Bremen FB3 TZI
Postfach 330440 Postfach 330440
D-28334 Bremen, GERMANY D-28334 Bremen, GERMANY
cabo@informatik.uni-bremen.de cabo@tzi.uni-bremen.de
phone +49.421.218-7024 phone +49.421.218-7024
fax +49.421.218-7000
A. Benchmarks
For the following considerations, we will define the ``normal'' PPP
header overhead to be four bytes: one byte of protocol identifier
(assuming address and control field compression as well as the use of
protocols that have protocol identifiers that can be compressed to
one byte), two bytes of CRC and one byte of flag. These assumptions
are not entirely accurate, as the protocol identifier and the CRC are
subject to bit- or octet-stuffing, slightly increasing the overhead.
In addition, many of the synchronous serial chips used today cannot
easily output frames that are delimited by only a single flag byte.
Just sending two packets sequentially using standard encapsulation
thus costs 8 bytes:
Pid1 . . . 2*CRC Flag Pid2 . . . 2*CRC Flag
Basic 12-bit multilink adds 3 bytes of header overhead to each
packet, as well as six bytes (the same three bytes plus four bytes
normal PPP overhead, minus the protocol identifier) to each
additional fragment.
MPPid 2*MPH Pid . . . 2*CRC Flag
Pid . . . 2*CRC Flag
MPPid 2*MPH . . . 2*CRC Flag
Being able to insert a real-time frame into a long packet
encapsulated in basic multilink therefore requires 9 more bytes of
overhead than just sending the two packets sequentially using
standard encapsulation. The six-byte overhead will generally recur
for longer packets, as the final bit is in the packet header and thus
at least one additional fragment (zero length, just to carry the
final bit) is required.
12-bit multilink with classes does not change the overhead at the top
level of priorities, unless the header prefix option is used and is
useful (i.e., only a small number of PPP protocol identifiers is in
use). In that case, 1 byte of overhead is saved per low-priority
packet.
The compact header reduces the additional per-packet overhead to 1
byte (or 0 bytes if the header prefix option is effective). The
total additional overhead for the insertion of a real-time frame thus
is only 6 to 4 bytes, if the special insertion header cannot be used.
NH [Pid] . . . 2*CRC Flag
NH [Pid] . . . 2*CRC Flag
NH . . . 2*CRC Flag
If the insertion header can be used, the additional overhead is
reduced by two more bytes, i.e., 4 to 2 bytes (of which one is the
block check byte).
NH [Pid] . . . 2*CRC Flag
IH [Pid] . . . 1*CRC NH . . . 2*CRC Flag
H.223 achieves even better numbers by using a per-packet CRC only (2
bytes saved) and, in the best case that the inserted packet is of a
repetitive length that has been defined in the multiplex table, a
common header for both elements of the second frame (1 more byte
saved). The first saving does not seem to be practical with many
current synchronous chips (although it could be made an option, in
particular for asynchronous applications -- some way would have to be
found to protect the compact header then, though); the second saving
is dubious in a more dynamic, multiple-packet-stream environment.
B. Usage Scenarios
Scenario: Two low-bitrate links are in the path between two internet
telephones that use G.723.1 compression for 20 byte audio packets (as
per G.723.1), with C-RTP headers of 2 bytes. These are repeated
every 30 ms.
To simplify the calculations, background traffic consists of a
continuous, infinite length packet. For packet size distributions
found in actual use, the resulting numbers would be more favorable to
compact headers.
For the compact header, the PPP overhead is four bytes; for insertion
headers, it is two bytes; in both cases, any packet that was
interrupted needs to be resumed with an additional overhead of four
bytes. For the 12-bit header without classes, the PPP overhead for
the audio frames also is four bytes; the overhead per fragment of
other data is six bytes.
As an rather lenient performance requirement, we allow a round-trip
delay budget of 300 ms (note that investigations show that this delay
already significantly reduces the mean opinion score). Of the 150 ms
available per path, 70 ms are reserved for delays in the rest of the
path, so 40 ms is the delay budget per link; we neglect transmission
delays. (If better values than 70 ms in the network become
realistic, it is likely that one would want to reduce the overall
delay instead of allocating more of it to the low-speed links).
B.1. GSM Scenario (9600 bit/s)
We assume a transparent, full-duplex 9600 bit/s link as could be
found on a full rate traffic channel in the GSM mobile phone system.
For these considerations, we ignore the additional delays that are
encountered in the air interface and its interleaving mechanisms.
At 1200 bytes per second, a maximum of 36 bytes can be transmitted
per 30 ms; note that for 22 bytes of payload at 1200 byte/s, about 20
ms of the 40 ms delay budget are already taken for the actual sending
of the packet. A regular fragmentation schedule would therefore have
to operate in 20 ms units, at about 24 bytes per fragment (of which
six are taken for fragmentation overhead -- an efficiency of about 75
%). At 1200 bytes per second, the load during a talkspurt is 26/1200
seconds every 30 ms, i.e., 22 ms every 30 ms; the capacity remaining
for data is about 170 byte/s.
It is obvious that an efficient fragmentation mechanism is required
to allow significant data to flow during talkspurts. With insertion
headers, the overhead per packet can be limited to 6 bytes, leaving
room for 8 bytes of actual data per 30 ms, or 270 byte/s.
Note that, as the access delay is very small with a suspend/resume
mode, part of the delay budget could be used by the application for
assembling two G.723.1 frames into one packet (at 40 + 2 C-RTP
bytes); there is then room for 24 bytes of non-audio data per 60 ms,
or 400 byte/s.
B.2. V.34 Modem scenario (24000 to 28800 bit/s)
We assume a link speed of 3000 byte/s as not all V.34 modem
communication reaches the full speed of 3600 byte/s (28800 bit/s).
At this speed, the transmission of 22 bytes of audio payload takes
about 8 ms, so about 32 ms of the 40 ms link delay budget is
available for access delay. With a regular fragmentation schedule
based on 12-bit headers, this allows a fragment size of 90 bytes plus
6 bytes of fragment overhead, i.e. about 7 % loss due to
fragmentation. As 26 out of the 90 bytes that can be sent in 30 ms
are used for the audio packets, an average of 64/96 such 90 byte
fragments can be sent per 30 ms, leading to a remaining data
throughput of about 2000 byte/s.
With compact headers (including the insertion option) and
suspend/resume operation, the audio information can be sent using
only two bytes of overhead per audio packet, leaving 66 of the 90
bytes that can be sent in 30 ms to data packets, of which four bytes
is lost to PPP overhead, resulting in a remaining data throughput of
about 2070 byte/s. If the application makes use of the reduced
jitter of suspend/resume by combining two audio packets into one, 136
of 180 bytes that can be sent in 60 ms are available to data packets,
of which, again, four bytes is lost to PPP overhead, resulting in a
remaining data throughput of about 2200 byte/s.
B.3. ISDN scenario (56000 to 64000 bit/s)
We assume a link speed of 7000 (US) to 8000 (non-US) byte/s. For a
regular fragmentation schedule, similar calculations lead to a
fragment size of 260 to 300 bytes, for about 2 % of fragmentation
overhead. The approximate numbers resulting for remaining data
throughput, based on 64 kbit/s (8000 byte/s) are: 7000 byte/s for a
regular schedule of 300 byte fragments, 7070 byte/s for compact
headers, and 7200 byte/s for compact headers making use of double
size packets.
 End of changes. 45 change blocks. 
345 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/