As per Relevance of the word experimental, we have this rfc below:
Network Working Group J.
Request for Comments: 2823 Sun Microsystems, Inc
Category: Experimental P.
Lucent Technologies Microelectronics
E. Hernandez-
J.
Lucent
May 2000
PPP over Simple Data Link (SDL
using SONET/SDH with ATM-like
Status of this
This memo defines an Experimental Protocol for the
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
Copyright (C) The Internet Society (2000). All Rights Reserved
The Point-to-Point Protocol (PPP) [1] provides a standard method
transporting multi-protocol datagrams over point-to-point links,
RFCs 1662 [2] and 2615 [3] provide a means to carry PPP
Synchronous Optical Network (SONET) [4] and Synchronous
Hierarchy (SDH) [5] circuits. This document extends these
to include a new encapsulation for PPP called Simple Data Link (SDL
[6]. SDL provides a very low overhead alternative to HDLC-
encapsulation, and can also be used on SONET/SDH links
This specification is intended for those implementations that use
over high speed point-to-point circuits, both with so-called "
fiber" and over public telecommunications networks. Because
enhanced PPP encapsulation has very low overhead and good
scaling characteristics, it is anticipated that significantly
throughput can be attained when compared to other possible SONET/
payload mappings, and at a significantly lower cost for
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
protocols, but this specification covers only the use of PPP over
on SONET/SDH
The use of SDL requires the presentation of packet length
in the SDL header. Thus, hardware implementing SDL must have
to the packet length when generating the header, and where a router'
input link does not have this information (that is, for non-SDL
links), the router may be required to buffer the entire packet
transmission. "Worm-hole" routing is thus at least problematic
SDL, unless the input links are also SDL. This, however, does
appear to be a great disadvantage on modern routers due to
general requirement of length information in other parts of
system, notably in queuing and congestion control strategies such
Weighted Fair Queuing [7] and Random Early Detect [8].
This document is not a replacement for the existing HDLC-like
mandated by RFC 2615 [3]. Instead, the authors intend to
implementation experience with this technique for operational
performance evaluation purposes, and would like to hear from
either considering or using the protocol as described in
document. Please see Section 14 of this document for
information
Carlson, et al. Experimental [Page 2]
RFC 2823 PPP SDL on SONET/SDH May 2000
Table of
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.
The Path Signal Label (SONET/SDH overhead byte named C2; referred
as PSL in this document) is intended to indicate the type of
carried on the path. This data, in turn, is referred to as the
Synchronous Payload Envelope (SPE) or SDH Administrative Unit
(AUG). The experimental PSL value of decimal 207 (CF hex)
currently [3] used to indicate that the SPE contains PPP framed
RFC 1662 Octet Synchronous (O-S) framing and transmission
scrambling, and the value 22 (16 hex) is used to indicated PPP
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
PPP over SONET/SDH, and describes the framing technique
requirements for PPP. While O-S framing on SONET/SDH has a
seven octet overhead per frame plus a worst-case overhead of 100%
all data octets transmitted, SDL has a fixed eight octet per
overhead with zero data overhead. Unlike O-S framing, SDL
provides positive indication of link synchronization
Note: This document describes two new SONET/SDH Path Signal
(PSL) values; 23 (17 hex) for SDL with the proposed self
scrambler and 25 (19 hex) for SDL with the proposed set-
scrambler. These values have been allocated by ANSI T1X1.5 and ITU-
SG-15 for use with SDL over SONET and SDH, and will appear
subsequent updates of T1.105 (Table 8) and Recommendation G.707
(Table 7).
2.
In this document, the words that are used to define the
of each particular requirement are capitalized
These words are
* "MUST
This word means that the item is an absolute requirement of
specification
* "MUST NOT
This phrase means that the item is an absolute prohibition of
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
circumstances to ignore this item, but the full
should be understood and the case carefully weighed
choosing a different course
* "SHOULD NOT
This phrase means that there may exist valid reasons in
circumstances to apply this item, but the full implications
be understood and the case carefully weighed before choosing
different course
* "MAY
This word means that this item is truly optional. One vendor
choose to include the item because a particular
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
of the MUST or MUST NOT requirements for this protocol.
implementation that satisfies all of the MUST, MUST NOT, SHOULD,
SHOULD NOT requirements for this protocol is said to
"unconditionally compliant". One that satisfies all the MUST
MUST NOT requirements but not all the SHOULD or SHOULD
requirements is said to be "conditionally compliant".
3. Physical Layer
PPP treats SONET/SDH transport as octet-oriented synchronous links
No provision is made to transmit partial octets. Also, SONET/
links are full-duplex by definition
3.1. Payload
Only synchronous payloads STS-1 and higher are considered in
document. Lower speed synchronous, such as VT1.5-SPE/VC-11,
plesiochronous payload mappings, such as T1 and T3, are defined
SONET/SDH and for the SDL algorithm itself, but, since HDLC-
framing is defined for PPP on those media, PPP over SDL is
defined
SDL is separately defined as a PPP transport for use on raw
without SONET/SDH framing for use as an alternative to bit
synchronous HDLC. Please see the separate work-in-progress
details
Carlson, et al. Experimental [Page 5]
RFC 2823 PPP SDL on SONET/SDH May 2000
3.2. Control
The PPP over SONET/SDH mapping allows the use of the PSL as a
signal. Not all equipment, however, is capable of setting
detecting this value, and any use must take this into account
Equipment employing only SDL MUST be capable of transmitting PSL
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
changing its own value
There are two methods to enable SDL, an LCP-negotiated method and
prior-arrangement method. The former allows for easier
and compatibility with existing equipment, while the latter
general use with separate SONET/SDH transmission equipment with
limitations. Both types of implementations will freely
given the procedures below
LCP-negotiated systems MUST be capable of changing their
PSL value and detecting the peer's value. Equipment without
features MUST NOT support LCP negotiation of SDL
When SDL is negotiated by LCP, LCP negotiation MUST be started
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
placed in the LCP Configure-Request messages transmitted.
reception of LCP Configure-Request with an SDL LCP option or when
peer's transmitted PSL value is received as 23 (or 25),
implementation MUST shut down LCP by sending a Down event to
state machine, then switch its transmitted PSL value to 23 (or 25),
switch encapsulation mode to SDL, wait for SDL synchronization,
then restart LCP by sending an Up event into LCP. Otherwise, if
peer does not transmit PSL value 23 (or 25) and it does not
the SDL LCP option in its LCP Configure-Request messages,
operation using non-SDL O-S PPP encapsulation continues. If
received PSL value subsequently received reverts from 23 (or 25)
any other value, then this is treated as a Down event into the
state machine, and an Up event MUST be generated if the new value
recognized as a valid PPP framing mode
When SDL is enabled by prior arrangement, the PSL SHOULD
transmitted as 23 (or 25). Any other value may also be used by
external arrangement with the peer, although the values 22 and 207
are discouraged. (Such use is enforced by an administrator, and
outside the scope of this specification.) When SDL is enabled
prior arrangement, the SDL LCP option SHOULD NOT be negotiated by
peers
Carlson, et al. Experimental [Page 6]
RFC 2823 PPP SDL on SONET/SDH May 2000
An implementation-specific configuration option SHOULD exist
enable the use of prior-arrangement versus LCP-negotiated modes
This option SHOULD be presented to an administrator, and
default to LCP-negotiated if the hardware permits. Otherwise, if
hardware implementation precludes non-SDL modes of operation, then
MUST default to prior-arrangement mode
The LCP-negotiated method of operation is compatible with the
version of G.783 [12]. This method may not be compatible, however
with some non-intrusive SDH path monitoring equipment based
obsolete versions of G.783. The change in PSL value indicated by
LCP negotiation method will cause this equipment to declare an
condition on the path. For this reason, the prior-arrangement
MUST be used on any SDH network that is using such
equipment
3.3. Synchronization
Unlike O-S encapsulation, SDL provides a positive indication that
has achieved synchronization with the peer. An SDL
implementation MUST provide a means to temporarily suspend PPP
transmission (both user data and negotiation traffic)
synchronization loss is detected. An SDL PPP implementation
also provide a configurable timer that is started when SDL
initialized and restarted on the loss of synchronization, and
terminated when link synchronization is achieved. If this
expires, implementation-dependent action should be taken to
the hardware failure
3.4. Simple-Data-Link LCP
A new LCP Configuration Option is used to request Simple Data
(SDL) [6] operation for the PPP link
A summary of the Simple-Data-Link Configuration Option format for
Link Control Protocol (LCP) is shown below. The fields
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
29
2
This option is used only as a hint to the peer that SDL
SONET/SDH operation is preferred by the sender. If the
encapsulation mode is not SDL, then the only appropriate response
reception of this option by an SDL speaker is to then switch
encapsulation mode to SDL (as detailed in the section above)
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
this option, then the next transmitted LCP Configure-Request MUST
include this option. If LCP Configure-Ack with this option
received, it MUST NOT be treated as a request to switch into
mode. If the received LCP Configure-Request message does not
an SDL LCP option, an implementation MUST NOT send an
Configure-Nak for the option
(An implementation of SDL that is already in SDL framing mode
receives this option in an LCP Configure-Request message MAY,
for clarity and for convergence reasons, elect to send
Configure-Ack. It MUST NOT restart LCP nor change framing modes
this case.)
3.5.
The PPP frames are located by row within the SPE payload.
frames are variable in length, the frames are allowed to cross
boundaries. Bytes marked as "overhead" or "fixed stuff" in SONET/
documentation for concatenated streams are not used as payload bytes
With reference to the Lucent SDL specification [6] when SDL
for PPP is employed, the SDL "Datagram Offset" feature is set to
value 4. This corresponds to the fixed overhead value 4 in
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.
optional features of SDL are not described in this document, but
rather described in Lucent's SDL specification
Fixing the Datagram Offset value described in the
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
header on the packet. This fixed-length header allows the use of
simple framer to detect synchronization as described in section 3.7.
For use with PPP, this fixed-length header precedes each PPP/
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 (
known as "modulo 2 addition") with the hex value B6AB31E0. This
the maximum transition, minimum sidelobe, Barker-like sequence
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
value zero and transmitted in network byte order. The PPP packet
scrambled, begins with the address and control fields, and may be
integral octet length (i.e., it is not padded unless the
Describing Padding option is used). The Packet CRC is
scrambled, and has a mode-dependent length (described below), and
located only on an octet boundary; no alignment of this field may
assumed
When the Packet Length value is 4 or greater, the distance in
between one message header and the next in SDL is the sum of 8
the Packet Length field. The value 8 represents a fixed overhead
4 octets plus the fixed length of the Packet CRC field. When
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,
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
special SDL messages used only with optional scrambling
management modes. See section 5 for details of the messages
General SDL, like PPP, allows the use of no CRC, ITU-T CRC-16,
ITU-T CRC-32 for the packet data. However, because the Packet
field does not include the CRC length, synchronization cannot
maintained if the CRC type is changed per RFC 1570 [9],
frame-to-frame distance is, as described above, calculated
the CRC length. Thus, this PPP over SDL specification fixes the
type to CRC-32 (four octets), and all SDL implementations MUST
any LCP FCS Alternatives Option [9] requested by the peer when in
mode
PPP over SDL implementations MAY allow a configuration option to
different CRC types for use by prior arrangement. Any
configurable option MUST default to CRC-32, and MUST NOT include
negotiation of FCS Alternatives
Setting the SDL Datagram Offset value to 4 accounts for the 4
SDL header overhead. With the SDL Datagram Offset set to 4,
value placed in the Packet Length field is exactly the length
octets of the PPP frame itself, including the address and
fields but not including the CRC field (the RFC 1662 PPP FCS field
not used with SDL). Note again that the Datagram Offset is just
arithmetic value; it does not occupy bits in the message itself
Because Packet Lengths below 4 are reserved, the Packet Length
be 4 or greater for any legal PPP packet. PPP packets with
octets, which are not possible without address/control or
field compression, MUST be padded to length 4 for SDL
Inter-packet time fill is accomplished by sending the four
length header with the Packet Length set to zero. No provision
made for intra-packet time fill
By default, an independent, self-synchronous x^43+1 scrambler is
on the data portion of the message including the 32 bit CRC. This
done in exactly the same manner as with the ATM x^43+1 scrambler
an ATM channel. The scrambler is not clocked when SDL header
are transmitted. Thus, the data scrambling MAY be implemented in
entirely independent manner from the SDL framing, and the data
may be prescrambled before insertion of SDL framing marks
Optionally, by prior arrangement, SDL links MAY use a set-
scrambler as described in section 6. If this option is provided,
MUST be configurable by the administrator, and the option
default to the self-synchronous scrambler
Carlson, et al. Experimental [Page 10]
RFC 2823 PPP SDL on SONET/SDH May 2000
3.6. Framing
To help clarify this structure, the following example may be helpful
First we have an LCP Configure-Request message that we wish
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 5
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 5
Note that the final length of the message is 8 (original
length) plus 4 (fixed datagram offset value) plus 4 (fixed
length), or 16 octets
3.7. Synchronization
The link synchronization procedure is similar to the I.432
4.5.1.1 ATM HEC delineation procedure [10], except that the
messages are variable length. The machine starts in HUNT state
a four octet sequence in the data stream with a valid CRC-16
found. (Note that the CRC-16 single-bit error correction
described in section 3.10 is not employed until the machine is in
SYNCH state. The header must have no bit errors in order to
HUNT state.) Such a valid sequence is a candidate SDL header.
finding the valid sequence, the machine enters PRESYNCH state.
one invalid SDL header in PRESYNCH state returns the link to
state
If a second valid SDL header is seen after entering PRESYNCH state
then the link enters SYNCH state and PPP transmission is enabled.
an invalid SDL header is detected, then the link is returned to
state without enabling PPP transmission
Once the link enters SYNCH state, the SDL header single bit
correction logic is enabled (see section 3.10). Any
header CRC error returns the link to HUNT state, disables
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
The transmit and receive scramblers are shift registers with 43
stages that MAY be initialized to all-ones when the link
initialized. Synchronization is maintained by the data itself
Transmit
DATA-STREAM (FROM PPP) IN (FROM SDL FRAMER
| |
v |
XOR<-------------------------+ +->D0-+->D1-> ... ->D41->D42-+
| | | |
+->D0-+->D1-> ... ->D41->D42-+ XOR<-------------------------+
| |
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
clock
The scrambler is clocked once after transmission or reception of
bit of payload and before the next bit is applied as input.
within an octet are, per SONET/SDH practice, transmitted and
MSB-first
3.9. CRC
The CRC-16 and CRC-32 generator polynomials used by SDL are the ITU-
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
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
PPP over SDL except by prior arrangement) uses the initial
value of FFFF hex for calculation and the bits are
before transmission. The final CRC remainder, however,
transmitted in network byte order, unlike the regular PPP FCS.
the CRC-16 algorithm is run over all of the octets including
appended CRC itself, then the remainder value on intact packets
Carlson, et al. Experimental [Page 12]
RFC 2823 PPP SDL on SONET/SDH May 2000
always be E2F0 hex. Alternatively, an implementation may stop
calculation before processing the appended CRC itself, and do
direct comparison
The CRC-32 on the payload data (used for PPP over SDL) uses
initial remainder value of FFFFFFFF hex for calculation and the
are complemented before transmission. The CRC, however,
transmitted in network byte order, most significant bit first,
the optional PPP 32 bit FCS, which is transmitted in reverse order
The remainder value on intact packets when the appended CRC value
included in the calculation is 38FB2284.
C code to generate these CRCs is found in section 8.1.
3.10. Error
The error correction technique is based on the use of a Galois
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
field, we can state that CRC(message+error) = CRC(message) +
CRC(error). Since the CRC-16 remainder of a properly formed
is always zero, this means that, for the N distinct "error"
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
calculation over the four octet SDL header to correct bit errors
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
message to correct bit errors and to detect multiple bit errors
(This second correction is also used for the special SDL A and
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
entered SYNCH state. While in HUNT or PRESYNCH state,
correction should not be performed, and only messages with
0000 are accepted. If the calculated syndrome does not appear
this table, then an unrecoverable error has occurred. Any such
in the SDL header will return the link to HUNT state
Since the CRC calculation is started with zero, the two tables can
merged. The four octet table is merely the last 32 entries of
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 (
hexadecimal):
FD81 F6D0 7B68 3DB4 1EDA 0F6D 8FA6 47D
ABF9 DDEC 6EF6 377B 93AD C1C6 60E3 B861
D420 6A10 3508 1A84 0D42 06A1 8B40 45A
22D0 1168 08B4 045A 022D 8906 4483 AA51
DD38 6E9C 374E 1BA7 85C3 CAF1 ED68 76B
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,
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 (
40) in the eighth octet is in error. For a four octet message,
same two syndromes would indicate a multiple bit error for 6EF6,
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
There are five general statistics that are important for
algorithms. These are
MTTF Mean time to
MTTS Mean time to
PFF Probability of false
PFS Probability of false
PLF Probability of loss of
The following sections summarize each of these statistics for SDL
Details and mathematic development can be found in the Lucent
documentation [6].
4.1. Mean Time To Frame (MTTF
This metric measures the amount of time required to establish
framing in the input data. This may be measured in any
units, such as seconds or bytes. For SDL, the relevant
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
frame detection state machine is "unavailable" because it failed
detect the next incoming SDL frame in the data stream
Since the probability of a false header detection using CRC-16
random data is 2^-16 and this rate is large compared to the
packet size, it is worthwhile to run multiple parallel frame
detection state machines. Each machine starts with a
candidate framing point in order to reduce the probability of
detecting user data as a valid frame header
The results for this calculation, given maximal 64KB packets
slightly larger than Internet average 354 byte packets, are
Number of Unavailability
Framers 64KB packets 354 byte
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
Error Rate (BER). These plots show a characteristically flat
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
approximately 1E-4, which is several orders of magnitude above
observed on existing SONET/SDH links. The flat rate values
summarized as
Number of Flat region Flat
Framers 64KB packets 354
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
framers using links with a BER of 1E-4 or better, the MTTF
approximately 1.5 packets. This is also the optimal time, since
represents initiating framing at an average point half-way into
packet, and achieving good framing after seeing exactly one
framed packet
4.2. Mean Time To Synchronization (MTTS
The MTTS for SDL with a self-synchronous scrambler is the same as
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
of the scrambling state transmission interval (in packets) plus
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
should also be included in this calculation. The probability
random corruption of this short message is shown in the SDL
[6] to be small enough that it can be neglected for
calculation.)
4.3. Probability of False Frame (PFF
The PFF is 2.328E-10 (2^-32), since false framing requires
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
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
falsely detected scrambler state message, which itself contains
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
square of the BER multiplied by 500, which is the probability of
or more bit errors occurring within the 32 bit SDL header. Thus,
a BER of 1E-5, the PLF is 5E-8.
5. The Special
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
follows. The next octet on the link is the first octet of the
SDL header
The values 1 through 3 are defined in the following subsections
These special messages each consist of a six octet data
followed by another CRC-16 over that data portion, as with the
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
The special value of 1 for Packet Length is reserved to transfer
scrambler state from the transmitter to the receiver for the
set-reset scrambler. In this case, the SDL header is followed by
octets (48 bits) of scrambler state. Neither the scrambler state
the CRC are scrambled
5.2. A/B
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
octets of CRC-16. Each of these eight octets are scrambled. No
for these messages with PPP SDL is defined. These messages
reserved for use by link maintenance protocols, in a manner
to ATM's OAM cells
6. The Set-Reset Scrambler
PPP over SDL uses a self-synchronous scrambler. SDL
MAY also employ a set-reset scrambler to avoid some of the
inherent problems with self-synchronous scramblers
6.1. The Killer Packet
Scrambling in general solves two problems. First, SONET and
interfaces require a minimum density of bit transitions in order
maintain hardware clock recovery. Since data streams
contain long runs of all zeros or all ones, scrambling the bits
a pseudo-random number sequence breaks up these patters. Second,
link-layer synchronization mechanisms rely on detecting long-
patterns in the received data to detect framing
Self-synchronous scramblers are an easy way to partially avoid
problems. One problem that is inherent with self-synchronous
however, is that long user packets from malicious sites can make
of the known properties of these scramblers to inject either
strings of zeros or other synchronization-destroying patterns
the link. For public networks, where the data presented to
network is usually multiplexed (interleaved) with multiple
streams, the clocking problem does not pose a significant threat
the public network. It does, however, pose a threat to the PPP
speaking device, and it poses a threat to long lines that
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
An alternative to the self-synchronous scrambler is the
synchronized or "set-reset" scrambler. This is a free-
scrambler that is not affected by the patterns in the user data,
therefore minimizes the possibility that a malicious user
present data to the network that mimics an undesirable data pattern
The option set-reset scrambler defined for SDL is
x^48+x^28+x^27+x+1 independent scrambler initialized to all ones
the link enters PRESYNCH state and reinitialized if the value
becomes all zero bits. As with the self-synchronous scrambler,
octets in the PPP packet data following the SDL header through
final packet CRC are scrambled
This mode MAY be detected automatically. If a scrambler
message is received (as described in the following section), an
implementation that includes the set-reset scrambler option
switch from self-synchronous into set-reset mode automatically.
SDL implementation that does not include the set-reset scrambler
NOT send scrambler state messages
6.3. SDL Scrambler
As described in the previous section, the special value of 1
Packet Length is reserved to transfer the scrambler state from
transmitter to the receiver. In this case, the SDL header
followed by six octets (48 bits) of scrambler state plus two
of CRC-16 over the scrambler state. None of these eight octets
scrambled
SDL synchronization consists of two components, link and
synchronization. Both must be completed before PPP data flows on
link
If a valid SDL header is seen in PRESYNCH state, then the link
SYNCH state, and the scrambler synchronization sequence is started
If an invalid SDL header is detected, then the link is returned
HUNT state, and PPP transmission is suspended
When scrambler synchronization is started, a scrambler state
is sent (Packet Length set to 1 and six octets of scrambler state
network byte order follow the SDL header). When a
synchronization message is received from the peer, PPP
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
peers in synchronization. A period of once per eight
packets is suggested, and it SHOULD be configurable.
packet CRC errors detected indicates an extended loss
synchronization and should trigger link resynchronization
On reception of a scrambler state message, an SDL implementation
compare the received 48 bits of state with the receiver's
state. If any of these bits differ, then a synchronization
error is declared. After such an error, the next valid
state message received MUST be loaded into the receiver's scrambler
and the error condition is then cleared
6.4. SDL Scrambler
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
ever becomes all zeros. This scrambler is not reset at the
of each frame, as is the SONET/SDH X^7+X^6+1 scrambler, nor is
modified by the transmitted data, as is the ATM self-
scrambler. Instead it is kept in synchronization using special
messages
+----XOR<--------------XOR<---XOR<----------------+
| ^ ^ ^ |
| | | | |
+->D0-+->D1-> ... ->D26-+->D27-+->D28-> ... ->D47-+
|
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
clock
The scrambler is clocked once after transmission of each bit of
data, whether or not the transmitted bit is scrambled.
scrambling is enabled for a given octet, the OUT bit is exclusive
ored with the raw data bit to produce the transmitted bit.
within an octet are transmitted MSB-first
Reception of scrambled data is identical to transmission.
received bit is exclusive-ored with the output of the
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 D
are snapshot at the point where the first scrambler state bit
sent. D47 is transmitted as the first bit of the output. The
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
check detects multiple bit errors, then the message is dropped and
not processed further
Otherwise, it then should compare the contents of the entire
scrambler state D47:D0 with the corrected message. (By
the receiver with multiple clock stages between SDL Header error
correction block and the descrambling block, the receive
will be on the correct clock boundary when the message arrives at
descrambler. This means that the decoded scrambler state can
treated as immediately available at the beginning of the D47
cycle into the receive scrambler.)
If any of the received scrambler state bits is different from
corresponding shift register bit, then a soft error flag is set.
the flag was already set when this occurs, then a
slip error is declared. This error SHOULD be counted and
through implementation-defined network management procedures.
the receiver has this soft error flag set, any scrambler
message that passes the CRC-16 message check without multiple
errors is clocked directly into the receiver's state register
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
falsely corrected scrambler state message with multiple bit
can corrupt the running scrambler state.)
7. Configuration
7.1. Default LCP
The LCP synchronous configuration defaults apply to SONET/SDH links
The following Configuration Options are recommended
Magic
No Address and Control Field
No Protocol Field
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
is four octets. If the SDL framer presents the SDL packet header
the PPP input handling in order to communicate the packet length (
Lucent implementation does not do this, but other
implementations may), this header is also four octets, and
is preserved
7.2. Modification of the Standard Frame
Since SDL does take the place of HDLC as a transport for PPP, it
at least tempting to remove the HDLC-derived overhead. This is
done for PPP over SDL in order to preserve the message alignment
to allow for the future possibility interworking with other
(e.g., Frame Relay).
By prior external arrangement or via LCP negotiation, any two
implementations MAY agree to omit the address and control fields
implement protocol field compression on a link. Such use is
described by this document and MUST NOT be the default on any
implementation
8. Implementation
8.1. CRC
The following unoptimized code generates proper CRC-16 and CRC-32
values for SDL messages. Note that the polynomial bits are
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 0x04C11DB
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
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
To generate the error correction table, the following
may be used. It creates a table called sdl_error_position, which
indexed on CRC residue value. The tables can be used to determine
no error exists (table entry is equal to FE hex), one
error exists (table entry is zero-based index to errored bit with
of first octet being 0), or more than one error exists, and error
uncorrectable (table entry is FF hex). To use for eight
messages, the bit index from this table is used directly. To use
four octet messages, the index is treated as an unrecoverable
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
3.10. This may be used as part of a "switch" statement in a
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
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');
}
}
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
The reliability of public SONET/SDH networks depends on well-
traffic that does not disrupt the synchronous data
mechanisms. This document describes framing and scrambling
that are used to ensure the distribution of transmitted data
that SONET/SDH design assumptions are not likely to be violated
10.
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
51, RFC 1661, July 1994.
[2] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51,
1662, July 1994.
[3] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615,
1999.
[4] "American National Standard for Telecommunications -
Synchronous Optical Network (SONET) Payload Mappings,"
T1.105.02-1995.
[5] ITU-T Recommendation G.707, "Network Node Interface for
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
Protocol for High Speed Packet Networks", Bell Labs
Journal, pp. 85-104, Vol.4 No.1, January-March 1999.
[7] Demers, A., S. Keshav, and S. Shenker, "Analysis and
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
Congestion Avoidance," IEEE/ACM Transactions on Networking
August 1993.
[9] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570,
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-
system," November 1989.
[12] ITU-T Recommendation G.783, "Characteristics of
digital hierarchy (SDH) equipment functional blocks,"
1997.
11.
PPP over SONET was first proposed by Craig Partridge (BBN) and
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
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
Extant, Inc
3496 Snouffer Road, Suite 100
Columbus, Ohio 43235
EMail: karl@extant.
13. Intellectual Property
The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed
pertain to the implementation or use of the technology described
this document or the extent to which any license under such
might or might not be available; neither does it represent that
has made any effort to identify any such rights. Information on
IETF's procedures with respect to rights in standards-track
standards-related documentation can be found in BCP-11. Copies
claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made
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
proprietary rights by implementors or users of this specification
be obtained from the IETF Secretariat
The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other
rights which may cover technology that may be required to
this standard. Please address the information to the IETF
Director
14. Authors'
James
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.
Paul
Lucent Technologies Microelectronics
555 Union
Allentown PA 18103-1286
EMail: plangner@lucent.
Enrique J. Hernandez-
Lucent
101 Crawford Corners Rd
Holmdel NJ 07733-3030
EMail: enrique@lucent.
James
Lucent
101 Crawford Corners Rd
Holmdel NJ 07733-3030
EMail: sterling@hotair.hobl.lucent.
Carlson, et al. Experimental [Page 27]
RFC 2823 PPP SDL on SONET/SDH May 2000
15. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Carlson, et al. Experimental [Page 28]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
