RFC1549 日本語訳
1549 PPP in HDLC Framing. W. Simpson, Ed.. December 1993. (Format: TXT=36352 bytes) (Obsoleted by RFC1662) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Simpson, Editor Request for Comments: 1549 Daydreamer Category: Standards Track December 1993
ワーキンググループのW.シンプソン、コメントを求めるエディタ要求をネットワークでつないでください: 1549年の空想家カテゴリ: 標準化過程1993年12月
PPP in HDLC Framing
HDLC縁どりにおけるppp
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。
This document describes the use of HDLC for framing PPP encapsulated packets. This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list.
このドキュメントはHDLCのパケットであるとカプセル化された縁どりPPPの使用について説明します。 このドキュメントはPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。 ietf-ppp@ucdavis.edu メーリングリストにコメントを提出するべきです。
Table of Contents
目次
1. Introduction ..................................................2 1.1 Specification of Requirements .................................2 1.2 Terminology ...................................................3 2. Physical Layer Requirements ...................................3 3. The Data Link Layer ...........................................4 3.1 Frame Format ..................................................5 3.2 Modification of the Basic Frame ...............................7 4. Asynchronous HDLC .............................................7 5. Bit-synchronous HDLC ..........................................5 6. Octet-synchronous HDLC ........................................12 APPENDIX A. Fast Frame Check Sequence (FCS) Implementation .........13 A.1 FCS Computation Method ........................................13 A.2 Fast FCS table generator ......................................15 SECURITY CONSIDERATIONS ............................................16 REFERENCES .........................................................17 ACKNOWLEDGEMENTS ...................................................17 CHAIR'S ADDRESS ....................................................18 EDITOR'S ADDRESS ...................................................18
1. 序論…2 1.1 要件の仕様…2 1.2用語…3 2. 物理的な層の要件…3 3. データ・リンク層…4 3.1 形式を縁どってください…5 3.2 基本枠の変更…7 4. 非同期なHDLC…7 5. ビット同期のHDLC…5 6. 八重奏同期のHDLC…12付録のA.の速いフレームチェックシーケンス(FCS)実装…13A.1 FCS計算メソッド…13 A.2の速いFCSはジェネレータをテーブルの上に置きます…15 セキュリティ問題…16の参照箇所…17の承認…17 議長のアドレス…18エディタのアドレス…18
Simpson [Page 1] RFC 1549 HDLC Framing Decvember 1993
シンプソン[1ページ]RFC1549HDLC縁どりDecvember1993
1. Introduction
1. 序論
This specification provides for framing over both bit-oriented and octet-oriented synchronous links, and asynchronous links with 8 bits of data and no parity. These links MUST be full-duplex, but MAY be either dedicated or circuit-switched. PPP uses HDLC as a basis for the framing.
この仕様はビット指向の、そして、八重奏指向の同期リンクと8ビットのデータとの非同期なリンクの両方にもかかわらず、どんな同等の上でも縁どらないのに提供されます。 これらのリンクは全二重であるに違いありませんが、5月は、捧げられるか、または回路によって切り換えられます。 PPPは縁どりの基礎としてHDLCを使用します。
An escape mechanism is specified to allow control data such as XON/XOFF to be transmitted transparently over the link, and to remove spurious control data which may be injected into the link by intervening hardware and software.
逃避機制は、XON/XOFFなどの制御データが透過的にリンクの上に伝えられて、介入しているハードウェアとソフトウェアでリンクに注がれるかもしれない偽りの制御データを移すのを許容するために指定されます。
Some protocols expect error free transmission, and either provide error detection only on a conditional basis, or do not provide it at all. PPP uses the HDLC Frame Check Sequence for error detection. This is commonly available in hardware implementations, and a software implementation is provided.
いくつかのプロトコルは、エラーのないトランスミッションを予想して、条件付きベースだけで誤り検出を提供するか、またはそれを全く提供しません。 PPPは誤り検出にHDLC Frame Check Sequenceを使用します。 これはハードウェア実装で一般的に利用可能です、そして、ソフトウェア実行を提供します。
1.1 Specification of Requirements
1.1 要件の仕様
In this document, several words are used to signify the requirements of the specification. These words are often capitalized.
本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。
MUST
必須
This word, or the adjective "required", means that the definition
is an absolute requirement of the specification.
「必要である」というこの単語、または形容詞が、定義が仕様に関する絶対条件であることを意味します。
MUST NOT
必須NOT
This phrase means that the definition is an absolute prohibition
of the specification.
この句は、定義が仕様の絶対禁止であることを意味します。
SHOULD
should
This word, or the adjective "recommended", means that there may
exist valid reasons in particular circumstances to ignore this
item, but the full implications must be understood and carefully
weighed before choosing a different course.
「推薦される」というこの単語、または形容詞が、この項目を無視する特定の事情の正当な理由が存在するかもしれないことを意味しますが、完全な含意を理解されて、異なったコースを選ぶ前に、慎重に熟慮しなければなりません。
MAY
5月
This word, or the adjective "optional", means that this item is
one of an allowed set of alternatives. An implementation which
does not include this option MUST be prepared to interoperate with
another implementation which does include the option.
「任意である」というこの単語、または形容詞が、この項目が許容セットの代替手段の1つであることを意味します。 オプションを含んでいる別の実装で共同利用するようにこのオプションを含んでいない実装を準備しなければなりません。
Simpson [Page 2] RFC 1549 HDLC Framing Decvember 1993
シンプソン[2ページ]RFC1549HDLC縁どりDecvember1993
1.2 Terminology
1.2 用語
This document frequently uses the following terms:
このドキュメントは頻繁に次の用語を使用します:
datagram
データグラム
The unit of transmission in the network layer (such as IP). A
datagram may be encapsulated in one or more packets passed to the
data link layer.
ネットワーク層(IPなどの)における、トランスミッションのユニット。 データグラムはデータ・リンク層に通過された1つ以上のパケットでカプセル化されるかもしれません。
frame
フレーム
The unit of transmission at the data link layer. A frame may
include a header and/or a trailer, along with some number of units
of data.
データ・リンク層におけるトランスミッションのユニット。 フレームは何らかの数のユニットのデータに伴うヘッダー、そして/または、トレーラを含むかもしれません。
packet
パケット
The basic unit of encapsulation, which is passed across the
interface between the network layer and the data link layer. A
packet is usually mapped to a frame; the exceptions are when data
link layer fragmentation is being performed, or when multiple
packets are incorporated into a single frame.
カプセル化の原単位。(それは、ネットワーク層とデータ・リンク層とのインタフェースの向こう側に通過されます)。 通常、パケットはフレームに写像されます。 例外はデータ・リンク層断片化がいつ実行されているか、そして、または複数のパケットがいつシングルフレームに法人組織であるかということです。
peer
同輩
The other end of the point-to-point link.
ポイントツーポイント接続のもう一方の端。
silently discard
静かに捨ててください。
This means the implementation discards the packet without further
processing. The implementation SHOULD provide the capability of
logging the error, including the contents of the silently
discarded packet, and SHOULD record the event in a statistics
counter.
これは、実装がさらなる処理なしでパケットを捨てることを意味します。 実装SHOULDは静かに捨てられたパケットのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。
2. Physical Layer Requirements
2. 物理的な層の要件
PPP is capable of operating across most DTE/DCE interfaces (such as, EIA RS-232-C, EIA RS-422, EIA RS-423 and CCITT V.35). The only absolute requirement imposed by PPP is the provision of a full-duplex circuit, either dedicated or circuit-switched, which can operate in either an asynchronous (start/stop), bit-synchronous, or octet- synchronous mode, transparent to PPP Data Link Layer frames.
PPPがほとんどのDTE/DCEインタフェースの向こう側に作動できる、(あれほど、EIA RS232C、EIA RS-422、EIA RS-423、およびCCITT V.35) PPPによって課された唯一の絶対条件がどちらかで非同期な(始め/停止)を操作できる捧げられたか、回路で切り換えられたビット同期の全二重回路か八重奏同期モードに関する条項です、PPP Data Link Layerフレームに、透明です。
Interface Format
インタフェース形式
PPP presents an octet interface to the physical layer. There is
PPPは物理的な層に八重奏インタフェースを提示します。 あります。
Simpson [Page 3] RFC 1549 HDLC Framing Decvember 1993
シンプソン[3ページ]RFC1549HDLC縁どりDecvember1993
no provision for sub-octets to be supplied or accepted.
サブ八重奏を供給するか、または受け入れる支給がありません。
PPP does not impose any restrictions regarding transmission rate,
other than that of the particular DTE/DCE interface.
PPPは特定のDTE/DCEインタフェースのもの以外の通信速度に関する少しの制限も課しません。
Control Signals
制御信号
PPP does not require the use of control signals, such as Request
To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and
Data Terminal Ready (DTR).
PPPは制御信号の使用を必要としません、Request To Send(RTS)や、Clear To Send(CTS)や、Data Carrier Detect(DCD)や、Data Terminal Ready(DTR)などのように。
When available, using such signals can allow greater functionality
and performance. In particular, such signals SHOULD be used to
signal the Up and Down events in the LCP Option Negotiation
Automaton [1]. When such signals are not available, the
implementation MUST signal the Up event to LCP upon
initialization, and SHOULD NOT signal the Down event.
利用可能であるときに、そのような信号を使用すると、より大きい機能性と性能を許容できます。 特に、そのようなものはLCP Option Negotiation AutomatonのUpに合図するのにおいて中古、そして、Downイベントが[1]であったならSHOULDに合図します。 そのような信号が初期化のときに利用可能でないときに、実装はUpイベントをLCPに示さなければなりません、そして、SHOULD NOTはDownイベントに合図します。
Because signalling is not required, the physical layer MAY be
decoupled from the data link layer, hiding the transient details
of the physical transport. This has implications for mobility in
cellular radio networks, and other rapidly switching links.
合図は必要でないので、物理的な層はデータ・リンク層から衝撃を吸収されるかもしれません、物理的な輸送の一時的な詳細を隠して。 これには、セルラジオ放送網における移動性のための意味、および他の急速に切り替わっているリンクがあります。
When moving from cell to cell within the same zone, an
implementation MAY choose to treat the entire zone as a single
link, even though transmission is switched among several
frequencies. The link is considered to be with the central
control unit for the zone, rather than the individual cell
transceivers. However, the link SHOULD re-establish its
configuration whenever the link is switched to a different
administration.
同じゾーンの中でセルからセルまで移行するとき、実装は、単一のリンクとして全体のゾーンを扱うのを選ぶかもしれません、トランスミッションがいくつかの頻度の中で切り換えられますが。 リンクが個別細胞トランシーバーよりむしろゾーンへの集中管理ユニットであると考えられます。 しかしながら、リンクが異なった管理に切り換えられるときはいつも、リンクSHOULDは構成を復職させます。
Due to the bursty nature of data traffic, some implementations
have choosen to disconnect the physical layer during periods of
inactivity, and reconnect when traffic resumes, without informing
the data link layer. Robust implementations should avoid using
this trick over-zealously, since the price for decreased setup
latency is decreased security. Implementations SHOULD signal the
Down event whenever "significant time" has elapsed since the link
was disconnected. The value for "significant time" is a matter of
considerable debate, and is based on the tariffs, call setup
times, and security concerns of the installation.
データ通信量のbursty本質のため、トラフィックが再開すると、いくつかの実装には不活発の期間、物理的な層から切断して、再接続するchoosenがあります、データ・リンク層を知らせないで。 強健な実装は、減少しているセットアップ潜在の価格が減少しているセキュリティであるので過剰熱心にこのトリックを使用するのを避けるべきです。 リンク切断されて以来「重要な時間」が経過しているときはいつも、実装SHOULDはDownイベントに合図します。 「重要な時間」のための値は、かなりの討論の問題であり、関税、呼び出しセットアップ回数、およびインストールの安全上の配慮に基づいています。
3. The Data Link Layer
3. データ・リンク層
PPP uses the principles, terminology, and frame structure of the International Organization For Standardization's (ISO) 3309-1979
PPPは国際標準化機構の(ISO)3309-1979の原則、用語、および枠組構造を使用します。
Simpson [Page 4] RFC 1549 HDLC Framing Decvember 1993
シンプソン[4ページ]RFC1549HDLC縁どりDecvember1993
High-level Data Link Control (HDLC) frame structure [2], as modified by "Addendum 1: Start/stop transmission" [3], which specifies modifications to allow HDLC use in asynchronous environments.
ハイレベルのData Link Control(HDLC)が変更されるとしての構造[2]を縁どっている、「付加物1:」 「始め/停止送信」[3]。(その[3]は、非同期な環境における使用をHDLCに許すために変更を指定します)。
The PPP control procedures use the definitions and Control field encodings standardized in ISO 4335-1979 [4] and ISO 4335- 1979/Addendum 1-1979 [5]. PPP framing is also consistent with CCITT Recommendation X.25 LAPB [6], and CCITT Recommendation Q.922 [7], since those are also based on HDLC.
PPPコントロール手順はISO4335-1979[4]とISO4335- 1979/付加物1-1979[5]で標準化された定義とControl分野encodingsを使用します。 また、PPP縁どりもCCITT Recommendation X.25 LAPB[6]、およびCCITT Recommendation Q.922[7]と一致しています、また、ものがHDLCに基づいているので。
The purpose of this specification is not to document what is already standardized in ISO 3309. It is assumed that the reader is already familiar with HDLC, or has access to a copy of [2] or [6]. Instead, this document attempts to give a concise summary and point out specific options and features used by PPP.
この仕様の目的はISO3309で既に標準化されることを記録しないことです。 読者が既にHDLCになじみ深いか、または[2]か[6]のコピーに近づく手段を持っていると思われます。 代わりに、このドキュメントは、簡潔な概要をして、特定のオプションとPPPによって使用された特徴を指摘するのを試みます。
To remain consistent with standard Internet practice, and avoid confusion for people used to reading RFCs, all binary numbers in the following descriptions are in Most Significant Bit to Least Significant Bit order, reading from left to right, unless otherwise indicated. Note that this is contrary to standard ISO and CCITT practice which orders bits as transmitted (network bit order). Keep this in mind when comparing this document with the international standards documents.
一般的なインターネット習慣と一致していたままで残って、読書RFCsに慣れている人々のために混乱を避けるために、Least Significant Bitオーダーには以下の記述におけるすべての2進の数がMost Significant Bitにあります、左から右まで読んで、別の方法で示されない場合。 これが標準のISOとCCITT習慣に合わないことに注意してください(伝えられるようにビットを配置します)(ネットワークはオーダーに噛み付きました)。 世界規格ドキュメントとこのドキュメントを比べるときにはこれを覚えておいてください。
3.1 Frame Format
3.1 フレーム形式
A summary of the PPP HDLC frame structure is shown below. This figure does not include start/stop bits (for asynchronous links), nor any bits or octets inserted for transparency. The fields are transmitted from left to right.
PPP HDLC枠組構造の概要は以下に示されます。 この図は透明ために挿入されたどんなスタート/ストップ・ビット(非同期なリンクへの)と、ビットや八重奏も入れません。 野原は左から右まで伝えられます。
+----------+----------+----------+
| Flag | Address | Control |
| 01111110 | 11111111 | 00000011 |
+----------+----------+----------+
+----------+-------------+---------+
| Protocol | Information | Padding |
| 16 bits | * | * |
+----------+-------------+---------+
+----------+----------+------------------+
| FCS | Flag | Inter-frame Fill |
| 16 bits | 01111110 | or next Address |
+----------+----------+------------------+
+----------+----------+----------+ | 旗| アドレス| コントロール| | 01111110 | 11111111 | 00000011 | +----------+----------+----------+ +----------+-------------+---------+ | プロトコル| 情報| 詰め物| | 16ビット| * | * | +----------+-------------+---------+ +----------+----------+------------------+ | FCS| 旗| インターフレーム中詰め| | 16ビット| 01111110 | または、次のAddress| +----------+----------+------------------+
The Protocol, Information and Padding fields are described in the Point-to-Point Protocol Encapsulation [1].
プロトコル、情報、およびPadding分野はPointからポイントへのプロトコルEncapsulation[1]で説明されます。
Simpson [Page 5] RFC 1549 HDLC Framing Decvember 1993
シンプソン[5ページ]RFC1549HDLC縁どりDecvember1993
Flag Sequence
フラグ・シーケンス
The Flag Sequence indicates the beginning or end of a frame, and
always consists of the binary sequence 01111110 (hexadecimal
0x7e).
Flag Sequenceはフレームの始めか端を示して、2進の系列01111110(16進0x7e)からいつも成ります。
The Flag Sequence is a frame separator. Only one Flag Sequence is
required between two frames. Two consecutive Flag Sequences
constitute an empty frame, which is ignored, and not counted as a
FCS error.
Flag Sequenceはフレーム分離符です。 1Flag Sequenceだけが2個のフレームの間で必要です。 2連続したFlag Sequencesが空のフレームを設立します。(それは、無視されて、FCS誤りにみなされません)。
Address Field
アドレス・フィールド
The Address field is a single octet and contains the binary
sequence 11111111 (hexadecimal 0xff), the All-Stations address.
PPP does not assign individual station addresses. The All-
Stations address MUST always be recognized and received. The use
of other address lengths and values may be defined at a later
time, or by prior agreement. Frames with unrecognized Addresses
SHOULD be silently discarded.
Address分野は、ただ一つの八重奏であり、2進の系列11111111(16進0xff)、All-駅のアドレスを含んでいます。 PPPは個々のステーションアドレスを割り当てません。 いつもAll駅のアドレスを認識して、受け取らなければなりません。 他のアドレスの長さと値の使用は後で、またはあらかじめ取り決めて定義されるかもしれません。 認識されていないAddresses SHOULDが静かに捨てられているフレーム。
Control Field
制御フィールド
The Control field is a single octet and contains the binary
sequence 00000011 (hexadecimal 0x03), the Unnumbered Information
(UI) command with the P/F bit set to zero. The use of other
Control field values may be defined at a later time, or by prior
agreement. Frames with unrecognized Control field values SHOULD
be silently discarded.
Control分野は、ただ一つの八重奏であり、2進の系列00000011(16進0x03)を含んでいます、ゼロに設定されたP/FビットによるUnnumbered情報(UI)コマンド。 他のControl分野値の使用は後で、またはあらかじめ取り決めて定義されるかもしれません。 認識されていないControl分野値のSHOULDが静かに捨てられているフレーム。
Frame Check Sequence (FCS) Field
フレームチェックシーケンス(FCS)分野
The Frame Check Sequence field is normally 16 bits (two octets).
The use of other FCS lengths may be defined at a later time, or by
prior agreement. The FCS is transmitted with the coefficient of
the highest term first.
通常、Frame Check Sequence分野は16ビット(2つの八重奏)です。 他のFCSの長さの使用は後で、またはあらかじめ取り決めて定義されるかもしれません。 FCSは最初に、最も高い用語の係数で伝えられます。
The FCS field is calculated over all bits of the Address, Control,
Protocol, Information and Padding fields, not including any start
and stop bits (asynchronous) nor any bits (synchronous) or octets
(asynchronous or synchronous) inserted for transparency. This
also does not include the Flag Sequences nor the FCS field itself.
FCS分野はAddress、Control、プロトコル、情報、およびPadding分野のすべてのビットの上計算されます、またはどんなビット(同期)や八重奏(非同期であるか同期の)も透明ために挿入しなかったどんな始めとストップビット(非同期な)も含んでいなくて。 また、これはFlag Sequencesを含んでいません。または、FCS分野自体。
Note: When octets are received which are flagged in the Async-
Control-Character-Map, they are discarded before calculating
the FCS.
以下に注意してください。 八重奏が受け取られているとき、(Async規制キャラクター地図で旗を揚げられます)FCSについて計算する前に、それらは捨てられます。
For more information on the specification of the FCS, see ISO
FCSの仕様の詳しい情報に関しては、ISOを見てください。
Simpson [Page 6] RFC 1549 HDLC Framing Decvember 1993
シンプソン[6ページ]RFC1549HDLC縁どりDecvember1993
3309 [2] or CCITT X.25 [6].
3309[2]かCCITT X.25[6]。
The end of the Information and Padding fields is found by locating the closing Flag Sequence and removing the Frame Check Sequence field.
情報とPadding分野の端は、終わりのFlag Sequenceの場所を見つけて、Frame Check Sequence野原を取り除くことによって、見つけられます。
3.2. Modification of the Basic Frame
3.2. 基本枠の変更
The Link Control Protocol can negotiate modifications to the basic HDLC frame structure. However, modified frames will always be clearly distinguishable from standard frames.
Link Controlプロトコルは基本的なHDLC枠組構造への変更を交渉できます。 しかしながら、変更されたフレームは標準のフレームから区別可能にいつも明確になるでしょう。
Address-and-Control-Field-Compression
アドレスとコントロール分野圧縮
When using the default HDLC framing, the Address and Control
fields contain the hexadecimal values 0xff and 0x03 respectively.
分野が含むデフォルトHDLC縁どり、Address、およびControlを使用するとき、16進はそれぞれ0xffと0×03を評価します。
On transmission, compressed Address and Control fields are formed
by simply omitting them.
トランスミッションのときに、圧縮されたAddressとControl分野は、単にそれらを省略することによって、形成されます。
On reception, the Address and Control fields are decompressed by
examining the first two octets. If they contain the values 0xff
and 0x03, they are assumed to be the Address and Control fields.
If not, it is assumed that the fields were compressed and were not
transmitted.
レセプションでは、AddressとControl分野は、最初の2つの八重奏を調べることによって、減圧されます。 値0xffと0x03を含んでいるなら、それらはAddressとControl分野であると思われます。 そうでなければ、野原が圧縮されて、伝えられなかったと思われます。
By definition, the first octet of a two octet Protocol field will
never be 0xff (since it is not even). The Protocol field value
0x00ff is not allowed (reserved) to avoid ambiguity when
Protocol-Field-Compression is enabled and the first Information
field octet is 0x03.
定義上、2八重奏プロトコル分野の最初の八重奏は決して0xff(それが同等でないので)でないでしょう。 プロトコル分野圧縮が可能にされて、最初の情報分野八重奏が0×03であるときに、プロトコル分野値の0x00ffはあいまいさを避けることができません(予約されます)。
When other Address or Control field values are in use, Address-
and-Control-Field-Compression MUST NOT be negotiated.
Address、他のAddressかControl分野値が使用中である、分野圧縮を制御してください、交渉されてはいけません。
4. Asynchronous HDLC
4. 非同期なHDLC
This section summarizes the use of HDLC with 8-bit asynchronous links.
このセクションは8ビットの非同期なリンクによるHDLCの使用をまとめます。
Flag Sequence
フラグ・シーケンス
The Flag Sequence indicates the beginning or end of a frame. The
octet stream is examined on an octet-by-octet basis for the value
01111110 (hexadecimal 0x7e).
Flag Sequenceはフレームの始めか端を示します。 八重奏の流れは値01111110(16進0x7e)の八重奏による八重奏ベースで調べられます。
Simpson [Page 7] RFC 1549 HDLC Framing Decvember 1993
シンプソン[7ページ]RFC1549HDLC縁どりDecvember1993
Transparency
透明
An octet stuffing procedure is used. The Control Escape octet is
defined as binary 01111101 (hexadecimal 0x7d) where the bit
positions are numbered 87654321 (not 76543210, BEWARE).
八重奏詰め物の手順は使用されています。 Control Escape八重奏はビット位置が番号付の87654321(76543210、BEWAREでない)である2進の01111101(16進0x7d)と定義されます。
Each end of the link maintains two Async-Control-Character-Maps.
The receiving ACCM is 32 bits, but the sending ACCM may be up to
256 bits. This results in four distinct ACCMs, two in each
direction of the link.
リンクの各端は2つのAsync規制キャラクター地図を維持します。 受信ACCMは32ビットですが、発信しているACCMは最大256ビットであるかもしれません。 これは4異なったACCMs、2をリンクの各方向にもたらします。
The default receiving ACCM is 0xffffffff. The default sending
ACCM is 0xffffffff, plus the Control Escape and Flag Sequence
characters themselves, plus whatever other outgoing characters are
known to be intercepted.
ACCMを受けるデフォルトは0xffffffffです。 デフォルト送付ACCMは0xffffffffと、Control Escapeと、Flag Sequenceキャラクタ自体と、他の外向的なキャラクタが妨害されるのが知られていることなら何でもです。
After FCS computation, the transmitter examines the entire frame
between the two Flag Sequences. Each Flag Sequence, Control
Escape octet, and octet with value less than hexadecimal 0x20
which is flagged in the sending Async-Control-Character-Map, is
replaced by a two octet sequence consisting of the Control Escape
octet and the original octet with bit 6 complemented (exclusive-
or'd with hexadecimal 0x20).
FCS計算の後に、送信機は2Flag Sequencesの間の全体のフレームを調べます。 または、各Flag Sequence(Control Escape八重奏、および値が送付Async規制キャラクター地図で旗を揚げられる16進0x20より少ない八重奏)をビット6によるControl Escape八重奏から成る系列とオリジナルの八重奏が補足となった2八重奏に取り替える、(排他的である、16進0x20)で、そうするでしょう。
Prior to FCS computation, the receiver examines the entire frame
between the two Flag Sequences. Each octet with value less than
hexadecimal 0x20 is checked. If it is flagged in the receiving
Async-Control-Character-Map, it is simply removed (it may have
been inserted by intervening data communications equipment). For
each Control Escape octet, that octet is also removed, but bit 6
of the following octet is complemented, unless it is the Flag
Sequence.
FCS計算の前に、受信機は2Flag Sequencesの間の全体のフレームを調べます。 値が16進0x20より少ない各八重奏はチェックされます。 受信Async規制キャラクター地図でそれに旗を揚げさせるなら、単にそれを取り除きます(それはデータ通信装置に介入することによって、挿入されたかもしれません)。 また、それぞれのControl Escape八重奏において、その八重奏を取り除きますが、以下の八重奏のビット6は補足となります、それがFlag Sequenceでないなら。
Note: The inclusion of all octets less than hexadecimal 0x20
allows all ASCII control characters [8] excluding DEL (Delete)
to be transparently communicated through all known data
communications equipment.
以下に注意してください。 16進0x20より少ないすべての八重奏の包含は、すべての知られているデータ通信装置を通って透明にコミュニケートするために、DEL(削除する)を除きながら、すべてのASCII制御文字[8]を許容します。
The transmitter may also send octets with value in the range 0x40
through 0xff (except 0x5e) in Control Escape format. Since these
octet values are not negotiable, this does not solve the problem
of receivers which cannot handle all non-control characters.
Also, since the technique does not affect the 8th bit, this does
not solve problems for communications links that can send only 7-
bit characters.
また、値が範囲0x40にある状態で、送信機は0xff(0x5eを除いた)を通してControl Escape形式で八重奏を送るかもしれません。 これらの八重奏値が交渉可能でないので、これはすべての非制御文字を扱うことができるというわけではない受信機の問題を解決しません。 また、テクニックが8番目のビットに影響しないので、これは7の噛み付いているキャラクタしか送ることができないコミュニケーションリンクへの問題を解決しません。
A few examples may make this more clear. Packet data is
transmitted on the link as follows:
いくつかの例がこの以上を明らかにするかもしれません。 パケットデータは以下のリンクの上に送られます:
Simpson [Page 8] RFC 1549 HDLC Framing Decvember 1993
シンプソン[8ページ]RFC1549HDLC縁どりDecvember1993
0x7e is encoded as 0x7d, 0x5e. 0x7d is encoded as 0x7d, 0x5d.
0x01 is encoded as 0x7d, 0x21.
0x7eは0x7d、0x5eとしてコード化されます。 0x7dは0x7d、0x5dとしてコード化されます。 0×01 0x7d、0×21として、コード化されます。
Some modems with software flow control may intercept outgoing DC1
and DC3 ignoring the 8th (parity) bit. This data would be
transmitted on the link as follows:
ソフトウェア・フロー制御があるいくつかのモデムが8(同等)番目のビットを無視する出発しているDC1とDC3を妨害するかもしれません。 このデータは以下のリンクの上に送られるでしょう:
0x11 is encoded as 0x7d, 0x31. 0x13 is encoded as 0x7d, 0x33.
0x91 is encoded as 0x7d, 0xb1. 0x93 is encoded as 0x7d, 0xb3.
0×11 0x7d、0×31として、コード化されます。 0×13 0x7d、0×33として、コード化されます。 0×91 0x7d、0xb1として、コード化されます。 0×93 0x7d、0xb3として、コード化されます。
Aborting a Transmission
トランスミッションを中止します。
On asynchronous links, frames may be aborted by transmitting a "0"
stop bit where a "1" bit is expected (framing error) or by
transmitting a Control Escape octet followed immediately by a
closing Flag Sequence.
非同期なリンクの上では、フレームがaを伝えることによって中止されるかもしれない、「0インチのストップビット、どこ、「1インチのビットが予想されたか(誤りを縁どっていて)、または伝わることによって、コントロールエスケープ八重奏はすぐ終わりのフラグ・シーケンスで続いたか」。
Time Fill
タイム・フィル
For asynchronous links, inter-octet and inter-frame time fill MUST
be accomplished by transmitting continuous "1" bits (mark-hold
state).
非同期なリンクに関しては、伝える連続した「1インチのビット(マークホールド状態)」で相互八重奏とインターフレームタイム・フィルを実行しなければなりません。
Inter-frame time fill can be viewed as extended inter-octet time
fill. Doing so can save one octet for every frame, decreasing
delay and increasing bandwidth. This is possible since a Flag
Sequence may serve as both a frame close and a frame begin. After
having received any frame, an idle receiver will always be in a
frame begin state.
拡張相互八重奏タイム・フィルとしてインターフレームタイム・フィルを見なすことができます。 遅れを減少させて、帯域幅を増加させて、そうするのは各フレームあたり1つの八重奏を救うことができます。 フレーム閉鎖とフレームの両方が始まるときFlag Sequenceが役立つかもしれないので、これは可能です。 どんなフレームも受けた後に、使用されていない受信機はフレームで状態を始めるためにいつもことになるでしょう。
Robust transmitters should avoid using this trick over-zealously,
since the price for decreased delay is decreased reliability.
Noisy links may cause the receiver to receive garbage characters
and interpret them as part of an incoming frame. If the
transmitter does not send a new opening Flag Sequence before
sending the next frame, then that frame will be appended to the
noise characters causing an invalid frame (with high reliability).
It is suggested that implementations will achieve the best results
by always sending an opening Flag Sequence if the new frame is not
back-to-back with the last. Transmitters SHOULD send an open Flag
Sequence whenever "appreciable time" has elapsed after the prior
closing Flag Sequence. The maximum value for "appreciable time"
is likely to be no greater than the typing rate of a slow typist,
say 1 second.
強健な送信機は、減少している遅れの価格が減少している信頼性であるので過剰熱心にこのトリックを使用するのを避けるはずです。 騒がしいリンクは、受信機が入って来るフレームの一部としてゴミキャラクタを受けて、彼らを解釈することを引き起こすかもしれません。 隣のフレームを送る前に送信機が新しい初めのFlag Sequenceを送らないと、無効のフレーム(高信頼性がある)を引き起こす雑音キャラクタにそのフレームを追加するでしょう。 新しいフレームが獲得しないと実現がいつも初めのFlag Sequenceを送ることによって最も良い結果を獲得することが提案される、背中合わせである、最終で。 「かなりの時間」が先の終わりのFlag Sequenceの後に経過したときはいつも、送信機SHOULDは開いているFlag Sequenceを送ります。 「かなりの時間」のための最大値は遅いタイピストのタイプよりレートである傾向があり、1 2番目を言ってください。
Encoding
コード化
All octets are transmitted with one start bit, eight bits of data,
すべての八重奏が1つのスタートビット、8ビットのデータで伝えられます。
Simpson [Page 9] RFC 1549 HDLC Framing Decvember 1993
シンプソン[9ページ]RFC1549HDLC縁どりDecvember1993
and one stop bit. There is no provision for seven bit
asynchronous links.
そして、1つのストップビット。 7ビットの非同期なリンクへの支給が全くありません。
5. Bit-synchronous HDLC
5. ビット同期のHDLC
This section summarizes the use of HDLC with bit-synchronous links.
このセクションはビット同期のリンクによるHDLCの使用をまとめます。
Flag Sequence
フラグ・シーケンス
The Flag Sequence indicates the beginning or end of a frame, and
is used for frame synchronization. The bit stream is examined on
a bit-by-bit basis for the binary sequence 01111110 (hexadecimal
0x7e).
Flag Sequenceはフレームの始めか端を示して、フレーム同期化に使用されます。 ビットストリームは2進の系列01111110(16進0x7e)ビットしばらくベースで調べられます。
The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT
be used. When not avoidable, such an implementation MUST ensure
that the first Flag Sequence detected (the end of the frame) is
promptly communicated to the link layer. Use of the shared zero
mode hinders interoperability with synchronous-to-asynchronous
converters.
「共有されて、モードのゼロを合わせてください」というFlag Sequence「011111101111110」を使用するべきではありません。 回避可能でないときに、そのような実現は、Flag Sequenceが検出した1(フレームの端)番目が即座にリンクレイヤに伝えられるのを確実にしなければなりません。 共有の使用はモードのゼロに合っています。非同期であるのと同期のコンバータで相互運用性を妨げます。
Transparency
透明
The transmitter examines the entire frame between the two Flag
Sequences. A "0" bit is inserted after all sequences of five
contiguous "1" bits (including the last 5 bits of the FCS) to
ensure that a Flag Sequence is not simulated.
送信機は2Flag Sequencesの間の全体のフレームを調べます。 0インチビットは5のすべての系列の後に挿入されます。「隣接の「フラグ・シーケンスがシミュレートされないのを保証する1インチのビット(最後の5ビットのFCSを含んでいます)。」
When receiving, any "0" bit that directly follows five contiguous
"1" bits is discarded.
いくらか受信する、「0インチ尾行fiveそんなに直接「ビットは何1インチも、捨てられます」隣接の噛み付いている。
Since the Control Escape octet-stuffing method is not used, the
default receiving and sending Async-Control-Character-Maps are 0.
八重奏を詰めるControl Escape方法が使用されていないので、デフォルト受信と送付Async規制キャラクター地図は0です。
There may be some use of synchronous-to-asynchronous converters
(some built into modems) in point-to-point links resulting in a
synchronous PPP implementation on one end of a link and an
asynchronous implementation on the other. It is the
responsibility of the converter to do all mapping conversions
during operation.
指すポイントの非同期であるのと同期のコンバータ(モデムが組み込まれたいくつか)リンクのもう片方でリンクと非同期な実現の片端で同期PPP実現をもたらす何らかの使用があるかもしれません。 操作の間、すべてのマッピング変換をするのは、コンバータの責任です。
To enable this functionality, bit-synchronous PPP implementations
MUST always respond to the Async-Control-Character-Map
Configuration Option with an LCP Configure-Ack. However,
acceptance of the Configuration Option does not imply that the
bit-synchronous implementation will do any octet mapping.
Instead, all such octet mapping will be performed by the
asynchronous-to-synchronous converter.
この機能性を可能にするために、ビット同期のPPP実現はLCP Configure-Ackと共にAsync規制キャラクター地図Configuration Optionにいつも応じなければなりません。 しかしながら、Configuration Optionの承認は、ビット同期の実現がどんな八重奏マッピングもするのを含意しません。 代わりに、そのようなすべての八重奏マッピングが同期変流機への非同期によって実行されるでしょう。
Simpson [Page 10] RFC 1549 HDLC Framing Decvember 1993
シンプソン[10ページ]RFC1549HDLC縁どりDecvember1993
Aborting a Transmission
トランスミッションを中止します。
A sequence of more than six "1" bits indicates an invalid frame,
which is ignored, and not counted as a FCS error.
6以上「1インチの無視される無効のフレームを示している、FCSにみなされなかったビット誤り」の系列。
Inter-frame Time Fill
インターフレームタイム・フィル
For bit-synchronous links, the Flag Sequence SHOULD be transmitted
during inter-frame time fill. There is no provision for inter-
octet time fill.
ビット同期のリンク、Flag Sequence SHOULD、インターフレームタイム・フィルの間、伝えられてください。 相互八重奏タイム・フィルへの支給が全くありません。
Mark idle (continuous ones) SHOULD NOT be used for inter-frame
ill. However, certain types of circuit-switched links require the
use of mark idle, particularly those that calculate accounting
based on periods of bit activity. When mark idle is used on a
bit-synchronous link, the implementation MUST ensure at least 15
consecutive "1" bits between Flags during the idle period, and
that the Flag Sequence is always generated at the beginning of a
frame after an idle period.
(連続したもの)使用されていないSHOULD NOTをマークしてください。インターフレームのために、ほとんど使用されません。 しかしながら、あるタイプのサーキットで切り換えられたリンクは活動していない状態でマークの使用を必要とします、特に噛み付いている活動の一区切りに基づいて会計について計算するもの。 マークがいつ怠けるかは少し同期のリンクの上に使用されて、実現は少なくとも15連続した「活動していない期間、およびそれの間の活動していない期間の後のフレームの始まりのフラグ・シーケンスがいつも発生する旗の間の1インチのビット」を確実にしなければなりません。
Encoding
コード化
The definition of various encodings and scrambling is the
responsibility of the DTE/DCE equipment in use, and is outside the
scope of this specification.
様々なencodingsとよじ登ることの定義は、使用中のDTE/DCE設備の責任であり、この仕様の範囲の外にあります。
While PPP will operate without regard to the underlying
representation of the bit stream, lack of standards for
transmission will hinder interoperability as surely as lack of
data link standards. At speeds of 56 Kbps through 2.0 Mbps, NRZ
is currently most widely available, and on that basis is
recommended as a default.
PPPが関係なしでビットストリームの基底表示に作動している間、トランスミッションのための標準の欠如は資料不足リンク規格と同じくらい確実に相互運用性を妨げるでしょう。 2.0Mbpsを通した56Kbpsの速度では、NRZは現在、最も広く利用可能であり、デフォルトとしてそのような方式でお勧めです。
When configuration of the encoding is allowed, NRZI is recommended
as an alternative, because of its relative immunity to signal
inversion configuration errors, and instances when it MAY allow
connection without an expensive DSU/CSU. Unfortunately, NRZI
encoding obviates the (1 + x) factor of the 16-bit FCS, so that
one error in 2**15 goes undetected (instead of one in 2**16), and
triple errors are not detected. Therefore, when NRZI is in use,
it is recommended that the 32-bit FCS be negotiated, which does
not include the (1 + x) factor.
コード化の構成が許されているとき、NRZIは代替手段としてお勧めです、高価なDSU/CSUなしで接続を許すとき逆構成誤り、および例に合図する部分的免疫のために。 残念ながら、NRZIコード化は16ビットのFCSの(1+x)要素を取り除きます、2**15の1つの誤りが察知されずにいて(2**16の1の代わりに)、三重の誤りが検出されないように。 したがって、NRZIが使用中であるときに、32ビットのFCSが交渉されるのは、お勧めです((1+x)要素を含んでいません)。
At higher speeds of up to 45 Mbps, some implementors have chosen
the ANSI High Speed Synchronous Interface [HSSI]. While this
experience is currently limited, implementors are encouraged to
cooperate in choosing transmission encoding.
最大45Mbpsの、より高い速度では、ANSI High Speed Synchronous Interface[HSSI]を選んだ作成者もいました。 この経験は現在制限されますが、作成者がトランスミッションコード化を選ぶのに協力するよう奨励されます。
Simpson [Page 11] RFC 1549 HDLC Framing Decvember 1993
シンプソン[11ページ]RFC1549HDLC縁どりDecvember1993
6. Octet-synchronous HDLC
6. 八重奏同期のHDLC
This section summarizes the use of HDLC with octet-synchronous links, such as SONET and optionally ISDN B or H channels.
このセクションはSonetなどの八重奏同期のリンクによるHDLCの使用をまとめます、そして、任意に、ISDN BかHは精神を集中します。
Although the bit rate is synchronous, there is no bit-stuffing. Instead, the octet-stuffing feature of 8-bit asynchronous HDLC is used.
ビット伝送速度は同時ですが、ビット・スタッフィングが全くありません。 代わりに、8ビットの非同期なHDLCの八重奏を詰める特徴は使用されています。
Flag Sequence
フラグ・シーケンス
The Flag Sequence indicates the beginning or end of a frame. The
octet stream is examined on an octet-by-octet basis for the value
01111110 (hexadecimal 0x7e).
Flag Sequenceはフレームの始めか端を示します。 八重奏の流れは値01111110(16進0x7e)の八重奏による八重奏ベースで調べられます。
Transparency
透明
An octet stuffing procedure is used. The Control Escape octet is
defined as binary 01111101 (hexadecimal 0x7d).
八重奏詰め物の手順は使用されています。 Control Escape八重奏は2進の01111101(16進0x7d)と定義されます。
The octet stuffing procedure is described in "Asynchronous HDLC"
above.
八重奏詰め物の手順は上の「非同期なHDLC」で説明されます。
The sending and receiving implementations need escape only the
Flag Sequence and Control Escape octets.
実現が必要とする発信と受信はFlag SequenceとControl Escape八重奏だけから逃げます。
Considerations concerning the use of converters are described in
"Bit-synchronous HDLC" above.
コンバータの使用に関する問題は上の「ビット同期のHDLC」で説明されます。
Aborting a Transmission
トランスミッションを中止します。
Frames may be aborted by transmitting a Control Escape octet
followed immediately by a closing Flag Sequence. The preceding
frame is ignored, and not counted as a FCS error.
フレームは、すぐ終わりのFlag Sequenceによって続かれたControl Escape八重奏を伝えることによって、中止されるかもしれません。 前のフレームは、無視されて、FCS誤りにみなされません。
Inter-frame Time Fill
インターフレームタイム・フィル
The Flag Sequence MUST be transmitted during inter-frame time
fill. There is no provision for inter-octet time fill.
インターフレームタイム・フィルの間、Flag Sequenceを伝えなければなりません。 相互八重奏タイム・フィルへの支給が全くありません。
Encoding
コード化
The definition of various encodings and scrambling is the
responsibility of the DTE/DCE equipment in use, and is outside the
scope of this specification.
様々なencodingsとよじ登ることの定義は、使用中のDTE/DCE設備の責任であり、この仕様の範囲の外にあります。
Simpson [Page 12] RFC 1549 HDLC Framing Decvember 1993
シンプソン[12ページ]RFC1549HDLC縁どりDecvember1993
A. Fast Frame Check Sequence (FCS) Implementation
A。 速いフレームチェックシーケンス(FCS)実現
The FCS was originally designed with hardware implementations in mind. A serial bit stream is transmitted on the wire, the FCS is calculated over the serial data as it goes out, and the complement of the resulting FCS is appended to the serial stream, followed by the Flag Sequence.
FCSは元々、ハードウェア実装で念頭に設計されました。 ワイヤの上に連続のビットストリームを伝えて、出かけて、Flag Sequenceによって続かれた連続の流れに結果として起こるFCSの補数を追加するとき、シリアルデータに関してFCSについて計算します。
The receiver has no way of determining that it has finished calculating the received FCS until it detects the Flag Sequence. Therefore, the FCS was designed so that a particular pattern results when the FCS operation passes over the complemented FCS. A good frame is indicated by this "good FCS" value.
受信機には、Flag Sequenceを検出するまで容認されたFCSについて計算し終えたことを決定する方法が全くありません。 したがって、FCSは、FCS操作が補足となっているFCSを通り過ぎると特定のパターンが結果として生じるように、設計されました。 良いフレームはこの「良いFCS」値によって示されます。
A.1 FCS Computation Method
A.1 FCS計算方法
The following code provides a table lookup computation for calculating the Frame Check Sequence as data arrives at the interface. This implementation is based on [9], [10], and [11]. The table is created by the code in section B.2.
以下のコードはデータがインタフェースに到着するのでFrame Check Sequenceについて計算するための索表計算を提供します。 この実現は[9]、[10]、および[11]に基づいています。 テーブルはセクションB.2のコードによって作成されます。
Simpson [Page 13] RFC 1549 HDLC Framing Decvember 1993
シンプソン[13ページ]RFC1549HDLC縁どりDecvember1993
/* * u16 represents an unsigned 16-bit number. Adjust the typedef for * your hardware. */ typedef unsigned short u16;
/**u16は無記名の16ビットの数を表します。 *のためにtypedefを調整してください。あなたのハードウェア。 */typedef無記名の短いu16。
/*
* FCS lookup table as calculated by the table generator in section B.2
*/
static u16 fcstab[256] = {
0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf,
0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7,
0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e,
0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876,
0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd,
0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5,
0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c,
0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974,
0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb,
0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3,
0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a,
0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72,
0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9,
0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1,
0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738,
0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70,
0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7,
0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff,
0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036,
0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e,
0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5,
0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd,
0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134,
0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c,
0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3,
0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb,
0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232,
0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a,
0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1,
0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9,
0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330,
0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78
};
計算されるとしてのセクションBのテーブルジェネレータによる/**FCSルックアップ表; 2の*/静的なu16 fcstab256が等しい、0×0000 0×1189 0×2312 0x329b、0×4624、0x57ad、0×6536、0x74bf、0x8c48、0x9dc1、0xaf5a、0xbed3、0xca6c、0xdbe5、0xe97e、0xf8f7、0×1081、0×0108、0×3393、0x221a、0x56a5、0x472c、0x75b7、0x643e、0x9cc9、0x8d40、0xbfdb、0xae52、0xdaed、0xcb64、0xf9ff、0xe876、0×2102、0x308b、0×0210、0×1399、0×6726、0x76af、0×4434、0x55bd、0xad4a、0xbcc3、0x8e58、0x9fd1、0xeb6e、0xfae7、0xc87c、0xd9f5、0×3183、0x200a、0×1291、0×0318、0x77a7、0x662e、0x54b5; 0x453c、0xbdcb、0xac42、0x9ed9、0x8f50、0xfbef、0xea66、0xd8fd、0xc974、0×4204、0x538d、0×6116、0x709f、0×0420、0x15a9、0×2732、0x36bb、0xce4c、0xdfc5、0xed5e、0xfcd7、0×8868、0x99e1、0xab7a、0xbaf3、0×5285、0x430c、0×7197、0x601e、0x14a1、0×0528、0x37b3、0x263a、0xdecd、0xcf44、0xfddf、0xec56、0x98e9、0×8960、0xbbfb、0xaa72、0×6306、0x728f、0×4014、0x519d、0×2522、0x34ab、0×0630、0x17b9、0xef4e、0xfec7、0xcc5c、0xddd5、0xa96a、0xb8e3、0x8a78、0x9bf1、0×7387、0x620e、0x5095、0x411c、0x35a3、0x242a、0x16b1、0×0738、0xffcf、0xee46、0xdcdd、0xcd54、0xb9eb、0xa862、0x9af9、0x8b70、0×8408、0×9581、0xa71a、0xb693、0xc22c、0xd3a5、0xe13e、0xf0b7、0×0840、0x19c9、0x2b52、0x3adb、0x4e64、0x5fed、0x6d76、0x7cff、0×9489、0×8500、0xb79b、0xa612、0xd2ad、0xc324、0xf1bf、0xe036、0x18c1、0×0948、0x3bd3、0x2a5a、0x5ee5、0x4f6c、0x7df7、0x6c7e、0xa50a、0xb483、0×8618、0×9791、0xe32e、0xf2a7、0xc03c、0xd1b5、0×2942、0x38cb、0x0a50、0x1bd9、0x6f66、0x7eef、0x4c74、0x5dfd、0xb58b、0xa402; 0×9699 0×8710 0xf3af、0xe226、0xd0bd、0xc134、0x39c3、0x284a、0x1ad1、0x0b58、0x7fe7、0x6e6e、0x5cf5、0x4d7c、0xc60c、0xd785、0xe51e、0xf497、0×8028、0x91a1、0xa33a、0xb2b3、0x4a44、0x5bcd、0×6956、0x78df、0x0c60、0x1de9、0x2f72、0x3efb、0xd68d、0xc704; 0xf59f、0xe416、0x90a9、0×8120、0xb3bb、0xa232、0x5ac5、0x4b4c、0x79d7、0x685e、0x1ce1、0x0d68、0x3ff3、0x2e7a、0xe70e、0xf687、0xc41c、0xd595、0xa12a、0xb0a3、0×8238、0x93b1、0x6b46、0x7acf、0×4854、0x59dd、0x2d62、0x3ceb、0x0e70、0x1ff9、0xf78f、0xe606、0xd49d、0xc514、0xb1ab、0xa022、0x92b9、0×8330、0x7bc7、0x6a4e、0x58d5、0x495c、0x3de3、0x2c6a、0x1ef1、0x0f78、。
#define PPPINITFCS16 0xffff /* Initial FCS value */ #define PPPGOODFCS16 0xf0b8 /* Good final FCS value */
#定義、PPPINITFCS16 0xffff/*初期のFCS値*/#、はPPPGOODFCS16 0xf0b8/*良い最終的なFCS値*/を定義します。
/*
/*
Simpson [Page 14] RFC 1549 HDLC Framing Decvember 1993
シンプソン[14ページ]RFC1549HDLC縁どりDecvember1993
* Calculate a new fcs given the current fcs and the new data.
*/
u16 pppfcs16(fcs, cp, len)
register u16 fcs;
register unsigned char *cp;
register int len;
{
ASSERT(sizeof (u16) == 2);
ASSERT(((u16) -1) > 0);
while (len--)
fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff];
* 現在のfcsと新しいデータを考えて、新しいfcsについて計算してください。 */u16 pppfcs16(fcs、cp、len)レジスタu16 fcs。 無記名の炭*cpを登録してください。 int lenを登録してください。 ASSERT(sizeof(u16)=2)(ASSERT(((u16)-1)>0))がゆったり過ごす、(len--、)、fcsは^fcstab[(fcs^ *cp++)と0xff]と等しいです(>>8をfcsします)。
return (fcs);
}
戻ってください(fcs)。 }
/*
* How to use the fcs
*/
tryfcs16(cp, len)
register unsigned char *cp;
register int len;
{
u16 trialfcs;
fcs*/tryfcs16を使用するために、(cp、len)が無記名で登録される/**は*cpを炭にします。 int lenを登録してください。 u16 trialfcs。
/* add on output */
trialfcs = pppfcs16( PPPINITFCS16, cp, len );
trialfcs ^= 0xffff; /* complement */
cp[len] = (trialfcs & 0x00ff); /* least significant byte first */
cp[len+1] = ((trialfcs >> 8) & 0x00ff);
/*は出力*/trialfcs=pppfcs16(PPPINITFCS16、cp、len)を加えます。 trialfcs^は0xffffと等しいです。 /*補数*/cp[len]は(trialfcsと0x00ff)と等しいです。 最初に、/*最も重要でないバイト*/cp[len+1]は((trialfcs>>8)と0x00ff)と等しいです。
/* check on input */
trialfcs = pppfcs16( PPPINITFCS16, cp, len + 2 );
if ( trialfcs == PPPGOODFCS16 )
printf("Good FCS0);
}
入力*/trialfcsの/*チェックはpppfcs16(PPPINITFCS16、cp、len+2)と等しいです。 (trialfcs=PPPGOODFCS16)printfである、(「良いFCS0)」、。 }
A.2. Fast FCS table generator
A.2。 速いFCSテーブルジェネレータ
The following code creates the lookup table used to calculate the FCS.
以下のコードはFCSについて計算するのに使用されるルックアップ表を作成します。
Simpson [Page 15] RFC 1549 HDLC Framing Decvember 1993
シンプソン[15ページ]RFC1549HDLC縁どりDecvember1993
/* * Generate a FCS table for the HDLC FCS. * * Drew D. Perkins at Carnegie Mellon University. * * Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier. */
/**はHDLC FCSのためにFCSテーブルを発生させます。 * * カーネギーメロン大学のドリュー・D.パーキンス。 * * コードはモホセンBananとD.ヒューRedelmeierから気前よく借りました。 */
/* * The HDLC polynomial: x**0 + x**5 + x**12 + x**16 (0x8408). */ #define P 0x8408
/**、HDLC多項式: x**0+x**5+x**12+x**16(0×8408)。 */#はP0x8408を定義します。
main()
{
register unsigned int b, v;
register int i;
メイン()、無記名のint b、vを登録してください; int iを登録してください。
printf("typedef unsigned short u16;0);
printf("static u16 fcstab[256] = {");
for (b = 0; ; ) {
if (b % 8 == 0)
printf("0);
printf、(「typedefの無記名の短いu16;、0)、」、。 printf、(「静的なu16 fcstab[256]が等しい、「)、(b=0)、(b%8 == 0)printfである、(「0)」。
v = b;
for (i = 8; i--; )
v = v & 1 ? (v >> 1) ^ P : v >> 1;
v=b。 =vと1? (>>1に対する)^Pに対する(i=8(i))のために: v>>1。
printf("0x%04x", v & 0xFFFF);
if (++b == 256)
break;
printf(",");
}
printf("0;0);
}
printf(「0x%04x」、v、および0xFFFF)。 (+ + b=256)が壊れるなら。 printf、(「」、)、。 printf、(「0;0)」、。 }
Security Considerations
セキュリティ問題
As noted in the Physical Layer Requirements section, the link layer might not be informed when the connected state of physical layer is changed. This results in possible security lapses due to over- reliance on the integrity and security of switching systems and administrations. An insertion attack might be undetected. An attacker which is able to spoof the same calling identity might be able to avoid link authentication.
Physical Layer Requirements部で注意されるように、リンクレイヤは物理的な層の関連状態がいつ変えられるかを知らされないかもしれません。 これは交換システムと政権の保全とセキュリティへの過剰信用のため可能なセキュリティ過失をもたらします。 挿入攻撃は非検出されるかもしれません。 アイデンティティと呼びながら同じようにだますことができる攻撃者はリンク認証を避けることができるかもしれません。
Simpson [Page 16] RFC 1549 HDLC Framing Decvember 1993
シンプソン[16ページ]RFC1549HDLC縁どりDecvember1993
References
参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
RFC 1548, December 1993
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、RFC1548、1993年12月
[2] International Organization For Standardization, ISO Standard
3309-1979, "Data communication - High-level data link control
procedures - Frame structure", 1979.
[2]国際標準化機構、ISO Standard3309-1979、「データ通信--ハイレベル・データリンク制御手順--枠組構造」、1979。
[3] International Organization For Standardization, Proposed Draft
International Standard ISO 3309-1991/PDAD1, "Information
processing systems - Data communication - High-level data link
control procedures - Frame structure - Addendum 1: Start/stop
transmission", 1991.
[3]国際標準化機構、Proposed国際規格案ISO3309-1991/PDAD1、「情報処理システム--データ通信--ハイレベル・データリンク制御手順--枠組構造--付加物1:、」 「始め/停止送信」、1991。
[4] International Organization For Standardization, ISO Standard
4335-1979, "Data communication - High-level data link control
procedures - Elements of procedures", 1979.
[4]国際標準化機構、ISO Standard4335-1979、「データ通信--ハイレベル・データリンク制御手順--手順のElements」1979。
[5] International Organization For Standardization, ISO Standard
4335-1979/Addendum 1, "Data communication - High-level data
link control procedures - Elements of procedures - Addendum 1",
1979.
[5]国際標準化機構、ISO Standard4335-1979/付加物1、「データ通信--ハイレベル・データリンク制御手順--手順のElements--付加物1インチ、1979。」
[6] International Telecommunication Union, CCITT Recommendation
X.25, "Interface Between Data Terminal Equipment (DTE) and Data
Circuit Terminating Equipment (DCE) for Terminals Operating in
the Packet Mode on Public Data Networks", CCITT Red Book,
Volume VIII, Fascicle VIII.3, Rec. X.25., October 1984.
[6] 国際電気通信連合、CCITT推薦X.25は「公共のデータ網がパケット形態で作動して、データ端末装置(DTE)とデータ回線終端装置(DCE)の間で端末に連結します」、CCITT職員録、巻VIII、分冊VIII.3、Rec。 X.25、10月1984日
[7] International Telegraph and Telephone Consultative Committee,
CCITT Recommendation Q.922, "ISDN Data Link Layer Specification
for Frame Mode Bearer Services", April 1991.
[7]国際電信電話諮問委員会、CCITT推薦Q.922、「フレーム方式運搬人サービスのためのISDNデータ・リンク層仕様」、1991年4月。
[8] American National Standards Institute, ANSI X3.4-1977,
"American National Standard Code for Information Interchange",
1977.
[8]American National Standards Institut、ANSI X3.4-1977、「情報交換用米国標準コード」1977。
[9] Perez, "Byte-wise CRC Calculations", IEEE Micro, June, 1983.
[9] ペレス、「バイト的なCRC計算」、IEEEミクロ、1983年6月。
[10] Morse, G., "Calculating CRC's by Bits and Bytes", Byte,
September 1986.
[10] モース、G.、「ビットとバイトの計算のCRCのもの」、バイト、1986年9月。
[11] LeVan, J., "A Fast CRC", Byte, November 1987.
1987年11月の[11] レバン、J.、「速いCRC」バイト。
Acknowledgments
承認
This specification is based on previous RFCs, where many
この仕様は多くであるところで前のRFCsに基づいています。
Simpson [Page 17] RFC 1549 HDLC Framing Decvember 1993
シンプソン[17ページ]RFC1549HDLC縁どりDecvember1993
contributions have been acknowleged.
貢献はacknowlegedされました。
Additional implementation detail for this version was provided by Fred Baker (ACC), Craig Fox (NSC), and Phil Karn (Qualcomm).
このバージョンのための追加実現詳細はフレッド・ベイカー(ACC)、クレイグフォックス(NSC)、およびフィルKarn(クアルコム)によって明らかにされました。
Special thanks to Morning Star Technologies for providing computing resources and network access support for writing this specification.
コンピューティング資源とネットワークアクセスを提供するためのMorning Star Technologiesへの特別な感謝は書くことのためにこの仕様を支持します。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California, 93111
Driveサンタバーバラ、フレッド・ベイカー・高度なコンピュータコミュニケーション315Bollayカリフォルニア 93111
EMail: fbaker@acc.com
メール: fbaker@acc.com
Editor's Address
エディタのアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
ミシガン ウィリアムアレンのシンプソン空想家コンピュータシステムズのコンサルタント業務1384フォンテーヌマディソンの高さ、48071
EMail: Bill.Simpson@um.cc.umich.edu
メール: Bill.Simpson@um.cc.umich.edu
Simpson [Page 18]
シンプソン[18ページ]
一覧
スポンサーリンク
