RFC 2823

PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing

📅 published May 2000, from ietf

🎀 RFC 2823: PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing 🎀

Okay bestie, this one is an Experimental RFC from May 2000, and it's about running PPP over SDL on SONET/SDH links 🦋 It was written by J. Carlson (Sun Microsystems, Inc.), P. Langner (Lucent Technologies Microelectronics Group), E. Hernandez-Valencia (Lucent Technologies), and J. Manchester (Lucent Technologies). It's from the Network Working Group, and the header doesn't list anything it obsoletes or updates. Super clean 💅

Okay, so the Status section says it's an Experimental Protocol for the Internet community and not an Internet standard of any kind. They want feedback! 🌸 Distribution is unlimited, and the Copyright Notice belongs to The Internet Society (2000) ✨

Abstract ✨

So PPP is the standard way to carry multi-protocol datagrams over point-to-point links 💜 RFC 1662 and RFC 2615 are how you carry PPP over SONET 🌈 and SDH 🌈, which are the same kind of thing in different parts of the world. This doc adds a brand new encapsulation for PPP called Simple Data Link (SDL). SDL has way less overhead than HDLC-like encapsulation, and it can run on SONET/SDH links too 🔥

Applicability 🧚

This spec is for implementations that run PPP over high speed point-to-point circuits, whether that's "dark fiber" or public telecom networks 🌌 Because this enhanced PPP encapsulation has very low overhead and scales nicely in hardware, they expect way higher throughput than other SONET/SDH payload mappings, and line termination equipment that costs a lot less 💸 Literally the dream.

SDL is also defined over other media types and for other data link protocols, but this spec only covers PPP over SDL on SONET/SDH 💅

Here's the tea 🍵 Using SDL means the packet length has to be in the SDL header. So hardware doing SDL needs the packet length when it builds that header. If a router's input link doesn't have that info (aka it's not an SDL input link), the router may be required to buffer the entire packet before sending it. That makes "worm-hole" routing at least problematic with SDL, unless the input links are SDL too 😭 But honestly, that's not a huge deal on modern routers, since they already need length info for things like queuing and congestion control, like Weighted Fair Queuing [7] and Random Early Detect [8] 🫶

This doc is NOT replacing the HDLC-like framing that RFC 2615 [3] requires. The authors just want to get real implementation experience with this technique, for operational and performance evaluation. If you're considering or already using the protocol in this document, they'd love to hear from you! Check Section 14 for contact info 💌

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

1. Introduction ✨

So the Path Signal Label is the SONET/SDH overhead byte named C2, and this doc calls it PSL 🦋 It tells you what kind of data is on the path. That data is called the SONET Synchronous Payload Envelope (SPE), or the SDH Administrative Unit Group (AUG) 🌸

The experimental PSL value of decimal 207 (CF hex) is currently used to say the SPE holds PPP framed with RFC 1662 Octet Synchronous (O-S) framing, sent with no scrambling 🫠 The value 22 (16 hex) means PPP framed with O-S framing and sent with ATM-style X^43+1 scrambling 💜 [3]

This doc describes how to use SDL framing for PPP over SONET/SDH, and it covers the framing technique and the requirements for PPP. Here's the comparison 👀 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 sent. SDL has a fixed eight octet overhead per frame and zero data overhead 🔥 SDL also gives you a positive indication of link synchronization, which O-S framing doesn't do.

Note: This doc 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. ANSI T1X1.5 and ITU-T SG-15 allocated these values for SDL over SONET and SDH 🎀 They'll show up in later updates of T1.105 (Table 8) and Recommendation G.707 (Table 7) 🌈

2. Compliance 💖

In this doc, the words that define how significant each requirement is get capitalized. Here they are, bestie 💅

"MUST"

This word means the item is an absolute requirement of the spec.

"MUST NOT"

This phrase means the item is an absolute prohibition of the spec.

"SHOULD"

This word means there may be valid reasons in particular circumstances to ignore this item. But you have to understand the full implications and weigh the case carefully before picking a different path 🤔

