PPP in a Real-time Oriented HDLC-like Framing
RFC 2687

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 2687 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         C. Bormann
Request for Comments: 2687                       Universitaet Bremen TZI
Category: Standards Track                                 September 1999

             PPP in a Real-time Oriented HDLC-like Framing

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 suspend/resume-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 its multi-class extension [5] and add suspend/resume in a way
   that is as compatible to existing hard- and firmware as possible.

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 suspend/resume-oriented solution for
   the real-time encapsulation format part of the architecture.  As
   described in more detail in the architecture document, a real-time
   encapsulation format is required as, e.g., a 1500 byte packet on a

Bormann                     Standards Track                     [Page 1]
RFC 2687      PPP in Real-time Oriented HDLC-like Framing September 1999

   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.

   A true suspend/resume-oriented approach can only be implemented on a
   type-1 sender [1], but provides the best possible delay performance
   to this type of senders.  The format defined in this document may
   also be of interest to certain type-2-senders that want to exploit
   the better bit-efficiency of this format as compared to [5].  The
   format was designed so that it can be implemented by both type-1 and
   type-2 receivers.

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 requirements for this document are similar to those listed in
   [5].

   A suspend/resume-oriented solution can provide better worst-case
   latency than the pre-fragmenting-oriented solution defined in [5].
   Also, as this solution requires a new encapsulation scheme, there is
   an opportunity to provide a slightly more efficient format.

   Predictability, robustness, and cooperation with PPP and existing
   hard- and firmware installations are as important with suspend/resume
   as with pre-fragmenting.  A good suspend/resume solution achieves
   good performance even with type-2 receivers [1] and is able to work
   with PPP hardware such as async-to-sync converters.

   Finally, a partial non-requirement: While the format defined in this
   draft is based on the PPP multilink protocol ([2], also abbreviated
   as MP), operation over multiple links is in many cases not required.

3.  General Approach

   As in [5], the general approach is to start out from PPP multilink
   and add multiple classes to obtain multiple levels of suspension.
   However, in contrast to [5], more significant changes are required to
   be able to suspend the transmission of a packet at any point and
   inject a higher priority packet.

Bormann                     Standards Track                     [Page 2]
RFC 2687      PPP in Real-time Oriented HDLC-like Framing September 1999

   The applicability of the multilink header for suspend/resume type
   implementations is limited, as the "end" bit is in the multilink
   header, which is the wrong place for suspend/resume operation.  To
Show full document text