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