RFC1551 日本語訳
1551 Novell IPX Over Various WAN Media (IPXWAN). M. Allen. December 1993. (Format: TXT=54210 bytes) (Obsoleted by RFC1634) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Allen Request For Comments: 1551 Novell, Inc. Obsoletes: RFC 1362 December 1993 Category: Informational
コメントを求めるワーキンググループM.アレンの要求をネットワークでつないでください: 1551 ノベルInc.は以下を時代遅れにします。 RFC1362 1993年12月のカテゴリ: 情報
Novell IPX Over Various WAN Media (IPXWAN)
様々な青白いメディアの上のノベルIPX(IPXWAN)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This document supercedes RFC 1362 and adds capability for Unnumbered RIP links, On-demand statically routed links and client to router connectivity.
このドキュメントはノベルIPXが様々なWANメディアの上でどう作動するかを説明します。 明確に、それはノベルが標準のIPX経路情報とトラフィックを青白いデータリンクの上と交換する前に必要なルータをルータ情報と交換するのに使用する一般的な「IPX WAN」プロトコルについて説明します。 これは、Unnumbered RIPリンク、静的に発送されたOn-要求リンク、およびクライアントのためにルータの接続性にsupercedes RFC1362を記録して、能力を追加します。
Table of Contents
目次
1. Introduction ................................................. 2 1.1 Operation Over PPP ........................................... 2 1.2 Operation Over X.25 Switched Virtual Circuits ................ 2 1.3 Operation Over X.25 Permanent Virtual Circuits ............... 3 1.4 Operation Over Frame Relay ................................... 3 1.5 Operation Over Other WAN Media ............................... 3 2. Glossary Of Terms ............................................ 4 3. IPX WAN Protocol Description ................................. 4 3.1 The Initial Negotiation ...................................... 5 3.2 Information Exchange ......................................... 9 3.3 NAK Packets .................................................. 10 4. Information Exchange Packet Formats .......................... 10 4.1 Timer Request Packet ......................................... 11 4.2 Timer Response Packet ........................................ 14 4.3 Information Request Packet ................................... 15 4.4 Information Response Packet .................................. 18 5. Running Unnumbered RIP ....................................... 19 6. Workstation Connectivity ..................................... 19 7. On-demand, Statically Routed Links ........................... 19 8. References ................................................... 21 9. Security Considerations ...................................... 21 10. Author's Address.............................................. 22
1. 序論… 2 pppの上の1.1操作… 2 X.25交換仮想回路の上の1.2操作… 2 X.25相手固定接続の上の1.3操作… 3 フレームリレーの上の1.4操作… 3 他の青白いメディアの上の1.5操作… 3 2. 用語の用語集… 4 3. IPXの青白いプロトコル記述… 4 3.1 初期の交渉… 5 3.2情報交換… 9 3.3 NAKパケット… 10 4. 情報交換パケット・フォーマット… 10 4.1 タイマリクエスト・パケット… 11 4.2タイマ応答パケット… 14 4.3 情報リクエスト・パケット… 15 4.4情報応答パケット… 18 5. 実行している無数の裂け目… 19 6. ワークステーションの接続性… 19 7. 要求次第の、そして、静的に発送されたリンク… 19 8. 参照… 21 9. セキュリティ問題… 21 10. 作者のアドレス… 22
Allen [Page 1] RFC 1551 IPXWAN December 1993
アレン[1ページ]RFC1551IPXWAN1993年12月
1. Introduction
1. 序論
This document describes how Novell IPX operates over various WAN media. It is strongly motivated by a desire for IPX to treat ALL wide area links in the same manner. Sections 3 and 4 describe this common "IPX WAN" protocol.
このドキュメントはノベルIPXが様々なWANメディアの上でどう作動するかを説明します。 それはIPXが同じ方法ですべての広い領域のリンクを扱う願望によって強く動機づけられています。 セクション3と4はこの一般的な「IPX WAN」プロトコルについて説明します。
The IPX WAN protocol operation begins immediately after link establishment. While IPX is a connectionless datagram protocol, WANs are often connection-oriented. Different WANs have different methods of link establishment. The subsections of section 1 of this document describe what link establishment means to IPX for different media. They also describe other WAN-media-dependent aspects of IPX operation, such as protocol identification, frame encapsulation, and link tear down.
IPX WANプロトコル操作はリンク設立直後始まります。 IPXはコネクションレスなデータグラムプロトコルですが、WANはしばしば接続指向です。 異なったWANには、リンク設立の異なったメソッドがあります。 このドキュメントのセクション1の小区分はリンク設立が異なったメディアのためにIPXに意味することについて説明します。 また、彼らは識別、フレームカプセル化、およびリンクが取りこわすプロトコルなどのIPX操作の他のWANメディア扶養家族局面について説明します。
1.1 Operation Over PPP
1.1 pppの上の操作
IPX uses PPP [1] when operating over point-to-point synchronous and asynchronous networks.
[1] 二地点間同時の、そして、非同期なネットワークの上で作動するとき、IPXはPPPを使用します。
With PPP, link establishment means the IPX NCP [4] reaches the Open state. NetWare IPX will negotiate down to a null set of NCP options, and uses normal frame encapsulation as defined by PPP. The IPXWAN protocol MUST NOT occur until the IPX NCP reaches the Open state. Options negotiated by the IPXWAN protocol MUST supercede any options negotiated by the IPXCP.
PPPと共に、リンク設立は、IPX NCP[4]がオープン状態に達することを意味します。 NetWare IPXはNCPオプションの零集合まで交渉して、PPPによって定義されるように正常なフレームカプセル化を使用します。 IPX NCPがオープン状態に達するまで、IPXWANプロトコルは起こってはいけません。 IPXWANプロトコルによって交渉されたオプションはどんなオプションもIPXCPで交渉したsupercedeがそうしなければなりません。
PPP allows either side of a connection to stop forwarding IPX if one end sends an IPXCP or an LCP Terminate-Request. When a router detects this, it will immediately reflect the lost connectivity in its routing information database instead of naturally aging it out.
PPPは片端がIPXCPかLCP Terminate-要求を送るならIPXを進めるのを接続のどちらの側面も止めさせます。 ルータがすぐにこれを検出するとき、それは外で自然にそれの年をとることの代わりにルーティング情報データベースの無くなっている接続性を反映するでしょう。
1.2 Operation over X.25 Switched Virtual Circuits
1.2 X.25交換仮想回路の上の操作
With X.25, link establishment means successfully opening an X.25 virtual circuit. As specified in RFC-1356, "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode" [2], the protocol identifier 0x800000008137 is used in the X.25 Call User Data field of the Call Request frame, and indicates that the virtual circuit will be devoted to IPX.
X.25と共に、リンク設立は、首尾よくX.25の仮想の回路を開けることを意味します。 RFC-1356、「Multiprotocolはパケット形態によるX.25とISDNで内部連絡する」[2]で指定されるように、プロトコル識別子0x800000008137は、Call RequestフレームのX.25 Call User Data分野で使用されて、仮想の回路がIPXにささげられるのを示します。
Furthermore, each IPX packet is encapsulated directly in X.25 data frame sequences without additional framing.
その上、それぞれのIPXパケットは追加縁どりなしで直接X.25データフレーム系列でカプセルに入れられます。
Either side of the virtual circuit may close it, thereby tearing down the IPX link. When a router detects this, it will immediately reflect the lost connectivity in its routing information database instead of
仮想の回路のどちらの端もそれを閉じて、その結果、IPXリンクを取りこわすかもしれません。 の代わりにするルータがすぐにこれを検出するとき、ルーティング情報データベースの無くなっている接続性を反映する。
Allen [Page 2] RFC 1551 IPXWAN December 1993
アレン[2ページ]RFC1551IPXWAN1993年12月
naturally aging it out.
自然に、外でそれの年をとります。
1.3 Operation over X.25 Permanent Virtual Circuits
1.3 X.25相手固定接続の上の操作
The nature of X.25 PVC's is that no call request is made. When the router is informed that X.25 Layer 2 is up, the router should assume that link establishment is complete.
X.25 PVCの自然は発呼要求を全くしないということです。 ルータがX.25 Layer2が上がっていると知らされるとき、ルータは、リンク設立が完全であると仮定するべきです。
Each IPX packet is encapsulated in an X.25 data frame sequence without additional framing. Novell IPX assumes a particular X.25 permanent circuit is devoted to the use of IPX.
それぞれのIPXパケットは追加縁どりなしでX.25データフレーム系列でカプセルに入れられます。 ノベルIPXは、特定のX.25永久的な回路がIPXの使用にささげられると仮定します。
If a router receives a layer 2 error condition (e.g., X.25 Restart), it should reflect lost connectivity for the permanent circuits in its routing information database and re-perform the necessary steps to obtain a full IPX connection.
ルータが層2のエラー条件(例えば、X.25 Restart)を受けるなら、それは、ルーティング情報データベースの永久的な回路に無くなっている接続性を反映して、完全なIPX接続を得るために必要なステップを再実行するべきです。
1.4 Operation over Frame Relay Permanent Virtual Circuits
1.4 フレームリレー相手固定接続の上の操作
To determine when a permanent virtual circuit (PVC) has become active or inactive, the router interacts periodically with either a private Frame Relay switch or a public Frame Relay network. The method used depends on the switch or service provider. Some support [7], section 6l others support [3], Annex D. Novell supports both methods.
相手固定接続(PVC)がいつアクティブであるか不活発になったかを決定するために、ルータは定期的に個人的なFrame Relayスイッチか公立のFrame Relayネットワークのどちらかと対話します。 使用されるメソッドはスイッチかサービスプロバイダーに頼っています。 或るものは[7]、Annex D.ノベルが両方のメソッドをサポートするセクション6l他のものサポート[3]をサポートします。
When a router is restarted, IPXWAN exchanges over active Frame Relay PVCs (that is, PVCs that have remained active before and after restart) can begin immediately.
ルータがすぐに再開されるとき、アクティブなFrame Relay PVCs(すなわち、再開の前後にアクティブなままで残っていたPVCs)の上のIPXWAN交換は始まることができます。
Each IPX packet is encapsulated in a Frame Relay frame sequence as defined in [3] without additional framing.
それぞれのIPXパケットは追加縁どりなしで[3]で定義されるようにFrame Relayフレーム系列でカプセルに入れられます。
When a router detects that a Frame Relay PVC has transitioned from an inactive to an active state, link establishment is considered complete and IPXWAN exchange over this newly activated link begins.
ルータがそれを検出するとき、a Frame Relay PVCが移行した、活動的な状態に不活発です、リンク設立は完全であると考えられて、この新たに動かされたリンクの上のIPXWAN交換は始まります。
When an active PVC becomes inactive, the router reflects the lost connectivity in its routing information database.
アクティブなPVCが不活発になると、ルータはルーティング情報データベースの無くなっている接続性を反映します。
1.5 Operation over other WAN media
1.5 他のWANメディアの上の操作
Additional WAN media will be added here as specifications are developed.
仕様が開発されているので、追加WANメディアはここで加えられるでしょう。
Allen [Page 3] RFC 1551 IPXWAN December 1993
アレン[3ページ]RFC1551IPXWAN1993年12月
2. Glossary Of Terms
2. 用語の用語集
Primary Network Number:
プライマリネットワーク・ナンバー:
Every IPX WAN router has a "primary network number". This is an
IPX network number unique to the entire internet. This number
will be a permanently assigned network number for the router.
Those readers familiar with NetWare 3.x servers should realize
that this is the "Internal" network number.
あらゆるIPX WANルータには、「プライマリネットワーク・ナンバー」があります。 これは全体のインターネットにユニークなIPXネットワーク・ナンバーです。 この数はルータの永久に割り当てられたネットワーク・ナンバーになるでしょう。 NetWare3.xサーバに詳しいそれらの読者は、これが「内部」のネットワーク・ナンバーであるとわかるべきです。
Router Name:
ルータ名:
Every IPX WAN router must have a "Router Name". This is a symbolic
name given to the router. Its purpose is to allow routers to know
who they are connected to after link establishment - particularly
for network management purposes. A symbolic name conveys more
information to an operator than a set of numbers. The symbolic
name should be between 1 and 47 characters in length containing
the characters 'A' through 'Z', underscore (_), hyphen (-) and
"at" sign (@). The string of characters should be followed by a
null character (byte of zero) and padded to 48 characters using
the null character. Those readers familiar with NetWare 3.x
servers should realize that the file server name is the Router
Name.
あらゆるIPX WANルータには、「ルータ名」がなければなりません。 これはルータに与えられた英字名です。 目的はだれにとって、それらが特にリンク設立の、後ネットワークマネージメント目的のために接続されているかを知るためにルータを許容することです。 英字名は一連の数字よりオペレータへの情報を伝えます。 英字名はキャラクタ''から'Z'、強調(_)、ハイフン(-)、および“at"サイン(@)を含む長さが1〜47のキャラクタであるべきです。 キャラクタのストリングは、ヌル文字を使用することでヌル文字(ゼロのバイト)があとに続いていて、48のキャラクタに水増しされるべきです。 NetWare3.xサーバに詳しいそれらの読者は、ファイルサーバー名がRouter Nameであるとわかるべきです。
For workstation (client) connectivity, it is useful if the client
connection software is configured with a symbolic name reflecting
the name of the client. This allows a router management utility to
determine which connection connects with which client/router. If
no name is configured, it is recommended that a default string
such as "DIAL-IN-CLIENT" is used.
ワークステーション(クライアント)の接続性に、クライアント接続ソフトウェアがクライアントの名前を反映する英字名によって構成されるなら、役に立ちます。 これで、ルータ管理ユーティリティは、どの接続がどのクライアント/ルータに接続するかを決定できます。 名前が全く構成されないなら、「ダイヤルインのクライアント」などのデフォルトストリングが使用されているのは、お勧めです。
3. IPX WAN Protocol Description
3. IPXの青白いプロトコル記述
After the underlying data link connection is established as described in the preceding media dependant description, the IPXWAN protocol is activated to exchange identities and determine certain operational charactaristics of the link.
基本的なデータリンク接続が前のメディア扶養家族記述で説明されるように確立された後に、IPXWANプロトコルは、アイデンティティを交換して、リンクのある操作上のcharactaristicsを決定するために活性化します。
There are two steps in the IPXWAN operation:
IPXWAN操作における2ステップがあります:
- Negotiating master/slave role and choice of routing protocol.
The master/slave roles persist for the IPXWAN exchanges only;
- マスター/奴隷の役割を交渉して、ルーティングの選択は議定書を作ります。 マスター/奴隷の役割はIPXWAN交換だけのために持続しています。
- Information exchange of final router configuration.
- 最終的なルータ構成の情報交換。
After these steps are concluded, transmission of IPX routing packets begins - using the routing protocol negotiated - as well as
これらのステップが結論づけられた後に、交渉されたルーティング・プロトコルを使用して、IPXルーティングパケットのトランスミッションは始まります--
Allen [Page 4] RFC 1551 IPXWAN December 1993
アレン[4ページ]RFC1551IPXWAN1993年12月
transmission of IPX data traffic.
IPXデータ通信量の送信。
3.1 The Initial Negotiation
3.1 初期の交渉
The first exchange of packets decides the master/slave roles and the routing protocol to be used on the link and gauges the link delay for the routing metrics. The initial negotiation is the same for all protocols.
パケットの第一交換は、リンクの上に使用されるためにマスター/奴隷の役割とルーティング・プロトコルについて決めて、ルーティング測定基準のためにリンク遅れを測ります。 すべてのプロトコルに、初期の交渉は同じです。
+---------------+ +---------------+
| Timer Request | | Timer Request |
+---------------+ +---------------+
\---->\ /<----/
\ /
x
/ \
/\ /<----/ \---->\ /\
/ \ / \
/ \ / \
/ My primary \ / My primary \
/ network address\ / network address\
\ is larger / \ is smaller /
\ / \ /
\ / \ /
\ / \ /
\/ \/
MASTER SLAVE
+---------------+ +---------------+ | タイマ要求| | タイマ要求| +---------------+ +---------------+ \---->\/<。----/\/x/\/\/<。----/ \---->\/\/\/\/\/\/、私のプライマリ\/ネットワークが\/ネットワーク・アドレス\\を扱う私のプライマリ\/が、より大きい/である、\は、より小さい/\/\/\/\/\/\/\/\/MASTER SLAVEです。
+----------------+
<----------------+ Timer Response +
+----------------+
+----------------+ <。----------------+ タイマ応答++----------------+
After link establishment, both sides of the link send Timer Request packets and start a timer waiting for a Timer Response. These Timer Requests are sent every 20 seconds until a response is received or a descision is made that the remote node is not responding. This could be after a predefined time (min. 60 seconds) or a number of retries (e.g., 16).
リンク設立の後に、タイマは、リンクの両側が、パケットをTimer Requestに送って、Timer Responseを待ち始めます。 応答が受け取られているか、またはdescisionが作られているこれらのTimer Requestsは20秒遠隔ノードが反応させていない送られた前毎です。 事前に定義された時間(60秒の分)か多くの再試行(例えば、16)の後に、これはあるかもしれません。
In composing the Timer Request, the router or workstation takes into consideration:
Timer Requestを構成する際に、ルータかワークステーションが考慮を連れていきます:
- Which types of routing protocols it supports;
- それがサポートするルーティング・プロトコルのどのタイプ。
- Whether it is prepared to assign a network address to the link;
- ネットワーク・アドレスをリンクに割り当てるのが準備されているか否かに関係なく。
- For workstations, whether they require the ability to specify
their network/NIC address on a reconnect;
- ワークステーションに関しては、彼らがaに関するそれらのネットワーク/NICアドレスを指定する能力を必要とするか否かに関係なく、再接続してください。
Allen [Page 5] RFC 1551 IPXWAN December 1993
アレン[5ページ]RFC1551IPXWAN1993年12月
- Whether it is able to support IPX header compression [6].
- それは、IPXがヘッダー圧縮[6]であるとサポートであることができるかどうか
For each routing protocol supported, place an option in the Timer Request packet. The Routing Type options should be added in the originator's order of preference with the most preferred option first.
サポートされた各ルーティング・プロトコルには、Timer Requestパケットにオプションを置いてください。 ルート設定Typeオプションは最初に、最も都合のよいオプションがある創始者のよく使われる順で加えられるべきです。
Some of the newer (or modified) routing protocols do not have the requirement to allocate a network number on a WAN link. This type of routing protocol has the advantage of potentially simpler configuration as no network number pools are necessary for WAN links. However, these router implementations may still wish to interoperate with the older IPXWAN implementations which are able to allocate network numbers to the WAN link. In this case, the following method is used to force the older implementation to become the link master. It should be noted that a router implementation capable of supporting workstation dial-in MUST be able to supply AT LEAST ONE network number on which the workstation can reside.
より新しくて(変更される)のルーティング・プロトコルのいくつかには、WANリンクの上にネットワーク・ナンバーを割り当てるという要件がありません。 どんなネットワーク・ナンバープールもWANリンクに必要でないので、このタイプのルーティング・プロトコルには、潜在的により簡単な構成の利点があります。 しかしながら、これらのルータ実装はWANリンクにネットワーク・ナンバーを割り当てることができるより古いIPXWAN実装でまだ共同利用していたがっているかもしれません。 この場合、以下のメソッドは、より古い実装がリンクマスターにするのに使用されます。 サポートワークステーションダイヤルインであることができるルータ実装がワークステーションが住むことができるネットワーク・ナンバーをAT LEAST ONEに供給できなければならないことに注意されるべきです。
If the router is prepared to assign an IPX network number to the link, it sends its primary network number in the Timer Request WNodeID field, and omits the Extended Node ID option. On the other hand, if the router is NOT prepared to assign an IPX network number to the link, it sets the Timer Request WNodeID field to zero, and includes its primary network number in an Extended Node ID option.
ルータがIPXネットワーク・ナンバーをリンクに割り当てるように準備されるなら、それは、Timer Request WNodeID分野でプライマリネットワーク・ナンバーを送って、Extended Node IDオプションを省略します。 他方では、ルータがIPXネットワーク・ナンバーをリンクに割り当てるように準備されないなら、それは、Timer Request WNodeID分野をゼロに設定して、Extended Node IDオプションでプライマリネットワーク・ナンバーを含めます。
Workstations follow a similar, but slightly different set of rules for setting the WNodeID field. If this is the first time the work- station is connecting to the router, the workstation will set the WNodeID to zero indicating the router should be the link master and allocate a network number for the new link. In this case, the work- station will respond to the router's Timer Request and acknowledge only the Workstation Routing Type option. Note that a workstation does NOT include an Extended Node ID option in it's timer request.
ワークステーションはWNodeID分野を設定するための同様の、しかし、わずかに異なったセットの規則に従います。 これが仕事ステーションがルータに接続するのが、初めてなら、ルータがリンクマスターであり、新しいリンクのネットワーク・ナンバーを割り当てるべきであるのを示さないのにワークステーションはWNodeIDを設定するでしょう。 この場合、仕事ステーションは、ルータのTimer Requestに応じて、Workstationルート設定Typeオプションだけを承諾するでしょう。 ワークステーションがそれのExtended Node IDオプションを含んでいないというメモによるタイマ要求です。
If the workstation is reconnecting a link after an earlier inactivity disconnect, it is necessary for the workstation to be able to specify its network, NIC address and "Router Name" field (so that file server connections can be maintained after the reconnect). In this case, the workstation will set its WNodeID field to FFFFFFFFh forcing itself to be the link master. In this case, the router will respond to the workstation's Timer Request with only the Workstation Router Type acknowledged.
ワークステーションが以前の不活発分離の後にリンクを再接続しているなら、ワークステーションがネットワークを指定できるのが必要です、NICアドレスと「ルータ名」分野、(ファイルサーバー接続を維持できるそう、再接続、) この場合、ワークステーションはそれ自体がリンクマスターであることを強制するFFFFFFFFhにWNodeID分野を設定するでしょう。 この場合、Workstation Router Typeだけが承認されている状態で、ルータはワークステーションのTimer Requestに応じるでしょう。
Further packets in the IPXWAN exchange MUST use the correct WNodeID (workstations will always use zero).
IPXWAN交換における一層のパケットは正しいWNodeIDを使用しなければなりません(ワークステーションはいつもゼロを使用するでしょう)。
Allen [Page 6] RFC 1551 IPXWAN December 1993
アレン[6ページ]RFC1551IPXWAN1993年12月
On receiving a Timer Request packet, a router determines its role - master or slave - for the remainder of the IPXWAN exchanges. The master role does not denote special privileges, it merely means that the router is the requestor in the ensuing request/response exchanges. The descision is made as follows:
Timer Requestパケットを受けると、ルータはIPXWAN交換の残りのために、役割(マスターか奴隷)を決定します。 マスターの役割は特権を指示しないで、それは、ルータが続く要求/応答交換で要請者であることを単に意味します。 descisionを以下の通りにします:
a) If there is an Extended Node ID present (and we understand
the option), this must be compared to our Primary Network
Number. If we have the lower Primary Network Number, we
MUST respond with a Timer Response and become the slave.
a) 存在しているExtended Node IDがあれば(私たちはオプションを理解しています)、私たちのPrimary Network Numberとこれを比較しなければなりません。 下側のPrimary Network Numberを持っているなら、私たちは、Timer Responseと共に応じて、奴隷にならなければなりません。
b) If there is NO Extended Node ID, we must compare the WNodeID
of the received Timer Request with our Primary Network Number
and respond if we have a lower number.
b) 私たちに下側の数があって、Extended Node IDが全くなければ、私たちは、容認されたTimer RequestのWNodeIDを私たちのPrimary Network Numberと比べて、応じなければなりません。
Note: The Primary Network Number for a workstation when
determining master/slave roles depends on whether the
workstation requires itself to be the master of slave. It
should compare the received WNodeID to that sent in it's own
Timer Request.
以下に注意してください。 マスター/奴隷の役割を決定するとき、ワークステーションのためのPrimary Network Numberはワークステーションが、それ自体が奴隷のマスターであることを必要とするかどうかによります。 それはそれの自身のTimer Requestで送られたそれと容認されたWNodeIDを比較するべきです。
The numeric comparisons are done by considering each byte of the WNodeID or Extended Node ID fields as an unsigned integer, and the first byte as most significant.
WNodeIDかExtended Nodeの各バイトが符号のない整数としてのID分野と、最も重要であるとして最初のバイトであると考えることによって、数値比較をします。
The link slave responds to the Timer Request with a Timer Response. To do so, each option in the received Timer Request is parsed. If an option is not supported (or recognized), that option is rejected by changing the WAccept field to "NO" for that option.
リンク奴隷はTimer Responseと共にTimer Requestに応じます。 そうするために、容認されたTimer Requestの各オプションは分析されます。 オプションがサポートされないなら(または、認識されます)、そのオプションは、そのオプションのためにWAccept分野を「いいえ」に変えることによって、拒絶されます。
When selecting the router type which will be used on the link, the first option in the Timer Request which can be supported should be accepted. All other router types should have the WAccept field set to "NO". A router MUST NOT accept workstation connectivity to a node which is another router.
リンクの上に使用されるルータタイプを選ぶとき、サポートすることができるTimer Requestの第1の選択を受け入れるべきです。 他のすべてのルータタイプが「いいえ」にWAccept分野を設定させるべきです。 ルータは別のルータであるノードにワークステーションの接続性を受け入れてはいけません。
Note: It is permitted for a router to support a numbered routing type, but not be able to assign the network number. In this case, that routing type can be selected only if the other router supports it and is able to assign the network number. This can be determined by the value of the received WNodeID field. If the router is unable to assign a network number to the link, it MUST support Unnumbered RIP and include this option in the Timer Requests.
以下に注意してください。 それは、ルータが番号付のルーティングがタイプであるとサポートしますが、ネットワーク・ナンバーを割り当てることができないことが許可されています。 この場合、もう片方のルータがそれをサポートして、ネットワーク・ナンバーを割り当てることができる場合にだけ、そのルーティングタイプを選ぶことができます。 これは容認されたWNodeID分野の値で決定できます。 ルータがネットワーク・ナンバーをリンクに割り当てることができないなら、それは、Timer RequestsにUnnumbered RIPをサポートして、このオプションを含まなければなりません。
If a router wishes to provide WAN Client access without supporting other WAN routing types, a potential problem arises since a router and WAN client would both just be sending a single Routing Type option indicating the use of WAN Client. The IPXWAN specification
ルータであるなら、他のWANがルーティングであるとサポートしない、WAN Clientを提供するという願望はタイプにアクセスします、ルータとWANクライアントはただ一つのルート設定TypeオプションにWAN Clientの使用をともにただ示させるでしょう、したがって、潜在的な問題が起こります。 IPXWAN仕様
Allen [Page 7] RFC 1551 IPXWAN December 1993
アレン[7ページ]RFC1551IPXWAN1993年12月
does not allow a WAN workstation to connect to another WAN workstation. The method for detecting this is that the sent and received Timer Requests have a single Routing Type defined of WAN Client. To overcome this problem, IPXWAN defines that a router MUST NOT send a single Routing Type if that type is just WAN Client. The router MUST additionally include one (or more) of the defined routing types (like WAN RIP) with the WAccept option set to NO. This is so that a workstation may detect that this is actually a router sending the Timer Request and not just another workstation trying to call a workstation. The extra option will serve to be a counted Routing Type that will be ignored. If a workstation detects it is connecting to another workstation, it should disconnect the link.
別のWANワークステーションにWANワークステーションを接続させないでください。 これを検出するためのメソッドは送られて容認されたTimer RequestsがWAN Clientについて独身のルート設定Typeを定義させるということです。 この問題を克服するために、IPXWANはそのタイプがただWAN Clientであるならルータが独身のルート設定Typeを送ってはいけないそのaを定義します。 ルータはさらに、WAcceptオプションがあるタイプ(WAN RIPのような)がNO.に設定する定義されたルーティングの1つ(さらに)を含まなければなりません。 これによるこれが実際にワークステーションがそれを検出できるためのただのワークステーションではなく、Timer Requestがワークステーションを呼ぼうとするのをさせるルータであるということです。 付加的なオプションは、無視される数えられたルート設定Typeであるのに役立つでしょう。 ワークステーションが検出する、それは別のワークステーションに接続していて、リンクから切断するべきです。
Note that a router supporting a workstation will need to be able to supply AT LEAST one network number for workstations. All dial-in workstations could share the same network, and be assigned unique node numbers by the router, or each workstation could be assigned a different network number. This is a router specific implementation detail. Use of a single network for all clients is prefered, however, this does involve extra work by the router when dealing with broadcast frames. When the router is the link master and allocating NIC addresses on a single network,it should ALWAYS use a unique value - by incrementing the NIC address for each client connection. This allows a workstation which is reconnecting the ability to specify his old network and NIC address. It is unlikely with a 6 byte NIC address, that there will be wrap-around in the numbers that would cause a problem. Router Node Number allocation should follow a few simple rules. The six byte NIC address SHOULD have the first byte set to 2.
ワークステーションをサポートするルータが、ワークステーションのネットワーク・ナンバーをAT LEAST1に供給できる必要に注意してください。 ユニークなノード番号がルータによって割り当てられたか、またはすべてのダイヤルインのワークステーションが同じネットワークを共有するかもしれません、そして、異なったネットワーク・ナンバーは各ワークステーションに割り当てることができました。 これはルータの特定の実装の詳細です。 ただ一つのネットワークのすべてのクライアントの使用はpreferedされて、放送フレームに対処するとき、しかしながら、これはルータで時間外労働にかかわります。 ルータがNICがただ一つのネットワークで演説するリンクマスターと割り当てであるときに、それは割り当てるべきであること。ALWAYSは、それぞれのクライアント接続のためにNICアドレスを増加することによって、ユニークな値を使用します。 これは彼の古いネットワークとNICアドレスを指定する能力を再接続しているワークステーションを許容します。 NICアドレス、それがそこでそうするのはそれが引き起こす数における巻きつけて着るドレスが問題であったなら6バイトにありそうもないです。 ルータNode Number配分はいくつかの簡単な規則に従うべきです。 6バイトのNICアドレスSHOULDは最初のバイトを2に設定させます。
Byte # +--1----2----3----4----5----6-+
| 02 | XX | XX | XX | XX | XX |
+-----------------------------+
バイト#+--1----2----3----4----5----6-+ | 02 | XX| XX| XX| XX| XX| +-----------------------------+
In an IEEE address space, this would represent a non-multicast, locally defined address. Node numbers of zero or -1 are not allowed.
IEEEアドレス空間では、これは非マルチキャストの、そして、局所的に定義されたアドレスを表すでしょう。 ゼロか-1のノード番号は許容されていません。
If a slave determines it cannot support any of the supplied routing protocols in the received Timer Request, it MUST issue a disconnect on the connection being established. The master of the link (determined when a Timer Response packet is received) is responsible for defining the network number that is to be used as a common network number for the new WAN link, and for calculating the RIP transport time that will be advertized to other RIP routers for the new link. This is calculated by stopping the timer which was started when a Timer Request was initiated and applying the algorithm in section 4.3.
奴隷が、容認されたTimer Requestの供給されたルーティング・プロトコルのどれかをサポートできないと決心しているなら、それは確立される接続のときに分離を発行しなければなりません。 リンク(Timer Responseパケットがいつ受け取られているかを決定する)のマスターは新しいWANの一般的なネットワーク・ナンバーがリンクされて、他のRIPルータにadvertizedされるRIP輸送時間について新しいリンクに計算するのに使用されることになっているネットワーク・ナンバーを定義するのに責任があります。 これは、Timer Requestが開始されたとき始動されたタイマを止めて、セクション4.3でアルゴリズムを適用することによって、計算されます。
Allen [Page 8] RFC 1551 IPXWAN December 1993
アレン[8ページ]RFC1551IPXWAN1993年12月
3.2 Information Exchange
3.2 情報交換
After exchanging Timer Request packets, the link master and slave have been determined, and the Routing Protocol to be used on the link is negotiated. The link master is now responsible for sending an Information Request packet to the slave specifying the network number to be used on the new link (zero for unnumbered RIP and On Demand), the calculated transport time to be used in the routing metric, the Router Name (for management purposes), and for a workstation connection, the NIC address the workstation will be adopting. The NIC address option is a separate option added in the Information Request/Response for workstation connectivity. It is NOT present for router to router connections.
Timer Requestパケットを交換した後に、リンクマスターと奴隷は断固としています、そして、リンクの上に使用されるべきルート設定プロトコルは交渉されます。 リンクマスターは現在新しいリンク(無数のRIPとOn Demandのためのゼロ)の上に使用されるためにネットワーク・ナンバーを指定する奴隷に情報Requestパケットを送るのに責任があります、ルーティングでメートル法で使用されるべき計算された輸送時間、Router Name(管理目的のために)、そして、ワークステーション接続、ワークステーションがそうするNICアドレスのための採用になってください。 NICアドレスオプションはワークステーションの接続性のための情報Request/応答で加えられた別々のオプションです。 ルータ接続において、それはルータのために存在していません。
If a router receives an inappropriate Information Request from a workstation trying to set the common network number and NIC address the router MUST overwrite these values with preferred values. When the workstation receives the Information Response, it MUST note the new values. If the workstation is unable to adjust to the new values, it MUST issue a disconnect on the link. If a workstation is the link master (i.e., it is reconnecting), the router is additionally responsible for ensuring the "Router Name" field matches that of the original connection. If the values differ, the call should be disconnected.
ルータが一般的なネットワーク・ナンバーとNICアドレスを設定しようとするワークステーションから不適当な情報Requestを受けるなら、ルータは都合のよい値でこれらの値を上書きしなければなりません。 ワークステーションが情報Responseを受けるとき、それは新しい値に注意しなければなりません。 ワークステーションが新しい値に適応できないなら、それはリンクの上に分離を発行しなければなりません。 ワークステーションがリンクマスター(すなわち、それは再接続されている)であるなら、ルータはさらに、マスターです。「ルータ名」分野マッチにオリジナルの接続のものを確実にするのに責任があります。 値が異なるなら、呼び出し切断されるべきです。
If a router detects an error for which no suitable protocol response exists (e.g., unable to allocate a network number), the link should be terminated according to the relevant media specification.
ルータがどんな適当なプロトコル応答も存在しない誤りを検出する、(例えば、ネットワーク・ナンバーを割り当てることができない、)、リンクは関連メディア仕様通りに終えられるべきです。
Under certain circumstances, particularly on X.25 permanent circuits, it is only possible to detect the remote router went away when it comes back up again. In this case, one side of the link receives a Timer Request packet when IPX is in a fully connected state. The side receiving the Timer Request MUST realize that a problem occurred, and revert to the IPX link establishment phase. Furthermore, the routing information learned from this connection should be immediately discarded.
ある状況の下と、そして、特にX.25の永久的な回路の上では、再び来て戻るとき、リモートルータを検出するのが遠ざかったのが、可能であるだけです。 この場合、IPXが完全に関連している状態にあるとき、リンクの半面はTimer Requestパケットを受けます。 Timer Requestを受ける側は、問題が起こったとわかって、IPXリンク確立段階に戻らなければなりません。 その上、この接続から学習されたルーティング情報はすぐに、捨てられるべきです。
When Unnumbered RIP, On-demand or Workstation options are negotiated, Information Request packets are repeated every 20 seconds until a response is received. For the Numbered RIP links, the Information Request is NOT resent. Instead, the link is disconnected after a suitable delay (min. 60 seconds) - this requirement ensures interoperabilty with earlier versions of IPXWAN. When Information Requests are repeated, they should continue for a preconfigured time (min. 60 seconds) or a preconfigured number of retries (e.g., 16). Each retry uses an incremented sequence number.
Unnumbered RIP、On-要求またはWorkstationオプションが交渉されるとき、応答が受け取られているまで、情報Requestパケットは20秒毎に繰り返されます。 Numbered RIPリンクに関しては、情報Requestは再送されません。 代わりに、リンク(60秒の分)のときに適当な遅れの後に切断されます--この要件はIPXWANの以前のバージョンでinteroperabiltyを確実にします。 情報Requestsが繰り返されるとき、彼らはあらかじめ設定された時間(60秒の分)かあらかじめ設定された数の再試行(例えば、16)のために続くべきです。 各再試行は増加している一連番号を使用します。
Allen [Page 9] RFC 1551 IPXWAN December 1993
アレン[9ページ]RFC1551IPXWAN1993年12月
3.3 NAK Packets
3.3 NAKパケット
The IPXWAN protocol uses a NAK packet to indicate the received IPXWAN packet was not acceptable. A NAK packet is an exact copy of the received packet with the WPacketType field set to NAK. There are two anticipated uses of this packet.
IPXWANプロトコルは、容認されたIPXWANパケットが許容できなかったのを示すのにNAKパケットを使用します。 NAKパケットはNAKに設定されたWPacketType分野がある容認されたパケットの正確なコピーです。 このパケットの2つの予期された用途があります。
- The received WPacketType is invalid or not recognized;
- 容認されたWPacketTypeは無効であるか認識されていません。
- A badly formed IPXWAN packet is received.
- ひどく形成されたIPXWANパケットは受け取られています。
Returning a NAK packet allows the sender a chance to work out what was wrong. If the sender was unable to determine the problem, the call can then be disconnected.
NAKパケットを返すと、問題であったことを解決する機会は送付者に許容されます。 送付者が問題を決定できなかったなら、呼び出しから切断することができます。
The value of the NAK WPacketType is FFh.
NAK WPacketTypeの値はFFhです。
4. Information Exchange Packet Formats
4. 情報交換パケット・フォーマット
All IPX WAN protocol exchanges utilize the standard Novell IPX packet format. The packets use the IPX defined packet type 04 defining a Packet Exchange Packet. The socket number 0x9004 is a Novell reserved socket number for exclusive use with IPX WAN protocol exchange. IPX defines that a network number of zero (0) is interpreted as being a local network of unknown number that requires no routing. This feature is of use to us in transferring these packets before the common network number is exchanged. Some routers need to know a "Node Number" (or MAC address) for each node on a link. Node numbers will be formed from the "WNode ID" field. The node number will be the 4 bytes of WNode ID followed by 2 bytes of zero. For a workstation, the node number will be explicitly assigned by the router and notified to the workstation in the Information Request packet.
すべてのIPX WANプロトコル交換が標準のノベルIPXパケット・フォーマットを利用します。 パケットはIPXの定義されたパケットタイプ04の定義しているa Packet Exchange Packetを使用します。 ソケットNo.0x9004はIPX WANプロトコル交換に伴う専用のノベルの予約されたソケット番号です。 IPXは(0)が掘るのを必要としない未知の数の企業内情報通信網であるので解釈されるそのaネットワーク・ナンバーのゼロを定義します。 この特徴は一般的なネットワーク・ナンバーを交換する前にこれらのパケットを移す際に私たちの役に立ちます。 いくつかのルータが、リンクの上のそれぞれのノードの「ノード番号」(または、MACアドレス)を知る必要があります。 ノード番号は「WNode ID」分野から形成されるでしょう。 ノード番号は4バイトのWNode IDになるでしょう2バイトのゼロがいうことになった。 ワークステーションに関しては、ノード番号は、ルータによって明らかに割り当てられて、情報Requestパケットのワークステーションに通知されるでしょう。
Router Type number assignment. Other vendors IPX routing protocols can make use of the IPXWAN protocol definition by obtaining Router Types from Novell. This document will then include the new Router Types (with the references to vendor protocol description documents). Current Routing Types are:
ルータType数の課題。 他のベンダーIPXルーティング・プロトコルは、ノベルからRouter Typesを入手することによって、IPXWANプロトコル定義を利用できます。 そして、このドキュメントは新しいRouter Types(ベンダープロトコル記述ドキュメントの参照がある)を含むでしょう。 現在のルート設定Typesは以下の通りです。
00 Numbered RIP/SAP
01 NLSP (no RIP/SAP - defined in [8])
02 Unnumbered RIP/SAP
03 On Demand, static routing (no RIP/SAP or NLSP)
04 Workstation (no RIP/SAP)
05-FF Currently undefined
00がリップ/SAP01NLSPに付番した、(RIP/SAPがありません--[8])02Unnumbered RIP/SAP03On Demand、スタティックルーティング(RIP/SAPでないNLSPがない)04では、未定義の状態でWorkstation(RIP/SAPがない)05-FF Currentlyを定義します。
WOption Number assignment. These numbers only need to be assigned from Novell for the "Timer Request" and "Timer Response" packets.
WOption Number課題。 これらの数は、「タイマ要求」と「タイマ応答」パケットのためにノベルから割り当てられる必要があるだけです。
Allen [Page 10] RFC 1551 IPXWAN December 1993
アレン[10ページ]RFC1551IPXWAN1993年12月
Packet Types also need to be assigned by Novell. However, the options within these packets are dependant on the "Router Type" negotiated. WOption numbers in these packets are then defined by the vendor defining the Routing Type. The same packet format should still be maintained.
また、パケットTypesは、ノベルによって割り当てられる必要があります。 しかしながら、これらのパケットの中のオプションは交渉された「ルータタイプ」の扶養家族です。 そして、これらのパケットのWOption番号はルート設定Typeを定義するベンダーによって定義されます。 同じパケット・フォーマットはまだ維持されているべきです。
Router Type 01 will not be described in this document since it involves knowledge of the NLSP protocol to implement. Please refer to [8] for a complete specification of these NLSP IPXWAN exchanges and the NLSP protocol.
本書では実装するNLSPプロトコルに関する知識にかかわるので、ルータType01は説明されないでしょう。 これらのNLSP IPXWAN交換とNLSPプロトコルの完全な仕様のための[8]を参照してください。
4.1 Timer Request Packet
4.1 タイマリクエスト・パケット
+---------------------------------------------------------------+
| Checksum | FF FF | Always FFFF |
| Packet Length | 02 40 | Max IPX size (576 bytes|
| | | Hi Lo order) |
| Trans Control | 00 | Hops traversed |
| Packet Type | 04 | Packet Exchange Packet |
| Dest Net # | 00 00 00 00 | Local Network |
| Dest Node # | FF FF FF FF FF FF | Broadcast |
| Dest Socket # | 90 04 | Reserved WAN socket |
| Source Net # | 00 00 00 00 | Local Network |
| Source Node # | 00 00 00 00 00 00 | Set to zero |
| Source Socket # | 90 04 | Reserved WAN socket |
|------------------+-------------------+------------------------|
| WIdentifier | 57 41 53 4D | Confidence identifier |
| WPacket Type | 00 | Timer Request |
| WNode ID | xx xx xx xx | Primary Net # of |
| | | sending router |
| | | (Hi Lo order) |
| WSequence # | xx | Sequence start at 0 |
| WNum Options | xx | Number of options |
|------------------+-------------------+------------------------|
| WOption Number | xx | Option Identifier |
| WAccept Option | xx | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | xx xx | Number of following |
| | | option bytes (Hi Lo) |
| WOption Data | nn | Option specific data |
+---------------------------------------------------------------+
+---------------------------------------------------------------+ | チェックサム| ff ff| いつもFFFF| | パケット長| 02 40 | マックスIPXサイズ(| | | | こんにちは、Loが命令する576バイト)| | 移-コントロール| 00 | 横断されたホップス| | パケットタイプ| 04 | パケット交換パケット| | Destネット#| 00 00 00 00 | 企業内情報通信網| | Destノード#| ff ff ff ff ff ff| 放送| | Destソケット#| 90 04 | 予約されたWANソケット| | ソースネット#| 00 00 00 00 | 企業内情報通信網| | ソースノード#| 00 00 00 00 00 00 | ゼロに、セットします。| | ソースソケット#| 90 04 | 予約されたWANソケット| |------------------+-------------------+------------------------| | WIdentifier| 57 41 53 4D| 信用識別子| | WPacketはタイプします。| 00 | タイマ要求| | WNode ID| xx xx xx xx| 予備選挙は#、を網で覆います。| | | | 送付ルータ| | | | (こんにちは、Loオーダー) | | WSequence#| xx| 0時の系列始め| | WNumオプション| xx| オプションの数| |------------------+-------------------+------------------------| | WOption番号| xx| オプション識別子| | WAcceptオプション| xx| 0 = いいえ、1ははいと等しく、3はどんなApplicとも等しくはありません。| | WOption Dataレン| xx xx| 次の事柄の数| | | | オプションバイト(こんにちは、Lo)| | WOptionデータ| nn| オプションの特定のデータ| +---------------------------------------------------------------+
Routing Type Option:
One or more of the following router type options should be included
in a Timer Request packet. A router should ALWAYS include Routing
Type zero (0) if full interoperability is required with an older
implementation. The router types MUST be included in the senders
order of preference. If a router receives a Timer Response with more
than one Router Type having WAccept set to Yes, the link MUST be
ルート設定タイプオプション: 以下のルータタイプオプションの1つ以上はTimer Requestパケットに含まれるべきです。 ルータは含むべきです。(0) 最大限のインターオペラビリティが、より古い実装で必要であるなら、ALWAYSはルート設定Typeゼロを含んでいます。 送付者よく使われる順にルータタイプを含まなければなりません。 ルータがはい、リンクに用意ができさせるWAcceptを1Router Typeでなければならないより以上でTimer Responseを受けるなら
Allen [Page 11] RFC 1551 IPXWAN December 1993
アレン[11ページ]RFC1551IPXWAN1993年12月
disconnected.
切断される。
+---------------------------------------------------------------+
| WOption Number | 00 | Define Routing Type |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 01 | Option length (Hi Lo) |
| WOption Data | 00 | IPX RIP/SAP Routing |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| WOption Number | 00 | Define Routing Type |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 01 | Option length (Hi Lo) |
| WOption Data | 01 | NLSP |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| WOption Number | 00 | Define Routing Type |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 01 | Option length (Hi Lo) |
| WOption Data | 02 | Unnumbered RIP/SAP |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| WOption Number | 00 | Define Routing Type |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 01 | Option length (Hi Lo) |
| WOption Data | 03 | On-demand, static Rting|
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| WOption Number | 00 | Define Routing Type |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 01 | Option length (Hi Lo) |
| WOption Data | 04 | Client - No RIP/SAP |
| | | except on request |
+---------------------------------------------------------------+
+---------------------------------------------------------------+ | WOption番号| 00 | ルート設定タイプを定義してください。| | WAcceptオプション| 01 | 0 = いいえ、1ははいと等しく、3はどんなApplicとも等しくはありません。| | WOption Dataレン| 00 01 | オプションの長さ(こんにちは、Lo)| | WOptionデータ| 00 | IPXはルート設定を裂くか、または徐々に破壊します。| +---------------------------------------------------------------+ +---------------------------------------------------------------+ | WOption番号| 00 | ルート設定タイプを定義してください。| | WAcceptオプション| 01 | 0 = いいえ、1ははいと等しく、3はどんなApplicとも等しくはありません。| | WOption Dataレン| 00 01 | オプションの長さ(こんにちは、Lo)| | WOptionデータ| 01 | NLSP| +---------------------------------------------------------------+ +---------------------------------------------------------------+ | WOption番号| 00 | ルート設定タイプを定義してください。| | WAcceptオプション| 01 | 0 = いいえ、1ははいと等しく、3はどんなApplicとも等しくはありません。| | WOption Dataレン| 00 01 | オプションの長さ(こんにちは、Lo)| | WOptionデータ| 02 | 無数の裂け目/SAP| +---------------------------------------------------------------+ +---------------------------------------------------------------+ | WOption番号| 00 | ルート設定タイプを定義してください。| | WAcceptオプション| 01 | 0 = いいえ、1ははいと等しく、3はどんなApplicとも等しくはありません。| | WOption Dataレン| 00 01 | オプションの長さ(こんにちは、Lo)| | WOptionデータ| 03 | 要求次第の、そして、静的なRting| +---------------------------------------------------------------+ +---------------------------------------------------------------+ | WOption番号| 00 | ルート設定タイプを定義してください。| | WAcceptオプション| 01 | 0 = いいえ、1ははいと等しく、3はどんなApplicとも等しくはありません。| | WOption Dataレン| 00 01 | オプションの長さ(こんにちは、Lo)| | WOptionデータ| 04 | クライアント--裂け目/SAPがありません。| | | | 要求に応じて除いてください。| +---------------------------------------------------------------+
Extended Node ID Option:
The extended node ID should only be included if the WNodeID field is
set to zero AND the node constructing the packet is a router. Note
that an older version of IPXWAN will just reject this option and
automatically become the link master as the WNodeID is zero.
拡張ノードIDオプション: WNodeID分野がゼロに設定される場合にだけ、拡張ノードIDは含まれるべきです、そして、パケットを組み立てるノードはルータです。 WNodeIDがゼロであるときに、IPXWANの旧式のバージョンがただこのオプションを拒絶して、自動的にリンクマスターになることに注意してください。
+---------------------------------------------------------------+
| WOption Number | 04 | Extended Node ID |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 04 | Pad data length (Hi Lo)|
| WOption Data | xx xx xx xx | Real primary network # |
| | | of this router (Hi-Lo) |
+---------------------------------------------------------------+
+---------------------------------------------------------------+ | WOption番号| 04 | 拡張Node ID| | WAcceptオプション| 01 | 0 = いいえ、1ははいと等しく、3はどんなApplicとも等しくはありません。| | WOption Dataレン| 00 04 | パッドデータの長さ(こんにちは、Lo)| | WOptionデータ| xx xx xx xx| 本当のプライマリネットワーク#| | | | このルータ(高Lo)について| +---------------------------------------------------------------+
Allen [Page 12] RFC 1551 IPXWAN December 1993
アレン[12ページ]RFC1551IPXWAN1993年12月
Header Compression Option:
Although more than one header compression option may be specified in
a Timer Request packet, it is important that a MAXIMUM of ONE header
compression option is accepted. If an implementation receives a
Timer Response with more than one header compression option with the
accept option set to Yes, the link MUST be disconnected. [Ref 6]
defines the full Telebit Header Compression method.
ヘッダー圧縮オプション: 1つ以上のヘッダー圧縮オプションがTimer Requestパケットで指定されるかもしれませんが、ONEヘッダー圧縮オプションのMAXIMUMを受け入れるのは重要です。 実装が1つ以上のヘッダー圧縮オプションがあるTimer Responseを受ける、はい、リンクへのセットから切断しなければならないオプションを受け入れてください。 [審判6]は完全なテレビットHeader Compressionメソッドを定義します。
+---------------------------------------------------------------+
| WOption Number | 80 | Header Compression |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 03 | Variable - at least 1 |
| WOption Data | 00 | 0 = Telebit Hdr Compr. |
| | xx | Compression Options |
| | xx | Compression Slots |
+---------------------------------------------------------------+
+---------------------------------------------------------------+ | WOption番号| 80 | ヘッダー圧縮| | WAcceptオプション| 01 | 0 = いいえ、1ははいと等しく、3はどんなApplicとも等しくはありません。| | WOption Dataレン| 00 03 | 変数--少なくとも1| | WOptionデータ| 00 | 0はテレビットHdr Comprと等しいです。 | | | xx| 圧縮オプション| | | xx| 圧縮スロット| +---------------------------------------------------------------+
PAD Option:
The PAD option is used to fill the Timer Request up to the 576 byte
limit. This field will be of variable length depending on the number
of other options in the packet. This option will normally be the
last entry in the packet. Its sole purpose is to fill the IPX
packet to be 576 bytes. The pad option data should be filled with a
selection of totally random numbers to avoid compression modems or
PPP data compression from destroying the link delay calculation.
Note that this is different from the original RFC 1362
specification. This should not affect implementations.
Implementations should not attempt to verify the contents of a PAD
option.
オプションを水増ししてください: PADオプションは、Timer Requestを576バイトの限界までいっぱいにするのに使用されます。 この分野には、可変長をパケットの別の選択肢の数に依存するのがあるでしょう。 通常、このオプションはパケットで最後のエントリーになるでしょう。 唯一の目的は576バイトになるようにIPXパケットをいっぱいにすることです。 パッドオプションデータは、リンク遅れ計算を破壊するので圧縮モデムかPPPデータ圧縮を避けるためにいくつかの完全に無作為の数で満たされるべきです。 これがオリジナルのRFC1362仕様と異なっていることに注意してください。 これは実装に影響するべきではありません。 実装は、PADオプションのコンテンツについて確かめるのを試みるべきではありません。
+---------------------------------------------------------------+
| WOption Number | FF | Pad option |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | xx xx | Pad data length (Hi Lo)|
| | | (enough to fill packet)|
| WOption Data | Random numbers | |
+---------------------------------------------------------------+
+---------------------------------------------------------------+ | WOption番号| ff| パッドオプション| | WAcceptオプション| 01 | 0 = いいえ、1ははいと等しく、3はどんなApplicとも等しくはありません。| | WOption Dataレン| xx xx| パッドデータの長さ(こんにちは、Lo)| | | | (パケットをいっぱいにすることができるくらいの)| | WOptionデータ| 乱数| | +---------------------------------------------------------------+
Note:
Timer Request packets will always be 576 bytes. However,
there should be no assumption made about the number of
options specified in this packet.
以下に注意してください。 タイマRequestパケットはいつも576バイトになるでしょう。 しかしながら、このパケットで指定されたオプションの数に関してされた仮定が全くあるべきではありません。
After link establishment, Timer Request packets are sent by both sides of the link. Each end starts their sequence number at zero. Subsequent retries (every 20 seconds) will increment the value of this sequence number. Only a Timer Response packet with a sequence number matching the last sent sequence number will be acted upon.
リンク設立の後に、リンクの両側はTimer Requestパケットを送ります。 各端はゼロでそれらの一連番号を始めます。 その後の再試行(20秒毎)はこの一連番号の値を増加するでしょう。 一連番号が最後に送られた一連番号に合っているTimer Responseパケットだけが作用されるでしょう。
Allen [Page 13] RFC 1551 IPXWAN December 1993
アレン[13ページ]RFC1551IPXWAN1993年12月
As mentioned earlier, the WNodeID field may be set to zero for a router if it is unable to provide a network number for the link. If a router ONLY supports the Numbered RIP/SAP option, it MUST be capable of proving a network number for a WAN link.
先に述べたように、それがリンクのネットワーク・ナンバーを提供できないなら、WNodeID分野はルータのためにゼロに設定されるかもしれません。 ルータが、Numbered RIP/SAPがオプションであるとサポートするだけであるなら、WANリンクのネットワーク・ナンバーを立証できなければなりません。
Packets received on the reserved socket number not having the WIdentifier set to the hexadecimal values noted above should be discarded.
上に述べられた16進値にWIdentifierを用意ができさせない予約されたソケット番号に受け取られたパケットは捨てられるべきです。
4.2 Timer Response Packet
4.2 タイマ応答パケット
+---------------------------------------------------------------+
| Checksum | FF FF | Always FFFF |
| Packet Length | 02 40 | Max IPX size (576 bytes|
| | | Hi Lo order) |
| Trans Control | 00 | Hops traversed |
| Packet Type | 04 | Packet Exchange Packet |
| Dest Net # | 00 00 00 00 | Local Network |
| Dest Node # | FF FF FF FF FF FF | Broadcast |
| Dest Socket # | 90 04 | Reserved WAN socket |
| Source Net # | 00 00 00 00 | Local Network |
| Source Node # | 00 00 00 00 00 00 | Set to zero |
| Source Socket # | 90 04 | Reserved WAN socket |
|------------------+-------------------+------------------------|
| WIdentifier | 57 41 53 4D | Confidence identifier |
| WPacket Type | 01 | Timer Response |
| WNode ID | xx xx xx xx | Primary Net # of |
| | | sending router |
| | | (Hi Lo order) |
| WSequence # | xx | Same as Timer Request |
| | | received |
| WNum Options | xx | Number of options |
|------------------+-------------------+------------------------|
| WOption Number | xx | Option Identifier |
| WAccept Option | xx | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | xx xx | Number of following |
| | | option bytes (Hi Lo) |
| WOption Data | nn | Option specific data |
+---------------------------------------------------------------+
+---------------------------------------------------------------+ | チェックサム| ff ff| いつもFFFF| | パケット長| 02 40 | マックスIPXサイズ(| | | | こんにちは、Loが命令する576バイト)| | 移-コントロール| 00 | 横断されたホップス| | パケットタイプ| 04 | パケット交換パケット| | Destネット#| 00 00 00 00 | 企業内情報通信網| | Destノード#| ff ff ff ff ff ff| 放送| | Destソケット#| 90 04 | 予約されたWANソケット| | ソースネット#| 00 00 00 00 | 企業内情報通信網| | ソースノード#| 00 00 00 00 00 00 | ゼロに、セットします。| | ソースソケット#| 90 04 | 予約されたWANソケット| |------------------+-------------------+------------------------| | WIdentifier| 57 41 53 4D| 信用識別子| | WPacketはタイプします。| 01 | タイマ応答| | WNode ID| xx xx xx xx| 予備選挙は#、を網で覆います。| | | | 送付ルータ| | | | (こんにちは、Loオーダー) | | WSequence#| xx| タイマ要求と同じこと| | | | 受信します。| | WNumオプション| xx| オプションの数| |------------------+-------------------+------------------------| | WOption番号| xx| オプション識別子| | WAcceptオプション| xx| 0 = いいえ、1ははいと等しく、3はどんなApplicとも等しくはありません。| | WOption Dataレン| xx xx| 次の事柄の数| | | | オプションバイト(こんにちは、Lo)| | WOptionデータ| nn| オプションの特定のデータ| +---------------------------------------------------------------+
The options contained within this packet are as described in section 4.1 Any unknown options or not supported options within the Timer Request MUST have the WAccept Option set to NO in the Timer Response.
Timer ResponseでいいえとWAccept OptionがTimer Requestの中のサポートしているオプションではなく、Anyの未知のオプションでセットしなければならないセクション4.1で説明するようにこのパケットの中に含まれたオプションがあります。
If the Timer Request packet contained more than one Router Type option and the "Slave" supports all the options, the "Slave" MUST set the WAccept Option to YES on the FIRST Router Type supported and NO to ALL other Router Types. This is the Router Type which is to be
Timer Requestパケットが1つ以上のRouter Typeオプションを含んで、「奴隷」が、すべてがオプションであることをサポートするなら、「奴隷」はサポートされたFIRST Router TypeにはいにWAccept Optionを設定しなければなりません、そして、他のすべてのRouter Types、いいえ。 これがそうするRouter Typeである、
Allen [Page 14] RFC 1551 IPXWAN December 1993
アレン[14ページ]RFC1551IPXWAN1993年12月
adopted by both ends of the link. Information exchanges will then proceed by the link master based on the accepted Router Type.
リンクの両端で、採用されます。 そして、情報交換は受け入れられたRouter Typeに基づくリンクマスターで続くでしょう。
This packet must contain the same sequence number as the received Timer Request. This packet should ONLY be sent by the router or workstation determining themselves to be the "Slave" of the link. (Workstations are ALWAYS the link slave).
このパケットは容認されたTimer Requestと同じ一連番号を含まなければなりません。 自分たちがリンクの「奴隷」であると決定するルータかワークステーションはこのパケットを送るだけであるべきです。 (ワークステーションはリンク奴隷のALWAYSです。)
Routers MUST set the WNodeID to their correct value when responding with the Timer Response. A value of zero must NOT be used.
Timer Responseと共に応じるとき、ルータはそれらの正しい値にWNodeIDを設定しなければなりません。 ゼロの値を使用してはいけません。
4.3 Information Request Packet
4.3 情報リクエスト・パケット
+---------------------------------------------------------------+
| Checksum | FF FF | Always FFFF |
| Packet Length | 00 63 | Size of header+data |
| | | (Hi Lo order) |
| Trans Control | 00 | Hops traversed |
| Packet Type | 04 | Packet Exchange Packet |
| Dest Net # | 00 00 00 00 | Local Network |
| Dest Node # | FF FF FF FF FF FF | Broadcast |
| Dest Socket # | 90 04 | Reserved WAN socket |
| Source Net # | 00 00 00 00 | Local Network |
| Source Node # | 00 00 00 00 00 00 | Set to zero |
| Source Socket # | 90 04 | Reserved WAN socket |
|------------------+-------------------+------------------------|
| WIdentifier | 57 41 53 4D | Confidence identifier |
| WPacket Type | 02 | Information Request |
| WNode ID | xx xx xx xx | Primary Net # of |
| | | sending router |
| | | (Hi Lo order) |
| WSequence # | 00 | Sequence start at 0 |
| WNum Options | 01 | 1 Option to follow |
| WOption Number | 01 | Define IPX RIP/SAP |
| | | info exchange |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 36 | Option length (Hi Lo) |
| WOption Data | | |
| Link Delay | xx xx | Hi Lo link delay in |
| | | milli seconds (see |
| | | below for calculation) |
| Common Net # | xx xx xx xx | Hi Lo Common Network # |
| Router Name | xx (x 48 decimal) | Router name - as defned|
| | | in section 2. |
+---------------------------------------------------------------+
+---------------------------------------------------------------+ | チェックサム| ff ff| いつもFFFF| | パケット長| 00 63 | ヘッダー+データのサイズ| | | | (こんにちは、Loオーダー) | | 移-コントロール| 00 | 横断されたホップス| | パケットタイプ| 04 | パケット交換パケット| | Destネット#| 00 00 00 00 | 企業内情報通信網| | Destノード#| ff ff ff ff ff ff| 放送| | Destソケット#| 90 04 | 予約されたWANソケット| | ソースネット#| 00 00 00 00 | 企業内情報通信網| | ソースノード#| 00 00 00 00 00 00 | ゼロに、セットします。| | ソースソケット#| 90 04 | 予約されたWANソケット| |------------------+-------------------+------------------------| | WIdentifier| 57 41 53 4D| 信用識別子| | WPacketはタイプします。| 02 | 情報要求| | WNode ID| xx xx xx xx| 予備選挙は#、を網で覆います。| | | | 送付ルータ| | | | (こんにちは、Loオーダー) | | WSequence#| 00 | 0時の系列始め| | WNumオプション| 01 | 1 続くオプション| | WOption番号| 01 | IPX裂け目/SAPを定義してください。| | | | インフォメーション交換| | WAcceptオプション| 01 | 0 = いいえ、1ははいと等しく、3はどんなApplicとも等しくはありません。| | WOption Dataレン| 00 36 | オプションの長さ(こんにちは、Lo)| | WOptionデータ| | | | リンク遅れ| xx xx| こんにちは、Loは遅れをリンクします。| | | | ミリ秒(計算に関して| | | | 下を見ます)| | 一般的なネット#| xx xx xx xx| こんにちは、最低気温の一般的なネットワーク#| | ルータ名| xx(x48小数)| defnedされるとしてのルータ名| | | | セクション2で。 | +---------------------------------------------------------------+
Routers MUST set the WNodeID to their correct value when sending an Information Request. A value of zero must NOT be used.
情報Requestを送るとき、ルータはそれらの正しい値にWNodeIDを設定しなければなりません。 ゼロの値を使用してはいけません。
Allen [Page 15] RFC 1551 IPXWAN December 1993
アレン[15ページ]RFC1551IPXWAN1993年12月
A workstation should replace the Router Name with the configured name, or a constant descriptor string as described in section 2.
ワークステーションはセクション2で説明されるようにRouter Nameを構成された名前、または一定の記述子ストリングに取り替えるはずです。
For a Workstation Information Request, an extra option is added which specifies the NIC address for the workstation. In this case, the number of options will be set to two (2).
Workstation情報Requestに関しては、ワークステーションのためのNICアドレスを指定する付加的なオプションは加えられます。 この場合、オプションの数は2(2)に設定されるでしょう。
+---------------------------------------------------------------+
| WOption Number | 05 | Define NIC Address |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 06 | Option length (Hi Lo) |
| WOption Data | 02 xx xx xx xx xx | NIC Address for W/S |
+---------------------------------------------------------------+
+---------------------------------------------------------------+ | WOption番号| 05 | NICアドレスを定義してください。| | WAcceptオプション| 01 | 0 = いいえ、1ははいと等しく、3はどんなApplicとも等しくはありません。| | WOption Dataレン| 00 06 | オプションの長さ(こんにちは、Lo)| | WOptionデータ| 02 xx xx xx xx xx| NICが扱う、S| +---------------------------------------------------------------+
Routers or workstations should not refuse to use a NIC address having a first byte with a value other than 02.
ルータかワークステーションが、02以外の値に従った最初のバイトを持っているNICアドレスを使用するのを拒否するはずがありません。
Calculation of link delay is performed as follows:
リンク遅れの計算は以下の通り実行されます:
// Start_time is a time stamp when Timer Request sent out
// End_time is a time stamp when a Timer Response is
// received.
link_delay = end_time - start_time; // 1/18th second
if (link_delay < 1)
{
link_delay = 1;
}/*IF*/
// We are on a slow net, so add some biasing to help stop
// multiple workstation sessions timing out on the link
link_delay *= 6; /* Add the biasing for multiple sessions */
link_delay *= 55; /* Convert link delay to milliseconds */
//スタート_時間はTimer Requestが//終わりの_時間を出したとき、Timer Responseが//受け取られているとき、タイムスタンプがタイムスタンプであるということです。_遅れ=終わり_時間をリンクしてください--_時間を始めてください。 // 1/18th second、(リンク_遅れ<1) リンク_遅れ=1; /が**///であるならaでネットを遅くするので、リンクリンク_遅れ*=6の外で複数のワークステーションセッションの助け停止//にタイミングに偏りながら、いくつかを加えてください。 /*は複数のセッション*/リンク_遅れ*=55のためのバイアスを加えます。 ミリセカンド*/への/*転向者リンク遅れ
If a higher resolution timer is available, better results may be
obtained using the following algorithm:
より高い解決タイマが利用可能であるなら、以下のアルゴリズムを使用することで、より良い結果を得るかもしれません:
conversion_factor = number of timer units in 1/18th second;
link_delay = ((end_time - start_time) * 6) / conversion_factor;
if (link_delay == 0)
{
link_delay = 1;
}/*IF*/
link_delay *= 55; /* Convert link delay to milliseconds */
1/第18 2番目のタイマユニットの変換_要素=番号。 _遅れ=(_時間終わり--始め_時間)*6)/変換_要素をリンクしてください。 (リンク_遅れ=0) リンク_遅れ=1; /は**/リンク_遅れ*であるなら55と等しいです。 ミリセカンド*/への/*転向者リンク遅れ
The "Link Delay" is used as the network transport time when advertized in the IPX RIP packet tuple for the network entry "Common Net #". For a consistent network, a common link delay is required at both ends of the link and is calculated by the link "Master". Link Delay is specified in milli seconds.
ネットワークエントリー「一般的なネット#」のためにIPX RIPパケットtupleでadvertizedされると、「リンク遅れ」はネットワーク輸送時間として使用されます。 一貫したネットワークにおいて、普通リンク遅れは、リンクの両端で必要であり、リンク「マスター」によって計算されます。 リンクDelayはミリ秒以降、指定されます。
Allen [Page 16] RFC 1551 IPXWAN December 1993
アレン[16ページ]RFC1551IPXWAN1993年12月
The Common Net # is supplied by the link "Master". This number must be unique in the connected internetwork. Each WAN call requires a separate number. If the negotiated Router Type was Unnumbered RIP, On-demand, or NLSP, the specified Common Net # will be zero.
Commonネット#はリンク「マスター」によって供給されます。 この数は接続インターネットワークでユニークであるに違いありません。 それぞれのWAN呼び出しは別々の数を必要とします。 交渉されたRouter TypeがUnnumbered RIP、On-要求、またはNLSPであったなら、指定されたCommonネット#はゼロになるでしょう。
This packet should contain a sequence number starting at zero. This packet should ONLY be sent by the router or workstation determining themselves to be the "Slave" of the link.
このパケットはゼロから出発する一連番号を含むはずです。 自分たちがリンクの「奴隷」であると決定するルータかワークステーションはこのパケットを送るだけであるべきです。
If extra options are included in this packet, they should be silently discarded.If the information option is missing, the link MUST be disconnected.
付加的なオプションがこのパケットに含まれているなら、それらは静かに、情報がゆだねるdiscarded.Ifがなくなる、リンクから切断しなければならないということであるべきです。
Allen [Page 17] RFC 1551 IPXWAN December 1993
アレン[17ページ]RFC1551IPXWAN1993年12月
4.4 Information Response Packet
4.4 情報応答パケット
+---------------------------------------------------------------+
| Checksum | FF FF | Always FFFF |
| Packet Length | 00 63 | Size of header+data |
| | | (Hi Lo Order) |
| Trans Control | 00 | Hops traversed |
| Packet Type | 04 | Packet Exchange Packet |
| Dest Net # | 00 00 00 00 | Local Network |
| Dest Node # | FF FF FF FF FF FF | Broadcast |
| Dest Socket # | 90 04 | Reserved WAN socket |
| Source Net # | 00 00 00 00 | Local Network |
| Source Node # | 00 00 00 00 00 00 | Set to zero |
| Source Socket # | 90 04 | Reserved WAN socket |
|------------------+-------------------+------------------------|
| WIdentifier | 57 41 53 4D | Confidence identifier |
| WPacket Type | 03 | Information Response |
| WNode ID | xx xx xx xx | Primary Net # of |
| | | sending router |
| | | (Hi Lo order) |
| WSequence # | 00 | Same as Info Request |
| WNum Options | 01 | 1 Option to follow |
| WOption Number | 01 | Define IPX RIP/SAP |
| | | info exchange |
| WAccept Option | 01 | 0=No,1=Yes,3=Not Applic|
| WOption Data Len | 00 36 | Option length (Hi Lo) |
| WOption Data | | |
| Link Delay | xx xx | Hi Lo link delay (as |
| | | received in Info Requ) |
| Common Net # | xx xx xx xx | Hi Lo Common Network # |
| | | (as received in Info |
| | | request) |
| Router Name | xx (x 48 decimal) | Router name - as defned|
| | | in section 2. |
+---------------------------------------------------------------+
+---------------------------------------------------------------+ | チェックサム| ff ff| いつもFFFF| | パケット長| 00 63 | ヘッダー+データのサイズ| | | | (こんにちは、最低気温オーダー) | | 移-コントロール| 00 | 横断されたホップス| | パケットタイプ| 04 | パケット交換パケット| | Destネット#| 00 00 00 00 | 企業内情報通信網| | Destノード#| ff ff ff ff ff ff| 放送| | Destソケット#| 90 04 | 予約されたWANソケット| | ソースネット#| 00 00 00 00 | 企業内情報通信網| | ソースノード#| 00 00 00 00 00 00 | ゼロに、セットします。| | ソースソケット#| 90 04 | 予約されたWANソケット| |------------------+-------------------+------------------------| | WIdentifier| 57 41 53 4D| 信用識別子| | WPacketはタイプします。| 03 | 情報応答| | WNode ID| xx xx xx xx| 予備選挙は#、を網で覆います。| | | | 送付ルータ| | | | (こんにちは、Loオーダー) | | WSequence#| 00 | インフォメーション要求と同じこと| | WNumオプション| 01 | 1 続くオプション| | WOption番号| 01 | IPX裂け目/SAPを定義してください。| | | | インフォメーション交換| | WAcceptオプション| 01 | 0 = いいえ、1ははいと等しく、3はどんなApplicとも等しくはありません。| | WOption Dataレン| 00 36 | オプションの長さ(こんにちは、Lo)| | WOptionデータ| | | | リンク遅れ| xx xx| こんにちは、Loが遅れをリンクする、(| | | | 容認されたコネInfo Requ、)| | 一般的なネット#| xx xx xx xx| こんにちは、最低気温の一般的なネットワーク#| | | | (Info| | | | 要求で受け取られている)です。 | | ルータ名| xx(x48小数)| defnedされるとしてのルータ名| | | | セクション2で。 | +---------------------------------------------------------------+
The responses contained within this packet are as described in section 4.3.
このパケットの中に含まれた応答がセクション4.3で説明されるようにあります。
A link slave will additionally respond with the received NIC address option as a confirmation of receipt. A workstation should replace the Router Name with the configured name, or a constant descriptor string as described in section 2. If the Information Request contained an inappropriate Common Net # or NIC address, the Information Response may set new values. The receiver of the Information Response is responsible for checking on the value and terminating the connection if the new values cannot be used.
リンク奴隷は領収書の確認として容認されたNICアドレスオプションでさらに、応じるでしょう。 ワークステーションはセクション2で説明されるようにRouter Nameを構成された名前、または一定の記述子ストリングに取り替えるはずです。 情報Requestが不適当なCommonネット#かNICアドレスを含んだなら、情報Responseは新しい値を設定するかもしれません。 情報Responseの受信機は新しい値を使用できないなら、値について検査して、接続を終えるのに原因となります。
Allen [Page 18] RFC 1551 IPXWAN December 1993
アレン[18ページ]RFC1551IPXWAN1993年12月
Routers MUST set the WNodeID to their correct value when sending an Information Response. A value of zero must NOT be used.
情報Responseを送るとき、ルータはそれらの正しい値にWNodeIDを設定しなければなりません。 ゼロの値を使用してはいけません。
5. Running Unnumbered RIP
5. 実行の無数の裂け目
Unnumbered RIP refers to the case where two WAN routers are communicating using the RIP protocol across a link with NO physical IPX network address. The premise for this ability is that there is no need to address a packet to anything on that WAN link. RIP and SAP run in exactly the same way as before, except the source and destination network numbers should be set to zero.
無数のRIPは2つのWANルータが物理的なIPXネットワーク・アドレスがないとのリンクの向こう側にRIPプロトコルを使用することで交信しているケースを示します。 この能力のための前提によるそのWANリンクの上に何にもパケットを扱う必要は全くないということです。 RIPとSAPは従来と同様まさに同じ道に立候補します、ソースと合わせてくださいネットワーク・ナンバーが設定されるべきであるゼロ目的地を除いて。
The advantage to running unnumbered RIP links is that it is not necessary to allocate/configure a pool of usable IPX network numbers which can be used on the WAN links. The other advantage is that when there is a large number of WAN links, it is not necessary to flood the network with an unnecessary set of extra RIP information.
実行している無数のRIPリンクの利点はWANリンクの上に使用できる使用可能なIPXネットワーク・ナンバーのプールを割り当てるか、または構成するのが必要でないということです。 もう片方の利点は多くのWANリンクがあるとき、付加的な不要なRIP情報でネットワークをあふれさせるのが必要でないということです。
6. Workstation Connectivity
6. ワークステーションの接続性
Workstations MUST reside on a network and have a unique NIC address on that network to be individually addressable. However, workstations do not need to periodically receive RIP and SAP broadcasts as they play no part in the routing process. This allows routers to reduce background traffic on the workstation link by not sending any periodic RIP and SAP data. Note that it will not cause a problem if the RIP and SAP is sent. It will just slow down the workstation access times.
ワークステーションは、そのネットワークにネットワークに住んでいて、個別にアドレス可能になるようにユニークなNICアドレスを持たなければなりません。 しかしながら、ルーティングプロセスで役割を全く演じないとき、ワークステーションは定期的にRIPとSAP放送を受け取る必要はありません。 これで、ルータは、ワークステーションリンクでどんな周期的なRIPとSAPにもデータを送らないことによって、バックグラウンドトラフィックを減少させることができます。 それがRIPであるなら問題を引き起こさないで、SAPが送られることに注意してください。 それはただワークステーションアクセスタイムを減速させるでしょう。
RIP and SAP information should ONLY be sent if the workstation makes a specific request for information - like a service or route request.
ワークステーションがサービスやルート要求のように情報に関する特定の要求をする場合にだけ、RIPとSAP情報を送るべきです。
It should also be noted that if multiple workstations are attached to a single WAN workstation network (per router), broadcasts on that network - whether originated from a workstation or the router - MUST reach ALL other workstations. This will involve the router duplicating the packet to all WAN workstation connections.
また、複数のワークステーションがただ一つのWANワークステーションネットワーク(1ルータあたりの)に取り付けられるなら、ワークステーションかルータから溯源されるか否かに関係なく、そのネットワークにおける放送が他のすべてのワークステーションに達しなければならないことに注意されるべきです。 これはすべてのWANワークステーション接続にパケットをコピーするルータにかかわるでしょう。
7. On-demand, Statically Routed Links
7. 要求次第の、そして、静的に発送されたリンク
On-demand, Static Routing serves two purposes. The "on-demand" part means that a router initiates communication to a destination only when there is data to be forwarded to that destination. "Inititating comunication" includes making a datalink call (where necessary) and performing the IPXWAN exchange. A transient connection is closed after a period of inactivity.
要求次第のStaticルート設定は2つの目的に役立ちます。 「要求次第」の部分は、その目的地に転送されるデータがあるときだけ、ルータが目的地にコミュニケーションを開始することを意味します。 "Inititating comunication"は、データリンクを呼ばせて(必要であるところ)、IPXWAN交換を実行するのを含んでいます。 一時的な接続は不活発の期間の後に閉店します。
Allen [Page 19] RFC 1551 IPXWAN December 1993
アレン[19ページ]RFC1551IPXWAN1993年12月
The "static routing" part means that no routing information is sent over the link - no RIP, no SAP, and no NLSP. Instead, the router at each end is configured with the routes and services accessible through the link.
「スタティックルーティング」部分は、ルーティング情報が全くリンクの上に送られないことを意味します--RIPがなく、またSAPがなく、またおよびNLSPがありません。 代わりに、各端のルータはリンクを通してアクセスしやすいルートとサービスによって構成されます。
With on-demand, static routing, the called router must be able to identify the calling router so that statically configured routes and services can be attached to that connection. For example, with X.25 switched virtual circuits, the calling DTE address can be used; with PPP, the PPP authentication can be used; after IPXWAN has completed, the "Router Name" can be used; with a persistent datalink connection, the physical port identifier or a permanent virtual circuit identifier can be used. The choice of identifier is an implementation decision. Whatever value the called router uses is called a Remote System Identifier, or RSI. For PPP links, Novell uses PPP PAP or CHAP authentication to determine the caller.
要求次第のスタティックルーティングで、呼ばれたルータは、静的に構成されたルートとサービスがその接続に愛着できるように、呼ぶルータを特定できなければなりません。 例えば、X.25交換仮想回路と共に、DTEが扱う呼ぶことを使用できます。 PPPと共に、PPP認証を使用できます。 後に、IPXWANはそうしました。完成していて、「ルータ名」を使用できます。 永続的なデータリンク接続と共に、物理的なポート識別子か相手固定接続識別子を使用できます。 識別子の選択は実装決定です。 呼ばれたルータが使用するどんな値もRemote System Identifier、またはRSIと呼ばれます。 PPPリンクに関しては、ノベルは、訪問者を決定するのにPPP PAPかCHAP認証を使用します。
A router implementing on-demand, static routing must maintain a database of RSIs, and lists describing the network numbers and services reachable through each RSI. These lists determine the reachability information it transmits to other routers in a routing area. Other routers treat each on-demand, static routing link as though it were permanently available.
要求次第のスタティックルーティングを実装するルータはRSIs、ネットワーク・ナンバーについて説明するリスト、および各RSIを通して届いているサービスに関するデータベースを維持しなければなりません。 これらのリストはそれがルーティング領域の他のルータに伝える可到達性情報を決定します。 まるでそれが永久に利用可能であるかのようにそれぞれ要求次第のスタティックルーティングがリンクする他のルータの御馳走。
The on-demand exchange has a slight variation on the IPXWAN protocol. The differences are as follows.
要求次第の交換には、IPXWANプロトコルのわずかな変化があります。 違いは以下の通りです。
In the Timer Request, the calling router offers only the "On-demand, static routing" Routing Type. If the called router is capable of On- demand static routing, it offers "On-demand, static routing" in the Timer Request, along with any additional routing types it is willing to support on the link. The Master/Slave election and choice of routing type proceeds as described previously. If the Slave detects a mismatch in routing types, it disconnects the link.
Timer Request、職業ルータ申し出だけ、「」 要求次第のスタティックルーティングルート設定Type。 呼ばれたルータはOn要求スタティックルーティングができて、それが申し出である、「」 タイプのためにそれを発送するTimer Requestの、そして、いずれと共にも追加しているコネがリンクの上にサポートしても構わないと思っている要求次第のスタティックルーティング。 Master/奴隷は以前に説明されるように続きます選挙とルーティングの選択が、タイプする。 Slaveがルーティングタイプによるミスマッチを検出するなら、それはリンクから切断します。
For a persistent datalink (like X.25 PVCs), there may be no descerable "link establishemnt" event. For such media, arrival of a Timer Request plays the role of detecting link establishment.
永続的なデータリンク(X.25 PVCsのような)のために、descerable「リンクestablishemnt」イベントは全くないかもしれません。 そのようなメディアのために、Timer Requestの到着はリンク設立を検出する役割を果たします。
As with Unnumbered RIP, there is no network number assigned to the link. NLSP Packets are not sent on the link. Moreover, periodic RIP and SAP packets are not sent on the link. However, a router must respond to RIP and SAP queries received on the link.
Unnumbered RIPのように、リンクに割り当てられたネットワーク・ナンバーが全くありません。 NLSP Packetsはリンクに送られません。 そのうえ、周期的なRIPとSAPパケットはリンクに送られません。 しかしながら、ルータはリンクの上に受けられたRIPとSAP質問に応じなければなりません。
Allen [Page 20] RFC 1551 IPXWAN December 1993
アレン[20ページ]RFC1551IPXWAN1993年12月
8. References
8. 参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP) for the
Transmission of Multi-protocol Datagrams over Point-to-Point
Links", RFC 1548, Daydreamer, December 1993.
[1] w.シンプソン、エディタ、「ポイントツーポイントの上のマルチプロトコルデータグラムの送信のための二地点間プロトコル(ppp)はリンクします」、RFC1548、空想家、1993年12月。
[2] Malis, A., Robinson, D., and R. Ullman, "Multiprotocol
Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356,
August 1992.
[2] Malis、A.、ロビンソン、D.、およびR.ウルマン、「Multiprotocolはパケット形態によるX.25とISDNで内部連絡します」、RFC1356、1992年8月。
[3] Bradley, T., Brown, C., and A. Malis, "Multiprotocol
Interconnect over Frame Relay", RFC 1490, Wellfleet
Communications, Inc., Ascom Timeplex, Inc., July 1993.
[3]ブラッドリーとT.とブラウン、C.とA.Malis、「Multiprotocolはフレームリレーの上で内部連絡する」RFC1490、WellfleetコミュニケーションInc.、Ascom Timeplex Inc.(1993年7月)。
[4] Simpson, W., "The PPP Internetwork Packet Exchange Control
Protocol (IPXCP)", RFC 1552, Daydreamer, December 1993.
[4] シンプソン、W.、「pppインターネットワークパケット交換制御プロトコル(IPXCP)」、RFC1552、空想家、1993年12月。
[5] Novell IPX Router Specification.
Novell Part Number 107-000029-001. This document may be
retrieved via Anonymous FTP to SJF-LWP (130.57.11.140) under
/sys/ftpguest/nw_shell/ipxdocs/ipxrout.zip.
[5] ノベルIPXルータ仕様。 ノベル部品番号107-000029-001。 このドキュメントがSJF-LWPへのアノニマス・エフテーピーで検索されるかもしれない、(130.57 .11 .140) /sys/ftpguest/nw_シェル/ipxdocs/ipxrout.zipの下で。
[6] Mathur, S., and M. Lewis, M., "Compressing IPX Headers
Over WAN Media (CIPX)", RFC 1553, Telebit Corporation,
December 1993.
[6] マートゥル、S.とM.ルイス、M.、「青白いメディア(CIPX)の上にIPXヘッダーを圧縮します」、RFC1553、テレビット社、1993年12月。
[7] ANSI, "Integrated Services Digital Network (ISDN) - Digital
Subscriber Signalling System Number 1 (DSS1) - Signalling
Specification for Frame Relay", ANSI T1.617-1991, June 1991
[7]ANSI、「サービス統合ディジタル網(ISDN)--デジタル加入者合図システムNo.1(DSS1)--フレームリレーのための合図仕様」、ANSI T1.617-1991、1991年6月
[8] Novell NetWare Link Services Protocol (NLSP) Specification.
Novell part number 100-001708-002. Information on this document
may be obtained by sending e-mail to dsink@novell.com.
[8] ノベルNetWareはサービスプロトコル(NLSP)仕様をリンクします。 ノベル部品番号100-001708-002。 メールを dsink@novell.com に送ることによって、このドキュメントに関する情報を得るかもしれません。
9. Security Considerations
9. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Allen [Page 21] RFC 1551 IPXWAN December 1993
アレン[21ページ]RFC1551IPXWAN1993年12月
10. Author's Address
10. 作者のアドレス
Michael Allen
Novell, Inc.
2180 Fortune Drive
San Jose, CA 95131
Driveサンノゼ、マイケルアレンノベルInc.2180Fortuneカリフォルニア 95131
EMail: mallen@novell.com
メール: mallen@novell.com
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
Allen [Page 22]
アレン[22ページ]
一覧
スポンサーリンク
