PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing
RFC 2823
Network Working Group J. Carlson
Request for Comments: 2823 Sun Microsystems, Inc.
Category: Experimental P. Langner
Lucent Technologies Microelectronics Group
E. Hernandez-Valencia
J. Manchester
Lucent Technologies
May 2000
PPP over Simple Data Link (SDL)
using SONET/SDH with ATM-like framing
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links, and
RFCs 1662 [2] and 2615 [3] provide a means to carry PPP over
Synchronous Optical Network (SONET) [4] and Synchronous Digital
Hierarchy (SDH) [5] circuits. This document extends these standards
to include a new encapsulation for PPP called Simple Data Link (SDL)
[6]. SDL provides a very low overhead alternative to HDLC-like
encapsulation, and can also be used on SONET/SDH links.
Applicability
This specification is intended for those implementations that use PPP
over high speed point-to-point circuits, both with so-called "dark
fiber" and over public telecommunications networks. Because this
enhanced PPP encapsulation has very low overhead and good hardware
scaling characteristics, it is anticipated that significantly higher
throughput can be attained when compared to other possible SONET/SDH
payload mappings, and at a significantly lower cost for line
termination equipment.
Carlson, et al. Experimental [Page 1]
RFC 2823 PPP SDL on SONET/SDH May 2000
SDL is defined over other media types and for other data link
protocols, but this specification covers only the use of PPP over SDL
on SONET/SDH.
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 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 due to the
general requirement of length information in other parts of the
system, notably in queuing and congestion control strategies such as
Weighted Fair Queuing [7] and Random Early Detect [8].
This document is not a replacement for the existing HDLC-like framing
mandated by RFC 2615 [3]. Instead, the authors intend to gain
implementation experience with this technique for operational and
performance evaluation purposes, and would like to hear from others
either considering or using the protocol as described in this
document. Please see Section 14 of this document for contact
information.
Carlson, et al. Experimental [Page 2]
RFC 2823 PPP SDL on SONET/SDH May 2000
Table of Contents
1. Introduction ............................................... 4
2. Compliance ................................................. 4
3. Physical Layer Requirements ................................ 5
3.1. Payload Types ............................................ 5
3.2. Control Signals .......................................... 6
3.3. Synchronization Modes .................................... 7
3.4. Simple-Data-Link LCP Option .............................. 7
3.5. Framing .................................................. 8
3.6. Framing Example .......................................... 11
3.7. Synchronization Procedure ................................ 11
3.8. Scrambler Operation ...................................... 12
3.9. CRC Generation ........................................... 12
3.10. Error Correction ........................................ 13
4. Performance Analysis ....................................... 14
4.1. Mean Time To Frame (MTTF) ................................ 14
4.2. Mean Time To Synchronization (MTTS) ...................... 15
Show full document text