summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2823.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2823.txt')
-rw-r--r--doc/rfc/rfc2823.txt1571
1 files changed, 1571 insertions, 0 deletions
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]
+