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
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
使用SONET/SDH和类似ATM帧的简单数据链路（SDL）上的PPP
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.
版权所有（C）互联网协会（2000年）。版权所有。
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.
点到点协议（PPP）[1]提供了通过点到点链路传输多协议数据报的标准方法，RFCs 1662[2]和2615[3]提供了通过同步光网络（SONET）[4]和同步数字体系（SDH）[5]电路传输PPP的方法。本文件扩展了这些标准，包括PPP的新封装，称为简单数据链路（SDL）[6]。SDL提供了一种类似HDLC封装的低开销替代方案，也可用于SONET/SDH链路。
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.
本规范适用于在高速点对点电路上使用PPP的实现，包括所谓的“暗光纤”和公共电信网络。由于这种增强的PPP封装具有非常低的开销和良好的硬件扩展特性，因此预计与其他可能的SONET/SDH有效负载映射相比，可以获得显著更高的吞吐量，并且线路终端设备的成本显著更低。
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.
SDL是针对其他媒体类型和其他数据链路协议定义的，但本规范仅涵盖在SONET/SDH上通过SDL使用PPP。
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].
SDL的使用要求在SDL报头中呈现数据包长度信息。因此，在生成报头时，实现SDL的硬件必须能够访问分组长度，并且在路由器的输入链路没有该信息的情况下（即，对于非SDL输入链路），可能需要路由器在传输之前缓冲整个分组。因此，“蠕虫洞”路由至少在SDL中有问题，除非输入链路也是SDL。然而，由于系统其他部分对长度信息的一般要求，尤其是在排队和拥塞控制策略（如加权公平排队[7]和随机早期检测[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.
本文件不是RFC 2615[3]规定的现有HDLC类框架的替代品。相反，为了操作和性能评估的目的，作者打算获得该技术的实施经验，并希望听取其他考虑或使用本文档中描述的协议的人的意见。联系方式请参见本文件第14节。
Table of Contents
目录
1. Introduction ............................................... 4
2. Compliance ................................................. 4
3. Physical Layer Requirements ................................ 5
3.1. Payload Types ............................................ 5
3.2. Control Signals .......................................... 6
3.3. Synchronization Modes .................................... 7
3.4. Simple-Data-Link LCP Option .............................. 7
3.5. Framing .................................................. 8
3.6. Framing Example .......................................... 11
3.7. Synchronization Procedure ................................ 11
3.8. Scrambler Operation ...................................... 12
3.9. CRC Generation ........................................... 12
3.10. Error Correction ........................................ 13
4. Performance Analysis ....................................... 14
4.1. Mean Time To Frame (MTTF) ................................ 14
4.2. Mean Time To Synchronization (MTTS) ...................... 15
4.3. Probability of False Frame (PFF) ......................... 16
4.4. Probability of False Synchronization (PFS) ............... 16
4.5. Probability of Loss of Frame (PLF) ....................... 16
5. The Special Messages ....................................... 16
5.1. Scrambler State .......................................... 17
5.2. A/B Message .............................................. 17
6. The Set-Reset Scrambler Option ............................. 17
6.1. The Killer Packet Problem ................................ 17
6.2. SDL Set-Reset Scrambler .................................. 18
6.3. SDL Scrambler Synchronization ............................ 18
6.4. SDL Scrambler Operation .................................. 19
7. Configuration Details ...................................... 20
7.1. Default LCP Configuration ................................ 20
7.2. Modification of the Standard Frame Format ................ 21
8. Implementation Details ..................................... 21
8.1. CRC Generation ........................................... 21
8.2. Error Correction Tables .................................. 23
9. Security Considerations .................................... 25
10. References ................................................ 25
11. Acknowledgments ........................................... 26
12. Working Group and Chair Address ........................... 26
13. Intellectual Property Notices ............................. 26
14. Authors' Addresses ........................................ 27
15. Full Copyright Statement .................................. 28
1. Introduction ............................................... 4
2. Compliance ................................................. 4
3. Physical Layer Requirements ................................ 5
3.1. Payload Types ............................................ 5
3.2. Control Signals .......................................... 6
3.3. Synchronization Modes .................................... 7
3.4. Simple-Data-Link LCP Option .............................. 7
3.5. Framing .................................................. 8
3.6. Framing Example .......................................... 11
3.7. Synchronization Procedure ................................ 11
3.8. Scrambler Operation ...................................... 12
3.9. CRC Generation ........................................... 12
3.10. Error Correction ........................................ 13
4. Performance Analysis ....................................... 14
4.1. Mean Time To Frame (MTTF) ................................ 14
4.2. Mean Time To Synchronization (MTTS) ...................... 15
4.3. Probability of False Frame (PFF) ......................... 16
4.4. Probability of False Synchronization (PFS) ............... 16
4.5. Probability of Loss of Frame (PLF) ....................... 16
5. The Special Messages ....................................... 16
5.1. Scrambler State .......................................... 17
5.2. A/B Message .............................................. 17
6. The Set-Reset Scrambler Option ............................. 17
6.1. The Killer Packet Problem ................................ 17
6.2. SDL Set-Reset Scrambler .................................. 18
6.3. SDL Scrambler Synchronization ............................ 18
6.4. SDL Scrambler Operation .................................. 19
7. Configuration Details ...................................... 20
7.1. Default LCP Configuration ................................ 20
7.2. Modification of the Standard Frame Format ................ 21
8. Implementation Details ..................................... 21
8.1. CRC Generation ........................................... 21
8.2. Error Correction Tables .................................. 23
9. Security Considerations .................................... 25
10. References ................................................ 25
11. Acknowledgments ........................................... 26
12. Working Group and Chair Address ........................... 26
13. Intellectual Property Notices ............................. 26
14. Authors' Addresses ........................................ 27
15. Full Copyright Statement .................................. 28
The Path Signal Label (SONET/SDH overhead byte named C2; referred to as PSL in this document) is intended to indicate the type of data carried on the path. This data, in turn, is referred to as the SONET Synchronous Payload Envelope (SPE) or SDH Administrative Unit Group (AUG). The experimental PSL value of decimal 207 (CF hex) is currently [3] used to indicate that the SPE contains PPP framed using RFC 1662 Octet Synchronous (O-S) framing and transmission without scrambling, and the value 22 (16 hex) is used to indicated PPP framed using O-S framing and transmission with ATM-style X^43+1 scrambling.
路径信号标签（名为C2的SONET/SDH开销字节；在本文件中称为PSL）旨在指示路径上携带的数据类型。该数据又称为SONET同步有效负载包络（SPE）或SDH管理单元组（AUG）。十进制207（CF hex）的实验PSL值目前[3]用于指示SPE包含使用RFC 1662八位组同步（O-S）帧和传输而不加扰的PPP帧，而值22（16 hex）用于指示使用O-S帧和传输且采用ATM样式X^43+1加扰的PPP帧。
This document describes a method to enable the use of SDL framing for PPP over SONET/SDH, and describes the framing technique and requirements for PPP. While O-S framing on SONET/SDH has a fixed seven octet overhead per frame plus a worst-case overhead of 100% of all data octets transmitted, SDL has a fixed eight octet per frame overhead with zero data overhead. Unlike O-S framing, SDL also provides positive indication of link synchronization.
本文件描述了通过SONET/SDH为PPP启用SDL成帧的方法，并描述了PPP的成帧技术和要求。虽然SONET/SDH上的O-S成帧具有固定的每帧七个八位字节的开销加上100%传输的所有数据八位字节的最坏情况开销，但SDL具有固定的每帧八个八位字节的开销，且数据开销为零。与O-S成帧不同，SDL还提供链路同步的积极指示。
Note: This document describes two new SONET/SDH Path Signal Label (PSL) values; 23 (17 hex) for SDL with the proposed self synchronous scrambler and 25 (19 hex) for SDL with the proposed set-reset scrambler. These values have been allocated by ANSI T1X1.5 and ITU-T SG-15 for use with SDL over SONET and SDH, and will appear in subsequent updates of T1.105 (Table 8) and Recommendation G.707 (Table 7).
注：本文件描述了两个新的SONET/SDH路径信号标签（PSL）值；23（17十六进制）用于SDL和建议的自同步扰码器，25（19十六进制）用于SDL和建议的set reset扰码器。这些值已由ANSI T1X1.5和ITU-T SG-15分配，用于SONET和SDH上的SDL，并将出现在T1.105（表8）和建议G.707（表7）的后续更新中。
In this document, the words that are used to define the significance of each particular requirement are capitalized.
在本文件中，用于定义每个特定要求重要性的词语大写。
These words are:
这些词是：
* "MUST"
* “必须”
This word means that the item is an absolute requirement of the specification.
该词表示该项目是本规范的绝对要求。
* "MUST NOT"
* “不得”
This phrase means that the item is an absolute prohibition of the specification.
该短语表示该项目是本规范的绝对禁止。
* "SHOULD"
* “应该”
This word means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
这个词的意思是，在特定情况下，可能存在忽略该项目的正当理由，但在选择不同的课程之前，应理解其全部含义并仔细权衡情况。
* "SHOULD NOT"
* “不应该”
This phrase means that there may exist valid reasons in particular circumstances to apply this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
这句话的意思是，在特定情况下，可能存在适用该项目的正当理由，但在选择不同的课程之前，应理解其全部含义并仔细权衡情况。
* "MAY"
* “五月”
This word means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.
这个词的意思是这个项目是真正的可选。一个供应商可能会选择包括该项目，因为特定的市场需要它，或者因为它增强了产品，例如；另一个供应商可以省略相同的项目。
An implementation is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for this protocol. An implementation that satisfies all of the MUST, MUST NOT, SHOULD, and SHOULD NOT requirements for this protocol is said to be "unconditionally compliant". One that satisfies all the MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT requirements is said to be "conditionally compliant".
如果实现未能满足此协议的一个或多个必须或不得要求，则该实现不符合要求。满足本协议所有必须、不得、应该和不应该要求的实现称为“无条件兼容”。满足所有“必须”和“不得”要求，但并非所有“应该”或“不应该”要求的人被称为“有条件遵从”。
PPP treats SONET/SDH transport as octet-oriented synchronous links. No provision is made to transmit partial octets. Also, SONET/SDH links are full-duplex by definition.
PPP将SONET/SDH传输视为面向八位字节的同步链路。没有规定传输部分八位字节。此外，SONET/SDH链路定义为全双工。
Only synchronous payloads STS-1 and higher are considered in this document. Lower speed synchronous, such as VT1.5-SPE/VC-11, and plesiochronous payload mappings, such as T1 and T3, are defined for SONET/SDH and for the SDL algorithm itself, but, since HDLC-like framing is defined for PPP on those media, PPP over SDL is not defined.
本文件仅考虑同步有效载荷STS-1和更高版本。对于SONET/SDH和SDL算法本身，定义了低速同步（如VT1.5-SPE/VC-11）和准同步有效负载映射（如T1和T3），但是，由于为这些媒体上的PPP定义了类似HDLC的帧，因此未定义SDL上的PPP。
SDL is separately defined as a PPP transport for use on raw fiber without SONET/SDH framing for use as an alternative to bit-synchronous HDLC. Please see the separate work-in-progress for details.
SDL被单独定义为一种PPP传输，用于在未使用SONET/SDH帧的原始光纤上使用，以替代位同步HDLC。有关详细信息，请参见正在进行的单独工作。
The PPP over SONET/SDH mapping allows the use of the PSL as a control signal. Not all equipment, however, is capable of setting or detecting this value, and any use must take this into account. Equipment employing only SDL MUST be capable of transmitting PSL with value 23, and MAY also be capable of transmitting PSL with value 25, but need not be capable of detecting the peer's value or capable of changing its own value.
通过SONET/SDH映射的PPP允许将PSL用作控制信号。然而，并非所有设备都能够设置或检测该值，任何使用都必须考虑到这一点。仅使用SDL的设备必须能够传输值为23的PSL，也可以传输值为25的PSL，但不需要能够检测对等方的值或能够更改其自身的值。
There are two methods to enable SDL, an LCP-negotiated method and a prior-arrangement method. The former allows for easier configuration and compatibility with existing equipment, while the latter allows general use with separate SONET/SDH transmission equipment with PSL limitations. Both types of implementations will freely interoperate given the procedures below.
有两种方法可以启用SDL，LCP协商方法和优先安排方法。前者允许更容易的配置和与现有设备的兼容性，而后者允许与具有PSL限制的单独SONET/SDH传输设备一起通用。根据下面的过程，这两种类型的实现都可以自由地进行互操作。
LCP-negotiated systems MUST be capable of changing their transmitted PSL value and detecting the peer's value. Equipment without these features MUST NOT support LCP negotiation of SDL.
LCP协商系统必须能够更改其传输的PSL值并检测对等方的值。没有这些功能的设备不得支持SDL的LCP协商。
When SDL is negotiated by LCP, LCP negotiation MUST be started with the PSL value initially set to 22 or 207 and the corresponding non-SDL O-S PPP encapsulation MUST be used. The SDL LCP option is then placed in the LCP Configure-Request messages transmitted. On reception of LCP Configure-Request with an SDL LCP option or when the peer's transmitted PSL value is received as 23 (or 25), the implementation MUST shut down LCP by sending a Down event to its state machine, then switch its transmitted PSL value to 23 (or 25), switch encapsulation mode to SDL, wait for SDL synchronization, and then restart LCP by sending an Up event into LCP. Otherwise, if the peer does not transmit PSL value 23 (or 25) and it does not include the SDL LCP option in its LCP Configure-Request messages, then operation using non-SDL O-S PPP encapsulation continues. If the received PSL value subsequently received reverts from 23 (or 25) to any other value, then this is treated as a Down event into the LCP state machine, and an Up event MUST be generated if the new value is recognized as a valid PPP framing mode.
当LCP协商SDL时，LCP协商必须首先将PSL值设置为22或207，并且必须使用相应的非SDL O-S PPP封装。然后，将SDL LCP选项置于发送的LCP配置请求消息中。在接收到带有SDL LCP选项的LCP配置请求时，或当对等方发送的PSL值被接收为23（或25）时，实现必须通过向其状态机发送关闭事件来关闭LCP，然后将其发送的PSL值切换为23（或25），将封装模式切换为SDL，等待SDL同步，然后通过向LCP发送Up事件来重新启动LCP。否则，如果对等方不传输PSL值23（或25），并且在其LCP配置请求消息中不包括SDL LCP选项，则使用非SDL O-S PPP封装的操作将继续。如果随后接收到的PSL值从23（或25）恢复为任何其他值，则这将被视为进入LCP状态机的向下事件，如果新值被识别为有效的PPP帧模式，则必须生成向上事件。
When SDL is enabled by prior arrangement, the PSL SHOULD be transmitted as 23 (or 25). Any other value may also be used by prior external arrangement with the peer, although the values 22 and 207 are discouraged. (Such use is enforced by an administrator, and is outside the scope of this specification.) When SDL is enabled by prior arrangement, the SDL LCP option SHOULD NOT be negotiated by the peers.
当通过事先安排启用SDL时，PSL应作为23（或25）传输。任何其他值也可通过事先与对等方的外部安排使用，尽管不鼓励使用值22和207。（此类使用由管理员强制执行，不在本规范的范围内。）当通过事先安排启用SDL时，对等方不应协商SDL LCP选项。
An implementation-specific configuration option SHOULD exist to enable the use of prior-arrangement versus LCP-negotiated modes. This option SHOULD be presented to an administrator, and SHOULD default to LCP-negotiated if the hardware permits. Otherwise, if the hardware implementation precludes non-SDL modes of operation, then it MUST default to prior-arrangement mode.
应存在特定于实施的配置选项，以允许使用优先安排与LCP协商模式。此选项应提交给管理员，如果硬件允许，应默认为协商的LCP。否则，如果硬件实现排除了非SDL操作模式，则必须默认为优先安排模式。
The LCP-negotiated method of operation is compatible with the current version of G.783 [12]. This method may not be compatible, however, with some non-intrusive SDH path monitoring equipment based on obsolete versions of G.783. The change in PSL value indicated by the LCP negotiation method will cause this equipment to declare an alarm condition on the path. For this reason, the prior-arrangement method MUST be used on any SDH network that is using such monitoring equipment.
LCP协商的操作方法与当前版本的G.783[12]兼容。但是，该方法可能与一些基于过时版本G.783的非侵入式SDH路径监测设备不兼容。LCP协商方法指示的PSL值变化将导致该设备在路径上宣布报警条件。因此，必须在使用此类监控设备的任何SDH网络上使用事先安排方法。
Unlike O-S encapsulation, 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 synchronization loss is detected. An SDL PPP implementation SHOULD also provide a configurable timer that is started when SDL is initialized and restarted 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.
与O-S封装不同，SDL提供了一个积极的迹象，表明它已经实现了与对等方的同步。如果检测到同步丢失，SDL PPP实现必须提供一种暂停PPP数据传输（用户数据和协商流量）的方法。SDL PPP实现还应提供一个可配置的计时器，该计时器在SDL初始化时启动，在同步丢失时重新启动，在实现链路同步时终止。如果此计时器过期，则应采取依赖于实现的操作来报告硬件故障。
A new LCP Configuration Option is used to request Simple Data Link (SDL) [6] operation for the PPP link.
新的LCP配置选项用于请求PPP链路的简单数据链路（SDL）[6]操作。
A summary of the Simple-Data-Link Configuration Option format for the Link Control Protocol (LCP) is shown below. The fields are transmitted from left to right.
链路控制协议（LCP）的简单数据链路配置选项格式摘要如下所示。字段从左向右传输。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
29
29
Length
长
2
2.
This option is used only as a hint to the peer that SDL over SONET/SDH operation is preferred by the sender. If the current encapsulation mode is not SDL, then the only appropriate response to reception of this option by an SDL speaker is to then switch the encapsulation mode to SDL (as detailed in the section above) and restart LCP. Non SDL-speakers SHOULD instead send LCP Configure-Reject for the option.
此选项仅用于提示对等方发送方首选SDL over SONET/SDH操作。如果当前封装模式不是SDL，则SDL扬声器接收此选项的唯一适当响应是将封装模式切换到SDL（如上一节所述），然后重新启动LCP。非SDL扬声器应改为发送该选项的LCP配置拒绝。
If either LCP Configure-Nak or LCP Configure-Reject is received for this option, then the next transmitted LCP Configure-Request MUST NOT include this option. If LCP Configure-Ack with this option is received, it MUST NOT be treated as a request to switch into SDL mode. If the received LCP Configure-Request message does not contain an SDL LCP option, an implementation MUST NOT send an unsolicited Configure-Nak for the option.
如果收到此选项的LCP Configure Nak或LCP Configure Reject，则下一个传输的LCP Configure请求不得包含此选项。如果收到带有此选项的LCP Configure Ack，则不得将其视为切换到SDL模式的请求。如果收到的LCP配置请求消息不包含SDL LCP选项，则实现不得为该选项发送未经请求的配置Nak。
(An implementation of SDL that is already in SDL framing mode and receives this option in an LCP Configure-Request message MAY, both for clarity and for convergence reasons, elect to send LCP Configure-Ack. It MUST NOT restart LCP nor change framing modes in this case.)
（已经处于SDL成帧模式并在LCP配置请求消息中接收此选项的SDL实现，出于清晰和收敛的原因，可以选择发送LCP配置确认。在这种情况下，不得重新启动LCP或更改成帧模式。）
The PPP frames are located by row within the SPE payload. Because frames are variable in length, the frames are allowed to cross SPE boundaries. Bytes marked as "overhead" or "fixed stuff" in SONET/SDH documentation for concatenated streams are not used as payload bytes.
PPP帧在SPE有效负载内按行定位。由于帧的长度可变，因此允许帧跨越SPE边界。SONET/SDH文档中标记为连接流的“开销”或“固定内容”的字节不用作有效负载字节。
With reference to the Lucent SDL specification [6] when SDL framing for PPP is employed, the SDL "Datagram Offset" feature is set to the value 4. This corresponds to the fixed overhead value 4 in the
参考朗讯SDL规范[6]，当采用用于PPP的SDL帧时，SDL“数据报偏移”特性被设置为值4。这与中的固定开销值4相对应
description below. The "A" and "B" messages are never used. These optional features of SDL are not described in this document, but are rather described in Lucent's SDL specification.
说明如下。从不使用“A”和“B”消息。SDL的这些可选特性在本文档中没有描述，而是在朗讯的SDL规范中描述。
Fixing the Datagram Offset value described in the Lucent documentation to 4 allows a PPP MRU/MTU up to 65536 using SDL.
将朗讯文档中描述的数据报偏移量值固定为4允许使用SDL的PPP MRU/MTU高达65536。
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 3.7. For use with PPP, this fixed-length header precedes each PPP/HDLC packet as follows:
SDL成帧通常通过在数据包上使用四个八位组的报头来完成。此固定长度标头允许使用简单的成帧器来检测同步，如第3.7节所述。对于PPP，该固定长度报头位于每个PPP/HDLC数据包之前，如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Length | Header CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP packet (beginning with address and control fields) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDL CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Length | Header CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP packet (beginning with address and control fields) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDL CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The four octet length header 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.
四个八位字节长度的报头由具有十六进制值B6AB31E0的异或（也称为“模2加法”）进行DC平衡。这是长度为32的最大过渡、最小旁瓣、巴克序列。在报头本身上不进行其他加扰。
Packet Length is an unsigned 16 bit number in network byte order. Unlike the PPP FCS, the Header CRC is a CRC-16 generated with initial value zero and transmitted in network byte order. The PPP packet is scrambled, begins with the 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.
数据包长度是网络字节顺序的无符号16位数字。与PPP FCS不同，报头CRC是初始值为零的CRC-16，并以网络字节顺序传输。PPP分组被加扰，以地址和控制字段开始，并且可以是任何整数八位字节长度（即，除非使用自描述填充选项，否则它不被填充）。分组CRC也被加扰，并且具有依赖于模式的长度（如下所述），并且仅位于八位组边界上；不得假设该字段对齐。
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 8 plus the Packet Length field. The value 8 represents a fixed overhead of 4 octets plus the fixed length of the Packet CRC field. When the Packet Length is 0, the distance to the next header is 4 octets. This is the idle fill header. When the Packet Length is 1 to 3, the
当数据包长度值为4或更大时，SDL中一个消息头和下一个消息头之间的距离（以八位字节为单位）为8加上数据包长度字段之和。值8表示4个八位字节加上分组CRC字段的固定长度的固定开销。当数据包长度为0时，到下一个报头的距离为4个八位字节。这是怠速加注收割台。当数据包长度为1到3时
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.
到下一个报头的距离是12个八位字节。这些标头用于特殊SDL消息，仅用于可选的加扰和管理模式。有关消息的详细信息，请参见第5节。
General SDL, like PPP, allows the use of no CRC, ITU-T CRC-16, or 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 [9], because frame-to-frame distance is, as described above, calculated including the CRC length. Thus, this PPP over SDL specification fixes the CRC type to CRC-32 (four octets), and all SDL implementations MUST reject any LCP FCS Alternatives Option [9] requested by the peer when in SDL mode.
与PPP一样，通用SDL允许对分组数据不使用CRC、ITU-T CRC-16或ITU-T CRC-32。然而，由于分组长度字段不包括CRC长度，如果根据RFC 1570[9]改变CRC类型，则无法保持同步，因为如上所述，帧到帧距离是包括CRC长度计算的。因此，此PPP over SDL规范将CRC类型固定为CRC-32（四个八位字节），所有SDL实施必须拒绝对等方在SDL模式下请求的任何LCP FCS备选方案[9]。
PPP over SDL implementations MAY allow a configuration option to set different CRC types for use by prior arrangement. Any such configurable option MUST default to CRC-32, and MUST NOT include LCP negotiation of FCS Alternatives.
SDL上的PPP实现可允许配置选项设置不同的CRC类型以供先前安排使用。任何此类可配置选项必须默认为CRC-32，且不得包括FCS备选方案的LCP协商。
Setting the SDL Datagram Offset value to 4 accounts for the 4 octet SDL header overhead. With the SDL Datagram Offset set to 4, the value 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 CRC field (the RFC 1662 PPP FCS field is not used with SDL). Note again that the Datagram Offset is just an arithmetic value; it does not occupy bits in the message itself.
将SDL数据报偏移量值设置为4说明了4个八位组的SDL报头开销。当SDL数据报偏移量设置为4时，数据包长度字段中的值正好是PPP帧本身的长度（以八位字节为单位），包括地址和控制字段，但不包括CRC字段（RFC 1662 PPP FCS字段不与SDL一起使用）。再次注意，数据报偏移量只是一个算术值；它不占用消息本身的位。
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.
由于保留小于4的数据包长度，因此对于任何合法PPP数据包，数据包长度必须为4或更大。如果没有地址/控制或协议字段压缩，八位字节较少的PPP数据包是不可能的，对于SDL，必须将其填充到长度4。
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 an ATM channel. The scrambler is not clocked when SDL header bits are transmitted. Thus, the data scrambling MAY be implemented in an entirely independent manner from the SDL framing, and the data stream may be prescrambled before insertion of SDL framing marks.
默认情况下，消息的数据部分（包括32位CRC）使用独立的自同步x^43+1扰码器。这与在ATM信道上使用ATM x^43+1加扰器的方式完全相同。传输SDL头比特时，扰码器不计时。因此，可以以完全独立于SDL帧的方式实现数据加扰，并且可以在插入SDL帧标记之前对数据流进行预扰。
Optionally, by prior arrangement, SDL links MAY use a set-reset scrambler as described in section 6. If this option is provided, it MUST be configurable by the administrator, and the option MUST default to the self-synchronous scrambler.
可选地，通过先前的安排，SDL链路可以使用第6节中描述的设置-重置扰频器。如果提供了此选项，则管理员必须对其进行配置，并且该选项必须默认为自同步加扰器。
To help clarify this structure, the following example may be helpful. First we have an LCP Configure-Request message that we wish to transmit over SDL:
为了帮助澄清此结构，以下示例可能会有所帮助。首先，我们希望通过SDL传输LCP配置请求消息：
FF 03 C0 21 01 01 00 04
FF 03 C0 21 01 00 04
Next, we create an SDL header for the length of this packet (8 octets), a header CRC, and an SDL CRC.
接下来，我们为该数据包的长度（8个八位字节）创建一个SDL报头、一个报头CRC和一个SDL CRC。
00 08 81 08 FF 03 C0 21 01 01 00 04 D1 F5 21 5E
00 08 81 08 FF 03 C0 21 01 00 04 D1 F5 21 5E
Finally, we DC-balance the header with the barker-like sequence:
最后，我们使用类似巴克的序列对报头进行DC平衡：
B6 A3 B0 E8 FF 03 C0 21 01 01 00 04 D1 F5 21 5E
B6 A3 B0 E8 FF 03 C0 21 01 00 04 D1 F5 21 5E
Note that the final length of the message is 8 (original message length) plus 4 (fixed datagram offset value) plus 4 (fixed CRC length), or 16 octets.
请注意，消息的最终长度是8（原始消息长度）加4（固定数据报偏移值）加4（固定CRC长度），或16个八位字节。
The link synchronization procedure is similar to the I.432 section 4.5.1.1 ATM HEC delineation procedure [10], except that the SDL messages 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 3.10 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.
链路同步程序类似于I.432第4.5.1.1节ATM HEC划定程序[10]，除了SDL消息是可变长度的。机器在HUNT状态下启动，直到在数据流中找到具有有效CRC-16的四个八位组序列。（注意，在机器处于同步状态之前，不使用第3.10节中描述的CRC-16单比特错误校正技术。报头必须没有比特错误才能离开HUNT状态。）这样的有效序列是候选SDL报头。找到有效序列后，机器进入预同步状态。任何一个处于预同步状态的无效SDL标头都会将链接返回到搜索状态。
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.
如果在进入预同步状态后看到第二个有效SDL报头，则链路进入同步状态并启用PPP传输。如果检测到无效的SDL报头，则链路将返回到搜索状态，而不启用PPP传输。
Once the link enters SYNCH state, the SDL header single bit error correction logic is enabled (see section 3.10). Any unrecoverable header CRC error returns the link to HUNT state, disables PPP transmission, and disables the error correction logic.
一旦链路进入同步状态，SDL报头单位纠错逻辑将启用（见第3.10节）。任何不可恢复的头CRC错误都会将链接返回到搜索状态，禁用PPP传输，并禁用纠错逻辑。
The transmit and receive scramblers are shift registers with 43 stages that MAY be initialized to all-ones when the link is initialized. Synchronization is maintained by the data itself.
发送和接收扰频器是具有43级的移位寄存器，当链路初始化时，可以将其初始化为所有的一级。同步由数据本身维护。
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)
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.
每个异或都是一个异或门；也称为模2加法器。每个Dn块是一个D型触发器，在适当的数据时钟上计时。
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 practice, transmitted and received MSB-first.
扰码器在传输或接收每一位有效载荷后，以及在下一位作为输入应用之前，计时一次。根据SONET/SDH实践，八位字节中的位首先传输和接收MSB。
The CRC-16 and CRC-32 generator polynomials used by SDL are the ITU-T polynomials [11]. These are:
SDL使用的CRC-16和CRC-32生成器多项式是ITU-T多项式[11]。这些是：
x^16+x^12+x^5+1
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
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.
用于三条特殊消息（扰码器状态、消息A和消息B；参见第5节）中每一条的SDL报头CRC和CRC-16都是使用0000十六进制的初始余数值生成的。
The optional CRC-16 on the payload data (this mode is not used with PPP over SDL except by prior arrangement) uses the initial remainder value of FFFF hex for calculation and the bits are complemented 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
有效载荷数据上的可选CRC-16（该模式不与PPP over SDL一起使用，除非事先安排）使用FFFF hex的初始余数值进行计算，并且在传输之前对位进行补充。然而，与常规PPP FCS不同，最终CRC余数以网络字节顺序传输。如果CRC-16算法在所有八位字节上运行，包括附加的CRC本身，则完整数据包上的剩余值将被删除
always be E2F0 hex. Alternatively, an implementation may stop CRC calculation before processing the appended CRC itself, and do a direct comparison.
始终为E2F0十六进制。或者，实现可以在处理附加的CRC本身之前停止CRC计算，并进行直接比较。
The CRC-32 on the payload data (used for 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.
有效载荷数据（用于SDL上的PPP）上的CRC-32使用FFFFFFFF hex的初始余数值进行计算，并且在传输之前对位进行补充。然而，CRC以网络字节顺序传输，最高有效位优先，与可选PPP 32位FCS不同，后者以相反顺序传输。当附加的CRC值包括在计算中时，完整数据包上的剩余值为38FB2284。
C code to generate these CRCs is found in section 8.1.
生成这些CRC的C代码见第8.1节。
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.
纠错技术基于伽罗瓦数字段的使用，与ATM HEC纠错一样。在伽罗瓦数域中，f（a+b）=f（a）+f（b）。由于用于SDL的CRC-16形成了这样一个字段，我们可以声明CRC（消息+错误）=CRC（消息）+CRC（错误）。由于正确格式的消息的CRC-16余数始终为零，这意味着，对于对应于单个位错误的N个不同的“错误”字符串，存在N个不同的CRC（错误）值，其中N是消息中的位数。
A table look-up is thus applied to the CRC-16 residue after calculation over the four octet SDL header to correct bit errors in the 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 PPP over SDL.)
因此，在对四个八位组SDL报头进行计算之后，对CRC-16残余值应用表查找，以校正报头中的位错误并检测多个位错误。对于可选的set reset扰码器，在对8个八位组扰码器状态消息进行计算后，类似地对CRC-16残差应用表查找，以纠正位错误并检测多个位错误。（第二次修正也用于特殊SDL A和B消息，它们不用于SDL上的PPP。）
Note: No error correction is performed for the payload.
注意：未对有效负载执行错误更正。
Note: This error correction technique is used only when the link has entered SYNCH state. While in HUNT or PRESYNCH state, error correction should not be performed, and only messages with syndrome 0000 are accepted. If the calculated syndrome does not appear in this table, then an unrecoverable error has occurred. Any such error in the SDL header will return the link to HUNT state.
注意：只有当链接进入同步状态时，才使用此错误更正技术。在HUNT或PRESYNCH状态下，不应执行错误更正，只接受带有0000的消息。如果计算的综合征未出现在此表中，则发生了不可恢复的错误。SDL标头中的任何此类错误都将使链接返回到搜索状态。
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.
由于CRC计算从零开始，因此可以合并这两个表。四个八位字节表只是八个八位字节表的最后32个条目。
Eight octet (64 bit) single bit error syndrome table (in hexadecimal):
八位八位组（64位）单位错误综合征表（十六进制）：
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
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 DCC 6E60 3730 1B98 0DCC 06E6 0373 899 CCC4 6662 3331 12481 1028
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.
因此，如果在八个八位字节的消息上看到综合征6EF6，则第二个八位字节的第三位（十六进制20）出错。类似地，如果在八个八位字节的消息中看到48C4，则第八个八位字节中的第二位（十六进制40）出错。对于四个八位字节的消息，相同的两个综合征将指示6EF6的多位错误，以及48C4的第四个八位字节的第二位的单位错误。
Note that eight octet messages are used only for the optional set-reset scrambling mode, described in section 6.
请注意，八个八位字节信息仅用于第6节所述的可选设置重置加扰模式。
Corresponding C code to generate this table is found in section 8.2.
生成此表的相应C代码见第8.2节。
There are five general statistics that are important for framing algorithms. These are:
有五种通用统计信息对帧算法很重要。这些是：
MTTF Mean time to frame MTTS Mean time to synchronization PFF Probability of false frame PFS Probability of false synchronization PLF Probability of loss of frame
MTTF平均帧间时间MTTS平均同步时间PFF假帧概率PFS假同步概率PLF帧丢失概率
The following sections summarize each of these statistics for SDL. Details and mathematic development can be found in the Lucent SDL documentation [6].
以下各节总结了SDL的每个统计信息。详细信息和数学发展可以在朗讯SDL文档[6]中找到。
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.
该指标测量在输入数据中建立正确帧所需的时间量。这可以用任何方便的单位来测量，例如秒或字节。对于SDL，相关的度量是以数据包为单位的，因为数据包的片段并不有用。
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 in the data stream.
为了计算MTTF，我们必须首先确定帧检测状态机“不可用”的频率，因为它无法检测数据流中的下一个传入SDL帧。
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 candidate framing point in order to reduce the probability of falsely detecting user data as a valid frame header.
由于在随机数据中使用CRC-16进行虚假报头检测的概率为2^-16，并且与允许的数据包大小相比，该速率较大，因此值得运行多个并行帧检测状态机。每台机器从不同的候选帧点开始，以降低将用户数据错误检测为有效帧头的概率。
The results for this calculation, given maximal 64KB packets and slightly larger than Internet average 354 byte packets, are:
考虑到最大64KB数据包和略大于互联网平均354字节数据包，此计算的结果如下：
Number of Unavailability Unavailability Framers 64KB packets 354 byte pkts 1 3.679E-1 5.373E-3 2 3.083E-2 1.710E-6 3 2.965E-3 9.712E-10 4 2.532E-4 4.653E-13
不可用数不可用帧器64KB数据包354字节PKT 1 3.679E-1 5.373E-3 2 3.083E-2 1.710E-6 3 2.965E-3 9.712E-10 4 2.532E-4 4 4.653E-13
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 summarized as:
使用这些值，MTTF可以计算为误比特率（BER）的函数。这些图显示了膝盖以下所有BER的典型平坦区域，超过该区域，BER开始急剧上升。在所有情况下，已发现该拐点出现在大约1E-4的误码率处，这比现有SONET/SDH链路上观察到的误码率高几个数量级。统一费率值汇总如下：
Number of Flat region Flat region Framers 64KB packets 354 bytes 1 3.58 1.52 2 1.595 1.5 3 1.52 1.5 4 1.5 1.5
平面区域成帧器的数量64KB数据包354字节1 3.58 1.52 2 1.595 1.5 3 1.52 1.5 4 1.5 1.1 1.5
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 approximately 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.
因此，对于使用BER为1E-4或更高的链路的两个并行成帧器的实现中的公共分组大小，MTTF约为1.5个分组。这也是最佳时间，因为它表示在一个数据包中间的平均点开始成帧，并在看到一个正确成帧的数据包后实现良好的成帧。
The MTTS for SDL with a self-synchronous scrambler is the same as the MTTF, or 1.5 packets.
带自同步扰码器的SDL的MTT与MTTF相同，即1.5个数据包。
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.
使用可选的set reset扰码器的SDL的MTT是扰码状态传输间隔（分组）加上MTTF的一半。对于以默认速率每八个数据包插入一个数据包，MTT为5.5个数据包。
(The probability of receiving a bad scrambling state transmission should also be included in this calculation. The probability of random corruption of this short message is shown in the SDL document [6] to be small enough that it can be neglected for this calculation.)
（此计算中还应包括接收到错误加扰状态传输的概率。SDL文档[6]中显示此短消息的随机损坏概率非常小，可以忽略此计算。）
The PFF is 2.328E-10 (2^-32), since false framing requires two consecutive headers with falsely correct CRC-16.
PFF为2.328E-10（2^-32），因为假帧需要两个连续的头，并且具有错误正确的CRC-16。
The PFS for SDL with the self-synchronous scrambler is the same as the PFF, or 2.328E-10 (2^-32).
带自同步扰码器的SDL的PFS与PFF相同，或为2.328E-10（2^-32）。
The PFS for SDL with the set-reset scrambler is 5.421E-20 (2^-64), and is calculated as the PFF above multiplied by the probability of a falsely detected scrambler state message, which itself contains two independent CRC-16 calculations.
带有set reset扰码器的SDL的PFS为5.421E-20（2^-64），计算为上述PFF乘以错误检测到的扰码器状态消息的概率，该消息本身包含两个独立的CRC-16计算。
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.
PLF是BER的函数，对于SDL，PLF大约是BER乘以500的平方，这是在32位SDL报头内发生两个或更多位错误的概率。因此，在1E-5的误码率下，PLF是5E-8。
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 follows. The next octet on the link is the first octet of the next SDL header.
当SDL数据包长度字段的值介于0000和0003之间时，报头后面的消息具有特殊的预定义长度。0值是空闲链路上的时间填充，没有其他数据跟随。链路上的下一个八位字节是下一个SDL头的第一个八位字节。
The values 1 through 3 are defined in the following subsections. These special messages each consist of a six octet data portion followed by another CRC-16 over that data portion, as with the SDL header, and this CRC is used for single bit error correction.
值1至3在以下小节中定义。这些特殊消息每个都由一个六个八位字节的数据部分组成，然后在该数据部分上加上另一个CRC-16，与SDL报头一样，该CRC用于单比特错误校正。
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.
保留数据包长度的特殊值1，以便为可选的set reset扰码器将扰码器状态从发射机传输到接收机。在这种情况下，SDL报头后面是六个八位字节（48位）的加扰器状态。扰码器状态和CRC都不会被扰码。
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.
数据包长度的特殊值2和3为“A”和“B”消息保留，这两个消息也是长度为6个八位字节，后面是CRC-16的两个八位字节。这八个八位组中的每一个都被置乱。未定义这些消息与PPP SDL的用途。这些消息保留供链路维护协议使用，其方式类似于ATM的OAM信元。
PPP over SDL uses a self-synchronous scrambler. SDL implementations MAY also employ a set-reset scrambler to avoid some of the possible inherent problems with self-synchronous scramblers.
SDL上的PPP使用自同步加扰器。SDL实现还可以使用设置-重置加扰器来避免自同步加扰器的一些可能的固有问题。
Scrambling in general solves two problems. First, SONET and SDH interfaces 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.
加扰通常可以解决两个问题。首先，SONET和SDH接口需要最小的位转换密度，以保持硬件时钟恢复。由于数据流经常包含全零或全一的长时间运行，因此使用伪随机数序列对位进行置乱会破坏这些模式。其次，所有链路层同步机制都依赖于检测接收数据中的长程模式来检测帧。
Self-synchronous scramblers are an easy way to partially avoid these problems. One problem that is inherent with self-synchronous, however, 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. For public networks, where the data presented to the network is usually multiplexed (interleaved) with multiple unrelated streams, the clocking problem does not pose a significant threat to the public network. It does, however, pose a threat to the PPP-speaking device, and it poses a threat to long lines that are unchannelized.
自同步扰频器是部分避免这些问题的简单方法。然而，自同步固有的一个问题是，来自恶意站点的长用户数据包可以利用这些扰码器的已知属性将长串零或其他破坏同步的模式注入链路。对于公共网络，其中呈现给网络的数据通常与多个不相关流复用（交织），时钟问题不会对公共网络构成重大威胁。然而，它确实对PPP语音设备构成威胁，并且对未经退火的长线构成威胁。
Such carefully constructed packets are called "killer packets".
这种精心构造的包被称为“杀手包”。
An alternative to the self-synchronous scrambler is the externally synchronized or "set-reset" scrambler. This is a free-running scrambler 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.
为SDL定义的选项集重置加扰器是一个x^48+x^28+x^27+x+1独立加扰器，当链路进入预同步状态时，该加扰器初始化为所有加扰器，如果该值变为所有零位，则重新初始化。与自同步加扰器一样，从SDL报头到最终分组CRC，PPP分组数据中的所有八位字节都被加扰。
This mode MAY be detected automatically. If a scrambler state message is received (as described in the following section), an SDL implementation that includes the set-reset scrambler option may switch from self-synchronous into set-reset mode automatically. An SDL implementation that does not include the set-reset scrambler MUST NOT send scrambler state messages.
此模式可自动检测。如果接收到扰码器状态消息（如以下部分所述），则包括set reset扰码器选项的SDL实现可自动从自同步切换到set reset模式。不包括set reset扰码器的SDL实现不得发送扰码器状态消息。
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 followed 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.
如前一节所述，保留包长度的特殊值1，以将扰码器状态从发送器传输到接收器。在这种情况下，SDL报头后面是六个八位字节（48位）的加扰器状态加上两个八位字节的CRC-16。这八个八位组中没有一个被置乱。
SDL synchronization consists of two components, link and scrambler synchronization. Both must be completed before PPP data flows on the link.
SDL同步由两部分组成，链路同步和加扰器同步。两者都必须在PPP数据在链路上流动之前完成。
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.
如果在预同步状态下看到有效的SDL报头，则链路进入同步状态，并启动扰码器同步序列。如果检测到无效的SDL报头，则链路将返回到搜索状态，PPP传输将暂停。
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). When a scrambler synchronization message is received from the peer, PPP transmission is enabled.
当启动扰码器同步时，发送扰码器状态消息（数据包长度设置为1，并且在SDL报头之后按网络字节顺序排列扰码器状态的六个八位字节）。当从对等方接收到扰码器同步消息时，将启用PPP传输。
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 synchronization and should trigger link resynchronization.
扰码器状态消息被周期性地传输，以保持对等点的同步。建议每发送八个数据包一次，并且应该是可配置的。检测到的数据包CRC错误过多表示同步丢失时间过长，应触发链路重新同步。
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.
在接收到扰码器状态消息时，SDL实现必须将接收到的48位状态与接收器的扰码器状态进行比较。如果这些位中的任何一位不同，则声明同步滑动错误。在发生此类错误后，必须将接收到的下一个有效加扰器状态消息加载到接收器的加扰器中，然后清除错误条件。
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.
发送和接收扰频器是移位寄存器，具有48个级，在链路初始化时初始化为所有级。如果移位寄存器中的值曾经变为全零，则每个位都会重新填充所有一位。与SONET/SDH X^7+X^6+1加扰器一样，该加扰器不会在每帧开始时重置，也不会像ATM自同步加扰器那样被传输的数据修改。相反，它使用特殊的SDL消息保持同步。
+----XOR<--------------XOR<---XOR<----------------+
| ^ ^ ^ |
| | | | |
+->D0-+->D1-> ... ->D26-+->D27-+->D28-> ... ->D47-+
|
v
OUT
+----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.
每个异或都是一个异或门；也称为模2加法器。每个Dn块是一个D型触发器，在适当的数据时钟上计时。
The scrambler is clocked once after transmission of each bit of SDL data, whether or not the transmitted bit is scrambled. When scrambling 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.
在传输SDL数据的每一位之后，无论传输的位是否被加扰，加扰器都被计时一次。当对给定八位字节启用加扰时，输出位与原始数据位进行异或运算，以产生传输位。八位字节中的位首先传输MSB。
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.
为了生成加扰器状态消息，D47到D0的内容在发送第一个加扰器状态位的点处进行快照。D47作为输出的第一位传输。传输的第一个八位组包含D47到D40，第二个八位组D39到D32，第六个八位组D7到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.
扰码器状态消息的接收器必须首先在此消息上运行CRC-16检查和纠正算法。如果CRC-16消息检查检测到多个位错误，则该消息将被丢弃，且不会进一步处理。
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.)
否则，它应将整个接收加扰器状态D47:D0的内容与更正的消息进行比较。（通过在SDL报头纠错块和解扰块之间使用多个时钟级对接收器进行流水线处理，当消息到达解扰器时，接收解扰器将位于正确的时钟边界上。这意味着在D47时钟开始时，解码的解扰器状态可以视为立即可用循环进入接收加扰器。）
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 message that passes the CRC-16 message check without multiple bit errors is clocked directly into the receiver's state register after the comparison is done, and the soft error flag is then cleared. Otherwise, while uncorrectable scrambler state messages are received, the soft error flag state is maintained.
如果任何接收到的扰码器状态位与相应的移位寄存器位不同，则设置软错误标志。如果发生这种情况时已设置该标志，则会声明同步滑动错误。应通过实施定义的网络管理程序统计并报告此错误。当接收机设置了此软错误标志时，在比较完成后，通过CRC-16消息检查且无多个位错误的任何加扰器状态消息将直接计时到接收机的状态寄存器中，然后清除软错误标志。否则，当接收到不可纠正的加扰器状态消息时，保持软错误标志状态。
(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.)
（该机制的目的是降低错误纠正的具有多个比特错误的扰码器状态消息损坏正在运行的扰码器状态的可能性。）
The LCP synchronous configuration defaults apply to SONET/SDH links.
LCP同步配置默认值适用于SONET/SDH链路。
The following Configuration Options are recommended:
建议使用以下配置选项：
Magic Number No Address and Control Field Compression No Protocol Field Compression No FCS alternatives (32-bit FCS default)
幻数无地址和控制字段压缩无协议字段压缩无FCS备选方案（32位FCS默认）
This configuration means that PPP over SDL 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 (the Lucent implementation does not do this, but other hardware implementations may), this header is also four octets, and alignment is preserved.
这种配置意味着SDL上的PPP通常向网络层提供一个32位对齐的数据报。在地址、控制和协议字段完好无损的情况下，每个数据包上的PPP开销为四个八位字节。如果SDL成帧器向PPP输入处理提供SDL数据包报头，以便传输数据包长度（朗讯实现不这样做，但其他硬件实现可能这样做），则该报头也是四个八位字节，并且保持对齐。
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 PPP over SDL in order to preserve the message alignment and to allow for the future possibility interworking with other services (e.g., Frame Relay).
由于SDL确实取代HDLC作为PPP的传输，因此至少有可能消除HDLC衍生的开销。为了保持消息对齐并允许将来与其他服务（例如，帧中继）互通，对于SDL上的PPP不这样做。
By prior external arrangement or via LCP negotiation, any two SDL implementations MAY agree to omit the address and control fields or implement protocol field compression on a link. Such use is not described by this document and MUST NOT be the default on any SDL implementation.
通过事先的外部安排或通过LCP协商，任何两个SDL实现可能同意省略地址和控制字段，或在链路上实现协议字段压缩。本文档未对此类使用进行说明，且不得作为任何SDL实现的默认使用。
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.
以下未优化代码为SDL消息生成正确的CRC-16和CRC-32值。注意，对于SDL CRC，多项式位按大端顺序编号；位0是MSB。
typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned long u32;
typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned long u32;
#define POLY16 0x1021 #define POLY32 0x04C11DB7
#定义POLY16 0x1021#定义POLY32 0x04C11DB7
u16
crc16(u16 crcval, u8 cval)
{
int i;
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;
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;
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;
}
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;
u16
crc16_special(u8 *buffer, int len)
{
u16 crc;
crc = 0;
while (--len >= 0)
crc = crc16(crc,*buffer++);
return crc;
}
crc = 0;
while (--len >= 0)
crc = crc16(crc,*buffer++);
return crc;
}
u16
crc16_payload(u8 *buffer, int len)
{
u16 crc;
u16
crc16_payload(u8 *buffer, int len)
{
u16 crc;
crc = 0xFFFF;
while (--len >= 0)
crc = crc16(crc,*buffer++);
return crc ^ 0xFFFF;
}
crc = 0xFFFF;
while (--len >= 0)
crc = crc16(crc,*buffer++);
return crc ^ 0xFFFF;
}
u32
crc32_payload(u8 *buffer, int len)
{
u32 crc;
u32
crc32_payload(u8 *buffer, int len)
{
u32 crc;
crc = 0xFFFFFFFFul;
while (--len >= 0)
crc = crc32(crc,*buffer++);
return crc ^ 0xFFFFFFFFul;
}
crc = 0xFFFFFFFFul;
while (--len >= 0)
crc = crc32(crc,*buffer++);
return crc ^ 0xFFFFFFFFul;
}
void
make_sdl_header(int packet_length, u8 *buffer)
{
u16 crc;
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;
}
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;
}
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 messages, 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.
为了生成纠错表，可以使用以下实现。它创建一个名为sdl_error_position的表，该表根据CRC剩余值编制索引。这些表可用于确定是否不存在错误（表项等于FE十六进制）、是否存在一个可纠正的错误（表项是错误位的基于零的索引，第一个八位位组的MSB为0）、是否存在多个错误以及错误是否不可纠正（表项为FF十六进制）。要用于八个八位字节消息，直接使用此表中的位索引。要用于四个八位字节消息，如果索引低于32，则将其视为不可恢复的错误；如果索引高于32，则将其视为位索引加32。
The program also prints out the error syndrome table shown in section 3.10. This may be used as part of a "switch" statement in a hardware implementation.
程序还打印出第3.10节所示的错误综合征表。这可以用作硬件实现中“switch”语句的一部分。
u8 sdl_error_position[65536];
u8 sdl_错误_位置[65536]；
/* Calculate new CRC from old^(byte<<8) */
u16
crc16_t8(u16 crcval)
{
u16 f1,f2,f3;
/* 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;
}
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;
void
generate_error_table(u8 *bptab, int nbytes)
{
u16 crc;
int i, j, k;
/* Marker for no error */
bptab[0] = 0xFE;
/* Marker for no error */
bptab[0] = 0xFE;
/* Marker for >1 error */
for (i = 1; i < 65536; i++ )
bptab[i] = 0xFF;
/* 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(' ');
/* Mark all single bit error cases. */
printf("Error syndrome table:\n");
for (i = 0; i < nbytes; i++) {
putchar(' ');
for (j = 0; j < 8; j++) {
crc = 0;
for (k = 0; k < i; k++)
crc = crc16_t8(crc);
crc = crc16_t8(crc ^ (0x8000>>j));
for (k++; k < nbytes; k++)
crc = crc16_t8(crc);
bptab[crc] = (i * 8) + j;
printf(" %04X",crc);
}
putchar('\n');
}
}
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;
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);
生成错误表（sdl错误位置，8）；
/* Run sample message through check routine. */
crc = 0;
for (i = 0; i < 8; i++)
crc = crc16_t8(crc ^ (buffer[i]<<8));
/* Run sample message through check routine. */
crc = 0;
for (i = 0; i < 8; i++)
crc = crc16_t8(crc ^ (buffer[i]<<8));
/* Output is 0000 64 -- no error encountered. */
printf("\nError test: CRC %04X, bit position %d\n",
crc,sdl_error_position[crc]);
}
/* Output is 0000 64 -- no error encountered. */
printf("\nError test: CRC %04X, bit position %d\n",
crc,sdl_error_position[crc]);
}
The reliability of public SONET/SDH networks depends on well-behaved traffic that does not disrupt the synchronous data recovery mechanisms. This document describes framing and scrambling options that are used to ensure the distribution of transmitted data such that SONET/SDH design assumptions are not likely to be violated.
公共SONET/SDH网络的可靠性取决于不破坏同步数据恢复机制的性能良好的通信量。本文件描述了用于确保传输数据分布的成帧和加扰选项，以确保不可能违反SONET/SDH设计假设。
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] 辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[2] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[2] 辛普森，W.，编辑，“HDLC类框架中的PPP”，STD 51，RFC 16621994年7月。
[3] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.
[3] Malis，A.和W.Simpson，“SONET/SDH上的PPP”，RFC 26151999年6月。
[4] "American National Standard for Telecommunications - Synchronous Optical Network (SONET) Payload Mappings," ANSI T1.105.02-1995.
[4] “美国国家电信标准-同步光网络（SONET）有效载荷映射”，ANSI T1.105.02-1995。
[5] ITU-T Recommendation G.707, "Network Node Interface for the Synchronous Digital Hierarchy (SDH)," March 1996.
[5] ITU-T建议G.707，“同步数字体系（SDH）的网络节点接口”，1996年3月。
[6] Doshi, B., Dravida, S., Hernandez-Valencia, E., Matragi, W., Qureshi, M., Anderson, J., Manchester, J.,"A Simple Data Link Protocol for High Speed Packet Networks", Bell Labs Technical Journal, pp. 85-104, Vol.4 No.1, January-March 1999.
[6] Doshi，B.，Dravida，S.，Hernandez Valencia，E.，Matragi，W.，Qureshi，M.，Anderson，J.，Manchester，J.，“高速分组网络的简单数据链路协议”，《贝尔实验室技术期刊》，第85-104页，第4卷第1期，1999年1-3月。
[7] Demers, A., S. Keshav, and S. Shenker, "Analysis and simulation of a fair queueing algorithm," ACM SIGCOMM volume 19 number 4, pp. 1-12, September 1989.
[7] Demers，A.，S.Keshav和S.Shenker，“公平排队算法的分析和模拟”，ACM SIGCOMM第19卷第4期，第1-12页，1989年9月。
[8] Floyd, S. and V. Jacobson, "Random Early Detection Gateways for Congestion Avoidance," IEEE/ACM Transactions on Networking, August 1993.
[8] Floyd，S.和V.Jacobson，“避免拥塞的随机早期检测网关”，IEEE/ACM网络事务，1993年8月。
[9] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994.
[9] 辛普森，W.，编辑，“PPP LCP扩展”，RFC 15701994年1月。
[10] ITU-T Recommendation I.432.1, "B-ISDN User-Network Interface - Physical Layer Specification: General Characteristics," February 1999.
[10] ITU-T建议I.432.1，“B-ISDN用户网络接口-物理层规范：一般特性”，1999年2月。
[11] ITU-T Recommendation V.41, "Code-independent error-control system," November 1989.
[11] ITU-T建议V.41，“代码独立差错控制系统”，1989年11月。
[12] ITU-T Recommendation G.783, "Characteristics of synchronous digital hierarchy (SDH) equipment functional blocks," April 1997.
[12] ITU-T建议G.783，“同步数字体系（SDH）设备功能块的特性”，1997年4月。
PPP over SONET was first proposed by Craig Partridge (BBN) and is documented by Andrew Malis and William Simpson as RFC 2615.
SONET的PPP最初由克雷格·帕特里奇（BBN）提出，安德鲁·马里和威廉·辛普森将其记录为RFC 2615。
Much of the material in this document was supplied by Lucent.
本文件中的大部分材料由朗讯公司提供。
Other length-prefixed forms of framing for PPP have gone before SDL, such as William Simpson's "PPP in Ether-like Framing" expired draft.
其他长度前缀的PPP框架形式在SDL之前就已经出现了，比如William Simpson的“以太框架中的PPP”过期草案。
The working group can be contacted via the mailing list (ietf-ppp@merit.edu; send mail to ietf-ppp-request@merit.edu to subscribe), or via the current chair:
可通过邮件列表（ietf）联系工作组-ppp@merit.edu；向ietf ppp发送邮件-request@merit.edu认购），或通过现任主席：
Karl Fox Extant, Inc. 3496 Snouffer Road, Suite 100 Columbus, Ohio 43235
卡尔·福克斯现存公司，俄亥俄州哥伦布斯努弗路3496号100室，邮编43235
EMail: karl@extant.net
EMail: karl@extant.net
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可供发布的权利主张副本和任何许可证保证副本，或试图
obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
可从IETF秘书处获得本规范实施者或用户使用此类专有权利的一般许可或许可。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
James Carlson Sun Microsystems, Inc. 1 Network Drive MS UBUR02-212 Burlington MA 01803-2757
James Carlson Sun Microsystems，Inc.1网络驱动器MS UBUR02-212马萨诸塞州伯灵顿01803-2757
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: james.d.carlson@sun.com
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: james.d.carlson@sun.com
Paul Langner Lucent Technologies Microelectronics Group 555 Union Boulevard Allentown PA 18103-1286
保罗朗纳朗讯科技微电子集团美国宾夕法尼亚州阿伦顿联合大道555号18103-1286
EMail: plangner@lucent.com
EMail: plangner@lucent.com
Enrique J. Hernandez-Valencia Lucent Technologies 101 Crawford Corners Rd. Holmdel NJ 07733-3030
恩里克·J·赫尔南德斯·巴伦西亚朗讯科技公司新泽西州霍姆德尔克劳福德角路101号07733-3030
EMail: enrique@lucent.com
EMail: enrique@lucent.com
James Manchester Lucent Technologies 101 Crawford Corners Rd. Holmdel NJ 07733-3030
詹姆斯·曼彻斯特·朗讯科技公司新泽西州霍姆德尔克劳福德角路101号07733-3030
EMail: sterling@hotair.hobl.lucent.com
EMail: sterling@hotair.hobl.lucent.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。