Network Working Group W A Simpson [DayDreamer]
Internet Draft
expires in six months August 1998
Applicability Statement for PPP over SONET/SDH
draft-ietf-pppext-sonet-as-00.txt
Status of this Memo
This document is an Internet-Draft. Internet Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute work-
ing 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 not appropriate to use Internet Drafts as refer-
ence material, or to cite them other than as a ``working draft'' or
``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
Directories on:
ftp.is.co.za (Africa)
nic.nordu.net (Northern Europe)
ftp.nis.garr.it (Southern Europe)
ftp.ietf.org (Eastern USA)
ftp.isi.edu (Western USA)
munnari.oz.au (Pacific Rim)
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) William Allen Simpson (1994, 1997-1998). All Rights
Reserved.
Abstract
The Point-to-Point Protocol (PPP) [RFC-1661] provides a standard
method for transporting multi-protocol datagrams over point-to-point
links. This document describes the use of PPP over Synchronous Opti-
cal Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits.
Simpson expires in six months [Page i]
DRAFT PPP AS SONET/SDH August 1998
1. Applicability Statement
PPP over SONET/SDH is intended for those implementations that desire
the PPP encapsulation over high speed private point-to-point links,
such as intra-campus single-mode fiber that may already be installed
and unused.
Some installations have attempted to use commercial long-distance
carriers. Because these services were installed and tested for
voice, and carriers have bid least-cost components that do not meet
the needs of high speed data services, numerous interoperability
problems have arisen. The profile identifies many of these pitfalls,
and recommends practices that avoid them.
1.1. Terminology
The various committees changing the SONET/SDH specifications have
been inconsistent in their terminology. This specification uses a
few simplified terms:
block A fixed-size time-based multiplexing unit, carried
from interface to interface; also known as the SONET
Synchronous Transport Signal (STS-N) Frame, or the
SDH Synchronous Transport Module (STM-N) Frame
Structure. This use of "frame" conflicts with link-
layer use of the same term. The format has more in
common with fixed-length unit record equipment, such
as a magnetic tape, than with a variable-length
packet.
byte An 8-bit quantity; also known as "octet" in stan-
dardese.
envelope A fixed-size time-based multiplexing unit, carried
within successive blocks along a path; also known as
the SONET Synchronous Payload Envelope (SPE), or the
SDH Administrative Unit Group (AUG).
frame A variable-length unit of transmission, which is
passed across the interface between the link-layer
and the physical-layer. A single packet is usually
wrapped in a frame, unless link-layer packet frag-
mentation is performed, or multiple packets are
aggregated into a single frame.
packet The basic unit of link encapsulation, which is
passed across the interface between the network-
Simpson expires in six months [Page 1]
DRAFT PPP AS SONET/SDH August 1998
layer and the link-layer. The packet information is
variable-length.
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC-2119].
To remain consistent with standard Internet practice, and avoid con-
fusion for people used to reading RFCs, all binary numbers in the
following descriptions are in Most Significant Bit to Least Signifi-
cant Bit order, from Most Significant Byte to Least Significant Byte,
reading from left to right, unless otherwise indicated. Note that
this is contrary to ISO and ITU practice, which orders bits as trans-
mitted (network bit order). Keep this in mind when comparing this
document with the other documents.
2. SONET/SDH Profile
"The nice thing about standards is that you have so many to choose
from; furthermore, if you do not like any of them, you can just wait
for next year's model." [Tanenbaum]
"The problem with standards is the last 's'." [Kleinrock]
SONET and SDH were "standardized" by at least 4 different organiza-
tions.
- Bellcore developed the original SONET specification, and has
issued significantly reorganized and revised documents in 1991 and
1995. According the [SONET] Revision History: "Since TR-
TSY-000253, Issue 1, there have been so many revisions to this
material that the use of change bars is impractical."
- ANSI (T1X1 and T1M3) has a separate series of documents, that are
continuously revised, and strongly influenced by a single vendor.
- ETSI also has a separate series of documents, but has greatly ben-
efited by close attention to detail, and coordination with
CCITT/ITU-T.
- CCITT (since renamed ITU-T) published the SDH specifications in
1988. Minor revisions occurred in 1993 and 1994, with a major
reorganization in 1996.
The latter organizations have not maintained consistent naming of
fields and payloads, have made conflicting changes and extensions,
and have been careless about conformity and backward compatibility
Simpson expires in six months [Page 2]
DRAFT PPP AS SONET/SDH August 1998
with existing deployment.
This specification was developed utilizing carefully chosen documents
that reflect a particular point in time, and that correspond to
extant fielded implementations. Where naming conventions are incon-
sistent, or conflict with other network usage of the same terms, a
simpler taxonomy is chosen.
To promote interoperability, this document provides a condensed
description of basic SONET/SDH functionality, together with some of
the recent changes and their relevance, and a profile of recommended
practices.
2.1. Bit Transmission
All bytes are transmitted Most Significant Bit first.
Discussion
Care must be taken when converting from other media, such as
serial links and ethernet, that are transmitted Least Significant
Bit first.
2.1.1. Electrical Bits
SONET specifies an optional electrical transmission capability using
a pair of 75 Ohm coaxial cables, one for each direction.
At 156 Mbps, Coded Mark Inversion (CMI) is specified.
single bits
- - ---
| | | | | | | |
| | | | | | | |
- - ---
"0" "0" "1" "1"
Simpson expires in six months [Page 3]
DRAFT PPP AS SONET/SDH August 1998
A1A2 pattern
--- --- - --- - - - - --- - - -
| | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | |
--- --- - --- - - - --- - - - -
1 1 1 1 0 1 1 0 0 0 1 0 1 0 0 0
or its inverse.
Lower signal rates (52 Mbps) use Bipolar with Three-Zero Substitution
(B3ZS). These rates are not relevant to PPP over SONET/SDH (see
"Physical Layer Requirements").
Discussion
There are no recent changes that might affect interoperability.
At the time of writing, there are no reported router implementa-
tions using CMI electrical transmission to directly feed electro-
optical section or line terminating equipment.
Typically, pseudo-ECL signals over very short inter-component dis-
tances are used to drive the optics with the same encoding pattern
as the optical bits.
Recommendations
As the cost of optical interfaces and cabling has rapidly
decreased, the use of optical transmission is preferred, even for
moderately short intra-office distances.
For electrical intra-office router interconnection, use of
100baseT (or future gigabit ethernet) is preferable to PPP over
SONET/SDH.
2.1.2. Optical Bits
SONET specifies an optical transmission capability using a pair of
fibers, one for each direction. The use of bi-directional fiber
transmission is "for further study".
The optical line coding used for all system interfaces is binary Non-
Return-to-Zero (NRZ). The convention adopted for optical logic level
is
Simpson expires in six months [Page 4]
DRAFT PPP AS SONET/SDH August 1998
logical 1 -- emission of light
logical 0 -- no emission of light
single bits
---
| |
| |
---
"0" "1"
A1A2 pattern
--------------- ------- --- ---
| | | | | | |
| | | | | | |
--- ----------- --- -----------
1 1 1 1 0 1 1 0 0 0 1 0 1 0 0 0
To simplify the development of compatible multi-vendor systems, it is
desirable to define a relatively small set of categories and corre-
sponding optical interface specifications.
Short Reach (intra-office)
SONET optical sections having loss budgets of 0 dB to 7 dB; alter-
natively, SDH interconnect distances less than 2 kilometers.
Intermediate Reach (short haul inter-office)
SONET optical sections having loss budgets of 0 dB to 12 dB;
alternatively, SDH interconnect distances up to 15 kilometers.
Long Reach (long haul inter-office)
SONET optical sections having loss budgets of 10 dB to 28 dB;
alternatively, SDH interconnect distances up to 40 kilometers at
1310 nanometers, and up to 60 kilometers at 1550 nanometers.
Unfortunately, the current proliferation of specifications falls far
short of this goal, having different category definitions (as seen
above) and more than 20 total pages of parameter tables.
Discussion
There are too many recent changes that impede interoperability to
detail in this short overview.
Care must be taken when comparing signals from other media, such
Simpson expires in six months [Page 5]
DRAFT PPP AS SONET/SDH August 1998
as high speed serial links, where "no signal" is "logical 1".
At the time of writing, the majority of reported implementations
use "intermediate" level 1310 nanometer optics with single mode
fiber. This can accommodate multi-mode fiber and short reach
(intra-office) interconnection with the addition of transmitter
attenuation.
Upgrading to future higher speeds would be facilitated by
installing single mode fiber instead of multi-mode fiber.
Recommendations
The greatest interoperability and economies of scale will be
achieved with deployment of a few general interface choices, all
for single mode fiber:
Intermediate Reach equipment at 1310 nanometers for each STM
line speed.
Long Reach equipment at 1550 nanometers for 2 Gbps and above.
2.1.3. Bit Scrambling
Optical interface signals use NRZ binary line coding (described
above). A series of repeated bits will not feature any signal level
transitions. Such transitions (zeros to ones and ones to zeros) are
needed at the receiver to dynamically correct bit timing variance for
line rate clock recovery. Therefore, although it has no effect on
random data, the signal is scrambled against the possibility that a
very long series of ones or zeros might naturally occur in the trans-
mitted bit stream.
Electrical interface signals use line encoding (B3ZS and CMI) that
assures adequate transitions. Scrambling is not needed. However,
they are also scrambled for consistency between the electrical and
optical component interfaces.
In both cases, a 7-bit linear feedback shift register (LFSR) is iden-
tically applied at the transmitter and receiver. The sequence of
bits from the x**7 stage of the LFSR is exclusive-or'd (in most sig-
nificant bit order) with the output bits before transmission, and
with the corresponding input bits after signal recovery.
The first row of the STM-N transmission block overhead (N * 9 bytes
described later) is not scrambled. The 7-bit LFSR state is reset to
bit value 1111111 (127 decimal) on the most significant bit of the
Simpson expires in six months [Page 6]
DRAFT PPP AS SONET/SDH August 1998
byte following the block overhead. The scrambler runs continuously
from that bit onward, throughout the remainder of the transmission
block.
The generating polynomial for the LFSR is x**7 + x**6 + 1. The
resulting 127-bit sequence repeats in a 127 byte stream (shown in
hex):
fe 04 18 51 e4 59 d4 fa 1c 49 b5 bd 8d 2e e6 55
fc 08 30 a3 c8 b3 a9 f4 38 93 6b 7b 1a 5d cc ab
f8 10 61 47 91 67 53 e8 71 26 d6 f6 34 bb 99 57
f0 20 c2 8f 22 ce a7 d0 e2 4d ad ec 69 77 32 af
e0 41 85 1e 45 9d 4f a1 c4 9b 5b d8 d2 ee 65 5f
c0 83 0a 3c 8b 3a 9f 43 89 36 b7 b1 a5 dc ca bf
81 06 14 79 16 75 3e 87 12 6d 6f 63 4b b9 95 7f
02 0c 28 f2 2c ea 7d 0e 24 da de c6 97 73 2a
Discussion
There are no recent changes that might affect interoperability.
The scrambling mechanism is defective in a packet transmission
context, where adjacent bytes are sequentially related. Appar-
ently, the short polynomial assumed unrelated data that is
obtained from DS0 through DS3 circuits. This is characteristic
for legacy technology such as Asynchronous Transfer Mode (ATM),
interleaved virtual circuits, or voice traffic.
Since the feedback is based on the internal state of the LFSR, and
is not dependent on its interaction with previous bytes, any sub-
set of the bit sequence that exactly matches the phase of the LFSR
will generate a series of zeros. The bitwise inverse of the bit
sequence will generate a series of ones.
This effect is not limited to direct PPP over SONET/SDH. Any
packet oriented transmissions carried by SONET/SDH without inter-
leaving would have the same result.
Moreover, although the 127 byte stream may have been appropriate
for the original STS-1 (90 bytes per row), this length is mani-
festly insufficient for STM-N (N * 270 bytes per row).
Finally, the most egregious flaw in this part of the SONET/SDH
specification, the number of bits permitted without a transition
is not explicitly defined. Instead, the value is implicitly
derived from the fixed length scrambling sequence versus the vari-
able length Loss of Signal (LOS) condition based on the link speed
(described later).
Simpson expires in six months [Page 7]
DRAFT PPP AS SONET/SDH August 1998
Note that the complete scrambling byte stream cannot be repre-
sented in a valid PPP packet. The pair "fd 03" is not conformant,
limiting the maximum sequence without a transition to 127 bytes.
Recommendations
Packet transmissions carried at rates less than 156 Mbps MUST be
interleaved under the VT/TU scheme (see "Physical Layer Require-
ments"). This is consistent with prior use of bit-synchronous
HDLC (and Frame Relay) over DS0 through DS3 circuits.
Line rate clock recovery SHOULD be sufficiently stable to with-
stand periods of 1016 repeated one or zero bits (127 bytes).
2.1.4. Loss of Signal (LOS)
To detect a failure that occurs at the transmitter (such as laser
failure) or within the transmission facility (such as a fiber cut),
all incoming signals (optical and electrical) are monitored for Loss
of Signal (LOS) before descrambling, by detecting a lack of suffi-
cient signal level transitions to ensure accurate line rate clock
recovery.
No transitions on the incoming signal is not considered LOS when the
condition lasts 2.3 microseconds or less, and is considered LOS when
the condition lasts 100 microseconds or more. The treatment of no
transitions lasting between 2.3 microseconds and 100 microseconds for
the purpose of LOS detection is not specified (left to the choice of
the equipment designer).
For electrical (B3ZS and CMI) interfaces, the no voltage transitions
condition is easily distinguished from an "all-zeros pattern".
For SONET optical (and component) interfaces, the no light pulses
condition corresponds to an "all-zeros pattern". For testing SONET
compliance with the LOS detection requirement, it suffices to apply
an "all-zeros pattern" lasting at most 2.3 microseconds, and to apply
an "all-zeros pattern" lasting at least 100 microseconds. Optical
equipment shall enter the LOS state within 100 microseconds of the
onset of the incoming "all-zeros pattern."
For SDH optical (and component) interfaces, equipment may also indi-
cate LOS within 3 milliseconds of the time the received signal level
drops below an implementation-determined threshold (based on receiver
sensitivity). The threshold should be selected such that LOS will
not be indicated while the Bit Error Rate (BER) is still acceptable.
For SDH, the BER is defined to be 1 in 10**(-3).
Simpson expires in six months [Page 8]
DRAFT PPP AS SONET/SDH August 1998
Note that the secondary method is in addition to the primary method,
not in lieu of it, and is not required to be implemented in SONET
installations.
The equipment shall terminate the LOS condition when the incoming
signal has two consecutive valid block alignment patterns (described
later), and during the intervening time (125 microseconds) sufficient
transitions prevent another LOS defect.
For trouble isolation purposes, especially for intermittent failures,
it is important to distinguish between LOS and other signal failure
conditions, such as Loss of Frame (LOF).
Discussion
There are significant differences between SONET, ANSI, and SDH;
SDH does not describe the primary method of detection. Circa
1994, this resulted in the addition of the secondary method to
SONET.
There is no explicit requirement given for the "all-ones pattern"
that would indicate a stuck clock or laser transmitter. The same
difficulty with lack of transitions will apply.
There is no rationale given for the selection of 2.3 us and 100
us. Presumably, 100 us was chosen to allow sufficient variance
between 125 us block alignment patterns. However, 100 us will
cause multiple errors in the block overhead (described later),
while 2.3 us is too short to cause any significant damage.
The wide disparity between 2.3 us and 100 us, and leaving the
error treatment to the vendor, has caused many interoperability
problems. Incorrect LOS values as low as 1 +-0.750 us have been
discovered. Typical values for valid designs are 20 +-3 us, and
26 +-1 us. No values higher than 30 us have been found.
Line rate clock stability has been a related interoperability
problem. Early 156 Mbps implementations were very robust, and
could handle periods of 2,000 bits with no transitions. Some sam-
ple and/or low quality implementations have not been as robust;
failure has been noted as low as 72 to 80 bits without transi-
tions.
Simpson expires in six months [Page 9]
DRAFT PPP AS SONET/SDH August 1998
Recommendations
Using the minimum and maximum specification of LOS, line rate
clock recovery MUST be sufficiently stable to withstand periods of
repeated one or zero bits:
Mbps min bits max bits
156 358 15,552
622 1,431 62,208
2,488 5,724 248,832
Implementations compatible with this specification SHOULD observe
a stricter range of LOS detection, between 13.89 us and 27.26 us:
Mbps min bits max bits
156 2,161 4,240
622 8,641 16,960
2,488 34,561 67,840
The lower limit affects no more than one row of overhead, while
the upper limit includes at least one row of overhead.
When a circuit path is divided into multiple line sections, the
LOS is not propagated end to end. A hidden section can fail inde-
pendently. Therefore, the LOS indication is only advisory, and
the (possibly improperly) decoded signal bits MUST be passed to
the next section. The framed PPP packet FCS is used to detect the
failure.
Some SONET framers provide a test feature to send an "all-zeroes
pattern" (post scrambling) that forces the LOS alarm downstream.
Alternatively, the pattern can be simulated with software. This
SHOULD be used to test for compatible equipment during the instal-
lation of the circuit, by generating progressively longer zero
patterns, to verify that the circuit meets the requirements of
this profile.
2.2. Block Transmission
SONET/SDH transmits each block at precise 125 microsecond intervals.
This corresponds to the traditional 4 kHz voice digital sampling rate
used for DS0.
Each block is divided into 9 logical "rows".
For "concatenated" STS/STM, each row consists of some multiple of 270
byte "columns".
Simpson expires in six months [Page 10]
DRAFT PPP AS SONET/SDH August 1998
Block transmission overhead is arranged into layers, which correspond
to different equipment interfaces that might occur in the path of a
single circuit. Although SONET and SDH use inconsistent terms, the
layers have a general equivalence.
SONET divides its Network Element (NE) interface overhead into Sec-
tion (SOH), Line (LOH), and Path (POH).
SDH has a corresponding Network Node Interface (NNI) overhead called
Regenerator-Section (RSOH), Multiplex-Section (MSOH), and Path (POH).
There are 3 rows of (Regenerator) Section Overhead (SOH or RSOH), and
6 rows of Line or Multiplex-Section Overhead (LOH or MSOH).
2.2.1. Block Overhead
The STS-3c/STM-1 transmission block overhead consists of 9 byte
columns at the beginning of each 270 byte row, with the remaining 261
bytes used for the data envelope(s).
+----+----+----+----+----+----+----+----+----+----------
| A1 A1 A1 A2 A2 A2 J0 Z0 Z0 envelope
+----+----+----+----+----+----+----+----+----+----------
| B1 ++ ++ E1 ++ ?? F1 ** ** envelope
+----+----+----+----+----+----+----+----+----+----------
| D1 ++ ++ D2 ++ ?? D3 ?? ?? envelope
+----+----+----+----+----+----+----+----+----+----------
| H1 H1# H1# H2 H2# H2# H3 H3 H3 envelope
+----+----+----+----+----+----+----+----+----+----------
| B2 B2 B2 K1 ?? ?? K2 ?? ?? envelope
+----+----+----+----+----+----+----+----+----+----------
| D4 ?? ?? D5 ?? ?? D6 ?? ?? envelope
+----+----+----+----+----+----+----+----+----+----------
| D7 ?? ?? D8 ?? ?? D9 ?? ?? envelope
+----+----+----+----+----+----+----+----+----+----------
| D10 ?? ?? D11 ?? ?? D12 ?? ?? envelope
+----+----+----+----+----+----+----+----+----+----------
| S1 Z1 Z1 Z2 Z2 M1 E2 ** ** envelope
+----+----+----+----+----+----+----+----+----+----------
++ media dependent.
** reserved for national use.
?? reserved for future use, SHOULD be zero.
Values relevant to this specification:
Simpson expires in six months [Page 11]
DRAFT PPP AS SONET/SDH August 1998
(A1) bit value 1111 0110 (f6 hex)
(A2) bit value 0010 1000 (28 hex)
(H1) and (H2) Each of the 3 consecutive pairs of H1H2 is taken as
a 16-bit mask, with various combinations of bits
determining the offset (in multiples of 3*N) to the
start of the data envelope. An offset of 0 indi-
cates that the envelope immediately follows the last
H3 overhead byte. An offset of 522 indicates that
the envelope immediately follows the last Z0 over-
head byte in the next transmission block.
When used for this specification, the second and
third H1#H2# pairs are always bit value 1001 xx11
1111 1111 (93ff hex), indicating a "concatenated"
envelope, where xx is ignored on receipt.
Since the block is transmitted by row, the overhead columns are
interspersed with envelope columns, complicating generation and
recovery.
An additional complication is added by the section-level bit scram-
bling. Overhead bytes of the first row (A1, A2, J0, Z0) are not
scrambled.
Discussion
J0 was formerly called C1. Z0 was formerly additional copies of
C1, but these bytes are now reserved for national use.
The xx bit values in H1# were originally 00 for SONET and 10 for
SDH.
These changes might affect interoperability between international
facilities.
The scrambler needs a reset signal to indicate the position of the
beginning of the transmission block and length of the overhead.
Failure of the reset signal timing could prevent recognition of
the block.
Teleopolists seem inordinately fond of groups of 3. This was evi-
dent in early digital efforts (24 DS0 in T1), and continues into
SONET/SDH (3 T3/E3 in STM-1). Note that all of the values,
including 261 and 270, are divisible by 3. This does not scale
well in a digital processing environment.
Simpson expires in six months [Page 12]
DRAFT PPP AS SONET/SDH August 1998
Recommendations
Envelopes SHOULD be sent with the H1H2 offset of 522. However,
every implementation MUST be prepared to receive a variable off-
set.
2.2.2. Block Synchronization
Timing alignment is detected by searching for (a subset of) the A1
and A2 overhead pattern. There are two levels of synchronization
recovery.
When synchronization has been lost for 3 milliseconds or more (or has
never been achieved), long-term synchronization recovery requires
detection of a minimum of eight (8) successive error-free A1 and A2
overhead patterns. The maximum recovery time is 3 milliseconds (24
error-free patterns).
Once alignment has been achieved, short-term synchronization loss is
declared when four (4) or more consecutive A1 and A2 pattern errors
have been detected. The maximum detection time is 625 microseconds.
The algorithm used shall be such that, under normal operation, a
10**(-3) Poisson distribution of bit errors will not cause a false
loss indication more than once every 6 minutes.
Recovery from a short-term synchronization loss requires detection of
only two (2) successive error-free A1 and A2 overhead patterns. Any
recovery circuitry is acceptable that achieves resynchronization
within the 250 microsecond interval implied by this definition.
Failure to obtain resynchronization within 24 blocks (3 milliseconds)
results in a long-term synchronization loss declaration, called Loss
of Frame (LOF).
Discussion
The SDH specification is incomplete, and is missing some time
intervals.
Conversely, SDH has a somewhat stricter requirement for resynchro-
nization after a short-term loss; the algorithm used shall be such
that, with a random signal, the probability for false recovery is
no more than 10**(-5) per 250 microsecond interval.
Simpson expires in six months [Page 13]
DRAFT PPP AS SONET/SDH August 1998
Recommendations
Because of the interaction between block synchronization detec-
tion, termination of the Loss of Signal (LOS) condition, and the
first row reset of the section-level bit scrambling, the detection
circuitry MUST be independent (upstream) of the scrambler, and
trigger the subsequent scrambler reset timing.
2.2.3. Envelope Overhead
A series of envelopes appear within the transmission block. These
envelopes float to allow precise timing alignment and jitter correc-
tion as the payload is carried over the circuit path. The position
of the envelope(s) head within the block is specified by the H1 and
H2 pair(s). The envelope(s) tail can carry over into the next trans-
mission block.
The STS-3c/STM-1 Path Overhead (POH for both SONET and SDH) consists
of a 1 byte column, with the remaining bytes used for the payload
data.
+----+---------
| J1 payload
+----+---------
| B3 payload
+----+---------
| C2 payload
+----+---------
| G1 payload
+----+---------
| F2 payload
+----+---------
| H4 payload
+----+---------
| Z3 payload
+----+---------
| Z4 payload
+----+---------
| Z5 payload
+----+---------
Values relevant to this specification:
(J1) Path Trace. Carries one byte at a time of a repeat-
ing 64-byte fixed-length string (SONET) or a 16-byte
E.164 number (SDH), so that a path receiving termi-
nal can verify its continued connection to the
Simpson expires in six months [Page 14]
DRAFT PPP AS SONET/SDH August 1998
intended transmitter.
(C2) Path Signal Label. Indicates the composition, con-
struction and content of the envelope payload.
(H4) Multipurpose Position Indicator. Used by specific
payload mappings, such as Floating Virtual Tribu-
tary.
Since the envelope is transmitted by row, the path overhead columns
are interspersed with payload columns, and the combination are inter-
spersed with block overhead columns, complicating generation and
recovery.
Discussion
The envelope payload provides the physical-layer interface for
insertion of PPP encapsulated packets.
The J1 16-byte E.164 number format is rarely applicable, as there
is no voice circuit involved in packets. Neither have fielded
implementations observed strict adherence to the 64-byte limita-
tion. A widely used implementation has generated a string con-
sisting of the following pattern, each line CRLF terminated:
Remote hostname : sl-bb10
Remote interface: POS9
Remote IP addr : 127.255.255.255
Remote Rx(K1/K2): 00/00 Tx(K1/K2): 00/00
The C2 value is primarily informational. It is difficult to use
for applying alternate processing for adjacent envelopes, as it
occurs after two rows of the envelope have already been processed.
Although there is no need for intermediate transit equipment to
interpret the value, some equipment fails upon encountering an
unrecognized value.
At first glance this floating envelope may appear to be a highly
efficient technique to avoid interface buffering of synchronized
incoming data. Unfortunately, due to interspersing the overhead
with the data, it is impossible to determine where the envelope
begins until at least a third of the transmission block has been
received.
Also, the envelope head can begin much later in the same block, or
even in the next block. An envelope tail can carry over into a
block that is two blocks later than the H1H2 overhead that indi-
cates its head.
Simpson expires in six months [Page 15]
DRAFT PPP AS SONET/SDH August 1998
Thus, in a packet switched network, no matter how fast the link
speed, a minimum of 125 microseconds is added at every hop, and
cut-through routing is difficult or impossible.
Recommendations
See [RFC-xxxx] "Physical Layer Requirements".
2.2.4. Envelope Ordering
SONET and SDH differ in the ordering of envelope rows. Several
schemes are described, including:
J1 ...
B3 ...
C2 ...
J1 ...
B3 ...
C2 ...
J1 ...
B3 ...
C2 ...
J1 ... J1 ... J1 ...
B3 ... B3 ... B3 ...
C2 ... C2 ... C2 ...
J1 J1 J1 ...
B3 B3 B3 ...
C2 C2 C2 ...
Another difficulty has been the interleaving of lower rate channels
within envelopes. These are time division multiplexed.
In the SONET and SDH specifications, much of the complexity is due to
these multi-stage multiplexing schemes.
Discussion
After optical specifications, this has been the worst impediment
to interoperability.
As carriers have upgraded equipment to STS-3c/STM-1 and
STS-12c/STM-4, some have merely reconnected older equipment with
Simpson expires in six months [Page 16]
DRAFT PPP AS SONET/SDH August 1998
coax (see "Electrical Bits"). This is often haphazard. Although
this has no effect on voice, where each byte is a separate chan-
nel, this is unacceptable for packets.
Recommendations
Higher data rate envelopes, and the bytes within envelopes, MUST
be sequentially ordered by row.
SDH VC-3/VC-4/VC-4-Xc ordering MUST be supported.
Envelope data MUST be carried from source to sink in sequential
order. That is, bytes inserted in the order "1234" MUST arrive in
the same order "1234".
At the current setup and monthly charges of hundreds of thousands
of US Dollars, installations can insist that equipment be care-
fully configured, or will need to find an alternative carrier.
2.2.5. Payload Insertion
Various ordering schemes differ only in the location of duplicate
POH. These redundant POH bytes are specified as "fixed stuff", and
the values are not examined.
For example, in the previous section, the latter schemes interleave
the redundant POH bytes throughout the row (VC-3/VC-4), or concate-
nate the redundant POH bytes at the beginning of the row (VC-4-Xc).
Recommendations
See [RFC-xxxx] "The Data Link Layer". The specification finesses
the issue by filling the "fixed stuff" with packet data. This
make VC-4 and VC-4-Xc identical with respect to packet processing.
2.2.6. Protection Switching
SONET provides Automatic Protection Switching (APS), also known as
the SDH Multiplex Section Protection Function (MSP), to switch from
one circuit to another spare circuit whenever a problem is detected.
This switch can take place based on Signal Fail (SF), Signal Degrade
(SD), or by manual intervention. Once switching is initiated, it can
take up to 50 milliseconds to complete the switch.
Signal Fail (SF) is defined as LOS, LOF, BER exceeding 10**(-3), and
various other error conditions.
Simpson expires in six months [Page 17]
DRAFT PPP AS SONET/SDH August 1998
Signal Degrade (SD) is defined as BER exceeding a user selectable
range from 10**(-5) to 10**(-9).
The protection switch applies to all circuits in one direction simul-
taneously. Bidirectional switching is optional.
Discussion
This time domain switching facility wastes entire backup links
against the rare possibility that a link might fail. Worse, these
links are frequently in the same cable, and backhoe fade kills all
the links.
Conversely, Internet routing utilizes all available circuits con-
currently, and gracefully degrades while providing best-effort
packet switching around points of failure.
Since this specification is intended for carrying PPP packets over
point-to-point links in a routed network, APS/MSP is superfluous.
During intermittent failures, due to the many orders of magnitude
time difference between activation (microseconds) and completion
of switching (milliseconds), and the severe extended packet loss,
APS/MSP link flapping can interact badly with routing protocols.
It usually costs more, with no added benefit.
Recommendations
Where SONET/SDH circuit path configuration is under control of the
user, APS/MSP SHOULD be disabled.
Security Considerations
This specification introduces no known security vulnerabilities.
Section-level bit scrambling consists of a simple repeated XOR with a
short, easily computed, LFSR bit stream (listed earlier). This is
not a pseudo-random number generator. There is no practical crypto-
graphic security.
Simpson expires in six months [Page 18]
DRAFT PPP AS SONET/SDH August 1998
Acknowledgements
PPP over SONET was first proposed by Craig Partridge (BBN). Some
information was obtained from the good folks at Bellcore.
Technical assistance and information was also provided by Victor Dem-
janenko (SUNY Buffalo).
Considerable explanatory text was contributed by C. M. Heard (VVNet).
Anonymous, Karl Fox (Ascend), Peter Lothberg (Sprint), Subhash Roy
(TranSwitch), Stuart Venters (Adtran), and Eric Verwillow (Juniper)
provided useful critiques of earlier versions of this document.
Special thanks to Ascend Communications (nee Morning Star Technolo-
gies) for providing computing resources and network access support
for writing this specification.
References
[RFC-1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
STD-51, DayDreamer, July 1994.
[RFC-1662] Simpson, W., Editor, "PPP in HDLC-like Framing", STD-51,
DayDreamer, July 1994.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP-14, Harvard University, March
1997.
[RFC-xxxx] Simpson, W., Editor, "PPP over SONET/SDH", DayDreamer,
work in progress.
[SONET] "Synchronous Optical Network (SONET) Transport Systems:
Common Generic Criteria", Bellcore, TR-NWT-000253 Issue
2, December 1991.
[G.707] CCITT Recommendation G.707, "Synchronous Digital Hierar-
chy Bit Rates", June 1992.
Simpson expires in six months [Page 19]
DRAFT PPP AS SONET/SDH August 1998
Contacts
Comments about this document should be discussed on the
pppsdh@greendragon.com or ietf-ppp@merit.edu mailing lists.
This document was reviewed by the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force (IETF). The working
group can be contacted via the current chair:
Karl Fox
Ascend Communications
655 Metro Place South, Suite 370
Dublin, Ohio 43017
karl@Ascend.com
Questions about this document can also be directed to:
William Allen Simpson
DayDreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
Simpson expires in six months [Page 20]
DRAFT PPP AS SONET/SDH August 1998
Full Copyright Statement
Copyright (C) William Allen Simpson (1994, 1997-1998). All Rights
Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this doc-
ument itself may not be modified in any way, except as required to
translate it into languages other than English.
This document and the information contained herein is provided on an
"AS IS" basis and the author(s) DISCLAIM 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.
Simpson expires in six months [Page 21]
