draft-ietf-issll-isslow-mcml-03.txt   draft-ietf-issll-isslow-mcml-04.txt 
INTERNET-DRAFT Carsten Bormann INTERNET-DRAFT Carsten Bormann
Expires: September 1998 Universitaet Bremen Expires: February 1999 Universitaet Bremen TZI
August 1998
The Multi-Class Extension to Multi-Link PPP The Multi-Class Extension to Multi-Link PPP
draft-ietf-issll-isslow-mcml-03.txt draft-ietf-issll-isslow-mcml-04.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
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Distribution of this document is unlimited.
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
skipping to change at page 4, line 51 skipping to change at page 4, line 45
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 also cannot multilink; the latter are not fragmentable (and therefore, the
be distributed to 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
are processed at the receiver may differ from the order they were
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 queues-
of-fragments type implementations) the overhead may become 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.
skipping to change at page 7, line 6 skipping to change at page 7, line 6
o Multilink Header Format o Multilink Header Format
o Prefix Elision o Prefix Elision
6.1. Multilink header format option 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 4: Figure 4:
0 1 2 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 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 | Length = 3 | Code | | Type = 27 | Length = 4 | Code | # Susp Clses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This LCP option advises the peer that the implementation wishes to This LCP 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, with the
default, long sequence number multilink headers without classes are maximum number of suspendable classes (see below) given.
used. When this option is received, an implementation MUST either
transmit all subsequent multilink packets on all links of the bundle
with the multilink header format given or configure-NAK or configure-
Reject the option.
The values defined for the use of this option are: When this option is negotiated, the accepting implementation MUST
either transmit all subsequent multilink packets on all links of the
bundle with the multilink header format given or Configure-Nak or
Configure-Reject the option. (Note that an implementation MAY
continue to send packets outside of multilink in any case.) If this
option is offered on a link which is intended to join an existing
bundle, a system MUST offer the same multilink header format option
value previously negotiated for the bundle, or none if none was
negotiated previously.
- Neither this option nor the Short Sequence Number Header Format The values defined in this document for the use of this option are:
Option (type = 18) [2] is present: long sequence number fragment
format
- This option present with code = 2: long sequence number fragment - Code = 2: long sequence number fragment format with classes
format with classes
- Short Sequence Number Header Format Option (type = 18) present: - Code = 6: short sequence number fragment format with classes
short sequence number fragment format
- This option present with code = 6: short sequence number The Multilink Header Format option MUST NOT occur more than once in a
fragment format with classes Configure-Request or Configure-Ack, and, if it is present, the Short
Sequence Number Header Format option ([2]) MUST NOT also be present.
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
default, long sequence number multilink headers with class 0 only are
used; this is equivalent to code equals 2 and number of suspendable
classes equals 1. An instance of the Short Sequence Number Header
Format Option is equivalent to an instance of this option with code
equals 6 and number of suspendable classes equal to 1.
An implementation MUST NOT request a combination of both the Short The number of suspendable classes bounds the allowable class numbers:
Sequence Number Header Format Option and this option. only class numbers numerically lower than this value can be used for
suspendable classes. Implementations MAY want to negotiate a number
smaller than made possible by the packet format to limit their
reassembly buffer space requirements. Implementations SHOULD at
least support the value 4 for the short sequence number fragment
format, and the value 8 for the long sequence number fragment format,
unless configured differently. Bit combinations that would indicate
class numbers outside the negotiated range MAY be used for other
semantics if negotiated by other means outside the scope of this
document (e.g., [6]).
6.2. Prefix elision option 6.2. Prefix elision option
This LCP option advises the peer that the implementation wishes to This LCP option advises the peer that the implementation expects to
send only packets with a certain prefix in each of the given classes; receive only packets with a certain prefix in each of the given
this prefix is not sent as part of the information in the fragment(s) classes; this prefix is not to be sent as part of the information in
of this class. By default, this common prefix is empty for all the fragment(s) of this class. By default, this common prefix is
classes. When this option is received, an implementation MUST either empty for all classes. When this option is negotiated, the accepting
add the prefix given for the class to all subsequently received implementation MUST either transmit all subsequent multilink packets
multilink packets of each of the given classes or configure-NAK or of each of the given classes with the given prefix elided or
configure-Reject the option. Configure-Nak or Configure-Reject the option. If none of the formats
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 class option contains a sequence of zero or more sequences of a single-
number, a length of the prefix for that class, and the octets in that octet class number, a single-octet length of the prefix for 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Option Length | Class | Prefix Length | | Type = 26 | Option Length | Class | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix... | Prefix... | Class |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NOTA BENE: the sense of this option is an indication from the sender The Prefix Elision option MUST NOT occur more than once in a
to the receiver, UNLIKE most PPP options that indicate capabilities Configure-Request or Configure-Nak. If this option is offered on a
of the receiver to the sender. link which is intended to join an existing multilink bundle, a system
MUST offer the same prefix elision option value previously negotiated
for the bundle, or none if none was negotiated previously.
IMPLEMENTATION NOTE: as with most PPP options that indicate
capabilities of the receiver to the sender, the sense of this option
is an indication from the receiver to the sender of the packets
concerned. Often, only the senders will have sufficient control over
their usage of classes to be able to supply useful values for this
option. A receiver willing to accept prefix-elided packets SHOULD
request this option with empty content; the sender then can use
Configure-Nak to propose the class-to-prefix mapping desired.
7. References 7. 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-03.txt), links'', Work in Progress (draft-ietf-issll-isslow-04.txt),
March 1998. August 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-02.txt), March Work in Progress (draft-ietf-issll-isslow-rtf-03.txt), August
1998. 1998.
8. 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.org
phone +49.421.218-7024 phone +49.421.218-7024
fax +49.421.218-7000 fax +49.421.218-7000
Acknowledgements 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
 End of changes. 20 change blocks. 
53 lines changed or deleted 87 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/