RFC1618 日本語訳
1618 PPP over ISDN. W. Simpson. May 1994. (Format: TXT=14896 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Simpson Request for Comments: 1618 Daydreamer Category: Standards Track May 1994
コメントを求めるワーキンググループW.シンプソン要求をネットワークでつないでください: 1618年の空想家カテゴリ: 標準化過程1994年5月
PPP over ISDN
ISDNの上の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. This document describes the use of PPP over Integrated Services Digital Network (ISDN) switched circuits.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。 このドキュメントはIntegrated Services Digital Network(ISDN)交換回線網の上でPPPの使用について説明します。
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@merit.edu mailing list.
このドキュメントはPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。 ietf-ppp@merit.edu メーリングリストにコメントを提出するべきです。
Applicability
適用性
This specification is intended for those implementations which desire to use the PPP encapsulation over ISDN point-to-point links. PPP is not designed for multi-point or multi-access environments.
この仕様はISDNポイントツーポイント接続の上でPPPカプセル化を使用することを望んでいるそれらの実現のために意図します。 PPPはマルチポイントかマルチアクセス環境のために設計されていません。
"It is clear that there is never likely to be a single, monolithic, worldwide ISDN." [3] The goal of this document is to describe a few common implementations, chosen from the current wide variety of alternatives, in an effort to promote interoperability.
「単一の、そして、一枚岩的で、世界的なISDNが決してありそうにないのは、明確です。」 [3] このドキュメントの目標は相互運用性を促進するための努力で現在の広いバラエティーの代替手段から選ばれたいくつかの一般的な実現について説明することです。
Simpson [Page i] RFC 1618 PPP over ISDN May 1994
ISDN1994年5月の上のシンプソン[ページi]RFC1618PPP
Table of Contents
目次
1. Introduction .......................................... 1
1. 序論… 1
2. Physical Layer Requirements ........................... 1
2. 物理的な層の要件… 1
3. Framing ............................................... 3
3. 縁どっています。 3
4. Out-of-Band signaling ................................. 4
4. バンドで出ているシグナリング… 4
5. Configuration Details ................................. 5
5. 構成の詳細… 5
SECURITY CONSIDERATIONS ...................................... 5
セキュリティ問題… 5
REFERENCES ................................................... 5
参照… 5
ACKNOWLEDGEMENTS ............................................. 6
承認… 6
CHAIR'S ADDRESS .............................................. 6
議長のアドレス… 6
AUTHOR'S ADDRESS ............................................. 6
作者のアドレス… 6
Simpson [Page ii] RFC 1618 PPP over ISDN May 1994
ISDN1994年5月の上のシンプソン[ページii]RFC1618PPP
1. Introduction
1. 序論
PPP was designed as a standard method of communicating over point- to-point links. Initial deployment has been over short local lines, leased lines, and plain-old-telephone-service (POTS) using modems. As new packet services and higher speed lines are introduced, PPP is easily deployed in these environments as well.
PPPはポイントへのポイントの上のリンクを伝える標準方法として設計されました。 短いローカル線、専用線、および明瞭な古い電話サービス(POTS)の上に初期の展開が、モデムを使用することでありました。新しいパケットサービスと、より高い速度線が紹介されるとき、PPPはまた、これらの環境で容易に配備されます。
This specification is primarily concerned with the use of the PPP encapsulation over ISDN links. Since the ISDN B-channel is by definition a point-to-point circuit, PPP is well suited to use over these links.
ISDNリンクに関してPPPカプセル化の使用にこの仕様を主として心配させます。 ISDN Bチャネルが定義上二地点間サーキットであるので、PPPはこれらのリンクの上の使用によく合っています。
The ISDN Primary Rate Interface (PRI) may support many concurrent B- channel links. The PPP LCP and NCP mechanisms are particularly useful in this situation in reducing or eliminating hand configuration, and facilitating ease of communication between diverse implementations.
ISDN Primary Rate Interface(PRI)は多くの同時発生のBチャンネルリンクを支えるかもしれません。 PPP LCPとNCPメカニズムは手の構成を減少するか、または排除して、さまざまの実現のコミュニケーションの容易さを容易にする際に特にこの状況で役に立ちます。
The ISDN D-channel can also be used for sending PPP packets when suitably framed, but is limited in bandwidth and often restricts communication links to a local switch.
ISDN Dチャネルは、また、適当に縁どられると送付PPPパケットに使用できますが、帯域幅で制限されて、しばしば通信リンクを地方のスイッチに制限します。
The terminology of ISDN can be confusing. Here is a simple graphical representation of the points used in subsequent descriptions:
ISDNの用語は混乱させられることができます。 ここに、その後の記述に使用されるポイントの簡単なグラフ表示があります:
+-------+ +-------+ +-------+
R | | S | | T | | U
+---+ TA +--+--+ NT2 +--+--+ NT1 +---+
| | | | | |
+-------+ +-------+ +-------+
+-------+ +-------+ +-------+ R| | S| | T| | U+---+ +--+--+ バイバイ、NT2+--+--+ NT1+---+ | | | | | | +-------+ +-------+ +-------+
These elements are frequently combined into a single device.
これらの要素は頻繁に単一の装置に結合されます。
2. Physical Layer Requirements
2. 物理的な層の要件
PPP treats ISDN channels as bit or octet oriented synchronous links. These links MUST be full-duplex, but MAY be either dedicated or circuit-switched.
PPPが噛み付かれるようにISDNチャンネルを扱うか、または八重奏は同期リンクを適応させました。 これらのリンクは全二重であるに違いありませんが、5月は、捧げられるか、またはサーキットによって切り換えられます。
Interface Format
インタフェース形式
PPP presents an octet interface to the physical layer. There is
no provision for sub-octets to be supplied or accepted. The octet
stream is applied primarily at the R or T reference points.
PPPは物理的な層に八重奏インタフェースを提示します。 サブ八重奏を供給するか、または受け入れるために、支給は全くありません。 八重奏の流れは主としてRかT基準点で適用されます。
Simpson [Page 1]
ISDN1994年5月の上のシンプソン[1ページ]RFC1618ppp
Transmission Rate
通信速度
PPP does not impose any restrictions regarding transmission rate,
other than that of the particular ISDN channel interface.
PPPは特定のISDNチャンネル・インタフェースのもの以外の通信速度に関する少しの制限も課しません。
Control Signals
制御信号
PPP does not require the use of control signals. When available,
using such signals can allow greater functionality and
performance. Implications are discussed in [2].
PPPは制御信号の使用を必要としません。 利用可能であるときに、そのような信号を使用すると、より大きい機能性と性能を許容できます。 [2]で含意について議論します。
Control signals MAY be required by some of the framing techniques
described, and is outside the scope of this specification.
信号がそうするコントロールは、テクニックが説明した縁どりのいくつかで必要であり、この仕様の範囲の外にあります。
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. The D-channel LAPD interface requires NRZ
encoding at the T reference point. Therefore, as a default, it is
recommended that NRZ be used over the B-channel interface at the T
reference point. This will allow frames to be easily exchanged
between the B and D channels.
PPPが関係なしでビットストリームの基底表示に作動している間、トランスミッションのための標準の欠如は資料不足リンク規格と同じくらい確実に相互運用性を妨げるでしょう。 DチャネルLAPDインタフェースはTで参照ポイントをコード化するNRZを必要とします。 したがって、デフォルトとして、NRZがBチャネルインタフェースの上でT基準点に使用されるのは、お勧めです。 これは、フレームがBとDチャネルの間で容易に交換されるのを許容するでしょう。
When configuration of the encoding is allowed, NRZI is recommended
as an alternative in order to ensure a minimum ones density where
required over the clear B-channel, with caveats regarding FCS [2].
コード化の構成が許されているとき、NRZIは明確なBチャネルに関して必要であるどこをもの最小の密度に確実にするかために代替手段としてお勧めです、警告がFCS[2]にある状態で。
Historically, some implementations have used Inverted NRZ (merely
switching the sense of mark and space), in order to ensure a
minimum ones density with bit-synchronous HDLC. The use of
Inverted NRZ is deprecated.
歴史的に、いくつかの実現がInverted NRZを使用しました(単にマークとスペースの感覚を切り換えて)、ビット同期のHDLCと共にもの最小の密度を確実にするために。 Inverted NRZの使用は推奨しないです。
Automatic Detection
自動検出
Implementations which desire to interoperate with multiple
encodings MAY choose to detect those encodings automatically.
Automatic encoding detection is particularly important for
Primary Rate Interfaces, to avoid extensive pre-configuration.
Only simple encodings are currently distinguished.
複数のencodingsで共同利用するそれの願望が自動的にそれらのencodingsを検出するのを選ぶかもしれない実現。 Primary Rate Interfacesには、自動コード化検出は、大規模なプレ構成を避けるために特に重要です。 簡単なencodingsだけが現在、区別されます。
The only reliable method of detection available is to switch
modes between the supported encodings. Transmission of the LCP
検出の利用可能な唯一の確かな方法は支持されたencodingsの間にモードを切り換えることです。 LCPのトランスミッション
Simpson [Page 2]
ISDN1994年5月の上のシンプソン[2ページ]RFC1618ppp
Configure-Request SHOULD be tried twice for each mode before
switching in rotation. This ensures that sufficient time is
available for a response to arrive from the peer.
要求を構成しているSHOULD、回転で切り替わる前に、各モードのために二度試みられてください。 これは、十分な時間が応答が同輩から到着するように空いているのを確実にします。
Max-Configure MUST be set such that the cumulative attempts
result in no more than 59 seconds of time before disconnect.
It is preferable that the usual limit of 30 seconds be
observed.
累積している試みが設定しなければならないので時間の59秒未満以前分離をもたらすのをマックスと同じくらい構成してください。 30秒の普通の限界が観測されるのは、望ましいです。
Prior Configuration
先の構成
By prior configuration, PPP MAY also be used with other
encodings. Because of difficulty distinguishing them, it is
not recommended that these encodings be automatically detected.
先の構成、PPP MAY、また、他のencodingsと共に使用されてください。 それらを区別することにおける苦労のために、これらのencodingsが自動的に検出されることが勧められません。
Terminal adapters conforming to V.120 [4] can be used as a
simple interface to workstations. Asynchronous HDLC framing
[2] is accepted at the R reference point. The terminal adapter
provides async-sync conversion. Multiple B-channels can be
used in parallel. Unfortunately, V.120 has a framing mode of
its own for rate adaptation, which is difficult to distinguish
from Frame Relay, and which can confuse in-band frame
detection. V.120 is not interoperable with bit-synchronous
links, since V.120 does not provide octet-stuffing to bit-
stuffing conversion. Therefore, V.120 is deprecated in favor
of more modern standards, such as "PPP in Frame Relay".
簡単なインタフェースとしてV.120[4]に一致しているターミナルアダプタはワークステーションに使用できます。 R基準点で非同期なHDLC縁ど[2]りを受け入れます。 ターミナルアダプタはasync-同時性変換を提供します。 平行で複数のBチャネルを使用できます。 残念ながら、V.120には、それ自身の縁どりモードがレート適合のためにあります。(それは、Frame Relayと区別するのが難しく、バンドにおけるフレーム検出を混乱させることができます)。 V.120がビット詰め物の変換に八重奏詰め物を提供しないので、V.120はビット同期のリンクで共同利用できません。 したがって、V.120は「フレームリレーにおけるppp」などの、より現代の規格を支持して非難されます。
The "Bandwidth On Demand Interoperability Group" has defined a
proposal called BONDING. Multiple B-channels can be used in
parallel. BONDING has an initialization period of its own,
which might conflict with the simple detection technique
described above, and requires extensive individual
configuration in some current implementations when multiple B-
channels are involved. It is recommended that the PPP Multi-
Link Procedure be used instead of BONDING.
「帯域幅のオンデマンドの相互運用性グループ」はBONDINGと呼ばれる提案を定義しました。 平行で複数のBチャネルを使用できます。 BONDINGには、それ自身の初期化の期間があります。(複数のBチャンネルがかかわるとき、それは、いくつかの現在の実現で上でテクニックが説明した簡便な検出と衝突して、大規模な個々の構成を必要とするかもしれません)。 PPP MultiリンクProcedureがBONDINGの代わりに使用されるのは、お勧めです。
3. Framing
3. 縁どり
For B-channels, in the absence of prior configuration, the implementation MUST first use bit-synchronous HDLC [2], as opposed to other framings, for initial link establishment. This assumes that circuit-switched communications are generally [host | router] to [host | router].
Bチャネルのために、先の構成がないとき実現は最初にビット同期のHDLC[2]を使用しなければなりません、他の縁どりと対照的に、初期のリンク設立のために。 これは、一般に[ホスト| ルータ][ホスト| ルータ]にはサーキットで切り換えられたコミュニケーションがあると仮定します。
By prior configuration, octet-synchronous HDLC [2] is recommended where the network termination equipment interfaces directly to the T
先の構成で、八重奏同期のHDLC[2]はネットワーク終了設備が直接Tに連結するところでお勧めです。
Simpson [Page 3]
ISDN1994年5月の上のシンプソン[3ページ]RFC1618ppp
reference point, and octet boundaries are available at the time of framing. Such equipment is likely to be highly integrated, and the elimination of bit-synchronous hardware can reduce the part count, resulting in lower cost interfaces and simpler configuration. Octet-synchronous HDLC MUST be used with NRZ bit encoding.
ポイント、および八重奏境界が縁どるとき利用可能である参照。 そのような設備は高集積度である傾向があります、そして、ビット同期のハードウェアの除去は部分カウントを抑えることができます、下側の費用インタフェースと、より簡単な構成をもたらして。 八重奏同期のHDLC MUST、NRZビットコード化と共に使用されてください。
For D-channels, by default no data service is expected. By prior configuration, "PPP in X.25" or "PPP in Frame Relay" framing MAY be used.
Dチャネルにおいて、デフォルトで、データサービスは全く予想されません。 先の構成で、「X.25"のpppか「フレームリレーにおけるppp」縁どりは使用されるかもしれません」。
Despite the fact that HDLC, LAPB, LAPD, and LAPF are nominally distinguishable, multiple methods of framing SHOULD NOT be used concurrently on the same ISDN channel. There is no requirement that PPP recognize alternative framing techniques, or switch between framing techniques without specific configuration.
HDLC、LAPB、LAPD、およびLAPFが名目上は区別可能であり、縁どりの複数の方法がSHOULD NOTであるという事実にもかかわらず、同時に同じISDNチャンネルの上に使用されてください。 PPPが代替の縁どりのテクニックを認識するか、または特定の構成なしで縁どりのテクニックを切り換えるという要件が全くありません。
4. Out-of-Band signaling
4. バンドで出ているシグナリング
Experience has shown that the LLC Information Element is not reliably transmitted end to end. The deployment of compatible switches is too limited, and the subscription policies of the providers are too diverse. Therefore, transmission of the LLC-IE SHOULD NOT be relied upon for framing or encoding determination.
経験は、LLC情報Elementが終わらせる確かに伝えられなかった終わりであることを示しました。 コンパチブルスイッチの展開はあまり限られています、そして、プロバイダーの購読方針は多様過ぎます。 したがって、縁どりのために当てにされるか、または決断をコード化することであるLLC-IE SHOULD NOTのトランスミッション。
No LLC-IE values which pertain to PPP have been assigned. Any other values which are received are not valid for PPP links, and can be ignored for PPP service.
PPPに関係するLLC-IE値が全く割り当てられていません。 いかなる他の受け取られていている値も、PPPリンクには有効でなく、PPPサービスのために無視できます。
As an alternative administrative measure, multiple directory numbers can point to the same physical access facility, by binding particular services to each directory number. The called party identifier has proven to be reliably provided by the local switch.
代替の管理基準として、複数のディレクトリ番号が同じ物理的なアクセス施設を示すことができます、それぞれのディレクトリ番号に対する拘束力がある特定のサービスで。 被呼者識別子は地方のスイッチによって確かに提供されると判明しました。
When a called party identifier is used, or when a future LLC-IE value is assigned to PPP and the PPP value is received, if the LCP has not had the administrative Open event, the call MUST be rejected. Receivers MUST NOT accept an incoming call, only to close the circuit or ignore packets from the circuit.
被呼者識別子が使用されているか、将来のLLC-IE値がPPPに割り当てられて、またはLCPに管理オープン出来事がないならPPP値が受け取られているとき、呼び出しを拒絶しなければなりません。 受信機はかかってきた電話を受け入れてはいけませんが、回路を閉じているか、またはサーキットからパケットを無視します。
Simpson [Page 4]
ISDN1994年5月の上のシンプソン[4ページ]RFC1618ppp
5. Configuration Details
5. 構成の詳細
The LCP recommended sync configuration options apply to ISDN links.
LCPのお勧めの同時性設定オプションはISDNリンクに適用されます。
The standard LCP sync configuration defaults apply to ISDN links.
標準のLCP同時性構成デフォルトはISDNリンクに適用されます。
The typical network feeding the link is likely to have a MRU of either 1500, or 2048 or greater. To avoid fragmentation, the Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT exceed 1500, unless a peer MRU of 2048 or greater is specifically negotiated.
リンクを食べさせる典型的なネットワークは1500か2048年のどちらか以上のMRUを持っていそうです。 断片化を避けるために、ネットワーク層SHOULD NOTのMaximumトランスミッションユニット(MTU)は1500を超えています、2048年以上の同輩MRUが明確に交渉されない場合。
Instead of a constant value for the Restart timer, the exponential backoff method is recommended. The Restart Timer SHOULD be 250 milliseconds for the initial value, and 3 seconds for the final value.
Restartタイマのための恒常価値の代わりに、指数のbackoff方法はお勧めです。 Restart Timer SHOULD、初期の値のための250ミリセカンドと、検査値のための3秒になってください。
Implementations that include persistent dialing features, such as "demand dialing" or "redialing", SHOULD use mechanisms to limit their persistence. Examples of such mechanisms include exponential backoff, and discarding packet queues after failure to complete link establishment. In some implementations, discarding the transmit queue can temporarily remove the stimulus to retry the connection.
「要求のダイヤルすること」や「再ダイヤルする」SHOULDなどのしつこいダイヤルすることの特徴を含んでいる実現は、彼らの固執を制限するのにメカニズムを使用します。 そのようなメカニズムに関する例は、リンク設立を終了しないことの後に指数のbackoffと、パケット待ち行列を捨てるのを含んでいます。 待ち行列を伝えてください。いくつかの実現、捨てる、一時、接続を再試行する刺激を取り除くことができます。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
References
参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
1548, Daydreamer, December 1993.
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、RFC1548、空想家、1993年12月。
[2] Simpson, W., Editor, "PPP in HDLC Framing", RFC 1549,
Daydreamer, December 1993.
[2] シンプソン、W.、エディタ、「HDLC縁どりにおけるppp」、RFC1549、空想家、1993年12月。
[3] Stallings, W, "ISDN and Broadband ISDN - 2nd ed", Macmillan,
1992.
[3] ストーリングズ、W、「ISDNと広帯域ISDN--、2番目の教育、」、マクミラン、1992
[4] CCITT Recommendations I.465 and V.120, "Data Terminal Equipment
Communications over the Telephone Network with Provision for
Statistical Multiplexing", CCITT Blue Book, Volume VIII,
Fascicle VIII.1, 1988.
[4] I.465とV.120、「統計的多重化への支給がある電話網の上のデータ端末装置コミュニケーション」、CCITT青が予約するCCITT推薦、巻VIII(分冊VIII.1、1988)。
Simpson [Page 5]
ISDN1994年5月の上のシンプソン[5ページ]RFC1618ppp
Acknowledgments
承認
This design was inspired by previous drafts of C. Frost, B. Gorsline, D. Leifer, K. Muramaki, S. Sheldon, K. Sklower, and T. Sugawara.
このデザインはC.フロスト、B.Gorsline、D.ライファー、K.Muramaki、S.シェルドン、K.Sklower、およびT.菅原の前の草稿で奮い立たせられました。
Thanks to Oliver Korfmacher (NetCS) for European considerations, Dory Leifer (University of Michigan) for technical details and called party signalling, and Vernon Schryver (Silicon Graphics) regarding handling of link misconfiguration and timeouts.
ヨーロッパの問題のためのオリバーKorfmacher(NetCS)、技術的詳細と被呼者合図のためのDoryライファー(ミシガン大学)、およびリンクmisconfigurationとタイムアウトの取り扱いに関するヴァーノンSchryver(シリコングラフィックス)をありがとうございます。
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 93117
フレッド・ベイカー・高度なコンピュータコミュニケーション315Bollay Driveサンタバーバラ、カリフォルニア 93117
EMail: fbaker@acc.com
メール: fbaker@acc.com
Author'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
bsimpson@MorningStar.com
メール: Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com
Simpson [Page 6]
シンプソン[6ページ]
一覧
スポンサーリンク
