idnits 2.17.1 

draft-takefman-pppext-transper-00.txt:
  ** The Abstract section seems to be numbered


  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-24) 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 -- however, there's a paragraph with a matching
     beginning. Boilerplate error?

  ** 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

  == The page length should not exceed 58 lines per page, but there was 1
     longer page, the longest (page 1) being 205 lines


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack an Abstract section.
     (A line matching the expected section header was found, but with an
    unexpected indentation:
     ' 1. Abstract' )

  ** The document seems to lack an Introduction section.
     (A line matching the expected section header was found, but with an
    unexpected indentation:
     ' 2. Introduction' )

  ** The document seems to lack a Security Considerations section.
     (A line matching the expected section header was found, but with an
    unexpected indentation:
     ' 5. Security Considerations' )

  ** 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.)

  ** There are 12 instances of too long lines in the document, the longest
     one being 5 characters in excess of 72.

  ** There are 13 instances of lines with control characters in the document.

  ** The abstract seems to contain references ([2], [1]), which it shouldn't.
      Please replace those with straight textual mentions of the documents in
     question.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The "Author's Address" (or "Authors' Addresses") section title is
     misspelled.

  -- 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.)

  -- Couldn't find a document date in the document -- date freshness check
     skipped.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Missing reference section? '1' on line 164 looks like a reference

  -- Missing reference section? '2' on line 166 looks like a reference


     Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	 Internet-Draft                                             M. Takefman
3	 							    R. Broberg
4	                                                            Cisco Systems

6								    P. Lothberg
7								    Sprint

9	                                                         July 31st, 1998

11	             Enabling Byte Stuffing Transparency for RFC-1619
12	                <draft-takefman-pppext-transper-00.txt

14	 Status of this Memo

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 months
22	    and may be updated, replaced, or obsoleted by other documents at any
23	    time.  It is inappropriate to use Internet- Drafts as reference
24	    material or to cite them other than as ``work in progress.''

26	    To learn the current status of any Internet-Draft, please check the
27	    ``1id-abstracts.txt'' listing contained in the Internet- Drafts
28	    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
29	    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
30	    ftp.isi.edu (US West Coast).

32	    This memo provides information for the Internet community.  This memo
33	    does not specify an Internet standard of any kind.  Distribution of
34	    this memo is unlimited.

36	 1. Abstract

38	    Recent Internet Draft submissions and discussion on the PPP
39	    Extensions Working Group email list have highlighted transparency
40	    issues with the PPP over SONET/SDH mapping described in IETF RFC1619
41	    and RFC1549. The HDLC byte stuffing described by RFC1549 can result
42	    in a worst case expansion of the actual payload data by a factor of
43	    2. An algorithm suggested below limits the expansion factor to be a
44	    maximum of 6% the actual data to be transported.

46	 2. Introduction

48	    Byte synchronous PPP (as described in RFC1549) is technique for link
49	    layer encoding of data streams on byte boundaries to maintain data
50	    transparency. The transparency processing used in PPP causes
51	    expansion of the data stream that is dependant on the contents of
52	    the data stream. On average the expansion factor is small enough to
53	    be ignored. However, a worst case expansion would result in the
54	    reduction of the available bandwidth by a factor of 2.

56	    Transparency processing is required in order to allow frame
57	    deliniation and the passage of control characters. Transparency
58	    processing ensures that control characters (0x7E, 0x7D) do not
59	    appear within the encoded data stream that is mapped into the
60	    payload. When a control character is encountered during
61	    the encoding phase the link layer inserts an escape character
62	    (0x7D) into the output stream and then XORs the control character
63	    with the value 0x20. This operation is referred to as stuffing as
64	    it results in one byte being represented by two. The receiver
65	    operation is quite simple, anytime an escape character is
66	    encountered it is deleted and the following character is XORed with
67	    0x20.

69	    The following example shows part of a data stream before and after
70	    stuffing:

72	    pre-stuff 0x01 0x02 0x7E 0x7D 0x05 0x7D 0x06 0x7E 0x08

74	    post-stuff 0x01 0x02 0x7D 0x5e 0x7D 0x5D 0x05 0x7D 0x5D 0x06 0x7D
75	    0x5E 0x08

77	    Assuming a random data stream there is a 2 in 256 chance that a
78	    stuffing operation will occur. Therefore, the average expansion factor
79	    (due to stuffing) of a PPP encoded stream will be less than 1%.

