idnits 2.17.1 draft-ietf-pppext-gandalf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 74: '...ber. This value MAY be compressed whe...' RFC 2119 keyword, line 77: '...Protocol packets MUST NOT be sent with...' RFC 2119 keyword, line 121: '...hex. This value MAY be compressed whe...' RFC 2119 keyword, line 160: '...t implement this information MUST send...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1993) is 11144 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dave Carr 2 Internet Draft Gandalf 3 expires in six months October 1993 5 PPP Gandalf FZA Compression Protocol 6 draft-ietf-pppext-gandalf-00.txt 8 Status of this Memo 10 This document is the product of the Point-to-Point Protocol Working 11 Group of the Internet Engineering Task Force (IETF). Comments should 12 be submitted to the ietf-ppp@ucdavis.edu mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a 25 ``working draft'' or ``work in progress.'' 27 Please check the 1id-abstracts.txt listing contained in the 28 internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 29 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 30 current status of any Internet Draft. 32 Abstract 34 The Point-to-Point Protocol (PPP) [1] provides a standard method for 35 transporting multi-protocol datagrams over point-to-point links. 37 The PPP Compression Control Protocol [2] provides a method to 38 negotiate and utilize compression protocols over PPP encapsulated 39 links. 41 This document describes the use of the Gandalf FZA data compression 42 algorithm for compressing PPP encapsulated packets. 44 1. Introduction 46 FZA is a high performance LZA derivative which maximizes compression 47 at the expense of memory and CPU. Compression performance can be 48 adjusted based on CPU and memory available. 50 Multiple PPP packets can be combined in a single compressed frame, or 51 a single PPP packet can be spread across multiple frames. 53 1.1. Licensing 55 Source and object licenses are available on a non-discriminatory 56 basis for either a royalty or fixed price arrangement. Patent 57 indemnity is included with the license. 59 2. FZA Packets 61 Before any FZA packets may be communicated, PPP must reach the 62 Network-Layer Protocol phase, and the CCP Control Protocol must reach 63 the Opened state. 65 Exactly one FZA datagram is encapsulated in the PPP Information 66 field, where the PPP Protocol field indicates type hex 00FD 67 (compressed datagram). 69 The maximum length of the FZA datagram transmitted over a PPP link is 70 the same as the maximum length of the Information field of a PPP 71 encapsulated packet. 73 Prior to compression, the uncompressed data begins with the PPP 74 Protocol number. This value MAY be compressed when Protocol-Field- 75 Compression is negotiated. 77 PPP Link Control Protocol packets MUST NOT be sent within compressed 78 data. 80 Padding 82 The FZA packets require the negotiation of the Self-Describing- 83 Padding Configuration Option [3] at LCP Link Establishment. 85 Reliability and Sequencing 87 The FZA algorithm expects a reliable link, as described in "PPP 88 Reliable Transmission" [4]. 90 Gandalf FZA expects the packets to be delivered in sequence. 92 Data Expansion 94 The maximum expansion of Gandalf FZA is 2:1. However, typical 95 expansion on pre-compressed data is 1.01:1. Expanded data is sent 96 to maintain the integrity of the compression history. 98 When the expansion exceeds the size of the peer's Maximum Receive 99 Unit for the link, the expanded packet is sent in multiple PPP 100 frames. The compressed data contains an indication of the end of 101 the original packet. 103 2.1. Packet Format 105 A summary of the Gandalf FZA packet format is shown below. The 106 fields are transmitted from left to right. 108 0 1 2 3 109 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 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | PPP Protocol | Compressed Data ... 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 PPP Protocol 116 The PPP Protocol field is described in the Point-to-Point Protocol 117 Encapsulation [1]. 119 When the Gandalf FZA compression protocol is successfully 120 negotiated by the PPP Compression Control Protocol [2], the value 121 is 00FD hex. This value MAY be compressed when Protocol-Field- 122 Compression is negotiated. 124 Compressed Data 126 The compressed PPP encapsulated packet. 128 3. Configuration Option Format 130 Description 132 The CCP Gandalf-FZA Configuration Option negotiates the use of 133 Gandalf FZA on the link. By default or ultimate disagreement, no 134 compression is used. 136 A summary of the Gandalf-FZA Configuration Option format is shown 137 below. The fields are transmitted from left to right. 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Type | Length | History | Data ... 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Type 147 6 149 Length 151 >= 3 153 History 155 The History field specifies the maximum size of the compression 156 history in powers of 2. Valid values range from 12 to 15. 158 Data 159 Zero or more octets of additional configuration information. Any 160 implementation which does not implement this information MUST send 161 a Configure-Nak without this field. 163 Security Considerations 165 Security issues are not discussed in this memo. 167 References 169 [1] Simpson, W.A., "The Point-to-Point Protocol (PPP)", work in 170 progress. 172 [2] Rand, D., "The PPP Compression Control Protocol (CCP)", work in 173 progress. 175 [3] Simpson, W.A., "PPP LCP Extensions", work in progress. 177 [4] Rand, D., "PPP Reliable Transmission", work in progress. 179 Acknowledgments 181 Editting and formatting by Bill Simpson. 183 Chair's Address 185 The working group can be contacted via the current chair: 187 Fred Baker 188 Advanced Computer Communications 189 315 Bollay Drive 190 Santa Barbara, California 93117 192 EMail: fbaker@acc.com 194 Author's Address 196 Questions about this memo can also be directed to: 198 Dave Carr 199 Gandalf Data Limited 200 130 Colonnade Road South 201 Napean, Ontario, Canada K2E 7M4 203 (613) 723-6500 204 (613) 226-1717 Fax 206 Email: dcarr@gandalf.ca 207 Table of Contents 209 1. Introduction .......................................... 1 210 1.1 Licensing ....................................... 1 212 2. FZA Packets ........................................... 2 213 2.1 Packet Format ................................... 3 215 3. Configuration Option Format ........................... 4 217 SECURITY CONSIDERATIONS ...................................... 5 219 REFERENCES ................................................... 5 221 ACKNOWLEDGEMENTS ............................................. 5 223 CHAIR'S ADDRESS .............................................. 6 225 AUTHOR'S ADDRESS ............................................. 6 227 Bill.Simpson@um.cc.umich.edu