rfc3153.txt

RFC 的详细文档！

   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: [phone]
   EMail: [e-mail]


   Irfan Ali
   Motorola, Network Solutions Sector
   1501, W. Shure Drive
   Arlington Heights, IL 60004

   Phone: [phone]
   EMail: [e-mail]


   Craig Fox
   Cisco Systems
   170 W. Tasman Street
   San Jose, CA 95134

   Phone: [phone]
   EMail: [e-mail]
























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]