[要約] 要約：RFC 2823は、SONET/SDHを使用したATMのようなフレーミングを介して、シンプルデータリンク（SDL）上のPPPを定義しています。 目的：このRFCの目的は、SDL上でのPPPの実装を標準化し、SONET/SDHネットワークでのデータ通信を効率的かつ信頼性の高いものにすることです。
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のようなフレーミングを使用して、SONET/SDHを使用した単純なデータリンク（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.
Copyright（c）The Internet Society（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]は、同期上にPPPを運ぶ手段を提供します。光ネットワーク（SONET）[4]および同期デジタル階層（SDH）[5]回路。このドキュメントは、これらの標準を拡張して、Simple Data Link（SDL）と呼ばれるPPPの新しいカプセル化を含むようにします[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]などのキューイングや輻輳制御戦略の一般的な長さ情報の一般的な要件のために、最新のルーターの大きな不利益ではないようです[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
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）と呼ばれます。10進207の実験PSL値（cf hex）は、現在[3]を使用して、SPEにRFC 1662 Octet同期（O-S）フレーミングとトランスミッションを使用してFRAMEDを含むことを示しています。ATMスタイルのX^43 1スクランブルを使用したO-Sフレーミングとトランスミッションを使用してフレーム化された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フレーミングには、フレームごとに固定された7オクテットのオーバーヘッドに加えて、すべてのデータオクテットの100％の最悪のオーバーヘッドが送信されますが、SDLには、ゼロデータオーバーヘッドを備えたフレームあたり8オクテットあたり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).
注：このドキュメントは、2つの新しいSONET/SDHパス信号ラベル（PSL）値を説明しています。提案されたセルフ同期スクランブラーを備えたSDLの23（17ヘックス）および提案されたセットレスセットスクランブラーを使用したSDLの25（19ヘックス）。これらの値は、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"
* "しなければならない"
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"
* "5月"
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.
この単語は、このアイテムが本当にオプションであることを意味します。1人のベンダーは、特定の市場に必要なものを必要とするため、またはたとえば製品を強化するため、アイテムを含めることを選択できます。別のベンダーは同じアイテムを省略する場合があります。
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".
このプロトコルの要件の1つ以上を満たすことができない場合、実装は準拠していません。このプロトコルの要件が「無条件に準拠している」と言われている、必須、必須、すべきではない、そしてすべきではないすべてのものを満たす実装が満たされます。すべての要件を満たす必要があり、必要ではないものは、すべての要件ではなく、要件をすべて満たすものではなく、要件をすべて満たすものではなく、「条件付きに準拠」していると言われています。
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以上のみが考慮されます。VT1.5-SPE/VC-11などの低速同期、およびT1やT3などのプレシオクロナスペイロードマッピングは、SONET/SDHおよびSDLアルゴリズム自体で定義されていますが、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は、ビット同期HDLCの代替として使用するためのSONET/SDHフレーミングなしで、生繊維で使用するPPP輸送として個別に定義されています。詳細については、Progressでの別の作業をご覧ください。
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のみを使用する機器は、PSLを値23で送信できる必要があり、PSLを値25で送信することもできますが、ピアの価値を検出したり、独自の値を変更できる必要はありません。
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を有効にする2つの方法、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.
SDLがLCPによって交渉される場合、LCP交渉は最初に22または207に設定されたPSL値から開始する必要があり、対応する非SDL O-S PPPカプセル化を使用する必要があります。SDL LCPオプションは、送信されたLCP Configure-Requestメッセージに配置されます。SDL LCPオプションを使用したLCP Configure-Requestの受信時、またはピアの送信PSL値が23（または25）として受信された場合、実装はダウンイベントをステートマシンに送信してLCPをシャットダウンし、送信されたPSL値を切り替える必要があります。23（または25）まで、カプセル化モードをSDLに切り替え、SDL同期を待ち、次にLCPをLCPに送信してLCPを再起動します。それ以外の場合、ピアがPSL値23（または25）を送信せず、LCP Configure-RequestメッセージにSDL LCPオプションが含まれていない場合、非SDL O-S PPPカプセル化を使用した操作が継続されます。受信したPSL値がその後23（または25）から他の値に戻る場合、これはLCP状態マシンのダウンイベントとして扱われ、新しい値が有効なPPPとして認識される場合はUPイベントを生成する必要がありますフレーミングモード。
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関連モードの使用を可能にする必要があります。このオプションは管理者に提示され、ハードウェアが許可されている場合は、デフォルトで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.
Link Controlプロトコル（LCP）のSimple-Data-Link構成オプションフォーマットの概要を以下に示します。フィールドは左から右に送信されます。
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.
このオプションは、SONET/SDH操作を介したSDLが送信者が好むピアのヒントとしてのみ使用されます。現在のカプセル化モードがSDLでない場合、SDLスピーカーによるこのオプションの受信に対する唯一の適切な応答は、カプセル化モードをSDL（上記のセクションで詳述）に切り替えてLCPを再起動することです。代わりに、SDLスピーカー以外のスピーカーは、オプションにLCP Configure-Rejectを送信する必要があります。
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-Requestにこのオプションを含めてはなりません。このオプションを使用してLCP configure-ackを受信した場合、SDLモードに切り替えるリクエストとして扱われてはなりません。受信したLCP Configure-RequestメッセージにSDL LCPオプションが含まれていない場合、実装はオプション用の未承諾Configure-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 Configure-Requestメッセージでこのオプションを受信するSDLの実装は、明確にも収束的な理由でも、LCP configure-ackを送信することを選択しません。この場合。）
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.
Lucent SDL仕様[6]を参照して、PPPのSDLフレーミングが使用されると、SDL「データグラムオフセット」機能は値4に設定されます。これは、以下の説明の固定オーバーヘッド値4に対応します。「A」と「B」メッセージは使用されません。SDLのこれらのオプションの機能は、このドキュメントでは説明されていませんが、LucentのSDL仕様で説明されています。
Fixing the Datagram Offset value described in the Lucent documentation to 4 allows a PPP MRU/MTU up to 65536 using SDL.
Lucentドキュメントで説明されているデータグラムのオフセット値を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オクテットの長さヘッダーは、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以上の場合、1つのメッセージヘッダーとSDLの次のメッセージヘッダーの間のオクテットの距離は、パケット長の合計とパケット長のフィールドです。値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.
PPPと同様に、一般的なSDLは、パケットデータにNO CRC、ITU-T CRC-16、またはITU-T CRC-32を使用できます。ただし、パケットの長さフィールドにはCRCの長さが含まれていないため、CRCタイプがRFC 1570 [9]ごとに変更された場合、同期は維持できません。したがって、このSDL仕様を介したこのPPPは、CRCタイプをCRC-32（4オクテット）に修正し、すべての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タイプを設定することができます。このような構成可能なオプションは、default 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つのOctet SDLヘッダーオーバーヘッドの4つのアカウントに設定します。SDL Datagramオフセットが4に設定されている場合、パケット長フィールドに配置された値は、アドレスと制御フィールドを含むが、CRCフィールドを含むPPPフレーム自体のオクテットの長さです（RFC 1662 PPP FCSフィールドはそうではありませんSDLで使用）。Datagramオフセットは単なる算術値であることに再度注意してください。メッセージ自体のビットを占有しません。
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.
デフォルトでは、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 Configure-Requestメッセージがあります。
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（Datagramオフセット値を固定）と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オクテットシーケンスが見つかるまで、ハント状態で開始されます。（セクション3.10で説明されているCRC-16単一ビットエラー補正手法は、マシンが同期状態になるまで使用されないことに注意してください。ヘッダーは、ハント状態を離れるために少しエラーを持たない必要があります。）このような有効なシーケンスは、候補SDLヘッダー。有効なシーケンスを見つけると、マシンはプレシン状態に入ります。Presynch StateのSDLヘッダーが無効になっている人は、Hunt Stateへのリンクを返します。
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.
Presynch Stateに入った後に2番目の有効なSDLヘッダーが見られる場合、リンクは同期状態に入り、PPP伝送が有効になります。無効なSDLヘッダーが検出された場合、リンクはPPP伝送を可能にすることなくHUNT状態に戻ります。
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エラーは、リンクをHUNT状態に戻し、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は排他的またはゲートです。Modulo-2 Adderとも呼ばれます。各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.
スクランブラーは、ペイロードの各ビットの送信または受信後、次のビットが入力として適用される前に1回クロックされます。Octet内のビットは、SONET/SDHプラクティスごとに、MSB-Firstを送信して受け取りました。
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^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と3つの特別なメッセージ（Scrambler State、メッセージA、およびメッセージBを参照）のそれぞれに使用されるCRC-16はすべて、0000 HEXの初期残り値を使用して生成されます。
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 160個の初期残り値を使用し、透過前にBITが補完されます。ただし、最終的なCRCの残りは、通常のPPP FCとは異なり、ネットワークバイトの順序で送信されます。CRC-16アルゴリズムが、追加されたCRC自体を含むすべてのオクテットで実行されている場合、無傷のパケットの残りの値は常にE2F0 HEXになります。あるいは、実装では、追加された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に使用）は、計算にFFFFFFFFF HEXの初期残り値を使用し、透過前にBITが補完されます。ただし、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補正と同様に、Galois番号フィールドの使用に基づいています。ガロワ数フィールドでは、f（a b）= f（a）f（b）。SDLに使用されるCRC-16はそのようなフィールドを形成するため、CRC（メッセージエラー）= CRC（メッセージ）CRC（エラー）を述べることができます。CRC-16は適切に形成されたメッセージの残りは常にゼロであるため、これは、単一のビットエラーに対応するn個の「エラー」文字列の場合、n個別のCRC（エラー）値があり、ここでnは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つのOctet SDLヘッダーの計算後にCRC-16残基に適用され、ヘッダーのビットエラーを修正し、複数のビットエラーを検出します。オプションのセットレスセットスクランブラーの場合、ビットエラーを修正し、複数のビットエラーを検出するために、8つのOctet Scrambler Stateメッセージの計算後、テーブルの検索がCRC-16残基に同様に適用されます。（この2番目の修正は、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.
注：このエラー補正手法は、リンクが同期状態に入った場合にのみ使用されます。ハントまたはシンチの状態では、エラー修正を実行する必要はなく、症候群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計算はゼロで開始されるため、2つのテーブルをマージできます。4 Octetテーブルは、8 Octetテーブルの最後の32エントリにすぎません。
Eight octet (64 bit) single bit error syndrome table (in hexadecimal):
8オクテット（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 DDEC 6EF6 377B 93AD C1C6 60E3 B861 D420 6A10 3508 1A84 0D42 06A1 8B40 45A0 22D0 374E 1BA7 85C3 CAF1 ED68 76B4 3B5A 1DAD 86C6 4363 A9A1 DCC0 6E60 3730 1B98 0DCC06E6 0373 89A9 CCC4 6662 3331 9188 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進数）が誤っています。同様に、48C4が8オクテットのメッセージで見られる場合、8番目のオクテットの2番目のビット（ヘックス40）が誤っています。4オクテットのメッセージの場合、同じ2つの症候群が6EF6の複数のビットエラーと、48C4の4番目のオクテットの2番目のビットに1つのビットエラーを示します。
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平均MTTS平均同期する平均時間PFF誤りの確率PFFS誤同期の確率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のこれらの統計のそれぞれを要約します。詳細と数学の開発は、Lucent 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 BYTE PKTS 1 3.679E-1 5.373E-3 2 3.083E-2 1.710E-6 3 2.965E-3 9.712E-10
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の特徴的な平坦な領域を示しており、それを超えて急激に上昇し始めます。すべての場合において、この膝点は約1E-4のBERで発生することがわかっています。これは、既存の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
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つのパケットへの途中でフレーミングを開始し、正確に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の半分です。8つのパケットあたり1つのデフォルトレートで挿入する場合、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.)
（この計算にも悪いスクランブル状態伝送を受ける確率も含める必要があります。この短いメッセージのランダム破損の確率は、SDLドキュメント[6]に、この計算のために無視できるほど小さいことが示されています。）
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（2^-32）です。
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）であり、上記の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の場合、BERのほぼ正方形に500を掛けています。これは、32ビットSDLヘッダー内で2つ以上のビットエラーが発生する可能性です。したがって、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.
パケット長の特別な値は、オプションのセットレセットスクランブラーのために、トランスミッターから受信機にスクランブラー状態を転送するために予約されています。この場合、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」と「B」メッセージに予約されており、長さ6オクテットに続いてCRC-16の2オクテットも続きます。これらの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インターフェイスには、ハードウェアクロック回復を維持するために、ビット遷移の最小密度が必要です。データストリームにはしばしばすべてのゼロまたはすべてのゼロのロングランが含まれているため、擬似ランダム数シーケンスを使用してビットをスクランブルすると、これらのパターンが分割されます。第二に、すべてのリンク層同期メカニズムは、受信したデータの長距離パターンの検出に依存してフレーミングを検出します。
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.
自己同期スクランブルは、これらの問題を部分的に回避する簡単な方法です。ただし、自己同期に固有の問題の1つは、悪意のあるサイトからの長いユーザーパケットがこれらのスクランブラーの既知のプロパティを利用して、ゼロの長い文字列または他の同期デストロキングパターンをリンクに注入できることです。ネットワークに提示されたデータが通常、複数の無関係なストリームを備えた多重化（相互作用）であるパブリックネットワークの場合、クロッキングの問題はパブリックネットワークに大きな脅威をもたらさない。しかし、それは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独立したスクランブラーです。自己同期スクランブラーと同様に、最終パケット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.
前のセクションで説明したように、パケット長の特別な値は、トランスミッターから受信機にスクランブラー状態を転送するために予約されています。この場合、SDLヘッダーの後に、スクランブラー状態の6オクテット（48ビット）とスクランブラー状態で2オクターのCRC-16が続きます。これらの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ヘッダーがプレシンチ状態で見られる場合、リンクは同期状態に入り、スクランブラー同期シーケンスが開始されます。無効な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.
Scrambler同期が開始されると、スクランブラー状態メッセージが送信されます（ネットワークバイトの順序でスクランブラー状態の1オクテットと6オクテットに設定されたパケット長。Scrambler同期メッセージがピアから受信されると、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.
Scramblerの状態メッセージは、ピアを同期させるために定期的に送信されます。送信された8つのパケットに1回の期間が提案されており、構成可能である必要があります。検出された過剰なパケット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.
Scrambler Stateメッセージを受信すると、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
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は排他的またはゲートです。Modulo-2 Adderとも呼ばれます。各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.
Scramblerは、送信されたビットがスクランブルされているかどうかにかかわらず、SDLデータの各ビットを送信した後に1回クロックされます。特定のオクテットのスクランブルが有効になっている場合、Out Bitは、送信ビットを生成するためにRaw Data Bitを使用して排他的に並んでいます。オクテット内のビットは、MSB-FIRSTを送信します。
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、2番目のオクテットD39からD32、6番目のオクテット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.
Scrambler Stateメッセージの受信者は、最初に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オーバーヘッドは4オクターです。SDLフレーマーがパケットの長さを通信するためにSDLパケットヘッダーをPPP入力処理に提示する場合（Lucent実装はこれを行いませんが、他のハードウェアの実装は可能な場合があります）、このヘッダーは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交渉を介して、2つの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;
#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）{int i;
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;
}
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;
}
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;
}
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;
}
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.
エラー修正テーブルを生成するには、次の実装を使用できます。SDL_ERROR_POSITIONというテーブルを作成し、CRC残基値にインデックス付けされています。テーブルを使用して、エラーが存在しないかどうかを判断できます（テーブルエントリがFe hexに等しい）、1つの修正可能なエラーが存在します（テーブルエントリはゼロベースのインデックスからエラービットからゼロベースのインデックスです。存在し、エラーは修正できません（テーブルエントリはFF 160個です）。8つのOctetメッセージに使用するために、このテーブルのビットインデックスが直接使用されます。4つのOctetメッセージに使用するために、インデックスは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.
パブリックソネット/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。、編集者、「HDLCのようなフレーミングのPPP」、STD 51、RFC 1662、1994年7月。
[3] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.
[3] Malis、A。and W. Simpson、「PPP Over 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、「同期デジタル階層のネットワークノードインターフェイス（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。、「高速パケットネットワーク用の単純なデータリンクプロトコル」、Bell Labs Technical Journal、pp。85-104、Vol.4 No.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 Volume 19番号4、pp。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、「混雑回避のためのランダムな早期検出ゲートウェイ」、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は、Craig Partridge（BBN）によって最初に提案され、Andrew MalisとWilliam SimpsonによってRFC 2615として記録されています。
Much of the material in this document was supplied by Lucent.
この文書の資料の多くは、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.
William Simpsonの「Ether-like Framing」の有効期限が切れたドラフトなど、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
Karl Fox Extant、Inc。3496 Snouffer Road、Suite 100 Columbus、Ohio 43235
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 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
James Carlson Sun Systems、Inc。1ネットワークドライブMS UBUR02-212バーリントンMA 01803-2757
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
Paul Langner Lucent Technologies Microelectronics Group 555 Union Boulevard Allentown PA 18103-1286
EMail: plangner@lucent.com
Enrique J. Hernandez-Valencia Lucent Technologies 101 Crawford Corners Rd. Holmdel NJ 07733-3030
Enrique J. Hernandez-Valencia Lucent Technologies 101 Crawford Corners Rd。ホルムデルNJ 07733-3030
EMail: enrique@lucent.com
James Manchester Lucent Technologies 101 Crawford Corners Rd. Holmdel NJ 07733-3030
ジェームズ・マンチェスター・ルーセント・テクノロジーズ101クロフォード・コーナーズ・ロード。ホルムデルNJ 07733-3030
EMail: sterling@hotair.hobl.lucent.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。