doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc3153.txt b/doc/rfc/rfc3153.txt
new file mode 100644
index 0000000..5f47b5a
--- /dev/null
+++ b/doc/rfc/rfc3153.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [7].
+
+1.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.
+
+
+
+
+
+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 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.
+
+
+
+
+
+
+
+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 protocol
+      field is present in the subframe, otherwise it is inferred at the
+      receiver.
+
+      The receiver MUST support Protocol-Field-Compression (PFC) 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 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.
+
+1.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 parameter, maximum
+   subframe length (MAX_SF_LEN), is used to determine the maximum size
+   of a PPP frame which can be multiplexed.  The value of MAX_SF_LEN
+   should be less or equal to the minimum of MRU-2(maximum size of
+   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 PPP
+   frames to be transmitted.  In case there are multiple frames, the PPP
+   multiplexing logic checks if the length of the first frame in the
+   buffer is less than or equal to MAX_SF_LEN bytes.  If so, 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
+
+
+
+Pazhyannur, et al.          Standards Track                     [Page 4]
+
+RFC 3153                    PPP Multiplexing                 August 2001
+
+
+   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 additionally to implement using timers.  In
+   such a case a timeout in addition to the conditions stated above is
+   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.
+
+1.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.
+
+2. 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 such as 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.
+
+
+
+Pazhyannur, et al.          Standards Track                     [Page 5]
+
+RFC 3153                    PPP Multiplexing                 August 2001
+
+
+   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. 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
+
+3. 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.
+
+4. Interaction with CCP and ECP
+
+   PPP multiplexing must be performed below (after) any bundle-level CCP
+   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 PPPMux
+   Option.
+
+   An implementation that cannot perform PPPMux above CCP or ECP MUST
+   issue Protocol-Reject for the per-link forms of CCP and ECP if PPPMux
+   has been negotiated.
+
+
+
+
+
+
+Pazhyannur, et al.          Standards Track                     [Page 6]
+
+RFC 3153                    PPP Multiplexing                 August 2001
+
+
+5. Security Considerations
+
+   This document does not impose additional security considerations
+   beyond those that apply to PPP and header-compression schemes over
+   PPP.
+
+6. Acknowledgements
+
+   The authors would like to thank contributors on the PPPext mailing
+   list, especially James Carlson, for valuable inputs to this document.
+
+7. References
+
+   [1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B.
+       Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August
+       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 Protocol
+       (IPCP)", RFC 1332, May 1992.
+
+   [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pazhyannur, et al.          Standards Track                     [Page 7]
+
+RFC 3153                    PPP Multiplexing                 August 2001
+
+
+8. 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
+   EMail: fox@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pazhyannur, et al.          Standards Track                     [Page 8]
+
+RFC 3153                    PPP Multiplexing                 August 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pazhyannur, et al.          Standards Track                     [Page 9]
+