Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

PPP Multiplexing (RFC3153)

IP.com Disclosure Number: IPCOM000005336D
Original Publication Date: 2001-Aug-01
Included in the Prior Art Database: 2001-Aug-22
Document File: 10 page(s) / 19K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Pazhyannur: AUTHOR [+3]

Abstract

This document describes a method to reduce the PPP (Point-to-Point Protocol) framing overhead used to transport small packets over slow links.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 18% of the total text.

Network Working Group R. Pazhyannur Request for Comments: 3153 I. Ali Category: Standards Track Motorola

C. Fox Cisco Systems

August 2001

PPP Multiplexing

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 (2001). All Rights Reserved.

Abstract

This document describes a method to reduce the PPP (Point-to-Point Protocol) framing overhead used to transport small packets over slow links.

1. Description

The method, PPP Multiplexing, sends multiple PPP encapsulated packets in a single PPP frame. As a result, the PPP overhead per packet is reduced. PPP encapsulation (for example with PPP in HDLC framing) adds several bytes of overhead: a HDLC flag (at least one to separate adjacent packets), the Address (0xFF) and Control (0x03) field bytes, a two byte PPP Protocol ID, and the two byte CRC field. Even with the Address and Control Fields negotiated off and the PPP Protocol ID compressed, each PPP encapsulated frame will include four bytes of overhead. When PPP frames are tunneled, as in L2TP [1], the L2TP overhead per PPP frame is significant.

The key idea is to concatenate multiple PPP encapsulated frames into a single PPP multiplexed frame by inserting a delimiter before the beginning of each frame. The description of the delimiters is provided in Subsection 1.1. The delimiters are used by the demultiplexor to separate the PPP frames within the multiplexed frame. Each PPP encapsulated frame within the multiplexed frame is called a PPP subframe.

Pazhyannur, et al. Standards Track [Page 1]

RFC 3153 PPP Multiplexing August 2001

During the NCP negotiation phase of PPP, a receiver can offer to receive multiplexed frames using the PPP Mux Control Protocol (PPPMuxCP), as described in Section 2. Once PPPMuxCP has been negotiated, the transmitter may choose which PPP frames to multiplex. Frames should not be re-ordered by either the transmitter or receiver regardless of whether they arrive as part of the PPP multiplexed frame or by themselves.

The scheme proposed is similar to the concatenated framing option [2]. The key differences are that PPP multiplexing is more efficient and that it allows concatenation of variable sized frames. This is unlike concatenated framing which restricts all frames to be of fixed length.

As with any concatenation scheme, the implementer has to consider the tradeoff between increased delay for multiplexing/demultiplexing and reduced packet overhead as the length of the multiplexed frame increases.

The key words "MUST", "MUST NOT", "REQU...