"SHOULD NOT"

This phrase means there may be valid reasons in particular circumstances to apply this item. Same deal though: understand the full implications and weigh it carefully before choosing a different course 🧐

"MAY"

This word means the item is truly optional. One vendor might include it because a marketplace needs it or because it makes the product better 🌟 Another vendor might skip the same item, and that's fine too.

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 is called "unconditionally compliant" 👑 One that satisfies all the MUST and MUST NOT requirements, but not all the SHOULD or SHOULD NOT requirements, is called "conditionally compliant" ✨

3. Physical Layer Requirements 🌸

PPP treats SONET/SDH transport as octet-oriented synchronous links 🦋 Partial octets aren't a thing here, and SONET/SDH links are full-duplex by definition.

3.1. Payload Types 🧚

Only synchronous payloads STS-1 and higher are considered in this doc. Lower speed synchronous payloads, like VT1.5-SPE/VC-11, and plesiochronous payload mappings, like T1 and T3, are defined for SONET/SDH and for the SDL algorithm itself. But since HDLC-like framing is already defined for PPP on those media, PPP over SDL isn't defined for them 🙈

SDL is also defined separately as a PPP transport for use on raw fiber without SONET/SDH framing, as an alternative to bit-synchronous HDLC 💜 For details, check out the separate work-in-progress 🍓

3.2. Control Signals ✨

okay so the PPP over SONET/SDH mapping lets you use the PSL as a control signal 💅 but not all gear can set or detect it, so you gotta plan around that 🫶 Equipment that only does SDL MUST be able to transmit PSL with value 23 🦋 It MAY also transmit PSL with value 25 💜 but it doesn't need to detect the peer's value or change its own value 🌸

there are two ways to turn SDL on 🎀 one is LCP-negotiated and the other is prior-arrangement. LCP-negotiated is easier to set up and plays nicer with existing equipment ✨ prior-arrangement lets you use separate SONET/SDH transmission gear that has PSL limitations 💖 and honestly both can interoperate freely if they follow the steps below 👑

LCP-negotiated systems MUST be able to change their transmitted PSL value and detect the peer's value 🔥 Equipment without those features MUST NOT support LCP negotiation of SDL 💀

when SDL gets negotiated by LCP, LCP negotiation MUST start with the PSL value set to 22 or 207, and the matching non-SDL O-S PPP encapsulation MUST be used 🧚 The SDL LCP option then goes into the LCP Configure-Request messages that get sent 💅 When an LCP Configure-Request with an SDL LCP option comes in, or the peer's transmitted PSL value shows up as 23 (or 25), the implementation MUST shut down LCP by sending a Down event to its state machine 😭 Then it switches its transmitted PSL to 23 (or 25), switches encapsulation to SDL, waits for SDL synchronization, and restarts LCP by sending an Up event into LCP ✨ If the peer doesn't transmit 23 (or 25) and doesn't include the SDL LCP option in its Configure-Request messages, then non-SDL O-S PPP encapsulation just keeps going 🌈 If the received PSL later goes from 23 (or 25) back to some other value, that counts as a Down event into the LCP state machine 💀 and an Up event MUST be generated if the new value is a recognized valid PPP framing mode 🙈

when SDL is enabled by prior arrangement, the PSL SHOULD be transmitted as 23 (or 25) 🍓 Any other value can also be used if you've got a prior external arrangement with the peer, but 22 and 207 are discouraged 😭 (That kind of use is enforced by an administrator, and it's outside the scope of this spec 🫠) When SDL is enabled by prior arrangement, the SDL LCP option SHOULD NOT be negotiated by the peers 🙅‍♀️

there SHOULD be an implementation-specific configuration option to pick prior-arrangement or LCP-negotiated mode 🎀 That option SHOULD be shown to an administrator, and it SHOULD default to LCP-negotiated if the hardware allows it 💖 But if the hardware rules out non-SDL modes of operation, then it MUST default to prior-arrangement mode 👑

