As per Relevance of the word standards, we have this rfc below:
Network Working Group R.
Request for Comments: 3153 I.
Category: Standards Track
C.
Cisco
August 2001
PPP
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document describes a method to reduce the PPP (Point-to-
Protocol) framing overhead used to transport small packets over
links
1.
The method, PPP Multiplexing, sends multiple PPP encapsulated
in a single PPP frame. As a result, the PPP overhead per packet
reduced. PPP encapsulation (for example with PPP in HDLC framing
adds several bytes of overhead: a HDLC flag (at least one to
adjacent packets), the Address (0xFF) and Control (0x03) field bytes
a two byte PPP Protocol ID, and the two byte CRC field. Even
the Address and Control Fields negotiated off and the PPP Protocol
compressed, each PPP encapsulated frame will include four bytes
overhead. When PPP frames are tunneled, as in L2TP [1], the L2
overhead per PPP frame is significant
The key idea is to concatenate multiple PPP encapsulated frames
a single PPP multiplexed frame by inserting a delimiter before
beginning of each frame. The description of the delimiters
provided in Subsection 1.1. The delimiters are used by
demultiplexor to separate the PPP frames within the
frame. Each PPP encapsulated frame within the multiplexed frame
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
receive multiplexed frames using the PPP Mux Control
(PPPMuxCP), as described in Section 2. Once PPPMuxCP has
negotiated, the transmitter may choose which PPP frames to multiplex
Frames should not be re-ordered by either the transmitter or
regardless of whether they arrive as part of the PPP
frame or by themselves
The scheme proposed is similar to the concatenated framing
[2]. The key differences are that PPP multiplexing is more
and that it allows concatenation of variable sized frames. This
unlike concatenated framing which restricts all frames to be of
length
As with any concatenation scheme, the implementer has to consider
tradeoff between increased delay for multiplexing/demultiplexing
reduced packet overhead as the length of the multiplexed
increases
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [7].
1.1. Payload
The format of the complete PPP frame along with multiple
for PPP in HDLC-like framing [3] is shown in Figure 1. Note
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
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
Multiplexed Frame (0x0059). The PPP header
options (ACFC and PFC) may be negotiated during LCP
could thus affect the format of this header
Pazhyannur, et al. Standards Track [Page 2]
RFC 3153 PPP Multiplexing August 2001
Length Field
The length field consists of three subfields
1. Protocol Field Flag (PFF):
The PFF refers to the most significant bit of the first byte
each subframe. This one bit field indicates whether the
Protocol ID of the subframe follows the subframe length field
For the first subframe, the PFF bit could be set to zero if
PPP protocol ID of the first subframe is equal to the
PID value negotiated in PPPMuxCP. PFF = 1 indicates that
protocol field is present (and follows the length field)
this subframe. PFF = 0 indicates that the protocol field
absent for this subframe. If PFF = 0 then the PPP Protocol
is the same as that of the preceding subframe with PFF = 1,
it is equal to default PID value of the PPPMuxCP Option for
first subframe. The transmitter is not obligated to remove
PPP Protocol ID for any subframe
2. Length Extension (LXT
This one bit field indicates whether the length field is
byte or two bytes long. If the LXT bit is set, then the
field is two bytes long (a PFF bit, a length extension bit,
14 bits of sub-frame length). If the LXT bit is cleared,
the length field is one byte long (a PFF bit, a
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
length field. However, it does include the PPP Protocol ID
present (i.e., if PFF = 1). If the length of the subframe
less than 64 bytes (less than or equal to 63 bytes), LXT is
to zero and the last six bits of the length field is
subframe length. If the length of the subframe is greater
63 bytes, LXT is set to one and the last 14 bits of the
field is the length of the subframe. The maximum length of
subframe is 16,383 bytes. PPP packets larger than 16,383
will need to be sent in their own PPP frame. A transmitter
not required to multiplex all frames smaller than 16,383 bytes
It may chose to only multiplex frames smaller than
configurable size into a PPP multiplexed frame
Pazhyannur, et al. Standards Track [Page 3]
RFC 3153 PPP Multiplexing August 2001
Protocol Field
This field contains the Protocol Field value for the subframe
This field is optional. If PFF = 1 for a subframe, the
field is present in the subframe, otherwise it is inferred at
receiver
The receiver MUST support Protocol-Field-Compression (PFC) one
two bytes long. The transmitter SHOULD compress PPP Protocol
in this field that have an upper byte of zero (i.e., Protocol
from 0x21 thru 0xFD). This Protocol Field Compression in each
subframe is not related to the negotiation of PFC during
negotiation which affects the length of PPP Multiplexed
Protocol ID
Information Field
This field contains the actual packet being encapsulated.
frame may be included here with the exception of LCP
Request, ACK, NAK and Reject frames and PPP Multiplexed frames
If LCP is renegotiated then PPP Multiplexing MUST be
until the PPP Mux Control Protocol is negotiated
1.2 Transmitter
A simple implementation of the transmitter is provided. During
transmission of a multiplexed PPP frame, the transmitter has a
variable, Last_PID, which is used to hold the most recent value
protocol field in a subframe with PFF=1. At the start of
multiplexing process, Last_PID is set equal to the default PID
negotiated in PPPMuxCP. Also, a user configurable parameter,
subframe length (MAX_SF_LEN), is used to determine the maximum
of a PPP frame which can be multiplexed. The value of MAX_SF_
should be less or equal to the minimum of MRU-2(maximum size
length field) and 16,383 (14 bits).
After transmitting a PPP frame (multiplexed or not) on the channel
the PPP multiplexing logic looks at the buffers that hold the
frames to be transmitted. In case there are multiple frames, the
multiplexing logic checks if the length of the first frame in
buffer is less than or equal to MAX_SF_LEN bytes. If so,
transmitter starts compiling a multiplexed PPP frame with
protocol field value corresponding to PPP Multiplexed Frame (0x59).
For each subframe, the test for deciding to prepend the
field to a subframe is to compare the protocol field value of
subframe to Last_PID. If they are equal, PFF is set to 0 and
protocol field is deleted. If not, PFF is set to 1, the
field is included, after PFC, in the subframe and Last_PID is set
Pazhyannur, et al. Standards Track [Page 4]
RFC 3153 PPP Multiplexing August 2001
the protocol field value of the current subframe. The
criteria in the concatenation process are (i) when the length of
next subframe is greater than MAX_SF_LEN bytes or (ii) the length
the entire PPP frame by including the new subframe exceeds
maximum receive unit (MRU) parameter negotiated during LCP [4],
(iii) there are no more subframes to concatenate
Implementers may choose additionally to implement using timers.
such a case a timeout in addition to the conditions stated above
used as a stopping criteria of the multiplexing process. Moreover
it may be desirable to limit the maximum size of a multiplexed
to be considerably smaller than MRU for reasons of
latency and packet error considerations
1.3 Receiver
If a multiplexed frame, i.e., a frame with Protocol field value
to PPP Multiplexed Frame (0x0059), is received, the frame
demultiplexed in order using the following input
logic. Similar to a transmitter, the receiver has a state
called Last_rcvd_PID, which is the value of the protocol field in
most recently demultiplexed subframe with PFF=1. Last_rcvd_PID
initialized to default PID value negotiated by PPPMuxCP. If PFF=0
for a subframe, Last_rcvd_PID is appended to the beginning of
subframe before handing the subframe, as determined by the
field, to the PPP logic. If PFF=1 for a subframe, Last_rcvd_PID
set to this value and the subframe, as determined by the
field, is passed to PPP logic. The remainder of the frame
returned to the demultiplexor. Each succeeding subframe is
similarly. This processing is complete when the remainder of
frame is empty, or when the size field of a subframe exceeds
amount of data remaining in a packet. In the latter case, there
an error either in the length field of the last subframe or in
length field of one of the previous subframes. In either case
last subframe must be dropped by the demultiplexing logic
It is illegal to put a multiplexed frame within a multiplexed frame
2. PPP Network Control Protocol for PPP Multiplexing (PPPMuxCP
A receiver will offer its ability to received multiplexed frames
negotiating NCP for PPP multiplexing, PPPMuxCP. The protocol
value for a PPPMuxCP frames is 0x8059. PPPMuxCP is similar to
NCPs such as IPCP [6]. A transmitter may not send a
frame unless the peer has offered to receive multiplexed frames
Support of multiplexed frame reception is negotiated in
direction independently. Successful negotiation of PPPMuxCP does
obligate a peer to transmit multiplexed frames
Pazhyannur, et al. Standards Track [Page 5]
RFC 3153 PPP Multiplexing August 2001
As part of the PPPMuxCP negotiation, a 'default PID' option is
negotiated. This enables the transmitter to transmit the
subframe of a PPP multiplexed frame without a PID (PFF=0),
resulting in a saving of one or two bytes. Note that the
of default PID does not require the transmitter to send the
subframe with PFF=0 even if doing so would optimize the transmission
And, as always, the option (and thus the default PID) is
by the receiver, i.e., the receiver will interpret a received
packet using the default PID it offered
LCP frames MUST NOT be sent in Multiplexed frames. The only option
PPPMuxCP is the negotiation of Default PID and is shown
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
3. Interaction with PPP Multilink (MP)
PPP multiplexed frame option is negotiated by an NCP. LCP
negotiated over each member link of a multilink bundle and not on
bundle itself [5]. Thus in case of MP, PPPmux cannot be
for individual links, but only for the bundle
Hence, on the transmitter side PPP multiplexing always occurs
multilink PPP encapsulation. On a link, an MP header (if present
MUST be outside of a PPPmux header (if present). Multilink
must not be sent in Multiplexed frames
4. Interaction with CCP and
PPP multiplexing must be performed below (after) any bundle-level
and/or ECP, and above (before) MP and any per-link CCP and/or 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
Option
An implementation that cannot perform PPPMux above CCP or ECP
issue Protocol-Reject for the per-link forms of CCP and ECP if
has been negotiated
Pazhyannur, et al. Standards Track [Page 6]
RFC 3153 PPP Multiplexing August 2001
5. Security
This document does not impose additional security
beyond those that apply to PPP and header-compression schemes
PPP
6.
The authors would like to thank contributors on the PPPext
list, especially James Carlson, for valuable inputs to this document
7.
[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B
Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
1999.
[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., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti
"The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[6] McGregor, G., "The PPP Internet Protocol Control
(IPCP)", RFC 1332, May 1992.
[7] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
Pazhyannur, et al. Standards Track [Page 7]
RFC 3153 PPP Multiplexing August 2001
8. Author's
Rajesh
Motorola, Network Solutions
1501, W. Shure
Arlington Heights, IL 60004
Phone: (847) 632-4524
EMail: pazhynnr@cig.mot.
Irfan
Motorola, Network Solutions
1501, W. Shure
Arlington Heights, IL 60004
Phone: (847) 632-3281
EMail: fia225@email.mot.
Craig
Cisco
170 W. Tasman
San Jose, CA 95134
Phone: (408) 526-6296
EMail: fox@cisco.
Pazhyannur, et al. Standards Track [Page 8]
RFC 3153 PPP Multiplexing August 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Pazhyannur, et al. Standards Track [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
