draft-ietf-issll-isslow-mcml-02.txt   draft-ietf-issll-isslow-mcml-03.txt 
INTERNET-DRAFT Carsten Bormann INTERNET-DRAFT Carsten Bormann
Expires: November 1997 Universitaet Bremen Expires: September 1998 Universitaet Bremen
The Multi-Class Extension to Multi-Link PPP The Multi-Class Extension to Multi-Link PPP
draft-ietf-issll-isslow-mcml-02.txt draft-ietf-issll-isslow-mcml-03.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 46 skipping to change at page 2, line 5
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 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.
This document is a product of the IETF ISSLL working group.
Comments are solicited and should be addressed to the two working
groups' mailing lists at issll@mercury.lcs.mit.edu and ietf-
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.
A companion document describes an architecture for providing
integrated services over low-bitrate links, such as modem lines, ISDN
B-channels, and sub-T1 links [1]. The main components of the
architecture are: a real-time encapsulation format for asynchronous
and synchronous low-bitrate links, a header compression architecture
optimized for real-time flows, elements of negotiation protocols used
between routers (or between hosts and routers), and announcement
protocols used by applications to allow this negotiation to take
place.
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
conversation. The PPP extensions defined in this document allow a conversation. The PPP extensions defined in this document allow a
sender to fragment the packets of various priorities into multiple sender to fragment the packets of various priorities into multiple
classes of fragments, allowing high-priority packets to be sent classes of fragments, allowing high-priority packets to be sent
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
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 4, line 34 skipping to change at page 4, line 34
| . | | . |
| . | | . |
+---------------+---------------+ +---------------+---------------+
PPP FCS: | FCS | PPP FCS: | FCS |
+---------------+---------------+ +---------------+---------------+
(Note that the address, control, and most significant PID bytes are (Note that the address, control, and most significant PID bytes are
often negotiated to be compressed away.) often negotiated to be compressed away.)
MP's monotonically increasing sequence numbering (contiguous numbers MP's monotonically increasing sequence numbering (contiguous numbers
are needed for all fragments of a packet) does not allow to suspend are needed for all fragments of a packet) does not allow suspension
sending a sequence of fragments of one packet for sending another of the sending of a sequence of fragments of one packet in order to
packet. It is, however, possible to send intervening packets that send another packet. It is, however, possible to send intervening
are not encapsulated in multilink headers; thus, MP supports two packets that are not encapsulated in multilink headers; thus, MP
levels of priority. supports two 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.
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,
skipping to change at page 6, line 29 skipping to change at page 6, line 29
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 why associating one of them with the prefix. (This is the reason why
four of 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 implementations to compress away prefixes that
reachable by these other methods. often are not reachable by header or data compression methods.
6. Negotiable options 6. Negotiable options
The following PPP LCP options are already defined by MP: The following PPP LCP 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
skipping to change at page 7, line 23 skipping to change at page 7, line 23
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 are default, long sequence number multilink headers without classes are
used. When this option is received, an implementation MUST either used. When this option is received, an implementation MUST either
transmit all subsequent multilink packets on all links of the bundle transmit all subsequent multilink packets on all links of the bundle
with the multilink header format given or configure-NAK or configure- with the multilink header format given or configure-NAK or configure-
Reject the option. Reject the option.
The values defined for the use of this option are: The values defined for the use of this option are:
- Neither this option nor the Short Sequence Number Header Format - Neither this option nor the Short Sequence Number Header Format
Option (type 18) [2] is present: long sequence number fragment Option (type = 18) [2] is present: long sequence number fragment
format format
- This option present with code = 2: long sequence number fragment - This option present with code = 2: long sequence number fragment
format with classes format with classes
- Short Sequence Number Header Format Option (type 18) present: - Short Sequence Number Header Format Option (type = 18) present:
short sequence number fragment format short sequence number fragment format
- This option present with code = 6: short sequence number - This option present with code = 6: short sequence number
fragment format with classes fragment format with classes
An implementation MUST NOT request a combination of both the Short An implementation MUST NOT request a combination of both the Short
Sequence Number Header Format Option and this option. Sequence Number Header Format Option and this option.
6.2. Prefix elision option 6.2. Prefix elision option
skipping to change at page 8, line 21 skipping to change at page 8, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Option Length | Class | Prefix Length | | Type = TBD | Option Length | Class | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix... | Prefix...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
NOTA BENE: the sense of this option is an indication from the sender NOTA BENE: the sense of this option is an indication from the sender
to the receiver, UNLIKE most PPP options that indicate capabilities to the receiver, UNLIKE most PPP options that indicate capabilities
of the receiver to the sender. of the receiver to the sender.
7. Acknowledgements 7. References
David Oran suggested using PPP Multilink for real-time framing and
reminded the author of his earlier attempts of making Multilink more
useful for this purpose. The participants in a lunch BOF at the 1996
Montreal IETF gave useful input on the design tradeoffs in various
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.
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-02.txt), May links'', Work in Progress (draft-ietf-issll-isslow-03.txt),
1997. March 1998.
[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'', Work [4] R. Andrades, F. Burg, ``QOSPPP Framing Extensions to PPP'', Work
in Progress (draft-andrades-framing-ext-00.txt), September 1996. in Progress (draft-andrades-framing-ext-00.txt), September 1996.
[5] C. Bormann, ``PPP in a real-time oriented HDLC-like framing'', [5] C. Bormann, ``PPP in a real-time oriented HDLC-like framing'',
Work in Progress (draft-ietf-issll-isslow-rtf-01.txt), May 1997. Work in Progress (draft-ietf-issll-isslow-rtf-02.txt), March
1998.
9. Addresses
9.1. Working Group
The ISSLL working group can be contacted via the co-chairs, Eric
Crawley <esc@baynetworks.com> and John Wroclawski <jtw@lcs.mit.edu>,
or via its WG mailing list <issll@mercury.lcs.mit.edu>.
9.2. Author's address 8. 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.uni-bremen.de cabo@tzi.uni-bremen.de
phone +49.421.218-7024 phone +49.421.218-7024
fax +49.421.218-7000 fax +49.421.218-7000
Acknowledgements
David Oran suggested using PPP Multilink for real-time framing and
reminded the author of his earlier attempts of making Multilink more
useful for this purpose. The participants in a lunch BOF at the 1996
Montreal IETF gave useful input on the design tradeoffs in various
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 specification had.
 End of changes. 14 change blocks. 
50 lines changed or deleted 24 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/