From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2823.txt | 1571 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1571 insertions(+) create mode 100644 doc/rfc/rfc2823.txt (limited to 'doc/rfc/rfc2823.txt') diff --git a/doc/rfc/rfc2823.txt b/doc/rfc/rfc2823.txt new file mode 100644 index 0000000..0a33632 --- /dev/null +++ b/doc/rfc/rfc2823.txt @@ -0,0 +1,1571 @@ + + + + + + +Network Working Group J. Carlson +Request for Comments: 2823 Sun Microsystems, Inc. +Category: Experimental P. Langner + Lucent Technologies Microelectronics Group + E. Hernandez-Valencia + J. Manchester + Lucent Technologies + May 2000 + + + PPP over Simple Data Link (SDL) + using SONET/SDH with ATM-like framing + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method for + transporting multi-protocol datagrams over point-to-point links, and + RFCs 1662 [2] and 2615 [3] provide a means to carry PPP over + Synchronous Optical Network (SONET) [4] and Synchronous Digital + Hierarchy (SDH) [5] circuits. This document extends these standards + to include a new encapsulation for PPP called Simple Data Link (SDL) + [6]. SDL provides a very low overhead alternative to HDLC-like + encapsulation, and can also be used on SONET/SDH links. + +Applicability + + This specification is intended for those implementations that use PPP + over high speed point-to-point circuits, both with so-called "dark + fiber" and over public telecommunications networks. Because this + enhanced PPP encapsulation has very low overhead and good hardware + scaling characteristics, it is anticipated that significantly higher + throughput can be attained when compared to other possible SONET/SDH + payload mappings, and at a significantly lower cost for line + termination equipment. + + + + + + +Carlson, et al. Experimental [Page 1] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + SDL is defined over other media types and for other data link + protocols, but this specification covers only the use of PPP over SDL + on SONET/SDH. + + The use of SDL requires the presentation of packet length information + in the SDL header. Thus, hardware implementing SDL must have access + to the packet length when generating the header, and where a router's + input link does not have this information (that is, for non-SDL input + links), the router may be required to buffer the entire packet before + transmission. "Worm-hole" routing is thus at least problematic with + SDL, unless the input links are also SDL. This, however, does not + appear to be a great disadvantage on modern routers due to the + general requirement of length information in other parts of the + system, notably in queuing and congestion control strategies such as + Weighted Fair Queuing [7] and Random Early Detect [8]. + + This document is not a replacement for the existing HDLC-like framing + mandated by RFC 2615 [3]. Instead, the authors intend to gain + implementation experience with this technique for operational and + performance evaluation purposes, and would like to hear from others + either considering or using the protocol as described in this + document. Please see Section 14 of this document for contact + information. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Carlson, et al. Experimental [Page 2] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + +Table of Contents + + 1. Introduction ............................................... 4 + 2. Compliance ................................................. 4 + 3. Physical Layer Requirements ................................ 5 + 3.1. Payload Types ............................................ 5 + 3.2. Control Signals .......................................... 6 + 3.3. Synchronization Modes .................................... 7 + 3.4. Simple-Data-Link LCP Option .............................. 7 + 3.5. Framing .................................................. 8 + 3.6. Framing Example .......................................... 11 + 3.7. Synchronization Procedure ................................ 11 + 3.8. Scrambler Operation ...................................... 12 + 3.9. CRC Generation ........................................... 12 + 3.10. Error Correction ........................................ 13 + 4. Performance Analysis ....................................... 14 + 4.1. Mean Time To Frame (MTTF) ................................ 14 + 4.2. Mean Time To Synchronization (MTTS) ...................... 15 + 4.3. Probability of False Frame (PFF) ......................... 16 + 4.4. Probability of False Synchronization (PFS) ............... 16 + 4.5. Probability of Loss of Frame (PLF) ....................... 16 + 5. The Special Messages ....................................... 16 + 5.1. Scrambler State .......................................... 17 + 5.2. A/B Message .............................................. 17 + 6. The Set-Reset Scrambler Option ............................. 17 + 6.1. The Killer Packet Problem ................................ 17 + 6.2. SDL Set-Reset Scrambler .................................. 18 + 6.3. SDL Scrambler Synchronization ............................ 18 + 6.4. SDL Scrambler Operation .................................. 19 + 7. Configuration Details ...................................... 20 + 7.1. Default LCP Configuration ................................ 20 + 7.2. Modification of the Standard Frame Format ................ 21 + 8. Implementation Details ..................................... 21 + 8.1. CRC Generation ........................................... 21 + 8.2. Error Correction Tables .................................. 23 + 9. Security Considerations .................................... 25 + 10. References ................................................ 25 + 11. Acknowledgments ........................................... 26 + 12. Working Group and Chair Address ........................... 26 + 13. Intellectual Property Notices ............................. 26 + 14. Authors' Addresses ........................................ 27 + 15. Full Copyright Statement .................................. 28 + + + + + + + + + +Carlson, et al. Experimental [Page 3] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + +1. Introduction + + The Path Signal Label (SONET/SDH overhead byte named C2; referred to + as PSL in this document) is intended to indicate the type of data + carried on the path. This data, in turn, is referred to as the SONET + Synchronous Payload Envelope (SPE) or SDH Administrative Unit Group + (AUG). The experimental PSL value of decimal 207 (CF hex) is + currently [3] used to indicate that the SPE contains PPP framed using + RFC 1662 Octet Synchronous (O-S) framing and transmission without + scrambling, and the value 22 (16 hex) is used to indicated PPP framed + using O-S framing and transmission with ATM-style X^43+1 scrambling. + + This document describes a method to enable the use of SDL framing for + PPP over SONET/SDH, and describes the framing technique and + requirements for PPP. While O-S framing on SONET/SDH has a fixed + seven octet overhead per frame plus a worst-case overhead of 100% of + all data octets transmitted, SDL has a fixed eight octet per frame + overhead with zero data overhead. Unlike O-S framing, SDL also + provides positive indication of link synchronization. + + Note: This document describes two new SONET/SDH Path Signal Label + (PSL) values; 23 (17 hex) for SDL with the proposed self synchronous + scrambler and 25 (19 hex) for SDL with the proposed set-reset + scrambler. These values have been allocated by ANSI T1X1.5 and ITU-T + SG-15 for use with SDL over SONET and SDH, and will appear in + subsequent updates of T1.105 (Table 8) and Recommendation G.707 + (Table 7). + +2. Compliance + + In this document, the words that are used to define the significance + of each particular requirement are capitalized. + + These words are: + + * "MUST" + + This word means that the item is an absolute requirement of the + specification. + + * "MUST NOT" + + This phrase means that the item is an absolute prohibition of the + specification. + + + + + + + +Carlson, et al. Experimental [Page 4] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + * "SHOULD" + + This word means that there may exist valid reasons in particular + circumstances to ignore this item, but the full implications + should be understood and the case carefully weighed before + choosing a different course. + + * "SHOULD NOT" + + This phrase means that there may exist valid reasons in particular + circumstances to apply this item, but the full implications should + be understood and the case carefully weighed before choosing a + different course. + + * "MAY" + + This word means that this item is truly optional. One vendor may + choose to include the item because a particular marketplace + requires it or because it enhances the product, for example; + another vendor may omit the same item. + + An implementation is not compliant if it fails to satisfy one or more + of the MUST or MUST NOT requirements for this protocol. An + implementation that satisfies all of the MUST, MUST NOT, SHOULD, and + SHOULD NOT requirements for this protocol is said to be + "unconditionally compliant". One that satisfies all the MUST and + MUST NOT requirements but not all the SHOULD or SHOULD NOT + requirements is said to be "conditionally compliant". + +3. Physical Layer Requirements + + PPP treats SONET/SDH transport as octet-oriented synchronous links. + No provision is made to transmit partial octets. Also, SONET/SDH + links are full-duplex by definition. + +3.1. Payload Types + + Only synchronous payloads STS-1 and higher are considered in this + document. Lower speed synchronous, such as VT1.5-SPE/VC-11, and + plesiochronous payload mappings, such as T1 and T3, are defined for + SONET/SDH and for the SDL algorithm itself, but, since HDLC-like + framing is defined for PPP on those media, PPP over SDL is not + defined. + + SDL is separately defined as a PPP transport for use on raw fiber + without SONET/SDH framing for use as an alternative to bit- + synchronous HDLC. Please see the separate work-in-progress for + details. + + + +Carlson, et al. Experimental [Page 5] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + +3.2. Control Signals + + The PPP over SONET/SDH mapping allows the use of the PSL as a control + signal. Not all equipment, however, is capable of setting or + detecting this value, and any use must take this into account. + Equipment employing only SDL MUST be capable of transmitting PSL with + value 23, and MAY also be capable of transmitting PSL with value 25, + but need not be capable of detecting the peer's value or capable of + changing its own value. + + There are two methods to enable SDL, an LCP-negotiated method and a + prior-arrangement method. The former allows for easier configuration + and compatibility with existing equipment, while the latter allows + general use with separate SONET/SDH transmission equipment with PSL + limitations. Both types of implementations will freely interoperate + given the procedures below. + + LCP-negotiated systems MUST be capable of changing their transmitted + PSL value and detecting the peer's value. Equipment without these + features MUST NOT support LCP negotiation of SDL. + + When SDL is negotiated by LCP, LCP negotiation MUST be started with + the PSL value initially set to 22 or 207 and the corresponding non- + SDL O-S PPP encapsulation MUST be used. The SDL LCP option is then + placed in the LCP Configure-Request messages transmitted. On + reception of LCP Configure-Request with an SDL LCP option or when the + peer's transmitted PSL value is received as 23 (or 25), the + implementation MUST shut down LCP by sending a Down event to its + state machine, then switch its transmitted PSL value to 23 (or 25), + switch encapsulation mode to SDL, wait for SDL synchronization, and + then restart LCP by sending an Up event into LCP. Otherwise, if the + peer does not transmit PSL value 23 (or 25) and it does not include + the SDL LCP option in its LCP Configure-Request messages, then + operation using non-SDL O-S PPP encapsulation continues. If the + received PSL value subsequently received reverts from 23 (or 25) to + any other value, then this is treated as a Down event into the LCP + state machine, and an Up event MUST be generated if the new value is + recognized as a valid PPP framing mode. + + When SDL is enabled by prior arrangement, the PSL SHOULD be + transmitted as 23 (or 25). Any other value may also be used by prior + external arrangement with the peer, although the values 22 and 207 + are discouraged. (Such use is enforced by an administrator, and is + outside the scope of this specification.) When SDL is enabled by + prior arrangement, the SDL LCP option SHOULD NOT be negotiated by the + peers. + + + + + +Carlson, et al. Experimental [Page 6] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + An implementation-specific configuration option SHOULD exist to + enable the use of prior-arrangement versus LCP-negotiated modes. + This option SHOULD be presented to an administrator, and SHOULD + default to LCP-negotiated if the hardware permits. Otherwise, if the + hardware implementation precludes non-SDL modes of operation, then it + MUST default to prior-arrangement mode. + + The LCP-negotiated method of operation is compatible with the current + version of G.783 [12]. This method may not be compatible, however, + with some non-intrusive SDH path monitoring equipment based on + obsolete versions of G.783. The change in PSL value indicated by the + LCP negotiation method will cause this equipment to declare an alarm + condition on the path. For this reason, the prior-arrangement method + MUST be used on any SDH network that is using such monitoring + equipment. + +3.3. Synchronization Modes + + Unlike O-S encapsulation, SDL provides a positive indication that it + has achieved synchronization with the peer. An SDL PPP + implementation MUST provide a means to temporarily suspend PPP data + transmission (both user data and negotiation traffic) if + synchronization loss is detected. An SDL PPP implementation SHOULD + also provide a configurable timer that is started when SDL is + initialized and restarted on the loss of synchronization, and is + terminated when link synchronization is achieved. If this timer + expires, implementation-dependent action should be taken to report + the hardware failure. + +3.4. Simple-Data-Link LCP Option + + A new LCP Configuration Option is used to request Simple Data Link + (SDL) [6] operation for the PPP link. + + A summary of the Simple-Data-Link Configuration Option format for the + Link Control Protocol (LCP) is shown below. The fields are + transmitted from left to right. + + + + + + + + + + + + + + +Carlson, et al. Experimental [Page 7] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 29 + + Length + + 2 + + This option is used only as a hint to the peer that SDL over + SONET/SDH operation is preferred by the sender. If the current + encapsulation mode is not SDL, then the only appropriate response to + reception of this option by an SDL speaker is to then switch the + encapsulation mode to SDL (as detailed in the section above) and + restart LCP. Non SDL-speakers SHOULD instead send LCP Configure- + Reject for the option. + + If either LCP Configure-Nak or LCP Configure-Reject is received for + this option, then the next transmitted LCP Configure-Request MUST NOT + include this option. If LCP Configure-Ack with this option is + received, it MUST NOT be treated as a request to switch into SDL + mode. If the received LCP Configure-Request message does not contain + an SDL LCP option, an implementation MUST NOT send an unsolicited + Configure-Nak for the option. + + (An implementation of SDL that is already in SDL framing mode and + receives this option in an LCP Configure-Request message MAY, both + for clarity and for convergence reasons, elect to send LCP + Configure-Ack. It MUST NOT restart LCP nor change framing modes in + this case.) + +3.5. Framing + + The PPP frames are located by row within the SPE payload. Because + frames are variable in length, the frames are allowed to cross SPE + boundaries. Bytes marked as "overhead" or "fixed stuff" in SONET/SDH + documentation for concatenated streams are not used as payload bytes. + + With reference to the Lucent SDL specification [6] when SDL framing + for PPP is employed, the SDL "Datagram Offset" feature is set to the + value 4. This corresponds to the fixed overhead value 4 in the + + + + + +Carlson, et al. Experimental [Page 8] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + description below. The "A" and "B" messages are never used. These + optional features of SDL are not described in this document, but are + rather described in Lucent's SDL specification. + + Fixing the Datagram Offset value described in the Lucent + documentation to 4 allows a PPP MRU/MTU up to 65536 using SDL. + + SDL framing is in general accomplished by the use of a four octet + header on the packet. This fixed-length header allows the use of a + simple framer to detect synchronization as described in section 3.7. + For use with PPP, this fixed-length header precedes each PPP/HDLC + packet as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Length | Header CRC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PPP packet (beginning with address and control fields) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ..... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SDL CRC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The four octet length header is DC balanced by exclusive-OR (also + known as "modulo 2 addition") with the hex value B6AB31E0. This is + the maximum transition, minimum sidelobe, Barker-like sequence of + length 32. No other scrambling is done on the header itself. + + Packet Length is an unsigned 16 bit number in network byte order. + Unlike the PPP FCS, the Header CRC is a CRC-16 generated with initial + value zero and transmitted in network byte order. The PPP packet is + scrambled, begins with the address and control fields, and may be any + integral octet length (i.e., it is not padded unless the Self + Describing Padding option is used). The Packet CRC is also + scrambled, and has a mode-dependent length (described below), and is + located only on an octet boundary; no alignment of this field may be + assumed. + + When the Packet Length value is 4 or greater, the distance in octets + between one message header and the next in SDL is the sum of 8 plus + the Packet Length field. The value 8 represents a fixed overhead of + 4 octets plus the fixed length of the Packet CRC field. When the + Packet Length is 0, the distance to the next header is 4 octets. + This is the idle fill header. When the Packet Length is 1 to 3, the + + + + + +Carlson, et al. Experimental [Page 9] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + distance to the next header is 12 octets. These headers are used for + special SDL messages used only with optional scrambling and + management modes. See section 5 for details of the messages. + + General SDL, like PPP, allows the use of no CRC, ITU-T CRC-16, or + ITU-T CRC-32 for the packet data. However, because the Packet Length + field does not include the CRC length, synchronization cannot be + maintained if the CRC type is changed per RFC 1570 [9], because + frame-to-frame distance is, as described above, calculated including + the CRC length. Thus, this PPP over SDL specification fixes the CRC + type to CRC-32 (four octets), and all SDL implementations MUST reject + any LCP FCS Alternatives Option [9] requested by the peer when in SDL + mode. + + PPP over SDL implementations MAY allow a configuration option to set + different CRC types for use by prior arrangement. Any such + configurable option MUST default to CRC-32, and MUST NOT include LCP + negotiation of FCS Alternatives. + + Setting the SDL Datagram Offset value to 4 accounts for the 4 octet + SDL header overhead. With the SDL Datagram Offset set to 4, the + value placed in the Packet Length field is exactly the length in + octets of the PPP frame itself, including the address and control + fields but not including the CRC field (the RFC 1662 PPP FCS field is + not used with SDL). Note again that the Datagram Offset is just an + arithmetic value; it does not occupy bits in the message itself. + + Because Packet Lengths below 4 are reserved, the Packet Length MUST + be 4 or greater for any legal PPP packet. PPP packets with fewer + octets, which are not possible without address/control or protocol + field compression, MUST be padded to length 4 for SDL. + + Inter-packet time fill is accomplished by sending the four octet + length header with the Packet Length set to zero. No provision is + made for intra-packet time fill. + + By default, an independent, self-synchronous x^43+1 scrambler is used + on the data portion of the message including the 32 bit CRC. This is + done in exactly the same manner as with the ATM x^43+1 scrambler on + an ATM channel. The scrambler is not clocked when SDL header bits + are transmitted. Thus, the data scrambling MAY be implemented in an + entirely independent manner from the SDL framing, and the data stream + may be prescrambled before insertion of SDL framing marks. + + Optionally, by prior arrangement, SDL links MAY use a set-reset + scrambler as described in section 6. If this option is provided, it + MUST be configurable by the administrator, and the option MUST + default to the self-synchronous scrambler. + + + +Carlson, et al. Experimental [Page 10] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + +3.6. Framing Example + + To help clarify this structure, the following example may be helpful. + First we have an LCP Configure-Request message that we wish to + transmit over SDL: + + FF 03 C0 21 01 01 00 04 + + Next, we create an SDL header for the length of this packet (8 + octets), a header CRC, and an SDL CRC. + + 00 08 81 08 FF 03 C0 21 01 01 00 04 D1 F5 21 5E + + Finally, we DC-balance the header with the barker-like sequence: + + B6 A3 B0 E8 FF 03 C0 21 01 01 00 04 D1 F5 21 5E + + Note that the final length of the message is 8 (original message + length) plus 4 (fixed datagram offset value) plus 4 (fixed CRC + length), or 16 octets. + +3.7. Synchronization Procedure + + The link synchronization procedure is similar to the I.432 section + 4.5.1.1 ATM HEC delineation procedure [10], except that the SDL + messages are variable length. The machine starts in HUNT state until + a four octet sequence in the data stream with a valid CRC-16 is + found. (Note that the CRC-16 single-bit error correction technique + described in section 3.10 is not employed until the machine is in in + SYNCH state. The header must have no bit errors in order to leave + HUNT state.) Such a valid sequence is a candidate SDL header. On + finding the valid sequence, the machine enters PRESYNCH state. Any + one invalid SDL header in PRESYNCH state returns the link to HUNT + state. + + If a second valid SDL header is seen after entering PRESYNCH state, + then the link enters SYNCH state and PPP transmission is enabled. If + an invalid SDL header is detected, then the link is returned to HUNT + state without enabling PPP transmission. + + Once the link enters SYNCH state, the SDL header single bit error + correction logic is enabled (see section 3.10). Any unrecoverable + header CRC error returns the link to HUNT state, disables PPP + transmission, and disables the error correction logic. + + + + + + + +Carlson, et al. Experimental [Page 11] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + +3.8. Scrambler Operation + + The transmit and receive scramblers are shift registers with 43 + stages that MAY be initialized to all-ones when the link is + initialized. Synchronization is maintained by the data itself. + + Transmit Receive + + DATA-STREAM (FROM PPP) IN (FROM SDL FRAMER) + | | + v | + XOR<-------------------------+ +->D0-+->D1-> ... ->D41->D42-+ + | | | | + +->D0-+->D1-> ... ->D41->D42-+ XOR<-------------------------+ + | | + v v + OUT (TO SDL FRAMER) DATA-STREAM (TO PPP) + + Each XOR is an exclusive-or gate; also known as a modulo-2 adder. + Each Dn block is a D-type flip-flop clocked on the appropriate data + clock. + + The scrambler is clocked once after transmission or reception of each + bit of payload and before the next bit is applied as input. Bits + within an octet are, per SONET/SDH practice, transmitted and received + MSB-first. + +3.9. CRC Generation + + The CRC-16 and CRC-32 generator polynomials used by SDL are the ITU-T + polynomials [11]. These are: + + x^16+x^12+x^5+1 + + x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1 + + The SDL Header CRC and the CRC-16 used for each of the three special + messages (scrambler state, message A, and message B; see section 5) + are all generated using an initial remainder value of 0000 hex. + + The optional CRC-16 on the payload data (this mode is not used with + PPP over SDL except by prior arrangement) uses the initial remainder + value of FFFF hex for calculation and the bits are complemented + before transmission. The final CRC remainder, however, is + transmitted in network byte order, unlike the regular PPP FCS. If + the CRC-16 algorithm is run over all of the octets including the + appended CRC itself, then the remainder value on intact packets will + + + + +Carlson, et al. Experimental [Page 12] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + always be E2F0 hex. Alternatively, an implementation may stop CRC + calculation before processing the appended CRC itself, and do a + direct comparison. + + The CRC-32 on the payload data (used for PPP over SDL) uses the + initial remainder value of FFFFFFFF hex for calculation and the bits + are complemented before transmission. The CRC, however, is + transmitted in network byte order, most significant bit first, unlike + the optional PPP 32 bit FCS, which is transmitted in reverse order. + The remainder value on intact packets when the appended CRC value is + included in the calculation is 38FB2284. + + C code to generate these CRCs is found in section 8.1. + +3.10. Error Correction + + The error correction technique is based on the use of a Galois number + field, as with the ATM HEC correction. In a Galois number field, + f(a+b) = f(a) + f(b). Since the CRC-16 used for SDL forms such a + field, we can state that CRC(message+error) = CRC(message) + + CRC(error). Since the CRC-16 remainder of a properly formed message + is always zero, this means that, for the N distinct "error" strings + corresponding to a single bit error, there are N distinct CRC(error) + values, where N is the number of bits in the message. + + A table look-up is thus applied to the CRC-16 residue after + calculation over the four octet SDL header to correct bit errors in + the header and to detect multiple bit errors. For the optional set- + reset scrambler, a table look-up is similarly applied to the CRC-16 + residue after calculation over the eight octet scrambler state + message to correct bit errors and to detect multiple bit errors. + (This second correction is also used for the special SDL A and B + messages, which are not used for PPP over SDL.) + + Note: No error correction is performed for the payload. + + Note: This error correction technique is used only when the link has + entered SYNCH state. While in HUNT or PRESYNCH state, error + correction should not be performed, and only messages with syndrome + 0000 are accepted. If the calculated syndrome does not appear in + this table, then an unrecoverable error has occurred. Any such error + in the SDL header will return the link to HUNT state. + + Since the CRC calculation is started with zero, the two tables can be + merged. The four octet table is merely the last 32 entries of the + eight octet table. + + + + + +Carlson, et al. Experimental [Page 13] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + Eight octet (64 bit) single bit error syndrome table (in + hexadecimal): + + FD81 F6D0 7B68 3DB4 1EDA 0F6D 8FA6 47D3 + ABF9 DDEC 6EF6 377B 93AD C1C6 60E3 B861 + D420 6A10 3508 1A84 0D42 06A1 8B40 45A0 + 22D0 1168 08B4 045A 022D 8906 4483 AA51 + DD38 6E9C 374E 1BA7 85C3 CAF1 ED68 76B4 + 3B5A 1DAD 86C6 4363 A9A1 DCC0 6E60 3730 + 1B98 0DCC 06E6 0373 89A9 CCC4 6662 3331 + 9188 48C4 2462 1231 8108 4084 2042 1021 + + Thus, if the syndrome 6EF6 is seen on an eight octet message, then + the third bit (hex 20) of the second octet is in error. Similarly, + if 48C4 is seen on an eight octet message, then the second bit (hex + 40) in the eighth octet is in error. For a four octet message, the + same two syndromes would indicate a multiple bit error for 6EF6, and + a single bit error in the second bit of the fourth octet for 48C4. + + Note that eight octet messages are used only for the optional set- + reset scrambling mode, described in section 6. + + Corresponding C code to generate this table is found in section 8.2. + +4. Performance Analysis + + There are five general statistics that are important for framing + algorithms. These are: + + MTTF Mean time to frame + MTTS Mean time to synchronization + PFF Probability of false frame + PFS Probability of false synchronization + PLF Probability of loss of frame + + The following sections summarize each of these statistics for SDL. + Details and mathematic development can be found in the Lucent SDL + documentation [6]. + +4.1. Mean Time To Frame (MTTF) + + This metric measures the amount of time required to establish correct + framing in the input data. This may be measured in any convenient + units, such as seconds or bytes. For SDL, the relevant measurement + is in packets, since fragments of packets are not useful. + + + + + + +Carlson, et al. Experimental [Page 14] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + In order to calculate MTTF, we must first determine how often the + frame detection state machine is "unavailable" because it failed to + detect the next incoming SDL frame in the data stream. + + Since the probability of a false header detection using CRC-16 in + random data is 2^-16 and this rate is large compared to the allowable + packet size, it is worthwhile to run multiple parallel frame- + detection state machines. Each machine starts with a different + candidate framing point in order to reduce the probability of falsely + detecting user data as a valid frame header. + + The results for this calculation, given maximal 64KB packets and + slightly larger than Internet average 354 byte packets, are: + + Number of Unavailability Unavailability + Framers 64KB packets 354 byte pkts + 1 3.679E-1 5.373E-3 + 2 3.083E-2 1.710E-6 + 3 2.965E-3 9.712E-10 + 4 2.532E-4 4.653E-13 + + Using these values, MTTF can be calculated as a function of the Bit + Error Rate (BER). These plots show a characteristically flat region + for all BERs up to a knee, beyond which the begins to rise sharply. + In all cases, this knee point has been found to occur at a BER of + approximately 1E-4, which is several orders of magnitude above that + observed on existing SONET/SDH links. The flat rate values are + summarized as: + + Number of Flat region Flat region + Framers 64KB packets 354 bytes + 1 3.58 1.52 + 2 1.595 1.5 + 3 1.52 1.5 + 4 1.5 1.5 + + Thus, for common packet sizes in an implementation with two parallel + framers using links with a BER of 1E-4 or better, the MTTF is + approximately 1.5 packets. This is also the optimal time, since it + represents initiating framing at an average point half-way into one + packet, and achieving good framing after seeing exactly one correctly + framed packet. + +4.2. Mean Time To Synchronization (MTTS) + + The MTTS for SDL with a self-synchronous scrambler is the same as the + MTTF, or 1.5 packets. + + + + +Carlson, et al. Experimental [Page 15] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + The MTTS for SDL using the optional set-reset scrambler is one half + of the scrambling state transmission interval (in packets) plus the + MTTF. For insertion at the default rate of one per eight packets, + the MTTS is 5.5 packets. + + (The probability of receiving a bad scrambling state transmission + should also be included in this calculation. The probability of + random corruption of this short message is shown in the SDL document + [6] to be small enough that it can be neglected for this + calculation.) + +4.3. Probability of False Frame (PFF) + + The PFF is 2.328E-10 (2^-32), since false framing requires two + consecutive headers with falsely correct CRC-16. + +4.4. Probability of False Synchronization (PFS) + + The PFS for SDL with the self-synchronous scrambler is the same as + the PFF, or 2.328E-10 (2^-32). + + The PFS for SDL with the set-reset scrambler is 5.421E-20 (2^-64), + and is calculated as the PFF above multiplied by the probability of a + falsely detected scrambler state message, which itself contains two + independent CRC-16 calculations. + +4.5. Probability of Loss of Frame (PLF) + + The PLF is a function of the BER, and for SDL is approximately the + square of the BER multiplied by 500, which is the probability of two + or more bit errors occurring within the 32 bit SDL header. Thus, at + a BER of 1E-5, the PLF is 5E-8. + +5. The Special Messages + + When the SDL Packet Length field has any value between 0000 and 0003, + the message following the header has a special, pre-defined length. + The 0 value is a time-fill on an idle link, and no other data + follows. The next octet on the link is the first octet of the next + SDL header. + + The values 1 through 3 are defined in the following subsections. + These special messages each consist of a six octet data portion + followed by another CRC-16 over that data portion, as with the SDL + header, and this CRC is used for single bit error correction. + + + + + + +Carlson, et al. Experimental [Page 16] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + +5.1. Scrambler State + + The special value of 1 for Packet Length is reserved to transfer the + scrambler state from the transmitter to the receiver for the optional + set-reset scrambler. In this case, the SDL header is followed by six + octets (48 bits) of scrambler state. Neither the scrambler state nor + the CRC are scrambled. + +5.2. A/B Message + + The special values of 2 and 3 for Packet Length are reserved for "A" + and "B" messages, which are also six octets in length followed by two + octets of CRC-16. Each of these eight octets are scrambled. No use + for these messages with PPP SDL is defined. These messages are + reserved for use by link maintenance protocols, in a manner analogous + to ATM's OAM cells. + +6. The Set-Reset Scrambler Option + + PPP over SDL uses a self-synchronous scrambler. SDL implementations + MAY also employ a set-reset scrambler to avoid some of the possible + inherent problems with self-synchronous scramblers. + +6.1. The Killer Packet Problem + + Scrambling in general solves two problems. First, SONET and SDH + interfaces require a minimum density of bit transitions in order to + maintain hardware clock recovery. Since data streams frequently + contain long runs of all zeros or all ones, scrambling the bits using + a pseudo-random number sequence breaks up these patters. Second, all + link-layer synchronization mechanisms rely on detecting long-range + patterns in the received data to detect framing. + + Self-synchronous scramblers are an easy way to partially avoid these + problems. One problem that is inherent with self-synchronous, + however, is that long user packets from malicious sites can make use + of the known properties of these scramblers to inject either long + strings of zeros or other synchronization-destroying patterns into + the link. For public networks, where the data presented to the + network is usually multiplexed (interleaved) with multiple unrelated + streams, the clocking problem does not pose a significant threat to + the public network. It does, however, pose a threat to the PPP- + speaking device, and it poses a threat to long lines that are + unchannelized. + + Such carefully constructed packets are called "killer packets". + + + + + +Carlson, et al. Experimental [Page 17] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + +6.2. SDL Set-Reset Scrambler + + An alternative to the self-synchronous scrambler is the externally + synchronized or "set-reset" scrambler. This is a free-running + scrambler that is not affected by the patterns in the user data, and + therefore minimizes the possibility that a malicious user could + present data to the network that mimics an undesirable data pattern. + + The option set-reset scrambler defined for SDL is an + x^48+x^28+x^27+x+1 independent scrambler initialized to all ones when + the link enters PRESYNCH state and reinitialized if the value ever + becomes all zero bits. As with the self-synchronous scrambler, all + octets in the PPP packet data following the SDL header through the + final packet CRC are scrambled. + + This mode MAY be detected automatically. If a scrambler state + message is received (as described in the following section), an SDL + implementation that includes the set-reset scrambler option may + switch from self-synchronous into set-reset mode automatically. An + SDL implementation that does not include the set-reset scrambler MUST + NOT send scrambler state messages. + +6.3. SDL Scrambler Synchronization + + As described in the previous section, the special value of 1 for + Packet Length is reserved to transfer the scrambler state from the + transmitter to the receiver. In this case, the SDL header is + followed by six octets (48 bits) of scrambler state plus two octets + of CRC-16 over the scrambler state. None of these eight octets are + scrambled. + + SDL synchronization consists of two components, link and scrambler + synchronization. Both must be completed before PPP data flows on the + link. + + If a valid SDL header is seen in PRESYNCH state, then the link enters + SYNCH state, and the scrambler synchronization sequence is started. + If an invalid SDL header is detected, then the link is returned to + HUNT state, and PPP transmission is suspended. + + When scrambler synchronization is started, a scrambler state message + is sent (Packet Length set to 1 and six octets of scrambler state in + network byte order follow the SDL header). When a scrambler + synchronization message is received from the peer, PPP transmission + is enabled. + + + + + + +Carlson, et al. Experimental [Page 18] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + Scrambler state messages are periodically transmitted to keep the + peers in synchronization. A period of once per eight transmitted + packets is suggested, and it SHOULD be configurable. Excessive + packet CRC errors detected indicates an extended loss of + synchronization and should trigger link resynchronization. + + On reception of a scrambler state message, an SDL implementation MUST + compare the received 48 bits of state with the receiver's scrambler + state. If any of these bits differ, then a synchronization slip + error is declared. After such an error, the next valid scrambler + state message received MUST be loaded into the receiver's scrambler, + and the error condition is then cleared. + +6.4. SDL Scrambler Operation + + The transmit and receive scramblers are shift registers with 48 + stages that are initialized to all-ones when the link is initialized. + Each is refilled with all one bits if the value in the shift register + ever becomes all zeros. This scrambler is not reset at the beginning + of each frame, as is the SONET/SDH X^7+X^6+1 scrambler, nor is it + modified by the transmitted data, as is the ATM self-synchronous + scrambler. Instead it is kept in synchronization using special SDL + messages. + + +----XOR<--------------XOR<---XOR<----------------+ + | ^ ^ ^ | + | | | | | + +->D0-+->D1-> ... ->D26-+->D27-+->D28-> ... ->D47-+ + | + v + OUT + + Each XOR is an exclusive-or gate; also known as a modulo-2 adder. + Each Dn block is a D-type flip-flop clocked on the appropriate data + clock. + + The scrambler is clocked once after transmission of each bit of SDL + data, whether or not the transmitted bit is scrambled. When + scrambling is enabled for a given octet, the OUT bit is exclusive- + ored with the raw data bit to produce the transmitted bit. Bits + within an octet are transmitted MSB-first. + + Reception of scrambled data is identical to transmission. Each + received bit is exclusive-ored with the output of the separate + receive data scrambler. + + + + + + +Carlson, et al. Experimental [Page 19] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + To generate a scrambler state message, the contents of D47 through D0 + are snapshot at the point where the first scrambler state bit is + sent. D47 is transmitted as the first bit of the output. The first + octet transmitted contains D47 through D40, the second octet D39 + through D32, and the sixth octet D7 through D0. + + The receiver of a scrambler state message MUST first run the CRC-16 + check and correct algorithm over this message. If the CRC-16 message + check detects multiple bit errors, then the message is dropped and is + not processed further. + + Otherwise, it then should compare the contents of the entire receive + scrambler state D47:D0 with the corrected message. (By pipelining + the receiver with multiple clock stages between SDL Header error- + correction block and the descrambling block, the receive descrambler + will be on the correct clock boundary when the message arrives at the + descrambler. This means that the decoded scrambler state can be + treated as immediately available at the beginning of the D47 clock + cycle into the receive scrambler.) + + If any of the received scrambler state bits is different from the + corresponding shift register bit, then a soft error flag is set. If + the flag was already set when this occurs, then a synchronization + slip error is declared. This error SHOULD be counted and reported + through implementation-defined network management procedures. When + the receiver has this soft error flag set, any scrambler state + message that passes the CRC-16 message check without multiple bit + errors is clocked directly into the receiver's state register after + the comparison is done, and the soft error flag is then cleared. + Otherwise, while uncorrectable scrambler state messages are received, + the soft error flag state is maintained. + + (The intent of this mechanism is to reduce the likelihood that a + falsely corrected scrambler state message with multiple bit errors + can corrupt the running scrambler state.) + +7. Configuration Details + +7.1. Default LCP Configuration + + The LCP synchronous configuration defaults apply to SONET/SDH links. + + The following Configuration Options are recommended: + + Magic Number + No Address and Control Field Compression + No Protocol Field Compression + No FCS alternatives (32-bit FCS default) + + + +Carlson, et al. Experimental [Page 20] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + This configuration means that PPP over SDL generally presents a 32- + bit aligned datagram to the network layer. With the address, + control, and protocol field intact, the PPP overhead on each packet + is four octets. If the SDL framer presents the SDL packet header to + the PPP input handling in order to communicate the packet length (the + Lucent implementation does not do this, but other hardware + implementations may), this header is also four octets, and alignment + is preserved. + +7.2. Modification of the Standard Frame Format + + Since SDL does take the place of HDLC as a transport for PPP, it is + at least tempting to remove the HDLC-derived overhead. This is not + done for PPP over SDL in order to preserve the message alignment and + to allow for the future possibility interworking with other services + (e.g., Frame Relay). + + By prior external arrangement or via LCP negotiation, any two SDL + implementations MAY agree to omit the address and control fields or + implement protocol field compression on a link. Such use is not + described by this document and MUST NOT be the default on any SDL + implementation. + +8. Implementation Details + +8.1. CRC Generation + + The following unoptimized code generates proper CRC-16 and CRC-32 + values for SDL messages. Note that the polynomial bits are numbered + in big-endian order for SDL CRCs; bit 0 is the MSB. + + typedef unsigned char u8; + typedef unsigned short u16; + typedef unsigned long u32; + + #define POLY16 0x1021 + #define POLY32 0x04C11DB7 + + u16 + crc16(u16 crcval, u8 cval) + { + int i; + + crcval ^= cval << 8; + for (i = 8; i--; ) + crcval = crcval & 0x8000 ? (crcval << 1) ^ POLY16 : + crcval << 1; + return crcval; + + + +Carlson, et al. Experimental [Page 21] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + } + + u32 + crc32(u32 crcval, u8 cval) + { + int i; + + crcval ^= cval << 24; + for (i = 8; i--; ) + crcval = crcval & 0x80000000 ? (crcval << 1) ^ POLY32 : + crcval << 1; + return crcval; + } + + u16 + crc16_special(u8 *buffer, int len) + { + u16 crc; + + crc = 0; + while (--len >= 0) + crc = crc16(crc,*buffer++); + return crc; + } + + u16 + crc16_payload(u8 *buffer, int len) + { + u16 crc; + + crc = 0xFFFF; + while (--len >= 0) + crc = crc16(crc,*buffer++); + return crc ^ 0xFFFF; + } + + u32 + crc32_payload(u8 *buffer, int len) + { + u32 crc; + + crc = 0xFFFFFFFFul; + while (--len >= 0) + crc = crc32(crc,*buffer++); + return crc ^ 0xFFFFFFFFul; + } + + + + + +Carlson, et al. Experimental [Page 22] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + void + make_sdl_header(int packet_length, u8 *buffer) + { + u16 crc; + + buffer[0] = (packet_length >> 8) & 0xFF; + buffer[1] = packet_length & 0xFF; + crc = crc16_special(buffer,2); + buffer[0] ^= 0xB6; + buffer[1] ^= 0xAB; + buffer[2] = ((crc >> 8) & 0xFF) ^ 0x31; + buffer[3] = (crc & 0xFF) ^ 0xE0; + } + +8.2. Error Correction Tables + + To generate the error correction table, the following implementation + may be used. It creates a table called sdl_error_position, which is + indexed on CRC residue value. The tables can be used to determine if + no error exists (table entry is equal to FE hex), one correctable + error exists (table entry is zero-based index to errored bit with MSB + of first octet being 0), or more than one error exists, and error is + uncorrectable (table entry is FF hex). To use for eight octet + messages, the bit index from this table is used directly. To use for + four octet messages, the index is treated as an unrecoverable error + if it is below 32, and as bit index plus 32 if it is above 32. + + The program also prints out the error syndrome table shown in section + 3.10. This may be used as part of a "switch" statement in a hardware + implementation. + + u8 sdl_error_position[65536]; + + /* Calculate new CRC from old^(byte<<8) */ + u16 + crc16_t8(u16 crcval) + { + u16 f1,f2,f3; + + f1 = (crcval>>8) | (crcval<<8); + f2 = (crcval>>12) | (crcval&0xF000) | ((crcval>>7)&0x01E0); + f3 = ((crcval>>3) & 0x1FE0) ^ ((crcval<<4) & 0xF000); + return f1^f2^f3; + } + + + + + + + +Carlson, et al. Experimental [Page 23] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + void + generate_error_table(u8 *bptab, int nbytes) + { + u16 crc; + int i, j, k; + + /* Marker for no error */ + bptab[0] = 0xFE; + + /* Marker for >1 error */ + for (i = 1; i < 65536; i++ ) + bptab[i] = 0xFF; + + /* Mark all single bit error cases. */ + printf("Error syndrome table:\n"); + for (i = 0; i < nbytes; i++) { + putchar(' '); + + for (j = 0; j < 8; j++) { + crc = 0; + for (k = 0; k < i; k++) + crc = crc16_t8(crc); + crc = crc16_t8(crc ^ (0x8000>>j)); + for (k++; k < nbytes; k++) + crc = crc16_t8(crc); + bptab[crc] = (i * 8) + j; + printf(" %04X",crc); + } + putchar('\n'); + } + } + + int + main(int argc, char **argv) + { + u8 buffer[8] = { + 0x01,0x55,0x02,0xaa, + 0x99,0x72,0x18,0x56 + }; + u16 crc; + int i; + + generate_error_table(sdl_error_position,8); + + /* Run sample message through check routine. */ + crc = 0; + for (i = 0; i < 8; i++) + crc = crc16_t8(crc ^ (buffer[i]<<8)); + + + +Carlson, et al. Experimental [Page 24] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + /* Output is 0000 64 -- no error encountered. */ + printf("\nError test: CRC %04X, bit position %d\n", + crc,sdl_error_position[crc]); + } + +9. Security Considerations + + The reliability of public SONET/SDH networks depends on well-behaved + traffic that does not disrupt the synchronous data recovery + mechanisms. This document describes framing and scrambling options + that are used to ensure the distribution of transmitted data such + that SONET/SDH design assumptions are not likely to be violated. + +10. References + + [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + [2] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC + 1662, July 1994. + + [3] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June + 1999. + + [4] "American National Standard for Telecommunications - + Synchronous Optical Network (SONET) Payload Mappings," ANSI + T1.105.02-1995. + + [5] ITU-T Recommendation G.707, "Network Node Interface for the + Synchronous Digital Hierarchy (SDH)," March 1996. + + [6] Doshi, B., Dravida, S., Hernandez-Valencia, E., Matragi, W., + Qureshi, M., Anderson, J., Manchester, J.,"A Simple Data Link + Protocol for High Speed Packet Networks", Bell Labs Technical + Journal, pp. 85-104, Vol.4 No.1, January-March 1999. + + [7] Demers, A., S. Keshav, and S. Shenker, "Analysis and simulation + of a fair queueing algorithm," ACM SIGCOMM volume 19 number 4, + pp. 1-12, September 1989. + + [8] Floyd, S. and V. Jacobson, "Random Early Detection Gateways for + Congestion Avoidance," IEEE/ACM Transactions on Networking, + August 1993. + + [9] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January + 1994. + + + + + +Carlson, et al. Experimental [Page 25] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + [10] ITU-T Recommendation I.432.1, "B-ISDN User-Network Interface - + Physical Layer Specification: General Characteristics," + February 1999. + + [11] ITU-T Recommendation V.41, "Code-independent error-control + system," November 1989. + + [12] ITU-T Recommendation G.783, "Characteristics of synchronous + digital hierarchy (SDH) equipment functional blocks," April + 1997. + +11. Acknowledgments + + PPP over SONET was first proposed by Craig Partridge (BBN) and is + documented by Andrew Malis and William Simpson as RFC 2615. + + Much of the material in this document was supplied by Lucent. + + Other length-prefixed forms of framing for PPP have gone before SDL, + such as William Simpson's "PPP in Ether-like Framing" expired draft. + +12. Working Group and Chair Address + + The working group can be contacted via the mailing list (ietf- + ppp@merit.edu; send mail to ietf-ppp-request@merit.edu to subscribe), + or via the current chair: + + Karl Fox + Extant, Inc. + 3496 Snouffer Road, Suite 100 + Columbus, Ohio 43235 + + EMail: karl@extant.net + +13. Intellectual Property Notices + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + + + + + +Carlson, et al. Experimental [Page 26] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +14. Authors' Addresses + + James Carlson + Sun Microsystems, Inc. + 1 Network Drive MS UBUR02-212 + Burlington MA 01803-2757 + + Phone: +1 781 442 2084 + Fax: +1 781 442 1677 + EMail: james.d.carlson@sun.com + + + Paul Langner + Lucent Technologies Microelectronics Group + 555 Union Boulevard + Allentown PA 18103-1286 + + EMail: plangner@lucent.com + + + Enrique J. Hernandez-Valencia + Lucent Technologies + 101 Crawford Corners Rd. + Holmdel NJ 07733-3030 + + EMail: enrique@lucent.com + + + James Manchester + Lucent Technologies + 101 Crawford Corners Rd. + Holmdel NJ 07733-3030 + + EMail: sterling@hotair.hobl.lucent.com + + + + + + + +Carlson, et al. Experimental [Page 27] + +RFC 2823 PPP SDL on SONET/SDH May 2000 + + +15. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Carlson, et al. Experimental [Page 28] + -- cgit v1.2.3