idnits 2.17.1 draft-narten-ppp-over-sonet-to-historic-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-23) 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 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 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** 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. 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 (August 7, 1998) is 9391 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) == Unused Reference: 'RFC 1662' is defined on line 63, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1619 (Obsoleted by RFC 2615) -- Possible downref: Non-RFC (?) normative reference: ref. 'G.707' -- Possible downref: Normative reference to a draft: ref. 'POS' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Thomas Narten 2 IBM 3 4 August 7, 1998 6 PPP Over SONET Applicability Statement for Historic Status 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Distribution of this memo is unlimited. 30 This Internet Draft expires February, 1999. 32 1. Introduction 34 PPP over Sonet [RFC 1619] uses "HDLC-like framing" as defined in [RFC 35 1662]. These documents were developed to address a void in existing 36 SONET standards at that time. 38 T1.X1 is the ANSI accredited T1 Technical Subcommitee responsible for 39 developing SONET standards, including SONET rates, formats and 40 payload mappings. Its output is also brought into the ITU, for 41 example as in ITU-T Recommendation G.707 [G.707]. 43 At the December, 1997 IETF in Washington DC, a BOF was held to 44 discuss a potential weakness in previous mappings. Specifically, long 45 packets (where "long" can include those carried by PPP) containing a 46 special bit pattern can cause a SONET reciever to declare a "loss of 47 signal". The minutes of the BOF are included in Appendix A. 49 T1.X1 has recently defined a mapping for HDLC over SONET [T1.105.02, 50 T1.105] that addresses the potential weakness described above. The 51 work done by T1.X1 on SONET supersedes past efforts that have taken 52 place within the IETF. The recommendation of this applicability 53 statement is that all PPP over SONET implementations use the 54 combination of RFC 1662 plus "Packet Over Sonet/SDH" [POS]. The first 55 document describes how to encapsulate PPP in HDLC; the second 56 document describes how to encapsulate HDLC in SONET. We also 57 recommend that RFC 1619 be reclassified as Historic. 59 2. References 61 [RFC 1619] Simpson, W., "PPP over SONET/SDH", RFC 1619, May 1994. 63 [RFC 1662] Simpson, W., "PPP in HDLC-like Framing", RFC 1662, July 64 1994. 66 [T1.105.02] ANSI T1.105.02 "Synchronous Optical Network (SONET) - 67 Payload Mappings" 69 [T1.105] ANSI T1.105 "Synchronous Optical Network (SONET) - Basic 70 Description including Multiplex Structure, Rates and 71 Formats". 73 [G.707] CCITT Recommendation G.707, "Synchronous Digital Hierarchy 74 Bit Rates", 1998 (??? - XXX). 75 [POS] Narten, T., "Packet over Sonet/SDH", draft-narten-packet- 76 over-sonet-00.txt. 78 3. Author's Address 80 Thomas Narten 81 IBM Corporation 82 3039 Cornwallis Ave. 83 PO Box 12195 - BRQA/502 84 Research Triangle Park, NC 27709-2195 86 Phone: 919-254-7798 87 EMail: narten@raleigh.ibm.com 88 APPENDIX A: Minutes of the PPP Over Sonet/SDH Bof 90 Minutes of the PPP Over Sonet/SDH Bof 10 December 1997 92 Chair: Mike O'Dell 94 Scribe: Frank Kastenholz 96 Agenda: 97 0. Introduction and Agenda-Bashing 98 1. Statement of the Problem 99 2. Stop gaps for the near-term 100 3. Long-term Solution 102 Mike O'Dell opened the meeting, presenting the agenda. There was no 103 agenda-bashing. 105 Peter Lothberg gave a brief talk on what the problem was: 107 If a SONET receiver detects a "long" string of 0s ("no light") 108 then the receiver will declare a "loss of signal". Of course, 109 someone may, legitimately, wish to send a large number of 0s; 110 this should not cause an LOS. 112 In order to prevent this, SONET uses a 'scrambler' which 113 attempts to ensure transmission of a sufficient number of 1s so 114 that the receiver will not declare a false LOS. This scrambler 115 works well for rather short data blocks. However, for long 116 blocks (such as PPP Packets), it is possible to devise packets 117 that, after scrambling, show up on the fiber as a long string of 118 0s (i.e. no light). Of course, it is also possible that such a 119 packet could be generated in the normal course of events (i.e. 120 non-maliciously and non-conciously) 122 Furthermore, an active attack could be launched against the 123 SONET infrastructure from anyplace in the Internet. 125 This is not a real operational issue right now. The current 126 error rates on SONET links (including otherwise unexplained LOS) 127 is well within the nominal error rates expected for SONET. 128 However, since this issue was brought up, there have been some 129 reports of attacks being made. 131 Peter then presented a stop-gap to deal with this issue in the short 132 term. 134 A new scrambler (the "ATM Scrambler") would be inserted between 135 the HDLC Byte-Stuffing and the normal sonet payload scrambler. 137 This has the property that it can be done in software in the 138 near term and migrated into hardware later on. The ATM Scrambler 139 is a 1+X**43 scrambler. This scrambler is well known and easy to 140 implement, is believed to have a sufficient number of states to 141 protect the SONET networks. On the down-side, it does introduce 142 error multiplication (because of the feed-back into the shift- 143 register) and may interact with the CRC-16 of PPP Packets in 144 ways to miss some errors. 146 The error multiplication was deemed not to be a significant 147 issue since once a packet was "errored", it really wasn't all 148 that big a deal if it had n bits of error or 2n bits or... 150 The interaction with CRC-16 can be alleviated in several ways: 151 - Packet header consistancy checks (eg, the packet length and 152 the IP header's Total Length field musth be consistant) 153 - Transport error detection 154 - Use of CRC-32 156 Karl Fox suggested that the PPP/SONET specification be 157 modified to require that CRC32 be used all the time (i.e. 158 not be negotiated, just "always used"). 160 Mike O'Dell then offered as a long-term solution that ANSI T1.X1 do 161 an addendum to T1.105.02 (?) to specify "HDLC Over Sonet". T1.X1 162 would formally adopt the ATM scrambler as a part of this 163 specification. 165 General Discussion then ensued. 167 Bill Simpson recommended that the solution be simple byte stuffing in 168 order to prevent the known bad bit patterns from appearing. 170 There were many comments back and forth on the relative merits of 171 byte stuffing vs 1+X**43 scrambling (which was easier, which was more 172 robust, implementing in hardware vs software, and so forth). 174 A "sense-of-the-BOF" was taken via the time-honored IETF Hum: 175 - The IETF should pursue the 1+X**43 scrambler solution offered by 176 Peter Lothberg for the near-term. 177 - The byte-stuffing technique would not be pursued. 178 - The long-term solution would be an ANSI T1.X1 "HDLC-over-SONET 179 Mapping" which would use the 1+X**43 scrambler. 181 Discussion then turned to the SONET Payload C2 byte. Should a new 182 code be allocated for the "new" (i.e. with 1+X**43 scrambling) 183 payload format? 184 - The current standard (RFC1619) specifies an experimental code 185 point of 207 (0xcf) for the C2 byte. 186 - A new code-point would allow receivers to differentiate new- 187 from old-format payloads. 188 - It was not clear whether all implementations generated or 189 checked the C2-byte code-point, so putting in a new code point 190 might not be a real win. 192 The recommendation of the BOF was that the IETF would not pursue a 193 new code-point and would use the old one for "new-format" packets. 194 However, if and when ANSI T1.X1 recommends a code-point for their 195 mapping, that number should be adopted "with all deliberate haste." 197 ANSI T1X1 expects to make a decision on this in January 1998. Their 198 results will be announced to the PPP Mailing List. 200 Peter Lothberg then made a brief presentation for "Bytes Over Sonet", 201 a proposed new standard, with the following suggested features: 202 - No byte stuffing, length-fields would be used. 203 - A Combined scrambler/CRC 204 - Combined multiple STM-1s 205 - Some kind of TDM 206 A mailing list will be set up: bos@stupi.se. Subscription requests 207 should be sent to bos-request@stupi.se