PPPext Working Group R. Pazhyannur,
Internet Engineering Task Force I. Ali
Internet Draft Motorola
C. Fox
Cisco Systems
Expires: April 2, 2000 October 2, 2000
PPP Multiplexing
draft-ietf-pppext-pppmux-01.txt
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
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 is 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 October, 2000
demultiplexor to separate the PPP frames within the multiplexed
frame. Each PPP encapsulated frame within the multiplexed frame is
called a PPP subframe.
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 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
[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.
2.1. Payload Format
The format of the complete PPP frame along with multiple subframes
for PPP in HDLC-like framing [3] is shown in Figure 1. 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|L| + + + +P|L| + + + |
| PPP/ +F|X|Len1 + PPP + + +F|X|LenN + PPP + + |
| HDLC +F|T| + Prot. +Info1+ ~ +F|T| + Prot. +InfoN+ CRC |
| Header+ | | + Field1+ + + | | +FieldN + + |
| (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 October, 2000
The length field consists of three subfields:
1. Protocol Field Flag (PFF):
The PFF refers to the most significant bit of the first byte of
each subframe. This one bit field indicates whether the PPP
Protocol ID of the subframe follows the subframe length field.
For the first subframe, the PFF bit could be set to zero if the
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
absent for this subframe. If PFF = 0 then the PPP Protocol ID
is the same as that of the preceding subframe with PFF = 1, or
it is equal to default PID value of the PPPMuxCP Option for the
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
byte or two bytes long. If the LXT bit is set, then the
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
length field. However, it does include the PPP Protocol ID if
present (i.e. if PFF = 1). If the length of the subframe is
less than 64 bytes (less than or equal to 63 bytes), LXT is set
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.
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)
[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 October, 2000
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
variable, Last_PID, which is used to hold the most recent value of
protocol field in a subframe with PFF=1. At the start of the
multiplexing process, Last_PID is set equal to the default PID value
negotiated in PPPMuxCP. Also, a user configurable maximum packet
length for multiplexing, MAX_SF_LEN, could be set which is less than
MRU and 16,384.
After transmitting a PPP frame (multiplexed or not) on the channel,
the PPP multiplexing logic looks at the buffers that 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 MAX_SF_LEN 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 MAX_SF_LEN bytes, 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
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, after PFC, 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 MAX_SF_LEN 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 [4], or
(iii) there are no more subframes to concatenate.
Implementers may choose alternately to implement using timers. In
such a case a timeout in addition to the conditions stated above is
used for the stopping criteria of the multiplexing process.
R. Pazhyannur, I. Ali, C. Fox [Page 4]
PPP Mux October, 2000
2.3 Receiver procedure
If a multiplexed frame, i.e. a frame with Protocol field value equal
to PPP Multiplexed Frame (0x0059), 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_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
field, to the PPP logic. If PFF=1 for a subframe, Last_rcvd_PID is
set to this value and the subframe, as determined by the length
field, is passed to PPP logic. The remainder of the frame is
returned to the demultiplexor. Each succeeding subframe is processed
similarly. This processing is complete when the remainder of the
frame is empty, or when the size field of a subframe exceeds 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 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
value for a PPPMuxCP frames is 0x8059. PPPMuxCP is similar to other
NCPs like IPCP [6]. A transmitter may not send a multiplexed 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.
As part of the PPPMuxCP negotiation, a 'default PID' option is
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 October, 2000
The only option in PPPMuxCP is the negotiation of Default PID and is
shown below
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
multilink PPP encapsulation. On a link, an MP header (if present)
MUST be outside of a PPPmux header (if present). Multilink frames
must not be sent in Multiplexed frames.
5. Interaction with CCP and ECP
Though PPP multiplexing in itself does not place any requirements on
the sequence in which it is performed with respect to compression
and encryption, in order to simplify implementation and ensure
interoperability, PPPmux header MUST always be outside CCP and ECP
header.
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
[1] Townsley, M., et al, "Layer Two Tunneling Protocol "L2TP"", RFC
2661, August 1999.
R. Pazhyannur, I. Ali, C. Fox [Page 6]
PPP Mux October, 2000
[2] Simpson, W., Ed., "PPP LCP extensions", RFC 1570, January, 1994.
[3] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994.
[4] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[5] Sklower, K., et al, "The PPP Multilink Protocol (MP)", RFC 1990,
August 1996.
[6] McGregor, G., "The PPP Internet Protocol Control Protocol
(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 October, 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). 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 languages other than
English.
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
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
R. Pazhyannur, I. Ali, C. Fox [Page 8]
