[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 RFC 3153

Internet Engineering Task Force              PPPext Working Group
Internet Draft                                     R. Pazhyannur,
                                                           I. Ali
                                                         Motorola
                                                        Craig Fox
                                                    Cisco Systems
Document: <draft-ietf-pppext-pppmux-00.txt>
Expires: June 5, 2000                             January 5, 2000


                      PPP Multiplexed Frame Option

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   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
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

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

   At a minimum, PPP encapsulating a packet adds several bytes of
   overhead, including an HDLC flag character (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
   if the Address and Control Fields are negotiated off and the PPP
   Protocol ID is compressed, each PPP encapsulated frame will include
   four bytes of overhead. This overhead can be reduced to one or two
   bytes.

   The key idea is to concatenate multiple PPP encapsulated frames into
   a single PPP multiplexed frame by inserting a length field before
   the beginning of each frame. Each PPP encapsulated frame is called a
   PPP subframe. Removing the PPP framing characters can save several
   bytes per packet, reducing overhead. The PPP Protocol ID field can

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

                               PPP Mux                  January, 2000


   also be removed for those subframes which have the same PPP Protocol
   ID as the preceding subframe.

   For the sake of efficiency, the maximum size of a subframe is 127
   bytes. This size includes the PPP Protocol ID, unless it is removed
   during the multiplexing process. This size limitation should not be
   significant since the impact of the PPP overhead is reduced as the
   packet size is increased.

   During the LCP negotiation phase of PPP, a receiver can offer to
   receive multiplexed frames using an LCP Option, described in Section
   4. Once LCP 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.

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


2.1. Protocol Field Elimination

   The PPP Protocol ID field of a subframe can be removed if the PPP
   Protocol ID of that subframe is the same as that for the preceding
   subframe. A Protocol Field Flag (PFF) bit is defined  part of the
   length field (thus reducing the length field from an 8-bit to a 7-
   bit field). The PFF bit is set if the PPP Protocol ID is included in
   the subframe. The PFF bit is cleared if the PPP Protocol ID has been
   removed from the subframe. The PFF bit MUST be set for the first
   subframe in a PPP multiplexed Frame. The transmitter is not
   obligated to remove the PPP Protocol ID for any subframe.

2.2. Payload Format

   The format of the complete PPP frame along with multiple subframes
   is shown in Figure 2. Note that 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 of a byte that contains both the
   PFF and the subframe length field.


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       +P|       +       +     +   +P|       +       +     +     |
   |  PPP  +F| Len1  +  PPP  +     +   +F| LenN  +  PPP  +     +     |
   |Header +F|       + Prot. +Info1+ ~ +F|       + Prot. +InfoN+ CRC |
   |       + |(7bits)+ Field1+     +   + |(7bits)+FieldN +     +     |
   | (2-5) +(1 byte )+ (0-2) +     +   +(1 byte) + (0-2) +     + (2) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 2. Multiplexing subframes in a PPP frame.

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

                               PPP Mux                  January, 2000



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


   Protocol Field Flag (PFF):
        This one bit field indicates whether the PPP Protocol ID of the
        subframe follows the subframe length field. PFF = 1 indicates
        that the protocol field is present for this subframe. PFF = 0
        indicates that the protocol field is absent for this subframe.
        The first subframe of each PPP multiplexed frame MUST have
        PFF = 1. If PFF = 0 then the PPP Protocol ID is the same as
        that of the preceding subframe with PFF = 1.

   Length Field:
        Each subframe has a seven bit subframe length field. This
        length does not include the byte containing the PFF and length
        field but does include the PPP Protocol ID if present (i.e. if
        PFF = 1). The maximum length of a subframe is 127 bytes. PPP
        packets larger than 127 bytes will need to be sent in their
        own PPP frame.

   Protocol Field:
        This field contains the Protocol Field value for the subframe.
        This field is optional. If PFF = 1 for a subframe, the
        protocol field is present in the subframe, otherwise it is
        inferred at the receiver.

        The receiver MUST support Protocol-Field-Compression (PFC)
        [2] for PPP Protocol IDs in this field. 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
        Protocol Field Compression is not related to the negotiation
        of PFC during LCP negotiation.

   Information Field:
        This field contains the actual packet being encapsulated.
        The maximum length of this field is 127 bytes, if the Protocol
        Field is eliminated from the subframe. 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.

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
   variable, Last_PID, which is used to hold the most recent value of

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

                               PPP Mux                  January, 2000


   protocol field in a subframe with PFF=1. This variable is only valid
   during the transmission of a multiplexed frame and no history is
   maintained from the transmission of one multiplexed PPP frame to the
   next one. This is because the first subframe in every multiplexed
   subframe MUST contain the protocol field.

   After transmitting a PPP frame (multiplexed or not) on the channel,
   the PPP multiplexing logic looks at the buffers which hold the PPP
   frames to be transmitted. In case there are multiple frames, the PPP
   multiplexing logic checks if either the length of the first frame or
   the second frame in the buffer is greater than 127 bytes. If either
   of these two conditions are met, the first and second frame are
   transmitted as non-multiplexed frames. The above logic ensures that
   small frames separated by large frames will not be transmitted as
   multiplexed frames with only one subframe. If both conditions are
   not true, i.e., the length of the first PPP frame and that of the
   second PPP frame are less than or equal to 127 bytes, the
   transmitter starts compiling a multiplexed PPP frame with the
   protocol field value corresponding to PPP_Multiplexed_Frame (0x59).
   It sets PFF=1 and then prepends the length of the first PPP
   subframe, after compressing the Protocol field. The protocol field
   is included in the first subframe. For subsequent subframes, the
   test for deciding to prepend the protocol field to a subframe is to
   compare the protocol field value of the subframe to Last_PID. If
   they are equal, PFF is set to 0 and the protocol field is deleted.
   If not, PFF is set to 1, the protocol field is included in the
   subframe and Last_PID is set to the protocol field value of the
   current subframe. The stopping criteria in the concatenation process
   are (i) when the length of the next subframe is greater than 127
   bytes or (ii)the length of the entire PPP frame by including the new
   subframe exceeds the maximum receive unit (MRU) parameter negotiated
   during LCP [2], or (iii) there are no more subframes to concatenate.

2.3 Receiver procedure

   If a multiplexed frame, i.e. a frame with Protocol field value equal
   to PPP_Multiplexed_Frame (0x59), is received, the frame is
   demultiplexed in order using the following input demultiplexing
   logic. Similar to a transmitter, the receiver has a state variable
   called Last_rcvd_ID, which is the value of the protocol field in the
   most recently demultiplexed subframe with PFF=1. No history is
   preserved in going from one multiplexed PPP frame to the next. From
   the first subframe the protocol field value is copied to
   Last_rcvd_PID. The length of the first subframe is determined, and
   the subframe is passed to be processed as a PPP frame. The remainder
   of the frame is returned to the demultiplexor.

   Each succeeding subframe is processed similarly. If PFF=0 for a
   subframe, Last_rcvd_PID is appended to the beginning of the subframe
   before handing the subframe to the PPP logic. If PFF=1 for a
   subframe, Last_rcvd_PID is set to this value and the subframe is
   passed to PPP logic. This processing is complete when the remainder
   of the frame is empty, or when the size field of a subframe exceeds

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

                               PPP Mux                  January, 2000


   the amount of data remaining in a packet. In the latter case, there
   is an error either in the length field of the last subframe or in
   the length field of one of the previous subframes. In either case
   the last subframe must be dropped by the demultiplexing logic.

   It is illegal to put a multiplexed frame within a multiplexed frame.

3. PPP Link Control Protocol Extension

   A receiver will offer its ability to received multiplexed frames by
   negotiating LCP Option 30. A transmitter may not send a multiplexed
   unless the peer has offered to receive multiplexed frames. Support
   of multiplexed frame reception is negotiated in each direction
   independently. Acknowledgement of the multiplexed Frame LCP Option
   (30) does not obligate a peer to transmit Multiplexed frames.

   LCP frames MUST NOT be sent in Multiplexed frames.

   A summary of the PPP multiplexed frame option is shown below


       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 30   |   Length = 2  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3. PPP Multiplexed Frame LCP Option


   The size of a multiplexed PPP frame MUST NOT exceed the maximum
   receive unit (MRU) size negotiated during LCP [2].

4. Security Considerations

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

5. References

   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
   9, RFC 2026, October 1996.

   [2] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51,
   RFC 1661, July 1994.

11. Author's Addresses

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

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

                               PPP Mux                  January, 2000


   Email: pazhynnr@cig.mot.com

   Irfan Ali
   Motorola, Network Solutions Sector
   2A8, 1421 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 6]

                               PPP Mux                  January, 2000



Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   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
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   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







































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


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/