As per Relevance of the word september, we have this rfc below:
Network Working Group C.
Request for Comments: 2687 Universitaet Bremen
Category: Standards Track September 1999
PPP in a Real-time Oriented HDLC-like
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
A companion document describes an architecture for
integrated services over low-bitrate links, such as modem lines,
B-channels, and sub-T1 links [1]. The main components of
architecture are: a real-time encapsulation format for
and synchronous low-bitrate links, a header compression
optimized for real-time flows, elements of negotiation protocols
between routers (or between hosts and routers), and
protocols used by applications to allow this negotiation to
place
This document proposes the suspend/resume-oriented solution for
real-time encapsulation format part of the architecture. The
approach is to start from the PPP Multilink fragmentation
[2] and its multi-class extension [5] and add suspend/resume in a
that is as compatible to existing hard- and firmware as possible
1.
As an extension to the "best-effort" services the Internet is well
known for, additional types of services ("integrated services")
support the transport of real-time multimedia information are
developed for, and deployed in the Internet
The present document defines the suspend/resume-oriented solution
the real-time encapsulation format part of the architecture.
described in more detail in the architecture document, a real-
encapsulation format is required as, e.g., a 1500 byte packet on
Bormann Standards Track [Page 1]
RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
28.8 kbit/s modem link makes this link unavailable for
transmission of real-time information for about 400 ms. This adds
worst-case delay that causes real-time applications to operate
round-trip delays on the order of at least a second --
for real-time conversation
A true suspend/resume-oriented approach can only be implemented on
type-1 sender [1], but provides the best possible delay
to this type of senders. The format defined in this document
also be of interest to certain type-2-senders that want to
the better bit-efficiency of this format as compared to [5].
format was designed so that it can be implemented by both type-1
type-2 receivers
1.1. Specification
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [8].
2.
The requirements for this document are similar to those listed
[5].
A suspend/resume-oriented solution can provide better worst-
latency than the pre-fragmenting-oriented solution defined in [5].
Also, as this solution requires a new encapsulation scheme, there
an opportunity to provide a slightly more efficient format
Predictability, robustness, and cooperation with PPP and
hard- and firmware installations are as important with suspend/
as with pre-fragmenting. A good suspend/resume solution
good performance even with type-2 receivers [1] and is able to
with PPP hardware such as async-to-sync converters
Finally, a partial non-requirement: While the format defined in
draft is based on the PPP multilink protocol ([2], also
as MP), operation over multiple links is in many cases not required
3. General
As in [5], the general approach is to start out from PPP
and add multiple classes to obtain multiple levels of suspension
However, in contrast to [5], more significant changes are required
be able to suspend the transmission of a packet at any point
inject a higher priority packet
Bormann Standards Track [Page 2]
RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
The applicability of the multilink header for suspend/resume
implementations is limited, as the "end" bit is in the
header, which is the wrong place for suspend/resume operation.
make a big packet suspendable, it must be sent with the "end"
off, and (unless the packet was suspended a small number of
before its end) an empty fragment has to be sent afterwards
"close" the packet. The minimum overhead for sending a
packet thus is twice the multilink header size (six bytes,
a compressed multilink protocol field) plus one PPP framing (
bytes). Each suspension costs another six bytes (not counting
overhead of the framing for the intervening packet).
Also, the existing multi-link header is relatively large; as
frequency of small high-priority packets increases, the
becomes significant
The general approach of this document is to start from PPP
with classes and provide a number of extensions to add
and reduce the overhead of using PPP Multilink for real-
transmission
This document introduces two new features
1) A compact fragment format and header,
2) a real-time frame format
4. The Compact Fragment
This section describes an optional multilink fragment format that
more optimized towards single-link operation and frequent
(type 1 senders)/a small fragment size (type 2 senders),
optional support for multiple links
When operating over a single link, the Multilink sequence number
used only for loss detection. Even a 12-bit sequence number
is larger than required for this application on most kinds of links
We therefore define the following compact multilink header
option with a three-bit sequence number
As, with a compact header, there is little need for sending
outside the multilink, we can provide an additional
mechanism for this format: the MP protocol identifier is not
with the compact fragment header. This obviously requires
negotiation (similar to the way address and control field
are negotiated), as well as a method for avoiding the bit
Bormann Standards Track [Page 3]
RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
0xFF (the first octet in an LCP frame before any LCP options
been negotiated), as the start of a new LCP negotiation
otherwise not be reliably detected
Figure 1: Compact Fragment
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
Having the least significant bit always be 1 helps with HDLC
that operate specially on least significant bits in HDLC addresses
(Initial bytes with the least significant bit set to zero are
for the extended compact fragment format, see next section.)
The R bit is the inverted equivalent of the B bit in the
multilink fragment formats, i.e. R = 1 means that this
resumes a packet previous fragments of which have been sent already
The following trick avoids the case of a header byte of 0xFF (
would mean R=1, sequence=7, and class=7): If the class field is
to 7, the R bit MUST never be set to one. I.e., class 7 frames
design cannot be suspended/resumed. (This is also the reason
sense of the B bit is inverted to an R bit in the compact
format -- class 7 would be useless otherwise, as a new packet
never be begun.)
As the sequence number is not particularly useful with the
field set to 7, it is used to distinguish eight more classes --
some minor additional complexity, the applicability of prefix
is significantly increased by providing more classes with
different elided prefixes
For purposes of prefix elision, the actual class number of a
is computed as follows
- If the class field is 0 to 6, the class number is 0 to 6,
- if the class field is 7 and the sequence field is 0 to 7,
class number is 7 to 14.
Bormann Standards Track [Page 4]
RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
As a result of this scheme, the classes 0 to 6 can be used
suspendable packets, and classes 7 to 14 (where the class field is 7
and the R bit must always be off) can be used for non-
high-priority classes, e.g., eight highly compressed voice streams
5. The Extended Compact Fragment
For operation over multiple links, a three-bit sequence number
rarely be sufficient. Therefore, we define an optional
compact fragment format. The option, when negotiated, allows
the basic compact fragment format and the extended compact
format to be used; each fragment indicates which format it is in
Figure 1: Extended Compact Fragment
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | seq LSB | class | 0 |
+---+---+---+---+---+---+---+---+
| sequence -- MSB | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
In the extended compact fragment format, the sequence number
composed of three least significant bits from the first octet of
fragment header and seven most significant bits from the
octet. (Again, the least significant bit of the second octet
always set to one for compatibility with certain HDLC chips.)
For prefix elision purposes, fragments with a class field of 7
use the basic format to indicate classes 7 to 14 and the
format to indicate classes 7 to 1030. Different classes may
different formats concurrently without problems. (This allows
classes to be spread over a multi-link and other classes to
confined to a single link with greater efficiency.) For class
0 to 6, i.e. suspendable classes, one of the two compact
formats SHOULD be used consistently within each class
If the use of the extended compact fragment format has
negotiated, receivers MAY keep 10-bit sequence numbers for
classes to facilitate senders switching formats in a class. When
sender starts sending basic format fragments in a class that
using extended format fragments, the 3-bit sequence number can
taken as a modulo-8 version of the 10-bit sequence number, and
discontinuity need result. In the inverse case, if a 10-bit
number has been kept throughout by the receiver (and no major
Bormann Standards Track [Page 5]
RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
of the sequence number have occurred), no discontinuity will result
although this cannot be guaranteed in the presence of errors
(Discontinuity, in this context, means that a receiver has
resynchronize sequence numbers by discarding fragments until
fragment with R=0 has been seen.)
6. Real-Time Frame
This section defines how fragments with compact fragment headers
mapped into real-time frames. This format has been designed
retain the overall HDLC based format of frames, so that
synchronous HDLC chips and async to sync converters can be used
the link. Note that if the design could be optimized for async
operation, more design alternatives would be available [4]; with
advent of V.80 style modems, asynchronous communications is likely
decrease in importance, though
The compact fragment format provides a compact rendition of the
multilink header with classes and a reduced sequence number space
However, it does not encode the E-bit of the PPP multilink header
which indicates whether the fragment at hand is the last fragment
a packet
For a solution where packets can be suspended at any point in time
the E-bit needs to be encoded near the end of each fragment.
real-time frame format, to ensure maximum compatibility with type 2
receivers, encodes the E-bit in the following way: Any normal
ending also ends the current fragment with E implicitly set to one
This ensures that packets that are ready for delivery to the
layers immediately trigger a receive interrupt even at type-2
receivers
Fragments of packets that are to be suspended are terminated
the HDLC frame by a special "fragment suspend escape" byte (FSE).
The overall structure of the HDLC frame does not change;
detection and handling of FSE bytes is done at a layer above
framing
The suspend/resume format with FSE detection is an alternative
address/control field compression (ACFC, LCP option 8). It does
apply to frames that start with 0xFF, the standard PPP-in-
address field; these frames are handled as defined in [6] and [7].
(This provision ensures that attempts to renegotiate LCP do not
ambiguities.)
Bormann Standards Track [Page 6]
RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
For frames that do not start with 0xFF, suspend/resume
performs a scan of every HDLC frame received. The FCS of the
frame is checked and stripped. Compact fragment format headers (
basic and extended) are handled without further FSE processing
(Note that, as the FSE byte was chosen such that it never occurs
compact fragment format headers, this does not require any
code.)
Within the remaining bytes of the HDLC frame ("data part"), an
byte is used to indicate the end of the current fragment, with an
bit implicitly cleared. All fragments up to the last FSE
considered suspended (E = 0); the final fragment is terminated (E =
1), or, if it is empty, ignored (i.e., the data part of an HDLC
can end in an FSE to indicate that the last fragment has E = 0).
Each fragment begins with a normal header, so the structure of
frame could be
Figure 2: Example frame with FSE
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
+ FSE + previous fragment implicitly E = 0
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
| Frame | previous fragment implicitly E = 1
| CRC |
+---+---+---+---+---+---+---+---+
The value chosen for FSE is 0xDE (this is a relatively unlikely
to occur in today's data streams, it does not trigger octet
and triggers bit stuffing only for 1/8 of the possible
bytes).
The remaining problem is that of data transparency. In the
described so far, an FSE is always followed by a compact
header. In these headers, the combination of a class field set to 7
Bormann Standards Track [Page 7]
RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
with R=1 is reserved. Data transparency is achieved by making
occurrence of an FSE byte followed by one of 0x8F, 0x9F, ... to 0
special
Figure 3: Data transparency with FSE bytes
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| R | sequence | class | 1 |
+---+---+---+---+---+---+---+---+
| data |
: :
+---+---+---+---+---+---+---+---+
+ FSE + fragment NOT
+---+---+---+---+---+---+---+---+
| R | S | T | U | 1 | 1 | 1 | 1 | R always is 1
+---+---+---+---+---+---+---+---+
| data | fragment
: :
In a combination of FSE/0xnF (where n is the first four-bit field
the second byte, RSTU in Figure 3), the n field gives a sequence
four bits indicating where in the received data stream FSE bytes
which cannot simply be transmitted in the data stream, are to
added by the receiver
0x8F: insert one FSE, back to
0x9F: insert one FSE, copy two data bytes, insert one FSE, back to
0xAF: insert one FSE, copy one data byte, insert one FSE, back to
0xBF: insert one FSE, copy one data byte, insert two FSE bytes,
to
0xCF: insert two FSE bytes, back to
0xDF: insert two FSE bytes, copy one data byte, insert one FSE,
to
0xEF: insert three FSE bytes, back to
0xFF: insert four FSE bytes, back to
The data bytes following the FSE/0xnF combinations and
to the zero bits in the N field may not be FSE bytes
This scheme limits the worst case expansion factor by FSE
to about 25 %. Also, it is designed such that a single data
can either trigger worst-case expansion by octet stuffing (or by
stuffing) or worst-case FSE processing, but never both. Figure 4
illustrates the scheme in a few examples; FSE/0xnF pairs are
in lower case
Bormann Standards Track [Page 8]
RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
Figure 4: Data transparency
Data stream FSE-stuffed
DD DE DF E0 DD de 8f DF E
01 DE 02 DE 03 01 de af 02 03
DE DA DE DE DB de bf DA
DE DE DE DE DE DA de ff de 8f
In summary, the real-time frame format is a HDLC-like frame
by flags and containing a final FCS as defined in [7], but
address and control fields, containing as data a sequence of FSE
stuffed fragments in compact fragment format, delimited by FSE bytes
As a special case, the final FSE may occur as the last byte of
data content (i.e. immediately before the FCS bytes) of the HDLC-
frame, to indicate that the last fragment in the frame is
and no final fragment is in the frame (e.g., because the
maximum size of the frame has been reached).
7. Implementation
7.1. MRU
The LCP parameter MRU defines the maximum size of the packets sent
the link. Async-to-sync converters that are monitoring the
negotiations on the link may interpret the MRU value as the
HDLC frame size to be expected
Implementations of this specification should preferably negotiate
sufficiently large MRU to cover the worst-case 25 % increase in
size plus the increase caused by suspended fragments. If that is
possible, the HDLC frame size should be limited by monitoring
HDLC frame sizes and possibly suspending the current fragment
sending an FSE with an empty final fragment (FSE immediately
by the end of the information field, i.e. by CRC bytes and a flag)
be able to continue in a new HDLC frame. This strategy also
minimizing the impact of lengthening the HDLC frame on the safety
the 16-bit FCS at the end of the HDLC frame
7.2. Implementing octet-stuffing and FSE processing in one
The simplest way to add real-time framing to an implementation may
to perform HDLC processing as usual and then, on the result,
perform FSE processing. A more advanced implementation may want
combine the two levels of escape character processing. Note
however, that FSE processing needs to wait until two bytes from
HDLC frame are available and followed by a third to ensure that
bytes are not the final HDLC FCS bytes, which are not subject to
Bormann Standards Track [Page 9]
RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
processing. I.e., on the reception of normal data byte, look for
FSE in the second-to-previous byte, and, on the reception of
frame-end, look for an FSE as the last data byte
8. Negotiable
The following options are already defined by MP [2]:
o Multilink Maximum Received Reconstructed
o Multilink Short Sequence Number Header
o Endpoint
The following options are already defined by MCML [5]:
o Multilink Header
o Prefix
This document defines two new code points for the Multilink
Format option
8.1. Multilink header format
The multilink header format option is defined in [5]. A summary
the Multilink Header Format Option format is shown below. The
are transmitted from left to right
Figure 5: Multilink header format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 27 | Length = 4 | Code | # Susp Clses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As defined in [5], this LCP option advises the peer that
implementation wishes to receive fragments with a format given
the code number, with the maximum number of suspendable classes (
below) given. This specification defines two additional values
Code, in addition to those defined in [5]:
- Code = 11: basic and extended compact real-time fragment
with classes, in FSE-encoded HDLC
- Code = 15: basic compact real-time fragment format with classes
in FSE-encoded HDLC
Bormann Standards Track [Page 10]
RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
An implementation MUST NOT request a combination of both
Address-and-Control-Field-Compression (ACFC) and the code values 11
or 15 for this option
The number of suspendable classes negotiated for the compact real
time fragment format only limits the use of class numbers that
suspending. As class numbers of 7 and higher do not
additional reassembly space, they are not subject to the class
limit negotiated
9. Security
Operation of this protocol is believed to be no more and no
secure than operation of the PPP multilink protocol [2].
with a small sequence number range increases the likelihood
fragments from different packets could be incorrectly
into one packet. While most such packets will be discarded by
receiver because of higher-layer checksum failures or
inconsistencies, there is an increase in likelihood that contents
packets destined for one host could be delivered to another host
Links that carry packets where this raises security
SHOULD use the extended sequence number range for multi-
packets
10.
[1] Bormann, C., "Providing Integrated Services over Low-
Links", RFC 2689, September 1999.
[2] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T
Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
1996.
[3] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
[4] Andrades, R. and F. Burg, "QOSPPP Framing Extensions to PPP",
Work in Progress
[5] Bormann, C., "The Multi-Class Extension to Multi-Link PPP",
2686, September 1999.
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
51, RFC 1661, July 1994.
[7] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51,
1662, July 1994.
Bormann Standards Track [Page 11]
RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
[8] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
11. Author's
Carsten
Universitaet Bremen FB3
Postfach 330440
D-28334 Bremen,
Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.
The participants in a lunch BOF at the Montreal IETF 1996 gave
input on the design tradeoffs in various environments.
Andrades, Fred Burg, and Murali Aravamudan insisted that there
be a suspend/resume solution in addition to the pre-fragmenting
defined in [5]. The members of the ISSLL subgroup on low
links (ISSLOW) have helped in coming up with a set of
that shaped this solution
Bormann Standards Track [Page 12]
RFC 2687 PPP in Real-time Oriented HDLC-like Framing September 1999
Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Bormann Standards Track [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
