RFC1476 日本語訳
1476 RAP: Internet Route Access Protocol. R. Ullmann. June 1993. (Format: TXT=45560 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Ullmann
Request for Comments: 1476 Process Software Corporation
June 1993
コメントを求めるワーキンググループR.ウルマン要求をネットワークでつないでください: 1476はソフトウェア社の1993年6月に処理されます。
RAP: Internet Route Access Protocol
以下を叩いてください。 インターネットルートアクセス・プロトコル
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. Discussion and suggestions for improvement are requested. 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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはインターネット標準を指定しません。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This RFC describes an open distance vector routing protocol for use at all levels of the internet, from isolated LANs to the major routers of an international commercial network provider.
このRFCは使用のためにインターネットのすべてのレベルで開いている距離ベクトルルーティング・プロトコルについて説明します、孤立しているLANから主要な国際的な商業ネットワーク内の提供者のルータまで。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . 2 1.1 Link-State and Distance-Vector . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . 3 1.3 Philosophy . . . . . . . . . . . . . . . . . . . . 3 2. RAP Protocol . . . . . . . . . . . . . . . . . . . 4 2.1 Command Header Format . . . . . . . . . . . . . . 4 2.1.1 Length field . . . . . . . . . . . . . . . . . . . 4 2.1.2 RAP version . . . . . . . . . . . . . . . . . . . 5 2.2 RAP Commands . . . . . . . . . . . . . . . . . . . 5 2.2.1 No operation . . . . . . . . . . . . . . . . . . . 5 2.2.2 Poll . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.3 Error . . . . . . . . . . . . . . . . . . . . . . 7 2.2.4 Add Route . . . . . . . . . . . . . . . . . . . . 8 2.2.5 Purge Route . . . . . . . . . . . . . . . . . . . 9 3. Attributes of Routes . . . . . . . . . . . . . . . 9 3.1 Metric and Option Format . . . . . . . . . . . . .10 3.1.1 Option Class . . . . . . . . . . . . . . . . . . 10 3.1.2 Type . . . . . . . . . . . . . . . . . . . . . . 10 3.1.3 Format . . . . . . . . . . . . . . . . . . . . . 11 3.2 Metrics and Options . . . . . . . . . . . . . . 11 3.2.1 Distance . . . . . . . . . . . . . . . . . . . . 12 3.2.2 Delay . . . . . . . . . . . . . . . . . . . . . 12 3.2.3 MTU . . . . . . . . . . . . . . . . . . . . . . 12 3.2.4 Bandwidth . . . . . . . . . . . . . . . . . . . 12
1. 序論. . . . . . . . . . . . . . . . . . . 2 1.1リンク状態と距離ベクトル. . . . . . . . . . 3 1.2用語. . . . . . . . . . . . . . . . . . . 3 1.3哲学. . . . . . . . . . . . . . . . . . . . 3 2。 RAPプロトコル. . . . . . . . . . . . . . . . . . . 4 2.1Command Header Format. . . . . . . . . . . . . . 4 2.1.1Lengthは.42.1.2RAPバージョン. . . . . . . . . . . . . . . . . . . 5 2.2RAP Commands. . . . . . . . . . . . . . . . . . . 5 2.2をさばきます; 1 いいえ、操作. . . . . . . . . . . . . . . . . . . 5 2.2.2Poll. . . . . . . . . . . . . . . . . . . . . . . 6 2.2.3Error. . . . . . . . . . . . . . . . . . . . . . 7 2.2.4Add Route. . . . . . . . . . . . . . . . . . . . 8 2.2.5Purge Route. . . . . . . . . . . . . . . . . . . 9 3。 ルート.93.1メートル法とオプション形式. . . . . . . . . . . . .10 3.1.1オプションのクラス. . . . . . . . . . . . . . . . . . 10 3.1.2の属性は.103.1.3書式. . . . . . . . . . . . . . . . . . . . . 11 3をタイプします; 2つの測定基準とオプション. . . . . . . . . . . . . . 11 3.2.1距離. . . . . . . . . . . . . . . . . . . . 12 3.2.2は.12に.123.2.3MTU. . . . . . . . . . . . . . . . . . . . . . 12 3.2.4帯域幅を遅らせます。
Ullmann [Page 1] RFC 1476 RAP June 1993
ウルマン[1ページ]RFC1476は1993年6月に叩きます。
3.2.5 Origin . . . . . . . . . . . . . . . . . . . . . 12 3.2.6 Target . . . . . . . . . . . . . . . . . . . . . 13 3.2.7 Packet Cost . . . . . . . . . . . . . . . . . . 13 3.2.8 Time Cost . . . . . . . . . . . . . . . . . . . 13 3.2.9 Source Restriction . . . . . . . . . . . . . . . 14 3.2.10 Destination Restriction . . . . . . . . . . . . 14 3.2.11 Trace . . . . . . . . . . . . . . . . . . . . . 14 3.2.12 AUP . . . . . . . . . . . . . . . . . . . . . . 15 3.2.13 Public . . . . . . . . . . . . . . . . . . . . . 15 4. Procedure . . . . . . . . . . . . . . . . . . . 15 4.1 Receiver filtering . . . . . . . . . . . . . . . 16 4.2 Update of metrics and options . . . . . . . . . 16 4.3 Aggregation . . . . . . . . . . . . . . . . . . 17 4.4 Active route selection . . . . . . . . . . . . . 17 4.5 Transmitter filtering . . . . . . . . . . . . . 17 4.6 Last resort loop prevention . . . . . . . . . . 18 5. Conclusion . . . . . . . . . . . . . . . . . . . 18 6. Appendix: Real Number Representation . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . 20 9. Author's Address . . . . . . . . . . . . . . . . 20
3.2.5 .8時間は.133.2に起源. . . . . . . . . . . . . . . . . . . . . 12 3.2.6目標. . . . . . . . . . . . . . . . . . . . . 13 3.2.7パケットに費用. . . . . . . . . . . . . . . . . . . 13 3.2.9ソース制限を費やしました…; . . . . . . . . . . . 14 3.2.10 目的地制限. . . . . . . . . . . . 14 3.2.11は公共の.154に.143.2.12AUP. . . . . . . . . . . . . . . . . . . . . . 15 3.2.13をたどります。 測定基準の.164.2Updateをフィルターにかける手順. . . . . . . . . . . . . . . . . . . 15 4.1Receiverと.174.6Lastをフィルターにかけるオプション. . . . . . . . . 16 4.3Aggregation. . . . . . . . . . . . . . . . . . 17 4.4Activeルート選択. . . . . . . . . . . . . 17 4.5Transmitterが輪の防止. . . . . . . . . . 18 5に行きます。 結論. . . . . . . . . . . . . . . . . . . 18 6。 付録: 実数表現. . . . . . 19 7。 参照. . . . . . . . . . . . . . . . . . . 20 8。 セキュリティ問題. . . . . . . . . . . . . 20 9。 作者のアドレス. . . . . . . . . . . . . . . . 20
1. Introduction
1. 序論
RAP is a general protocol for distributing routing information at all levels of the Internet, from private LANs to the widest-flung international carrier networks. It does not distinguish between "interior" and "exterior" routing (except as restricted by specific policy), and therefore is not as restricted nor complex as those protocols that have strict level and area definitions in their models.
RAPはインターネットのすべてのレベルでルーティング情報を分配するための一般的なプロトコルです、個人的なLANから最も広く投げつけられた国際的な航空会社ネットワークまで。 それは、「内部」の、そして、「外」のルーティングを見分けないで(特定保険証券によって制限される以外に)、またしたがって、制限されるとしてありません。または、厳しいレベルを持っているそれらのプロトコルと彼らのモデルへの領域指定として、複雑です。
The protocol encourages the widest possible dissemination of topology information, aggregating it only when limits of thrust, bandwidth, or administrative policy require it. Thus RAP permits aggressive use of resources to optimize routes where desired, without the restrictions inherent in the simplifications of other models.
プロトコルはトポロジー情報の可能な限り広い普及を奨励します、突き、帯域幅、または施政方針の限界がそれを必要とするときだけ、それに集めて。 したがって、RAPは、リソースの攻撃的な使用が必要であるところでルートを最適化するのを可能にします、他のモデルの簡素化の固有である制限なしで。
While RAP uses IPv7 [RFC1475] addressing internally, it is run over both IPv4 and IPv7 networks, and shares routing information between them. A IPv4 router will only be able to activate and propagate routes that are defined within the local Administrative Domain (AD), loading the version 4 subset of the address into the local IP forwarding database.
RAPは内部的にIPv7[RFC1475]アドレシングを使用しますが、それは、IPv4とIPv7ネットワークの両方の上を走って、それらの間でルーティング情報を共有します。 IPv4ルータは、地方のAdministrative Domain(AD)の中で定義されるルートを、動かして、伝播できるだけでしょう、アドレスのバージョン4部分集合をローカルアイピー推進データベースにロードして。
Ullmann [Page 2] RFC 1476 RAP June 1993
ウルマン[2ページ]RFC1476は1993年6月に叩きます。
1.1 Link-State and Distance-Vector
1.1 リンク状態と距離ベクトル
Of the two major classes of routing algorithm, link-state and distance vector, only distance vector seems to scale from the local network (where RIP is existence-proof of its validity) to large scale inter-domain policy routing, where the number of links and policies exceeds the ability of each router to map the entire network.
2つの主要なクラスのルーティング・アルゴリズム、リンク状態、および距離ベクトルでは、距離ベクトルだけが企業内情報通信網(RIP存在の正当性の耐であるところ)から大規模相互ドメイン方針ルーティングまで比例するように思えます。(そこでは、リンクと方針の数が各ルータが全体のネットワークを写像する能力を超えています)。
In between, we have OSPF, an open link state (specifically, using shortest-path-first analysis of the graph, hence the acronym) protocol, with extensive development in intra-area routing.
中間で、私たちはOSPFを持っています、開いているリンク状態、(明確に使用、最も短い経路、最初に、したがって、グラフの分析、頭文字語) 大規模な開発で、イントラ領域ルーティングで、議定書を作ってください。
Since distance vector has proven useful at both ends of the range, it seems reasonable to apply it to the entire range of scales, creating a protocol that works automatically on small groups of LANs, but can apply fairly arbitrary policy in the largest networks.
距離ベクトルが範囲の両端で有用であることが分かったので、全体の範囲のスケールにそれを適用するのは妥当に思えます、自動的に小集団のLANに取り組みますが、最も大きいネットワークで任意の方針を公正に当てはまることができるプロトコルを作成して。
This helps model the real world, where networks are not clearly divided into hierarchical domains with identifiable "border" routers, but have many links across organizational structure and over back fences.
これは、ネットワークが身元保証可能な「境界」ルータで明確に階層的なドメインに分割されない本当の世界をモデル化するのを助けますが、組織体制の向こう側に逆フェンスの上に多くのリンクを持ってください。
1.2 Terminology
1.2 用語
The RAP protocol propagates routes in the opposite direction to the travel of datagrams using the routes. To avoid confusion explaining the routing protocol, several terms are distinguished:
RAPプロトコルは、ルートを使用することでデータグラムの旅行への逆方向にルートを伝播します。 ルーティング・プロトコルがわかる混乱を避けるために、いくつかの用語が顕著です:
source where datagrams come from, the source of the
datagrams
データグラムが来るソース、データグラムの源
destination where datagrams go to, the destination of the
datagrams
データグラムが動く目的地、データグラムの目的地
origin where routing information originates, the router
initially inserting route information into the
RAP domain
ルータが初めはRAPドメインに経由地案内を挿入して、ルーティング情報が由来する起源
target where routing information goes, the target uses the
information to send datagrams
ルーティング情報が行って、目標がデータグラムを送るのに情報を使用する目標
1.3 Philosophy
1.3 哲学
Protocols should become simpler as they evolve.
発展するのに従って、プロトコルは、より簡単になるべきです。
Ullmann [Page 3] RFC 1476 RAP June 1993
ウルマン[3ページ]RFC1476は1993年6月に叩きます。
2. RAP Protocol
2. ラッププロトコル
The RAP protocol operates on TCP port 38, with peers opening a symmetric TCP connection between the RAP ports on each system. Thus only one RAP connection exists between any pair of peers.
RAPプロトコルはTCPポート38を作動させます、同輩が各システムの上のRAPポートの間の左右対称のTCP接続を開いていて。 したがって、1つのRAP接続だけがどんな組の同輩の間にも存在しています。
RAP is also used on UDP port 38, as a peer discovery method. Hosts (i.e., non-routing systems) may listen to RAP datagrams on this port to discover local gateways. This is in addition to, or in lieu of, an Internet Standard gateway discovery protocol, which does not exist at this writing.
また、RAPは同輩発見方法としてUDPポート38の上で使用されます。 ホスト(すなわち、非ルーティングシステム)は、地方のゲートウェイを発見するためにこのポートの上のRAPデータグラムを聞くかもしれません。 これはプロトコルかインターネットStandardゲートウェイ発見プロトコルあります。(それは、この文を草するときに存在しません)。
The peers then use RAP commands to send each other all routes available though the sending peer. This occurs as a full-duplex (i.e., simultaneous) exchange of information, with no acknowledgement of individual commands.
そして、同輩は送付同輩ですが、利用可能なすべてのルートを互いに送るRAPコマンドを使用します。 これは全二重(すなわち、同時の)情報交換として個々のコマンドの承認なしで起こります。
Once the initial exchange has been completed, the peers send only updates to routes, new routes, and purge commands to delete routes previously offered.
初期の交換がいったん終了されると、同輩はルート、新しいルート、および以前に提供されたルートを削除する除きコマンドにアップデートだけを送ります。
When the connection is broken, each system purges all routes that had been offered by the peer.
接続が失意であるときに、各システムは同輩によって提供されたすべてのルートを掃除します。
2.1 Command Header Format
2.1 コマンドヘッダー形式
Each RAP command starts with a header. The header contains a length field to identify the start of the next packet in the TCP stream, a version number, and the code for the command. On UDP, the length field does not appear: each UDP datagram must contain exactly one RAP command and not contain data or padding after the end of the command.
それぞれのRAPコマンドはヘッダーから始まります。 ヘッダーはコマンドのためにTCPの流れ、バージョン番号、およびコードにおける、次のパケットの始まりを特定する長さの分野を含んでいます。 UDPでは、長さの野原は現れません: それぞれのUDPデータグラムは、まさに1つのRAPコマンドを含んでいて、コマンドの終わり以降にデータか詰め物は含んではいけません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RAP version | command code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RAPバージョン| コマンドコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.1 Length field
2.1.1 長さの分野
The length is a 32 bit unsigned number specifying the offset in bytes from the first byte of the length field of this command packet to the start of the length field of the next. The minimum value is 8. There is no specific limit to the length of a command packet; implementations MUST be able to at least count and skip over a packet
長さはこのコマンドパケットの長さの分野の最初のバイトから次の長さの分野の始まりまでバイトにおけるオフセットを指定する32の噛み付いている符号のない数です。 最小値は8です。 コマンドパケットの長さへのどんな特定の限界もありません。 実現は、パケットを少なくとも数えて、飛ばすことができなければなりません。
Ullmann [Page 4] RFC 1476 RAP June 1993
ウルマン[4ページ]RFC1476は1993年6月に叩きます。
that is too large and then MAY send an error indication.
それは、大き過ぎ、次に、誤り表示を送るかもしれません。
Each version of the protocol will profile what size should be considered the limit for senders, and what (larger) size should be considered by receivers to mean that the connection is insane: either unsynchronized or worse.
プロトコルの各バージョンはどんなサイズが送付者のための限界であると考えられるべきであるか、そして、(より大きい)のサイズが受信機によって接続が狂気であることを意味すると考えられるべきであることの輪郭を描くでしょう: 非連動しているか、または、より悪いです。
For version 1 of the protocol, senders MUST NOT send command packets greater than 16384 bytes. Receivers SHOULD consider packets that appear to be greater than 162144 bytes in length to be an indication of an unrecoverable error.
プロトコルのバージョン1のために、送付者は16384バイト以上をコマンドパケットに送ってはいけません。 受信機SHOULDは、長さ162144バイト以上であるように見えるパケットが回復不能エラーのしるしであると考えます。
Note that these limits probably will not be approached in normal operation of version 1 of the protocol; receivers may reasonably decline to use routes described by 16K bytes of metrics and policy. But even the most memory-restricted implementation MUST be able to skip such a command packet.
たぶんプロトコルのバージョン1の通常の操作でこれらの限界にアプローチしないことに注意してください。 受信機は、16Kのバイトの測定基準と方針で説明されたルートを使用するのを合理的に断るかもしれません。 しかし、最も多くのメモリで制限された実現さえそのようなコマンドパケットをスキップできなければなりません。
2.1.2 RAP version
2.1.2 RAPバージョン
The version field is a 16 bit unsigned number. It identifies the version of RAP used for that command. Note that commands with different versions may be mixed on the same connection, although the usual procedure will be to do the serious protocol (exchanging route updates) only at the highest version common to both ends of the connection.
バージョン分野は16の噛み付いている符号のない数です。 それはそのコマンドに使用されるRAPのバージョンを特定します。 異なった見解があるコマンドが同じ接続のときに複雑であるかもしれないことに注意してください、普通の手順が単に接続の両端に共通の最も高いバージョンで重大なプロトコル(ルートアップデートを交換する)をすることですが。
Each side starts the connection by sending a poll command, using the highest version supported and continues by using the highest version received in any command from the remote. The response to the poll will either be a no-operation packet at that version or an error packet at the highest version supported by the remote.
それぞれの側は投票命令を送ることによって、接続を始めます、と最も高いバージョンを使用するのがかけ離れるのからどんなコマンドでも受け取られる中で最も高いバージョンを使用することによって、支持して、続けています。 投票への応答は、リモートによって支持される中で最も高いバージョンでそのバージョンにおける操作がないパケットか誤りパケットのどちらかになるでしょう。
This document describes version 1 of the RAP protocol.
このドキュメントはRAPプロトコルのバージョン1について説明します。
2.2 RAP Commands
2.2 ラップコマンド
There five simple RAP commands, described in the following sections.
そこでは、以下のセクションで説明されて、5の簡単なRAPが命令します。
2.2.1 No operation
2.2.1 操作がありません。
The no operation command serves to reset the poll timer (see next section) of the receiver, or (as a side effect) to tell the receiver that a particular version is supported. It never contains option specific data and its length is always 8.
または、いいえ、操作命令が受信機の投票タイマ(次のセクションを見る)をリセットするために役立つ(副作用としての) 特定のバージョンが支持されると受信機に言うために。 それはオプションの特定のデータを決して含んでいません、そして、いつも長さは8です。
The no operation command is also used in a UDP broadcast to inform other systems that the sender is running RAP actively on the network
また、ノー、は、送付者がネットワークでRAPを活発に走らせていることを他のシステムに知らせるのにUDP放送に使用されます操作が、命令する。
Ullmann [Page 5] RFC 1476 RAP June 1993
ウルマン[5ページ]RFC1476は1993年6月に叩きます。
and is both a possible gateway and a candidate peer. If this command is being sent in response to a broadcast poll, it should be sent only to the poller.
そして、可能なゲートウェイと候補同輩の両方がそうですか? 放送投票に対応してこのコマンドを送るなら、それをpollerだけに送るべきです。
A RAP process may send such broadcasts in a startup sequence, or it may persist indefinitely to inform other systems coming on line. If it persists, it must not send them more than once every 10 minutes (after the initial startup sequence). If the RAP process sends polls as part of its startup, it must not persist in sending them after the startup sequence.
RAPの過程が始動系列におけるそのような放送を送るかもしれませんか、またはそれは、稼働中に次の他のシステムを知らせるために無期限に固執するかもしれません。 固執しているなら、それはかつての10分毎よりそれらを送ってはいけません(初期の始動系列の後に)。 RAPの過程が始動の一部として投票を送るなら、それは始動系列の後にそれらを送るのに固執してはいけません。
The command code for no-operation is always 0, regardless of RAP version.
いつも操作でないコマンドコードはRAPバージョンにかかわらず0です。
2.2.2 Poll
2.2.2 投票
A poll command packet requests that the other side transmit either a no-operation packet, or some other packet if sent without delay. (i.e., receivers MUST NOT delay a response to a poll by waiting for some other packet expected to be queued soon.)
投票コマンドパケットは、即刻送るなら反対の側が操作がないパケットかパケットのどちらかをある他の伝えるよう要求します。 (すなわち、受信機はすぐ列に並ばせられると予想されたある他のパケットを待つことによって、投票への応答を遅らせてはいけません。)
The poll command code is always 1, regardless of version, and the length is always 8.
いつも投票コマンドコードはバージョンにかかわらず1です、そして、いつも長さは8です。
Each RAP implementation runs a timer for each connection, to ensure that if the other system becomes unreachable, the connection will be closed or reset. The timers run at each end of the connection are independent; each system is responsible for sending polls in time to reset its own timer.
それぞれのRAP実現は、もう片方のシステムが手が届かなくなると、接続が閉店するか、またはリセットされるのを保証するために各接続のためのタイマを動かします。 接続の各端のタイマ走行は独立しています。 時間内にの送付投票がそれ自身のタイマをリセットするのにおいてそれぞれのシステムは原因となります。
The timer MUST be reset (restarted) on the receipt of any RAP packet, regardless of whether the version or command code is known.
どんなRAPパケットの領収書の上にもタイマをリセットしなければなりません(再開されます)、バージョンかコマンドコードが知られているかどうかにかかわらず。
In normal operation, if route updates are being sent in both directions, polls may not be necessary for long periods of time as the timers are continually reset. When the connection is quiescent, both timers will typically get reset as a result of the side with the shorter timer doing a poll, and then getting a no-operation in response. RAP implementations MUST NOT be dependent in any way on the size or existence of the remote timer.
通常の操作では、ルートアップデートを両方の方向に送るなら、タイマが絶えずリセットされるので、投票は長期間に必要でないかもしれません。 接続が静かであるときに、両方のタイマは、より短いタイマが投票して、次に、応答における操作を全く得ていない側の結果、通常リセットされるでしょう。 RAP実現は何らかの方法でリモートタイマのサイズか存在に依存しているはずがありません。
An implementation that has access to information from the TCP layer, such as the results of TCP layer keepalives, MAY use this instead of or in addition to a timer. However, the use of TCP keepalives is discouraged, and this procedure does not ensure that the remote RAP process is alive, only that its TCP is accepting data. Thus a failure mode exists that would not exist for active RAP layer polls.
TCP層のkeepalivesの結果などのように、TCP層からの情報に近づく手段を持っている実現はタイマかタイマに加えてこれを使用するかもしれません。 しかしながら、TCP keepalivesの使用はお勧めできないです、そして、この手順はリモートRAPの過程が生きていて、TCPがデータを受け入れているだけであるのを確実にしません。 したがって活発なRAP層の投票のために存在しない故障モードは存在しています。
Ullmann [Page 6] RFC 1476 RAP June 1993
ウルマン[6ページ]RFC1476は1993年6月に叩きます。
The timer MUST be implemented, SHOULD be configurable in at least the range 1 to 10 minutes on a per-peer basis, and MAY be infinite (disabled) by explicit configuration.
タイマを実行しなければならなくて、SHOULDは1〜10分間1同輩あたり1個のベースで少なくとも範囲で構成可能であり、明白な構成による無限であるかもしれません(障害がある)。
On UDP, a system (router or non-routing host) may send RAP polls to attempt to locate candidate peers or possible gateways. Such a system must not persist in sending polls after its startup sequence, except that a system which actually has offered traffic for non-local destinations, and has no available gateways, may continue to send periodic polls to attempt to acquire a gateway.
UDPでは、システム(ルータか非ルーティングホスト)は、候補同輩か可能なゲートウェイの場所を見つけるのを試みるために投票をRAPに送るかもしれません。 そのようなシステムは始動系列の後に送付投票に固執してはいけません、非地方の目的地のために実際にトラフィックを提供して、どんな利用可能なゲートウェイも持っていないシステムが、ゲートウェイを入手するのを試みるために周期的な投票を送り続けるかもしれないのを除いて。
2.2.3 Error
2.2.3 誤り
The error packet is used to report an error, whether fatal, serious or informational. It includes a null terminated text description in ISO-10646-UTF-1 of the condition, which may be useful to a human administrator, and SHOULD be written to a log file. (The machine is not expected to understand the text.)
致命的であるか、重大であるかまたは情報であることにかかわらず誤りパケットは、誤りを報告するのに使用されます。 書かれていて、それは人間の管理者の役に立つかもしれない状態とSHOULDのISO-10646-UTF-1でヌル終えられたテキスト記述をログファイルに含めます。 (マシンがテキストを理解していないと予想されます。)
Errors are actual failures (in the interpretation of the receiver) to use the correct syntax and semantics of the RAP protocol itself, or "failure" of the receiver to implement a version of the protocol. Other conditions that may require action on the part of the peer (such as purging a route) are given their own command codes.
誤りは、正しい構文を使用しない実際のこと(受信機の解釈における)とRAPプロトコル自体の意味論か、プロトコルのバージョンを実装する受信機の「失敗」です。 同輩(ルートを掃除などなどの)側の動作を必要とするかもしれない他の状態にそれら自身のコマンドコードを与えます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RAP version (1) | command code (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| error code (0) [reserved] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| description |
+ +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RAPバージョン(1)| コマンドコード(2)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード(0)[予約されます]| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 記述| + + | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RAP system receiving an Error packet MUST NOT regard it as fatal, and close the connection or discard routes. If the sending system desires the condition to be fatal (unrecoverable), its proper action is to close the connection. This requirement is to prevent the kind of failure mode demonstrated by hosts that killed off TCP connections on the receipt of ICMP Host-Unreachable notifications, even when the condition is transient. We do not want to discourage the reporting of errors, in the way that some implementations avoided sending ICMP datagrams to deal with overly sensitive hosts.
Errorパケットを受けるRAPシステムは、それが致命的であるとみなして、接続を終えてはいけませんし、またルートを捨ててはいけません。 送付システムが致命的である(復しない)状態を望んでいるなら、適切な動きは接続を終えることです。 この要件はICMP Host手の届かない通知の領収書の上でTCP接続を全滅させたホストによって示された故障モードの種類を防ぐことです、状態が一時的であるときにさえ。 誤りの報告をがっかりさせたいと思いません、いくつかの実装がひどく敏感なホストに対応するためにデータグラムをICMPに送るのを避けた方法で。
Ullmann [Page 7] RFC 1476 RAP June 1993
ウルマン[7ページ]RFC1476は1993年6月に叩きます。
An error packet MUST NOT be sent in response to something that is (or might be) an error packet itself. Subsequent versions of RAP should keep the command code point (2) of the error packet.
(または、あるかもしれません)誤りパケット自体である何かに対応して誤りパケットを送ってはいけません。 RAPのその後のバージョンは、コマンドコードが誤りパケットのポイント(2)であることを保つべきです。
2.2.4 Add Route
2.2.4 ルートを加えてください。
The add route command offers a route to the receiving peer. As noted later, it MUST be a route actually loaded into the forwarding database of the offering peer at the time the add route is sent.
ルートコマンドが受信同輩にルートを提供すると言い足してください。 それが後で注意されるように実際に当時提供同輩の推進データベースにロードされたルートであるに違いない、ルートが送られると言い足してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RAP version (1) | command code (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| distance | (MBZ) | mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination network |
+ +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| route identifier |
+ +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metrics and options .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RAPバージョン(1)| コマンドコード(3)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 距離| (MBZ) | マスク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送信先ネットワーク| + + | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルート識別子| + + | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 測定基準とオプション… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The add route command describes a single offered route, with the metrics and other options (such as policies) associated with the route.
ルートコマンドがただ一つの提供されたルートを説明すると言い足してください、ルートに関連している測定基準と別の選択肢(方針などの)で。
Distance is a simple count of the hops to the RAP process (or other routing process) that originated the route, incremented every time the route is forwarded. Its initial value may be greater than 1, particularily for a route that is administratively configured to aggregate routes for a large network or AD. It may also enter the RAP routing domain for the first time with a non-zero distance because the route originated in RIP, OSPF, or BGP; if so, the distance carried in that protocol is copied into the RAP route.
距離はルートを進めるときはいつも、増加されたルートを溯源したRAPプロセス(または、他のルーティングプロセス)へのホップの簡単なカウントです。 初期の値は1以上であるかもしれません、大きいネットワークかADの間、ルートに集めるために行政上構成されるルートにおいて、particularilyです。 また、ルートがリップ、OSPF、またはBGPで起こったので、それは初めて、非ゼロ距離でRAP経路ドメインに入るかもしれません。 そうだとすれば、そのプロトコルで運ばれた距離はRAPルートにコピーされます。
The mask is a count of the number of bits of prefix ones in the binary representation of the network mask. Non-contiguous masks are not supported directly. (The destination restriction option may be used to give another, non-contiguous, mask; the header mask would then describes the number of contiguous ones.)
マスクはビットの接頭語の数のカウントです。ネットワークマスクの2進法表示におけるもの。 非隣接のマスクは直接支えられません。 (目的地制限オプションは使用されて、マスク; ヘッダーマスクがそしてそうする別の非隣接のものに与えるのが隣接のものの数について説明するということであるかもしれません。)
Ullmann [Page 8] RFC 1476 RAP June 1993
ウルマン[8ページ]RFC1476は1993年6月に叩きます。
The route identifier is a 64 bit value that the IP forwarding module on the sending host can use to rapidly identify the route and the next hop for each incoming datagram. The host receiving the route places this identifier into the forward route ID field of the datagrams being sent to this host.
ルート識別子は送付ホストの上のIP推進モジュールが各受信データグラムのために急速にルートと次のホップを特定するのに使用できる64ビットの値です。 ルートを受け取るホストはこのホストに送られるデータグラムの前進のルートID分野にこの識別子を置きます。
The route ID is also used to uniquely identify the route in the purge route operation.
また、ルートIDは、パージルート操作で唯一ルートを特定するのに使用されます。
2.2.5 Purge Route
2.2.5 パージルート
The purge route command requires that the receiving peer delete a route from its database if in use, and requires that it revoke that route from any of its peers to whom it has offered the route. This command should preferably be sent before the route is deleted from the sending peer's forwarding database, but this is not (cannot be) required; it should be sent without delay when the route is removed.
パージルート命令は、使用中であるなら受信同輩がデータベースからルートを削除するのが必要であり、それがルートを提供した同輩のどれかからそのルートを取り消すのを必要とします。 送付同輩の推進データベースからルートを削除する前に望ましくはこのコマンドを送るべきですが、これを必要としません(あることができません)。 ルートを取り外すとき、即刻それを送るべきです。
The command code is 4. The format is the same as add route without any added metrics or options.
コマンドコードは4です。 形式は少しも加えられた測定基準やオプションなしでルートを加えるのと同じです。
If the route identifier in a purge route command is zero, the command requires the deletion of all routes to the destination previously offered by this peer.
パージルート命令におけるルート識別子がゼロであるなら、コマンドは以前にこの同輩によって提供された目的地にすべてのルートの削除を必要とします。
3. Attributes of Routes
3. ルートの属性
There are a rather large number of possible attributes. Possibilities include both metrics, and other options describing for example policy restrictions and alterations of proximity. Any particular route will usefully carry only a few attributes or none at all, particularily on an infrastructure backbone. A reasonable policy for the routers that make up a backbone might be to strip all attributes before propagating routes (discarding routes that carry attributes with class indications prohibiting this), and then adding (for example) an AUP attribute to all routes propagated off of the backbone. A less drastic method would be to simply prefer routes with no restrictions, but still propagate a route with restrictions if no other is available.
かなり多くの可能な属性があります。 ポシビリティーズは例えば近接の方針制限と変更について説明する測定基準と別の選択肢の両方を含んでいます。 どんな特定のルートもインフラストラクチャバックボーンで有効に全く、particularilyにいくつかの属性かなにもだけ運ばないでしょう。 バックボーンを作るルータのための合理的な方針は次に、バックボーンから伝播されたすべてのルートにルートを伝播して(クラス指摘がこれを禁止している状態で属性を運ぶルートを捨てます)、AUP属性を追加する(例えば)前にすべての属性を剥取ることであるかもしれません。 それほど抜本的でないメソッドが制限なしでルートを単に好むだろうことですが、それでも、何か他のものが手があかないなら、制限でルートを伝播してください。
Most options can occur more than once in a route if there is any sensible reason to do so.
ほとんどのオプションがあれば分別があるいずれもそうするためにルートの一度推論するより起こることができます。
Ullmann [Page 9] RFC 1476 RAP June 1993
ウルマン[9ページ]RFC1476は1993年6月に叩きます。
3.1 Metric and Option Format
3.1 メートル法とオプション形式
Each metric or option for a route begins with a 32 bit header:
それぞれメートル法、ルートのためのオプションは32ビットのヘッダーと共に以下を始めます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | C | format | type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option data ... | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| C| 形式| タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションデータ… | 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RAP Option/Metric Header Format
ラップオプション/メートル法のヘッダー形式
A description of each field:
それぞれの分野の記述:
length length of the option or metric C option class, see below format data format type option type identifier data variable length
オプションが分類して、形式データの形式タイプオプションの下で識別子データ可変長をタイプするのを見るオプションかメートル法のCの長さの長さ
3.1.1 Option Class
3.1.1 オプションのクラス
This field tells implementations what to do with routes containing options or metrics they do not understand. No implementation is required to implement (i.e., understand) any given option or metric by the RAP specification itself, except for the distance metric in the RAP header.
この分野は、ルートがオプションを含んでいてするべきことかそれらがする測定基準が分からないと実装に言います。 どんな実装も、どんな与えられたオプションも実装するのが(すなわち、分かります)必要であり、RAP仕様自体でメートル法ではありません、RAPヘッダーのメートル法の距離を除いて。
Classes:
クラス:
0 use, propagate, and include this option unmodified 1 use, propagate, but do not include this option 2 use this route, but do not propagate it 3 discard this route
0がこのオプション変更されていない1使用を使用して、伝播して、含んでいますが、伝播しますが、これが発送するこのオプション2使用は含んでいませんが、それを伝播しないでください、3はこのルートを捨てます。
Note that class 0 is an imperative: if the route is propagated, the option must be included.
クラス0が命令であることに注意してください: ルートが伝播されるなら、オプションを含まなければなりません。
Class and type are entirely orthogonal, different implementations might use different classes for the same option or metric.
クラスとタイプが完全に直交している、異なった実装は同じくらいにオプションかメートル法で異なったクラスを使用するかもしれません。
3.1.2 Type
3.1.2 タイプ
The type code identifies the specific option or metric. The codes are part of the option descriptions following.
タイプコードは特定のオプションかメートル法を特定します。 続きながら、コードはオプション記述の一部です。
Ullmann [Page 10] RFC 1476 RAP June 1993
ウルマン[10ページ]RFC1476は1993年6月に叩きます。
Type 0 indicates a null (no-operation) option. It should be class zero, but an implementation that "understands" the null option may decline to propagate it.
タイプ0はヌル(操作がない)のオプションを示します。 それはクラスゼロであるべきであるが、ヌルオプションを「理解している」実装は、それを伝播するのを断るかもしれません。
Note that since an implementation may delete an option of class 1 by simply setting its type to 0 and forwarding the route description, class 1 does not provide any confidentiality of the content of an option.
実装が単に0にタイプを設定して、ルート記述を送ることによってクラス1のオプションを削除するかもしれないのでクラス1がオプションの内容の少しの秘密性も提供しないことに注意してください。
3.1.3 Format
3.1.3 形式
The format field specifies the format of the data included after the option header. Formats:
オプションヘッダーの後にデータの形式を含んでいて、形式分野は指定します。 形式:
0 none, no data present. 1 one or more 32-bit signed integers 2 a character string, null terminated 3 one or more real numbers 4 an octet string 5 one real, followed by a character string
0 なにも、データプレゼントがありません。 より1 32ビットが整数2a文字列に署名した1、ヌルが1八重奏あたり4が結ぶ3つの1か、より現実的な番号を終えた、5、ある本物、文字列はあとに続いています。
Format is also orthogonal to type, but a particular type is usually only reasonably represented by one format. This allows decoding of all option values for logging and other troubleshooting, even when the option type is unknown. (A new unknown format will still present a problem.)
また、形式もタイプするために直交していますが、通常、特定のタイプは1つの形式によって合理的に代理をされるだけです。 オプションタイプが未知であるときにさえ、これで、伐採と他のトラブルシューティングのためのすべてのオプション価値を解読します。 (それでも、新しい未知の形式は問題を提示するでしょう。)
Format 4, octet string, is to be represented in dotted-decimal byte form when printed; it is normally an internet address.
形式4(八重奏ストリング)は印刷されるとドット付き10進法バイトフォームに表されることです。 通常、それはインターネットアドレスです。
Format 5 is intended for dimensioned parameters with the character string giving the dimension or scale.
文字列が寸法かスケールを与えていて、形式5はdimensionedパラメタのために意図します。
3.2 Metrics and Options
3.2 測定基準とオプション
As much as possible, metrics are kept in the base units of bytes and seconds, by analogy to the physics systems of MKS (meter-kilogram- second) and CGS (centimeter-gram-second) of base units.
できるだけ、測定基準でバイトと秒のベース単位であることが保たれます、物理学への類推で。MKSのシステム(メーター-キログラム2番目)とベース単位のCGS(グラムが後援するセンチメートル)。
Bytes aren't the real primitive, the bit is. We are thus using a multiple of 8 that isn't part of what one would come to expect from a decimal metric system that uses the other prefixes. However, since K (kilo) is often taken to be 1024, and M (mega) to be 1,048,576 (or even 1,024,000) we allow this liberty.
バイトが全く原始でない、ビットはそうです。 その結果、私たちは1つが他の接頭語を使用する10進メートル法から予想するようになるだろうことに関する部分でない8の倍数を使用しています。 しかしながら、K(キロ)が104万8576(または、102万4000さえ)である1024年になるようにしばしば取られて、M(メガ)であるので、私たちはこの自由を許します。
Distance is measured in units also unique to the field. It is the integer number of times that a datagram must be forwarded to reach the destination. (Hop count.)
距離はその分野にユニークなもユニットで測定されます。 それは目的地に達するようにデータグラムを進めなければならないという回の整数です。 (カウントを飛び越してください。)
Ullmann [Page 11] RFC 1476 RAP June 1993
ウルマン[11ページ]RFC1476は1993年6月に叩きます。
3.2.1 Distance
3.2.1 距離
The Distance metric counts the number of hops on a route; this is included in the RAP route command header.
aのホップの数が発送するDistanceメートル番手。 これはRAPルートコマンドヘッダーに含まれています。
The initial distance at insertion into the RAP domain by the origin of the route MUST be less than or equal to 2z, where z is the number of zero bits in the route mask.
ルートの発生源によるRAPドメインへの挿入における初期の距離は、より2z以下であるに違いありません。(そこでは、zがルートマスクのゼロ・ビットの数です)。
If the origin derives the route from RIP or OSPF, and the distance exceeds 2z, the route must not be used.
発生源がルートにRIPかOSPFに由来していて、距離が2zを超えているなら、ルートを使用してはいけません。
When a router originates a route designed to permit aggregation, the distance is usefully set to more than 0; this allows simple subset aggregation without propagating small distance changes repeatedly as the internal diameter of the described network changes.
ルータが集合を可能にするように設計されたルートを溯源するとき、距離は有効に0以上に設定されます。 説明されたネットワークの内径が変化するのに応じて繰り返して短い距離変化を伝播しないで、これは簡単な部分集合集合を許容します。
For example, for routers designated to announce a default route for an AD, with a 24/48 mask, the maximum initial distance is 96.
例えば、24/48マスクでデフォルトルートをADに発表するために指定されたルータのために、最大の初期の距離は96です。
3.2.2 Delay
3.2.2 遅れ
The Delay metric (Type = 2) measures the one-way path delay. It is usually the sum of delays configured for the gateways and interfaces, but might also include path segments that are actually measured.
一方通行の経路が遅らせるDelayのメートル法(=2をタイプする)の測定。 それは、通常ゲートウェイとインタフェースに構成された遅れの合計ですが、また、実際に測定される経路セグメントを含むかもしれません。
Format is real (3), with one value. The units are seconds.
形式は1つの値がある本当の(3)です。 ユニットは秒です。
3.2.3 MTU
3.2.3 MTU
The MTU metric (Type = 3) measures the minimum value over the route of the Maximum Transmission Unit, i.e., the largest IP datagram that can be routed without resulting in fragmentation.
MTUメートル法、(タイプ=3)はMaximum Transmission Unit(すなわち、断片化をもたらさないで発送できる中で最も大きいIPデータグラム)のルートの上で最小値を測定します。
Format is one integer, measuring the MTU in bytes.
バイトでMTUを測定して、形式は1つの整数です。
3.2.4 Bandwidth
3.2.4 帯域幅
The Bandwidth metric (Type = 4) measures the minimum bandwidth of the path segments that make up the route.
ルートを作る経路の最小の帯域幅が区分するBandwidthのメートル法(=4をタイプする)の測定。
Format is one real, representing bandwidth in bytes/second.
形式はバイト/秒が1つの本当の表す帯域幅です。
3.2.5 Origin
3.2.5 発生源
The origin attribute (type = 5) identifies the router that originally inserted the route into the RAP domain. It is one of the IP addresses of the router, format is 4.
発生源属性(=5をタイプする)は元々RAPドメインにルートを挿入したルータを特定します。 それがルータのIPアドレスの1つである、形式は4です。
Ullmann [Page 12] RFC 1476 RAP June 1993
ウルマン[12ページ]RFC1476は1993年6月に叩きます。
3.2.6 Target
3.2.6 目標
The target attribute (type = 6) identifies a host or network toward which the route should be propagated, regardless of proximity filtering that would otherwise occur. This aids in the establishment of tunnels for hosts or subnets "away from home." It can be used to force the route to propagate all the way to the home network, or to try to propagate a better route to a host that the origin has established a connection (e.g., TCP) with. Note that a router can distinguish these two cases during proximity filtering by comparing the route described with the host or network identified by the target option.
目標属性(=6をタイプする)はルートが伝播されるべきであるホストかネットワークを特定します。そうでなければ、近接にかかわらず、それをフィルターにかけるのは起こるでしょう。 これはホストかサブネットのために「ホームから遠くへ」トンネルの設立で支援されます。 ルートにホームネットワークまでのいっぱいに伝播しようとするか、または発生源と取引関係を築いた(例えば、TCP)ホストにより良いルートを伝播させようとするように、それを使用できます。 ルータが近接フィルタリングの間ホストかネットワークが目標オプションで特定されている状態で説明されたルートを比較することによってこれらの2つのケースを区別できることに注意してください。
Format is 4.
形式は4です。
3.2.7 Packet Cost
3.2.7 パケット費用
The packet cost metric (type = 7) measures the actual cost (to someone) of sending data over the route. It is probably either class 3 or 0. Format is 5.
メートル法(=7をタイプする)の測定はルートの上で送付データの実費(だれかへの)をパケットに費やします。 それはたぶんクラス3か0です。 形式は5です。
The real number is the cost in currency units/byte. Tariffs set in packets or "segments" should be converted using the nominal (or actual path) size. For example, Sprintnet charges for DAF connections within its network are US$1.40/Ksegment thus for segments of 64 bytes, the cost is 0.000021875 USD.
実数は通貨ユニット/バイトが費用です。 関税がパケットにセットしたか、または「セグメント」は、名目上(または、実際の経路)のサイズを使用することで変換されるべきです。 例えば、ネットワークの中のDAF接続のためのSprintnet料金は1.40/Ksegment USドルです、その結果、64バイトのセグメントのために、費用が0.000021875U.S.ドルです。
The string is the 3 capital letter ISO code [ISO4217] for the currency used. Funds codes and codes XAU, XBA, XBB, XBC, XBD, and XXX are not used.
ストリングは通貨のためのISOコード[ISO4217]が使用した3大文字です。 基金のコードのコード、XAU、XBA、XBB、XBC、XBD、およびXXXは使用されていません。
If a route already has a packet cost in a different currency associated with it, another instance of this option should be added. RAP implementations MUST NOT attempt to convert the currency units except when actually making a route selection decision. That is, the effects of a currency conversion should never be propagated, except for the proper effect of such a selection decision.
ルートがそれに関連している異なった通貨に既にパケット費用を持つなら、このオプションの別の例は加えられるべきです。 RAP実現は、実際にルート選択決定をする時以外に、通貨ユニットを変換するのを試みてはいけません。 すなわち、通貨の転換の効果は決して伝播されるべきではありません、そのような選択決定の適切な効果を除いて。
3.2.8 Time Cost
3.2.8 時間費用
The time cost metric (type = 8) measures the actual cost of holding one or more paths in the route open to send data. It is probably either class 3 or 0. Format is 5.
メートル法(=8をタイプする)の測定が1つを保持する実費を時間に費やしたか、またはルートの、より多くの経路が、データを送るために開きます。 それはたぶんクラス3か0です。 形式は5です。
The real number is the cost in currency units/second. For example, Sprintnet charges for international connections (to typical destinations) are US$10/hour so the cost is 0.002777778 USD.
実数は2番目に、通貨ユニット/の費用です。 例えば、国際的な接続(典型的な目的地への)のためのSprintnet料金が10USドル/時間であるので、費用は0.002777778U.S.ドルです。
Ullmann [Page 13] RFC 1476 RAP June 1993
ウルマン[13ページ]RFC1476は1993年6月に叩きます。
The other notes re codes used and conversions in the previous section also apply.
また、前項でのコードが使用したもう片方の注意reと変換は適用されます。
3.2.9 Source Restriction
3.2.9 ソース制限
A source restriction option (type 9, format 4, class 2 or 3) indicates that a route may only be used by datagrams from a particular source or set of sources. The data consists of a network or host number, and a mask to qualify it. If multiple source restriction options are included, the restriction is the logical union of the sources specified; i.e., any are permitted.
ソース制限オプション(9をタイプしてください、形式4、クラス2か3)は、ルートがデータグラムによって特定のソースか1セットの源から使用されるだけであるかもしれないのを示します。 データは、それに資格を与えるためにネットワークかホスト番号と、マスクから成ります。 複数のソース制限オプションが含まれているなら、制限は指定されたソースの論理的な組合です。 すなわち、いずれも受入れられます。
Source restrictions must be added to routes when the RAP system has security filters set in the IP forwarding layer. This is necessary to prevent datagrams from taking "better" routes that end in the datagram being silently discarded at the filter. Note that this propagates confidential information about the security configuration, but only toward the net authorized to use the route if the RAP implementation is careful about where it is propagated.
IP推進層の中にRAPシステムでセキュリティフィルタを設定すると、ソース制限をルートに追加しなければなりません。 これが、データグラムがその終わりにフィルタで静かに捨てられたデータグラム存在で「より良い」ルートを取るのを防ぐのに必要です。 これがセキュリティ構成に関する秘密情報を伝播しますが、RAP実現がどこに関して慎重であるかならルートを使用するのが認可されたネットだけに向かって、それが伝播されることに注意してください。
3.2.10 Destination Restriction
3.2.10 目的地制限
A destination restriction option (type 10, format 4, class 3) serves only to provide a non-contiguous mask, the destination already having been specified in the command header. Data is the destination network and mask.
目的地制限オプション(10をタイプしてください、形式4、クラス3)は、単に、非隣接のマスク(コマンドヘッダーで既に指定された目的地)を提供するのに役立ちます。 データは、送信先ネットワークとマスクです。
3.2.11 Trace
3.2.11 跡
Trace (type 11, format 4, class 0) provides an indication that the route has propagated through a particular system. This can be used for loop detection, as well as various methods of troubleshooting. The data is one internet address, one of the addresses of the system. If an arriving route already carries a trace identifying this system, and is not an update, it is discarded. If it is an update, the route is purged.
跡(タイプ11、形式4、クラス0)はルートに特定のシステムを通して伝播されたという指示を提供します。 輪の検出、およびトラブルシューティングの様々な方法にこれを使用できます。 データは1つのインターネットアドレス、システムのアドレスの1つです。 到着ルートが既にこのシステムを特定する跡を運んで、アップデートでないなら、捨てられます。 それがアップデートであるなら、ルートは掃除されます。
Trace SHOULD NOT be simply added to every route traversing a system. Rather, it should be added (if being used for loop detection) when there is a suspicion that a loop has formed.
システムを横断するあらゆるルートに追加されて、跡のSHOULD NOTは単にそうです。 容疑があるとき、むしろ、輪が形成されたと言い足されるべきです(輪の検出に使用されるなら)。
When the distance to a destination has increased twice in a row in a fairly short period of time, and the number of trace options present in the route did not increase as a result of the last update, the RAP process should add a trace option identifying itself to the route. Effectively, when a loop forms, one router will select itself to be a tracer, adding itself and breaking the loop after one more turn. If that fails for some reason, another router will add its trace. Each
目的地への距離が時間のかなり短い時代に二度並んで増えて、ルートの現在の跡のオプションの数がアップデートの結果、増加しなかったとき、RAPの過程はルートにそれ自体を特定する跡のオプションを加えるべきです。 輪が形成されるとき、事実上、1つのルータが、それ自体が追跡者であることを選択するでしょう、それ自体ともうひとつの後の輪を壊すのがターンすると言い足して。 それがある理由で失敗すると、別のルータは跡を加えるでしょう。 それぞれ
Ullmann [Page 14] RFC 1476 RAP June 1993
ウルマン[14ページ]RFC1476は1993年6月に叩きます。
router thus depends in the end only on its own trace and will break the loop, even if the other routers are using other methods, or simply counting-out the route.
ルータは、その結果、結局、それ自身の跡だけによって、輪を壊すでしょう、他のルータが他の方法を使用すること、または単にルートを除外していても。
3.2.12 AUP
3.2.12 AUP
The AUP (Acceptable Use Policy) option (type 12, format 2, class any), tags a route as being useable only according to the policy of a network. This may be used to avoid traversal of the net by (for example) commercial traffic, or to prevent un-intentional use of an organization's internal net. (It does not provide a security barrier in the sense of forwarding filters, but does provide cooperative exchange of information on the useability of a net.)
AUP(許容できるUse Policy)オプション(タイプ12(形式2)はいずれも分類する)、ネットワークの方針だけに応じて、タグaは存在としてuseableを発送します。 これは、(例えば、)商業交通によるネットの縦断を避けるか、または組織の内部のネットの意図的でない使用を防ぐのに使用されるかもしれません。 (それは、フィルタを進めるという意味にセキュリティバリアを提供しませんが、ネットのuseabilityで協力的な情報交換を供給します。)
The data is a domain name, probably the name of the network, although it may be the name of another organization. E.g., the routers that are subject to the NSF AUP might add NSF.NET as the descriptor of that policy.
データはドメイン名、たぶんネットワークの名前です、それが別の組織の名前であるかもしれませんが。 例えば、NSF AUPを受けることがあるルータはその方針に関する記述子としてNSF.NETを加えるかもしれません。
3.2.13 Public
3.2.13 公共です。
Public (type 13, format 0, class 2 or 3) marks the route as consisting in part of a public broadcast medium. Examples of a public medium are direct radio broadcast or a multi-drop cable in which other receivers, not associated with the destination may read the traffic. I.e., a TV cable is a public medium, a LAN within an organization is not, even if it can be easily wiretapped.
公衆は公共放送媒体の一部成るとしてルートをマークします(13をタイプしてください、形式0、クラス2か3)。 交通が読まれて、公共の媒体に関する例は、目的地に関連づけられなかった他の受信機がそうするかもしれないダイレクト無線放送かマルチ低下ケーブルです。 すなわち、テレビのケーブルが公共の媒体である、組織の中のLANはそうではありません、容易にそれを盗聴できても。
This is intended for use by cable TV providers to identify routes that should not be used for private communications, in spite of the attractively high bandwidth being offered.
これがケーブルテレビプロバイダーによる使用が私信に使用されるべきでないルートを特定することを意図する、魅力的である、提供される高帯域。
4. Procedure
4. 手順
Routing information arrives in the RAP process from other peers, from (local) static route and interface configuration, and from other protocols (e.g., RIP). The RAP process filters out routes that are of no interest (too detailed or too "far away" in the topology) and builds an internal database of available routes.
ルート設定情報は他の同輩と、(地方)のスタティックルートとインタフェース構成と、他のプロトコル(例えば、RIP)からのRAPの過程に到着します。 RAPの過程は、全く(トポロジーで詳細過ぎるか「遠過ぎる」)のおもしろくないルートを無視して、利用可能なルートの内部のデータベースを築き上げます。
From this database, it selects routes that are to be active and loads them into the IP forwarding database.
このデータベースから、それは、アクティブであることになっているルートを選択して、それらをIP推進データベースに積み込みます。
It then advertises those routes to its peers, at a greater distance.
そして、それはより遠い距離でそれらのルートの同輩に広告を出します。
Ullmann [Page 15] RFC 1476 RAP June 1993
ウルマン[15ページ]RFC1476は1993年6月に叩きます。
-------------------------------------------------------------------
-------------------------------------------------------------------
[incoming routes]
|
v
[proximity filtering/aggregation] [static routes]
| |
v v
[route database] ---> [selected active routes]
^ |
| v
[RIP, etc. routes] [output filtering]
|
v
[routes advertised]
[入って来るルート]| v[近接フィルタリング/集合][スタティックルート]| | v[ルートデータベース]に対して--->[アクティブなルートを選択する]^| | [RIP、などルート][出力フィルタリング]に対して| v[広告に掲載されたルート]
-------------------------------------------------------------------
-------------------------------------------------------------------
4.1 Receiver filtering
4.1 受信機フィルタリング
The first step is to filter out offered routes that are too "far away" or too specific. The filter consists of a maximum distance at which a route is considered usable for each possible (contiguous) mask.
第一歩は「遠過ぎる」か特定過ぎる提供されたルートを無視することです。 フィルタはルートがそれぞれの可能な(隣接の)マスクに使用可能であると考えられる最大距離から成ります。
Routers that need universal connectivity must either pass through the filter all routes regardless of distance (short of "infinity"), and use aggregation to reduce them, or have a default route to a router that does this.
普遍的な接続性を必要とするルータは、これをするルータに、距離(「無限」に不足した)にかかわらずフィルタにすべてのルートを通して、それらを減少させるのに集合を使用しなければならないか、またはデフォルトルートを持たなければなりません。
The filter may be adjusted dynamically to fit limited resources, but if the filter is opened, i.e., made less restrictive, there may be routes that have already been offered and discarded that will never become available.
すなわち、それほど制限しているのに作られていなくて、フィルタが開けられるなら、既に提供されたルートがあるかもしれません、そして、フィルタは限りある資源に合うようにダイナミックに調整されるかもしれませんが、捨てられて、それは利用可能に決してならないでしょう。
4.2 Update of metrics and options
4.2 測定基準とオプションのアップデート
The process then updates any metrics present on the route to reflect the path to the RAP peer. MTU and bandwidth are minimized, delay and cost are added in. Distance is incremented. Any unknown options cause class-dependent processing: discarding the option (class 2) or route (3), or marking the route as non-propagatable (1).
そして、過程は、RAP同輩に経路を反映するためにルートの現在のどんな測定基準もアップデートします。 MTUと帯域幅は最小にされて、遅れと費用は加えられます。 距離は増加されています。 どんな未知のオプションもクラス依存する処理を引き起こします: オプション(クラス2)かルート(3)を捨てるか、または非伝播可能(1)としてルートをマークします。
Policy options that are known may cause the route to be discarded at this stage.
知られている政策選択で、現在のところ、ルートを捨てるかもしれません。
Ullmann [Page 16] RFC 1476 RAP June 1993
ウルマン[16ページ]RFC1476は1993年6月に叩きます。
4.3 Aggregation
4.3 集合
The next step is to aggregate routes that are subsetted by other routes through the same peer. This should not be done automatically in every possible case. The more information that is propagated, the more effective the use of forward route identifiers is likely to be, particularily in the case of aggregating into a default route.
次のステップは同じ同輩を通して他のルートでsubsettedされるルートに集めることです。 これは自動的にありとあらゆる場合に完了しているべきではありません。 前進のルート識別子の、より多くが、情報が伝播されて、使用が効果的であれば効果的であるほど、デフォルトルートに集める場合でありそうであって、particularilyです。
In general, a route can be included in an aggregate, and not propagated further, if it is through the same peer (next hop) and has a smaller distance metric than the containing route. (Thus datagrams will always travel "downhill" as they take more specific routes.)
一般に、ルートを集合に含んでいて、さらに伝播できません、同じ同輩(次のホップ)を通してあって、含んでいるルートより小さい距離メトリックを持っているなら。 (その結果、より特定のルートを取るのに応じて、データグラムはいつも「ダウンヒル」を旅行するでしょう。)
The usual case of aggregation is that routes derived from interface configurations on the routers from which they originated are subsumed into routes offered by routers explicitly configured to route for an entire network, area, or AD. If the larger area becomes partitioned, unaggregatable routes will appear (as routes outside the area become the shortest distance routes) and traffic will flow around the partition.
集合の普通のケースはそれらが由来したルータでのインタフェース構成から得られたルートが全体のネットワークのために明らかにルートに構成されたルータによって提供されたルート、領域、またはADまで包括されているということです。 より広大な地域が仕切られるようになると、「非-集合-可能」ルートは現れるでしょう、そして、(領域の外のルートが最短距離ルートになるとき)交通はパーティションの周りを流れるでしょう。
Attributes of routes, particularily policy options, may prevent aggregation and may result in routes simply being discarded.
ルートの属性(particularily政策選択)は集合を防いで、単にルートをもたらして、捨てられるかもしれません。
Some information about aggregation also needs to be represented in the forwarding database, if the route is made active: the router will need to make a decision as to which forward route identifier to use for each datagram arriving on the active route.
また、ルートをアクティブにするなら、集合の何らかの情報が、推進データベースに表される必要があります: ルータは、アクティブなルートで届く各データグラムにどの前進のルート識別子を使用したらよいかに関して決定する必要があるでしょう。
4.4 Active route selection
4.4 活発なルート選択
The router selects those routes to be entered into the IP forwarding database and actively used to forward datagrams from the set of routes after aggregation, combined with routes derived from other protocols such as RIP. This selection may be made on any combination of attributes and options desired by local policy.
ルータは、RIPなどの他のプロトコルから得られたルートに結合された集合の後にルートのセットからデータグラムを進めるためにそれらのルートがIP推進データベースに入られて、活発に使用されるのを選択します。 ローカルの方針で望まれていた属性とオプションのどんな組み合わせのときにもこの選択をするかもしれません。
4.5 Transmitter filtering
4.5 送信機フィルタリング
Finally, the RAP process must decide which routes to offer to its peers. These must be a subset of the active routes, and may in turn be a selected subset for each peer. Arbitrary local policies may be used in deciding whether or not to offer any particular route to a given peer.
最終的に、RAPの過程は、どのルートを同輩に提供したらよいかを決めなければなりません。 これらは、アクティブなルートの部分集合でなければならなく、順番に各同輩のための選択された部分集合であるかもしれません。 何か特定のルートを与えられた同輩に提供するかどうか決める際に任意のローカルの方針は使用されるかもしれません。
However, the transmitter must ensure that any datagram filters are represented in the offered route, so that the peer (and its peers) will not route into a black hole.
しかしながら、送信機は、どんなデータグラムフィルタも提供されたルート(同輩(そして、同輩)がブラックホールの中に発送しないそう)に表されるのを確実にしなければなりません。
Ullmann [Page 17] RFC 1476 RAP June 1993
ウルマン[17ページ]RFC1476は1993年6月に叩きます。
4.6 Last resort loop prevention
4.6 切り札の輪の防止
RAP is designed to support many different kinds of routing selection algorithms, and allow them to interact to varying extents. Routes can be shared among administrations, and between systems managed with more or less sophistication.
RAPは、多くの異種のルーティング選択アルゴリズムを支持して、それらが異なった範囲に相互作用するのを許容するように設計されています。 政権の中と、そして、だいたい洗練で経営されたシステムの間でルートを共有できます。
This leaves one absolute requirement: routing loops must be self- healing, regardless of the algorithm used on each host. There are two caveats:
これは1つの絶対条件を残します: ルーティング輪は各ホストの上で使用されるアルゴリズムにかかわらず治療の自己であるに違いありません。 2つの警告があります:
1. A loop will not fix itself in the presence of an error that
continually recurs (thus re-generating the loop)
1. 輪は絶えず再発する誤りがあるときそれ自体を修理しないでしょう。(その結果、輪を作り直します)
2. The last resort algorithm does not provide rapid breaking of
loops, only eventual breaking of them even in the absence of
any intervention by (human) intelligence.
2. 切り札のアルゴリズムは、(人間)の知性によるどんな介入がないときでさえ輪、それらを最後の壊すことだけを矯正しながら、急速な状態で提供されません。
The algorithm relies on the distance in the RAP route header. This count must be updated (i.e., incremented by one) at each router forwarding the route.
アルゴリズムはRAPルートヘッダーの距離を当てにします。 ルートを進める各ルータでこのカウントをアップデートしなければなりません(すなわち、1つ増加されます)。
Routers must also impose some limit on the number of hops permitted in incoming routes, discarding any routes that exceed the limit. This limit is "infinity" in the classic algorithm. In RIP, infinity is 15, much too low for general inter-domain routing.
また、ルータは入って来るルートで受入れられたホップの数に何らかの限界を課さなければなりません、度を超すどんなルートも捨てて。 古典的なアルゴリズムでこの限界は「無限」です。 RIPでは、無限は非常に低く一般的な相互ドメインルーティングのための15であり過ぎます。
In RAP, infinity is defined as 2z + i, where z is the number of zero bits in the mask (as described previously) and i is a small number which MUST be configurable.
RAPでは、無限は2z+iと定義されます、そして、iは構成可能であるに違いない少ない数です。(そこでは、zがマスクのゼロ・ビットの数(以前に説明されるように)です)。
Note that RAP depends on the last resort algorithm, "counting to infinity," much less than predecessors such as RIP. Routes in the RAP domain will usually be purged from the net as the purge route command is flooded without the delays typical of periodic broadcast algorithms. Only in some cases will loops form, and they will be counted out as fast as the routing processes can exchange the information.
RAPが「無限で数え」て、RIPなどの前任者よりはるかに少ない切り札のアルゴリズムによることに注意してください。 パージルート命令が周期的な放送アルゴリズムの典型の遅れなしで水につかっているので、通常、ネットはRAPドメインのルートから追放されるでしょう。輪はいくつかの場合だけで形成されるでしょう、そして、それらはルーティングの過程が情報を交換できるのと同じくらい速く除外されるでしょう。
5. Conclusion
5. 結論
Unlike prior routing protocols, RAP is designed to solve the entire problem, from hands-off autoconfiguration of LAN networks, to implementing the most complex policies of international carriers. It provides a scaleable solution to carry the Internet forward to a future in which essentially all users of data transmission use IP as the fabric of their networks.
先のルーティング・プロトコルと異なって、RAPは全体の問題を解決するように設計されています、LANネットワークの下に手の自動構成から、国際的な航空会社の最も複雑な政策を実施するのに。 それは、インターネットをデータ伝送の本質的にはすべてのユーザが彼らのネットワークの織物としてIPを使用する未来まで進展させるようにスケーラブルな解決法を提供します。
Ullmann [Page 18] RFC 1476 RAP June 1993
ウルマン[18ページ]RFC1476は1993年6月に叩きます。
6. Appendix: Real Number Representation
6. 付録: 実数表現
Real numbers are represented by a one byte exponent, e, in excess-128 notation, and a fraction, f, in excess-8388608 notation, with the radix point at the right. (I.e., the "fraction" is actually an integer.)
実数は1バイトの解説者によって表されます、e、余分な128記法、および断片で、f、余分な8388608記法で、権利における小数点で。 (すなわち、「断片」は実際に整数です。)
e is thus in the range 0 to 255, representing exponents (powers of 2) in the range 2^-128 to 2^127.
その結果、eはそうです。範囲2^-128で解説者(2人の強国)の2^127に代理をする範囲0〜255で。
f is in the range 0 to 16777215, representing numbers from -8388608 to 8388607
-8388608〜8388607まで数を表して、fが範囲に0〜16777215にあります。
The value is (f-8338608) x 2^(e-128)
値は(f-8338608)x2^です。(e-128)
The real number is not necessarily normalized, but a normalized representation will, of course, provide more accuracy for numbers not exactly representable.
実数は必ず正常にされるというわけではありませんが、正常にされた表現はもちろんちょうど「表-可能」ではなく、数により多くの精度を提供するでしょう。
Example code, in C:
Cの例のコード:
#include <math.h>
#<math.h>を含めてください。
typedef struct {
unsigned e : 8;
unsigned f : 24;
} real;
typedef struct、無記名のe: 8無記名のf: (24)、本当。
double a; /* input value */ real r; double b; /* output value */ double d; int e32;
aを倍にしてください。 /*は値*/本当のrを入力しました。 bを倍にしてください。 /*は値*/二重なdを出力しました。 int e32。
/* convert to real: */
本当への/*転向者: */
d = frexp(a, &e32); r.e = e32+105; r.f = (int)(d*8388608.0) + 8388608;
dはfrexpと等しいです(a、およびe32)。 r. eはe32+105と等しいです。 r. fは(int)(d*8388608.0)+8388608と等しいです。
/* convert back: */
/*転向者後部: */
b = ldexp((double)r.f - 8388608.0, (int)r.e - 128);
bはldexp((二重)のr.f--8388608.0、(int)r.e--128)と等しいです。
Ullmann [Page 19] RFC 1476 RAP June 1993
ウルマン[19ページ]RFC1476は1993年6月に叩きます。
7. References
7. 参照
[ISO3166] International Organization for Standardization. Codes
for the Representation of Names of Countries. ISO
3166, ISO, 1988.
[ISO3166]国際標準化機構。 国の名前の表現のためのコード。 ISO3166、ISO、1988。
[ISO4217] International Organization for Standardization. Codes
for the representation of currencies and funds. ISO
4217, ISO, 1981.
[ISO4217]国際標準化機構。 通貨と基金の表現のためのコード。 ISO4217、ISO、1981。
[RFC791] Postel, J., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 791, DARPA,
September 1981.
[RFC791] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD5、RFC791、DARPA、1981年9月。
[RFC1058] Hedrick, C., "Routing Information Protocol", STD 34,
RFC 1058, Rutgers University, June 1988.
[RFC1058]ヘドリック、C.、「ルーティング情報プロトコル」、STD34、RFC1058、ラトガース大学、1988年6月。
[RFC1247] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc.,
July 1991.
[RFC1247]Moy、J.、「OSPF、バージョン2インチ、RFC1247、Proteon Inc.、1991インチ年7月。
[RFC1287] Clark, D., Chapin, L., Cerf, V., Braden, R., and
R. Hobby, "Towards the Future Internet Architecture",
RFC 1287, MIT, BBN, CNRI, ISI, UCDavis, December 1991.
[RFC1287] クラークとD.とチェーピンとL.とサーフとV.とブレーデン、R.とR.趣味、「将来のインターネットアーキテクチャ」、RFC1287、MIT、BBN、CNRI、ISI、UCDavis(1991年12月)。
[RFC1338] Fuller, V., Li, T., Yu, J., and K. Varadhan,
"Supernetting: an Address Assignment and Aggregation
Strategy", RFC 1338, BARRNet, cicso, Merit, OARnet,
June 1992.
[RFC1338] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「スーパーネッティング:」 Merit、OARnet、「Address AssignmentとAggregation Strategy」(RFC1338、BARRNet)がcicsoする、6月1992日
[RFC1475] Ullmann, R., "TP/IX: The Next Internet", RFC 1475,
Process Software Corporation, June 1993.
[RFC1475]ウルマン、R.、「TP/IX:」 「次のインターネット」、RFC1475は1993年6月にソフトウェア社を処理します。
8. Security Considerations
8. セキュリティ問題
Security issues are discussed in sections 3.2.9 and 3.2.12.
セクション3.2.9と3.2で.12に安全保障問題について議論します。
9. Author's Address
9. 作者のアドレス
Robert Ullmann Process Software Corporation 959 Concord Street Framingham, MA 01701 USA
ロバートウルマンプロセスソフトウェア社959の一致通りMA01701フレイミングハム(米国)
Phone: +1 508 879 6994 x226 Email: Ariel@Process.COM
以下に電話をしてください。 +1 6994年の508 879x226メール: Ariel@Process.COM
Ullmann [Page 20]
ウルマン[20ページ]
一覧
スポンサーリンク
