draft-ietf-issll-isslow-mcml-01.txt   draft-ietf-issll-isslow-mcml-02.txt 
INTERNET-DRAFT Carsten Bormann INTERNET-DRAFT Carsten Bormann
Expires: September 1997 Universitaet Bremen Expires: November 1997 Universitaet Bremen
The Multi-Class Extension to Multi-Link PPP The Multi-Class Extension to Multi-Link PPP
draft-ietf-issll-isslow-mcml-01.txt draft-ietf-issll-isslow-mcml-02.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 3, line 12 skipping to change at page 3, line 12
time flows. In particular, the usual MTU should be available to time flows. In particular, the usual MTU should be available to
these flows. these flows.
The most general approach would provide the ability to suspend any The most general approach would provide the ability to suspend any
packet (real-time or not) for a more urgent real-time packet, up to packet (real-time or not) for a more urgent real-time packet, up to
an infinite number of levels of nesting. On the other hand, it is an infinite number of levels of nesting. On the other hand, it is
likely that there would rarely be a requirement for a real-time likely that there would rarely be a requirement for a real-time
packet to suspend another real-time packet that is not at least about packet to suspend another real-time packet that is not at least about
twice as long. Typically, the largest packet size to be expected on twice as long. Typically, the largest packet size to be expected on
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 22 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).
On an architectural level, there are several additional requirements On an architectural level, there are several additional requirements
for the fragmentation scheme: for the fragmentation scheme:
skipping to change at page 3, line 52 skipping to change at page 3, line 52
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.
The current draft does not address additional requirements that may This document does not address additional requirements that may be
be relevant in conjunction with Frame Relay; however, there seems to relevant in conjunction with Frame Relay; however, there seems to be
be little problem in applying the principles of this draft to ``PPP little problem in applying the principles of this document to ``PPP
in Frame Relay'' [3]. in Frame Relay'' [3].
3. Using existing mechanisms 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 purpose of this section is to examine existing fragmentation. The existing PPP Multilink Protocol (MP, [2])
mechanisms that are available for packet fragmentation and, by provides for sequence numbering and begin/end bits, allowing packets
relating them to the requirements listed above, to outline their to be split into fragments (Figure 1).
areas and limits of applicability.
Fragmentation is existing functionality of the IP layer. As
fragmentation and reassembly also are useful in a logical link
composed of multiple physical links, PPP Multilink (a standards track
protocol) already defines a fragmentation mechanism [2].
Unfortunately, neither approach, as is, fulfills all the requirements
listed above.
3.1. Using IP fragmentation
An IPv4 header already contains fields that allow a large IP datagram
to be fragmented into small parts. A queues-of-fragments type sender
[1] might simply indicate a small MTU to its IP stack and thus cause
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
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
access delay goal with the peer system -- if that system supports
priority queueing at the fragment level.)
Unfortunately, a full, 20 byte IP header is needed for each fragment
(larger when IP options are used). This limits the minimum size of
fragment that can be used without too much overhead. (Also, the size
of non-final fragments must be a multiple of 8 bytes, further
limiting the choice.) With path MTU discovery, IP level
fragmentation causes TCP implementations to use small MSSs -- this
further increases the per-packet overhead to 40 bytes per fragment.
In any case, fragmentation at the IP level persists on the path
further down to the datagram receiver, increasing the transmission
overheads and router load throughout the network. With its high
overhead and the adverse effect on the Internet, IP level
fragmentation can only be a stop-gap mechanism when no other
fragmentation protocol is available in the peer implementation.
_________________________
[1] This assumes that the IP stack is able to priority-tag frag-
ments, or that the PPP implementation is able to correlate the
fragments to the initial one that carries the information relevant
for prioritizing, or that only initial fragments can be high-
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 |
+-+-+-+-+-------+---------------+ +-+-+-+-+-------+---------------+
skipping to change at page 5, line 42 skipping to change at page 4, line 45
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.
3.3. 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. multilink; the latter are not fragmentable (and therefore also cannot
be distributed to multiple links).
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.
The general approach of this document is to start from PPP Multilink
and provide a number of extensions to add functionality and reduce
the overhead of using PPP Multilink for real-time transmission.
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.
This document defines (some of the) previously unused bits as a class This document defines (some of the) previously unused bits as a class
skipping to change at page 7, line 54 skipping to change at page 6, line 34
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 to compress away prefixes that often are not
reachable by these other methods. reachable by these other methods.
6. Negotiable options 6. Negotiable options
The following 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
This document defines two new options: This document defines two new LCP options:
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
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 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. 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
skipping to change at page 9, line 7 skipping to change at page 7, line 40
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
This option advises the peer that the implementation wishes to send This LCP option advises the peer that the implementation wishes to
only packets with a certain prefix in each of the given classes; the send only packets with a certain prefix in each of the given classes;
prefix is not sent as part of the information in the fragment(s) of this prefix is not sent as part of the information in the fragment(s)
this class. By default, this common prefix is empty for all classes. of this class. By default, this common prefix is empty for all
When this option is received, an implementation MUST either add the classes. When this option is received, an implementation MUST either
prefix given for the class to all subsequently received multilink add the prefix given for the class to all subsequently received
packets of each of the given classes on all links of the bundle or multilink packets of each of the given classes or configure-NAK or
configure-NAK or configure-Reject the option. configure-Reject the option.
If none of the formats with classes has been negotiated, class 0 is If none of the formats with classes has been negotiated, class number
used to indicate a common prefix for all packets sent within 0 may be used to indicate a common prefix for all packets sent within
multilink fragments. multilink fragments.
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
number, a length of the prefix for that 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 = 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. 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 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 draft had. versions of this draft had.
8. 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-01.txt), links'', Work in Progress (draft-ietf-issll-isslow-02.txt), May
February 1997. 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'', Work
September 20, 1996, Work in Progress (draft-andrades-framing- in Progress (draft-andrades-framing-ext-00.txt), September 1996.
ext-00.txt).
[5] C. Bormann, ``PPP in a real-time oriented HDLC-like framing, [5] C. Bormann, ``PPP in a real-time oriented HDLC-like framing'',
internet Draft draft-ietf-issll-isslow-rtf-00.txt, Work in Work in Progress (draft-ietf-issll-isslow-rtf-01.txt), May 1997.
Progress, March 1997.
9. Addresses 9. Addresses
9.1. Working Group 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>.
9.2. Author's address 9.2. Author's address
 End of changes. 19 change blocks. 
86 lines changed or deleted 39 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/