One document matched: draft-ietf-pppext-sdl-pol-00.txt
PPP over Simple Data Link (SDL)
using raw lightwave channels with ATM-like framing
<draft-ietf-pppext-sdl-pol-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
This document is the product of the Point-to-Point Protocol
Extensions Working Group of the Internet Engineering Task Force
(IETF). Comments should be submitted to the ietf-ppp@merit.edu
mailing list.
Distribution of this memo is unlimited.
Carlson, et al. expires December 1999 [Page 1]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
Abstract
The Point-to-Point Protocol (PPP) in RFC-1661 [1] provides a standard
method for transporting multi-protocol datagrams over point-to-point
links, and RFCs 1662 [2] and 1619 [3] provide a means to carry PPP
over Synchronous Optical Network (SONET) [5] and Synchronous Digital
Hierarchy (SDH) [6] circuits. PPP over Simple Data Link (SDL) using
SONET/SDH with ATM-like framing (PPPEXT WG work in Progress) extended
these standards to include a new encapsulation for PPP called Simple
Data Link (SDL) [8]. This document extends the use of SDL over raw
lightwave channels without an intervening SONET/SDH layer, which are
also referred to as "dark fiber" or Packet-over-Lightwave" (POL)
links,
This document is the product of the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the ietf-ppp@merit.edu mailing list.
Applicability
This specification is intended for those implementations which desire
to use PPP encapsulation over high speed point-to-point circuits with
the so-called "dark fiber" or raw lightwave channels. This enhanced
framing mechanisms for PPP encapsulation method has very low
overhead, good hardware scaling properties and is resilient to
payload expansion. It is anticipated that significantly higher
throughput can be attained with SDL when compared to other transport
and encapsulation mechanisms for high-speed packet data over
lightwave channels, and at a significantly lower cost for line
termination equipment.
SDL is defined over other media types and for other data link
protocols, but this specification covers only the use of PPP over SDL
raw lightwave channels. Systems requiring typical public network
functions such as transmission quality assessment, protection
switching/restoration, and OAM&P at the transmission level will may
require either an additional transmission layer (e.g., SONET/SDH or
OTN [7]) with or equivalent OAM&P functionality not defined in this
document.
The use of SDL requires the presentation of packet length information
in the SDL header. Thus, hardware implementing SDL must have access
to the packet length when generating the header, and where a router's
input link does not readily have this information (that is, for non-
SDL input links), the router may be required to buffer the entire
packet before transmission. "Worm-hole" routing is thus at least
problematic with SDL, unless the input links are also SDL. This,
however, does not appear to be a great disadvantage on modern routers
Carlson, et al. expires December 1999 [Page 2]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
due to the general requirement of length information in other parts
of the system, notably in queueing and congestion control strategies
such as Weighted Fair Queuing [12] and Random Early Detection [13].
Carlson, et al. expires December 1999 [Page 3]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
Table of Contents
1. Introduction ............................................... 5
2. Physical Layer Requirements ................................ 6
2.1. Payload Types ............................................ 6
2.2. Control Signals .......................................... 6
2.3. Synchronization Modes .................................... 6
2.4. Framing .................................................. 6
2.5. Synchronization Procedure ................................ 9
2.6. Scrambler Operation ...................................... 9
2.7. CRC Generation ........................................... 10
2.8. Error Correction ......................................... 10
3. Performance Analysis ....................................... 11
3.1. Mean Time To Frame (MTTF) ................................ 12
3.2. Mean Time To Synchronization (MTTS) ...................... 13
3.3. Probability of False Frame (PFF) ......................... 13
3.4. Probability of False Synchronization (PFS) ............... 13
3.5. Probability of Loss of Frame (PLF) ....................... 14
4. The Special Messages ....................................... 14
4.1. Scrambler State .......................................... 14
4.2. A/B Message .............................................. 14
5. The Set-Reset Scrambler Option ............................. 14
5.1. The Killer Packet Problem ................................ 15
5.2. SDL Set-Reset Scrambler .................................. 15
5.3. SDL Scrambler Synchronization ............................ 15
5.4. SDL Scrambler Operation .................................. 16
6. Configuration Details ...................................... 18
Appendix A: CRC Generation .................................... 19
Appendix B: Error Correction Tables ........................... 21
7. Security Considerations .................................... 23
8. References ................................................. 23
9. Acknowledgments ............................................ 24
10. Intellectual Properties Considerations .................... 24
11. Authors' Addresses ........................................ 25
Carlson, et al. expires December 1999 [Page 4]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
1. Introduction
The term packet-over-lightwave (POL) has been used to refer to the
capability of transmitting packet data directly over a raw lightwave
channel, also referred to as "dark fiber", without an intervening
SONET/SDH or optical transport network (OTN) layer. POL solutions are
attractive in data networking scenarios were neither multi-
segment/multi-path transport nor the OAM&P capabilities of optical
transport networking or SONET/SDH is required. SDL on POL does not
rely on SONET/SDH or OTN overheads to enable networking features such
as transmission quality assessment, protection switching/restoration,
and OAM&P. Performance assessment, switching and OAM&P capabilities
for SDL on POL are not defined in this document
This document describes a method to enable the use of SDL framing for
PPP over such raw lightwave channels and describes the framing and
encapsulation requirements for PPP.. The protocol stack is illus-
trated in Figure 1. While bit-synchronous HDLC-like framing has a
worst-case octet overhead of 20% for some specific data patterns, SDL
uses no payload encoding, and hence, has zero payload overhead.
+--------------------------+
| |
| Higher-layer Protocol |
| |
+--------------------------+
| |
| PPP |
| |
+--------------------------+
| |
| SDL |
| |
+--------------------------+
| |
| Raw Lightwave Channel |
| |
+--------------------------+
Figure 1: Protocol stack for PPP over SDL over a raw lightwave channel.
Carlson, et al. expires December 1999 [Page 5]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
2. Physical Layer Requirements
The transport mode for SDL on POL is packet-oriented. The raw
lightwave links are intrinsically bit-synchronous even though PPP
treats the lower transport layer as a full-duplex octet-oriented syn-
chronous interface. No provision is made to support sending or
receiving bare octets over lightwaves (as is the case with
SONET/SDH).
2.1. Payload Types
Only bit-synchronous payloads at STS-1 and higher line rates are
currently considered in this document. Operations at lower bit rates
is feasible but not considered at present. Mappings of plesiochronous
payloads, such as T1 and T3, on to SDL are not considered in this
document.
2.2. Control Signals
A prior-arrangement method is required to enable SDL framing for POL.
No LCP-negotiated method is currently proposed. LCP may be used to
negotiated other PPP-related parameters (see sections 2.4 and 6).
2.3. Synchronization Modes
Unlike non-SDL O-S encapsulations, SDL provides a positive indication
that it has achieved synchronization with the peer. An SDL PPP
implementation MUST provide a means to temporarily suspend PPP data
transmission (both user data and negotiation traffic) if synchroniza-
tion loss is detected. An SDL PPP implementation SHOULD also provide
a configurable timer that is started when SDL is initialized and res-
tarted on the loss of synchronization, and is terminated when link
synchronization is achieved. If this timer expires, implementation-
dependent action should be taken to report the hardware failure.
2.4. Framing
PPP over SDL over raw lightwave channels uses the same data link
frame format as for PPP over SDL over SONET/SDH [4]. When SDL framing
for PPP is employed, the SDL "Datagram Offset" is fixed at 4, and the
"A" and "B" messages are not used. Additional information on these
optional features of SDL can be found in Lucent's SDL specification
[8].
Carlson, et al. expires December 1999 [Page 6]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
Fixing the Datagram Offset to 4 allows a PPP MRU/MTU of 65536 using
SDL.
SDL framing is in general accomplished by the use of a four octet
header on the packet. This fixed-length header allows the use of a
simple framer to detect synchronization as described in section 2.6.
For use with PPP, this header precedes each raw PPP packet as fol-
lows:
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The four octet length header is DC balanced by exclusive-OR (also
known as "modulo 2 addition") with the hex value B6AB31E0. This is
the maximum transition, minimum sidelobe, Barker-like sequence of
length 32. No other scrambling is done on the header itself.
Packet Length is an unsigned 16 bit number in network byte order.
Unlike the standard PPP FCS, the Header CRC is a CRC-16 generated
with initial value zero and transmitted in standard network byte
order. The PPP packet is scrambled, and begins with the standard
address and control fields, and may be any integral octet length
(i.e., it is not padded unless the Self Describing Padding option is
used). The Packet CRC is also scrambled, and has a mode-dependent
length (described below), and is located only on an octet boundary;
no alignment of this field may be assumed.
When the Packet Length value is 4 or greater, the distance in octets
between one message header and the next in SDL is the sum of Packet
Length field, Datagram Offset value, and the fixed size of the Packet
CRC field. The Datagram Offset is a configurable SDL parameter,
which is set to the fixed value 4 for PPP. When the Packet Length is
0, the distance to the next header is 4 octets. This is the idle
fill header. When the Packet Length is 1 to 3, the distance to the
next header is 12 octets. These headers are used for special SDL
messages used only with optional scrambling and management modes.
See section 5 for details of the messages.
General SDL, like PPP, allows the use of no CRC, ITU-T CRC-16, or
Carlson, et al. expires December 1999 [Page 7]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
ITU-T CRC-32 for the packet data. However, because the Packet Length
field does not include the CRC length, synchronization cannot be
maintained if the CRC type is changed per RFC 1570, because frame-
to-frame distance is, as described above, calculated including the
CRC length. Although synchronization can be regained by readjusting
the receiver's frame-to-frame distance after a CRC negotiation, this
PPP over SDL specification fixes the CRC type to CRC-32 (four
octets), and all SDL implementations MUST reject any LCP FCS Alterna-
tives Option [9] requested by the peer when in SDL mode.
PPP over SDL implementations MAY allow a configuration option to set
different CRC types for use by prior arrangement. Any such configur-
able option MUST default to CRC-32, and MUST NOT be include LCP nego-
tiation of FCS Alternatives.
With the SDL Datagram Offset set to 4, the value placed in the Packet
Length field is exactly the length in octets of the PPP frame itself,
including the address and control fields but not including the FCS
field.
Because Packet Lengths below 4 are reserved, the Packet Length MUST
be 4 or greater for any legal PPP packet. PPP packets with fewer
octets, which are not possible without address/control or protocol
field compression, MUST be padded to length 4 for SDL.
Inter-packet time fill is accomplished by sending the four octet
length header with the Packet Length set to zero. No provision is
made for intra-packet time fill.
By default, an independent, self-synchronous x^43+1 scrambler is used
on the data portion of the message including the 32 bit CRC. This is
done in exactly the same manner as with the ATM x^43+1 scrambler on a
SONET/SDH link. The scrambler is not clocked when SDL header bits
are transmitted. Thus, the data scrambling can be implemented in an
entirely independent manner from the SDL framing.
Optionally, by prior arrangement, SDL links MAY use a set-reset
scrambler as described in section 2.9. If this option is provided,
it MUST be configurable by the administrator, and the option MUST
default to the self-synchronous scrambler.
Once the link enters SYNCH state, the SDL header single bit error
correction logic is enabled (see section 2.9). Any unrecoverable
header CRC error returns the link to HUNT state, disables PPP
transmission, and disables the error correction logic.
Carlson, et al. expires December 1999 [Page 8]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
2.5. Synchronization Procedure
The link synchronization procedure is similar to the I.432 section
4.5.1.1 ATM HEC delineation procedure [10], except that the SDL mes-
sages are variable length. The machine starts in HUNT state until a
four octet sequence in the data stream with a valid CRC-16 is found.
(Note that the CRC-16 single-bit error correction technique described
in section 2.9 is not employed until the machine is in in SYNCH
state. The header must have no bit errors in order to leave HUNT
state.) Such a valid sequence is a candidate SDL header. On finding
the valid sequence, the machine enters PRESYNCH state. Any one
invalid SDL header in PRESYNCH state returns the link to HUNT state.
If a second valid SDL header is seen after entering PRESYNCH state,
then the link enters SYNCH state and PPP transmission is enabled. If
an invalid SDL header is detected, then the link is returned to HUNT
state without enabling PPP transmission.
2.6. Scrambler Operation
The transmit and receive scramblers are shift registers with 43
stages that MAY be initialized to all-ones when the link is initial-
ized. Synchronization is maintained by the data itself.
Transmit Receive
DATA-STREAM (FROM PPP) IN (FROM SDL FRAMER)
| |
v |
XOR<-------------------------+ +->D0-+->D1-> ... ->D41->D42-+
| | | |
+->D0-+->D1-> ... ->D41->D42-+ XOR<-------------------------+
| |
v v
OUT (TO SDL FRAMER) DATA-STREAM (TO PPP)
Each XOR is an exclusive-or gate; also known as a modulo-2 adder.
Each Dn block is a D-type flip-flop clocked on the appropriate data
clock.
The scrambler is clocked once after transmission or reception of each
bit of payload and before the next bit is applied as input. Bits
within an octet are, per SONET/SDH standard practice, transmitted and
received MSB-first.
Carlson, et al. expires December 1999 [Page 9]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
2.7. CRC Generation
The CRC-16 and CRC-32 generator polynomials used by SDL are the ITU-T
standard polynomials [11]. These are:
x^16+x^12+x^5+1
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1
The SDL Header CRC and the CRC-16 used for each of the three special
messages (scrambler state, message A, and message B; see section 5)
are all generated using an initial remainder value of 0000 hex.
The optional CRC-16 on the payload data (this mode is not used with
PPP over SDL except by prior arrangement) uses the standard initial
remainder value of FFFF hex for calculation and the bits are comple-
mented before transmission. The final CRC remainder, however, is
transmitted in network byte order, unlike the regular PPP FCS. If
the CRC-16 algorithm is run over all of the octets including the
appended CRC itself, then the remainder value on intact packets will
always be E2F0 hex. Alternatively, an implementation may stop CRC
calculation before processing the appended CRC itself, and do a
direct comparison.
The standard CRC-32 on the payload data (used for standard PPP over
SDL) uses the initial remainder value of FFFFFFFF hex for calculation
and the bits are complemented before transmission. The CRC, however,
is transmitted in network byte order, most significant bit first,
unlike the optional PPP 32 bit FCS, which is transmitted in reverse
order. The remainder value on intact packets when the appended CRC
value is included in the calculation is 38FB2284.
C code to generate these CRCs is found in Appendix A.
2.8. Error Correction
The error correction technique is based on the use of a Galois number
field, as with the ATM HEC correction. In a Galois number field,
f(a+b) = f(a) + f(b). Since the CRC-16 used for SDL forms such a
field, we can state that CRC(message+error) = CRC(message) +
CRC(error). Since the CRC-16 remainder of a properly formed message
is always zero, this means that, for the N distinct "error" strings
corresponding to a single bit error, there are N distinct CRC(error)
values, where N is the number of bits in the message.
A table look-up is thus applied to the CRC-16 residue after calcula-
tion over the four octet SDL header to correct bit errors in the
Carlson, et al. expires December 1999 [Page 10]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
header and to detect multiple bit errors. For the optional set-reset
scrambler, a table look-up is similarly applied to the CRC-16 residue
after calculation over the eight octet scrambler state message to
correct bit errors and to detect multiple bit errors. (This second
correction is also used for the special SDL A and B messages, which
are not used for standard 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 correc-
tion should not be performed, and only messages with syndrome 0000
are accepted. If the calculated syndrome does not appear in this
table, then an unrecoverable error has occurred. Any such error in
the SDL header will return the link to HUNT state.
Since the CRC calculation is started with zero, the two tables can be
merged. The four octet table is merely the last 32 entries of the
eight octet table.
Eight octet (64 bit) single bit error syndrome table (in hex):
FD81 F6D0 7B68 3DB4 1EDA 0F6D 8FA6 47D3
ABF9 DDEC 6EF6 377B 93AD C1C6 60E3 B861
D420 6A10 3508 1A84 0D42 06A1 8B40 45A0
22D0 1168 08B4 045A 022D 8906 4483 AA51
DD38 6E9C 374E 1BA7 85C3 CAF1 ED68 76B4
3B5A 1DAD 86C6 4363 A9A1 DCC0 6E60 3730
1B98 0DCC 06E6 0373 89A9 CCC4 6662 3331
9188 48C4 2462 1231 8108 4084 2042 1021
Thus, if the syndrome 6EF6 is seen on an eight octet message, then
the third bit (hex 20) of the second octet is in error. Similarly,
if 48C4 is seen on an eight octet message, then the second bit (hex
40) in the eighth octet is in error. For a four octet message, the
same two syndromes would indicate a multiple bit error for 6EF6, and
a single bit error in the second bit of the fourth octet for 48C4.
Note that eight octet messages are used only for the optional set-
reset scrambling mode, described in section 6.
Corresponding C code to generate this table is found in Appendix B.
3. Performance Analysis
There are five general statistics that are important for framing
algorithms. These are:
Carlson, et al. expires December 1999 [Page 11]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
MTTF Mean time to frame
MTTS Mean time to synchronization
PFF Probability of false frame
PFS Probability of false synchronization
PLF Probability of loss of frame
The following sections summarize each of these statistics for SDL.
Details and mathematic development can be found in the Lucent SDL
documentation [8].
3.1. Mean Time To Frame (MTTF)
This metric measures the amount of time required to establish correct
framing in the input data. This may be measured in any convenient
units, such as seconds or bytes. For SDL, the relevant measurement
is in packets, since fragments of packets are not useful.
In order to calculate MTTF, we must first determine how often the
frame detection state machine is "unavailable" because it failed to
detect the next incoming SDL frame within the user data.
Since the probability of a false header detection using CRC-16 in
random data is 2^-16 and this rate is large compared to the allowable
packet size, it is worthwhile to run multiple parallel frame-
detection state machines. Each machine starts with a different can-
didate framing point in order to reduce the probability of falsely
detecting user data as a valid frame header.
The results for this calculation for 64KB, 8KB and 384B packets are:
Number of Unavailability Unavailability Unavailability
Framers 64Kb Packets 8KB packets 384 byte pkts
1 8.75E-1 3.68E-1 2.31E-2
2 7.50E-1 1.04E-1 3.57E-4
3 6.27E-1 2.32E-2 4.17E-6
4 5.08E-1 4.35E-3 3.89E-8
Using these values, MTTF can be calculated as a function of the Bit
Error Rate (BER). These plots show a characteristically flat region
for all BERs up to a knee, beyond which the begins to rise sharply.
In all cases, this knee point has been found to occur at a BER of
approximately 1E-4, which is several orders of magnitude above that
observed on existing SONET/SDH links. The flat rate values are sum-
marized as:
Number of Flat Region Flat region Flat region
Framers 64KB Packets 8KB packets 384B packets
Carlson, et al. expires December 1999 [Page 12]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
1 8.50 2.08 1.52
2 4.57 1.62 1.50
3 3.18 1.52 1.50
4 2.53 1.50 1.50
Thus, for common packet sizes in an implementation with two parallel
framers using links with a BER of 1E-4 or better, the MTTF is approx-
imately 1.5 packets. This is also the optimal time, since it
represents initiating framing at an average point half-way into one
packet, and achieving good framing after seeing exactly one correctly
framed packet.
Note that the numbers in both tables apply only after the link loses
synchronization, which is by itself a very rare event as per the
estimate PLF in seccion 3.5.
3.2. Mean Time To Synchronization (MTTS)
The MTTS for standard 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 probability of ran-
dom corruption of this short message is shown in the SDL document [8]
to be small enough that it can be neglected for this calculation.)
3.3. Probability of False Frame (PFF)
The PFF is 232.8E-12 (2^-32), since false framing requires two con-
secutive headers with falsely correct CRC-16.
3.4. Probability of False Synchronization (PFS)
The PFS for the standard self-synchronous scrambler is the same as
the PFF, or 232.8E-21 (2^-32).
The PFS for the set-reset scrambler is 54.21E-21 (2^-64), and is cal-
culated as the PFF above multiplied by the probability of a falsely
detected scrambler state message, which itself contains two indepen-
dent CRC-16 calculations.
Carlson, et al. expires December 1999 [Page 13]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
3.5. Probability of Loss of Frame (PLF)
The PLF is a function of the BER, and for SDL is approximately the
square of the BER multiplied by 500, which is the probability of two
or more bit errors occurring within the 32 bit SDL header. Thus, at a
BER of 1E-5, the PLF is 5E-8. For the typical fiber BER, between 1E-
10 to 1E-12, frame delineation loss would occur less than once every
year, on the average, even at OC-768 rates.
4. The Special Messages
When the SDL Packet Length field has any value between 0000 and 0003,
the message following the header has a special, pre-defined length.
The 0 value is a time-fill on an idle link, and no other data fol-
lows. The next octet on the link is the first octet of the next SDL
header.
The values 1 through 3 are defined in the following subsections.
These special messages each consist of a six octet data portion fol-
lowed by another CRC-16 over that data portion, as with the SDL
header, and this CRC is used for single bit error correction.
4.1. Scrambler State
The special value of 1 for Packet Length is reserved to transfer the
scrambler state from the transmitter to the receiver for the optional
set-reset scrambler. In this case, the SDL header is followed by six
octets (48 bits) of scrambler state. Neither the scrambler state nor
the CRC are scrambled.
4.2. A/B Message
The special values of 2 and 3 for Packet Length are reserved for "A"
and "B" messages, which are also six octets in length followed by two
octets of CRC-16. Each of these eight octets are scrambled. No use
for these messages with PPP SDL is defined. These messages are
reserved for use by link maintenance protocols, in a manner analogous
to ATM's OAM cells.
5. The Set-Reset Scrambler Option
Standard PPP over SDL uses a self-synchronous scrambler. SDL imple-
mentations MAY also employ a set-reset scrambler to avoid some of the
possible inherent problems with self-synchronous scramblers.
Carlson, et al. expires December 1999 [Page 14]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
5.1. The Killer Packet Problem
Scrambling in general solves two problems. First, most line inter-
faces (e.g., SONET/SDH) require a minimum density of bit transitions
in order to maintain hardware clock recovery. Since data streams
frequently contain long runs of all zeros or all ones, scrambling the
bits using a pseudo-random number sequence breaks up these patters.
Second, all link-layer synchronization mechanisms rely on detecting
long-range patterns in the received data to detect framing.
Self-synchronous scramblers are an easy way to partially avoid these
problems. One problem that is inherent with self-synchronous, how-
ever, is that long user packets from malicious sites can make use of
the known properties of these scramblers to inject either long
strings of zeros or other synchronization-destroying patterns into
the link.
Such carefully constructed packets are called "killer packets."
5.2. SDL Set-Reset Scrambler
An alternative to the self-synchronous scrambler is the externally
synchronized or "set-reset" scrambler. This is a free-running scram-
bler that is not affected by the patterns in the user data, and
therefore minimizes the possibility that a malicious user could
present data to the network that mimics an undesirable data pattern.
The option set-reset scrambler defined for SDL is an
x^48+x^28+x^27+x+1 independent scrambler initialized to all ones when
the link enters PRESYNCH state and reinitialized if the value ever
becomes all zero bits. As with the self-synchronous scrambler, all
octets in the PPP packet data following the SDL header through the
final packet CRC are scrambled.
5.3. SDL Scrambler Synchronization
As described in the previous section, the special value of 1 for
Packet Length is reserved to transfer the scrambler state from the
transmitter to the receiver. In this case, the SDL header is fol-
lowed by six octets (48 bits) of scrambler state plus two octets of
CRC-16 over the scrambler state. None of these eight octets are
scrambled.
SDL synchronization consists of two components, link and scrambler
synchronization. Both must be completed before PPP data flows on the
link.
Carlson, et al. expires December 1999 [Page 15]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
If a valid SDL header is seen in PRESYNCH state, then the link enters
SYNCH state, and the scrambler synchronization sequence is started.
If an invalid SDL header is detected, then the link is returned to
HUNT state, and PPP transmission is suspended.
When scrambler synchronization is started, a scrambler state message
is sent (Packet Length set to 1 and six octets of scrambler state in
network byte order follow the SDL header). This message is sent
once. At this point, PPP transmission is enabled.
Scrambler state messages are periodically transmitted to keep the
peers in synchronization. A period of once per eight transmitted
packets is suggested, and it SHOULD be configurable. Excessive
packet CRC errors detected indicates an extended loss of synchroniza-
tion and should trigger link resynchronization.
On reception of a scrambler state message, an SDL implementation MUST
compare the received 48 bits of state with the receiver's scrambler
state. If any of these bits differ, then a synchronization slip
error is declared. After such an error, the next valid scrambler
state message received MUST be loaded into the receiver's scrambler,
and the error condition is then cleared.
5.4. SDL Scrambler Operation
The transmit and receive scramblers are shift registers with 48
stages that are initialized to all-ones when the link is initialized.
Each is refilled with all one bits if the value in the shift register
ever becomes all zeros. This scrambler is not reset at the beginning
of each frame, as is the SONET/SDH X^7+X^6+1 scrambler, nor is it
modified by the transmitted data, as is the ATM self-synchronous
scrambler. Instead it is kept in synchronization using special SDL
messages.
+----XOR<--------------XOR<---XOR<----------------+
| ^ ^ ^ |
| | | | |
+->D0-+->D1-> ... ->D26-+->D27-+->D28-> ... ->D47-+
|
v
OUT
Each XOR is an exclusive-or gate; also known as a modulo-2 adder.
Each Dn block is a D-type flip-flop clocked on the appropriate data
clock.
The scrambler is clocked once after transmission of each bit of SDL
Carlson, et al. expires December 1999 [Page 16]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
data, whether or not the transmitted bit is scrambled. When scram-
bling is enabled for a given octet, the OUT bit is exclusive-ored
with the raw data bit to produce the transmitted bit. Bits within an
octet are transmitted MSB-first.
Reception of scrambled data is identical to transmission. Each
received bit is exclusive-ored with the output of the separate
receive data scrambler.
To generate a scrambler state message, the contents of D47 through D0
are snapshot at the point where the first scrambler state bit is
sent. D47 is transmitted as the first bit of the output. The first
octet transmitted contains D47 through D40, the second octet D39
through D32, and the sixth octet D7 through D0.
The receiver of a scrambler state message MUST first run the CRC-16
check and correct algorithm over this message. If the CRC-16 message
check detects multiple bit errors, then the message is dropped and is
not processed further.
Otherwise, it then should compare the contents of the entire receive
scrambler state D47:D0 with the corrected message. (By pipelining
the receiver with multiple clock stages between SDL Header error-
correction block and the descrambling block, the receive descrambler
will be on the correct clock boundary when the message arrives at the
descrambler. This means that the decoded scrambler state can be
treated as immediately available at the beginning of the D47 clock
cycle into the receive scrambler.)
If any of the received scrambler state bits is different from the
corresponding shift register bit, then a soft error flag is set. If
the flag was already set when this occurs, then a synchronization
slip error is declared. This error SHOULD be counted and reported
through implementation-defined network management procedures. When
the receiver has this soft error flag set, any scrambler state mes-
sage that passes the CRC-16 message check without multiple bit errors
is clocked directly into the receiver's state register after the com-
parison is done, and the soft error flag is then cleared. Otherwise,
while uncorrectable scrambler state messages are received, the soft
error flag state is maintained.
(The intent of this mechanism is to reduce the likelihood that a
falsely corrected scrambler state message with multiple bit errors
can corrupt the running scrambler state.)
Carlson, et al. expires December 1999 [Page 17]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
6. Configuration Details
The following PPP 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 that standard PPP over SDL on POL generally
presents a 32-bit aligned datagram to the network layer. With the
address, control, and protocol field intact, the PPP overhead on each
packet is four octets. If the SDL framer presents the SDL packet
header to the PPP input handling in order to communicate the packet
length , this header is also four octets, and word-alignment is
preserved.
Since SDL does take the place of HDLC as a transport for PPP, it is
at least tempting to remove the HDLC-derived overhead. This is not
done for standard PPP over SDL in order to preserve the message
alignment and the future possibility of Frame Relay internetworking.
By prior external arrangement, any two SDL implementations MAY omit
the address and control fields or implement protocol field compres-
sion. Such use is not standardized and MUST NOT be the default on
any SDL implementation.
Carlson, et al. expires December 1999 [Page 18]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
Appendix A: CRC Generation
The following unoptimized code generates proper CRC-16 and CRC-32
values for SDL messages. Note that the polynomial bits are numbered
in big-endian order for SDL CRCs; bit 0 is the MSB.
typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned long u32;
#define POLY16 0x1021
#define POLY32 0x04C11DB7
u16
crc16(u16 crcval, u8 cval)
{
int i;
crcval ^= cval << 8;
for (i = 8; i--; )
crcval = crcval & 0x8000 ? (crcval << 1) ^ POLY16 :
crcval << 1;
return crcval;
}
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;
}
Carlson, et al. expires December 1999 [Page 19]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
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;
}
Carlson, et al. expires December 1999 [Page 20]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
Appendix B: Error Correction Tables
To generate the error correction table, the following implementation
may be used. It creates a table called sdl_error_position, which is
indexed on CRC residue value. The tables can be used to determine if
no error exists (table entry is equal to FE hex), one correctable
error exists (table entry is zero-based index to errored bit with MSB
of first octet being 0), or more than one error exists, and error is
uncorrectable (table entry is FF hex). To use for eight octet mes-
sages, the bit index from this table is used directly. To use for
four octet messages, the index is treated as an unrecoverable error
if it is below 32, and as bit index plus 32 if it is above 32.
The program also prints out the error syndrome table shown in section
2.9. 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(' ');
Carlson, et al. expires December 1999 [Page 21]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
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_message_error_position[crc]);
}
Carlson, et al. expires December 1999 [Page 22]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
7. Security Considerations
The reliability of communication networks places special requirements
in the handling of data payloads as appropriate to the specific line
encoding schemes. This document describes framing and scrambling
options for SDL over raw lightwave channels that enable the use of
current typical design (non burst mode) optical transceiver and tim-
ing subsystem. In particular, this proposal is compatible with DWDM
regenerator networks. No other security concerns have been identi-
fied.
8. References
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)," RFC
1661, Daydreamer, July 1994.
[2] Simpson, W., Editor, "PPP in HDLC-like Framing," RFC 1662,
Daydreamer, July 1994.
[3] Simpson, W., Editor, "PPP over SONET/SDH," RFC 1619, Daydreamer,
May 1994.
[4] Carlson, Langner, Hernandez-Valencia, Manchester, "PPP over
Simple Data Link (SDL) using SONET/SDH with ATM-like
framing." PPPEXT WG work in progress.
[5] "American National Standard for Telecommunications -
Synchronous Optical Network (SONET) Payload Mappings," ANSI
T1.105.02-1995.
[6] ITU-T Recommendation G.707, "Network Node Interface for the
Synchronous Digital Hierarchy (SDH)," March 1996.
[7] ITU-T Recommendation G.872, "Architecture of Optical
Transport Networks," February 1999.
[8] 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.
[9] Simpson, W., Editor, "PPP LCP Extensions," RFC 1570, Daydreamer,
January 1994.
[10] ITU-T Recommendation I.432.1, "B-ISDN User-Network Interface -
Physical Layer Specification: General Characteristics,"
Carlson, et al. expires December 1999 [Page 23]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
February 1999.
[11] ITU-T Recommendation V.41, "Code-independent error-control
system," November 1989.
[12] 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.
[13] Floyd, S. and V. Jacobson, "Random Early Detection Gateways
for Congestion Avoidance," IEEE/ACM Transactions on
Networking, August 1993.
9. Acknowledgments
The authors recognize Jon Anderson, Bharat Doshi, Subra Dravida and
James Manchester from Lucent Technologies for their various contribu-
tions to this work.
10. Intellectual Properties Considerations
Lucent Technologies Inc. may own intellectual property on some of the
technologies disclosed in this document. The patent licensing policy
of Lucent Technologies Inc. with respect to any patents or patent
applications relating to this submission is stated in the March 1,
1999, letter to the IETF from Dr. Roger E. Stricker, Intellectual
Property Vice President, Lucent Technologies Inc. This letter is on
file in the offices of the IETF Secretariat.
IronBridge Networks has no claim on any of this material.
Carlson, et al. expires December 1999 [Page 24]
INTERNET DRAFT PPP SDL on Packet-over-Lightwave June 1999
11. Authors' Addresses
James Carlson
IronBridge Networks
55 Hayden Avenue
Lexington MA 02421-7996
Phone: +1 781 372 8132
Fax: +1 781 372 8090
Email: carlson@ibnets.com
Enrique J. Hernandez-Valencia
Lucent Technologies Bell Laboratories
101 Crawford Corners Rd.
Holmdel NJ 07733-3030
Email: enrique@lucent.com
Nevin Jones
Lucent Technologies Microelectronics Group
555 Union Boulevard
Allentown PA 18103-1286
Email: nrjones@lucent.com
Paul Langner
Lucent Technologies Microelectronics Group
555 Union Boulevard
Allentown PA 18103-1286
Email: plangner@lucent.com
Carlson, et al. expires December 1999 [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-22 15:17:28 |