doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc2118.txt b/doc/rfc/rfc2118.txt
new file mode 100644
index 0000000..f6c0689
--- /dev/null
+++ b/doc/rfc/rfc2118.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                            G. Pall
+Request for Comments: 2118                         Microsoft Corporation
+Category: Informational                                       March 1997
+
+
+
+          Microsoft Point-To-Point Compression (MPPC) Protocol
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   The Point-to-Point Protocol (PPP) [1] provides a standard method for
+   transporting multi-protocol datagrams over point-to-point links.
+
+   The PPP Compression Control Protocol [2] provides a method to
+   negotiate and utilize compression protocols over PPP encapsulated
+   links.
+
+   This document describes the use of the Microsoft Point to Point
+   Compression protocol (also referred to as MPPC in this document) for
+   compressing PPP encapsulated packets.
+
+Table of Contents
+
+   1.     Introduction ..........................................    2
+      1.1       Licensing .......................................    2
+      1.2.      Specification of Requirements ...................    2
+   2.     Configuration Option Format ...........................    3
+   3.     MPPC Packets ..........................................    4
+      3.1       Packet Format....................................    5
+   4. Description of Compressor and Encoding ....................    6
+      4.1       Literal Encoding ................................    7
+      4.2       Copy Tuple Encoding .............................    7
+          4.2.1     Offset Encoding .............................    7
+          4.2.2     Length-of-Match Encoding ....................    7
+      4.3       Synchronization .................................    8
+   SECURITY CONSIDERATIONS ......................................    8
+   REFERENCES ...................................................    9
+   ACKNOWLEDGEMENTS .............................................    9
+   CHAIR'S ADDRESS    ...........................................    9
+   AUTHORS' ADDRESS .............................................    9
+
+
+
+
+
+Pall                         Informational                      [Page 1]
+
+RFC 2118                     MPPC Protocol                    March 1997
+
+
+1.  Introduction
+
+
+   The Microsoft Point to Point Compression scheme is a means of
+   representing arbitrary Point to Point Protocol (PPP) packets in a
+   compressed form. The MPPC algorithm is designed to optimize processor
+   utilization and bandwidth utilization in order to support large
+   number of simultaneous connections. The MPPC algorithm is also
+   optimized to work efficiently in typical PPP scenarios
+   (1500 byte MTU, etc.).
+
+   The MPPC algorithm uses an LZ [3] based algorithm with a sliding
+   window history buffer.
+
+   The MPPC algorithm keeps a continous history so that after 8192 bytes
+   of data has been transmitted compressed there is always 8192 bytes of
+   history to use for compressing, except when the history is flushed.
+
+1.1.  Licensing
+
+   MPPC can only be used in products that implement the Point to Point
+   Protocol AND for the sole purpose of interoperating with other MPPC
+   and Point to Point Protocol implementations.
+
+   Source and object licenses are available on a non-discriminatory
+   basis from Stac Electronics. Please contact:
+
+         Cheryl Poland
+         Stac Electronics
+         12636 High Bluff Drive,
+         San Deigo, CA 92130
+         Phone: (619)794-4534
+         Email: cherylp@stac.com
+
+1.2.  Specification of Requirements
+
+   In this document, several words are used to signify the requirements
+   of the specification.  These words are often capitalized.
+
+   MUST      This word, or the adjective "required", means that the
+             definition is an absolute requirement of the specification.
+
+   MUST NOT  This phrase means that the definition is an absolute
+             prohibition of the specification.
+
+
+
+
+
+
+
+Pall                         Informational                      [Page 2]
+
+RFC 2118                     MPPC Protocol                    March 1997
+
+
+   SHOULD    This word, or the adjective "recommended", means that there
+             may exist valid reasons in particular circumstances to
+             ignore this item, but the full implications MUST be
+             understood and carefully weighed before choosing a
+             different course.
+
+   MAY       This word, or the adjective "optional", means that this
+             item is one of an allowed set of alternatives.  An
+             implementation which does not include this option MUST be
+             prepared to interoperate with another implementation which
+             does include the option.
+
+2.  Configuration Option Format
+
+   Description
+
+      The CCP Configuration Option negotiates the use of MPPC on the
+      link.  By default or ultimate disagreement, no compression is
+      used.
+
+   A summary of the CCP Configuration Option format is shown below.
+   The fields are transmitted from left to right.
+
+    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      |    Length     |        Supported Bits         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |       Supported Bits          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      18
+
+   Length
+
+      6
+
+   Supported Bits
+
+      This field is 4 octets, most significant octet first. The least
+      significant bit in the least significant octet set to 1 indicates
+      desire to negotiate MPPC.
+
+      All other bits MUST be set to 0.
+
+
+
+
+
+Pall                         Informational                      [Page 3]
+
+RFC 2118                     MPPC Protocol                    March 1997
+
+
+3.  MPPC Packets
+
+   Before any MPPC packets may be communicated, PPP must reach the
+   Network-Layer Protocol phase, and the CCP Control Protocol must reach
+   the Opened state.
+
+   Exactly one MPPC datagram is encapsulated in the PPP Information
+   field. The PPP Protocol field indicates type hex 00FD for all
+   compressed datagrams.
+
+   The maximum length of the MPPC datagram transmitted over a PPP link
+   is the same as the maximum length of the Information field of a PPP
+   encapsulated packet. Since the history buffer is limited to 8192
+   bytes, this length cannot be greater than 8192 bytes.
+
+   Only packets with PPP Protocol numbers in the range hex 0021 to hex
+   00FA are compressed.  Other packets are not passed thru the MPPC
+   processor and are sent with their original PPP Protocol numbers.
+
+   Padding
+
+      It is recommended that padding not be used with MPPC since it
+      defeats the purpose of compression. If the sender must use padding
+      it MUST negotiate the Self-Describing-Padding Configuration option
+      during LCP phase and use self-describing pads.
+
+   Reliability and Sequencing
+
+      The MPPC scheme does not require a reliable link.  Instead, it
+      relies on a 12 bit coherency count in each packet to keep the
+      history buffers synchronized.  If the receiver recognizes that the
+      coherency count received in the packet does not match the count it
+      is expecting, it sends a CCP Reset-Request packet to resynchronize
+      its history buffer with the sender's history buffer.
+
+      MPPC expects the packets to be delivered in sequence, otherwise
+      history buffer re-synchronization will not occur.
+
+      MPPC MAY be used over a reliable link, as described in "PPP
+      Reliable Transmision" [5], but this typically just adds
+      unnecessary overhead since only the coherency count is required.
+
+   Data Expansion
+
+      If compressing the data results in data expansion, the original
+      data is sent as an uncompressed MPPC packet. The sender must flush
+      the history before compressing any more data and set the FLUSHED
+      bit on the next outgoing packet.
+
+
+
+Pall                         Informational                      [Page 4]
+
+RFC 2118                     MPPC Protocol                    March 1997
+
+
+3.1.  Packet Format
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         PPP Protocol          |A|B|C|D| Coherency Count       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Compressed Data...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   PPP Protocol
+
+      The PPP Protocol field is described in the Point-to-Point Protocol
+      Encapsulation [1].
+
+      When the MPPC compression protocol is successfully negotiated by
+      the PPP Compression Control Protocol, the value is hex 00FD. This
+      value MAY be compressed when Protocol-Field-Compression is
+      negotiated.
+
+   Bit A
+
+      This bit indicates that the history buffer has just been
+      initialized before this packet was generated.  This packet can
+      ALWAYS be decompressed because it is not based on any previous
+      history. This bit is typically sent to inform the peer that the
+      sender has initialized its history buffer before compressing the
+      packet and that the receiving peer must initialize its history
+      buffer before decompressing the packet. This bit is referred to as
+      FLUSHED bit in this document.
+
+      Implementation Note: Compression and decompression histories are
+      always initialized with all zeroes.
+
+   Bit B
+
+      This bit indicates that the packet was moved to the front of the
+      history buffer typically because there was no room at the end of
+      the history buffer.  This bit is used to tell the decompressor to
+      set its history pointer to the beginning of the history buffer.
+
+      Implementation Notes:
+      1. It is implied that this bit must be set at least once for every
+         8192 bytes of data that is sent compressed.
+      2. It is also implied that this bit can be set even if the
+         sender's history buffer is not full. Initialized history that
+         has not been used for compressing data must not be referred to
+         in the compressed packets.
+
+
+
+Pall                         Informational                      [Page 5]
+
+RFC 2118                     MPPC Protocol                    March 1997
+
+
+   Bit C
+
+      This bit (if set) is used to indicate that the packet is
+      compressed.
+
+   Bit D
+
+      This bit must be set to 0.
+
+   Coherency Count
+
+      The coherency count is used to assure that the packets are sent in
+      proper order and that no packet has been dropped.  This count
+      starts at 0 and is always increased by 1 and NEVER decreases or
+      goes back. When all bits are 1, the count returns to 0.
+
+   Compressed Data
+
+      The compressed data begins with the protocol field.  For example,
+      in case of an IP packet (0021 followed by an IP header), the
+      compressor will first try to compress the 0021 protocol field and
+      then compress the IP header.
+
+      If the packet contains header compression, the MPPC compressor is
+      applied AFTER header compression is preformed and MUST be applied
+      to the compressed header as well.  For example, if a packet
+      contained the protocol 002d for a compressed TCP/IP header, the
+      compressor would first attempt to compress 002d and then it
+      would attempt to compress the compressed Van-Jacobsen TCP/IP
+      header.
+
+4. Description of Compressor and Encoding
+
+   The compressor runs through the length of the frame producing as
+   output a Literal (byte to be sent uncompressed) or a <Offset,
+   Length-of-Match> Copy tuple, where Offset is the number of bytes
+   before in the history where the match lies and Length-of-Match is the
+   number of bytes to copy from the location indicated by Offset.
+
+   For example, comsider the following string:
+
+   0         1         2         3         4
+   012345678901234567890123456789012345678901234567890
+   for whom the bell tolls, the bell tolls for thee.
+
+   The compressor would produce:
+
+   for whom the bell tolls,<16,15> <40,4><19,3>e.
+
+
+
+Pall                         Informational                      [Page 6]
+
+RFC 2118                     MPPC Protocol                    March 1997
+
+
+   The Literal and Copy tuple tokens are then encoded according to the
+   MPPC encoding scheme.
+
+4.1 Literal Encoding
+
+   Literals are bytes sent uncompressed. If the value of the Literal is
+   below hex 80, it is encoded with its value itself. If the Literal has
+   value greater than hex 7F it is sent as bits 10 followed by the lower
+   7 bits of the Literal.
+
+   Example: Literal hex 56 is transmitted as  01010110
+            Literal hex E7 is transmitted as 101100111
+
+4.2 Copy Tuple Encoding
+
+   Copy tuples represent compressed data. A tuple has two elements: the
+   Offset and Length-of-Match. The Offset is encoded before the Length-
+   of-Match.
+
+4.2.1 Offset Encoding
+
+   Offset values less than 64 are encoded as bits 1111 followed by the
+   lower 6 bits of the value.
+
+   Offset values between 64 and 320 are encoded as bits 1110 followed by
+   the lower 8 bits of the computation (value - 64).
+
+   Offset values between 320 and 8191 are encoded as bits 110 followed
+   by the lower 13 bits of the computation (value - 320).
+
+   Examples: Offset value of 3 is encoded as:     1111 000011
+             Offset value of 128 is encoded as:   1110 01000000
+             Offset value of 1024 is encoded as:   110 0001011000000
+
+4.2.2 Length-of-Match Encoding
+
+   Length of 3 is encoded with bit 0.
+
+   Length values from 4 to 7 are encoded as 10 followed by lower 2 bits
+   of the value.
+
+   Length values from 8 to 15 are encoded as 110 followed by lower 3
+   bits of the value.
+
+   Length values from 16 to 31 are encoded as 1110 followed by lower 4
+   bits of the value.
+
+
+
+
+
+Pall                         Informational                      [Page 7]
+
+RFC 2118                     MPPC Protocol                    March 1997
+
+
+   Length values from 32 to 63 are encoded as 11110 followed by lower 5
+   bits of the value.
+
+   Length values from 64 to 127 are encoded as 111110 followed by lower
+   6 bits of the value.
+
+   Length values from 128 to 255 are encoded as 1111110 followed by
+   lower 7 bits of the value.
+
+   Length values from 256 to 511 are encoded as 11111110 followed by
+   lower 8 bits of the value.
+
+   Length values from 512 to 1023 are encoded as 111111110 followed by
+   lower 9 bits of the value.
+
+   Length values from 1024 to 2047 are encoded as 1111111110 followed by
+   lower 10 bits of the value.
+
+   Length values from 2048 to 4095 are encoded as 11111111110 followed
+   by lower 11 bits of the value.
+
+   Length values from 4096 to 8191 are encoded as 111111111110 followed
+   by lower 12 bits of the value.
+
+   Examples: Length of 15 is encoded as:           110 111
+             Length of 120 is encoded as:       111110 111000
+             Length of 4097 is encoded as:111111111110 000000000001
+
+   The largest Length value that can be encoded is 8191.
+
+4.3  Synchronization
+
+   Packets may be lost during transfer. If the decompressor maintained
+   coherency count does not match the coherency count received in the
+   compressed packet, the decompressor drops the packet and sends a CCP
+   Reset-Request packet. The compressor on receiving this packet flushes
+   the history buffer and sets the FLUSHED bit in the next packet it
+   sends. The decompressor on receiving a packet with its FLUSHED bit
+   set flushes its history buffer and sets its coherency count to the
+   one transmitted by the compressor in that packet. Thus
+   synchronization is achieved without a CCP Reset-Ack packet.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+Pall                         Informational                      [Page 8]
+
+RFC 2118                     MPPC Protocol                    March 1997
+
+
+References
+
+   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
+         51, RFC 1661, Daydreamer, July 1994.
+
+   [2]   Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
+         1962, Novell, June 1996.
+
+   [3]   Lempel, A. and Ziv, J., "A Universal Algorithm for Sequential
+         Data Compression", IEEE Transactions On Information Theory,
+         Vol. IT-23, No. 3, May 1977.
+
+   [4]   Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July
+         1994.
+
+Acknowledgments
+
+   Thomas Dimitri made significant contributions towards the design and
+   development of Microsoft Point-To-Point Compression Protocol. Robert
+   Friend of Stac Technology provided editoral input.
+
+Chair's Address
+
+   The working group can be contacted via the current chair:
+
+         Karl F. Fox
+         Ascend Communications
+         3518 Riverside Dr., Suite 101
+         Columbus, Ohio  43221
+
+         (614) 451-1883
+
+         EMail: karl@ascend.Com
+
+Author's Address
+
+   Questions about this memo can also be directed to:
+
+         Gurdeep Singh Pall
+         1, Microsoft Way,
+         Redmond, WA 98052
+
+         (206) 882-8080
+
+         Email: gurdeep@microsoft.com
+
+
+
+
+
+
+Pall                         Informational                      [Page 9]
+