81	    The worst case expansion will occur if the frame to be transmitted
82	    consists of control characters. In this case, the expansion factor
83	    will be 100%, as every byte is transformed into 2 output bytes.

85	 3. An option to PPP syncronous byte stuffing

87	    While the worst case expansion scenario is highly unlikely, it is
88	    always prudent to avoid problems, however unlikely, when possible.
89	    The following stuffing compression scheme provides a method for
90	    bounding the expansion factor.

92	    The key concept in this compression scheme is to recognize when
93	    stuff operations will occur within 32 bytes of each other. In this
94	    case, a new encoding can allow a single stuff operation to replace 2
95	    stuff operations. An escape character is inserted into the data stream
96	    followed by a character encoded as follows:

98	 	Bit	Value / Description
99	 	7	1 to differentiate from the standard encoding.
100	 	6	1 if the first stuff operation is a 0x7E.
101	 		0 if the first stuff operation is a 0x7D.
102	 	5	1 if the second stuff operation is a 0x7E.
103	 		0 if the second stuff operation is a 0x7D.
104	 	4:0	the number of bytes between the stuff operations
105	 		0 indicates adjacent bytes.
106	 		31 indicates that 31 bytes are between the control characters.

108	    The second byte requiring stuffing is deleted from the stream as it
109	    has already been sent within the encoded byte.

111	    For the example stream shown above no expansion occurs and the post-stuff
112	    encoding is given by:

114	 		0x01 0x02 0x7D 0xC0 0x05 0x7D 0xA1 0x08

116	    At the receiver, when a 0x7D is encounter the MSB of the next byte
117	    is checked to determine if the compressed stuffing operation
118	    occured. If so the escape character is deleted and the first
119	    compressed character is output and a counter is loaded with the
120	    distance value. If the counter is zero, the next byte to be output is
121	    the second compressed control character. Otherwise, the bytes following
122	    the encoded stuff byte are output, and the counter is decremented for
123	    each byte. Once the counter reaches zero the second compressed character
124	    is output.

126	    Compression does not extend across frame boundaries. Therefore the
127	    transmitter/receiver resets the compression/decompression state
128	    whenever the end of frame is found.

130	    Assume a large packet that starts with a control character and
131	    then has another control character every 33 characters. The
132	    first 33 characters will be transmitted as 34 characters. This
133	    repeats until the end of packet. The efficiency is therefore 34/33
134	    or 1.030303. The degenerate case is when all packets are 34 bytes
135	    long with a control character at the begining and end. In this case
136	    the transmitted packet is 36 bytes long and the efficiency is therefore
137	    36/34 or 1.058824.

139	 4. Recommendations

141	    It is recommended that this be considered an optional feature for
142	    Packet Over Sonet links as defined by RFC1619. An implementation
143	    done by one of the authors at 622mbits/second leads us to believe
144	    that this can be scaled to 10gigabits/second. An RFC1619
145	    implementation with the modification described above limits the
146	    maximum payload expansion to less than 6% thereby removing any
147	    concerns regarding the actual contents of the data.

149	 5. Security Considerations

151	    RFC1619 as currently proposed does have what may be considered a
152	    weakness in that the available bandwidth of a given link is a
153	    function the data to be transported across that link.

155	    Given that POS links currently are aggregated from many smaller links
156	    it is considered highly unlikely that a malicous user could effect
157	    any serious harm on a link. Although the likelyhood of a steady
158	    stream of control characters passing across the link is extremely
159	    small the above algorithm is offered as way to bound the expansion
160	    to less than 6%.

162	 6. References

164	    [1] W. Simpson, "PPP over SONET/SDH," RFC 1619, May 1994.

166	    [2] W. Simpson, "PPP in HDLC-like Framing," RFC 1549, December 1993.

168	 7. Author Addresses

170	    M. Takefman
171	    Cisco Systems
172	    146 Colonnade Road
173	    Suite 201
174	    Nepean, Ontario
175	    Canada K2E7Y1

177	    Email: tak@cisco.com

179	    R. Broberg
180	    Cisco Systems
181	    170 West Tasman Drive
182	    San Jose, CA 94513
183	    USA

185	    Email: rbroberg@cisco.com

187	    Peter Lothberg
188	    Sprint
189	    VARESA0104
190	    12502 Sunrise Valley Drive
191	    Reston VA, 20196

193	    Email: roll@stupi.se