

Versions: 00 01 02 RFC 3153

PPPext Working Group                               R. Pazhyannur,
                                                           I. Ali
Internet Engineering Task Force                          Motorola
Internet Draft                                             C. Fox
                                                    Cisco Systems

Expires: August 15, 2001                        February 15, 2001

                            PPP Multiplexing

Status of this Memo

   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

1. Abstract

   This draft describes a method to reduce the PPP framing overhead
   used to transport small packets over slow links. The method, PPP
   Multiplexing, sends multiple PPP encapsulated packets in a single
   PPP frame. As a result, the PPP overhead per packet is reduced.

2. Description

   PPP encapsulation (for example with PPP in HDLC framing) adds
   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 2.1. The delimiters are used by the

R. Pazhyannur, I. Ali, C. Fox                                 [Page 1]

                               PPP Mux                 February, 2001

   demultiplexor to separate the PPP frames within the multiplexed
   frame. Each PPP encapsulated frame within the multiplexed frame is
   called a PPP subframe.

   receive multiplexed frames using the PPP Mux Control Protocol
   (PPPMuxCP), as described in Section 3. 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
   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

2.1. Payload Format

   The format of the complete PPP frame along with multiple subframes
   regardless of the order in which individual bits are transmitted,
   i.e. LSB first or MSB first, the PFF bit will be seen to be the MSB

   | (2-5) +  (1-2 ) + (0-2) +     +   +  (1û2)  + (0-2) +     + (2) |

   Figure 1. Multiplexing subframes in a PPP frame.

   PPP Header:
        The PPP header contains the PPP Protocol Field for a PPP
        Multiplexed Frame (0x0059). The PPP header compression
        options (ACFC and PFC) may be negotiated during LCP and
        could thus affect the format of this header.

   Length Field:

R. Pazhyannur, I. Ali, C. Fox                                 [Page 2]

                               PPP Mux                 February, 2001

        The length field consists of three subfields:

    1. Protocol Field Flag (PFF):
        each subframe. This one bit field indicates whether the PPP
        Protocol ID of the subframe follows the subframe length field.
        PPP protocol ID of the first subframe is equal to the default
        PID value negotiated in PPPMuxCP. PFF = 1 indicates that the
        protocol field is present (and follows the length field) for
        this subframe. PFF = 0 indicates that the protocol field is
        first subframe. The transmitter is not obligated to remove the
        PPP Protocol ID for any subframe.

    2. Length Extension (LXT)
        This one bit field indicates whether the length field is one
        length field is two bytes long (a PFF bit, a length extension
        bit, and 14 bits of sub-frame length). If the LXT bit is
        cleared, then the length field is one byte long(a PFF bit, a
        length extension bit, and 6 bits of sub-frame length).

    3. Sub-frame Length (LEN):
        This is the length of the subframe in bytes not including the
        present (i.e. if PFF = 1). If the length of the subframe is
        to zero and the last six bits of the length field is
        the subframe length. If the length of the subframe is greater
        than 63 bytes, LXT is set to one and the last 14 bits of the
        length field is the length of the subframe. The maximum
        length of a subframe is 16,383 bytes. PPP packets larger than
        16,383 bytes will need to be sent in their own PPP frame. A
        transmitter is not required to multiplex all frames smaller
        than 16,383 bytes. It may chose to only multiplex frames
        smaller than a configurable size into a PPP multiplexed frame.

   Protocol Field:
        This field contains the Protocol Field value for the subframe.
        protocol field is present in the subframe, otherwise it is
        inferred at the receiver.

        The receiver MUST support Protocol-Field-Compression (PFC)
        [4] for subframe PPP Protocol IDs. Thus the field may be
        one or two bytes long. The transmitter SHOULD
        compress PPP Protocol IDs in this field that have an upper
        byte of zero (i.e. Protocol IDs from 0x21 thru 0xFD). This

R. Pazhyannur, I. Ali, C. Fox                                 [Page 3]

                               PPP Mux                 February, 2001

        Protocol Field Compression in each PPP subframe is not related
        to the negotiation of PFC during LCP negotiation which affects
        the length of PPP Multiplexed Frame Protocol ID.

   Information Field:
        This field contains the actual packet being encapsulated.
        Any frame may be included here with the exception of LCP
        Configure Request, ACK, NAK and Reject frames and PPP
        Multiplexed frames. If LCP is renegotiated then PPP
        Multiplexing MUST be disabled until the PPP Mux Control
        Protocol is negotiated.

2.2 Transmitter procedure

   A simple implementation of the transmitter is provided. During the
   transmission of a multiplexed PPP frame, the transmitter has a state
   multiplexing process, Last_PID is set equal to the default PID value
   negotiated in PPPMuxCP. Also, a user configurable parameter, maximum
   length field) and 16,383 (14 bits).

   the PPP multiplexing logic looks at the buffers that hold the PPP
   multiplexing logic checks if the length of the first frame in the
   transmitter starts compiling a multiplexed PPP frame with the
   protocol field value corresponding to PPP Multiplexed Frame (0x59).
   For each subframe, the test for deciding to prepend the protocol
   the protocol field value of the current subframe. The stopping
   the entire PPP frame by including the new subframe exceeds the
   (iii) there are no more subframes to concatenate.

   Implementers may choose additionally to implement using timers. In
   used as a stopping criteria of the multiplexing process. Moreover,
   it may be desirable to limit the maximum size of a multiplexed
   packet to be considerably smaller than MRU for reasons of
   multiplexing latency and packet error considerations.