the LCP-negotiated method works with the current version of G.783 [12] ✨ BUT it may not be compatible with some non-intrusive SDH path monitoring equipment built on obsolete versions of G.783 🥲 The PSL change from LCP negotiation will make that equipment declare an alarm condition on the path 🚨 So for this reason, the prior-arrangement method MUST be used on any SDH network running that kind of monitoring equipment 🛑

3.3. Synchronization Modes ✨

the vibe here is that SDL actually tells you when it's synced 🔥 which O-S encapsulation doesn't. An SDL PPP implementation MUST have a way to temporarily suspend PPP data transmission (both user data and negotiation traffic) if it detects a loss of synchronization 💅 It SHOULD also have a configurable timer that starts when SDL is initialized, restarts when synchronization is lost, and stops once link synchronization is achieved ⏱️ If that timer expires, implementation-dependent action should be taken to report the hardware failure 🚩

3.4. Simple-Data-Link LCP Option ✨

there's a new LCP Configuration Option that asks for Simple Data Link (SDL) [6] operation on the PPP link 🦋

here's the summary of the Simple-Data-Link Configuration Option format for the Link Control Protocol (LCP) 💜 the fields go left to right, obviously 🫶

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

this option is only a hint to the peer that the sender would prefer SDL over SONET/SDH operation 🍓 If the current encapsulation mode isn't SDL, then the only right response for an SDL speaker is to switch encapsulation to SDL (like we covered above) and restart LCP 🔄 Non-SDL speakers SHOULD send an LCP Configure-Reject for the option instead 🙅‍♀️

if you get either an LCP Configure-Nak or an LCP Configure-Reject for this option, the next LCP Configure-Request you send MUST NOT include this option 😭 If an LCP Configure-Ack with this option comes back, it MUST NOT be treated as a request to switch into SDL mode 🙈 And if the received LCP Configure-Request doesn't contain an SDL LCP option, an implementation MUST NOT send an unsolicited Configure-Nak for the option 🚫

(okay this one's a little extra 🎀 An implementation that's already in SDL framing mode and gets this option in an LCP Configure-Request MAY, both for clarity and for convergence reasons, choose to send LCP Configure-Ack 💖 But it MUST NOT restart LCP or change framing modes in this case 🫶)

3.5. Framing ✨

the PPP frames get located by row inside the SPE payload 🧚 Frames are variable in length, so they're 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 🙅‍♀️

(oops, I accidentally capitalized that wrong, let me fix it 🙈) Bytes marked as "overhead" or "fixed stuff" in SONET/SDH documentation for concatenated streams are not used as payload bytes 💅

so when SDL framing for PPP is in use, following Lucent's SDL spec [6], the SDL "Datagram Offset" feature is set to the value 4 🔢 That matches the fixed overhead value 4 described below 💖 The "A" and "B" messages are never used 🙅‍♀️ These optional SDL features aren't described in this document, they're described in Lucent's SDL specification instead 📄

fixing the Datagram Offset value in the Lucent docs to 4 means a PPP MRU/MTU of up to 65536 can be used with SDL 🚀

SDL framing is generally done with a four octet header on each packet ✨ That fixed-length header lets you use a simple framer to detect synchronization, as described in section 3.7 🔍 For PPP, this fixed-length header goes in front of each PPP/HDLC packet like this 👇

 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 gets 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 an initial value of zero and sent in network byte order 💅 The PPP packet is scrambled, begins with the address and control fields, and can be any integral octet length (it isn't padded unless the Self Describing Padding option is used) 🎀 The Packet CRC is scrambled too, has a mode-dependent length (more on that below) 🌸 and is only located on an octet boundary, so you can't assume any alignment for this field 🫠

when the Packet Length value is 4 or greater, the distance in octets from one message header to the next in SDL is the Packet Length field plus 8 🧮 That 8 is 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, and that's the idle fill header 💤 When the Packet Length is 1 to 3, the distance to the next header is 12 octets 🌈 These headers are for special SDL messages used only with optional scrambling and management modes 🔐 Check section 5 for the details of those messages 📖

General SDL, like PPP, lets you use no CRC, ITU-T CRC-16, or ITU-T CRC-32 for the packet data 🔐 BUT because the Packet Length field doesn't include the CRC length, synchronization can't be maintained if the CRC type changes per RFC 1570 [9] 😱 The frame-to-frame distance is calculated including the CRC length, as described above, so it breaks 💀 That's why this PPP over SDL spec fixes the CRC type to CRC-32 (four octets) 💜 and all SDL implementations MUST reject any LCP FCS Alternatives Option [9] the peer requests while 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 in the Packet Length field is exactly the length in octets of the PPP frame itself, including the address and control fields but not the CRC field (the RFC 1662 PPP FCS field isn't used with SDL) 🦋 Note again that the Datagram Offset is just an arithmetic value and doesn't take up any 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 only possible with address/control or protocol field compression, MUST be padded to length 4 for SDL 🍓

