Network Working Group W A Simpson [DayDreamer]
Internet Draft
expires in six months August 1998
PPP over SONET/SDH
draft-ietf-pppext-sonet-ds-01.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 (1993-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 over SONET/SDH August 1998
1. Introduction
PPP was designed as a standard method of communicating over point-to-
point links. Initial deployment has been over short local lines,
leased lines, and plain-old-telephone-service (POTS) using modems.
As new packet services and higher speed lines are introduced, PPP is
easily deployed in these environments as well.
The Synchronous Optical Network [SONET] is a time division multiplex-
ing scheme that defines a family of standard rates and formats.
Despite the name, it is not limited to optical links. The ITU-T Syn-
chronous Digital Hierarchy (SDH) attempts to internationalize SONET
to provide interworking beteen networks based on different ple-
siochronous digital hierarchies and speech encoding regimes.
The SONET and SDH efforts specify an entire infrastructure, from
physical-layer through network-layer to application-layer. The upper
layers rely on ISO CLNP, TP4/CLNS, ASN.1, ASCE, CMISE, and an exten-
sive list of ITU-T X.committee specifications.
Where SONET/SDH is configured as a point-to-point circuit, PPP is
well suited to use over these links. PPP provides link-layer packet
encapsulation with framing, and treats SONET/SDH in its entirety
merely as an overly complicated physical-layer, ignoring its other
features.
Because the PPP encapsulation has relatively low overhead, it is
anticipated that substantially higher throughput can be attained com-
pared to other SONET/SDH payload mappings, at a significantly lower
cost for line termination equipment.
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.
Simpson expires in six months [Page 1]
DRAFT PPP over SONET/SDH August 1998
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-
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. Physical Layer Requirements
PPP treats SONET/SDH transport as an octet-oriented synchronous link.
SONET/SDH links are bi-directional and full-duplex by definition.
Interface Format
PPP presents an octet interface to the physical layer. There is
no provision for sub-octets to be supplied or accepted.
The octet stream is mapped into the SONET/SDH envelope payload,
with the octet boundaries aligned with the payload byte bound-
aries.
Simpson expires in six months [Page 2]
DRAFT PPP over SONET/SDH August 1998
PPP Authentication is preferable to the use of Path Trace (J1) for
confirming connection between the correct peers.
The Path Signal Label (C2) is intended to indicate the contents of
the envelope.
16 (10 hex) has been assigned to indicate PPP in octet-synchronous
HDLC-like framing [RFC-1662] with ATM-style payload scrambling.
This scrambling MUST be configurable at both terminals, and
SHOULD NOT be enabled by default. This technique is only used
at STS-3c/STM-1.
17 (11 hex) has been assigned to indicate PPP in ether-like fram-
ing [RFC-yyyy] with LSFR payload scrambling.
207
(cf hex) SHOULD be used to indicate PPP in octet-synchronous
HDLC-like framing [RFC-1662]. Byte sequences that might other-
wise need scrambling (for under-performing circuits) are
escaped using optional prophylactic octet-stuffing. This tech-
nique is only used at STS-3c/STM-1 and STS-12c/STM-4.
An implementation MUST also allow configuration of the C2 field to
0 (Unequipped) or 1 (Non-Specific Payload).
The Multipurpose Position Indicator (H4) is currently unused, and
MUST be zero.
Transmission Rate
The SONET transmission rates are integral multiples of 51.840
Mbps, which may be used to carry T3/E3 signals. The allowed mul-
tiples are currently specified (in Mbps) as
STS-1 51.840 STS-18 933.120
STS-3 155.520 STS-24 1,244.160
STS-9 466.560 STS-36 1,866.240
STS-12 622.080 STS-48 2,488.320
STS-192 9,953.280
SDH defines a subset of SONET transmission rates beginning at
155.520 Mbps [G.707]
Simpson expires in six months [Page 3]
DRAFT PPP over SONET/SDH August 1998
SONET SDH equivalent
STS-3c STM-1
STS-12c STM-4
STS-48c STM-16
STS-192c STM-48
The basic rate chosen for this specification is that of
STS-3c/STM-1 at 155.520 Mbps. The available information bandwidth
is 149.760 Mbps, which is the STS-3c/STM-1 envelope payload with
overhead removed. This is the same super-rate mapping that is
used for ATM and FDDI.
Lower signal rates MUST use the SONET Virtual Tributary (VT) mech-
anism, also known as SDH Tributary Units (TU) and Virtual Contain-
ers (VC). This maps existing signals up to T3/E3 rates asyn-
chronously into the envelope, or uses available clocks for bit-
synchronous and byte-synchronous mapping.
Higher signal rates SHOULD conform to the SDH STM series, rather
than the SONET STS series, as equipment becomes available. The
STM series progresses in powers of 4 (instead of 3), and employs
fewer steps, which is likely to simplify multiplexing and integra-
tion, thereby promoting interoperability.
Control Signals
PPP does not require the use of control signals. When available,
using such signals can allow greater functionality and perfor-
mance. Implications are discussed in [RFC-1662].
For more information on the specification of the SONET/SDH interface,
see [RFC-zzzz].
3. The Data Link Layer
The framed PPP packet MUST be mapped directly into the envelope pay-
load by row, skipping a single column for Path Overhead (POH), and
filling any fixed-stuff columns. Because packets are variable in
length, the frames are allowed to carry over envelope boundaries.
Interleaving and separating VT/TU PPP packet streams over multiple
circuit paths are beyond the scope of this specification.
Simpson expires in six months [Page 4]
DRAFT PPP over SONET/SDH August 1998
3.1. STS-3c/STM-1 and STS-12c/STM-4
By default, octet-synchronous HDLC-like framing [RFC-1662] MUST be
implemented.
As an option, octet-synchronous Frame Relay [RFC-1973bis] MAY be
implemented.
3.2. STS-48c/STM-4 and above
By default, ether-like framing [RFC-yyyy] MUST be implemented.
4. Configuration Details
The standard LCP 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
Link Quality Monitoring
Self Describing Padding
32-bit FCS
Simpson expires in six months [Page 5]
DRAFT PPP over SONET/SDH August 1998
A. Payload Scrambling
Several suggestions have been made for reducing the possibility that
a maliciously chosen payload can cause a long sequence of one or zero
bits, resulting in the Loss of Signal (LOS) indication. Implementa-
tions strictly conforming to original SONET specification are not
subject to this problem, and the recommendations in the [RFC-zzzz]
profile completely prevent this problem.
However, the profile recommends testing for non-conforming installa-
tions. When the recommended installation test detects that line rate
clock recovery is not sufficiently stable to meet the requirements of
this specification, Prophylactic Octet Stuffing MAY be configured by
the sending peer. There is no requirement that this method be imple-
mented.
A.1. Prophylactic Octet Stuffing
The installation test SHOULD determine the maximum number of bytes
that can be safely sent, and configure the allowance at one less.
The transmitter checks the outgoing bytes, and adds an escape when-
ever the allowance is exceeded.
The principal advantage of this method is that it is fully backward
compatible. The receiver does not need to make any changes, as
octet-stuffing escapes are already handled.
Also, there are no additional error patterns introduced that are
undetectable by the FCS.
Moreover, this method operates on octets rather than bits, and is
parallelizable in the same fashion as HDLC-like framing.
Finally, the resulting protection is complete, rather than proba-
bilistic.
/* Detect SONET/SDH section scrambler pattern in PPP data.
* 1996 May, William Allen Simpson
*/
typedef unsigned char uint8;
/* Combining the patterns for all-zeros and all-ones, each
* byte in this table contains the next byte in the pattern.
* There are 2 bytes that do not appear in the patterns
* (00 and ff). These are both directed to 7d, as the series
* "7d 0e" is not a feasible PPP construct.
Simpson expires in six months [Page 6]
DRAFT PPP over SONET/SDH August 1998
*/
uint8 pattern[256] =
{ 0x7d, 0xfb, 0x0c, 0xf7, 0x18, 0xe3, 0x14, 0xef,
0x30, 0xcb, 0x3c, 0xc7, 0x28, 0xd3, 0x24, 0xdf,
0x61, 0x9a, 0x6d, 0x96, 0x79, 0x82, 0x75, 0x8e,
0x51, 0xaa, 0x5d, 0xa6, 0x49, 0xb2, 0x45, 0xbe,
0xc2, 0x39, 0xce, 0x35, 0xda, 0x21, 0xd6, 0x2d,
0xf2, 0x09, 0xfe, 0x05, 0xea, 0x11, 0xe6, 0x1d,
0xa3, 0x58, 0xaf, 0x54, 0xbb, 0x40, 0xb7, 0x4c,
0x93, 0x68, 0x9f, 0x64, 0x8b, 0x70, 0x87, 0x7c,
0x7e, 0x85, 0x72, 0x89, 0x66, 0x9d, 0x6a, 0x91,
0x4e, 0xb5, 0x42, 0xb9, 0x56, 0xad, 0x5a, 0xa1,
0x1f, 0xe4, 0x13, 0xe8, 0x07, 0xfc, 0x0b, 0xf0,
0x2f, 0xd4, 0x23, 0xd8, 0x37, 0xcc, 0x3b, 0xc0,
0xbc, 0x47, 0xb0, 0x4b, 0xa4, 0x5f, 0xa8, 0x53,
0x8c, 0x77, 0x80, 0x7b, 0x94, 0x6f, 0x98, 0x63,
0xdd, 0x26, 0xd1, 0x2a, 0xc5, 0x3e, 0xc9, 0x32,
0xed, 0x16, 0xe1, 0x1a, 0xf5, 0x0e, 0xf9, 0x02,
0xfd, 0x06, 0xf1, 0x0a, 0xe5, 0x1e, 0xe9, 0x12,
0xcd, 0x36, 0xc1, 0x3a, 0xd5, 0x2e, 0xd9, 0x22,
0x9c, 0x67, 0x90, 0x6b, 0x84, 0x7f, 0x88, 0x73,
0xac, 0x57, 0xa0, 0x5b, 0xb4, 0x4f, 0xb8, 0x43,
0x3f, 0xc4, 0x33, 0xc8, 0x27, 0xdc, 0x2b, 0xd0,
0x0f, 0xf4, 0x03, 0xf8, 0x17, 0xec, 0x1b, 0xe0,
0x5e, 0xa5, 0x52, 0xa9, 0x46, 0xbd, 0x4a, 0xb1,
0x6e, 0x95, 0x62, 0x99, 0x76, 0x8d, 0x7a, 0x81,
0x83, 0x78, 0x8f, 0x74, 0x9b, 0x60, 0x97, 0x6c,
0xb3, 0x48, 0xbf, 0x44, 0xab, 0x50, 0xa7, 0x5c,
0xe2, 0x19, 0xee, 0x15, 0xfa, 0x01, 0xf6, 0x0d,
0xd2, 0x29, 0xde, 0x25, 0xca, 0x31, 0xc6, 0x3d,
0x41, 0xba, 0x4d, 0xb6, 0x59, 0xa2, 0x55, 0xae,
0x71, 0x8a, 0x7d, 0x86, 0x69, 0x92, 0x65, 0x9e,
0x20, 0xdb, 0x2c, 0xd7, 0x38, 0xc3, 0x34, 0xcf,
0x10, 0xeb, 0x1c, 0xe7, 0x08, 0xf3, 0x04, 0x7d
};
int pattern_allowed = 7; /* maximum number of bytes
permitted before escaping,
default 7 */
int pattern_found = 0; /* count of bytes matched */
uint8 pattern_next = 0x7e; /* next byte in pattern,
assume start of HDLC frame */
/* Check a byte stream for a pattern matching sequence
* exceeding the allowed match length. Return true/false.
Simpson expires in six months [Page 7]
DRAFT PPP over SONET/SDH August 1998
* On true, the caller will generate a two byte escape sequence,
* calling this routine again with both values.
*/
int pattern_escape_needed( uint8 current_byte )
{
if ( current_byte != pattern_next )
{
pattern_found = 0;
}
else
{
pattern_found++;
}
pattern_next = pattern[current_byte];
return ((pattern_found > pattern_allowed)
&& (current_byte != 0x5e)
&& (current_byte != 0x7d)
&& (current_byte != 0x7e));
}
A.2. LFSR scrambling
A.3. ATM-style scrambling
The ATM (x**43 + 1) LFSR can be applied to the entire frame as it is
inserted into the payload.
The polynomial has an undesirable interaction with the HDLC 16-bit
FCS (x**16 + x**12 + x**5 + 1). Analysis has shown [FC97] that there
exist undetectable burst error patterns, and that protection against
errors in general is reduced.
A.4. Rejected Alternatives
An enhancement to the octet-stuffing technique has been suggested
that checks the scrambler output for the all-zeros pattern, and sig-
nals an escape insertion to the HDLC-like framer (or Frame Relay).
This is only useful for highly integrated devices, and protects only
the first section. Other payload alignments could occur on later
sections in the path.
Several recurrent suggestions are less desirable than octet stuffing.
These suggestions do not provide backward compatibility.
Simpson expires in six months [Page 8]
DRAFT PPP over SONET/SDH August 1998
Moreover, none of these suggestions scale well. They do not accommo-
date parallel processing, as they are bit-oriented.
Furthermore, for the LFSR techniques, the resulting protection is
probabilistic, not a complete solution.
ATM employs a payload LFSR scrambler that affects only the data por-
tion of the ATM cell, and does not include the ATM header. The gen-
erating polynomial for the LFSR is x**43 + 1.
The equivalent technique applied to PPP encapsulated packets in HDLC-
like frames (or Frame Relay) as they are inserted into the payload
would not include the framing octets.
This is rejected, as the scrambled data could mimic the frame delim-
iting flag sequence, resulting in incorrect frame detection.
Other LFSR polynomials have been proposed. These have a similar
error multiplication effect.
Security Considerations
This specification introduces no known security vulnerabilities.
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).
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.
Simpson expires in six months [Page 9]
DRAFT PPP over SONET/SDH August 1998
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-yyyy] Simpson, W., "PPP in Ether-like Framing", DayDreamer,
work in progress.
[RFC-zzzz] Simpson, W., "Applicability Statement for 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 10]
DRAFT PPP over 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 11]
DRAFT PPP over SONET/SDH August 1998
Full Copyright Statement
Copyright (C) William Allen Simpson (1993-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 12]