R. Pazhyannur, I. Ali, C. Fox                                 [Page 4]

                               PPP Mux                 February, 2001

2.3 Receiver procedure

   If a multiplexed frame, i.e. a frame with Protocol field value equal
   demultiplexed in order using the following input demultiplexing
   called Last_rcvd_PID, which is the value of the protocol field in
   the most recently demultiplexed subframe with PFF=1. Last_rcvd_PID
   is initialized to default PID value negotiated by PPPMuxCP. If PFF=0
   for a subframe, Last_rcvd_PID is appended to the beginning of the
   subframe before handing the subframe, as determined by the length
   returned to the demultiplexor. Each succeeding subframe is processed
   similarly. This processing is complete when the remainder of the
   last subframe must be dropped by the demultiplexing logic.


3. PPP Network Control Protocol for PPP Multiplexing (PPPMuxCP)

   A receiver will offer its ability to received multiplexed frames by
   negotiating NCP for PPP multiplexing, PPPMuxCP. The protocol field
   frame unless the peer has offered to receive multiplexed frames.
   Support of multiplexed frame reception is negotiated in each
   direction independently. Successful negotiation of PPPMuxCP does not
   obligate a peer to transmit multiplexed frames.

   always negotiated. This enables the transmitter to transmit the
   first subframe of a PPP multiplexed frame without a PID (PFF=0),
   thus resulting in a saving of one or two bytes. Note that the
   negotiation of default PID does not require the transmitter to send
   the first subframe with PFF=0 even if doing so would optimize the
   transmission. And, as always, the option (and thus the default PID)
   is negotiated by the receiver, i.e. the receiver will interpret a
   received PPPmux packet using the default PID it offered.

   LCP frames MUST NOT be sent in Multiplexed frames.

R. Pazhyannur, I. Ali, C. Fox                                 [Page 5]

                               PPP Mux                 February, 2001

   The only option in PPPMuxCP is the negotiation of Default PID and is
   shown below

    0                   1                   2                   3
   |   Type = 1    |   Length = 4  |        Default PID            |

   Figure 2. Default PID option for PPPMuxCP

4. Interaction with PPP Multilink (MP) Protocol

   PPP multiplexed frame option is negotiated by an NCP.  LCP is
   negotiated over each member link of a multilink bundle and not on
   the bundle itself [5]. Thus in case of MP, PPPmux cannot be
   negotiated for individual links, but only for the bundle.

   Hence, on the transmitter side PPP multiplexing always occurs before
   must not be sent in Multiplexed frames.

5. Interaction with CCP and ECP

   ECP.  Thus,  to negotiate the hypothetical transmit path sequence
   CCP -> PPPMux -> ECP, the bundle-level version of CCP (80fd) and the
   per-link version of ECP (8055) are negotiated along with the PPPMux

   An implementation that cannot perform PPPMux above CCP or ECP MUST
   PPPMux has been negotiated.

6. Security Considerations

   This draft does not impose additional security considerations beyond
   those that apply to PPP and header-compression schemes over PPP.

7. Acknowledgements

   The authors would like to thank contributors on the PPPext mailing
   list, especially James Carlson, for valuable inputs to this draft.

8. References

R. Pazhyannur, I. Ali, C. Fox                                 [Page 6]

                               PPP Mux                 February, 2001

   [1] Townsley, M., et al, "Layer Two Tunneling Protocol "L2TP"", RFC
   2661, August 1999.


   July 1994.

   RFC 1661, July 1994.

   [5] Sklower, K., et al, "The PPP Multilink Protocol (MP)", RFC 1990,
   August 1996.

   (IPCP)", RFC 1332, May 1992.

7. Author's Addresses

   Rajesh Pazhyannur
   Motorola, Network Solutions Sector
   1501, W. Shure Drive
   Arlington Heights, IL 60004
   Phone: (847) 632-4524
   Email: pazhynnr@cig.mot.com

   Irfan Ali
   Motorola, Network Solutions Sector
   1501, W. Shure Drive
   Arlington Heights, IL 60004
   Phone: (847) 632-3281
   Email: fia225@email.mot.com

   Craig Fox
   Cisco Systems
   170 W. Tasman Street
   San Jose, CA 95134
   Phone: (408) 526-6296
   E-mail: fox@cisco.com

R. Pazhyannur, I. Ali, C. Fox                                 [Page 7]

                               PPP Mux                 February, 2001

Full Copyright Statement


   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   kind, provided that the above copyright notice and this paragraph
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.   This
   document and the information contained herein is provided on an

R. Pazhyannur, I. Ali, C. Fox                                 [Page 8]
