The Multi-Class Extension to Multi-Link PPP
RFC 2686

Document Type RFC - Proposed Standard (September 1999; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2686 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         C. Bormann
Request for Comments: 2686                       Universitaet Bremen TZI
Category: Standards Track                                 September 1999

              The Multi-Class Extension to Multi-Link PPP

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   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.

   This document proposes the fragment-oriented solution for the real-
   time encapsulation format part of the architecture.  The general
   approach is to start from the PPP Multilink fragmentation protocol
   [2] and provide a small number of extensions to add functionality and
   reduce the overhead.

1.  Introduction

   As an extension to the "best-effort" services the Internet is well-
   known for, additional types of services ("integrated services") that
   support the transport of real-time multimedia information are being
   developed for, and deployed in the Internet.

   The present document defines the fragment-oriented solution 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
   the architecture document, a real-time encapsulation format is

Bormann                     Standards Track                     [Page 1]
RFC 2686      The Multi-Class Extension to Multi-Link PPP September 1999

   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
   information for about 400 ms.  This adds a worst-case delay that
   causes real-time applications to operate with round-trip delays on
   the order of at least a second -- unacceptable for real-time
   conversation.  The PPP extensions defined in this document allow a
   sender to fragment the packets of various priorities into multiple
   classes of fragments, allowing high-priority packets to be sent
   between fragments of lower priorities.

   A companion document based on these extensions [5] defines a
   suspend/resume-oriented solution for those cases where the best
   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 [8].

2.  Requirements

   The main design goal for the components of an architecture that
   addresses real-time multimedia flows over low-bitrate links is that
   of minimizing the end-to-end delay.  More specifically, the worst
   case delay (after removing possible outliers, which are equivalent to
   packet losses from an application point of view) is what determines
   the playout points selected by the applications and thus the delay
   actually perceived by the user.

   In addition, every attempt should obviously be undertaken to maximize
   the bandwidth actually available to media data; overheads must be
   minimized.

   The solution should not place unnecessary burdens on the non-real-
   time flows.  In particular, the usual MTU should be available to
   these flows.

   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
   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
   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
   a PPP link is the default MTU of 1500 bytes.  The smallest high-
   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
   to be expected, this translates to a maximum requirement of about

Bormann                     Standards Track                     [Page 2]
RFC 2686      The Multi-Class Extension to Multi-Link PPP September 1999
Show full document text