draft-ietf-issll-isslow-mcml-05.txt   rfc2686.txt 
INTERNET-DRAFT Carsten Bormann Network Working Group C. Bormann
Expires: October 1999 Universitaet Bremen TZI Request for Comments: 2686 Universitaet Bremen TZI
April 1999 Category: Standards Track September 1999
The Multi-Class Extension to Multi-Link PPP The Multi-Class Extension to Multi-Link PPP
draft-ietf-issll-isslow-mcml-05.txt
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Status of this Memo
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 This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet- Drafts as reference improvements. Please refer to the current edition of the "Internet
material or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (1999). All Rights Reserved.
http://www.ietf.org/shadow.html
Abstract Abstract
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
skipping to change at page 2, line 7 skipping to change at page 1, line 41
place. place.
This document proposes the fragment-oriented solution for the real- This document proposes the fragment-oriented solution for the real-
time encapsulation format part of the architecture. The general time encapsulation format part of the architecture. The general
approach is to start from the PPP Multilink fragmentation protocol approach is to start from the PPP Multilink fragmentation protocol
[2] and provide a small number of extensions to add functionality and [2] and provide a small number of extensions to add functionality and
reduce the overhead. reduce the overhead.
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
that support the transport of real-time multimedia information are support the transport of real-time multimedia information are being
being developed for, and deployed in the Internet. developed for, and deployed in the Internet.
The present document defines the fragment-oriented solution for the The present document defines the fragment-oriented solution for the
real-time encapsulation format part of the architecture, i.e. for the real-time encapsulation format part of the architecture, i.e. for the
queues-of-fragments type sender [1]. As described in more detail in queues-of-fragments type sender [1]. As described in more detail in
the architecture document, a real-time encapsulation format is the architecture document, a real-time encapsulation format is
required as, e.g., a 1500 byte packet on a 28.8 kbit/s modem link required as, e.g., a 1500 byte packet on a 28.8 kbit/s modem link
makes this link unavailable for the transmission of real-time makes this link unavailable for the transmission of real-time
information for about 400 ms. This adds a worst-case delay that information for about 400 ms. This adds a worst-case delay that
causes real-time applications to operate with round-trip delays on causes real-time applications to operate with round-trip delays on
the order of at least a second -- unacceptable for real-time the order of at least a second -- unacceptable for real-time
skipping to change at page 2, line 34 skipping to change at page 2, line 22
between fragments of lower priorities. between fragments of lower priorities.
A companion document based on these extensions [5] defines a A companion document based on these extensions [5] defines a
suspend/resume-oriented solution for those cases where the best suspend/resume-oriented solution for those cases where the best
possible delay is required and the senders are of type 1 [1]. possible delay is required and the senders are of type 1 [1].
1.1. Specification Language 1.1. Specification Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119 [8].
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 32 skipping to change at page 3, line 26
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 (PPP Link Control Protocol [6, 7]) 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. (See [1] for a more extensive discussion of systems. (See [1] for a more extensive discussion of
implementation models.) For synchronous links this means using implementation models.) For synchronous links this means using
HDLC framing; with much existing hardware, it is also hard to HDLC framing; with much existing hardware, it is also hard to
switch off the HDLC per-frame CRC. For asynchronous links, switch off the HDLC per-frame CRC. For asynchronous links,
there is much more freedom in design; on the other hand, a there is much more freedom in design; on the other hand, a
design that treats them much different from synchronous links design that treats them much different from synchronous links
would lose a number of desirable properties of PPP. 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.
This document does not address additional requirements that may be This document 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 document to ``PPP little problem in applying the principles of this document to "PPP in
in Frame Relay'' [3]. Frame Relay" [3].
3. Using PPP Multilink as-is 3. Using PPP Multilink as-is
Transmitting only part of a packet to allow higher-priority traffic Transmitting only part of a packet to allow higher-priority traffic
to intervene and resuming its transmission later on is a kind of to intervene and resuming its transmission later on is a kind of
fragmentation. The existing PPP Multilink Protocol (MP, [2]) fragmentation. The existing PPP Multilink Protocol (MP, [2])
provides for sequence numbering and begin/end bits, allowing packets provides for sequence numbering and begin/end bits, allowing packets
to be split into fragments (Figure 1). to be split into fragments (Figure 1).
Figure 1: Multilink Short Sequence Number Fragment Format [2] Figure 1: Multilink Short Sequence Number Fragment Format [2]
skipping to change at page 4, line 43 skipping to change at page 4, line 49
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.
3.1. Limitations of multilink as-is 3.1. Limitations of multilink as-is
Multilink-as-is is not the complete 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 fragmentable (and therefore, the multilink; the latter are not fragmentable (and therefore, the
content of one packet cannot be sent in parallel on multiple links; content of one packet cannot be sent in parallel on multiple links;
if the packets are sent in rounds on multiple links, the order they if the packets are sent in rounds on multiple links, the order they
are processed at the receiver may differ from the order they were are processed at the receiver may differ from the order they were
sent). sent).
A problem not solved by this specification is that the multi-link A problem not solved by this specification is that the multi-link
header is relatively large; as delay bounds become small (for queues- header is relatively large; as delay bounds become small (for
of-fragments type implementations) the overhead may become queues-of-fragments type implementations) the overhead may become
significant. significant.
4. 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.
skipping to change at page 7, line 44 skipping to change at page 8, line 23
Sequence Number Header Format option ([2]) MUST NOT also be present. Sequence Number Header Format option ([2]) MUST NOT also be present.
If no instance of this option or the Short Sequence Number Header If no instance of this option or the Short Sequence Number Header
Format option is present, but an MRRU option [2] is present, then by Format option is present, but an MRRU option [2] is present, then by
default, long sequence number multilink headers with class 0 only are default, long sequence number multilink headers with class 0 only are
used; this is equivalent to code equals 2 and number of suspendable used; this is equivalent to code equals 2 and number of suspendable
classes equals 1. An instance of the Short Sequence Number Header classes equals 1. An instance of the Short Sequence Number Header
Format Option is equivalent to an instance of this option with code Format Option is equivalent to an instance of this option with code
equals 6 and number of suspendable classes equal to 1. equals 6 and number of suspendable classes equal to 1.
The number of suspendable classes bounds the allowable class numbers: The number of suspendable classes bounds the allowable class numbers:
only class numbers numerically lower than this value can be used for only class numbers numerically lower than this limit can be used for
suspendable classes. Implementations MAY want to negotiate a number suspendable classes. Implementations MAY want to negotiate a number
smaller than made possible by the packet format to limit their smaller than made possible by the packet format to limit their
reassembly buffer space requirements. Implementations SHOULD at reassembly buffer space requirements. Implementations SHOULD at
least support the value 4 for the short sequence number fragment least support the value 4 for the short sequence number fragment
format, and the value 8 for the long sequence number fragment format, format, and the value 8 for the long sequence number fragment format,
unless configured differently. Bit combinations that would indicate unless configured differently. Bit combinations that would indicate
class numbers outside the negotiated range MAY be used for other class numbers outside the negotiated range MAY be used for other
semantics if negotiated by other means outside the scope of this semantics if negotiated by other means outside the scope of this
document (e.g., [6]). document (e.g., [6]).
6.2. Prefix elision option 6.2. Prefix elision option
This LCP option advises the peer that the implementation expects to This LCP option advises the peer that, in each of the given classes,
receive only packets with a certain prefix in each of the given the implementation expects to receive only packets with a certain
classes; this prefix is not to be sent as part of the information in prefix; this prefix is not to be sent as part of the information in
the fragment(s) of this class. By default, this common prefix is the fragment(s) of this class. By default, this common prefix is
empty for all classes. When this option is negotiated, the accepting empty for all classes. When this option is negotiated, the accepting
implementation MUST either transmit all subsequent multilink packets implementation MUST either transmit all subsequent multilink packets
of each of the given classes with the given prefix elided or of each of the given classes with the given prefix removed from the
Configure-Nak or Configure-Reject the option. If none of the formats start of the packet or Configure-Nak or Configure-Reject the option.
with classes has been negotiated, class number 0 may be used to If none of the formats with classes has been negotiated, class number
indicate a common prefix for all packets sent within multilink 0 may be used to indicate a common prefix for all packets sent within
fragments. multilink fragments.
Apart from the type and length octets common to all LCP options, the Apart from the type and length octets common to all LCP options, the
option contains a sequence of zero or more sequences of a single- option contains a sequence of zero or more sequences of a single-
octet class number, a single-octet length of the prefix for that octet class number, a single-octet length of the prefix for that
class, and the octets in that prefix: class, and the octets in that prefix:
Figure 5: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 50 skipping to change at page 9, line 31
IMPLEMENTATION NOTE: as with most PPP options that indicate IMPLEMENTATION NOTE: as with most PPP options that indicate
capabilities of the receiver to the sender, the sense of this option capabilities of the receiver to the sender, the sense of this option
is an indication from the receiver to the sender of the packets is an indication from the receiver to the sender of the packets
concerned. Often, only the senders will have sufficient control over concerned. Often, only the senders will have sufficient control over
their usage of classes to be able to supply useful values for this their usage of classes to be able to supply useful values for this
option. A receiver willing to accept prefix-elided packets SHOULD option. A receiver willing to accept prefix-elided packets SHOULD
request this option with empty content; the sender then can use request this option with empty content; the sender then can use
Configure-Nak to propose the class-to-prefix mapping desired. Configure-Nak to propose the class-to-prefix mapping desired.
7. References 7. Security Considerations
[1] C. Bormann, ``Providing integrated services over low-bitrate Operation of this protocol is believed to be no more and no less
links'', Work in Progress (draft-ietf-issll-isslow-05.txt), secure than operation of the PPP multilink protocol [2].
April 1999.
[2] K. Sklower, B. Lloyd, G. McGregor, D. Carr, T. Coradetti, ``The 8. References
PPP Multilink Protocol (MP)'', RFC 1990, August 1996 (obsoletes
RFC1717).
[3] W. Simpson, ``PPP in Frame Relay'', RFC 1973, June 1996. [1] Bormann, C., "Providing Integrated Services over Low-bitrate
Links", RFC 2689, September 1999.
[4] R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'', Work [2] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
in Progress (draft-andrades-framing-ext-00.txt), September 1996. "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[5] C. Bormann, ``PPP in a real-time oriented HDLC-like framing'', [3] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996.
Work in Progress (draft-ietf-issll-isslow-rtf-04.txt), April
1999.
8. Author's address [4] Andrades, R. and F. Burg, "QOSPPP Framing Extensions to PPP",
Work in Progress.
[5] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing",
RFC 2687, September 1999.
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[7] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC
1662, July 1994.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
9. 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@tzi.org
phone +49.421.218-7024
fax +49.421.218-7000
Acknowledgements Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.org
10. 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 1996 useful for this purpose. The participants in a lunch BOF at the 1996
Montreal IETF gave useful input on the design tradeoffs in various Montreal IETF gave useful input on the design tradeoffs in various
environments. The members of the ISSLL subgroup on low bitrate links environments. The members of the ISSLL subgroup on low bitrate links
(ISSLOW) have helped reducing the large set of options that initial (ISSLOW) have helped reducing the large set of options that initial
versions of this specification had. versions of this specification had.
11. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 25 change blocks. 
60 lines changed or deleted 63 lines changed or added

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