inter-packet time fill is done 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 gets used on the data portion of the message, including the 32 bit CRC 🔀 This is done in exactly the same way as the ATM x^43+1 scrambler on an ATM channel 🧚 The scrambler isn't clocked when SDL header bits are transmitted 🙈 So the data scrambling MAY be implemented completely independently from the SDL framing, and the data stream may be prescrambled before the SDL framing marks get inserted 🌸

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 👑

3.6. Framing Example 🎀

okay so to make this click, here's an example bestie 🫶 We start with an LCP Configure-Request message that we want to send over SDL:

    FF 03 C0 21 01 01 00 04

Next, we build an SDL header for the length of this packet (8 octets), plus 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

Quick math check: the final length is 8 (original message length) plus 4 (fixed datagram offset value) plus 4 (fixed CRC length), so 16 octets total. ✨

3.7. Synchronization Procedure 🦋

the link sync procedure is kinda like the I.432 section 4.5.1.1 ATM HEC delineation procedure [10], except SDL messages are variable length, so it's its own vibe 🌈 The machine starts in HUNT state and stays there until it finds a four octet sequence in the data stream with a valid CRC-16. (Heads up: the CRC-16 single-bit error correction from section 3.10 is NOT used until the machine is in SYNCH state. The header has to have zero bit errors to leave HUNT state. 🙈) That valid sequence counts as a candidate SDL header. Once it's spotted, the machine enters PRESYNCH state. Any single invalid SDL header while in PRESYNCH state sends the link right back to HUNT state 💀

If a second valid SDL header shows up after entering PRESYNCH state, the link enters SYNCH state and PPP transmission gets turned on 🔥 But if an invalid SDL header is detected, the link goes back to HUNT state and PPP transmission stays off.

Once the link is in SYNCH state, SDL header single bit error correction logic gets switched on (see section 3.10). Any unrecoverable header CRC error sends the link back to HUNT state, turns PPP transmission off, and turns the error correction logic off too 😭

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, which is so iconic 👑

               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 gets clocked once after each bit of payload is sent or received, and before the next bit goes in as input. Bits within an octet are, following SONET/SDH practice, sent 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]. They 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 with an initial remainder value of 0000 hex 🌈

The optional CRC-16 on the payload data is NOT used with PPP over SDL unless you've arranged it beforehand. When it is used, it starts with an initial remainder value of FFFF hex and the bits get complemented before transmission. The final CRC remainder, though, is sent in network byte order, which is different from the regular PPP FCS 🙈 If you run the CRC-16 over all the octets including the appended CRC itself, intact packets will always leave a remainder of E2F0 hex. Or, an implementation can stop the CRC calculation before processing the appended CRC and just do a direct comparison. Both work, bestie 💅

The CRC-32 on the payload data (used for PPP over SDL) starts with an initial remainder value of FFFFFFFF hex and the bits get complemented before transmission. The CRC is sent in network byte order, most significant bit first. That's different from the optional PPP 32 bit FCS, which is sent in reverse order 🔥 The remainder 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 a Galois number field, same as 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 say that CRC(message+error) = CRC(message) + CRC(error). The CRC-16 remainder of a properly formed message is always zero, so for the N distinct "error" strings that correspond to a single bit error, there are N distinct CRC(error) values, where N is the number of bits in the message. Galois fields are literally so cool 👑

