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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
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]はポイントツーポイントリンク、およびRFC 1662上のマルチプロトコル・データグラムを搬送するための標準的な方法を提供する[2]、2615 [3]同期上PPPを運ぶ手段を提供します光ネットワーク（SONET）[4]と同期デジタルハイアラーキ（SDH）[5]の回路。このドキュメントは、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で定められ、既存のHDLCのようなフレーミング[3]に代わるものではありません。代わりに、著者は、運用と性能評価目的のために、この技術を用いて実装経験を積むつもり、と考えるか、この文書に記載されたプロトコルを使用して他の人のいずれかから聞きしたいと思います。連絡先については、このドキュメントのセクション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
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管理ユニットグループ（8月）と呼ばれています。小数207（CFヘクス）の実験PSLの値は、現在[3] SPEは、PPPは、RFC 1662オクテット同期（OS）フレーミングおよび送信スクランブルせず、値22（16進）のために使用されている使用してフレーム含んでいることを示すために使用されます示されたPPPは、スクランブリングATMスタイルのX ^ 43 + 1とOSフレーミング及び送信を使用してフレーム。
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フレーミングはA固定7つのオクテットフレーム当たりのオーバーヘッドを加えた送信されたすべてのデータオクテットの100％の最悪の場合のオーバーヘッドを有するが、SDLゼロのデータオーバーヘッドを有するフレームオーバヘッドあたり固定8つのオクテットを有しています。 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）の値を示します。提案されたセット - リセットスクランブラとSDLのために提案された自己同期スクランブラ25（19進）とSDLのための23（17進）。これらの値は、SONETおよびSDH上SDLと共に使用するためのANSI T1X1.5とITU-T SG-15によって割り当てられた、および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"
* "MUST"
This word means that the item is an absolute requirement of the specification.
この単語は、アイテムが仕様の絶対的な要件であることを意味します。
* "MUST NOT"
* "MUST NOT"
This phrase means that the item is an absolute prohibition of the specification.
この句は、項目が仕様の絶対禁止であることを意味します。
* "SHOULD"
* "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".
それはMUSTの一つ以上を満たすために失敗したか、このプロトコルのための要件はありませんしなければならない場合は実装が準拠していません。 MUSTのすべてを満たす実装は、、、およびこのプロトコルのための要件は、「無条件に準拠した」と言われてすべきでないてはなりません。すべてのMUSTを満たし、要件はならず全てではないSHOULDまたはべきではありません要件は、「条件付き準拠した」と言われています。ワン
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と高いが、本書では考慮されています。 HDLCのようなフレーミングが定義されているので、このようなVT1.5-SPE / VC-11、およびそのようなT1及びT3としてプレシオクロナスペイロードマッピングなど、同期低速は、SONET / SDHおよびSDLアルゴリズム自体のために定義されるが、これらのメディア上のPPPは、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は、別々に、ビット同期HDLCの代替として使用するためのSONET / SDHフレーミングなし生ファイバ上で使用するためのPPPトランスポートとして定義されます。詳細については、独立したワーク・イン・プログレスを参照してください。
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ネゴシエーション方式と従来の配置方法を有効にする2つの方法があります。後者は、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.
SDLは、LCPによって交渉されると、LCPネゴシエーションは、最初に22または207に設定され、対応する非SDL O-S PPPカプセル化を使用しなければならないPSLの値で開始しなければなりません。 SDL LCPオプションは、送信さLCP設定要求メッセージ内に配置されています。 SDL LCPオプションまたはピアの送信PSLの値が23（または25）のように受信された場合、実装は、その状態マシンにダウンイベントを送ることによって、LCPをシャットダウンしなければならないとのLCP設定要求を受信すると、その送信されたPSL値を切り替えます23（または25）SDLに、スイッチのカプセル化モードに、SDLの同期化を待ち、その後、LCPにアップイベントを送信することにより、LCPを再起動します。そうでなければ、ピアはPSL値23（又は25）を送信しないと、それはSDLのLCPの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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
29
２９
Length
長さ
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 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設定否定応答またはLCPのいずれかを設定し、拒否した場合は、このオプションのために受信され、その後、次の送信LCP設定要求には、このオプションを含んではいけません。このオプションを指定したLCP設定肯定応答を受信した場合、それがSDLモードに切り替えるための要求として扱われてはなりません。受信LCP設定要求メッセージは、SDL LCPオプションが含まれていない場合、実装はオプションのため、迷惑設定否定応答を送ってはいけません。
(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フレーミングモードに既にあるとMAY、両方明確にするためと収束の理由から、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 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.
PPPのためのSDLフレーミングを用いた場合ルーセントSDL仕様を参照して、[6]、SDL特徴を値4に設定されている。これは、以下の説明では、固定オーバーヘッド値4に対応する「データグラムがオフセット」。 「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を使用して65536までPPP MRU / MTUを可能にします。
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フレーミングは、パケット上の4つのオクテットのヘッダを使用することによって達成一般的です。この固定長ヘッダは、セクション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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
4つのオクテット長ヘッダは、排他的OR（また、「モジュロ2加算」としても知られる）16進値B6AB31E0とでバランスが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 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.
パケット長値が4以上である場合には、SDL内の1つのメッセージヘッダと次との間のオクテットの距離が8の和プラスパケット長フィールドです。値8は、4つのオクテットプラスパケットのCRCフィールドの固定長の固定オーバーヘッドを表します。パケット長が0である場合、次のヘッダへの距離は4つのオクテットです。これは、アイドルフィルヘッダです。パケット長が1〜3である場合、次のヘッダまでの距離は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.
一般的なSDLは、PPPのようなパケットデータのないCRC、ITU-T CRC-16、またはITU-T CRC-32の使用を可能にします。パケット長フィールドは、CRCの長さを含んでいないので、CRCタイプはRFC 1570ごとに変更された場合、上記のようにフレーム間の距離は、CRCの長さを含む計算されているのでしかし、同期は、[9]に維持することができません。したがって、このPPPは、SDL仕様上CRC-32（4つのオクテット）のCRCタイプを固定し、すべてのSDLの実装は、任意のLCP FCS代替オプションSDLモードで[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.
4オクテットSDLヘッダのオーバーヘッドのために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.
パケット間のタイムフィルはゼロに設定され、パケット長を有する4つのオクテット長ヘッダを送信することによって達成されます。規定は、パケット内のタイムフィルのために作られていません。
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.
デフォルトでは、独立した、自己同期X ^ 43 + 1スクランブラは、32ビットのCRCを含むメッセージのデータ部に使用されます。これは、ATMチャネル上のATMのx ^ 43 + 1つのスクランブラと全く同じ方法で行われます。 SDLヘッダビットが送信されるときスクランブラはクロックされません。したがって、スクランブルデータは、SDLフレーミングから完全に独立した方法で実施することができる、データストリームは、SDLフレーミングマークの挿入前prescrambledことができます。
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.
必要に応じて、セクション6で説明したように事前の取り決めにより、SDLのリンクは、このオプションが提供されている場合、それは管理者によって構成可能でなければなりませんセット・リセットスクランブラを使用することができ、オプションでは、自己同期スクランブラをデフォルトとしなければなりません。
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 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つのオクテット）、ヘッダCRC、及びSDL CRCの長さのためにSDLヘッダを作成します。
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 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 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.
リンク同期手順SDLメッセージが可変長であることを除いて、I.432セクション4.5.1.1 ATM HEC描写手順[10]と同様です。有効なCRC-16とのデータストリームの4つのオクテットのシーケンスが発見されるまで、マシンはHUNT状態で起動します。 （マシンがSYNCH状態になるまでのセクション3.10に記載のCRC-16の単一ビット誤り訂正技術が採用されていないことに注意してください。ヘッダーはHUNT状態を残すために何ビットエラーを有していてはならない。）このような有効なシーケンスであります候補SDLヘッダー。有効なシーケンスを見つけることに、マシンはPRESYNCH状態になります。 PRESYNCH状態のいずれかの無効な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ヘッダがPRESYNCH状態に入った後に見られる場合、リンクがSYNCH状態に入り、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)
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.
各XORは、排他的論理和ゲートです。また、モジュロ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.
SDLヘッダCRCとCRC-16の3つの特別なメッセージの各々に使用される（スクランブル状態、メッセージA、メッセージB、セクション5を参照）は、すべての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 always be E2F0 hex. Alternatively, an implementation may stop CRC calculation before processing the appended CRC itself, and do a direct comparison.
オプションのCRC-16のペイロードデータには、（このモードは事前の取り決めによって除いSDL上PPPで使用されていない）計算のためヘクスFFFFの初期剰余値を使用し、ビットは送信前に補完されます。最終CRC残りは、しかし、定期的なPPP FCSとは異なり、ネットワークバイト順に伝送されます。 CRC-16アルゴリズムが付加されたCRC自体を含むオクテットのすべてにわたって実行された場合は、そのままパケット上の剰余値は常に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.
CRC-32のペイロードデータ（SDL上PPPのために用いられる）の計算のためにFFFFFFFFヘクスの初期剰余値を使用し、ビットは送信前に補完されます。 CRCは、しかしながら、逆の順序で送信される任意PPP 32ビットのFCSとは異なり、最上位ビットの第1、ネットワークバイト順に伝送されます。付加された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.)
テーブルルックアップは、このようにヘッダ内のビット誤りを訂正するために、複数のビット誤りを検出する4つのオクテットSDLヘッダにわたって計算した後にCRC-16残基に適用されます。オプションのセットリセットスクランブラのために、テーブルルックアップは、同様にビット誤りを訂正するために、複数のビット誤りを検出するために8つのオクテットスクランブラ状態メッセージにわたって計算後のCRC-16残基に適用されます。 （この第二の補正もSDL上PPPのために使用されていない特殊なSDL A及びBメッセージのために使用されます。）
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ヘッダ内の任意のこのようなエラーは、HUNT状態へのリンクを返します。
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の計算はゼロで開始されているので、2つの表は、マージすることができます。 4つのオクテットのテーブルには、単に8つのオクテットテーブルの最後の32のエントリです。
Eight octet (64 bit) single bit error syndrome table (in hexadecimal):
八つのオクテット（64ビット）（16進数）の単一ビット誤りシンドロームテーブル：
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 NEC 6EF6 377B 93AD C1-C6 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 6662 3331 9188 89A9 CC4 48C4 2462 1231 8108 4084 2042 1021
Thus, if the syndrome 6EF6 is seen on an eight octet message, then the third bit (hex 20) of the second octet is in error. Similarly, if 48C4 is seen on an eight octet message, then the second bit (hex 40) in the eighth octet is in error. For a four octet message, the same two syndromes would indicate a multiple bit error for 6EF6, and a single bit error in the second bit of the fourth octet for 48C4.
シンドローム6EF6は8つのオクテットメッセージで見ている場合したがって、第2オクテットの第3ビット（16進数20）はエラーです。 48C4は8つのオクテットメッセージに見られる場合に同様に、次いで第オクテットにおける第2ビット（16進数40）はエラーです。 4つのオクテットメッセージを、同じ2つのシンドロームが6EF6ための複数のビット誤り、および48C4のための第四オクテットの2ビットでシングルビットエラーを示すであろう。
Note that eight octet messages are used only for the optional set-reset scrambling mode, described in section 6.
8つのオクテットメッセージはセクション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:
アルゴリズムをフレーミングするための重要な5つの一般的な統計があります。これらは：
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は、フレームの損失の虚偽の同期PLF確率の偽フレームPFS確率のPFF確率を同期化MTTS平均時間をフレームに時間を平均します
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:
最大64キロバイトのパケットとインターネット平均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
使用不可使用不可フレーマ64キロバイトのパケットの数354のバイトのパケット数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
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のための特徴的平坦な領域を示しています。すべての場合において、このニーポイントは、既存のSONET / SDHリンク上で観察される上記数桁は約1E-4のBER、で生じることが見出されました。フラットレート値は次のように要約されます。
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
平坦領域平坦領域フレーマ64キロバイトのパケットの数354バイト1 3.58 1.52 2 1.595 1.5 3 1.52 1.5 4 1.5 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.
したがって、1E-4以上のBERとのリンクを使用して、2つの平行フレーマと実装における共通パケットサイズのために、MTTFは約1.5のパケットです。それは1つのパケットに平均ポイント途中でフレーミングを開始し、かつ正確に一つ正しくフレームのパケットを見た後の良好なフレーミングを達成表しているので、これはまた、最適な時間です。
The MTTS for SDL with a self-synchronous scrambler is the same as the MTTF, or 1.5 packets.
自己同期スクランブラとSDLのためのMTTSは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.
オプションのセットリセットスクランブラを使用してSDLためMTTSは、一（パケットにおける）スクランブル状態の送信間隔の半分プラスMTTFあります。 1 8あたりのパケットのデフォルトのレートで挿入するために、MTTSは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.)
（悪いスクランブル状態の送信を受信する確率は、この計算に含まれるべきである。このショートメッセージのランダムな破損の確率は、それが、この計算のために無視することができるように十分に小さくなるように[6] SDL文書に示されています。）
The PFF is 2.328E-10 (2^-32), since false framing requires two consecutive headers with falsely correct CRC-16.
偽フレーミングが誤って正しいCRC-16を有する2つの連続したヘッダを必要とするのでPFFは、2.328E-10（^ -32 2）です。
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.
セットリセットスクランブラとSDLのためのPFSは5.421E-20（2 ^ -64）、及び上記自体は、2つの独立したCRC-16の計算が含まれて誤検出スクランブル状態メッセージの確率を乗じたPFFとして算出されます。
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のために約32ビットSDLヘッダ内に発生する二つ以上のビットエラーの確率である500を乗じたBERの正方形です。したがって、1E-5のBERで、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の値は、以下のサブセクションで定義されています。これらの特別なメッセージはそれぞれSDLヘッダを持つように、そのデータ部分の上に別のCRC-16に続く6つのオクテットのデータ部で構成され、この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の特別な値は、オプションのセットリセットスクランブラのために送信機から受信機にスクランブル状態を転送するために予約されています。この場合には、SDLヘッダは、スクランブラ状態の6つのオクテット（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」ともCRC-16の2つのオクテットが続く長さが6つのオクテットである「B」メッセージのために予約されています。これらの8つのオクテットのそれぞれは、スクランブルされています。 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.
一般的に、スクランブリングは、2つの問題を解決します。まず、SONETおよびSDHインターフェイスは、ハードウェア・クロック・リカバリを維持するために、ビット遷移の最小濃度を必要とします。データストリームので、しばしばこれらpattersを分割擬似乱数シーケンスを用いてビットをスクランブリング、すべてゼロまたはすべてのものの長いランを含みます。第二に、すべてのリンク層の同期メカニズムは、フレーミングを検出するために、受信したデータに長距離パターンの検出に依存します。
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のために定義されたオプションセットリセットスクランブラは、リンクがPRESYNCH状態に入り、値がこれまでのすべてのゼロ・ビットになると再初期化時にすべてのものに初期化X ^ 48 + X ^ 28 + X ^ 27 + X + 1の独立したスクランブラです。自己同期スクランブラと同様に、最終的なパケットCRC介してSDLヘッダに続く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.
このモードは、自動的に検出することができます。スクランブラ状態メッセージが（次のセクションで説明したように）受信した場合、セットリセットスクランブラオプションを含むSDL実装が自動的に設定リセットモードに自己同期型から切り替えることができます。セット・リセットスクランブラを含んでいない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ヘッダは、スクランブラ状態の6つのオクテット（48ビット）プラススクランブラ状態にわたるCRC-16の2つのオクテットが続きます。これらの8つのオクテットのどれもがスクランブルされていません。
SDL synchronization consists of two components, link and scrambler synchronization. Both must be completed before PPP data flows on the link.
SDLの同期は、2つのコンポーネント、リンク及びスクランブラの同期で構成されています。 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ヘッダがPRESYNCH状態で見ている場合、リンクがSYNCH状態になり、スクランブラの同期シーケンスが開始されます。無効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.
スクランブラの同期が開始されると、スクランブラ状態メッセージは、（パケット長がSDLヘッダに従うネットワークバイト順にスクランブラ状態の1と6オクテットに設定される）送信されます。スクランブラ同期メッセージがピアから受信されたとき、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.
スクランブラの状態メッセージは、定期的に同期してピアを維持するために送信されます。一度8あたりの送信パケットの期間が提案され、そしてそれは設定であるべきです。検出された過剰なパケットの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回のステージでのシフトレジスタです。シフトレジスタ内の値は、これまですべてゼロになった場合に各々が全て1つのビットを再充填されます。 SONET / SDH X ^ 7 + X ^ 6 + 1スクランブラであり、またATMの自己同期スクランブラであるように、それは、送信されたデータによって変更されるように、このスクランブラは、各フレームの開始時にリセットされません。その代わりに、特殊なSDLメッセージを使用して、同期に保たれています。
+----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.
各XORは、排他的論理和ゲートです。また、モジュロ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データの各ビットの送信後に一度クロックされます。スクランブリングは、所与のオクテットが有効になっている場合、OUTビットは排他的論理和伝送されたビットを生成するために生データビットです。オクテット内のビットは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.
スクランブラ状態メッセージを生成するために、D0を介しD47の内容は、最初のスクランブル状態ビットが送信される時点でのスナップショットです。 D47は、出力の最初のビットとして送信されます。送信された最初のオクテットは、D0を介しD40を介して、D47、D32を介して第2のオクテットD39、第6オクテットD7を含んでいます。
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.)
修正されたメッセージをD0：それ以外の場合は、全体の内容がスクランブル状態D47を受け取る比較する必要があります。 （メッセージのデスクランブラに到着したとき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のオーバーヘッドは4つのオクテットです。 SDLフレーマは、パケット長を通信するために処理PPP入力にSDLパケットヘッダを提示する場合（ルーセントの実装がこれを行っていないが、他のハードウェア実装があります）、このヘッダは、4つのオクテットであり、位置合わせが維持されます。
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は、PPPのトランスポートとしてHDLCの場所を取るしているので、それは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.
次の最適化されていないコードは、適切なCRC-16及びSDLメッセージのCRC-32値を生成します。多項式のビットがSDLのCRCのためのビッグエンディアン順に番号が付けられていることに注意してください。ビット0がMSBです。
typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned long u32;
#define POLY16 0x1021 #define POLY32 0x04C11DB7
#define POLY16 0x1021の#define POLY32 0x04C11DB7
u16 crc16(u16 crcval, u8 cval) { int i;
U16のCRC16（U16のcrcval、U8のCVAL）{iがint型。
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）{iがint型。
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 *バッファ、INT LEN）{U16の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 *バッファ、INT LEN）{U16のCRC。
crc = 0xFFFF;
while (--len >= 0)
crc = crc16(crc,*buffer++);
return crc ^ 0xFFFF;
}
u32 crc32_payload(u8 *buffer, int len) { u32 crc;
U32のcrc32_payload（U8 *バッファ、INT LEN）{U32のCRC。
crc = 0xFFFFFFFFul;
while (--len >= 0)
crc = crc32(crc,*buffer++);
return crc ^ 0xFFFFFFFFul;
} void
make_sdl_header(int packet_length, u8 *buffer)
{
u16 crc;
buffer[0] = (packet_length >> 8) & 0xFF;
buffer[1] = packet_length & 0xFF;
crc = crc16_special(buffer,2);
buffer[0] ^= 0xB6;
buffer[1] ^= 0xAB;
buffer[2] = ((crc >> 8) & 0xFF) ^ 0x31;
buffer[3] = (crc & 0xFF) ^ 0xE0;
}
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.
誤差補正テーブルを生成するために、次の実装が使用されてもよいです。これは、CRC剰余値でインデックス化されsdl_error_positionと呼ばれるテーブルを作成します。テーブルは、（テーブルエントリはFEヘクスに等しい）エラーがないかどうかを決定するために使用することができ、1つの訂正可能なエラーが存在する、または複数のエラー（テーブル・エントリは0である最初のオクテットのMSBとエラーの発生したビットに0から始まるインデックスです）存在し、エラー（テーブルエントリがFFヘクスで）訂正不能です。 8つのオクテットのメッセージに使用するには、このテーブルからのビットインデックスが直接使用されます。 4つのオクテットのメッセージに使用するために、それが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に示すエラーシンドロームテーブルをプリントアウトします。これは、ハードウェア実装に「スイッチ」文の一部として使用することができます。
u8 sdl_error_position[65536];
U8のsdl_error_position [65536]。
/* Calculate new CRC from old^(byte<<8) */
u16
crc16_t8(u16 crcval)
{
u16 f1,f2,f3;
f1 = (crcval>>8) | (crcval<<8);
f2 = (crcval>>12) | (crcval&0xF000) | ((crcval>>7)&0x01E0);
f3 = ((crcval>>3) & 0x1FE0) ^ ((crcval<<4) & 0xF000);
return f1^f2^f3;
} void
generate_error_table(u8 *bptab, int nbytes)
{
u16 crc;
int i, j, k;
/* Marker for no error */
bptab[0] = 0xFE;
/* Marker for >1 error */
for (i = 1; i < 65536; i++ )
bptab[i] = 0xFF;
/* Mark all single bit error cases. */
printf("Error syndrome table:\n");
for (i = 0; i < nbytes; i++) {
putchar(' ');
for (j = 0; j < 8; j++) {
crc = 0;
for (k = 0; k < i; k++)
crc = crc16_t8(crc);
crc = crc16_t8(crc ^ (0x8000>>j));
for (k++; k < nbytes; k++)
crc = crc16_t8(crc);
bptab[crc] = (i * 8) + j;
printf(" %04X",crc);
}
putchar('\n');
}
}
int
main(int argc, char **argv)
{
u8 buffer[8] = {
0x01,0x55,0x02,0xaa,
0x99,0x72,0x18,0x56
};
u16 crc;
int i;
generate_error_table(sdl_error_position,8);
generate_error_table（sdl_error_position、8）。
/* Run sample message through check routine. */
crc = 0;
for (i = 0; i < 8; i++)
crc = crc16_t8(crc ^ (buffer[i]<<8));
/* Output is 0000 64 -- no error encountered. */
printf("\nError test: CRC %04X, bit position %d\n",
crc,sdl_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 1661、1994年7月。
[2] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[2]シンプソン、W.、エディタ、 "PPP HDLC様のフレーミングに" STD 51、RFC 1662、1994年7月。
[3] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.
[3] Malis、A.およびW.シンプソン、 "PPP SONET上/ SDH"、RFC 2615、1999年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、1996年3月 "同期デジタル階層（SDH）、のためのネットワークノードインタフェース"。
[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]道志、B.、Dravida、S.、ヘルナンデス - バレンシア、E.、Matragi、W.、クレシ、M.、アンダーソン、J.、マンチェスター、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]デマーズ、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]フロイド、S.とV. Jacobson氏、 "輻輳回避のためのランダム早期検出ゲートウェイ、" ネットワーキング、1993年8月にIEEE / ACM取引。
[9] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994.
[9]シンプソン、W.、エディタ、 "PPP LCP拡張機能"、RFC 1570、1994年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としてアンドリューMalisとウィリアム・シンプソンによって文書化されています。
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のフレーミングの他の長さ接頭辞形態は、ウィリアム・シンプソンの「PPPエーテルのようなフレーミングで」期限切れドラフトとして、SDLの前に行っています。
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 Snouffer道路、スイート100コロンバス、オハイオ州43235
EMail: karl@extant.net
メールアドレス：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 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は、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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
ジェームズ・カールソンサン・マイクロシステムズ株式会社1ネットワークドライブのMS UBUR02-212バーリントンMA 01803から2757
Phone: +1 781 442 2084 Fax: +1 781 442 1677 EMail: james.d.carlson@sun.com
電話：+1 781 442 2084ファックス：+1 781 442 1677 Eメール：james.d.carlson@sun.com
Paul Langner Lucent Technologies Microelectronics Group 555 Union Boulevard Allentown PA 18103-1286
ポールLangnerルーセント・テクノロジーマイクロエレクトロニクスグループ555連合大通りアレンタウンPA 18103から1286
EMail: plangner@lucent.com
メールアドレス：plangner@lucent.com
Enrique J. Hernandez-Valencia Lucent Technologies 101 Crawford Corners Rd. Holmdel NJ 07733-3030
エンリケJ.ヘルナンデス - バレンシアルーセントテクノロジーズ101クロフォードコーナーRdを。ホルムデルNJ 07733-3030
EMail: enrique@lucent.com
メールアドレス：enrique@lucent.com
James Manchester Lucent Technologies 101 Crawford Corners Rd. Holmdel NJ 07733-3030
ジェームズ・マンチェスター・ルーセント・テクノロジーズ101クロフォードコーナーRdを。ホルムデルNJ 07733-3030
EMail: sterling@hotair.hobl.lucent.com
メールアドレス：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 Editor機能のための基金は現在、インターネット協会によって提供されます。