RFC1377 日本語訳
1377 The PPP OSI Network Layer Control Protocol (OSINLCP). D. Katz. November 1992. (Format: TXT=22109 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Katz Request for Comments: 1377 cisco November 1992
コメントを求めるワーキンググループD.キャッツ要求をネットワークでつないでください: 1377年のコクチマス1992年11月
The PPP OSI Network Layer Control Protocol (OSINLCP)
ppp OSIネットワーク層制御プロトコル(OSINLCP)
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でNetwork Layerがプロトコル情報であるとカプセル化する標準方法を提供します。 PPPは、異なったネットワーク層プロトコルを設立して、構成するためにまた、広げることができるLink Controlプロトコルを定義して、Network Controlプロトコル(NCP)のファミリーを提案します。
This document defines the NCP for establishing and configuring OSI Network Layer Protocols.
このドキュメントは、OSI Network Layerプロトコルを設立して、構成するためにNCPを定義します。
This memo is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.
このメモはPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の製品です。 このメモのコメントを ietf-ppp@ucdavis.edu メーリングリストに提出するべきです。
Table of Contents
目次
1. Introduction .......................................... 2 1.1 OSI Network Layer Protocols over PPP .................. 2 2. A PPP Network Control Protocol (NCP) for OSI .......... 5 2.1 Sending OSI NPDUs ..................................... 6 2.2 NPDU Alignment ........................................ 6 2.3 Network Layer Addressing Information .................. 6 3. OSINLCP Configuration Options ......................... 7 3.1 Align-NPDU ............................................ 7 REFERENCES ................................................... 9 ACKNOWLEDGEMENTS ............................................. 9 SECURITY CONSIDERATIONS ...................................... 10 CHAIR'S ADDRESS .............................................. 10 AUTHOR'S ADDRESS ............................................. 10
1. 序論… 2 1.1 pppの上のOSIネットワーク層プロトコル… 2 2. pppネットワークはOSIのためにプロトコル(NCP)を制御します… 5 2.1 OSI NPDUsを送ります… 6 2.2 NPDU整列… 6 2.3 ネットワーク層アドレス指定情報… 6 3. OSINLCP設定オプション… 7 3.1 NPDUを並べます… 7つの参照箇所… 9つの承認… 9 セキュリティ問題… 10 議長のアドレス… 10作者のアドレス… 10
Katz [Page 1] RFC 1377 PPP OSINLCP November 1992
キャッツ[1ページ]RFC1377ppp OSINLCP1992年11月
1. Introduction
1. 序論
PPP has three main components:
PPPには、3つの主なコンポーネントがあります:
1. A method for encapsulating datagrams over serial links.
1. シリーズの上でデータグラムをカプセル化するためのメソッドはリンクされます。
2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection.
2. データリンク接続を設立して、構成して、テストするためのLink Controlプロトコル(LCP)。
3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
3. 異なったネットワーク層プロトコルを設立して、構成するためのNetwork Controlプロトコル(NCP)のファミリー。
In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, PPP must send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link.
ポイントツーポイント接続の上でコミュニケーションを確立するために、PPPリンクの各端は、最初に、構成するパケットをLCPに送って、データ・リンクをテストに送らなければなりません。 リンクが設立されて、任意の施設が必要に応じてLCPによって交渉された後に、PPPは、1つ以上のネットワーク層プロトコルを選んで、構成するためにNCPパケットを送らなければなりません。 いったんそれぞれの選ばれたネットワーク層プロトコルを構成すると、各ネットワーク層プロトコルからのデータグラムをリンクの上に送ることができます。
The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (an inactivity timer expires or network administrator intervention).
リンクは明白なLCPかNCPパケットがリンクを閉鎖するか、または何らかの外部のイベントが起こるまで(不活発タイマが期限が切れるか、または管理者介入をネットワークでつないでください)コミュニケーションのために構成されたままで残るでしょう。
1.1. OSI Network Layer Protocols over PPP
1.1. pppの上のOSIネットワーク層プロトコル
A number of protocols have been defined for the Network Layer of OSI, including the Connectionless Network Layer Protocol (CLNP, ISO 8473) [3], the End System to Intermediate System routing protocol (ES-IS, ISO 9542) [4], the Intermediate System to Intermediate System routing protocol (IS-IS, ISO 10589) [5], and the Inter-Domain Routeing Protocol (IDRP, CD 10747) [6]. Generally, these protocols were designed to run over non-reliable data link protocols such as PPP.
多くのプロトコルがOSIのNetwork Layerのために定義されました、Connectionless Network Layerプロトコル(CLNP、ISO8473)[3]を含んでいて、Intermediate Systemルーティング・プロトコルへのEnd System、(ES存在、ISO9542) [4]、Intermediate SystemルーティングへのIntermediate Systemが議定書を作る、(-、ISO10589) [5]、およびInter-ドメインRouteingプロトコル(IDRP、CD10747)[6]。 一般に、これらのプロトコルは、PPPなどの非確実な資料リンク・プロトコルをひくように設計されました。
Network Layer Protocol Identifier (NLPID)
ネットワーク層プロトコル識別子(NLPID)
OSI Network Layer protocols can be discriminated according to the first octet in each Network Protocol Data Unit (NPDU, that is, packet), known as the Network Layer Protocol Identifier (NLPID), which is defined in ISO/TR 9577 [7]. This allows the various protocols to be run over a common data link without any discriminator below the network layer.
ISO/TR9577[7]で定義されるNetwork LayerプロトコルIdentifier(NLPID)として知られているそれぞれのNetworkプロトコルData Unit(すなわち、NPDU、パケット)における最初の八重奏に従って、OSI Network Layerプロトコルを差別できます。 これは、様々なプロトコルがネットワーク層の下における少しも弁別器のない一般的なデータ・リンクの上の走行であることを許容します。
Katz [Page 2] RFC 1377 PPP OSINLCP November 1992
キャッツ[2ページ]RFC1377ppp OSINLCP1992年11月
Inactive Network Layer Protocol
不活発なネットワーク層プロトコル
ISO/TR 9577 reserves a NLPID value of zero to represent the "Inactive Network Layer Protocol", as defined in ISO 8473. The inactive network layer protocol MUST NOT be used over PPP. This assures that whichever OSI network layer protocol is used will have a non-zero NLPID value.
ISO/TR9577は、「不活発なネットワーク層プロトコル」を表すためにISO8473で定義されるようにゼロのNLPID値を予約します。 PPPの上で不活発なネットワーク層プロトコルを使用してはいけません。 これは、どの使用されたOSIネットワーク層プロトコルに非ゼロNLPID価値があるかを保証します。
Connection-Oriented Network Protocol
接続指向のネットワーク・プロトコル
The OSI Connection-Oriented Network Protocol (ISO 8208) [8], effectively the Packet Layer of CCITT X.25, is intended to be run over a reliable data link, such as IEEE 802.2 type II or LAPB. Therefore, the unreliable data link service provided by PPP is not appropriate for use with ISO 8208.
OSI Connectionが指向のNetworkプロトコル(ISO8208)[8](事実上CCITT X.25のPacket Layer)は確実な資料リンクの上の走行であることを意図します、IEEE802.2タイプのIIやLAPBのように。 したがって、ISO8208との使用には、PPPによって提供された頼り無いデータ・リンクサービスは適切ではありません。
ConnectionLess Network Protocol (CLNP)
コネクションレスなネットワーク・プロトコル(CLNP)
The ConnectionLess Network Protocol offers a simple non-reliable datagram service very similar to IP, and is designed to run over a non-reliable data link service, such as provided by PPP.
ConnectionLess Networkプロトコルは、IPと非常に同様の簡単な非信頼できるデータグラムサービスを提供して、非確実な資料リンクサービスをひくように設計されています、PPPによって提供されるように。
End-System to Intermediate-System Protocol (ES-IS)
中間システムプロトコルへのエンドシステム(ES存在、)
ES Hellos and IS Hellos are retransmitted on a periodic timer- driven basis (based on expiration of the "Configuration Timer"). The resulting ES and IS configuration information is invalidated on a timer driven basis, based on expiration of the "Holding Timer" for each piece of information. The value of a Holding Timer is set by the source of the information, and transmitted in the Holding Time field of the appropriate ES-IS packet. ISO 9542 recommends that the holding time field is set to approximately twice the Configuration Timer parameter, such that even if every other Hello packet is lost the configuration information will be retained (implying that the Holding Timer is actually set to slightly more than twice the Configuration Timer).
ESハローズ、ハローズがa周期的なタイマやる気満々ベース(「構成タイマ」の満了に基づいている)で再送されるということです。 そして、結果として起こるES、設定情報がタイマやる気満々のベースで無効にされるということであり、それぞれの情報のための「把持タイマ」の満了に基づいています。 Holding Timerの値が情報の情報筋によって設定されて、Holding Time分野で送られる、適切である、ES存在、パケット ISO9542は、把持時間分野がConfiguration Timerパラメタのおよそ2倍に設定されることを勧めます、他のあらゆるHelloパケットが無くなっても設定情報が保有される(Holding Timerが実際にConfiguration Timerの2倍わずかに以上に用意ができているのを含意して)ように。
Generally, the recommendation in ISO 9542 is sufficient for PPP links. For very unreliable links, it may be necessary to set the Holding Timer to be slightly more than three times the Configuration Timer to ensure that loss of configuration information is an unusual event.
一般に、ISO9542の推薦はPPPリンクに十分です。 全く頼り無いリンクに、設定情報の損失が珍しいイベントであることを保証するためにHolding TimerにConfiguration Timerのわずかに3倍以上であるように設定するのが必要であるかもしれません。
Redirect information is not transmitted on point-to-point links, but may be transmitted on general topology subnetworks, which in turn may make use of PPP. Redirect information is sent on a event-driven basis (based on a CLNP packet being forwarded by a router out the incoming interface), but redirect information is
一般的なトポロジーサブネットワークの上で伝えられるかもしれない以外に、再直接の情報はポイントツーポイント接続の上で伝えられません。順番に、サブネットワークはPPPを利用するかもしれません。 イベントドリブンベース(ルータによって入って来るインタフェースから進められるCLNPパケットに基づいている)で再直接の情報を送りますが、再直接の情報は送ります。
Katz [Page 3] RFC 1377 PPP OSINLCP November 1992
キャッツ[3ページ]RFC1377ppp OSINLCP1992年11月
invalidated on a timer-driven basis. Loss of a single redirect may result in a subsequent data packet being sent to the same incorrect router, which will re-issue the redirect. This operates in the same manner as ICMP redirects for IP packets, and does not pose any problem for operation over PPP links.
タイマでやる気満々のベースでは、無効にされます。 シングルの損失が向け直す、同じ不正確なルータに送られる順次データパケットの結果(そうする)が再直接を再発行しますように。 これは、ICMPがIPのためにパケットを向け直すとき同じ方法で作動して、PPPリンクの上の操作のためにどんな問題も引き起こしません。
Intermediate-System to Intermediate-System Protocol (IS-IS)
中間システムプロトコルへの中間システム(IS-IS)
IS-IS allows for broadcast links (typically LANs), point-to-point links (such as PPP), and general topology links (such as X.25 networks) which are modelled as a collection of point-to-point links.
-、ポイントツーポイントの収集がリンクされるときモデル化される放送リンク(通常LAN)、ポイントツーポイント接続(PPPなどの)、および一般的なトポロジーのリンク(X.25ネットワークなどの)に許容します。
There are four types of IS-IS packets: IS-IS Hello Packets, Link State Packets (LSPs), Complete Sequence Number Packets (CSNPs), and Partial Sequence Number Packets (PSNPs).
4つのタイプがある、-、パケット: -、こんにちは、パケット、リンク州のパケット(LSPs)、完全な配列数のパケット(CSNPs)、および部分的な一連番号パケット(PSNPs。)
IS-IS Hello messages are transmitted periodically on point-to- point links (based on expiration of the "ISISHello" timer). Routers expect to receive IS-IS Hello packets periodically. Specifically, the IS-IS Hello packet specifies a "Holding Time". If no subsequent IS-IS Hello is received over the corresponding link for the specified time period, then the neighboring router is assumed to have been disconnected or to be down. It is highly undesireable for links to "flap" up and down unnecessarily, which implies that the holding time needs to be large enough that a link is very unlikely to be declared down due to a failure to receive an IS-IS Hello. This implies that running IS-IS over unreliable data links requires the Holding time to be greater than "k" times the ISISHello timer, where k is chosen such that the loss of k consecutive IS-IS Hello's is rare. If the quality of the link is poor, then the Holding Time will need to be increased or the "ISISHello" time decreased.
-、Helloメッセージはポイントからポイントへのリンク("ISISHello"タイマの満了に基づいている)の上に定期的に送られます。 ルータが、受信すると予想する、-、Helloパケット、定期的に。 明確に、-、Helloパケットは「把持時間」を指定します。 いいえその後、-、指定された期間に対応するリンクの上にHelloを受け取って、次に、切断されたか、または下がっていると隣接しているルータを思います。 リンクが上下に不必要に「ばたつく」であることが、非常に「非-望-可能」である、(把持時間が、受信しないことのためリンクが非常に宣言されそうにないほど大きい必要であるのを含意します)-、Hello。 これがその稼働を含意する、-、あてにならないデータ、上リンクが「k」よりすばらしい回がそのようなものがkに選ばれているISISHelloタイマであったならHolding時間が必要であるそれ、k連続することの損失、-、Helloはまれです。 リンクの品質が劣っていると、Holding Timeは増強されるべき必要性か減少する"ISISHello"時間がそうするでしょう。
LSPs are acknowledged by the IS-IS protocol (via use of partial sequence number packets). A lost LSP will be recovered from with no problem provided that PPP links are treated the same way as other point-to-point links. On those rare occasions where a partial sequence number packet is lost, this might result in the retransmission of a link state packet over a single link, but will not impact the correct operation of the routing algorithm.
LSPsが承認される、-、議定書を作ってください(部分的な一連番号パケットの使用で)。 無くなっているLSPから、PPPリンクが同じように他のポイントツーポイント接続として扱われると、問題なしで回復されるでしょう。 それらのまれな機会に、これは、部分的な一連番号パケットが無くなるところに、単一のリンクの上にリンク州のパケットの「再-トランスミッション」をもたらすかもしれませんが、ルーティング・アルゴリズムの正しい操作に影響を与えないでしょう。
CSNPs are sent upon link startup on a point-to-point link. This does not need to be changed for PPP. If a CSNP fragment is lost upon startup it is merely loss of an optimization -- LSPs that did not need to be transmitted over the link will be transmitted. If a periodic CSNP fragment is lost it merely means that detection of low probability database corruption will take longer.
ポイントツーポイント接続でリンク始動にCSNPsを送ります。 PPPのためにこれは変えられる必要はありません。 CSNP断片が始動のときになくされているなら、それは単に最適化の損失です--リンクの上に伝えられる必要はなかったLSPsが伝えられるでしょう。 周期的なCSNP断片が無くなるなら、それは、低い確率データベース不正の検出に時間がかかることを単に意味します。
Katz [Page 4] RFC 1377 PPP OSINLCP November 1992
キャッツ[4ページ]RFC1377ppp OSINLCP1992年11月
PSNPs function as ACKs. Loss of a PSNP may result in an unnecessary retransmission of an LSP, but does not prevent correct operation of the routing protocol.
PSNPsはACKsとして機能します。 PSNPの損失は、LSPの不要な「再-トランスミッション」をもたらすかもしれませんが、ルーティング・プロトコルの正しい操作を防ぎません。
Inter-Domain Routeing Protocol (IDRP)
相互ドメインRouteingプロトコル(IDRP)
IDRP expects to run over datagram links, but requires reliable exchange of IDRP information. For this reason, IDRP contains built-in reliability mechanisms which ensure that packets will be received correctly.
IDRPはデータグラムリンクをひくと予想しますが、IDRP情報の信頼できる交換を必要とします。 この理由で、IDRPはパケットが正しく受け取られるのを確実にする内蔵の信頼性のメカニズムを含んでいます。
2. A PPP Network Control Protocol (NCP) for OSI
2. OSIのためのpppネットワーク制御プロトコル(NCP)
The OSI Network Layer Control Protocol (OSINLCP) is responsible for configuring, enabling, and disabling the OSI protocol modules on both ends of the point-to-point link. OSINLCP uses the same packet exchange machanism as the Link Control Protocol (LCP). OSINLCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. OSINLCP packets received before this phase is reached should be silently discarded.
ポイントツーポイント接続の両端でOSIプロトコルがモジュールであると構成して、可能にして、無効にするのにOSI Network Layer Controlプロトコル(OSINLCP)は原因となります。 OSINLCPはLink Controlプロトコル(LCP)としての同じパケット交換machanismを使用します。 PPPがNetwork-層のプロトコルフェーズに達するまで、OSINLCPパケットは交換されないかもしれません。 このフェーズに達する前に受け取られたOSINLCPパケットは静かに捨てられるべきです。
The OSI Network Layer Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions:
OSI Network Layer Controlプロトコルはまさに以下の例外でLink Controlプロトコル[1]と同じです:
Frame Modifications
フレーム変更
The packet may utilize any modifications to the basic frame format which have been negotiated during the Link Establishment phase.
パケットは基本枠形式へのLink特権階級段階の間に交渉されているどんな変更も利用するかもしれません。
Data Link Layer Protocol Field
データリンク層プロトコル分野
Exactly one OSINLCP packet is encapsulated in the Information field of a PPP Data Link Layer frame where the Protocol field indicates type hex 8023 (OSI Network Layer Control Protocol).
ちょうど1つのOSINLCPパケットがプロトコル分野が、タイプが8023(OSI Network Layer Controlプロトコル)人に魔法をかけるのを示すPPP Data Link Layerフレームの情報分野でカプセルに入れられます。
Code field
コード分野
Only Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in Code-Rejects.
Codes1だけ、通じて、7 (要求を構成する、Configure-Ack、Configure-Nak、Configure-廃棄物、Terminate-要求、Terminate-Ack、およびCode-廃棄物) 使用されます。 他のCodesは認識されていないとして扱われるべきであり、Code-廃棄物をもたらすはずです。
Timeouts
タイムアウト
OSINLCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other
PPPがNetwork-層のプロトコルフェーズに達するまで、OSINLCPパケットは交換されないかもしれません。 実装はAuthenticationとLink Quality Determinationが、以前タイミングが外で何らかのConfigure-Ackを待ち終えるのを待つように準備されるべきです。
Katz [Page 5] RFC 1377 PPP OSINLCP November 1992
キャッツ[5ページ]RFC1377ppp OSINLCP1992年11月
response. It is suggested that an implementation give up only after user intervention or a configurable amount of time.
応答。 実装がユーザ介入か構成可能な時間の後にだけあきらめることが提案されます。
Configuration Option Types
設定オプションタイプ
OSINLCP has one Configuration Option, which is defined below.
OSINLCPには1Configuration Optionがあります。(Configuration Optionは以下で定義されます)。
2.1. Sending OSI NPDUs
2.1. 送付OSI NPDUs
Before any Network Protocol Data Units (NPDUs) may be communicated, PPP must reach the Network-Layer Protocol phase, and the OSI Network Layer Control Protocol must reach the Opened state.
どんなNetworkプロトコルData Units(NPDUs)も伝えられるかもしれない前に、PPPはNetwork-層のプロトコルフェーズに達しなければなりません、そして、OSI Network Layer ControlプロトコルはOpened状態に達しなければなりません。
Exactly one OSI NPDU is encapsulated in the Information field of a PPP Data Link Layer frame where the Protocol field indicates type hex 0023 (OSI Network Layer).
ちょうど1OSI NPDUがプロトコル分野が、タイプが0023(OSI Network Layer)人に魔法をかけるのを示すPPP Data Link Layerフレームの情報分野でカプセル化されます。
The maximum length of an OSI NPDU transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. Larger NPDUs must be segmented as necessary. If a system wishes to avoid segmentation and reassembly, it should use transport layer mechanisms to discourage others from sending large PDUs.
PPPリンクの上に伝えられたOSI NPDUの最大の長さはPPPデータ・リンク層フレームの情報分野の最大の長さと同じです。 必要に応じてより大きいNPDUsを区分しなければなりません。 システムが分割を避けて、再アセンブリしたいなら、それは、他のものが大きいPDUsを送るのを思いとどまるのにトランスポート層メカニズムを使用するべきです。
2.2. NPDU Alignment
2.2. NPDU整列
OSI protocols have peculiar alignment problems due to the fact that they are often encapsulated in data link protocols with odd-length headers, while PPP defaults to even-length headers. A router switching an OSI packet may find that the beginning of the packet falls on an inconvenient memory boundary when the hardware used to transmit the packet to its next hop requires a particular alignment. This situation can be addressed by the use of leading zero padding.
OSIプロトコルには、独特の整列問題がそれらが変な長さのヘッダーと共にデータリンクプロトコルでしばしばカプセル化されるという事実のためあります、PPPは長ささえのヘッダーをデフォルトとしますが。 OSIパケットを切り換えるルータによって、ハードウェアが以前はよく次のホップにパケットを伝えていた不便なメモリ限界のパケット滝の始まりが特定の整列を必要とするのがわかるかもしれません。 先行ゼロ詰め物の使用でこの状況を扱うことができます。
When sending, an implementation MAY insert one to three octets of zero between the PPP header and the OSI NPDU. These zero octets correspondingly reduce the maximum length of the NPDU that may be transmitted.
発信するとき、実装はPPPヘッダーとOSI NPDUの間のゼロの1〜3つの八重奏を挿入するかもしれません。 これらは八重奏のゼロに合っています。伝えられるかもしれない最大の長さのNPDUを対応する減少させてください。
On reception, any such leading zero octets (if present) MUST be removed. Regardless of whether leading zero padding is used, an implementation MUST also be able to receive a PPP packet with any arbitrary alignment of the NPDU.
レセプションでは、どんなそのような先行ゼロ八重奏(存在しているなら)も取り除かなければなりません。 また、先行ゼロ詰め物が使用されているかどうかにかかわらず、実装はNPDUのどんな任意の整列でもPPPパケットを受けることができなければなりません。
2.3. Network Layer Addressing Information
2.3. ネットワーク層アドレス指定情報
OSINLCP does not define a separate configuration option for the exchange of OSI Network Layer address information. Instead, the ES-
OSINLCPはOSI Network Layerアドレス情報の交換のための別々の設定オプションを定義しません。 代わりにES
Katz [Page 6] RFC 1377 PPP OSINLCP November 1992
キャッツ[6ページ]RFC1377ppp OSINLCP1992年11月
IS protocol, ISO 9542, should be used. This protocol provides a mechanism for determining the Network Layer address(es) of the neighbor on the link, as well as determining if the neighbor is an End System or an Intermediate System.
プロトコル、ISO9542であり、使用されるべきです。 このプロトコルは隣人がEnd SystemかそれともIntermediate Systemであるかを決定することと同様にリンクの上に隣人のNetwork Layerアドレス(es)を決定するのにメカニズムを提供します。
A draft addendum to ES-IS [9] is being defined in ISO to add support for dynamic address assignment. This addendum has currently passed the formal "Committee Draft" (CD) letter ballot.
草稿付加物、ES存在、[9]は、ダイナミックなアドレス課題のサポートを加えるためにISOで定義されています。 この付加物は現在、正式な「委員会草案」(CD)手紙投票を通過しました。
3. OSINLCP Configuration Options
3. OSINLCP設定オプション
OSINLCP Configuration Options allow negotiatiation of desirable Internet Protocol parameters. OSINLCP uses the same Configuration Option format defined for LCP [1], with a separate set of Options.
OSINLCP Configuration Optionsは望ましいインターネットプロトコルパラメタのnegotiatiationを許容します。 OSINLCPはLCP[1]のためにOptionsの別々のセットで定義された同じConfiguration Option書式を使用します。
The most up-to-date values of the OSINLCP Option Type field are specified in the most recent "Assigned Numbers" RFC [2]. Current values are assigned as follows:
OSINLCP Option Type分野の最も最新の値は最新の「規定番号」RFC[2]で指定されます。 現行価値は以下の通り割り当てられます:
1 Align-NPDU
1、NPDUを並べます。
3.1. Align-NPDU
3.1. NPDUを並べます。
Description
記述
This Configuration Option provides a way for the receiver to negotiate a particular alignment of the OSI NPDU. Empirical evidence suggests that the greatest time deficit for re-alignment exists at the receiver.
このConfiguration Optionは、OSI NPDUの特定の整列を交渉するために受信機のための方法を提供します。 実証的証拠は、再整列のための最大級の時間赤字が受信機に存在するのを示します。
The alignment is accomplished through combination of PPP header compression with leading zero padding (see above). It is recommended that alignment be entirely through header compression combinations whenever possible. For example, an alignment of 3 could be achieved by combining uncompressed PPP Address and Control fields (2 octets) with a compressed PPP Protocol field (1 octet).
整列は先行ゼロ詰め物でPPPヘッダー圧縮の組み合わせで実行されます(上を見てください)。 可能であるときはいつも、整列が完全にヘッダー圧縮組み合わせることであるのは、お勧めです。 例えば、解凍されたPPP AddressとControl分野(2つの八重奏)を圧縮されたPPPプロトコル分野(1つの八重奏)に結合することによって、3の整列を達成できるでしょう。
This option is negotiated separately in each direction. A receiver which does not need alignment MUST NOT request the option. A sender which desires alignment prior to sending SHOULD Configure-Nak with an appropriate value.
このオプションは別々に各方向と交渉されます。 整列を必要としない受信機はオプションを要求してはいけません。 適切な値がある送付SHOULD Configure-Nakの前で整列を望んでいる送付者。
Implementation Note: In a complex environment, there might be several conflicting needs for alignment. It is recommended that the receiver request alignment based on the needs of the highest speed next hop link. Also, greater efficiency might be obtained by negotiating upstream the values requested by
実装注意: 複雑な環境には、整列に関する数個の相反する要求があるかもしれません。 最も高いことの必要性に基づく受信機要求整列が次のホップリンクを促進するのは、お勧めです。 また、上流へ要求された値を交渉することによって、より大きい効率を得るかもしれません。
Katz [Page 7] RFC 1377 PPP OSINLCP November 1992
キャッツ[7ページ]RFC1377ppp OSINLCP1992年11月
downstream PPP links, since those packets will not need a change in alignment on transit.
川下に、それらのパケットがトランジットのときに整列における変化を必要としないので、PPPはリンクします。
The alignment request is advisory, and failure to agree on an alignment MUST NOT prevent the OSINLCP from reaching the Opened state. By default, the alignment is done according to the needs of the sender, and all receivers MUST be capable of accepting packets with any alignment.
整列要求は顧問です、そして、整列に同意しない場合、OSINLCPがOpened状態に達するのを防いではいけません。 デフォルトで、送付者の必要性に従って、整列します、そして、すべての受信機がどんな整列でもパケットを受け入れることができなければなりません。
Vernacular: If you don't like this option, you can refuse to negotiate it, and you can send whatever alignment you want. However, if you accept the peer's alignment option, then you MUST transmit packets with the agreed alignment.
方言: このオプションが好きでないなら、あなたは、それを交渉するのを拒否できます、そして、あなたが欲しいどんな整列も送ることができます。 しかしながら、同輩の整列オプションを受け入れるなら、あなたは同意された整列でパケットを伝えなければなりません。
A summary of the Align-NPDU Configuration Option format is shown below. The fields are transmitted from left to right.
Align-NPDU Configuration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Alignment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 整列| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
1
1
Length
長さ
3
3
Alignment
整列
This field specifies the offset of the beginning of the OSI NPDU relative to the beginning of the PPP packet header (not including any leading Flag Sequences).
この分野はPPPパケットのヘッダーの始まりに比例してOSI NPDUの始まりのオフセットを指定します(少しの主なFlag Sequencesも含んでいなくて)。
A value of 1 through 4 requires an offset of that specific length, modulo 4. For example, a value of 1 would require no padding when the PPP Address, Control, and Protocol fields are compressed. One octet of leading zero padding would be necessary when the PPP header is full sized.
1〜4の値はその特定の長さ、法4のオフセットを必要とします。 例えば、1の値は、PPP Address、Control、およびプロトコル分野が圧縮されるときそっと歩くのを必要としないでしょう。 PPPヘッダーが大きさで分けられた状態で完全であるときに、先行ゼロ詰め物の1つの八重奏が必要でしょう。
A value of 255 requests an offset of an odd length (1 or 3). A value of 254 requests an offset of an even length (2 or 4). If the sender is not capable of dynamically varying the amount of padding, it MUST NAK with one of the two specific values.
255の値は変な長さ(1か3)のオフセットを要求します。 254の値は同等の長さ(2か4)のオフセットを要求します。 送付者はダイナミックに詰め物の量を変えることができないで、それは2つの特定の値の1つがあるMUST NAKです。
Katz [Page 8] RFC 1377 PPP OSINLCP November 1992
キャッツ[8ページ]RFC1377ppp OSINLCP1992年11月
References
参照
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331, Daydreamer, May 1992.
w.[1] シンプソン、「二地点間プロトコル(ppp)」(RFC1331、空想家)は1992がそうするかもしれません。
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992.
[2] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。
[3] ISO, "Information processing systems -- Data communications -- Protocol for providing the connectionless-mode network service", ISO 8473, 1988.
[3] ISO、「情報処理システム--データ通信--コネクションレスなモードネットワーク・サービスを提供するためのプロトコル」、ISO8473、1988。
[4] ISO, "Information processing systems -- Telecommunications and information exchange between systems -- End system to Intermediate system Routeing exchange protocol for use in conjunction with the protocol for providing the connectionless- mode network service (ISO 8473)", ISO 9542, 1988.
[4] ISO、「情報処理システム(システムの間のテレコミュニケーションと情報交換)がプロトコルに関連したコネクションレスなモードネットワーク・サービスを提供する使用のIntermediateシステムRouteing交換プロトコルへのシステムを終わらせる、(ISO8473)、」、ISO9542、1988
[5] ISO, "Information processing systems -- Telecommunications and information exchange between systems -- Intermediate system to Intermediate system Intra-Domain routeing exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO 10589, 1990.
[5] ISO、「情報処理システム--システムの間のテレコミュニケーションと情報交換--プロトコルに関連したコネクションレスなモードネットワーク・サービスを提供する使用のために交換プロトコルをrouteingするIntermediateシステムIntra-ドメインへの中間システム、(ISO8473)、」、ISO10589、1990
[6] ISO, "Protocol for Exchange of Inter-domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs", ISO CD 10747, 1991.
[6] ISO、「相互ドメインRouteing情報の交換のために推進をサポートする中間システムの中で議定書を作ってください、ISO8473PDUs、」、ISO CD10747、1991
[7] ISO, "Information technology -- Telecommunications and information exchange between systems -- Protocol identification in the network layer", ISO/IEC TR9577:1990.
[7] ISO、「情報技術--システムの間のテレコミュニケーションと情報交換--ネットワーク層におけるプロトコル識別」、ISO/IEC TR9577:1990。
[8] ISO, "Information processing systems -- Data communications -- X.25 packet level protocol for Data terminal equipment", ISO 8208, 1984.
[8]ISO、「情報処理システム--データ通信--Data端末装置のためのX.25パケット・レベルプロトコル」、ISO8208、1984。
[9] Taylor, E., "Addendum to ISO 9542 (PDAM 1 - Dynamic Discovery of OSI NSAP Addresses by End Systems)", SC6/N7248.
[9] テイラー、E.、「ISO9542(PDAM1--エンドシステムによるオウシNSAP Addressesのダイナミックな発見)への付加物」、SC6/N7248。
Acknowledgments
承認
Some of the text in this document is taken from previous documents produced by the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).
テキストのいくつかがPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)によって製作された前のドキュメントから本書では抜粋されます。
Special thanks to Ross Callon (DEC), and Cyndi Jung (3Com), for contributions of text and design suggestions based on implementation
ロスCallonへの特別な感謝(12月)、および実装に基づくテキストとデザイン提案の貢献のためのシンディ・ユング(3Com)
Katz [Page 9] RFC 1377 PPP OSINLCP November 1992
キャッツ[9ページ]RFC1377ppp OSINLCP1992年11月
experience.
経験。
Thanks also to Bill Simpson for his editing and formatting efforts, both for this document and for PPP in general.
また、彼の編集と形式取り組み、このドキュメント、および一般に、PPPのためのビル・シンプソンをありがとうございます。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Chair's Address
議長のアドレス
The working group can be contacted via the current chair:
現在のいすを通してワーキンググループに連絡できます:
Brian Lloyd Lloyd & Associates 3420 Sudbury Road Cameron Park, California 95682
ブライアン・ロイド・ロイドと3420年のサドベリー道路キャメロン公園、仲間カリフォルニア 95682
Phone: (916) 676-1147 EMail: brian@lloyd.com
以下に電話をしてください。 (916) 676-1147 メールしてください: brian@lloyd.com
Author's Address
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
Dave Katz cisco Systems, Inc. 1525 O'Brien Dr. Menlo Park, CA 94025
メンローパーク、デーヴキャッツコクチマスSystems Inc.1525オブライエン博士カリフォルニア 94025
Phone: (415) 688-8284 EMail: dkatz@cisco.com
以下に電話をしてください。 (415) 688-8284 メールしてください: dkatz@cisco.com
Katz [Page 10]
キャッツ[10ページ]
一覧
スポンサーリンク