A table look-up gets applied to the CRC-16 residue after calculation over the four octet SDL header, which corrects bit errors in the header and detects 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 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 starts with zero, the two tables can be merged. The four octet table is just the last 32 entries of the eight octet table ✨

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

So if the syndrome 6EF6 shows up on an eight octet message, the third bit (hex 20) of the second octet is in error. Similarly, if 48C4 shows up on an eight octet message, the second bit (hex 40) in the eighth octet is in error. For a four octet message, the same two syndromes would mean 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 only used 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 matter a lot for framing algorithms. They 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 next sections break down each of these stats for SDL. Details and the math can be found in the Lucent SDL documentation [6] 🤓

4.1. Mean Time To Frame (MTTF) 🎀

This metric measures how long it takes to establish correct framing in the input data. It can be measured in any convenient units, like seconds or bytes. For SDL, the relevant measurement is in packets, since fragments of packets aren't useful 🦋

To calculate MTTF, we first need to figure out how often the frame detection state machine is "unavailable" because it failed to detect the next incoming SDL frame in the data stream.

The probability of a false header detection using CRC-16 in random data is 2^-16. That rate is big compared to the allowable packet size, so it's worth running multiple parallel frame-detection state machines. Each machine starts at a different candidate framing point, which reduces the chance 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). The plots show a characteristically flat region for all BERs up to a knee, beyond which it begins to rise sharply. In all cases, the knee point has been found to occur at a BER of approximately 1E-4, which is several orders of magnitude above what's 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

So, 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 starting framing at an average point halfway into one packet, and getting 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 🌸

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 SDL document [6] shows the probability of random corruption of this short message is 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). It's 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. For SDL, it's 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. So at a BER of 1E-5, the PLF is 5E-8 🫶

5. The Special Messages 🎀

okay so when the SDL Packet Length field is anywhere from 0000 to 0003, the message after the header has a special, pre-defined length 🧚. The 0 value is a time-fill on an idle link, and no other data follows it. The next octet on the link is the first octet of the next SDL header 💤.

Values 1 through 3 each get their own subsection below. These special messages all have a six octet data portion, followed by another CRC-16 over that data portion, just like the SDL header. This CRC is used for single bit error correction 🔧.

5.1. Scrambler State 🦋

The special value of 1 for Packet Length is reserved for moving the scrambler state from the transmitter to the receiver, for the optional set-reset scrambler. So the SDL header is followed by six octets (48 bits) of scrambler state. Neither the scrambler state nor the CRC gets scrambled 🙈.

5.2. A/B Message 💜

Values 2 and 3 are reserved for "A" and "B" messages. These are also six octets long, followed by two octets of CRC-16. Each of these eight octets is scrambled. No use for these messages with PPP SDL is defined. They're reserved for link maintenance protocols, kind of like 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 dodge some of the inherent problems of self-synchronous scramblers ✨.

6.1. The Killer Packet Problem 💀

Scrambling solves two problems in general. First, SONET and SDH interfaces need a minimum density of bit transitions to keep hardware clock recovery happy. Data often has long runs of all zeros or all ones, so scrambling with a pseudo-random sequence breaks those up. Second, all link-layer synchronization mechanisms rely on spotting long-range patterns in the received data to find framing.

Self-synchronous scramblers are an easy way to partly dodge these problems. The catch is that long user packets from malicious sites can use the known properties of these scramblers to inject long strings of zeros or other synchronization-destroying patterns into the link 😤. On public networks, the data is usually multiplexed (interleaved) with lots of unrelated streams, so the clocking problem isn't a big threat to the public network. It does threaten the PPP-speaking device, though, and it threatens long lines that are unchannelized 🥺.

Such carefully built packets are called "killer packets" 🔪.

6.2. SDL Set-Reset Scrambler 🔐

An alternative to the self-synchronous scrambler is the externally synchronized or "set-reset" scrambler. It's free-running and unaffected by the patterns in the user data, so it makes it much harder for a sneaky user to send data that mimics an undesirable pattern 🕵️.

The optional set-reset scrambler defined for SDL is an x^48+x^28+x^27+x+1 independent scrambler. It's initialized to all ones when the link enters PRESYNCH state, and reinitialized if its value ever becomes all zero bits. Same as before, all octets in the PPP packet data from after the SDL header through the final packet CRC get scrambled 💖.

This mode MAY be detected automatically. If a scrambler state message comes in (see the next 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 🤝

Like we said, the special value 1 for Packet Length is reserved for moving the scrambler state from transmitter to receiver. The SDL header is followed by six octets (48 bits) of scrambler state, plus two octets of CRC-16 over that state. None of these eight octets get scrambled.

SDL synchronization has two parts: link and scrambler synchronization. Both must be completed before PPP data can flow on the link 🌊.

If a valid SDL header shows up in PRESYNCH state, the link enters SYNCH state and scrambler synchronization starts. If an invalid SDL header is detected, the link goes back to HUNT state and PPP transmission gets suspended 🛑.

When scrambler synchronization starts, a scrambler state message gets 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 comes in from the peer, PPP transmission is enabled 🎉.

Scrambler state messages are sent periodically to keep the peers in sync. Once per eight transmitted packets is suggested, and it SHOULD be configurable. Excessive packet CRC errors indicate 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, a synchronization slip error is declared. After that error, the next valid scrambler state message received MUST be loaded into the receiver's scrambler, and then the error condition is cleared 🧹.

6.4. SDL Scrambler Operation 🧠

The transmit and receive scramblers are shift registers with 48 stages, 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 isn't reset at the start of each frame (unlike the SONET/SDH X^7+X^6+1 scrambler), and it isn't modified by the transmitted data (unlike the ATM self-synchronous scrambler). Instead, it stays in sync 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 each bit of SDL data is transmitted, whether or not that bit is scrambled. When scrambling is enabled for an 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 works the same as transmission. Each received bit is exclusive-ORed with the output of the separate receive data scrambler 🪞.

To generate a scrambler state message, the contents of D47 through D0 are snapshotted 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, the message is dropped and isn't 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 the 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 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, a soft error flag is set. If the flag was already set when this happens, 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 then the soft error flag is 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)

This configuration means PPP over SDL generally presents a 32-bit aligned datagram to the network layer. With the address, control, and protocol fields 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's at least tempting to remove the HDLC-derived overhead. This is not done for PPP over SDL, in order to preserve message alignment and to allow for the future possibility of 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 ✨

okay bestie, this code is unoptimized on purpose (it's about being correct, not fast 🧮), and it spits out proper CRC-16 and CRC-32 values for SDL messages. heads up: for SDL CRCs the polynomial bits are numbered big-endian, so 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;

}

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;
}
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 🔍

okay so this part is giving error-detective vibes 🕵️‍♀️ you can use the following implementation to generate the error correction table. it creates a table called sdl_error_position, which is indexed on CRC residue value. the table tells you one of three things: no error exists (entry is FE hex), one correctable error exists (entry is a zero-based index to the errored bit, with the MSB of the first octet being 0), or more than one error exists and the error is uncorrectable (entry is FF hex). for eight octet messages, you use the bit index from the table directly. for four octet messages, the index is treated as an unrecoverable error if it's below 32, and as the bit index plus 32 if it's 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;
}
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));

    /* Output is 0000 64 -- no error encountered. */
    printf("\nError test:  CRC %04X, bit position %d\n",
      crc,sdl_error_position[crc]);
}

9. Security Considerations 🔐

⚠️ bestie, this one's serious, so read it carefully!

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 make sure the distribution of transmitted data is handled so 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.
[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. it also doesn't 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 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

15. Full Copyright Statement 🎀

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 🧚

📦 where this page comes from

ietf: rfc2823 2000-05
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms