RFC1479 日本語訳
1479 Inter-Domain Policy Routing Protocol Specification: Version 1. M.Steenstrup. July 1993. (Format: TXT=275823 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Steenstrup
Request for Comments: 1479 BBN Systems and Technologies
July 1993
コメントを求めるワーキンググループM.ステーンストルプの要求をネットワークでつないでください: 1479台のBBNシステムと技術1993年7月
Inter-Domain Policy Routing Protocol Specification: Version 1
相互ドメイン方針ルート設定プロトコル仕様: バージョン1
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
We present the set of protocols and procedures that constitute Inter-Domain Policy Routing (IDPR). IDPR includes the virtual gateway protocol, the flooding protocol, the route server query protocol, the route generation procedure, the path control protocol, and the data message forwarding procedure.
私たちはInter-ドメインPolicyルート設定(IDPR)を構成するプロトコルと手順のセットを寄贈します。 IDPRは仮想のゲートウェイプロトコル、氾濫プロトコル、ルートサーバ質問プロトコル、ルート世代手順、経路制御プロトコル、およびデータメッセージ推進手順を含んでいます。
Contributors
貢献者
The following people have contributed to the protocols and procedures described in this document: Helen Bowns, Lee Breslau, Ken Carlberg, Isidro Castineyra, Deborah Estrin, Tony Li, Mike Little, Katia Obraczka, Sam Resheff, Martha Steenstrup, Gene Tsudik, and Robert Woodburn.
以下の人々は本書では説明されたプロトコルと手順に貢献しました: ヘレンBowns、リー・ブレスラウ、ケンCarlberg、イシドロCastineyra、デボラEstrin、トニー・李、マイク・リトル、カチアObraczka、サムResheff、マーサ・ステーンストルプ、遺伝子Tsudik、およびロバートWoodburn。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Domain Elements . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. IDPR Functions. . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.1. IDPR Entities . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Policy Semantics. . . . . . . . . . . . . . . . . . . . . . . 7 1.4.1. Source Policies . . . . . . . . . . . . . . . . . . . . . . 7 1.4.2. Transit Policies. . . . . . . . . . . . . . . . . . . . . . 8 1.5. IDPR Message Encapsulation. . . . . . . . . . . . . . . . . . 9 1.5.1. IDPR Data Message Format. . . . . . . . . . . . . . . . . .11 1.6. Security. . . . . . . . . . . . . . . . . . . . . . . . . . .12 1.7. Timestamps and Clock Synchronization. . . . . . . . . . . . .13 1.8. Network Management. . . . . . . . . . . . . . . . . . . . . .14 1.8.1. Policy Gateway Configuration. . . . . . . . . . . . . . . .17 1.8.2. Route Server Configuration. . . . . . . . . . . . . . . . .18
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. ドメイン要素. . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 方針。 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. IDPRは機能します。 . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.1. IDPR実体. . . . . . . . . . . . . . . . . . . . . . . 6 1.4。 方針意味論。 . . . . . . . . . . . . . . . . . . . . . . 7 1.4.1. ソース方針. . . . . . . . . . . . . . . . . . . . . . 7 1.4.2。 運送保険証券。 . . . . . . . . . . . . . . . . . . . . . 8 1.5. IDPRメッセージカプセル化。 . . . . . . . . . . . . . . . . . 9 1.5.1. IDPRデータメッセージ・フォーマット。 . . . . . . . . . . . . . . . . .11 1.6. セキュリティ。 . . . . . . . . . . . . . . . . . . . . . . . . . .12 1.7. タイムスタンプと時計同期。 . . . . . . . . . . . .13 1.8. ネットワークマネージメント。 . . . . . . . . . . . . . . . . . . . . .14 1.8.1. 方針ゲートウェイ構成。 . . . . . . . . . . . . . . .17 1.8.2. サーバ構成を発送してください。 . . . . . . . . . . . . . . . .18
Steenstrup [Page 1] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[1ページ]RFC1479IDPRは1993年7月に議定書を作ります。
2. Control Message Transport Protocol. . . . . . . . . . . . . . .18 2.1. Message Transmission. . . . . . . . . . . . . . . . . . . . .20 2.2. Message Reception . . . . . . . . . . . . . . . . . . . . . .22 2.3. Message Validation. . . . . . . . . . . . . . . . . . . . . .23 2.4. CMTP Message Formats. . . . . . . . . . . . . . . . . . . . .24 3. Virtual Gateway Protocol. . . . . . . . . . . . . . . . . . . .27 3.1. Message Scope . . . . . . . . . . . . . . . . . . . . . . . .28 3.1.1. Pair-PG Messages. . . . . . . . . . . . . . . . . . . . . .28 3.1.2. Intra-VG Messages . . . . . . . . . . . . . . . . . . . . .29 3.1.3. Inter-VG Messages . . . . . . . . . . . . . . . . . . . . .29 3.1.4. VG Representatives. . . . . . . . . . . . . . . . . . . . .31 3.2. Up/Down Protocol. . . . . . . . . . . . . . . . . . . . . . .31 3.3. Implementation. . . . . . . . . . . . . . . . . . . . . . . .33 3.4. Policy Gateway Connectivity . . . . . . . . . . . . . . . . .35 3.4.1. Within a Virtual Gateway. . . . . . . . . . . . . . . . . .35 3.4.2. Between Virtual Gateways. . . . . . . . . . . . . . . . . .37 3.4.3. Communication Complexity. . . . . . . . . . . . . . . . . .40 3.5. VGP Message Formats . . . . . . . . . . . . . . . . . . . . .41 3.5.1. UP/DOWN . . . . . . . . . . . . . . . . . . . . . . . . . .41 3.5.2. PG CONNECT. . . . . . . . . . . . . . . . . . . . . . . . .42 3.5.3. PG POLICY . . . . . . . . . . . . . . . . . . . . . . . . .43 3.5.4. VG CONNECT. . . . . . . . . . . . . . . . . . . . . . . . .44 3.5.5. VG POLICY . . . . . . . . . . . . . . . . . . . . . . . . .45 3.5.6. Negative Acknowledgements . . . . . . . . . . . . . . . . .46 4. Routing Information Distribution. . . . . . . . . . . . . . . .47 4.1. AD Representatives. . . . . . . . . . . . . . . . . . . . . .48 4.2. Flooding Protocol . . . . . . . . . . . . . . . . . . . . . .48 4.2.1. Message Generation. . . . . . . . . . . . . . . . . . . . .50 4.2.2. Sequence Numbers. . . . . . . . . . . . . . . . . . . . . .52 4.2.3. Message Acceptance. . . . . . . . . . . . . . . . . . . . .52 4.2.4. Message Incorporation . . . . . . . . . . . . . . . . . . .54 4.2.5. Routing Information Database. . . . . . . . . . . . . . . .56 4.3. Routing Information Message Formats . . . . . . . . . . . . .57 4.3.1. CONFIGURATION . . . . . . . . . . . . . . . . . . . . . . .57 4.3.2. DYNAMIC . . . . . . . . . . . . . . . . . . . . . . . . . .62 4.3.3. Negative Acknowledgements . . . . . . . . . . . . . . . . .63 5. Route Server Query Protocol . . . . . . . . . . . . . . . . . .64 5.1. Message Exchange. . . . . . . . . . . . . . . . . . . . . . .64 5.2. Remote Route Server Communication . . . . . . . . . . . . . .65 5.3. Routing Information . . . . . . . . . . . . . . . . . . . . .66 5.4. Routes. . . . . . . . . . . . . . . . . . . . . . . . . . . .67 5.5. Route Server Message Formats. . . . . . . . . . . . . . . . .67 5.5.1. ROUTING INFORMATION REQUEST . . . . . . . . . . . . . . . .67 5.5.2. ROUTE REQUEST . . . . . . . . . . . . . . . . . . . . . . .68 5.5.3. ROUTE RESPONSE. . . . . . . . . . . . . . . . . . . . . . .71 5.5.4. Negative Acknowledgements . . . . . . . . . . . . . . . . .72 6. Route Generation. . . . . . . . . . . . . . . . . . . . . . . .73 6.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . . .74
2. メッセージトランスポート・プロトコルを制御してください。 . . . . . . . . . . . . . .18 2.1. メッセージ送信。 . . . . . . . . . . . . . . . . . . . .20 2.2. メッセージレセプション. . . . . . . . . . . . . . . . . . . . . .22 2.3。 メッセージ合法化。 . . . . . . . . . . . . . . . . . . . . .23 2.4. CMTPメッセージ・フォーマット。 . . . . . . . . . . . . . . . . . . . .24 3. 仮想のゲートウェイプロトコル。 . . . . . . . . . . . . . . . . . . .27 3.1. メッセージ範囲. . . . . . . . . . . . . . . . . . . . . . . .28 3.1.1。 組未成年者不適当映画メッセージ。 . . . . . . . . . . . . . . . . . . . . .28 3.1.2. イントラ-VGメッセージ. . . . . . . . . . . . . . . . . . . . .29 3.1.3。 相互VGメッセージ. . . . . . . . . . . . . . . . . . . . .29 3.1.4。 VG代表。 . . . . . . . . . . . . . . . . . . . .31 3.2. /下にプロトコルに。 . . . . . . . . . . . . . . . . . . . . . .31 3.3. 実現。 . . . . . . . . . . . . . . . . . . . . . . .33 3.4. 方針ゲートウェイの接続性. . . . . . . . . . . . . . . . .35 3.4.1。 仮想のゲートウェイの中で。 . . . . . . . . . . . . . . . . .35 3.4.2. 仮想のゲートウェイの間で。 . . . . . . . . . . . . . . . . .37 3.4.3. コミュニケーションの複雑さ。 . . . . . . . . . . . . . . . . .40 3.5. VGPメッセージ・フォーマット. . . . . . . . . . . . . . . . . . . . .41 3.5.1。 /に、.2は.3.5にダウンしています。 未成年者不適当映画は接続します。 . . . . . . . . . . . . . . . . . . . . . . . .42 3.5.3. 未成年者不適当映画方針. . . . . . . . . . . . . . . . . . . . . . . . .43 3.5.4。 VGは接続します。 . . . . . . . . . . . . . . . . . . . . . . . .44 3.5.5. VG方針. . . . . . . . . . . . . . . . . . . . . . . . .45 3.5.6。 否定的承認. . . . . . . . . . . . . . . . .46 4。 情報流通を発送します。 . . . . . . . . . . . . . . .47 4.1. AD代表。 . . . . . . . . . . . . . . . . . . . . .48 4.2. プロトコル. . . . . . . . . . . . . . . . . . . . . .48 4.2.1をあふれさせます。 メッセージ世代。 . . . . . . . . . . . . . . . . . . . .50 4.2.2. 一連番号。 . . . . . . . . . . . . . . . . . . . . .52 4.2.3. メッセージ承認。 . . . . . . . . . . . . . . . . . . . .52 4.2.4. メッセージ編入. . . . . . . . . . . . . . . . . . .54 4.2.5。 情報データベースを発送します。 . . . . . . . . . . . . . . .56 4.3. 情報メッセージ・フォーマット. . . . . . . . . . . . .57 4.3.1を発送します。 構成. . . . . . . . . . . . . . . . . . . . . . .57 4.3.2。 動力. . . . . . . . . . . . . . . . . . . . . . . . . .62 4.3.3。 否定的承認. . . . . . . . . . . . . . . . .63 5。 サーバ質問プロトコル. . . . . . . . . . . . . . . . . .64 5.1を発送してください。 交換処理。 . . . . . . . . . . . . . . . . . . . . . .64 5.2. リモートルートサーバコミュニケーション. . . . . . . . . . . . . .65 5.3。 情報. . . . . . . . . . . . . . . . . . . . .66 5.4を発送します。 ルート。 . . . . . . . . . . . . . . . . . . . . . . . . . . .67 5.5. サーバメッセージ・フォーマットを発送してください。 . . . . . . . . . . . . . . . .67 5.5.1. 情報要求. . . . . . . . . . . . . . . .67 5.5.2を発送します。 要求. . . . . . . . . . . . . . . . . . . . . . .68 5.5.3を発送してください。 応答を発送してください。 . . . . . . . . . . . . . . . . . . . . . .71 5.5.4. 否定的承認. . . . . . . . . . . . . . . . .72 6。 世代を発送してください。 . . . . . . . . . . . . . . . . . . . . . . .73 6.1. 探すこと… .74
Steenstrup [Page 2] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[2ページ]RFC1479IDPRは1993年7月に議定書を作ります。
6.1.1. Implementation. . . . . . . . . . . . . . . . . . . . . . .75 6.2. Route Directionality. . . . . . . . . . . . . . . . . . . . .78 6.3. Route Database. . . . . . . . . . . . . . . . . . . . . . . .79 6.3.1. Cache Maintenance . . . . . . . . . . . . . . . . . . . . .80 7. Path Control Protocol and Data Message Forwarding Procedure . .80 7.1. An Example of Path Setup. . . . . . . . . . . . . . . . . . .81 7.2. Path Identifiers. . . . . . . . . . . . . . . . . . . . . . .84 7.3. Path Control Messages . . . . . . . . . . . . . . . . . . . .85 7.4. Setting Up and Tearing Down a Path. . . . . . . . . . . . . .87 7.4.1. Validating Path Identifiers . . . . . . . . . . . . . . . .89 7.4.2. Path Consistency with Configured Transit Policies . . . . .89 7.4.3. Path Consistency with Virtual Gateway Reachability. . . . .91 7.4.4. Obtaining Resources . . . . . . . . . . . . . . . . . . . .92 7.4.5. Target Response . . . . . . . . . . . . . . . . . . . . . .93 7.4.6. Originator Response . . . . . . . . . . . . . . . . . . . .93 7.4.7. Path Life . . . . . . . . . . . . . . . . . . . . . . . . 94 7.5. Path Failure and Recovery . . . . . . . . . . . . . . . . . 95 7.5.1. Handling Implicit Path Failures . . . . . . . . . . . . . 96 7.5.2. Local Path Repair . . . . . . . . . . . . . . . . . . . . 97 7.5.3. Repairing a Path. . . . . . . . . . . . . . . . . . . . . 98 7.6. Path Control Message Formats. . . . . . . . . . . . . . . . 100 7.6.1. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . . 101 7.6.2. ACCEPT. . . . . . . . . . . . . . . . . . . . . . . . . . 103 7.6.3. REFUSE. . . . . . . . . . . . . . . . . . . . . . . . . . 103 7.6.4. TEARDOWN. . . . . . . . . . . . . . . . . . . . . . . . . 104 7.6.5. ERROR . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.6.6. REPAIR. . . . . . . . . . . . . . . . . . . . . . . . . . 106 7.6.7. Negative Acknowledgements . . . . . . . . . . . . . . . . 106 8. Security Considerations . . . . . . . . . . . . . . . . . . . 106 9. Authors's Address . . . . . . . . . . . . . . . . . . . . . . 107 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.1.1. 実現。 . . . . . . . . . . . . . . . . . . . . . .75 6.2. 方向性を発送してください。 . . . . . . . . . . . . . . . . . . . .78 6.3. データベースを発送してください。 . . . . . . . . . . . . . . . . . . . . . . .79 6.3.1. 維持. . . . . . . . . . . . . . . . . . . . .80 7をキャッシュしてください。 経路制御プロトコルとデータメッセージ推進手順. .80 7.1。 経路セットアップに関する例。 . . . . . . . . . . . . . . . . . .81 7.2. 経路識別子。 . . . . . . . . . . . . . . . . . . . . . .84 7.3. 経路制御メッセージ. . . . . . . . . . . . . . . . . . . .85 7.4。 経路をセットアップして、取りこわします。 . . . . . . . . . . . . .87 7.4.1. 経路識別子. . . . . . . . . . . . . . . .89 7.4.2を有効にします。 構成された運送保険証券. . . . .89 7.4.3がある経路の一貫性。 仮想のゲートウェイの可到達性がある経路の一貫性。 . . . .91 7.4.4. リソース. . . . . . . . . . . . . . . . . . . .92 7.4.5を得ます。 応答. . . . . . . . . . . . . . . . . . . . . .93 7.4.6を狙ってください。 創始者応答. . . . . . . . . . . . . . . . . . . .93 7.4.7。 経路生活. . . . . . . . . . . . . . . . . . . . . . . . 94 7.5。 経路失敗と回復. . . . . . . . . . . . . . . . . 95 7.5.1。 暗黙の経路失敗. . . . . . . . . . . . . 96 7.5.2を扱います。 地方の経路修理. . . . . . . . . . . . . . . . . . . . 97 7.5.3。 経路を修理します。 . . . . . . . . . . . . . . . . . . . . 98 7.6. 経路制御メッセージ・フォーマット。 . . . . . . . . . . . . . . . 100 7.6.1. セットアップ. . . . . . . . . . . . . . . . . . . . . . . . . . 101 7.6.2。 受け入れてください。 . . . . . . . . . . . . . . . . . . . . . . . . . 103 7.6.3. 拒否してください。 . . . . . . . . . . . . . . . . . . . . . . . . . 103 7.6.4. 分解。 . . . . . . . . . . . . . . . . . . . . . . . . 104 7.6.5. 誤り. . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.6.6。 修理してください。 . . . . . . . . . . . . . . . . . . . . . . . . . 106 7.6.7. 否定的承認. . . . . . . . . . . . . . . . 106 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 106 9。 作者のsアドレス. . . . . . . . . . . . . . . . . . . . . . 107参照. . . . . . . . . . . . . . . . . . . . . . . . . . . 107
1. Introduction
1. 序論
In this document, we specify the protocols and procedures that compose Inter-Domain Policy Routing (IDPR). The objective of IDPR is to construct and maintain routes between source and destination administrative domains, that provide user traffic with the services requested within the constraints stipulated for the domains transited. IDPR supports link state routing information distribution and route generation in conjunction with source specified message forwarding. Refer to [5] for a detailed justification of our approach to inter-domain policy routing.
本書では、私たちはInter-ドメインPolicyルート設定(IDPR)を構成するプロトコルと手順を指定します。 IDPRの目的がソースと目的地の管理ドメインの間のルートを構成して、維持することであり、それは通過されたドメインに規定された規制の中で要求されたサービスをユーザ交通に提供します。 IDPRはソースの指定されたメッセージ推進に関連してリンク州のルーティング情報流通とルート世代を支持します。 相互ドメイン方針ルーティングへの私たちのアプローチの詳細な正当化のための[5]を参照してください。
1.1. Domain Elements
1.1. ドメイン要素
The IDPR architecture has been designed to accommodate an internetwork with tens of thousands of administrative domains
IDPR構造は、何万もの管理ドメインがあるインターネットワークを収容するように設計されています。
Steenstrup [Page 3] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[3ページ]RFC1479IDPRは1993年7月に議定書を作ります。
collectively containing hundreds of thousands of local networks. Inter-domain policy routes are constructed using information about the services offered by, and the connectivity between, administrative domains. The intra-domain details - gateways, networks, and links traversed - of an inter-domain policy route are the responsibility of intra-domain routing and are thus outside the scope of IDPR.
何十万もの企業内情報通信網をまとめて含みます。 相互ドメイン方針ルートが間に提供されたサービス、および接続性の情報を使用することで構成される、管理ドメイン。 その結果、IDPRの範囲の外に、相互ドメイン方針ルートのイントラドメイン細部(ゲートウェイ、ネットワーク、および横断されたリンク)は、イントラドメインルーティングの責任であり、あります。
An "administrative domain" (AD) is a collection of contiguous hosts, gateways, networks, and links managed by a single administrative authority. The domain administrator defines service restrictions for transit traffic and service requirements for locally-generated traffic, and selects the addressing schemes and routing procedures that apply within the domain. Within the Internet, each domain has a unique numeric identifier assigned by the Internet Assigned Numbers Authority (IANA).
「管理ドメイン」(AD)はただ一つの職務権限によって経営された隣接のホスト、ゲートウェイ、ネットワーク、およびリンクの収集です。 ドメイン管理者は、トランジット交通のためのサービス制限と局所的に発生している交通のためのサービス要件を定義して、ドメインの中で適用されるアドレシング計画とルーティング手順を選択します。 インターネットの中では、各ドメインで、インターネットAssigned民数記Authority(IANA)はユニークな数値識別子を割り当てます。
"Virtual gateways" (VGs) are the only IDPR-recognized connecting points between adjacent domains. Each virtual gateway is a collection of directly-connected "policy gateways" (see below) in two adjoining domains, whose existence has been sanctioned by the administrators of both domains. The domain administrators may agree to establish more than one virtual gateway between the two domains. For each such virtual gateway, the two administrators together assign a local numeric identifier, unique within the set of virtual gateways connecting the two domains. To produce a virtual gateway identifier unique within its domain, a domain administrator concatenates the mutually assigned local virtual gateway identifier together with the adjacent domain's identifier.
「仮想のゲートウェイ」(VGs)は隣接しているドメインの間の唯一のIDPRによって認識された接続ポイントです。 それぞれの仮想のゲートウェイは存在が両方のドメインの管理者によって認可された2つの隣接しているドメインでの直接接続された「方針ゲートウェイ」(以下を見る)の収集です。 ドメイン管理者は、2つのドメインの間の仮想の1つ以上の門以上を設立するのに同意するかもしれません。 そのようなそれぞれの仮想のゲートウェイに関しては、一緒に2人の管理者がローカルの数値識別子を割り当てます、2つのドメインをつなげる仮想のゲートウェイのセットの中でユニークです。 ドメインの中でユニークな仮想のゲートウェイ識別子を作り出すために、ドメイン管理者は隣接しているドメインの識別子と共に互いに割り当てられたローカルの仮想のゲートウェイ識別子を連結します。
Policy gateways (PGs) are the physical gateways within a virtual gateway. Each policy gateway enforces service restrictions on IDPR transit traffic, as stipulated by the domain administrator, and forwards the traffic accordingly. Within a domain, two policy gateways are "neighbors" if they are in different virtual gateways. A single policy gateway may belong to multiple virtual gateways. Within a virtual gateway, two policy gateways are "peers" if they are in the same domain and are "adjacent" if they are in different domains. Adjacent policy gateways are "directly connected" if the only Internet-addressable entities attached to the connecting medium are policy gateways in the virtual gateways. Note that this definition implies that not only point-to-point links but also networks may serve as direct connections between adjacent policy gateways. The domain administrator assigns to each of its policy gateways a numeric identifier, unique within that domain.
方針ゲートウェイ(PGs)は仮想のゲートウェイの中の物理的なゲートウェイです。 それぞれの方針ゲートウェイは、ドメイン管理者によって規定されているようにサービス制限にIDPRトランジット交通に押しつけて、それに従って、交通を送ります。 ドメインの中では、彼らが異なった仮想のゲートウェイにいるなら、2方針門は「隣人」です。 1方針門は複数の仮想のゲートウェイに属すかもしれません。 仮想のゲートウェイの中では、異なったドメインにいるなら、彼らが同じドメインにいて、「隣接している」なら、2方針門は「同輩」です。 隣接している方針ゲートウェイは接続媒体に愛着している唯一のインターネットアドレス可能な実体が仮想のゲートウェイの方針ゲートウェイであるなら「直接接続されます」。 この定義が、ポイントツーポイント接続だけではなく、ネットワークも隣接している方針ゲートウェイの間のダイレクト接続として機能するかもしれないのを含意することに注意してください。 ドメイン管理者はそのドメインの中でユニークな数値識別子をそれぞれの方針ゲートウェイに割り当てます。
A "domain component" is a subset of a domain's entities such that all entities within the subset are mutually reachable via intra-domain routes, but no entities outside the subset are reachable via intra-
部分集合の中のすべての実体が「ドメインコンポーネント」がドメインの実体の部分集合であるので、イントラドメインルートで互いに届きますが、部分集合の外におけるどんな実体もイントラで届いていません。
Steenstrup [Page 4] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[4ページ]RFC1479IDPRは1993年7月に議定書を作ります。
domain routes from entities within the subset. Normally, a domain consists of a single component, namely itself; however, when partitioned, a domain consists of multiple components. Each domain component has an identifier, unique within the Internet, composed of the domain identifier together with the identifier of the lowest- numbered operational policy gateway within the component. All operational policy gateways within a domain component can discover mutual reachability through intra-domain routing information. Hence, all such policy gateways can consistently determine, without explicit negotiation, which of them has the lowest number.
部分集合の中の実体からのドメインルート。 通常、ドメインはすなわち、ただ一つのコンポーネント、それ自体から成ります。 しかしながら、仕切られると、ドメインは複数のコンポーネントから成ります。 それぞれのドメインコンポーネントには、識別子があります、インターネットの中でユニークです、最も低い番号付の運用政策ゲートウェイに関する識別子と共にコンポーネントの中にドメイン識別子を落ち着かせます。 ドメインコンポーネントの中のすべての運用政策ゲートウェイがイントラドメインルーティング情報を通して互いの可到達性を発見できます。 したがって、そのようなすべての方針ゲートウェイが、明白な交渉なしでそれらのどれに最も下位の数があるかを一貫して決定できます。
1.2. Policy
1.2. 方針
With IDPR, each domain administrator sets "transit policies" that dictate how and by whom the resources in its domain should be used. Transit policies are usually public, and they specify offered services comprising:
IDPRと共に、それぞれのドメイン管理者はその方法を書き取って、ドメインのリソースが使用されるべきである「運送保険証券」を設定します。 通常、運送保険証券は公共です、そして、それらは以下を包括する提供サービスを指定します。
- Access restrictions: e.g., applied to traffic to or from certain
domains or classes of users.
- 制限にアクセスしてください: 例えば、ユーザかある一定のドメインかクラスのユーザからの交通に適用されています。
- Quality: e.g., delay, throughput, or error characteristics.
- 品質: 例えば、遅れ、スループット、または誤りの特性。
- Monetary cost: e.g., charge per byte, message, or unit time.
- 貨幣原価: 例えば、1バイトあたりの料金、メッセージ、またはユニット時間。
Each domain administrator also sets "source policies" for traffic originating in its domain. Source policies are usually private, and they specify requested services comprising:
また、それぞれのドメイン管理者はドメインで起こる交通のための「ソース方針」を設定します。 通常、ソース方針は個人的です、そして、それらは以下を包括する要求されたサービスを指定します。
- Access restrictions: e.g., domains to favor or avoid in routes.
- 制限にアクセスしてください: 例えばルートで支持するか、または避けるドメイン。
- Quality: e.g., acceptable delay, throughput, and reliability.
- 品質: 例えば、許容できる遅れ、スループット、および信頼性。
- Monetary cost: e.g., acceptable session cost.
- 貨幣原価: 例えば、許容できるセッション費用。
1.3. IDPR Functions
1.3. IDPR機能
IDPR comprises the following functions:
IDPRは以下の機能を包括します:
- Collecting and distributing routing information including domain
transit policies and inter-domain connectivity.
- ドメイン運送保険証券と相互ドメインの接続性を含むルーティング情報を、集めて、分配します。
- Generating and selecting policy routes based on the routing
information distributed and on the source policies configured or
requested.
- 情報が分配して、構成したか、またはソース方針要求したルーティングに基づく方針ルートを、発生して、選択します。
- Setting up paths across the Internet using the policy routes
generated.
- インターネットの向こう側にルートが発生させた方針を使用することで経路をセットアップします。
Steenstrup [Page 5] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[5ページ]RFC1479IDPRは1993年7月に議定書を作ります。
- Forwarding messages across and between domains along the
established paths.
- ドメインの向こう側に確立した経路に沿ったドメインの間にメッセージを転送します。
- Maintaining databases of routing information, inter-domain policy
routes, forwarding information, and configuration information.
- ルーティング情報に関するデータベース、相互ドメイン方針ルート、推進情報、および設定情報を保守します。
1.3.1. IDPR Entities
1.3.1. IDPR実体
Several different entities are responsible for performing the IDPR functions.
いくつかの異なった実体がIDPR機能を実行するのに原因となります。
Policy gateways, the only IDPR-recognized connecting points between adjacent domains, collect and distribute routing information, participate in path setup, forward data messages along established paths, and maintain forwarding information databases.
方針ゲートウェイ(隣接しているドメインの間の唯一のIDPRによって認識された接続ポイント)は、ルーティング情報を集めて、分配して、経路セットアップに参加して、確立した経路に沿ってデータメッセージを転送して、推進情報データベースを維持します。
"Path agents", resident within policy gateways and within "route servers" (see below), act on behalf of hosts to select policy routes, to set up and manage paths, and to maintain forwarding information databases. Any Internet host can reap the benefits of IDPR, as long as there exists a path agent configured to act on its behalf and a means by which the host's messages can reach the path agent. Specifically, a path agent in one domain may be configured to act on behalf of hosts in another domain. In this case, the path agent's domain is an IDPR "proxy" for the hosts' domain.
方針ゲートウェイと「ルートサーバ」(以下を見る)の中で居住している「経路エージェント」は、方針ルートを選択して、経路をセットアップして、管理して、推進情報データベースを維持するためにホストを代表して行動します。 どんなインターネット・ホストもIDPRの利益を獲得できます、利益に影響するように構成された経路エージェントとホストのメッセージが経路エージェントに届くことができる手段が存在している限り。 明確に、1つのドメインの経路エージェントは、別のドメインのホストを代表して行動するために構成されるかもしれません。 この場合、経路エージェントのドメインはホストのドメインへのIDPR「プロキシ」です。
Route servers maintain both the routing information database and the route database, and they generate policy routes using the routing information collected and the source policies requested by the path agents. A route server may reside within a policy gateway, or it may exist as an autonomous entity. Separating the route server functions from the policy gateways frees the policy gateways from both the memory intensive task of database (routing information and route) maintenance and the computationally intensive task of route generation. Route servers, like policy gateways, each have a unique numeric identifier within their domain, assigned by the domain administrator.
ルートサーバは、両方がルーティング情報データベースとルートデータベースであることを支持します、そして、それらは情報が集めて、ソース方針が経路エージェントから要求したルーティングを使用することで方針ルートを生成します。 ルートサーバが方針ゲートウェイの中にあるかもしれませんか、またはそれは自治の実体として存在するかもしれません。 方針ゲートウェイとルートサーバ機能を切り離すと、方針ゲートウェイはデータベース(ルーティング情報とルート)メインテナンスのメモリの徹底的なタスクとルート世代の計算上徹底的なタスクの両方から解放されます。 方針ゲートウェイのように、ルートサーバはドメイン管理者によって割り当てられたそれらのドメインの中にそれぞれユニークな数値識別子を持っています。
Given the size of the current Internet, each policy gateway can perform the route server functions, in addition to its message forwarding functions, with little or no degradation in message forwarding performance. Aggregating the routing functions into policy gateways simplifies implementation; one need only install IDPR protocols in policy gateways. Moreover, it simplifies communication between routing functions, as all functions reside within each policy gateway. As the Internet grows, the memory and processing required to perform the route server functions may become a burden for the policy gateways. When this happens, each domain administrator should
現在のインターネットのサイズを考えて、それぞれの方針ゲートウェイはルートサーバ機能を実行できます、メッセージ推進機能に加えて、ほとんどメッセージ推進性能におけるどんな退行でも、そうしません。 方針ゲートウェイへの経路選択機能に集めるのは実装を簡素化します。 1つはIDPRプロトコルを方針ゲートウェイにインストールするだけでよいです。 そのうえ、すべての機能がそれぞれの方針ゲートウェイの中にあるとき、それは経路選択機能のコミュニケーションを簡素化します。 インターネットが発展するのに従って、ルートサーバ機能を実行するのに必要であるメモリと処理は方針ゲートウェイへの負担になるかもしれません。 これが起こると、それぞれのドメイン管理者は起こるべきです。
Steenstrup [Page 6] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[6ページ]RFC1479IDPRは1993年7月に議定書を作ります。
separate the route server functions from the policy gateways in its domain.
ドメインの方針ゲートウェイとルートサーバ機能を切り離してください。
"Mapping servers" maintain the database of mappings that resolve Internet names and addresses to domain identifiers. Each host is contained within a domain and is associated with a proxy domain which may be identical with the host's domain. The mapping server function will be integrated into the existing DNS name service (see [6]) and will provide mappings between a host and its local and proxy domains.
「マッピングサーバ」はインターネット名とアドレスをドメイン識別子に決議するマッピングに関するデータベースを維持します。 それぞれのホストは、ドメインの中に保管されていて、ホストのドメインと同じであるかもしれないプロキシドメインに関連しています。 マッピングサーバ機能はDNSがサービスと命名する存在と統合されるでしょう。([6])を見て、ホストとその地方とプロキシドメインの間にマッピングを提供するでしょう。
"Configuration servers" maintain the databases of configured information that apply to IDPR entities within their domains. Configuration information for a given domain includes transit policies (i.e., service offerings and restrictions), source policies (i.e., service requirements), and mappings between local IDPR entities and their names and addresses. The configuration server function will be integrated into a domain's existing network management system (see [7]-[8]).
「構成サーバ」はそれらのドメインの中でIDPR実体に適用される構成された情報に関するデータベースを維持します。 与えられたドメインのための設定情報はそれらの運送保険証券(すなわち、サービス提供と制限)、ソース方針(すなわち、サービス要件)、地方のIDPR実体の間のマッピング、名前、およびアドレスを含んでいます。 構成サーバ機能はドメインの存在ネットワーク管理システムと統合されるでしょう。([7]--[8])を見てください。
1.4. Policy Semantics
1.4. 方針意味論
The source and transit policies supported by IDPR are intended to accommodate a wide range of services available throughout the Internet. We describe the semantics of these policies, concentrating on the access restriction aspects. To express these policies in this document, we have chosen to use a syntactic variant of Clark's policy term notation [1]. However, we provide a more succinct syntax (see [7]) for actually configuring source and transit policies.
IDPRによってサポートされたソースと運送保険証券がインターネット中で利用可能なさまざまなサービスを収容することを意図します。 アクセス制限局面に集中して、私たちはこれらの方針の意味論について説明します。 本書ではこれらの方針を言い表すために、私たちは、クラークの方針用語記法[1]の構文の異形を使用するのを選びました。 しかしながら、私たちは、より簡潔な構文を提供します。(実際にソースと運送保険証券を構成するための[7])を見てください。
1.4.1. Source Policies
1.4.1. ソース方針
Each source policy takes the form of a collection of sets as follows:
それぞれのソース方針は以下のセットの収集の形を取ります:
Applicable Sources and Destinations:
{((H(1,1),s(1,1)),...,(H(1,f1),s(1,f1))),...,((H(n,1),s(n,1)),...,
(H(n,fn),s(n,fn)))}: The set of groups of source/destination
traffic flows to which the source policy applies. Each traffic
flow group ((H(i,1),s(i,1)),...,(H(i,fi),s(i,fi))) contains a set
of source hosts and corresponding destination hosts. Here, H(i,j)
represents a host, and s(i,j), an element of {SOURCE,
DESTINATION}, represents an indicator of whether H(i,j) is to be
considered as a source or as a destination.
適切なソースと目的地: (H(1、1)、s(1、1、)…(H(1、f1)、s(1、f1)))、…(H(n、1)、s(n、1)、…(H(fnのn)、s(fnのn)))、: ソース方針が適用されるソース/目的地トラフィックのグループのセットは流れます。 … それぞれのトラフィック流動は(H(i、1)、s(i、1))を分類して、(H(i、fi)、s(i、fi))は1セットの送信元ホストと対応するあて先ホストを含みます。 ここで、H(i、j)はホストの代理をします、そして、s(i、j)(SOURCE、DESTINATIONの要素)はH(i、j)がソースか目的地と考えられることになっているかどうかに関するインディケータを表します。
Domain Preferences: {(AD(1),x(1)),...,(AD(m),x(m))}: The set of
transit domains that the traffic flows should favor, avoid, or
exclude. Here, AD(i) represents a domain, and x(i), an element of
{FAVOR, AVOID, EXCLUDE}, represents an indicator of whether routes
including AD(i) are to be favored, avoided if possible, or
ドメイン好み: (AD(1)、x(1))、…、(AD(m)、x(m))、: 交通の流れが支持するべきであるか、避けるべきであるか、または除くべきであるトランジットドメインのセット。 またはここに、AD(i)がドメインを表して、x(i)(FAVOR、AVOID、EXCLUDEの要素)ができれば、避けられた支持されるかどうかに関するAD(i)を含むルートがことであるインディケータを表す。
Steenstrup [Page 7] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[7ページ]RFC1479IDPRは1993年7月に議定書を作ります。
unconditionally excluded.
無条件に除かれます。
UCI: The source user class for the traffic flows listed.
UCI: 交通の流れのためのソースユーザ・クラスは記載しました。
RequestedServices: The set of requested services not related to
access restrictions, i.e., service quality and monetary cost.
RequestedServices: 要求されたサービスのセットはすなわち、アクセス制限、サービスに上質の、そして、通貨の費用を関係づけませんでした。
When selecting a route for a traffic flow from a source host H(i,j) to a destination host H(i,k), where 1 < or = i < or = n and 1 < or = j, k < or = fi, the path agent (see section 1.3.1) must honor the source policy such that:
送信元ホストH(i、j)からあて先ホストH(i、k)までの交通の流れのためのルート(1<か=i<か=nと1<か=jかk<か=fi、経路エージェント(セクション1.3.1を見る)がソース方針を光栄に思わなければならない)を選択する、以下のことのようなもの
- For each domain, AD(p), contained in the route, AD(p) is not equal
to any AD(k), such that 1 < or = k < or = m and x(k) = EXCLUDE.
- 各ドメイン、ルートに含まれたAD(p)に関しては、AD(p)はどんなAD(k)とも等しくはありません、1<か=k<か=mとx(k)がEXCLUDEと等しいように。
- The route provides the services listed in the set Requested
Services.
- ルートはセットRequested Servicesで記載されたサービスを提供します。
1.4.2. Transit Policies
1.4.2. 運送保険証券
Each transit policy takes the form of a collection of sets as follows:
各運送保険証券は以下のセットの収集の形を取ります:
Source/Destination Access Restrictions:
{((H(1,1),AD(1,1),s(1,1)),...,(H(1,f1),AD(1,f1),s(1,f1))),...,
((H(n,1),AD(n,1),s(n,1)),...,(H(n,fn),AD(n,fn),s(n,fn)))}: The set
of groups of source and destination hosts and domains to which the
transit policy applies. Each domain group
((H(i,1),AD(i,1),s(i,1)),...,(H(i,fi),AD(i,fi),s(i,fi))) contains
a set of source and destination hosts and domains such that this
transit domain will carry traffic from each source listed to each
destination listed. Here, H(i,j) represents a set of hosts,
AD(i,j) represents a domain containing H(i,j), and s(i,j), a
subset of {SOURCE, DESTINATION}, represents an indicator of
whether (H(i,j),AD(i,j)) is to be considered as a set of sources,
destinations, or both.
ソース/目的地アクセス制限: 西暦..西暦..西暦..西暦 運送保険証券が適用されるソース、あて先ホスト、およびドメインのグループのセット。 … それぞれのドメイングループ(H(i、1)、AD(i、1)、s(i、1))、(H(i、fi)、AD(i、fi)、s(i、fi))はこのトランジットドメインが記載された各目的地に記載された各ソースからトラフィックを運ぶように、1セットのソース、あて先ホスト、およびドメインを含んでいます。 ここで、H(i、j)は1セットのホストの代理をします、そして、AD(i、j)はH(i、j)を含むドメインを表します、そして、s(i、j)(SOURCE、DESTINATIONの部分集合)は(H(i、j)、AD(i、j))がソース、目的地、または両方のセットであるとみなされることになっているかどうかに関するインディケータを表します。
Temporal Access Restrictions: The set of time intervals during which
the transit policy applies.
時のアクセス制限: 運送保険証券が適用される時間間隔のセット。
User Class Access Restrictions: The set of user classes to which the
transit policy applies.
ユーザ・クラスは制限にアクセスします: 運送保険証券が適用されるユーザのセットは属します。
Offered Services: The set of offered services not related to access
restrictions, i.e., service quality and monetary cost.
提供サービス: 提供サービスのセットはすなわち、アクセス制限、サービスに上質の、そして、通貨の費用を関係づけませんでした。
Steenstrup [Page 8] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[8ページ]RFC1479IDPRは1993年7月に議定書を作ります。
Virtual Gateway Access Restrictions:
{((VG(1,1),e(1,1)),...,(VG(1,g1),e(1,g1))),...,((VG(m,1),e(m,1)),
gateways to which the transit policy applies. Each virtual
gateway group ((VG(i,1),e(i,1)),...,(VG(i,gi),e(i,gi))) contains a
set of domain entry and exit points such that each entry virtual
gateway can reach (barring an intra-domain routing failure) each
exit virtual gateway via an intra-domain route supporting the
transit policy. Here, VG(i,j) represents a virtual gateway, and
e(i,j), a subset of {ENTRY, EXIT}, represents an indicator of
whether VG(i,j) is to be considered as a domain entry point, exit
point, or both.
仮想のゲートウェイアクセス制限: ゲートウェイ..運送保険証券..適用..仮想..ゲートウェイ..グループ..兵士..兵士..含む..セット..ドメイン..エントリー..エキジットポイント..エントリー..仮想..ゲートウェイ..達する..イントラ..ドメイン..ルーティング..失敗..出口..仮想..ゲートウェイ..イントラ..ドメイン..ルート..サポートする..運送保険証券; ここに、VG(i、j)は仮想のゲートウェイを表します、そして、e(i、j)(ENTRY、EXITの部分集合)はVG(i、j)がドメインエントリー・ポイントであるとみなされることになっているかどうかに関するインディケータ、エキジットポイント、または両方を表します。
The domain advertising such a transit policy will carry traffic from any host in the set H(i,j) in AD(i,j) to any host in the set H(i,k) in AD(i,k), where 1 < or = i < or = n and 1 < or = j, k < or = fi, provided that:
そのような運送保険証券の広告を出すドメインがAD(i、k)のセットH(i、k)でトラフィックをAD(i、j)のセットH(i、j)のどんなホストからどんなホストまでも運ぶ、:(そこでは、1<か=i<か=nと1<か、=jか、k<か=がfiされます)。
- SOURCE is an element of s(i,j).
- SOURCEはs(i、j)の要素です。
- DESTINATION is an element of s(i,k).
- DESTINATIONはs(i、k)の要素です。
- Traffic from H(i,j) enters the domain during one of the intervals
in the set Temporal Access Restrictions.
- 間隔の1つの間、H(i、j)からのトラフィックはセットTemporal Access Restrictionsでドメインに入ります。
- Traffic from H(i,j) carries one of the user class identifiers in
the set User Class Access Restrictions.
- H(i、j)からのトラフィックはセットUser Class Access Restrictionsのユーザ・クラス識別子の1つを運びます。
- Traffic from H(i,j) enters via any VG(u,v) such that ENTRY is an
element of e(u,v), where 1 < or = u < or = m and 1 < or = v < or =
gu.
- H(i、j)からのトラフィックに、ENTRYがどこe(u、v)の要素か、1<か=u<であるか、そして、=mと1<か=対<か=がguであるようにどんなVG(u、v)を通しても入ります。
- Traffic to H(i,k) leaves via any VG(u,w) such that EXIT is an
element of e(u,w), where 1 < or = w < or = gu.
- H(i、k)へのトラフィックがどんなVG(u、w)を通ってもいなくなるので、EXITはどこe(u、w)の要素か、1<か=w<であるか、そして、guと等しいです。
1.5. IDPR Message Encapsulation
1.5. IDPRメッセージカプセル化
There are two kinds of IDPR messages:
2種類のIDPRメッセージがあります:
- "Data messages" containing user data generated by hosts.
- ホストによって生成された利用者データを含む「データメッセージ。」
- "Control messages" containing IDPR protocol-related control
information generated by policy gateways and route servers.
- IDPRのプロトコル関連の制御情報を含む「コントロールメッセージ」は、ゲートウェイとルートがサーバであると方針で生成しました。
Within an internetwork, only policy gateways and route servers are able to generate, recognize, and process IDPR messages. The existence of IDPR is invisible to all other gateways and hosts, including mapping servers and configuration servers. Mapping servers and configuration servers perform necessary but ancillary functions
インターネットワークの中では、方針ゲートウェイとルートサーバだけが、IDPRメッセージを生成して、認識して、処理できます。 サーバと構成サーバを写像するのを含む他のすべてのゲートウェイとホストにとって、IDPRの存在は目に見えません。 マッピングサーバと構成サーバは必要な、しかし、付属の機能を実行します。
Steenstrup [Page 9] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[9ページ]RFC1479IDPRは1993年7月に議定書を作ります。
for IDPR, and thus they are not required to handle IDPR messages.
IDPR、およびその結果、それらはそうです。IDPRメッセージを扱うのが必要ではありません。
An IDPR entity places IDPR-specific information in each IDPR control message it originates; this information is significant only to recipient IDPR entities. Using "encapsulation" across each domain, an IDPR message tunnels from source to destination across an internetwork through domains that may employ disparate intra-domain addressing schemes and routing procedures.
IDPR実体はそれが溯源するそれぞれのIDPRコントロールメッセージのIDPR-特殊情報を置きます。 この情報は受取人IDPR実体だけに重要です。 各ドメインの向こう側に「カプセル化」を使用して、IDPRメッセージは異種のイントラドメインアドレシング体系とルーティング手順を使うかもしれないドメインを通してインターネットワークの向こう側にソースから目的地までトンネルを堀ります。
As an alternative to encapsulation, we had considered embedding IDPR in IP, as a set of IP options. However, this approach has the following disadvantages:
カプセル化に代わる手段として、私たちは、1セットのIPオプションとしてIDPRをIPに埋め込むと考えました。 しかしながら、このアプローチには、以下の損失があります:
- Only domains that support IP would be able to participate in IDPR;
domains that do not support IP would be excluded.
- IPをサポートするドメインだけがIDPRに参加できるでしょう。 IPをサポートしないドメインが除かれるでしょう。
- Each gateway, policy or other, in a participating domain would at
least have to recognize the IDPR option, even if it did not execute
the IDPR protocols. However, most commercial routers are not
optimized for IP options processing, and so IDPR message handling
might require significant processing at each gateway.
- 各ゲートウェイ、何らかの参加ドメインの方針はIDPRオプションを少なくとも認識しなければならないでしょう、IDPRプロトコルを実行しなかったとしても。 しかしながら、ほとんどの商業ルータがIPオプション処理のために最適化されないので、IDPRメッセージハンドリングは各ゲートウェイで重要な処理を必要とするかもしれません。
- For some IDPR protocols, in particular path control, the size
restrictions on IP options would preclude inclusion of all of the
necessary protocol-related information.
- いくつかのIDPRプロトコルのために、特定の経路制御では、IPオプションのサイズ制限は必要なプロトコル関連の情報のすべての包含を排除するでしょう。
For these reasons, we decided against the IP option approach and in favor of encapsulation.
これらの理由で、私たちはIPオプションアプローチに対してカプセル化を支持して決めました。
An IDPR message travels from source to destination between consecutive policy gateways. Each policy gateway encapsulates the IDPR message with information, for example an IP header, that will enable the message to reach the next policy gateway. Note that the encapsulating header and the IDPR-specific information may increase the message size beyond the MTU of the given domain. However, message fragmentation and reassembly is the responsibility of the protocol, for example IP, that encapsulates IDPR messages for transport between successive policy gateways; it is not currently the responsibility of IDPR itself.
IDPRメッセージは連続した方針ゲートウェイの間をソースから目的地まで移動します。 それぞれの方針ゲートウェイは情報、例えば、隣の方針ゲートウェイに達するメッセージを可能にするIPヘッダーと共にIDPRメッセージをカプセル化します。 要約のヘッダーとIDPR-特殊情報が与えられたドメインのMTUを超えてメッセージサイズを増強するかもしれないことに注意してください。 しかしながら、メッセージの断片化と再アセンブリはプロトコル、例えば、連続した方針ゲートウェイの間の輸送へのメッセージをIDPRにカプセル化するIPの責任です。 現在、それはIDPR自身の責任ではありません。
A policy gateway, when forwarding an IDPR message to a peer or a neighbor policy gateway, encapsulates the message in accordance with the addressing scheme and routing procedure of the given domain and indicates in the protocol field of the encapsulating header that the message is indeed an IDPR message. Intermediate gateways between the two policy gateways forward the IDPR message as they would any other message, using the information in the encapsulating header. Only the recipient policy gateway interprets the protocol field, strips off
方針ゲートウェイは、同輩か隣人方針ゲートウェイにIDPRメッセージを転送するとき、与えられたドメインのアドレシング体系とルーティング手順によってメッセージをカプセル化して、要約のヘッダーのプロトコル分野で本当に、メッセージがIDPRメッセージであることを示します。 要約のヘッダーで情報を使用するいかなる他のメッセージも転送するように2方針門の間の中間ゲートウェイはIDPRメッセージを転送します。 受取人方針ゲートウェイだけが、プロトコル分野を解釈して、全部はぎ取られます。
Steenstrup [Page 10] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[10ページ]RFC1479IDPRは1993年7月に議定書を作ります。
the encapsulating header, and processes the IDPR message.
IDPRが通信させる要約のヘッダー、およびプロセス。
A policy gateway, when forwarding an IDPR message to a directly- connected adjacent policy gateway, encapsulates the message in accordance with the addressing scheme of the entities within the virtual gateway and indicates in the protocol field of the encapsulating header that the message is indeed an IDPR message. The recipient policy gateway strips off the encapsulating header and processes the IDPR message. We recommend that the recipient policy gateway perform the following validation check of the encapsulating header, prior to stripping it off. Specifically, the recipient policy gateway should verify that the source address and the destination address in the encapsulating header match the adjacent policy gateway's address and its own address, respectively. Moreover, the recipient policy gateway should verify that the message arrived on the interface designated for the direct connection to the adjacent policy gateway. These checks help to ensure that IDPR traffic that crosses domain boundaries does so only over direct connections between adjacent policy gateways.
方針ゲートウェイは、直接接続された隣接している方針ゲートウェイにIDPRメッセージを転送するとき、実体のアドレシング体系通りに仮想のゲートウェイの中でメッセージをカプセル化して、要約のヘッダーのプロトコル分野で本当に、メッセージがIDPRメッセージであることを示します。 受取人方針ゲートウェイは要約のヘッダーとプロセスでIDPRメッセージを剥取ります。 私たちは、受取人方針ゲートウェイが要約のヘッダーの以下の合法化チェックを実行することを勧めます、それを全部はぎ取る前に。 明確に、受取人方針ゲートウェイは、ソースアドレスと目的地が、要約のヘッダーマッチで隣接している方針がゲートウェイのアドレスとそれ自身のアドレスであるとそれぞれ扱うことを確かめるはずです。 そのうえ、受取人方針ゲートウェイは、メッセージがダイレクト接続のために隣接している方針ゲートウェイに指定されたインタフェースで到着したことを確かめるはずです。 これらのチェックは、ドメイン境界に交差するIDPRトラフィックがそう隣接している方針ゲートウェイの間のダイレクト接続だけの上にするのを保証するのを助けます。
Policy gateways forward IDPR data messages according to a forwarding information database which maps "path identifiers", carried in the data messages, into next policy gateways. Policy gateways forward IDPR control messages according to next policy gateways selected by the particular IDPR control protocols associated with the messages. Distinguishing IDPR data messages and IDPR control messages at the encapsulating protocol level, instead of at the IDPR protocol level, eliminates an extra level of dispatching and hence makes IDPR message forwarding more efficient. When encapsulated within IP messages, IDPR data messages and IDPR control messages carry the IP protocol numbers 35 and 38, respectively.
データメッセージで運ばれた「経路識別子」を隣の方針ゲートウェイに写像する推進情報データベースに応じて、方針ゲートウェイはデータメッセージをIDPRに転送します。 メッセージに関連している特定のIDPR制御プロトコルによって選択された隣の方針ゲートウェイに応じて、方針ゲートウェイはコントロールメッセージをIDPRに転送します。 要約のプロトコルレベルIDPRプロトコルレベルの代わりにIDPRデータメッセージとIDPRコントロールメッセージを区別するのに、付加的なレベルの急ぎを排除して、したがって、IDPRメッセージ推進は、より効率的になります。 IPメッセージの中でカプセル化されると、IDPRデータメッセージとIDPRコントロールメッセージはそれぞれIPプロトコル番号35と38を運びます。
1.5.1. IDPR Data Message Format
1.5.1. IDPRデータメッセージ・フォーマット
The path agents at a source domain determine which data messages generated by local hosts are to be handled by IDPR. To each data message selected for IDPR handling, a source path agent prepends the following header:
IDPRによって扱われるように、ソースドメインの経路エージェントは、ローカル・ホストによって生成されたデータメッセージがどれであるかを決心しています。 各データに、メッセージはIDPR取り扱い、ソースの経路エージェントprependsのために以下のヘッダーを選びました:
Steenstrup [Page 11] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[11ページ]RFC1479IDPRは1993年7月に議定書を作ります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VERSION | PROTO | LENGTH |
+---------------+---------------+-------------------------------+
| PATH ID |
| |
+---------------------------------------------------------------+
| TIMESTAMP |
+---------------------------------------------------------------+
| INT/AUTH |
| |
+---------------------------------------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| プロト| 長さ| +---------------+---------------+-------------------------------+ | 経路ID| | | +---------------------------------------------------------------+ | タイムスタンプ| +---------------------------------------------------------------+ | INT/AUTH| | | +---------------------------------------------------------------+
VERSION (8 bits) Version number for IDPR data messages, currently equal to 1.
現在1と等しいIDPRデータメッセージのバージョン(8ビット)バージョン番号。
PROTO (8 bits) Numeric identifier for the protocol with which to process the contents of the IDPR data message. Only the path agent at the destination interprets and acts upon the contents of the PROTO field.
IDPRデータメッセージのコンテンツを処理するプロトコルのためのプロト(8ビット)の数値識別子。 目的地の経路エージェントだけが、プロト分野のコンテンツを解釈して、作用します。
LENGTH (16 bits) Length of the entire IDPR data message in bytes.
バイトで表現される全体のIDPRデータメッセージのLENGTH(16ビット)の長さ。
PATH ID (64 bits) Path identifier assigned by the source's path agent and consisting of the numeric identifier for the path agent's domain (16 bits), the numeric identifier for the path agent's policy gateway (16 bits), and the path agent's local path identifier (32 bits) (see section 7.2).
PATH ID(64ビット)経路識別子は、経路エージェントのドメインのための数値識別子(16ビット)、経路エージェントの方針ゲートウェイのための数値識別子(16ビット)、および経路エージェントのローカルの経路識別子からソースの経路エージェントで割り当てて、成りました(32ビット)(セクション7.2を見てください)。
TIMESTAMP (32 bits) Number of seconds elapsed since 1 January 1970 0:00 GMT.
1970年1月1日のグリニッジ標準時0時0分以来TIMESTAMP(32ビット)秒数は経過しました。
INT/AUTH (variable) Computed integrity/authentication value, dependent on the type of integrity/authentication requested during path setup.
保全/認証のタイプの上の扶養家族は、経路セットアップの間、INT/AUTH(可変)が保全/認証値を計算したよう要求しました。
We describe the IDPR control message header in section 2.4.
私たちはセクション2.4でIDPRコントロールメッセージヘッダーについて説明します。
1.6. Security
1.6. セキュリティ
IDPR contains mechanisms for verifying message integrity and source authenticity and for protecting against certain types of denial of service attacks. It is particularly important to keep IDPR control messages intact, because they carry control information critical to the construction and use of viable policy routes between domains.
IDPRはメッセージの保全とソースの信憑性について確かめて、あるタイプのサービス不能攻撃から守るためのメカニズムを含んでいます。 IDPRコントロールメッセージを完全に保つのは特に重要です、ドメインの間の実行可能な方針ルートの工事と使用に重要な制御情報を運ぶので。
All IDPR messages carry a single piece of information, referred to as
IDPRメッセージが示された1片の情報を運ぶすべて
Steenstrup [Page 12] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[12ページ]RFC1479IDPRは1993年7月に議定書を作ります。
the "integrity/authentication value", which may be used not only to detect message corruption but also to verify the authenticity of the message source. In the Internet, the IANA will sanction the set of valid algorithms which may be used to compute the integrity/authentication values. This set may include algorithms that perform only message integrity checks such as n-bit cyclic redundancy checksums (CRCs), as well as algorithms that perform both message integrity and source authentication checks such as signed hash functions of message contents.
単にメッセージ不正を検出するのではなく、メッセージ源の信憑性について確かめもするのに使用されるかもしれない「保全/認証値。」 インターネットでは、IANAは保全/認証値を計算するのに使用されるかもしれない有効なアルゴリズムのセットを認可するでしょう。 このセットはn-ビットの周期的な冗長チェックサム(CRCs)などのメッセージの保全チェックだけを実行するアルゴリズムを含むかもしれません、メッセージ内容のハッシュ関数であると署名されるようにメッセージの保全とソース認証チェックの両方を実行するアルゴリズムと同様に。
Each domain administrator is free to select any integrity/authentication algorithm, from the set specified by the IANA, for computing the integrity/authentication values contained in its domain's messages. However, we recommend that IDPR entities in each domain be capable of executing all of the valid algorithms so that an IDPR control message originating at an entity in one domain can be properly checked by an entity in another domain.
それぞれのドメイン管理者はIANAによって指定されたセットからどんな保全/認証アルゴリズムも自由に選択できます、ドメインのメッセージに含まれた保全/認証値を計算するために。 しかしながら、私たちは、各ドメインのIDPR実体が別のドメインで実体で適切に1つのドメインの実体で起因するIDPRコントロールメッセージはチェックできるように有効なアルゴリズムのすべてを実行できることを勧めます。
Each IDPR control message must carry a non-null integrity/authentication value. We recommend that control message integrity/authentication be based on a digital signature algorithm applied to a one-way hash function, such as RSA applied to MD5 [17], which simultaneously verifies message integrity and source authenticity. The digital signature may be based on either public- key or private-key cryptography. Our approach to digital signature use in IDPR is based on the privacy-enhanced Internet electronic mail service [13]-[15], already available in the Internet.
それぞれのIDPRコントロールメッセージは非ヌル保全/認証値を運ばなければなりません。 私たちは、コントロールメッセージの保全/認証が一方向ハッシュ関数に適用されたデジタル署名アルゴリズムに基づくことを勧めます、MD5[17]に適用されたRSAなどのように。MD5は同時に、メッセージの保全とソースの信憑性について確かめます。 デジタル署名は公共のキーか秘密鍵暗号のどちらかに基づくかもしれません。 IDPRにおけるデジタル署名使用への私たちのアプローチはプライバシーで高められたインターネット電子メールサービス[13]に基づいています--インターネットで既に利用可能な[15]。
We do not require that IDPR data messages carry a non-null integrity/authentication value. In fact, we recommend that a higher layer (end-to-end) procedure, and not IDPR, assume responsibility for checking the integrity and authenticity of data messages, because of the amount of computation involved.
私たちは、IDPRデータメッセージが非ヌル保全/認証値を運ぶのを必要としません。 事実上、私たちは、IDPRではなく、より高い層(終わるには、終わる)の手順が、保全をチェックすることへの責任と計算の量によるデータメッセージの信憑性にかかわると仮定することを勧めます。
1.7. Timestamps and Clock Synchronization
1.7. タイムスタンプと時計同期
Each IDPR message carries a timestamp (expressed in seconds elapsed since 1 January 1970 0:00 GMT, following the UNIX precedent) supplied by the source IDPR entity, which serves to indicate the age of the message. IDPR entities use the absolute value of the timestamp to confirm that a message is current and use the relative difference between timestamps to determine which message contains the more recent information.
それぞれのIDPRメッセージはソースIDPR実体によって提供されたタイムスタンプ(言い表されて、1970年1月1日のグリニッジ標準時0時0分は以来秒に経過していました、UNIX先例に従って)を運びます。実体はメッセージの時代を示すのに役立ちます。 IDPR実体は、どのメッセージが、より最近の情報を含むかを決定するのにメッセージがよく見られると確認して、タイムスタンプの相対的な違いを使用するのにタイムスタンプの絶対値を使用します。
All IDPR entities must possess internal clocks that are synchronized to some degree, in order for the absolute value of a message timestamp to be meaningful. The synchronization granularity required by IDPR is on the order of minutes and can be achieved manually.
すべてのIDPR実体がある程度連動する内部クロックを所有しなければなりません、メッセージタイムスタンプの絶対値が重要であるように。 IDPRによって必要とされた同期粒状は、数分の注文にはあって、手動で達成できます。
Steenstrup [Page 13] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[13ページ]RFC1479IDPRは1993年7月に議定書を作ります。
Thus, a clock synchronization protocol operating among all IDPR entities in all domains, while useful, is not necessary.
したがって、役に立つ間にすべてのドメインのすべてのIDPR実体の中で作動する時計同期プロトコルは必要ではありません。
An IDPR entity can determine whether to accept or reject a message based on the discrepancy between the message's timestamp and the entity's own internal clock time. Any IDPR message whose timestamp lies outside of the acceptable range may contain stale or corrupted information or may have been issued by a source whose internal clock has lost synchronization with the message recipient's internal clock. Timestamp checks are required for control messages because of the consequences of propagating and acting upon incorrect control information. However, timestamp checks are discretionary for data messages but may be invoked during problem diagnosis, for example, when checking for suspected message replays.
IDPR実体は、メッセージのタイムスタンプと実体の自己の内部クロック時間の間で食い違いに基づくメッセージを受け入れるか、または拒絶するかを決定できます。 タイムスタンプが許容できる範囲の外にあるどんなIDPRメッセージも、聞き古した崩壊した情報を含んでいるか、または内部クロックがメッセージ受取人の内部クロックとの同期を失ったソースによって発行されたかもしれません。 タイムスタンプチェックが不正確な制御情報を伝播して、作用する結果のためにコントロールメッセージに必要です。 しかしながら、タイムスタンプチェックは、データメッセージにおいて任意ですが、例えば、疑われたメッセージ再生がないかどうかチェックするとき、問題診断の間呼び出されるかもしれません。
We note that none of the IDPR protocols contain explicit provisions for dealing with an exhausted timestamp space. As timestamp space exhaustion will not occur until well into the next century, we expect timestamp space viability to outlast the IDPR protocols.
私たちは、IDPRプロトコルのいずれも疲れ果てているタイムスタンプスペースに対処するための明示の条項を含まないことに注意します。 タイムスタンプ宇宙疲労困憊がよく次の世紀まで起こらないとき、私たちは、タイムスタンプスペース生存力がIDPRプロトコルより長持ちすると予想します。
1.8. Network Management
1.8. ネットワークマネージメント
In this document, we do not describe how to configure and manage IDPR. However, in this section, we do provide a list of the types of IDPR configuration information required. Also, in later sections describing the IDPR protocols, we briefly note the types of exceptional events that must be logged for network management. Complete descriptions of IDPR entity configuration and IDPR managed objects appear in [7] and [8] respectively.
本書では、私たちは、どのようにIDPRを構成して、管理するかを説明しません。 しかしながら、このセクションに、私たちは設定情報が必要としたIDPRのタイプのリストを供給します。 また、IDPRプロトコルについて説明する後のセクションで、私たちは簡潔にネットワークマネージメントのために登録しなければならない例外的なイベントのタイプに注意します。 IDPR実体構成とIDPR管理オブジェクトの完全な記述は[7]と[8]にそれぞれ現れます。
To participate in inter-domain policy routing, policy gateways and route servers within a domain each require configuration information. Some of the configuration information is specifically defined within the given domain, while some of the configuration information is universally defined throughout an internetwork. A domain administrator determines domain-specific information, and in the Internet, the IANA determines globally significant information.
それぞれドメインの中で相互ドメイン方針ルーティング、方針ゲートウェイ、およびルートサーバに参加するには、設定情報を必要としてください。 設定情報のいくつかが与えられたドメインの中で明確に定義されます、設定情報のいくつかがインターネットワーク中で一般に定義されますが。 ドメイン管理者はドメイン特殊情報を決定します、そして、インターネットでは、IANAはグローバルに重要な情報を決定します。
To produce valid domain configurations, the domain administrators must receive the following global information from the IANA:
有効なドメイン構成を発生させるように、ドメイン管理者はIANAから以下のグローバルな情報を受け取らなければなりません:
- For each integrity/authentication type, the numeric
identifier, syntax, and semantics. Available integrity and
authentication types include but are not limited to:
- それぞれの保全/認証タイプ、数値識別子、構文、および意味論のために。 利用可能な保全としかしタイプが含む認証は以下のことのために制限されません。
o public-key based signatures;
o 公開鍵は署名を基礎づけました。
o private-key based signatures;
o 秘密鍵は署名を基礎づけました。
Steenstrup [Page 14] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[14ページ]RFC1479IDPRは1993年7月に議定書を作ります。
o cyclic redundancy checksums;
o 周期的な冗長チェックサム。
o no integrity/authentication.
o 保全/認証がありません。
- For each user class, the numeric identifier, syntax, and
semantics. Available user classes include but are not limited to:
- 各ユーザ・クラス、数値識別子、構文、および意味論のために。 含んでいますが、利用可能なユーザ・クラスは制限されません:
o federal (and if necessary, agency-specific such as NSF, DOD,
DOE, etc.);
o 連邦(そして、必要なら政府機関特有のNSF、DODなどのようにDOEなど)。
o research;
o 研究してください。
o commercial;
o コマーシャル。
o support.
o サポート。
- For each offered service that may be advertised in transit
policies, the numeric identifier, syntax, and semantics. Available
offered services include but are not limited to:
- 各提供サービスにおいて、運送保険証券、数値識別子、構文、および意味論でそれの広告を出すかもしれません。 含んでいますが、利用可能な提供サービスは制限されません:
o average message delay;
o メッセージ遅延を平均してください。
o message delay variation;
o メッセージ遅延変化。
o average bandwidth available;
o 利用可能な平均した帯域幅。
o available bandwidth variation;
o 利用可能な帯域幅変化。
o maximum transfer unit (MTU);
o 最大の移動単位数(MTU)。
o charge per byte;
o 1バイト単位で充電してください。
o charge per message;
o メッセージ単位で充電してください。
o charge per unit time.
o ユニット時間単位で充電してください。
- For each access restriction that may be advertised in transit
policies, the numeric identifier, syntax, and semantics. Available
access restrictions include but are not limited to:
- それぞれのアクセス制限において、運送保険証券、数値識別子、構文、および意味論でそれの広告を出すかもしれません。 含んでいますが、利用可能なアクセス制限は制限されません:
o Source and destination domains and host sets.
o ソース、目的地ドメイン、およびホストセット。
o User classes.
o ユーザは属します。
o Entry and exit virtual gateways.
o エントリーと出口の仮想のゲートウェイ。
o Time of day.
o 時刻。
Steenstrup [Page 15] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[15ページ]RFC1479IDPRは1993年7月に議定書を作ります。
- For each requested service that may appear within a path setup
message, the numeric identifier, syntax, and semantics. Available
requested services include but are not limited to:
- それぞれの要求されたサービスに関しては、それは経路セットアップメッセージ、数値識別子、構文、および意味論の中に現れるかもしれません。 含んでいますが、利用可能な要求されたサービスは制限されません:
o maximum path life in minutes, messages, or bytes;
o 数分、メッセージ、またはバイトにおける最大の経路の寿命。
o integrity/authentication algorithms to be used on data
messages sent over the path;
o データメッセージで使用されるべき保全/認証アルゴリズムは経路を移動しました。
o upper bound on path delay;
o 経路遅れに関する上限。
o minimum delay path;
o 最小の遅れ経路。
o upper bound on path delay variation;
o 経路遅れ変化に関する上限。
o minimum delay variation path;
o 最小の遅れ変化経路。
o lower bound on path bandwidth;
o 経路帯域幅における下界。
o maximum bandwidth path;
o 最大の帯域幅経路。
o upper bound on monetary cost;
o 貨幣原価に関する上限。
o minimum monetary cost path.
o 最小の貨幣原価経路。
In an internetwork-wide implementation of IDPR, the set of global configuration parameters and their syntax and semantics must be consistent across all participating domains. The IANA, responsible for establishing the full set of global configuration parameters in the Internet, relies on the cooperation of the administrators of all participating domains to ensure that the global parameters are consistent with the desired transit policies and user service requirements of each domain. Moreover, as the syntax and semantics of the global parameters affects the syntax and semantics of the corresponding IDPR software, the IANA must carefully define each global parameter so that it is unlikely to require future modification.
IDPRのインターネットワーク全体の実装では、それらのグローバルな設定パラメータ、構文、および意味論のセットはすべて参加しているドメインの向こう側に一貫しているに違いありません。 インターネットのグローバルな設定パラメータのフルセットを確立するのに責任があるIANAは、グローバルなパラメタがそれぞれのドメインに関する必要な運送保険証券とユーザサービス要件と一致しているのを保証するためにすべて参加しているドメインの管理者の協力に依存します。 グローバルなパラメタの構文と意味論が対応するIDPRソフトウェアの構文と意味論に影響するとき、IANAが慎重にそれぞれのグローバルなパラメタを定義しなければならないので、そのうえ、それは今後の変更を必要としそうにはありません。
The IANA provides configured global information to configuration servers in all domains participating in IDPR. Each domain administrator uses the configured global information maintained by its configuration servers to develop configurations for each IDPR entity within its domain. Each configuration server retains a copy of the configuration for each local IDPR entity and also distributes the configuration to that entity using, for example, SNMP.
IANAは、IDPRに参加しながら、すべてのドメインで構成されたグローバルな情報を構成サーバに提供します。 それぞれのドメイン管理者はドメインの中のそれぞれのIDPR実体のために構成を発生するように構成サーバによって保守された構成されたグローバルな情報を使用します。 それぞれの構成サーバは、それぞれの地方のIDPR実体のために構成のコピーを保有して、また、例えばSNMPを使用することでその実体に構成を分配します。
Steenstrup [Page 16] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[16ページ]RFC1479IDPRは1993年7月に議定書を作ります。
1.8.1. Policy Gateway Configuration
1.8.1. 方針ゲートウェイ構成
Each policy gateway must contain sufficient configuration information to perform its IDPR functions, which subsume those of the path agent. These include: validating IDPR control messages; generating and distributing virtual gateway connectivity and routing information messages to peer, neighbor, and adjacent policy gateways; distributing routing information messages to route servers in its domain; resolving destination addresses; requesting policy routes from route servers; selecting policy routes and initiating path setup; ensuring consistency of a path with its domain's transit policies; establishing path forwarding information; and forwarding IDPR data messages along existing paths. The necessary configuration information includes the following:
それぞれの方針ゲートウェイは経路エージェントのものを包括するIDPR機能を実行できるくらいの設定情報を含まなければなりません。 これらは: IDPRを有効にして、メッセージを制御してください。 仮想のゲートウェイの接続性、じっと見るルーティング情報メッセージ、隣人、および隣接している方針ゲートウェイを生成して、分配します。 ドメインでサーバを発送するルーティング情報メッセージを分配します。 送付先アドレスを決議します。 方針を要求すると、ルートから、サーバは発送されます。 方針ルートを選択して、経路を開始するのはセットアップされます。 ドメインの運送保険証券がある経路について一貫性があることを保証します。 経路推進情報を確立します。 そして、存在することに沿ったIDPRデータメッセージに経路を送ること。 必要な設定情報は以下を含んでいます:
- For each integrity/authentication type, the numeric identifier,
syntax, and semantics.
- それぞれの保全/認証タイプ、数値識別子、構文、および意味論のために。
- For each policy gateway and route server in the given domain, the
numeric identifier and set of addresses or names.
- アドレスか名前の与えられたドメインのそれぞれの方針ゲートウェイとルートサーバ、数値識別子、およびセットのために。
- For each virtual gateway connected to the given domain, the numeric
identifier, the numeric identifiers for the constituent peer policy
gateways, and the numeric identifier for the adjacent domain.
- 与えられたドメイン、数値識別子、構成している同輩方針ゲートウェイのための数値識別子、および隣接しているドメインのための数値識別子に接続されたそれぞれの仮想のゲートウェイに。
- For each virtual gateway of which the given policy gateway is a
member, the numeric identifiers and set of addresses for the
constituent adjacent policy gateways.
- それのそれぞれの仮想のゲートウェイに関して、与えられた方針ゲートウェイは構成している隣接している方針ゲートウェイへのメンバー、数値識別子、およびセットのアドレスです。
- For each policy gateway directly-connected and adjacent to the
given policy gateway, the local connecting interface.
- 各方針のために、ゲートウェイは、直接接続して、与えられた方針ゲートウェイ、地方の接続インタフェースに隣接してそうしました。
- For each local route server to which the given policy gateway
distributes routing information, the numeric identifier.
- 与えられた方針ゲートウェイがルーティング情報、数値識別子を分配するそれぞれのローカルのルートサーバのために。
- For each source policy applicable to hosts within the given domain,
the syntax and semantics.
- 与えられたドメイン、構文、および意味論の中でホストに適切なそれぞれのソース方針のために。
- For each transit policy applicable to the domain, the numeric
identifier, syntax, and semantics.
- そのドメインに適切なそれぞれの運送保険証券、数値識別子、構文、および意味論のために。
- For each requested service that may appear within a path setup
message, the numeric identifier, syntax, and semantics.
- それぞれの要求されたサービスに関しては、それは経路セットアップメッセージ、数値識別子、構文、および意味論の中に現れるかもしれません。
- For each source user class, the numeric identifier, syntax, and
semantics.
- それぞれのソースユーザ・クラス、数値識別子、構文、および意味論のために。
Steenstrup [Page 17] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[17ページ]RFC1479IDPRは1993年7月に議定書を作ります。
1.8.2. Route Server Configuration
1.8.2. ルートサーバ構成
Each route server must contain sufficient configuration information to perform its IDPR functions, which subsume those of the path agent. These include: validating IDPR control messages; deciphering and storing the contents of routing information messages; exchanging routing information with other route servers and policy gateways; generating policy routes that respect transit policy restrictions and source service requirements; distributing policy routes to path agents in policy gateways; resolving destination addresses; selecting policy routes and initiating path setup; establishing path forwarding information; and forwarding IDPR data messages along existing paths. The necessary configuration information includes the following:
それぞれのルートサーバは経路エージェントのものを包括するIDPR機能を実行できるくらいの設定情報を含まなければなりません。 これらは: IDPRを有効にして、メッセージを制御してください。 ルーティング情報メッセージのコンテンツを解読して、保存します。 他のルートサーバとルーティング情報を交換して、方針ゲートウェイ。 方針ルートがそれであると生成して、運送保険証券制限とソースサービス要件を尊敬してください。 方針を分配すると、方針ゲートウェイのエージェントは経路に発送されます。 送付先アドレスを決議します。 方針ルートを選択して、経路を開始するのはセットアップされます。 経路推進情報を確立します。 そして、存在することに沿ったIDPRデータメッセージに経路を送ること。 必要な設定情報は以下を含んでいます:
- For each integrity/authentication type, the numeric identifier,
syntax, and semantics.
- それぞれの保全/認証タイプ、数値識別子、構文、および意味論のために。
- For each policy gateway and route server in the given domain, the
numeric identifier and set of addresses or names.
- アドレスか名前の与えられたドメインのそれぞれの方針ゲートウェイとルートサーバ、数値識別子、およびセットのために。
- For each source policy applicable to hosts within the given domain,
the syntax and semantics.
- 与えられたドメイン、構文、および意味論の中でホストに適切なそれぞれのソース方針のために。
- For access restriction that may be advertised in transit
policies, the numeric identifier, syntax, and semantics.
- アクセス制限において、運送保険証券、数値識別子、構文、および意味論でそれの広告を出すかもしれません。
- For each offered service that may be advertised in transit policies,
the numeric identifier, syntax, and semantics.
- 各提供サービスにおいて、運送保険証券、数値識別子、構文、および意味論でそれの広告を出すかもしれません。
- For each requested service that may appear within a path setup
message, the numeric identifier, syntax, and semantics.
- それぞれの要求されたサービスに関しては、それは経路セットアップメッセージ、数値識別子、構文、および意味論の中に現れるかもしれません。
- For each source user class, the numeric identifier, syntax, and
semantics.
- それぞれのソースユーザ・クラス、数値識別子、構文、および意味論のために。
2. Control Message Transport Protocol
2. 規制メッセージトランスポート・プロトコル
IDPR control messages convey routing-related information that directly affects the policy routes generated and the paths set up across the Internet. Errors in IDPR control messages can have widespread, deleterious effects on inter-domain policy routing, and so the IDPR protocols have been designed to minimize loss and corruption of control messages. For every control message it transmits, each IDPR protocol expects to receive notification as to whether the control message successfully reached the intended IDPR recipient. Moreover, the IDPR recipient of a control message first verifies that the message appears to be well-formed, before acting on its contents.
IDPRコントロールメッセージは直接ルートが発生させた方針とインターネットの向こう側にセットアップされた経路に影響するルーティング関連の情報を伝えます。 IDPRコントロールメッセージにおける誤りが相互ドメイン方針ルーティングに広範囲の、そして、有害な影響を与えることができるので、IDPRプロトコルはコントロールメッセージの損失と不正を最小にするように設計されています。 それが送るあらゆるコントロールメッセージに関しては、IDPRが議定書の中で述べるそれぞれが、コントロールメッセージが首尾よく意図しているIDPR受取人に届いたかどうかに関して通知を受け取ると予想します。 そのうえ、コントロールメッセージのIDPR受取人は、最初にメッセージがよく形成されているように見えることを確かめます、コンテンツに影響する前に。
Steenstrup [Page 18] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[18ページ]RFC1479IDPRは1993年7月に議定書を作ります。
All IDPR protocols use the Control Message Transport Protocol (CMTP), a connectionless, transaction-based transport layer protocol, for communication with intended recipients of control messages. CMTP retransmits unacknowledged control messages and applies integrity and authenticity checks to received control messages.
すべてのIDPRプロトコルがControl Message Transportプロトコル(CMTP)を使用します、コネクションレスで、取引ベースのトランスポート層プロトコル、コントロールメッセージの意図している受取人とのコミュニケーションのために。 CMTPは不承認のコントロールメッセージを再送して、保全を適用します、そして、信憑性は受信されたコントロールメッセージにチェックします。
There are three types of CMTP messages:
3つのタイプに関するCMTPメッセージがあります:
DATAGRAM:
Contains IDPR control messages.
データグラム: IDPRコントロールメッセージを含んでいます。
ACK: Positive acknowledgement in response to a DATAGRAM message.
ACK: データグラムメッセージに対応した積極的な承認。
NAK: Negative acknowledgement in response to a DATAGRAM message.
NAK: データグラムメッセージに対応した否定的承認。
Each CMTP message contains several pieces of information supplied by the sender that allow the recipient to test the integrity and authenticity of the message. The set of integrity and authenticity checks performed after CMTP message reception are collectively referred to as "validation checks" and are described in section 2.3.
それぞれのCMTPメッセージは受取人にメッセージの保全と信憑性をテストさせる送付者によって提供された数片の情報を含んでいます。 CMTPメッセージレセプションが「合法化はチェックする」とまとめて呼ばれて、セクション2.3で説明された後に保全と信憑性チェックのセットは働きました。
When we first designed the IDPR protocols, CMTP as a distinct protocol did not exist. Instead, CMTP-equivalent functionality was embedded in each IDPR protocol. To provide a cleaner implementation, we later decided to provide a single transport protocol that could be used by all IDPR protocols. We originally considered using an existing transport protocol, but rejected this approach for the following reasons:
私たちが最初にIDPRプロトコルを設計したとき、異なったプロトコルとしてのCMTPは存在しませんでした。 代わりに、CMTP同等な機能性はそれぞれのIDPRプロトコルに埋め込まれました。 クリーナー実現を提供するために、私たちは、後ですべてのIDPRプロトコルで使用できたただ一つのトランスポート・プロトコルを提供すると決めました。 私たちは、元々既存のトランスポート・プロトコルを使用すると考えましたが、以下の理由でこのアプローチを拒絶しました:
- The existing reliable transport protocols do not provide all of the
validation checks, in particular the timestamp and authenticity
checks, required by the IDPR protocols. Hence, if we were to use
one of these protocols, we would still have to provide a separate
protocol on top of the transport protocol to force retransmission of
IDPR messages that failed to pass the required validation checks.
- 既存の信頼できるトランスポート・プロトコルは特にチェック、タイムスタンプ、および信憑性チェックがIDPRプロトコルで必要とした合法化のすべてを提供しません。 したがって、私たちがこれらのプロトコルの1つを使用するなら、必要な合法化チェックを通過しなかったIDPRメッセージの「再-トランスミッション」を強制するためにトランスポート・プロトコルの上でまだ別々のプロトコルを提供しなければならないでしょうに。
- Many of the existing reliable transport protocols are window-based
and hence can result in increased message delay and resource use
when, as is the case with IDPR, multiple independent messages use
the same transport connection. A single message experiencing
transmission problems and requiring retransmission can prevent the
window from advancing, forcing all subsequent messages to queue
behind it. Moreover, many of the window-based protocols do not
support selective retransmission of failed messages but instead
require retransmission of not only the failed message but also all
preceding messages within the window.
- 複数の独立しているメッセージがIDPRがあるケースのように同じ輸送接続を使用すると、既存の信頼できるトランスポート・プロトコルの多くが、窓のベースであり、したがって、増加するメッセージ遅延とリソース使用をもたらすことができます。 トランスミッション問題を経験して、「再-トランスミッション」を必要とするただ一つのメッセージは、窓が進むのを防ぐことができます、それの後ろに列を作るすべてのその後のメッセージを強制して。 そのうえ、窓のベースのプロトコルの多くが、失敗したメッセージの選択している「再-トランスミッション」を支持するのではなく、代わりに失敗したメッセージだけではなく、窓の中のすべての前のメッセージも「再-トランスミッション」に要求します。
For these reasons, we decided against using an existing transport
これらの理由で、私たちは、既存の輸送を使用しないように決めました。
Steenstrup [Page 19] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[19ページ]RFC1479IDPRは1993年7月に議定書を作ります。
protocol and in favor of developing CMTP.
議定書の中で述べて、CMTPを開発することを支持して。
2.1. Message Transmission
2.1. メッセージ送信
At the transmitting entity, when an IDPR protocol is ready to issue a control message, it passes a copy of the message to CMTP; it also passes a set of parameters to CMTP for inclusion in the CMTP header and for proper CMTP message handling. In turn, CMTP converts the control message and associated parameters into a DATAGRAM by prepending the appropriate header to the control message. The CMTP header contains several pieces of information to aid the message recipient in detecting errors (see section 2.4). Each IDPR protocol can specify all of the following CMTP parameters applicable to its control message:
伝える実体では、IDPRプロトコルがコントロールメッセージを発行する準備ができているとき、メッセージのコピーをCMTPに渡します。 また、それはCMTPヘッダーでの包含と適切なCMTPメッセージハンドリングのために1セットのパラメタをCMTPに通過します。 順番に、CMTPは、コントロールメッセージに適切なヘッダーをprependingすることによって、コントロールメッセージと関連パラメタをデータグラムに変換します。 CMTPヘッダーは誤りを検出する際にメッセージ受取人を支援する数片の情報を含んでいます(セクション2.4を見てください)。 それぞれのIDPRプロトコルはコントロールメッセージに適切な以下のCMTPパラメタのすべてを指定できます:
- IDPR protocol and message type.
- IDPRプロトコルとメッセージタイプ。
- Destination.
- 目的地。
- Integrity/authentication scheme.
- 保全/認証計画。
- Timestamp.
- タイムスタンプ。
- Maximum number of transmissions allotted.
- 割り当てられたトランスミッションの最大数。
- Retransmission interval in microseconds.
- マイクロセカンドの再送信間隔。
One of these parameters, the timestamp, can be specified directly by CMTP as the internal clock time at which the message is transmitted. However, two of the IDPR protocols, namely flooding and path control, themselves require message generation timestamps for proper protocol operation. Thus, instead of requiring CMTP to pass back a timestamp to an IDPR protocol, we simplify the service interface between CMTP and the IDPR protocols by allowing an IDPR protocol to specify the timestamp in the first place.
直接CMTPはメッセージが送られる内部クロック時としてこれらのパラメタの1つ(タイムスタンプ)を指定できます。 しかしながら、2つのIDPRプロトコルであり、すなわち、氾濫と経路が制御される、自分たち、適切なプロトコル操作のためのメッセージ世代タイムスタンプを必要としてください。 したがって、CMTPがIDPRプロトコルにタイムスタンプを戻すのが必要であることの代わりに、IDPRプロトコルが第一にタイムスタンプを指定するのを許容することによって、私たちはCMTPとIDPRプロトコルとのサービスインタフェースを簡素化します。
Using the control message and accompanying parameters supplied by the IDPR protocol, CMTP constructs a DATAGRAM, adding to the header CMTP-specific parameters. In particular, CMTP assigns a "transaction identifier" to each DATAGRAM generated, which it uses to associate acknowledgements with DATAGRAM messages. Each DATAGRAM recipient includes the received transaction identifier in its returned ACK or NAK, and each DATAGRAM sender uses the transaction identifier to match the received ACK or NAK with the original DATAGRAM.
IDPRプロトコルによって提供されたコントロールメッセージと付随のパラメタを使用して、CMTPはデータグラムを構成します、ヘッダーのCMTP特有のパラメタに加えて。 特に、CMTPは「取引識別子」を発生する各データグラムに割り当てます。(それは、データグラムメッセージに承認を関連づけるのにそれを使用します)。 それぞれのデータグラム受取人はその返されたACKかNAKの受信された取引識別子を入れます、そして、それぞれのデータグラム送付者は容認されたACKかNAKをオリジナルのデータグラムに合わせるのに取引識別子を使用します。
A single DATAGRAM, for example a routing information message or a path control message, may be handled by CMTP at many different policy gateways. Within a pair of consecutive IDPR entities, the DATAGRAM
ただ一つのデータグラム(例えば、ルーティング情報メッセージか経路制御メッセージ)は、多くの異なった方針ゲートウェイでCMTPによって扱われるかもしれません。 1組の連続したIDPR実体、データグラムの中で
Steenstrup [Page 20] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[20ページ]RFC1479IDPRは1993年7月に議定書を作ります。
sender expects to receive an acknowledgement from the DATAGRAM recipient. However, only the IDPR entity that actually generated the original CMTP DATAGRAM has control over the transaction identifier, because that entity may supply a digital signature that covers the entire DATAGRAM. The intermediate policy gateways that transmit the DATAGRAM do not change the transaction identifier. Nevertheless, at each DATAGRAM recipient, the transaction identifier must uniquely distinguish the DATAGRAM so that only one acknowledgement from the next DATAGRAM recipient matches the original DATAGRAM. Therefore, the transaction identifier must be globally unique.
送付者は、データグラム受取人から承認を受けると予想します。 しかしながら、実際にオリジナルのCMTP DATAGRAMを発生させたIDPR実体だけが取引識別子を管理します、その実体が全体のデータグラムをカバーするデジタル署名を供給するかもしれないので。 データグラムを伝える中間的方針ゲートウェイは取引識別子を変えません。 それにもかかわらず、それぞれのデータグラム受取人では、取引識別子が唯一データグラムを区別しなければならないので、次のデータグラム受取人からの1つの承認だけがオリジナルのデータグラムに合っています。 したがって、取引識別子はグローバルにユニークでなければなりません。
The transaction identifier consists of the numeric identifiers for the domain and IDPR entity (policy gateway or route server) issuing the original DATAGRAM, together with a 32-bit local identifier assigned by CMTP operating within that IDPR entity. We recommend implementing the 32-bit local identifier either as a simple counter incremented for each DATAGRAM generated or as a fine granularity clock. The former always guarantees uniqueness of transaction identifiers; the latter guarantees uniqueness of transaction identifiers, provided the clock granularity is finer than the minimum possible interval between DATAGRAM generations and the clock wrapping period is longer than the maximum round-trip delay to and from any internetwork destination.
取引識別子はオリジナルのデータグラムを発行するドメインとIDPR実体(方針ゲートウェイかルートサーバ)のために数値識別子から成ります、そのIDPR実体の中で作動するCMTPによって割り当てられた32ビットのローカルの識別子と共に。 私たちは、発生する各データグラムのために増加された簡単なカウンタとして、または、すばらしい粒状時計として32ビットのローカルの識別子を実行することを勧めます。 前者はいつも取引識別子のユニークさを保証します。 後者は取引識別子のユニークさを保証します、時計粒状がデータグラム世代と時計ラッピングの期間の最小の可能な間隔が最大の往復の遅れより長い間目的地とどんなインターネットワークの目的地からもあるよりすばらしいなら。
Before transmitting a DATAGRAM, CMTP computes the length of the entire message, taking into account the prescribed integrity/authentication scheme, and then computes the integrity/authentication value over the whole message. CMTP includes both of these quantities, which are crucial for checking message integrity and authenticity at the recipient, in the DATAGRAM header. After sending a DATAGRAM, CMTP saves a copy and sets an associated retransmission timer, as directed by the IDPR protocol parameters. If the retransmission timer fires and CMTP has received neither an ACK nor a NAK for the DATAGRAM, CMTP then retransmits the DATAGRAM, provided this retransmission does not exceed the transmission allotment. Whenever a DATAGRAM exhausts its transmission allotment, CMTP discards the DATAGRAM, informs the IDPR protocol that the control message transmission was not successful, and logs the event for network management. In this case, the IDPR protocol may either resubmit its control message to CMTP, specifying an alternate destination, or discard the control message altogether.
データグラムを伝える前に、CMTPは処方された保全/認証計画を考慮に入れて、全体のメッセージの長さを計算して、次に、全体のメッセージに関して保全/認証値を計算します。 CMTPはこれらの受取人でメッセージの保全と信憑性をチェックするのに、重要な量の両方を含んでいます、データグラムヘッダーで。 データグラムを送った後に、CMTPはコピーを保存して、関連再送信タイマーを設定します、IDPRプロトコルパラメタによって指示されるように。 再送信タイマーが撃たれて、CMTPがデータグラムのためにACKもNAKも受けていないなら、CMTPはデータグラムを再送します、この「再-トランスミッション」がトランスミッション割当てを超えていないなら。 トランスミッション割当てがデータグラムでくたくたになるときはいつも、CMTPはデータグラムを捨てて、コントロールメッセージ送信がうまくいかなかったことをIDPRプロトコルに知らせて、ネットワークマネージメントのために出来事を登録します。 この場合、IDPRプロトコルは、交互の目的地を指定して、コントロールメッセージをCMTPに再提出するか、または全体でコントロールメッセージを捨てるかもしれません。
Steenstrup [Page 21] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[21ページ]RFC1479IDPRは1993年7月に議定書を作ります。
2.2. Message Reception
2.2. メッセージレセプション
At the receiving entity, when CMTP obtains a DATAGRAM, it takes one of the following actions, depending upon the outcome of the message validation checks:
CMTPがデータグラムを得るとき、受信実体では、以下の動作の1つを取ります、メッセージ合法化チェックの結果によって:
- The DATAGRAM passes the CMTP validation checks. CMTP then delivers
the DATAGRAM with enclosed IDPR control message, to the appropriate
IDPR protocol, which in turn applies its own integrity checks to
the control message before acting on the contents. The recipient
IDPR protocol, except in one case, directs CMTP to generate an ACK
and return the ACK to the sender. That exception is the up/down
protocol (see section 3.2) which determines reachability of
adjacent policy gateways and does not use CMTP ACK messages to
notify the sender of message reception. Instead, the up/down
protocol messages themselves carry implicit information about
message reception at the adjacent policy gateway. In the cases
where the recipient IDPR protocol directs CMTP to generate an ACK,
it may pass control information to CMTP for inclusion in the ACK,
depending on the contents of the original IDPR control message.
For example, a route server unable to fill a request for routing
information may inform the requesting IDPR entity, through an ACK
for the initial request, to place its request elsewhere.
- データグラムはCMTP合法化チェックを通過します。 次に、CMTPは同封のIDPRコントロールメッセージがあるデータグラムを送ります、適切なIDPRプロトコルに。(順番に、コンテンツに影響する前に、それは、それ自身の保全チェックをコントロールメッセージに適用します)。 1つのケースを除いて、受取人IDPRプロトコルはACKを発生させて、ACKを送付者に返すようCMTPに指示します。 例外が上がるか下がることであることが議定書を作ります(隣接している方針ゲートウェイの可到達性を決定して、メッセージレセプションについて送付者に通知するCMTP ACKメッセージを使用しません)(セクション3.2を見てください)。 代わりに、上/下にプロトコルメッセージ自体は隣接している方針ゲートウェイでメッセージレセプションの暗黙の情報を運びます。 受取人IDPRプロトコルがACKを発生させるようCMTPに指示する場合では、ACKでの包含のために制御情報をCMTPに通過するかもしれません、オリジナルのIDPRコントロールメッセージのコンテンツによって。 例えば、ルーティング情報に関する要求をいっぱいにすることができないルートサーバは、要求をほかの場所に置くために初期の要求のためのACKを通して要求しているIDPR実体を知らせるかもしれません。
- The DATAGRAM fails at least one of the CMTP validation checks.
CMTP then generates a NAK, returns the NAK to the sender, and
discards the DATAGRAM, regardless of the type of IDPR control
message contained in the DATAGRAM. The NAK indicates the nature of
the validation failure and serves to help the sender establish
communication with the recipient. In particular, the CMTP NAK
provides a mechanism for negotiation of IDPR version and
integrity/authentication scheme, two parameters crucial for
establishing communication between IDPR entities.
- データグラムは少なくともCMTP合法化チェックの1つに失敗します。 CMTPは次に、NAKを発生させて、NAKを送付者に返して、データグラムを捨てます、データグラムで含まれたIDPRコントロールメッセージのタイプにかかわらず。 NAKは、合法化失敗の本質を示して、送付者が受取人とのコミュニケーションを確立するのを助けるのに役立ちます。 特に、CMTP NAKはIDPRバージョンと保全/認証計画(IDPR実体のコミュニケーションを確立するのに、重要な2つのパラメタ)の交渉にメカニズムを提供します。
Upon receiving an ACK or a NAK, CMTP immediately discards the message if at least one of the validation checks fails or if it is unable to locate the associated DATAGRAM. CMTP logs the latter event for network management. Otherwise, if all of the validation checks pass and if it is able to locate the associated DATAGRAM, CMTP clears the associated retransmission timer and then takes one of the following actions, depending upon the message type:
ACKかNAKを受けると、少なくとも合法化チェックの1つが失敗するか、または関連データグラムの場所を見つけることができないなら、CMTPはすぐに、メッセージを捨てます。 CMTPはネットワークマネージメントのために後者の出来事を登録します。 さもなければ、合法化チェックのすべてが通って、関連データグラムの場所を見つけることができるなら、CMTPは関連再送信タイマーをきれいにして、次に、以下の動作の1つを取ります、メッセージタイプに頼っていて:
- The message is an ACK. CMTP discards the associated DATAGRAM and
delivers the ACK, which may contain IDPR control information, to
the appropriate IDPR protocol.
- メッセージはACKです。 CMTPは関連データグラムを捨てて、適切なIDPRプロトコルにACKを届けます。(ACKはIDPR制御情報を含むかもしれません)。
- The message is a NAK. If the associated DATAGRAM has exhausted its
transmission allotment, CMTP discards the DATAGRAM, informs the
- メッセージはNAKです。 トランスミッション割当てが関連データグラムでくたくたになったなら、CMTPはデータグラムを捨てて、知らせます。
Steenstrup [Page 22] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[22ページ]RFC1479IDPRは1993年7月に議定書を作ります。
appropriate IDPR protocol that the control message transmission was
not successful, and logs the event for network management.
Otherwise, if the associated DATAGRAM has not yet exhausted its
transmission allotment, CMTP first checks its copy of the DATAGRAM
against the failure indication contained in the NAK. If its
DATAGRAM copy appears to be intact, CMTP retransmits the DATAGRAM
and sets the associated retransmission timer. However, if its
DATAGRAM copy appears to be corrupted, CMTP discards the DATAGRAM,
informs the IDPR protocol that the control message transmission was
not successful, and logs the event for network management.
うまくいかなくコントロールメッセージ送信があったIDPRプロトコルを当ててください。そうすれば、ログはネットワークマネージメントのための出来事を当てます。 そうでなければ失敗指示に対するデータグラムのコピーがNAKに含んだCMTP最初のチェックトランスミッション割当てが関連データグラムでまだくたくたになっていないなら。 データグラムコピーが完全であるように見えるなら、CMTPはデータグラムを再送して、関連再送信タイマーを設定します。 しかしながら、データグラムコピーが崩壊するように見えるなら、CMTPはデータグラムを捨てて、コントロールメッセージ送信がうまくいかなかったことをIDPRプロトコルに知らせて、ネットワークマネージメントのために出来事を登録します。
2.3. Message Validation
2.3. メッセージ合法化
On every CMTP message received, CMTP performs a set of validation checks to test message integrity and authenticity. The order in which these tests are executed is important. CMTP must first determine if it can parse enough of the message to compute the integrity/authentication value. (Refer to section 2.4 for a description of CMTP message formats.) Then, CMTP must immediately compute the integrity/authentication value before checking other header information. An incorrect integrity/authentication value means that the message is corrupted, and so it is likely that CMTP header information is incorrect. Checking specific header fields before computing the integrity/authentication value not only may waste time and resources, but also may lead to incorrect diagnoses of a validation failure.
受け取られたあらゆるCMTPメッセージに、CMTPは、メッセージの保全と信憑性をテストするために1セットの合法化チェックを実行します。 これらのテストが実行されるオーダーは重要です。 CMTPは、最初に、それが保全/認証値を計算するメッセージを十分分析できるかどうか決定しなければなりません。 (CMTPメッセージ・フォーマットの記述についてセクション2.4を参照してください。) そして、他のヘッダー情報をチェックする前に、CMTPはすぐに、保全/認証値を計算しなければなりません。 不正確な保全/認証値が、メッセージが崩壊することを意味するので、CMTPヘッダー情報が不正確であることは、傾向があります。 保全/認証値を計算する前に特定のヘッダーフィールドをチェックするのは時間とリソースを浪費するかもしれないだけではなく、合法化失敗の不正確な診断に通じもするかもしれません。
The CMTP validation checks are as follows:
CMTP合法化チェックは以下の通りです:
- CMTP verifies that it can recognize both the control message
version type contained in the header. Failure to recognize either
one of these values means that CMTP cannot continue to parse the
message.
- CMTPは、コントロールメッセージバージョンタイプがヘッダーに含んだ両方を認識できることを確かめます。 これらのどちらの値も認識しない場合、CMTPが、メッセージを分析し続けることができないことを意味します。
- CMTP verifies that it can recognize and accept the
integrity/authentication type contained in the header; no
integrity/authentication is not an acceptable type for CMTP.
- CMTPはヘッダーに含まれた保全/認証タイプを見分けて、受け入れることができることを確かめます。 どんな保全/認証もCMTPのための許容タイプではありません。
- CMTP computes the integrity/authentication value and verifies that
it equals the integrity/authentication value contained in the
header. For key-based integrity/authentication schemes, CMTP may
use the source domain identifier contained in the CMTP header to
index the correct key. Failure to index a key means that CMTP
cannot compute the integrity/authentication value.
- CMTPは、保全/認証値を計算して、それがヘッダーに含まれた保全/認証値と等しいことを確かめます。 キーベースの保全/認証計画のために、CMTPは正しいキーに索引をつけるためにCMTPヘッダーに含まれたソースドメイン識別子を使用するかもしれません。 キーに索引をつけない場合、CMTPが保全/認証値を計算できないことを意味します。
- CMTP computes the message length in bytes and verifies that it
equals the length value contained in the header.
- CMTPは、バイトで表現されるメッセージ長を計算して、それがヘッダーに含まれた長さの値と等しいことを確かめます。
Steenstrup [Page 23] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[23ページ]RFC1479IDPRは1993年7月に議定書を作ります。
- CMTP verifies that the message timestamp is in the acceptable
range. The message should be no more recent than cmtp_new (300)
seconds ahead of the entity's current internal clock time. In this
document, when we present an IDPR system configuration parameter,
such as cmtp_new, we usually follow it with a recommended value in
parentheses. The cmtp_new value allows some clock drift between
IDPR entities. Moreover, each IDPR protocol has its own limit on
the maximum age of its control messages. The message should be no
less recent than a prescribed number of seconds behind the
recipient entity's current internal clock time. Hence, each IDPR
protocol performs its own message timestamp check in addition to
that performed by CMTP.
- CMTPは、メッセージタイムスタンプが許容できる範囲にあることを確かめます。 メッセージは実体の現在の内部クロック時間のcmtp_新しい(300)秒前ほど最近であるべきではありません。 新しい状態でcmtp_などのIDPRシステム構成パラメタを提示するとき、本書では、通常、推奨値が括弧にある状態で、私たちはそれの後をつけます。 cmtpの_の新しい価値はIDPR実体の間のいくらかの時計ドリフトを許容します。 そのうえ、それぞれのIDPRプロトコルには、コントロールメッセージの最大の時代に、それ自身の限界があります。 メッセージは受取人実体の現在の内部クロック時間の後ろの定員の秒ほど最近であるべきでないというわけではありません。 したがって、それぞれのIDPRプロトコルはCMTPによってそこへ持ってきて実行されたそれ自身のメッセージタイムスタンプチェックを実行します。
- CMTP verifies that it can recognize the IDPR protocol designated
for the enclosed control message.
- CMTPは、同封のコントロールメッセージのために指定されたIDPRプロトコルを認識できることを確かめます。
Whenever CMTP encounters a failure while performing any of these validation checks, it logs the event for network management. If the failure occurs on a DATAGRAM, CMTP immediately generates a NAK containing the reason for the failure, returns the NAK to the sender, and discards the DATAGRAM message. If the failure occurs on an ACK or a NAK, CMTP discards the ACK or NAK message.
CMTPがこれらの合法化チェックのどれかを実行している間、失敗に遭遇するときはいつも、それはネットワークマネージメントのためにイベントを登録します。 失敗がデータグラムに起こるなら、CMTPはすぐに失敗の理由を含むNAKを生成して、NAKを送付者に返して、データグラムメッセージを捨てます。 失敗がACKかNAKに起こるなら、CMTPはACKかNAKメッセージを捨てます。
2.4. CMTP Message Formats
2.4. CMTPメッセージ・フォーマット
In designing the format of IDPR control messages, we have attempted to strike a balance between efficiency of link bandwidth usage and efficiency of message processing. In general, we have chosen compact representations for IDPR information in order to minimize the link bandwidth consumed by IDPR-specific information. However, we have also organized IDPR information in order to speed message processing, which does not always result in minimum link bandwidth usage.
IDPRコントロールメッセージの形式を設計する際に、私たちは、リンク帯域幅用法の効率とメッセージ処理の効率の間のバランスをとるのを試みました。 一般に、私たちは、IDPR-特殊情報によって消費されたリンク帯域幅を最小にするためにIDPR情報のコンパクトな表現を選びました。 しかしながら、また、私たちは、メッセージ処理(いつも、最小のリンク帯域幅用法をもたらすというわけではない)を促進するためにIDPR情報を組織化しました。
To limit link bandwidth usage, we currently use fixed-length identifier fields in IDPR messages; domains, virtual gateways, policy gateways, and route servers are all represented by fixed-length identifiers. To simplify message processing, we currently align fields containing an even number of bytes on even-byte boundaries within a message. In the future, if the Internet adopts the use of super domains, we will offer hierarchical, variable-length identifier fields in an updated version of IDPR.
リンク帯域幅用法を制限するために、私たちは現在、IDPRメッセージで固定長識別子分野を使用します。 ドメイン、仮想のゲートウェイ、方針ゲートウェイ、およびルートサーバは固定長識別子によってすべて表されます。 メッセージ処理を簡素化するために、私たちは現在、メッセージの中に偶数バイト境界のバイトの偶数を含む分野を並べます。 将来、インターネットが最高のドメインの使用を採用するなら、私たちはIDPRのアップデートされたバージョンの階層的で、可変長の識別子野原を提供するつもりです。
The header of each CMTP message contains the following information:
それぞれのCMTPメッセージのヘッダーは以下の情報を含んでいます:
Steenstrup [Page 24] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[24ページ]RFC1479IDPRは1993年7月に議定書を作ります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VERSION | PRT | MSG | DPR | DMS | I/A TYP |
+---------------+-------+-------+-------+-------+---------------+
| SOURCE AD | SOURCE ENT |
+-------------------------------+-------------------------------+
| TRANS ID |
+---------------------------------------------------------------+
| TIMESTAMP |
+-------------------------------+-------------------------------+
| LENGTH | message specific |
+-------------------------------+-------------------------------+
| DATAGRAM AD | DATAGRAM ENT |
+-------------------------------+-------------------------------+
| INFORM |
+---------------------------------------------------------------+
| INT/AUTH |
| |
+---------------------------------------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| PRT| エムエスジー| DPR| DMS| I/A TYP| +---------------+-------+-------+-------+-------+---------------+ | ADの出典を明示してください。| ソースENT| +-------------------------------+-------------------------------+ | 移-ID| +---------------------------------------------------------------+ | タイムスタンプ| +-------------------------------+-------------------------------+ | 長さ| メッセージ特有です。| +-------------------------------+-------------------------------+ | データグラム、西暦| データグラムENT| +-------------------------------+-------------------------------+ | 知らせてください。| +---------------------------------------------------------------+ | INT/AUTH| | | +---------------------------------------------------------------+
VERSION
(8 bits) Version number for IDPR control messages, currently
equal to 1.
IDPRのバージョン(8ビット)バージョン番号は現在1と等しいメッセージを制御します。
PRT (4 bits) Numeric identifier for the control message transport
protocol, equal to 0 for CMTP.
CMTPに、0と等しい規制メッセージトランスポート・プロトコルのためのPRT(4ビット)の数値識別子。
MSG (4 bits) Numeric identifier for the CMTP message type,equal to 0
for a DATAGRAM, 1 for an ACK, and 2 for a NAK.
CMTPメッセージタイプ、データグラムのための0への同輩、ACKのための1、およびNAKのための2のためのMSG(4ビット)の数値識別子。
DPR (4 bits) Numeric identifier for the original DATAGRAM's IDPR
protocol type.
DPR(4ビット)のオリジナルのデータグラムのIDPRプロトコルタイプにおける数値の識別子。
DMS (4 bits) Numeric identifier for the original DATAGRAM's IDPR
message type.
DMS(4ビット)のオリジナルのデータグラムのIDPRメッセージタイプにおける数値の識別子。
I/A TYP (8 bits) Numeric identifier for the integrity/authentication
scheme used. CMTP requires the use of an
integrity/authentication scheme; this value must not be set
equal to 0, indicating no integrity/authentication in use.
使用される保全/認証体系のためのI/A TYP(8ビット)の数値識別子。 CMTPは保全/認証体系の使用を必要とします。 使用中のどんな保全/認証も示さないで、この値は0と等しいセットであるはずがありません。
SOURCE AD (16 bits) Numeric identifier for the domain containing the
IDPR entity that generated the message.
メッセージを生成したIDPR実体を含むドメインのためのSOURCE AD(16ビット)の数値識別子。
SOURCE ENT (16 bits) Numeric identifier for the IDPR entity that
generated the message.
メッセージを生成したIDPR実体のためのSOURCE ENT(16ビット)の数値識別子。
Steenstrup [Page 25] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[25ページ]RFC1479IDPRは1993年7月に議定書を作ります。
TRANSACTION ID (32 bits) Local transaction identifier assigned by the
IDPR entity that generated the original DATAGRAM.
オリジナルのデータグラムを生成したIDPR実体によって割り当てられたTRANSACTION ID(32ビット)のローカルのトランザクション識別子。
TIMESTAMP (32 bits) Number of seconds elapsed since 1 January 1970
0:00 GMT.
1970年1月1日のグリニッジ標準時0時0分以来TIMESTAMP(32ビット)秒数は経過しました。
LENGTH (16 bits) Length of the entire IDPR control message, including
the CMTP header, in bytes.
バイトでCMTPヘッダーを含む全体のIDPRコントロールメッセージのLENGTH(16ビット)の長さ。
message specific (16 bits) Dependent upon CMTP message type.
CMTPメッセージタイプのメッセージの特定(16ビット)の扶養家族。
For DATAGRAM and ACK messages:
データグラムとACKメッセージのために:
RESERVED
(16 bits) Reserved for future use and currently set
equal to 0.
未来への予約されたRESERVED(16ビット)は0に同輩を使用して、現在、設定します。
For NAK messages:
NAKメッセージのために:
ERR TYP (8 bits) Numeric identifier for the type of CMTP
validation failure encountered. Validation failures
include the following types:
ERR TYP(8ビット)の失敗が遭遇したCMTP合法化のタイプにおける数値の識別子。 合法化失敗は以下のタイプを含んでいます:
1. Unrecognized IDPR control message version number.
1. 認識されていないIDPRはメッセージバージョン番号を制御します。
2. Unrecognized CMTP message type.
2. 認識されていないCMTPメッセージタイプ。
3. Unrecognized integrity/authentication scheme.
3. 認識されていない保全/認証体系。
4. Unacceptable integrity/authentication scheme.
4. 容認できない保全/認証体系。
5. Unable to locate key using source domain.
5. ソースドメインを使用することでキーの場所を見つけることができません。
6. Incorrect integrity/authentication value.
6. 不正確な保全/認証値。
7. Incorrect message length.
7. 不正確なメッセージ長。
8. Message timestamp out of range.
8. 範囲からのメッセージタイムスタンプ。
9. Unrecognized IDPR protocol designated for the
enclosed control message.
9. 認識されていないIDPRは同封のコントロールメッセージのために指定されていた状態で議定書を作ります。
Steenstrup [Page 26] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[26ページ]RFC1479IDPRは1993年7月に議定書を作ります。
ERR INFO (8 bits) CMTP supplies the following additional
information for the designated types of validation
failures:
ERR INFO(8ビット)CMTPは指定されたタイプの合法化失敗のための以下の追加情報を提供します:
Type 1:
Acceptable IDPR control message version number.
タイプ1: 許容できるIDPRはメッセージバージョン番号を制御します。
Types 3 and 4: Acceptable integrity/authentication
type.
タイプ3と4: 許容できる保全/認証タイプ。
DATAGRAM AD
(16 bits) Numeric identifier for the domain containing the IDPR
entity that generated the original DATAGRAM. Present only in
ACK and NAK messages.
オリジナルのデータグラムを生成したIDPR実体を含むドメインのためのデータグラムのAD(16ビット)の数値識別子。 ACKとNAKだけにメッセージを提示してください。
DATAGRAM ENT (16 bits) Numeric identifier for the IDPR entity that
generated the original DATAGRAM. Present only in ACK and NAK
messages.
オリジナルのデータグラムを生成したIDPR実体のためのDATAGRAM ENT(16ビット)の数値識別子。 ACKとNAKだけにメッセージを提示してください。
INFORM (optional,variable) Information to be interpreted by the IDPR
protocol that issued the original DATAGRAM. Present only in ACK
messages and dependent on the original DATAGRAM's IDPR protocol
type.
オリジナルのデータグラムを発行したIDPRプロトコルによって解釈されるべきINFORM(任意で、可変)の情報。 オリジナルのデータグラムのIDPRプロトコルタイプの上にACKだけにメッセージと扶養家族を提示してください。
INT/AUTH (variable) Computed integrity/authentication value,
dependent on the type of integrity/authentication scheme used.
INT/AUTH(可変)は使用される保全/認証体系のタイプに依存する保全/認証値を計算しました。
3. Virtual Gateway Protocol
3. 仮想のゲートウェイプロトコル
Every policy gateway within a domain participates in gathering information about connectivity within and between virtual gateways of which it is a member and in distributing this information to other virtual gateways in its domain. We refer to these functions collectively as the Virtual Gateway Protocol (VGP).
ドメインの中のあらゆる方針ゲートウェイがゲートウェイとそれがメンバーである仮想のゲートウェイの間の接続性の周りと、そして、ドメインで他の仮想のゲートウェイにこの情報を分配することで集会情報に参加します。 私たちはVirtualゲートウェイプロトコル(VGP)とこれらの機能をまとめて呼びます。
The information collected through VGP has both local and global significance for IDPR. Virtual gateway connectivity information, distributed to policy gateways within a single domain, aids those policy gateways in selecting routes across and between virtual gateways connecting their domain to adjacent domains. Inter-domain connectivity information, distributed throughout an internetwork in routing information messages, aids route servers in constructing feasible policy routes.
VGPを通して集められた情報は地方のものとIDPRのための同様にグローバルな意味を持っています。 単一領域の中の方針ゲートウェイに分配された仮想のゲートウェイ接続性情報はゲートウェイの向こう側の隣接しているドメインにそれらのドメインをつなげる仮想のゲートウェイの間のルートを選択する際にそれらの方針ゲートウェイを支援します。 相互ドメイン接続性情報であって、ルーティング情報メッセージのインターネットワーク中で分配されていて、援助は可能な方針ルートを構成する際にサーバを発送します。
Provided that a domain contains simple virtual gateway and transit policy configurations, one need only implement a small subset of the VGP functions. The connectivity among policy gateways within a virtual gateway and the heterogeneity of transit policies within a
ドメインが簡単な仮想のゲートウェイと運送保険証券構成を含んでいれば、1つはVGP機能の小さい部分集合を実装するだけでよいです。 仮想のゲートウェイの中の方針ゲートウェイの中の接続性とaの中の運送保険証券の異種性
Steenstrup [Page 27] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[27ページ]RFC1479IDPRは1993年7月に議定書を作ります。
domain determine which VGP functions must be implemented, as we explain toward the end of this section.
ドメインは、私たちがこのセクションの端に向かって説明するようにどのVGP機能を実装しなければならないかを決定します。
3.1. Message Scope
3.1. メッセージ範囲
Policy gateways generate VGP messages containing information about perceived changes in virtual gateway connectivity and distribute these messages to other policy gateways within the same domain and within the same virtual gateway. We classify VGP messages into three distinct categories: "pair-PG", "intra-VG", and "inter-VG", depending upon the scope of message distribution.
方針ゲートウェイは、仮想のゲートウェイの接続性における知覚された変化の情報を含むメッセージをVGPに生成して、同じドメインと、そして、同じ仮想のゲートウェイの中の他の方針ゲートウェイにこれらのメッセージを分配します。 私たちはVGPメッセージを3つの異なったカテゴリに分類します: 「組未成年者不適当映画」、「イントラ-VG」、およびメッセージの振分けの範囲による「相互VG。」
Policy gateways use CMTP for reliable transport of VGP messages. The issuing policy gateway must communicate to CMTP the maximum number of transmissions per VGP message, vgp_ret, and the interval between VGP message retransmissions, vgp_int microseconds. The recipient policy gateway must determine VGP message acceptability; conditions of acceptability depend on the type of VGP message, as we describe below.
方針ゲートウェイはVGPメッセージの信頼できる輸送にCMTPを使用します。 発行している方針ゲートウェイはVGPメッセージ「再-トランスミッション」(vgp_intマイクロセカンド)のVGPメッセージあたりのトランスミッション、_が浸水させるvgp、および間隔の最大数をCMTPに伝えなければなりません。 受取人方針ゲートウェイはVGPメッセージの受容性を決定しなければなりません。 私たちが以下で説明するように受容性の状態はVGPメッセージのタイプに頼っています。
Policy gateways store, act upon, and in the case of inter-VG messages, forward the information contained in acceptable VGP messages. VGP messages that pass the CMTP validation checks but fail a specific VGP message acceptability check are considered to be unacceptable and are hence discarded by recipient policy gateways. A policy gateway that receives an unacceptable VGP message also logs the event for network management.
方針ゲートウェイ店(場合と相互VGメッセージの場合における行為)は許容できるVGPメッセージに含まれた情報を転送します。 CMTP合法化チェックを通過しますが、特定のVGPメッセージ受容性チェックに失敗するVGPメッセージが、容認できないと考えられて、したがって、受取人方針ゲートウェイによって捨てられます。 また、容認できないVGPメッセージを受け取る方針ゲートウェイはネットワークマネージメントのためにイベントを登録します。
3.1.1. Pair-PG Messages
3.1.1. 組未成年者不適当映画メッセージ
Pair-PG message communication occurs between the two members of a pair of adjacent, peer, or neighbor policy gateways. With IDPR, the only pair-PG messages are those periodically generated by the up/down protocol and used to monitor mutual reachability between policy gateways.
組未成年者不適当映画メッセージ通信は1組の隣接している同輩、または隣人方針ゲートウェイの2個の部材の間に現れます。 IDPRと共に、唯一の組未成年者不適当映画メッセージが定期的に上がるか下がることによって方針ゲートウェイの間の互いの可到達性をモニターするのにおいてプロトコルの、そして、中古の生成されたものです。
A pair-PG message is "acceptable" if:
組未成年者不適当映画メッセージが「許容できる」、:
- It passes the CMTP validation checks.
- それはCMTP合法化チェックを通過します。
- Its timestamp is less than vgp_old (300) seconds behind the
recipient's internal clock time.
- タイムスタンプは受取人の内部クロック時間の(300)秒後ろで古いvgp_より少ないです。
- Its destination policy gateway identifier coincides with the
identifier of the recipient policy gateway.
- 目的地方針ゲートウェイ識別子は受取人方針ゲートウェイに関する識別子と一致しています。
- Its source policy gateway identifier coincides with the identifier
of a policy gateway configured for the recipient's domain or
- または方針ゲートウェイに関する識別子が受取人のドメインに構成にされているのでソース方針ゲートウェイ識別子が一致する。
Steenstrup [Page 28] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[28ページ]RFC1479IDPRは1993年7月に議定書を作ります。
associated virtual gateway.
関連仮想のゲートウェイ。
3.1.2. Intra-VG Messages
3.1.2. イントラ-VGメッセージ
Intra-VG message communication occurs between one policy gateway and all of its peers. Whenever a policy gateway discovers that its connectivity to an adjacent or neighbor policy gateway has changed, it issues an intra-VG message indicating the connectivity change to all of its reachable peers. Whenever a policy gateway detects that a previously unreachable peer is now reachable, it issues, to that peer, intra-VG messages indicating connectivity to adjacent and neighbor policy gateways. If the issuing policy gateway fails to receive an analogous intra-VG message from the newly reachable peer within twice the configured VGP retransmission interval, vgp_int microseconds, it actively requests the intra-VG message from that peer. These message exchanges ensure that peers maintain a consistent view of each others' connectivity to adjacent and neighbor policy gateways.
イントラ-VGメッセージ通信は同輩の1方針門とすべての間に現れます。 方針ゲートウェイが、隣接するか隣人方針ゲートウェイへの接続性が変化したと発見するときはいつも、それは届いている同輩のすべてへの接続性変化を示すイントラ-VGメッセージを発行します。 方針ゲートウェイがそれを検出するときはいつも、以前に手の届かない同輩は現在届いています、とそれがその同輩(隣接しているのと隣人方針ゲートウェイに接続性を示すイントラ-VGメッセージ)に発行します。 発行している方針ゲートウェイが失敗するなら、構成されたVGP再送信間隔の2倍中の新たに届いている同輩、vgp_intマイクロセカンドから類似のイントラ-VGメッセージを受け取るために、それはその同輩からイントラ-VGメッセージを活発に要求します。 これらの交換処理は、同輩が、それぞれの一貫した視点が他のものの接続性であることを隣接しているのと隣人方針ゲートウェイに支持するのを確実にします。
An intra-VG message is "acceptable" if:
イントラ-VGメッセージが「許容できる」、:
- It passes the CMTP validation checks.
- それはCMTP合法化チェックを通過します。
- Its timestamp is less than vgp_old (300) seconds behind the
recipient's internal clock time.
- タイムスタンプは受取人の内部クロック時間の(300)秒後ろで古いvgp_より少ないです。
- Its virtual gateway identifier coincides with that of a virtual
gateway configured for the recipient's domain.
- 仮想のゲートウェイのものが受取人のドメインに構成にされているので、仮想のゲートウェイ識別子は一致します。
3.1.3. Inter-VG Messages
3.1.3. 相互VGメッセージ
Inter-VG message communication occurs between one policy gateway and all of its neighbors. Whenever the lowest-numbered operational policy gateway in a set of mutually reachable peers discovers that its virtual gateway's connectivity to the adjacent domain or to another virtual gateway has changed, it issues an inter-VG message indicating the connectivity change to all of its neighbors. Specifically, the policy gateway distributes an inter-VG message to a "VG representative" policy gateway (see section 3.1.4 below) in each virtual gateway in the domain. Each VG representative in turn propagates the inter-VG message to each of its peers.
相互VGメッセージ通信は隣人の1方針門とすべての間に現れます。 1セットの互いに届いている同輩の最も低く番号付の運用政策ゲートウェイが、隣接しているドメイン、または、仮想のもう1つの門への仮想のゲートウェイの接続性が変化したと発見するときはいつも、それは隣人のすべてへの接続性変化を示す相互VGメッセージを発行します。 明確に、方針ゲートウェイはそのドメインのそれぞれの仮想のゲートウェイで「VG代表」方針ゲートウェイに相互VGメッセージを分配します(セクション3.1.4未満を見ます)。 それぞれのVG代表は順番に相互VGメッセージを同輩各人に伝播します。
Whenever the lowest-numbered operational policy gateway in a set of mutually peers detects that one or more previously unreachable peers are now reachable, it issues, to the lowest-numbered operational policy gateway in all other virtual gateways, requests for inter-VG information indicating connectivity to adjacent domains and to other virtual gateways. The recipient policy gateways return the requested
いつ、最も低く番号付の運用政策ゲートウェイ、互いにセットされたaでは、同輩がそれを検出するか、または以前により手の届かない同輩は現在届いています、と発行します、他のすべての仮想のゲートウェイの最も低く番号付の運用政策ゲートウェイに、隣接しているドメインと、そして、他の仮想のゲートウェイに接続性を示す相互VG情報に関する要求。 受取人方針ゲートウェイは要求を返します。
Steenstrup [Page 29] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[29ページ]RFC1479IDPRは1993年7月に議定書を作ります。
inter-VG messages to the issuing policy gateway, which in turn distributes the messages to the newly reachable peers. These message exchanges ensure that virtual gateways maintain a consistent view of each others' connectivity, while consuming minimal domain resources in distributing connectivity information.
発行している方針ゲートウェイへの相互VGメッセージ。(順番に、それは、新たに届いている同輩にメッセージを分配します)。 これらの交換処理は、接続性情報を分配する際に最小領域リソースを消費している間、仮想のゲートウェイが、それぞれの一貫した視点が他のものの接続性であることを支持するのを確実にします。
An inter-VG message contains information about the entire virtual gateway, not just about the issuing policy gateway. Thus, when virtual gateway connectivity changes happen in rapid succession, recipients of the resultant inter-VG messages should be able to determine the most recent message and that message must contain the current virtual gateway connectivity information. To ensure that the connectivity information distributed is consistent and unambiguous, we designate a single policy gateway, namely the lowest-numbered operational peer, for generating and distributing inter-VG messages. It is a simple procedure for a set of mutually reachable peers to determine the lowest-numbered member, as we describe in section 3.2 below.
相互VGメッセージはほとんど発行している方針ゲートウェイではなく、全体の仮想のゲートウェイの情報を含んでいます。 仮想のゲートウェイ接続性変化が矢つぎばやに起こるとき、したがって、結果の相互VGメッセージの受取人は、最新のメッセージとそのメッセージが現在の仮想のゲートウェイ接続性情報を含まなければならないことを決定できるべきです。 情報が分配した接続性が確実に一貫していて明白になるようにするために、私たちは1方針門、すなわち、最も低く番号付の操作上の同輩を任命します、相互VGメッセージを発生して、分配するために。 1セットの互いに届いている同輩が最も低く番号付のメンバーを決心するのは、簡単な手順です、私たちが下のセクション3.2で説明するように。
To understand why a single member of a virtual gateway must issue inter-VG messages, consider the following example. Suppose that two peers in a virtual gateway each detect a different connectivity change and generate separate inter-VG messages. Recipients of these messages may not be able to determine which message is more recent if policy gateway internal clocks are not perfectly synchronized. Moreover, even if the clocks were perfectly synchronized, and hence message recency could be consistently determined, it is possible for each peer to issue its inter-VG message before receiving current information from the other. As a result, neither inter-VG message contains the correct connectivity from the perspective of the virtual gateway. However, these problems are eliminated if all inter-VG messages are generated by a single peer within a virtual gateway, in particular the lowest-numbered operational policy gateway.
仮想のゲートウェイの独身の部材がなぜ相互VGメッセージを発行しなければならないかを理解するには、以下の例を考えてください。 仮想のゲートウェイの2人の同輩がそれぞれ異なった接続性変化を検出して、別々の相互VGメッセージを発生させると仮定してください。 これらのメッセージの受取人は、方針ゲートウェイ内部クロックが完全に連動しないならどちらのメッセージが、より最近であるかを決定できないかもしれません。 そのうえ、時計が完全に連動し、したがって、メッセージ新鮮が一貫して決定できても、もう片方から現行情報を受け取る前に各同輩が相互VGメッセージを発行するのは、可能です。 その結果、どちらの相互VGメッセージも仮想のゲートウェイの見解からの正しい接続性を含んでいません。 しかしながら、すべての相互VGメッセージは仮想のゲートウェイの中の独身の同輩、特に最も低く番号付の運用政策ゲートウェイによって発生させられるなら、これらの問題が解決されます。
An inter-VG message is "acceptable" if:
相互VGメッセージが「許容できる」、:
- It passes the CMTP validation checks.
- それはCMTP合法化チェックを通過します。
- Its timestamp is less than vgp_old (300) seconds behind the
recipient's internal clock time.
- タイムスタンプは受取人の内部クロック時間の(300)秒後ろで古いvgp_より少ないです。
- Its virtual gateway identifier coincides with that of a virtual
gateway configured for the recipient's domain.
- 仮想のゲートウェイのものが受取人のドメインに構成にされているので、仮想のゲートウェイ識別子は一致します。
- Its source policy gateway identifier represents the lowest numbered
operational member of the issuing virtual gateway, reachable from
the recipient.
- ソース方針ゲートウェイ識別子は発行の仮想のゲートウェイの最も低い番号付の操作上の部材の代理をします、受取人から、届きます。
Steenstrup [Page 30] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[30ページ]RFC1479IDPRは1993年7月に議定書を作ります。
Distribution of intra-VG messages among peers often triggers generation and distribution of inter-VG messages among virtual gateways. Usually, the lowest-numbered operational policy gateway in a virtual gateway generates and distributes an inter-VG message immediately after detecting a change in virtual gateway connectivity, through receipt or generation of an intra-VG message. However, if this policy gateway is also waiting for an intra-VG message from a newly reachable peer, it does not immediately generate and distribute the inter-VG message.
同輩の中のイントラ-VGメッセージの分配は仮想のゲートウェイの中でしばしば相互VGメッセージの生成と分配の引き金となります。 通常、変化を検出する直後、仮想のゲートウェイの最も低く番号付の運用政策ゲートウェイは、仮想のゲートウェイの接続性で相互VGメッセージを発生して、分配します、イントラ-VGメッセージの領収書か時代で。 しかしながら、また、この方針ゲートウェイが新たに届いている同輩からのイントラ-VGメッセージを待っているなら、それは、すぐに、相互VGメッセージを発生して、分配しません。
Waiting for intra-VG messages enables the lowest-numbered operational policy gateway in a virtual gateway to gather the most recent connectivity information for inclusion in the inter-VG message. However, under unusual circumstances, the policy gateway may fail to receive an intra-VG message from a newly reachable peer, even after actively requesting such a message. To accommodate this case, VGP uses an upper bound of four times the configured retransmission interval, vgp_int microseconds, on the amount of time to wait before generating and distributing an inter-VG message, when receipt of an intra-VG message is pending.
イントラ-VGメッセージを待つのは、仮想のゲートウェイの最も低く番号付の運用政策ゲートウェイが相互VGメッセージでの包含のための最新の接続性情報を集めるのを可能にします。 しかしながら、珍しい状況で、方針ゲートウェイは新たに届いている同輩からイントラ-VGメッセージを受け取らないかもしれません、活発にそのようなメッセージを要求さえした後にさえ。 本件に対応するのに、VGPは構成された再送信間隔の4回の上限を使用します、vgp_intマイクロセカンド、相互VGメッセージを発生して、分配する前に待つ時間に。(その時、イントラ-VGメッセージの領収書は未定です)。
3.1.4. VG Representatives
3.1.4. VG代表
When distributing an inter-VG message, the issuing policy gateway selects as recipients one neighbor, the VG Representative, from each virtual gateway in the domain. To be selected as a VG representative, a policy gateway must be reachable from the issuing policy gateway via intra-domain routing. The issuing policy gateway gives preference to neighbors that are members of more than one virtual gateway. Such a neighbor acts as a VG representative for all virtual gateways of which it is a member and restricts inter-VG message distribution as follows: any policy gateway that is a peer in more than one of the represented virtual gateways receives at most one copy of the inter-VG message. This message distribution strategy minimizes the number of message copies required for disseminating inter-VG information.
相互VGメッセージを分配するとき、発行している方針ゲートウェイは受取人として1人の隣人を選定します、VG代表、そのドメインのそれぞれの仮想のゲートウェイから。 VG代表として選択されるために、方針ゲートウェイは発行している方針ゲートウェイからイントラドメインルーティングで届いていなければなりません。 発行している方針ゲートウェイは仮想の1つ以上の門以上の部材である隣人に優先を与えます。 そのような隣人はそれがメンバーであり、相互VGメッセージの振分けを制限するすべての仮想のゲートウェイへのVG代表として以下の通りに務めます: 表された仮想のゲートウェイの1つ以上の同輩であるどんな方針ゲートウェイも相互VGメッセージのほとんどのコピー1部で受信されます。 このメッセージの振分け戦略は相互VG情報を広めるのに必要であるメッセージコピーの数を最小にします。
3.2. Up/Down Protocol
3.2. /下にプロトコルに
Directly-connected adjacent policy gateways execute the Up/Down Protocol to determine mutual reachability. Pairs of peer or neighbor policy gateways can determine mutual reachability through information provided by the intra-domain routing procedure or through execution of the up/down protocol. In general, we do not recommend implementing the up/down protocol between each pair of policy gateways in a domain, as it results in O(n**2) (where n is the number of policy gateways within the domain) communications complexity. However, if the intra-domain routing procedure is slow to detect
直接接続された隣接している方針ゲートウェイは、互いの可到達性を決定するためにUp/下にプロトコルを実行します。 同輩か隣人方針ゲートウェイのペアは、情報を通した互いの可到達性がイントラドメインルーティング手順か上がるか下がることの実行を通してプロトコルを提供したことを決定できます。 一般に、私たちは上がるか下がるのがドメインのそれぞれの組の方針ゲートウェイの間で議定書の中で述べる実行を推薦しません、O(n**2)(nがドメインの中の方針ゲートウェイの数であるところ)コミュニケーションの複雑さをもたらしている間。 しかしながら、イントラドメインであるなら、ルーティング手順は検出するのが遅いです。
Steenstrup [Page 31] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[31ページ]RFC1479IDPRは1993年7月に議定書を作ります。
connectivity changes or is unable to report reachability at the IDPR entity level, the reachability information obtained through the up/down protocol may well be worth the extra communications cost. In the remainder of this section, we decribe the up/down protocol from the perspective of adjacent policy gateways, but we note that the identical protocol can be applied to peer and neighbor policy gateways as well.
接続性が変化するか、またはIDPR実体レベルで可到達性を報告できない、可到達性情報は価値がたぶん余分なコミュニケーション費用であっただろうなら上がるか下がることを通してプロトコルを得ました。 このセクションの残りでは、隣接している方針ゲートウェイの見解から上/下にプロトコルをdecribeしますが、私たちは、じっと見て、また、方針ゲートウェイを近所付き合いさせるように同じプロトコルを適用できることに注意します。
The up/down protocol determines whether the direct connection between adjacent policy gateways is acceptable for data traffic transport. A direct connection is presumed to be "down" (unacceptable for data traffic transport) until the up/down protocol declares it to be "up" (acceptable for data traffic transport). We say that a virtual gateway is "up" if there exists at least one pair of adjacent policy gateways whose direct connection is acceptable for data traffic transport, and that a virtual gateway is "down" if there exists no such pair of adjacent policy gateways.
上がるデータ通信量輸送において、隣接している方針ゲートウェイの間のダイレクト接続が許容できるか否かに関係なく、/下にプロトコルが決定する。 ダイレクト接続はあえて上がるか下がるのに“down"であって(データ通信量輸送に、容認できない)、プロトコルが、それが“up"であると宣言するという(データ通信量輸送において、許容できる)ことです。 私たちはデータ通信量輸送において、ダイレクト接続が許容できる少なくとも1組の隣接している方針ゲートウェイが存在しているなら仮想のゲートウェイが“up"であり、隣接している方針ゲートウェイの何かそのような組が存在していないなら仮想のゲートウェイが“down"であると言います。
When executing the up/down protocol, policy gateways exchange UP/DOWN messages every ud_per (1) second. All policy gateways use the same default period of ud_per initially and then negotiate a preferred period through exchange of UP/DOWN messages. A policy gateway reports its desired value for ud_per within its UP/DOWN messages. It then chooses the larger of its desired value and that of the adjacent policy gateway as the period for exchanging subsequent UP/DOWN messages. Policy gateways also exchange, in UP/DOWN messages, information about the identity of their respective domain components. This information assists the policy gateways in selecting routes across virtual gateways to partitioned domains.
実行するとき、上がるか下がるのが議定書を作って、方針ゲートウェイはあらゆる1(1)あたりのud_単位で2番目に、UP/DOWNメッセージを交換します。 すべての方針ゲートウェイが、初めは単位でud_の同じデフォルトの期間を費やして、次に、UP/DOWNメッセージの交換を通して都合のよい期間を交渉します。 方針ゲートウェイがUP/DOWNメッセージの中でud_のための目標値を報告する単位。 そして、その後のUP/DOWNを交換するための期間が通信するようにそれは隣接している方針ゲートウェイの目標値とものについて、より大きいのを選びます。 また、方針ゲートウェイはUP/DOWNメッセージでそれらのそれぞれのドメインコンポーネントのアイデンティティの情報を交換します。 この情報は仕切られたドメインへの仮想のゲートウェイの向こう側にルートを選択するのに方針ゲートウェイを助けます。
Each UP/DOWN message is transported using CMTP and hence is covered by the CMTP validation checks. However, unlike other IDPR control messages, UP/DOWN messages do not require reliable transport. Specifically, the up/down protocol requires only a single transmission per UP/DOWN message and never directs CMTP to return an ACK. As pair-PG messages, UP/DOWN messages are acceptable under the conditions described in section 3.1.1.
それぞれのUP/DOWNメッセージは、CMTPを使用することで輸送されて、したがって、CMTP合法化チェックでカバーされています。 しかしながら、他のIDPRコントロールメッセージと異なって、UP/DOWNメッセージは信頼できる輸送を必要としません。 プロトコルは、明確に、上がるか下がるのが、ACKを返すようCMTPに決して指示するだけではないのを必要とします。 組未成年者不適当映画メッセージとして、UP/DOWNメッセージはセクション3.1.1で説明された状態の下で許容できます。
Each policy gateway assesses the state of its direct connection, to the adjacent policy gateway, by counting the number of acceptable UP/DOWN messages received within a set of consecutive periods. A policy gateway communicates its perception of the state of the direct connection through its UP/DOWN messages. Initially, a policy gateway indicates the down state in each of its UP/DOWN messages. Only when the direct connection appears to be up from its perspective does a policy gateway indicate the up state in its UP/DOWN messages.
それぞれの方針ゲートウェイはダイレクト接続の状態を評価します、隣接している方針ゲートウェイに、連続した期間のセットの中に受け取られた許容できるUP/DOWNメッセージの数を数えることによって。 方針ゲートウェイはUP/DOWNメッセージを通したダイレクト接続の状態の認知を伝えます。 初めは、方針ゲートウェイはそれぞれに関するUP/DOWNメッセージで下に状態を示します。 ダイレクト接続が、見解から上がるように見えるときだけ、方針ゲートウェイは、UP/DOWNメッセージで上がるのが述べるのを示します。
A policy gateway can begin to transport data traffic over a direct
方針ゲートウェイはaの上でデータ通信量をダイレクトに輸送し始めることができます。
Steenstrup [Page 32] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[32ページ]RFC1479IDPRは1993年7月に議定書を作ります。
connection only if both of the following conditions are true:
接続は以下の条件の両方である場合にだけ本当です:
- The policy gateway receives from the adjacent policy gateway at
least j acceptable UP/DOWN messages within the last m consecutive
periods. From the recipient policy gateway's perspective, this
event up. Hence, the recipient policy gateway indicates the up
state in its subsequent UP/DOWN messages.
- 方針ゲートウェイは最後のm連続した期間以内に少なくとも隣接している方針ゲートウェイからj許容できるUP/DOWNメッセージを受け取ります。 受取人方針ゲートウェイの見解、この出来事によって、上がります。 したがって、受取人方針ゲートウェイは、上がるのがその後のUP/DOWNにメッセージを述べるのを示します。
- The UP/DOWN message most recently received from the adjacent policy
gateway indicates the up state, signifying that the adjacent policy
gateway considers the direct connection to be up.
- 上がるのが述べる隣接している方針ゲートウェイから受け取られたごく最近が、示すUP/DOWNメッセージ、隣接している方針ゲートウェイが上がるようにダイレクト接続であると考える意味。
A policy gateway must cease to transport data traffic over a direct connection whenever either of the following conditions is true:
方針ゲートウェイは、以下の条件のどちらかが本当であるときはいつも、ダイレクト接続の上でデータ通信量を輸送するのをやめなければなりません:
- The policy gateway receives from the adjacent policy gateway at
most acceptable UP/DOWN messages within the last n consecutive
periods.
- 方針ゲートウェイはここn連続した期間以内にほとんどの許容できるUP/DOWNメッセージにおける隣接している方針ゲートウェイから受信されます。
- The UP/DOWN message most recently received from the adjacent policy
gateway indicates the down state, signifying that the adjacent
policy gateway considers the direct connection to be down.
- ごく最近隣接している方針ゲートウェイから受け取られたUP/DOWNメッセージは下に状態を示します、ダイレクト接続がゲートウェイが考える隣接している方針であることがダウンするのを意味して。
From the recipient policy gateway's perspective, either of these events constitutes a state transition of the direct connection from up to down. Hence, the policy gateway indicates the down state in its subsequent UP/DOWN messages.
受取人方針ゲートウェイの見解から、これらの出来事のどちらかが倒す上からのダイレクト接続の状態遷移を構成します。 したがって、方針ゲートウェイはその後のUP/DOWNメッセージで下に状態を示します。
3.3. Implementation
3.3. 実現
We recommend implementing the up/down protocol using a sliding window. Each window slot indicates the UP/DOWN message activity during a given period, containing either a "hit" for receipt of an acceptable UP/DOWN message or a "miss" for failure to receive an acceptable UP/DOWN message. In addition to the sliding window, the implementation should include a tally of hits recorded during the current period and a tally of misses recorded over the current window.
私たちは上がるか下がるのが使用することで議定書の中で述べる実行に引窓を推薦します。 各ウィンドウ・スロットは与えられた期間、UP/DOWNメッセージ活動を示します、許容できるUP/DOWNメッセージの領収書のための「ヒット」か許容できるUP/DOWNメッセージを受け取らないことのための「ミス」を含んでいて。 引窓に加えて、実現は当期の間に記録されたヒットの合札と現在の窓の上に記録されたミスの合札を含むべきです。
When the direct connection moves to the down state, the initial values of the up/down protocol parameters must be set as follows:
下への移動が述べるダイレクト接続、上がるか下がることの初期の値が議定書を作るとき、以下の通りパラメタを設定しなければなりません:
- The sliding window size is equal to m.
- 引窓サイズはmと等しいです。
- Each window slot contains a miss.
- 各ウィンドウ・スロットはミスを含んでいます。
- The current period hit tally is equal to 0.
- 当期ヒット合札は0と等しいです。
Steenstrup [Page 33] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[33ページ]RFC1479IDPRは1993年7月に議定書を作ります。
- The current window miss tally is equal to m.
- 現在のウィンドウミス合札はmと等しいです。
When the direct connection moves to the up state, the initial values of the up/down protocol parameters must be set as follows:
ダイレクト接続が上の状態に移るとき、以下の通り上/下にプロトコルパラメタの初期の値を設定しなければなりません:
- The sliding window size is equal to n.
- 引窓サイズはnと等しいです。
- Each window slot contains a hit.
- 各ウィンドウ・スロットはヒットを含んでいます。
- The current period hit tally is equal to 0.
- 当期ヒット合札は0と等しいです。
- The current window miss tally is equal to 0.
- 現在のウィンドウミス合札は0と等しいです。
At the conclusion of each period, a policy gateway computes the miss tally and determines whether there has been a state transition of the direct connection to the adjacent policy gateway. In the down state, a miss tally of no more than m - j signals a transition to the up state. In the up state, a miss tally of no less than n - k signals a transition to the down state.
それぞれの期間の結論のときに、方針ゲートウェイは、ミス合札を計算して、ダイレクト接続の状態遷移があったかどうか隣接している方針ゲートウェイに決定します。 下であるのが述べるコネ、mだけのミス合札--jは上の状態への変遷に合図します。 上の状態では、少なくともn--kのミス合札は下に状態への変遷を示します。
Computing the correct miss tally involves several steps. First, the policy gateway prepares to slide the window by one slot so that the oldest slot disappears, making room for the newest slot. However, before sliding the window, the policy gateway checks the contents of the oldest window slot. If this slot contains a miss, the policy gateway decrements the miss tally by 1, as this slot is no longer part of the current window.
正しいミス合札を計算すると、数ステップはかかわります。 まず最初に方針ゲートウェイが、1つのスロットのそばで窓を滑らせるのを準備するので、最も古いスロットは見えなくなります、最も新しいスロットに場所を開けて。 しかしながら、窓を滑らせる前に、方針ゲートウェイは最も古いウィンドウ・スロットのコンテンツをチェックします。 このスロットがミスを含んでいるなら、方針ゲートウェイはミス合札を1つ減少させます、このスロットがもう現在の窓の一部でないので。
After sliding the window, the policy gateway determines the proper contents. If the hit tally for the current period equals 0, the policy gateway records a miss for the newest slot and increments the miss tally by 1. Otherwise, if the hit tally for the current period is greater than 0, the policy gateway records a hit for the newest slot and decrements the hit tally by 1. Moreover, the policy gateway applies any remaining hits to slots containing misses, beginning with the newest and progressing to the oldest such slot. For each such slot containing a miss, the policy gateway records a hit in that slot and decrements both the hit and miss tallies by 1, as the hit cancels out a miss. The policy gateway continues to apply each remaining hit tallied to any slot containing a miss, until either all such hits are exhausted or all such slots are accounted for. Before beginning the next up/down period, the policy gateway resets the hit tally to 0.
窓を滑らせた後に、方針ゲートウェイは適切なコンテンツを決定します。 当期のヒット合札が0と等しいなら、方針ゲートウェイは、最も新しいスロットにミスを記録して、ミス合札を1つ増加します。 さもなければ、当期のヒット合札が0以上であるなら、方針ゲートウェイは、最も新しいスロットにヒットを記録して、ヒット合札を1つ減少させます。 そのうえ、方針ゲートウェイはどんな残っているヒットもミスを含むスロットに適用します、最も新しいことで始まって、そのような最も古いスロットに進んでいて。 ミスを含むそのような各スロットに関しては、方針ゲートウェイは、そのスロットにヒットを記録して、ヒットとミス合札の両方を1つ減少させます、ヒットがミスを相殺するとき。 方針ゲートウェイは、ミスを含むどんなスロットにも記録されたそれぞれの残っているヒットを適用し続けています、そのようなすべてのヒットが疲れ果てているか、またはそのようなすべてのスロットが説明されるまで。 /下に期間に次を始める前に、方針ゲートウェイはヒット合札を0にリセットします。
Although we expect the hit tally, within any given period, to be no greater than 1, we do anticipate the occasional period in which a policy gateway receives more than one UP/DOWN message from an adjacent policy gateway. The most common reasons for this occurrence are message delay and clock drift. When an UP/DOWN message is
どんな与えられた期間以内にもヒット合札を予想しますが、1以下に、なるように、私たちは隣接している方針ゲートウェイから方針ゲートウェイが1UP/DOWNのメッセージより受信される時々の期間を予期します。 この発生の最も一般的な理由は、メッセージ遅延と時計ドリフトです。 UP/DOWNメッセージはいつですか。
Steenstrup [Page 34] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[34ページ]RFC1479IDPRは1993年7月に議定書を作ります。
delayed, the receiving policy gateway observes a miss in one period followed by two hits in the next period, one of which cancels the previous miss. However, excess hits remaining in the tally after miss cancellation indicate a problem, such as clock drift. Thus, whenever a policy gateway accumulates excess hits, it logs the event for network management.
遅らせられます、受信方針ゲートウェイはそれの1つが前のミスを中止する次の期間の2つのヒットで、ある期間のミスが続いたのを観測します。 しかしながら、ミスキャンセルの後に合札に残っている余分なヒットは時計ドリフトなどの問題を示します。 したがって、方針ゲートウェイが余分なヒットを蓄積するときはいつも、それはネットワークマネージメントのために出来事を登録します。
When clock drift occurs between two adjacent policy gateways, it causes the period of one policy gateway to grow with respect to the period of the other policy gateway. Let p(X) be the period for PG X, let p(Y) be the period for PG Y, and let g and h be the smallest positive integers such that g * p(X) = h * p(Y). Suppose that p(Y) > p(X) because of clock drift. In this case, PG X observes g - h misses in g consecutive periods, while PG Y observes g - h surplus hits in h consecutive periods. As long as (g - h)/g < (n - k)/n and (g - h)/g < or = (m - j)/m, the clock drift itself will not cause the direct connection to enter or remain in the down state.
時計ドリフトが隣接している2方針門の間に起こると、それで、1方針門の期間はもう片方の方針ゲートウェイの期間に関して成長します。 gとhが最もわずかな正の整数であることを未成年者不適当映画Xのためにp(X)が期間であることをさせてください、そして、未成年者不適当映画Yのためにp(Y)が期間であることをさせてください、そして、g*p(X)がh*p(Y)と等しいように、させてください。 時計ドリフトのためにそのp(Y)>がp(X)であると仮定してください。 この場合、未成年者不適当映画Xはgを観測します--hはg連続した時代に消えます、未成年者不適当映画Yはgを観測しますが--h連続した期間のh余分ヒット。 (g--h)/g<(n--k)/nと(g--h)/g<か=(m--j)/mと同じくらい長くて、時計ドリフト自体は、ダイレクト接続が下に州に入るか、または留まることを引き起こさないでしょう。
3.4. Policy Gateway Connectivity
3.4. 方針ゲートウェイの接続性
Policy gateways collect connectivity information through the intra- domain routing procedure and through VGP, and they distribute connectivity changes through VGP in both intra-VG messages to peers and inter-VG messages to neighbors. Locally, this connectivity information assists policy gateways in selecting routes, not only across a virtual gateway to an adjacent domain but also across a domain between two virtual gateways. Moreover, changes in connectivity between domains are distributed, in routing information messages, to route servers throughout an internetwork.
方針ゲートウェイはイントラドメインルーティング手順を通してVGPを通して接続性情報を集めます、そして、それらは同輩へのイントラ-VGメッセージと相互VGメッセージの両方でVGPを通して接続性変化を隣人に分配します。 局所的に、この接続性情報は隣接しているドメインへの仮想のゲートウェイの向こう側に選択するだけではなく、仮想の2つの門の間のドメインの向こう側にもルートを選択するのに方針ゲートウェイを助けます。 そのうえ、ドメインの間の接続性における変化は、インターネットワーク中でサーバを発送するためにルーティング情報メッセージで分配されます。
3.4.1. Within a Virtual Gateway
3.4.1. 仮想のゲートウェイの中で
Each policy gateway within a virtual gateway constantly monitors its connectivity to all adjacent and to all peer policy gateways. To determine the state of its direct connection to an adjacent policy gateway, a policy gateway uses reachability information supplied by the up/down protocol. To determine the state of its intra-domain routes to a peer policy gateway, a policy gateway uses reachability information supplied by either the intra-domain routing procedure or the up/down protocol.
仮想のゲートウェイの中のそれぞれの方針ゲートウェイは絶えずゲートウェイとすべての同輩方針ゲートウェイへのすべてに接続性をモニターします。 隣接している方針ゲートウェイ、方針ゲートウェイにダイレクト接続の状態を決定するために、可到達性情報が上がるか下がるのから供給した用途は議定書を作ります。 同輩方針ゲートウェイ、方針ゲートウェイにイントラドメインルートの状態を決定するために、可到達性情報がイントラドメインルーティング手順か上がるか下がどちらかから供給した用途は議定書を作ります。
A policy gateway generates a PG CONNECT message whenever either of the following conditions is true:
以下の条件のどちらかが本当であるときはいつも、方針ゲートウェイはPG CONNECTメッセージを生成します:
- The policy gateway detects a change, in state or in adjacent
domain component, associated with its direct connection to an
adjacent policy gateway. In this case, the policy gateway
distributes a copy of the message to each peer reachable via
- 方針ゲートウェイは状態か隣接しているドメインコンポーネントにおける変化を検出します、隣接している方針ゲートウェイとのダイレクト接続に関連しています。 を通してこの場合方針ゲートウェイが各同輩にとって、届いているメッセージのコピーを分配する。
Steenstrup [Page 35] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[35ページ]RFC1479IDPRは1993年7月に議定書を作ります。
intra-domain routing.
イントラドメインルーティング。
- The policy gateway detects that a previously unreachable peer is
now reachable. In this case, the policy gateway distributes a
copy of the message to the newly reachable peer.
- 方針ゲートウェイはそれを検出します。以前に手の届かない同輩は現在、届いています。 この場合、方針ゲートウェイは新たに届いている同輩にメッセージのコピーを分配します。
A PG CONNECT message is an intra-VG message that includes information about each adjacent policy gateway directly connected to the issuing policy gateway. Specifically, the PG CONNECT message contains the adjacent policy gateway's identifier, status (reachable or unreachable), and domain component identifier. If a PG CONNECT message contains a "request", each peer that receives the message responds to the sender with its own PG CONNECT message.
PG CONNECTメッセージは直接発行している方針ゲートウェイに接続されたそれぞれの隣接している方針ゲートウェイの情報を含んでいるイントラ-VGメッセージです。 明確に、PG CONNECTメッセージは隣接している方針ゲートウェイの識別子、状態(届いているか手の届かない)、およびドメインコンポーネント識別子を含んでいます。 PG CONNECTメッセージが「要求」を含んでいるなら、メッセージを受け取る各同輩がそれ自身のPG CONNECTメッセージで送付者に応じます。
All mutually reachable peers monitor policy gateway connectivity within their virtual gateway, through the up/down protocol, the intra-domain routing procedure, and the exchange of PG CONNECT messages. Within a given virtual gateway, each constituent policy gateway maintains the following information about each configured adjacent policy gateway:
すべての互いに届いている同輩が彼らの仮想のゲートウェイの中で方針ゲートウェイの接続性をモニターして、上がることを通して、/はPG CONNECTメッセージのプロトコル、イントラドメインルーティング手順、および交換より倒します。 与えられた仮想のゲートウェイの中では、それぞれの構成している方針ゲートウェイはそれぞれの構成された隣接している方針ゲートウェイの以下の情報を保守します:
- The identifier for the adjacent policy gateway.
- 隣接している方針ゲートウェイのための識別子。
- The status of the adjacent policy gateway: reachable/unreachable,
directly connected/not directly connected.
- 隣接している方針ゲートウェイの状態: 届くか、または手が届かなくて、直接接続された/は直接接続しませんでした。
- The local exit interfaces used to reach the adjacent policy
gateway, provided it is reachable.
- それが届くなら、地方の出口インタフェースは以前はよく隣接している方針ゲートウェイに達していました。
- The identifier for the adjacent policy gateway's domain component.
- 隣接している方針ゲートウェイのドメインコンポーネントのための識別子。
- The set of peers to which the adjacent policy gateway is
directly-connected.
- 同輩のセットは直接隣接している方針ゲートウェイがどれであるかと接続しました。
Hence, all mutually reachable peers can detect changes in connectivity across the virtual gateway to adjacent domain components.
したがって、すべての互いに届いている同輩が隣接しているドメインコンポーネントへの仮想のゲートウェイの向こう側に接続性における変化を検出できます。
When the lowest-numbered operational peer policy gateway within a virtual gateway detects a change in the set of adjacent domain components reachable through direct connections across the given virtual gateway, it generates a VGCONNECT message and distributes a copy to a VG representative in all other virtual gateways connected to its domain. A VG CONNECT message is an inter-VG message that includes information about each peer's connectivity across the given virtual gateway. Specifically, the VG CONNECT message contains, for each peer, its identifier and the identifiers of the domain components reachable through its direct connections to adjacent
仮想のゲートウェイの中の最も低く番号付の操作上の同輩方針ゲートウェイが与えられた仮想のゲートウェイの向こう側のダイレクト接続で届いている隣接しているドメインコンポーネントのセットにおける変化を検出するとき、それは、ドメインに接続された他のすべての仮想のゲートウェイのVG代表にVGCONNECTメッセージを生成して、コピーを分配します。 VG CONNECTメッセージは与えられた仮想のゲートウェイの向こう側に各同輩の接続性の情報を含んでいる相互VGメッセージです。 明確に、VG CONNECTメッセージは隣接していた状態で各同輩のための識別子とダイレクト接続で届いているドメインコンポーネントに関する識別子を含んでいます。
Steenstrup [Page 36] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[36ページ]RFC1479IDPRは1993年7月に議定書を作ります。
policy gateways. Moreover, the VG CONNECT message gives each recipient enough information to determine the state, up or down, of the issuing virtual gateway.
方針ゲートウェイ。 そのうえ、VG CONNECTメッセージは発行の仮想のゲートウェイの上がっているか下がっている州を決定できるくらいの情報を各受取人に教えます。
The issuing policy gateway, namely the lowest-numbered operational peer, may have to wait up to four times vgp_int microseconds after detecting the connectivity change, before generating and distributing the VGCONNECT message, as described in section 3.1.3. Each recipient VG representative in turn distributes a copy of the VG CONNECT message to each of its peers reachable via intra-domain routing. If a VG CONNECT message contains a "request", then in each recipient virtual gateway, the lowest-numbered operational peer that receives the message responds to the original sender with its own VGCONNECT message.
接続性変化を検出した後に発行している方針ゲートウェイ(すなわち、最も低く番号付の操作上の同輩)は最大4回のvgp_intマイクロセカンドを待たなければならないかもしれません、VGCONNECTメッセージを生成して、分配する前に、セクション3.1.3で説明されるように。 それぞれの受取人VG代表は順番にVG CONNECTメッセージのコピーをイントラドメインルーティングで届いた状態で同輩各人に分配します。 VG CONNECTメッセージが「要求」を含んでいるなら、それぞれの受取人の仮想のゲートウェイでは、メッセージを受け取る最も低く番号付の操作上の同輩はそれ自身のVGCONNECTメッセージで元の送り主に応じます。
3.4.2. Between Virtual Gateways
3.4.2. 仮想のゲートウェイの間で
At present, we expect transit policies to be uniform over all intra- domain routes between any pair of policy gateways within a domain. However, when tariffed qualities of service become prevalent offerings for intra-domain routing, we can no longer expect uniformity of transit policies throughout a domain. To monitor the transit policies supported on intra-domain routes between virtual gateways requires both a policy-sensitive intra-domain routing procedure and a VGP exchange of policy information between neighbor policy gateways.
現在のところ、私たちは、ドメインの中のどんな組の方針ゲートウェイの間のすべてのイントラドメインルートに関して運送保険証券が一定であると予想します。 しかしながら、tariffedサービスの品質がイントラドメインルーティングのための一般的な提供になると、私たちはもうドメイン中で運送保険証券の一様性を期待できません。 仮想のゲートウェイの間のイントラドメインルートの上でサポートされた運送保険証券をモニターするのは方針敏感なイントラドメインルーティング手順と隣人方針ゲートウェイの間の方針情報のVGP交換の両方を必要とします。
Each policy gateway within a domain constantly monitors its connectivity to all peer and neighbor policy gateways, including the transit policies supported on intra-domain routes to these policy gateways. To determine the state of its intra-domain connection to a peer or neighbor policy gateway, a policy gateway uses reachability information supplied by either the intra-domain routing procedure or the up/down protocol. To determine the transit policies supported on intra-domain routes to a peer or neighbor policy gateway, a policy gateway uses policy-sensitive reachability information supplied by the intra-domain routing procedure. We note that when transit policies are uniform over a domain, reachability and policy-sensitive reachability are equivalent.
ドメインの中のそれぞれの方針ゲートウェイは絶えずすべての同輩と隣人方針ゲートウェイに接続性をモニターします、イントラドメインルートの上でこれらの方針ゲートウェイにサポートされた運送保険証券を含んでいて。 同輩か隣人方針ゲートウェイとのイントラドメイン接続、方針ゲートウェイの状態を決定するために、可到達性情報がイントラドメインルーティング手順か上がるか下がどちらかから供給した用途は議定書を作ります。 イントラドメインルートの上で同輩か隣人方針ゲートウェイにサポートされた運送保険証券を決定するために、方針ゲートウェイはイントラドメインルーティング手順で提供された方針機密の可到達性情報を使用します。 私たちは、運送保険証券がドメインの上で一定であるときに、可到達性と方針敏感な可到達性が同等であることに注意します。
Within a virtual gateway, each constituent policy gateway maintains the following information about each configured peer and neighbor policy gateway:
仮想のゲートウェイの中では、それぞれの構成している方針ゲートウェイはそれぞれの構成された同輩と隣人方針ゲートウェイの以下の情報を保守します:
- The identifier for the peer or neighbor policy gateway.
- 同輩か隣人方針ゲートウェイのための識別子。
- The identifiers corresponding to the transit policies configured to
be supported by intra-domain routes to the peer or neighbor policy
- 運送保険証券に対応する識別子はイントラドメインルートで同輩か隣人方針にサポートされるのを構成されました。
Steenstrup [Page 37] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[37ページ]RFC1479IDPRは1993年7月に議定書を作ります。
gateway.
ゲートウェイ。
- According to each transit policy, the status of the peer or
neighbor policy gateway: reachable/unreachable.
- 各運送保険証券、同輩か隣人方針ゲートウェイの状態に従って: 届くか、または手が届きません。
- For each transit policy, the local exit interfaces used to reach
the peer or neighbor policy gateway, provided it is reachable.
- 各運送保険証券のために、地方の出口インタフェースは以前はよく同輩か隣人方針ゲートウェイに届いていました、それが届くなら。
- The identifiers for the adjacent domain components reachable
through direct connections from the peer or neighbor policy
gateway, obtained through VG CONNECT messages.
- 同輩か隣人方針ゲートウェイからのダイレクト接続で届いていて、VG CONNECTメッセージを通して得られた隣接しているドメインコンポーネントのための識別子。
Using this information, a policy gateway can detect changes in its connectivity to an adjoining domain component, with respect to a given transit policy and through a given neighbor. Moreover, combining the information obtained for all neighbors within a given virtual gateway, the policy gateway can detect changes in its connectivity, with respect to a given transit policy, to that virtual gateway and to adjoining domain components reachable through that virtual gateway.
この情報を使用して、方針ゲートウェイは与えられた運送保険証券と、そして、隣接しているドメインコンポーネントへの接続性と、与えられた隣人を通して変化を検出できます。 そのうえ、与えられた仮想のゲートウェイの中のすべての隣人に得られた情報を結合することでの方針ゲートウェイは接続性における変化を検出できます、その仮想のゲートウェイと、そして、その仮想のゲートウェイを通して届いているドメインコンポーネントに隣接していることへの与えられた運送保険証券に関して。
All policy gateways mutually reachable via intra-domain routes supporting a configured transit policy need not exchange information about perceived changes in connectivity, with respect to the given transit policy. In this case, each policy gateway can infer another's policy-sensitive reachability to a third, through mutual intra-domain reachability information provided by the intra-domain routing procedure. However, whenever two or more policy gateways are no longer mutually reachable with respect to a given transit policy, these policy gateways can no longer infer each other's reachability to other policy gateways, with respect to that transit policy. In this case, these policy gateways must exchange explicit information about changes in connectivity to other policy gateways, with respect to that transit policy.
構成された運送保険証券をサポートするイントラドメインルートを通して互いに届いているすべての方針ゲートウェイが接続性における知覚された変化に関して情報交換しなければならないというわけではありません、与えられた運送保険証券に関して。 この場合、それぞれの方針ゲートウェイは別のものの方針敏感な可到達性を3分の1に推論できます、イントラドメインルーティング手順で提供された互いのイントラドメイン可到達性情報を通して。 しかしながら、2方針門以上がもう与えられた運送保険証券に関して互いに届いていないときはいつも、これらの方針ゲートウェイはもう他の方針ゲートウェイに互いの可到達性を推論できません、その運送保険証券に関して。 この場合、これらの方針ゲートウェイは接続性における変化に関する明示的な情報を他の方針ゲートウェイと交換しなければなりません、その運送保険証券に関して。
A policy gateway generates a PG POLICY message whenever either of the following conditions is true:
以下の条件のどちらかが本当であるときはいつも、方針ゲートウェイはPG POLICYメッセージを生成します:
- The policy gateway detects a change in its connectivity to another
virtual gateway, with respect to a configured transit policy, or to
an adjoining domain component reachable through that virtual
gateway. In this case, the policy gateway distributes a copy of
the message to each peer reachable via intra-domain routing but not
currently reachable via any intra-domain routes of the given
transit policy.
- 方針ゲートウェイは構成された運送保険証券に関する仮想のもう1つの門、または、その仮想のゲートウェイを通して届いている隣接しているドメインコンポーネントに接続性における変化を検出します。 この場合、方針ゲートウェイはイントラドメインルーティングを通して届いていますが、現在与えられた運送保険証券のどんなイントラドメインルートを通しても届いていないそれぞれの同輩にメッセージのコピーを分配します。
- The policy gateway detects that a previously unreachable peer is
reachable. In this case, the policy gateway distributes a copy of
- 方針ゲートウェイはそれを検出します。以前に手の届かない同輩は届いています。 この場合ゲートウェイがコピーを分配する方針
Steenstrup [Page 38] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[38ページ]RFC1479IDPRは1993年7月に議定書を作ります。
the message to the newly reachable peer.
新たに届いている同輩へのメッセージ。
A PG POLICY message is an intra-VG message that includes information about each configured transit policy and each virtual gateway configured to be reachable from the issuing policy gateway via intra-domain routes of the given transit policy. Specifically, the PGPOLICY message contains, for each configured transit policy:
PG POLICYメッセージはそれぞれの構成された運送保険証券の情報を含んでいるイントラ-VGメッセージです、そして、それぞれの仮想のゲートウェイは発行している方針ゲートウェイから与えられた運送保険証券のイントラドメインルートで届くのを構成されました。 明確に、PGPOLICYメッセージはそれぞれの構成された運送保険証券のために以下を含んでいます。
- The identifier for the transit policy.
- 運送保険証券のための識別子。
- The identifiers for the virtual gateways associated with the given
transit policy and currently reachable, with respect to that
transit policy, from the issuing policy gateway.
- 発行している方針ゲートウェイから与えられた運送保険証券に関連していて、現在その運送保険証券に関して届いている仮想のゲートウェイのための識別子。
- The identifiers for the domain components reachable from and
adjacent to the members of the given virtual gateways.
- 部材と与えられた仮想のゲートウェイの部材に隣接して届いているドメインコンポーネントのための識別子。
If a PG POLICY message contains a "request", each peer that receives the message responds to the original sender with its own PG POLICY message.
PG POLICYメッセージが「要求」を含んでいるなら、メッセージを受け取る各同輩がそれ自身のPG POLICYメッセージで元の送り主に応じます。
In addition to connectivity between itself and its neighbors, each policy gateway also monitors the connectivity, between domain components adjacent to its virtual gateway and domain components adjacent to other virtual gateways, through its domain and with respect to the configured transit policies. For each member of each of its virtual gateways, a policy gateway monitors:
また、それ自体とその隣人の間の接続性に加えて、それぞれの方針ゲートウェイは接続性をモニターします、仮想のゲートウェイに隣接したドメインコンポーネントとドメインと他の仮想のゲートウェイに隣接した構成された運送保険証券に関するドメインコンポーネントの間で。 それぞれの仮想のゲートウェイの各部材に関しては、方針ゲートウェイは以下をモニターします。
- The set of adjacent domain components currently reachable
through direct connections across the given virtual gateway. The
policy gateway obtains this information through PG CONNECT messages
from reachable peers and through UP/DOWN messages from adjacent
policy gateways.
- 現在与えられた仮想のゲートウェイの向こう側のダイレクト接続で届いている隣接しているドメインコンポーネントのセット。 方針ゲートウェイは届いている同輩からのPG CONNECTメッセージを通してUP/DOWNメッセージを通して隣接している方針ゲートウェイからこの情報を得ます。
- For each configured transit policy, the set of virtual gateways
currently reachable from the given virtual gateway with respect to
that transit policy and the set of adjoining domain components
currently reachable through direct connections across those virtual
gateways. The policy gateway obtains this information through PG
POLICY messages from peers, VG CONNECT messages from neighbors, and
the intra-domain routing procedure. Using this information, a
policy gateway can detect connectivity changes, through its domain
and with respect to a given transit policy, between adjoining
domain components.
- それぞれの構成された運送保険証券、現在その運送保険証券に関して与えられた仮想のゲートウェイから届いている仮想のゲートウェイのセット、および現在それらの仮想のゲートウェイの向こう側のダイレクト接続で届いているドメインコンポーネントに隣接するセットのために。 方針ゲートウェイはPG POLICYメッセージを通して同輩、隣人からのVG CONNECTメッセージ、およびイントラドメインルーティング手順からこの情報を得ます。 この情報を使用して、方針ゲートウェイはドメインと与えられた運送保険証券に関して接続性変化を検出できます、ドメインコンポーネントに隣接しているとき。
When the lowest-numbered operational policy gateway within a virtual gateway detects a change in the connectivity between a domain component adjacent to its virtual gateway and a domain component
仮想のゲートウェイの中の最も低く番号付の運用政策ゲートウェイが仮想のゲートウェイに隣接したドメインコンポーネントとドメインコンポーネントの間の接続性における変化を検出するとき
Steenstrup [Page 39] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[39ページ]RFC1479IDPRは1993年7月に議定書を作ります。
adjacent to another virtual gateway in its domain, with respect to a configured transit policy, it generates a VG POLICY message and distributes a copy to a VG representative in selected virtual gateways connected to its domain. In particular, the lowest-numbered operational policy gateway distributes a VG POLICY message to a VG representative in every other virtual gateway containing a member reachable via intra-domain routing but not currently reachable via any routes of the given transit policy. A VG POLICY message is an inter-VG message that includes information about the connectivity between domain components adjacent to the issuing virtual gateway and domain components adjacent to the other virtual gateways in the domain, with respect to configured transit policies. Specifically, the VG POLICY message contains, for each transit policy:
ドメインの仮想のもう1つの門に隣接して、構成された運送保険証券に関して、それは、ドメインに接続された選択された仮想のゲートウェイのVG代表にVG POLICYメッセージを生成して、コピーを分配します。 特に、最も低く番号付の運用政策ゲートウェイはイントラドメインルーティングを通して届いているメンバーを含む他のあらゆる仮想のゲートウェイで代表していますが、現在与えられた運送保険証券のどんなルートを通しても届いていないVGにVG POLICYメッセージを分配します。 VG POLICYメッセージは発行の仮想のゲートウェイとドメインコンポーネントに隣接してそのドメインの他の仮想のゲートウェイに隣接してドメインコンポーネントの間の接続性の情報を含んでいる相互VGメッセージです、構成された運送保険証券に関して。 明確に、VG POLICYメッセージは各運送保険証券のために以下を含んでいます。
- The identifier for the transit policy.
- 運送保険証券のための識別子。
- The identifiers for the virtual gateways associated with the given
transit policy and currently reachable, with respect to that
transit policy, from the issuing virtual gateway.
- 発行の仮想のゲートウェイから与えられた運送保険証券に関連していて、現在その運送保険証券に関して届いている仮想のゲートウェイのための識別子。
- The identifiers for the domain components reachable from and
adjacent to the members of the given virtual gateways.
- 部材と与えられた仮想のゲートウェイの部材に隣接して届いているドメインコンポーネントのための識別子。
The issuing policy gateway, namely the lowest-numbered operational peer, may have to wait up to four times vgp_int microseconds after detecting the connectivity change, before generating and distributing the VG POLICY message, as described in section 3.1.3. Each recipient VG representative in turn distributes a copy of the VG POLICY message to each of its peers reachable via intra-domain routing. If a VG POLICY message contains a "request", then in each recipient virtual gateway, the lowest-numbered operational peer that receives the message responds to the original sender with its own VG POLICY message.
接続性変化を検出した後に発行している方針ゲートウェイ(すなわち、最も低く番号付の操作上の同輩)は最大4回のvgp_intマイクロセカンドを待たなければならないかもしれません、VG POLICYメッセージを生成して、分配する前に、セクション3.1.3で説明されるように。 それぞれの受取人VG代表は順番にVG POLICYメッセージのコピーをイントラドメインルーティングで届いた状態で同輩各人に分配します。 VG POLICYメッセージが「要求」を含んでいるなら、それぞれの受取人の仮想のゲートウェイでは、メッセージを受け取る最も低く番号付の操作上の同輩はそれ自身のVG POLICYメッセージで元の送り主に応じます。
3.4.3. Communication Complexity
3.4.3. コミュニケーションの複雑さ
We offer an example, to provide an estimate of the number of VGP messages exchanged within a domain, AD X, after a detected change in policy gateway connectivity. Suppose that an adjacent domain, AD Y, partitions such that the partition is detectable through the exchange of UP/DOWN messages across a virtual gateway connecting AD X and AD Y. Let V be the number of virtual gateways in AD X. Suppose each virtual gateway contains P peer policy gateways, and no policy gateway is a member of multiple virtual gateways. Then, within AD X, the detected partition will result in the following VGP message exchanges:
私たちはドメインの中で交換されたVGPメッセージの数の見積りを提供するために例を提供します、AD X、検出された政策の方向転換ゲートウェイの接続性の後に。 隣接しているドメイン(AD Y)がパーティションがAD X.Supposeのそれぞれの仮想のゲートウェイが含む仮想のゲートウェイの数がP同輩方針ゲートウェイであったならAD XとAD Y.Let Vを接続しながら仮想のゲートウェイの向こう側にUP/DOWNメッセージの交換を通して検出可能であり、どんな方針ゲートウェイも複数の仮想のゲートウェイの部材でないようにものを仕切ると仮定してください。 次に、AD X中に、検出されたパーティションは以下のVGP交換処理をもたらすでしょう:
- P policy gateways each receive at most P-1 PG CONNECT messages.
- P方針ゲートウェイはほとんどのP-1 PG CONNECTメッセージでそれぞれ受信されます。
Steenstrup [Page 40] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[40ページ]RFC1479IDPRは1993年7月に議定書を作ります。
Each policy gateway detecting the adjacent domain partition
generates a PG CONNECT message and distributes it to each reachable
peer in the virtual gateway.
隣接しているドメインパーティションを検出するそれぞれの方針ゲートウェイが、仮想のゲートウェイのそれぞれの届いている同輩にPG CONNECTメッセージを生成して、それを分配します。
- P * (V-1) policy gateways each receive at most one VG CONNECT
message. The lowest-numbered operational policy gateway in the
virtual gateway detecting the partition of the adjacent domain
generates a VG CONNECT message and distributes it to a VG
representative in all other virtual gateways connected to the
domain. In turn, each VG representative distributes the VG CONNECT
message to each reachable peer within its virtual gateway.
- P*(V-1)方針ゲートウェイはそれぞれ1つのVG CONNECTメッセージを高々受け取ります。 隣接しているドメインのパーティションを検出する仮想のゲートウェイの最も低く番号付の運用政策ゲートウェイは、そのドメインに接続された他のすべての仮想のゲートウェイのVG代表にVG CONNECTメッセージを生成して、それを分配します。 順番に、それぞれのVG代表は仮想のゲートウェイの中のそれぞれの届いている同輩にVG CONNECTメッセージを分配します。
- P * (V-1) policy gateways each receive at most P-1 PG POLICY
messages, and only if the domain has more than a single uniform
transit policy. Each policy gateway in each virtual gateway
generates a PG POLICY message and distributes it to all reachable
peers not currently reachable with respect to the given transit
policy.
- ほとんどのP-1 PG POLICYメッセージとドメインではただ一つの一定の運送保険証券以上があるだけであるかどうかでP*(V-1)方針ゲートウェイはそれぞれ受信されます。 それぞれの仮想のゲートウェイのそれぞれの方針ゲートウェイは、現在与えられた運送保険証券に関して届いていないすべての届いている同輩にPG POLICYメッセージを生成して、それを分配します。
- P * V policy gateways each receive at most V-1 VG POLICY messages,
only if the domain has more than a single uniform transit policy.
The lowest-numbered operational policy gateway in each virtual
gateway generates a VG POLICY message and distributes it to a VG
representative in all other virtual gateways containing at least
one reachable member not currently reachable with respect to the
given transit policy. In turn, each VG representative distributes
a VG POLICY message to each peer within its virtual gateway.
- P*V方針ゲートウェイはほとんどのV-1 VG POLICYメッセージでそれぞれ受信されます、ドメインにただ一つの一定の運送保険証券以上がある場合にだけ。 それぞれの仮想のゲートウェイの最も低く番号付の運用政策ゲートウェイは、現在与えられた運送保険証券に関して届いていない少なくとも1人の届いているメンバーを含む他のすべての仮想のゲートウェイのVG代表にVG POLICYメッセージを生成して、それを分配します。 順番に、それぞれのVG代表は仮想のゲートウェイの中の各同輩にVG POLICYメッセージを分配します。
3.5. VGP Message Formats
3.5. VGPメッセージ・フォーマット
The virtual gateway protocol number is equal to 0. We describe the contents of each type of VGP message below.
仮想のゲートウェイプロトコル番号は0と等しいです。 私たちは以下のそれぞれのタイプに関するVGPメッセージのコンテンツについて説明します。
3.5.1. UP/DOWN
3.5.1. 上がるか、または下がっています。
The UP/DOWN message type is equal to 0.
UP/DOWNメッセージタイプは0に堪えます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRC CMP | DST AD |
+-------------------------------+---------------+---------------+
| DST PG | PERIOD | STATE |
+-------------------------------+---------------+---------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRC Cmp| DST西暦| +-------------------------------+---------------+---------------+ | DST未成年者不適当映画| 期間| 状態| +-------------------------------+---------------+---------------+
SRC CMP
(16 bits) Numeric identifier for the domain component containing
the issuing policy gateway.
発行している方針ゲートウェイを含むドメインコンポーネントのためのSRC CMP(16ビット)の数値識別子。
Steenstrup [Page 41] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[41ページ]RFC1479IDPRは1993年7月に議定書を作ります。
DST AD (16 bits) Numeric identifier for the destination domain.
目的地ドメインのためのDST AD(16ビット)の数値識別子。
DST PG (16 bits) Numeric identifier for the destination policy
gateway.
目的地方針ゲートウェイのためのDST PG(16ビット)の数値識別子。
PERIOD (8 bits) Length of the UP/DOWN message generation period, in
seconds.
秒の期間のUP/DOWNメッセージ世代のPERIOD(8ビット)の長さ。
STATE (8 bits) Perceived state (1 up, 0 down) of the direct
connection from the perspective of the issuing policy gateway,
contained in the right-most bit.
州(8ビット)は最も権利ビットに含まれた発行している方針ゲートウェイの見解からダイレクト接続の状態(1つの上、0はダウンする)を知覚しました。
3.5.2. PG CONNECT
3.5.2. 未成年者不適当映画は接続します。
The PG CONNECT message type is equal to 1. PG CONNECT messages are not required for any virtual gateway containing exactly two policy gateways.
PG CONNECTメッセージタイプは1に堪えます。 PG CONNECTメッセージはちょうど2方針門を含むどんな仮想のゲートウェイにも必要ではありません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADJ AD | VG | RQST |
+-------------------------------+---------------+---------------+
| NUM RCH | NUM UNRCH |
+-------------------------------+-------------------------------+
For each reachable adjacent policy gateway:
+-------------------------------+-------------------------------+
| ADJ PG | ADJ CMP |
+-------------------------------+-------------------------------+
For each unreachable adjacent policy gateway:
+-------------------------------+
| ADJ PG |
+-------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADJ西暦| VG| RQST| +-------------------------------+---------------+---------------+ | ヌムRCH| ヌムUNRCH| +-------------------------------+-------------------------------それぞれの届いている隣接している方針ゲートウェイへの+: +-------------------------------+-------------------------------+ | ADJ未成年者不適当映画| ADJ Cmp| +-------------------------------+-------------------------------それぞれの手の届かない隣接している方針ゲートウェイへの+: +-------------------------------+ | ADJ未成年者不適当映画| +-------------------------------+
ADJ AD
(16 bits) Numeric identifier for the adjacent domain.
隣接しているドメインのためのADJ AD(16ビット)の数値識別子。
VG (8 bits) Numeric identifier for the virtual gateway.
仮想のゲートウェイのためのVG(8ビット)の数値識別子。
RQST (8 bits) Request for a PG CONNECT message (1 request, 0 no
request) from each recipient peer, contained in the right-most
bit.
最も権利ビットに含まれたそれぞれの受取人同輩からのPG CONNECTメッセージ(1つの要求、いいえが要求する0)に関するRQST(8ビット)要求。
NUM RCH (16 bits) Number of adjacent policy gateways within the
virtual gateway, which are directly-connected to and currently
reachable from the issuing policy gateway.
仮想のゲートウェイの中の隣接している方針ゲートウェイのNUM RCH(16ビット)番号。(ゲートウェイは、発行している方針ゲートウェイから直接接続されていて現在、届いています)。
NUM UNRCH (16 bits) Number of adjacent policy gateways within the
隣接している方針ゲートウェイのNUM UNRCH(16ビット)番号、中
Steenstrup [Page 42] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[42ページ]RFC1479IDPRは1993年7月に議定書を作ります。
virtual gateway, which are directly-connected to but not
currently reachable from the issuing policy gateway.
仮想のゲートウェイ。(発行している方針ゲートウェイから直接接続されていますが、そのゲートウェイは現在、届いていません)。
ADJ PG (16 bits) Numeric identifier for a directly-connected adjacent
policy gateway.
直接接続された隣接している方針ゲートウェイのためのADJ PG(16ビット)の数値識別子。
ADJ CMP (16 bits) Numeric identifier for the domain component
containing the reachable, directly-connected adjacent policy
gateway.
届いていて、直接接続された隣接している方針ゲートウェイを含むドメインコンポーネントのためのADJ CMP(16ビット)の数値識別子。
3.5.3. PG POLICY
3.5.3. 未成年者不適当映画方針
The PG POLICY message type is equal to 2. PG POLICY messages are not required for any virtual gateway containing exactly two policy gateways or for any domain with a single uniform transit policy.
PG POLICYメッセージタイプは2に堪えます。 PG POLICYメッセージはちょうど2方針門を含むどんな仮想のゲートウェイかただ一つの一定の運送保険証券があるどんなドメインにも必要ではありません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADJ AD | VG | RQST |
+-------------------------------+---------------+---------------+
| NUM TP |
+-------------------------------+
For each transit policy associated with the virtual gateway:
+-------------------------------+-------------------------------+
| TP | NUM VG |
+-------------------------------+-------------------------------+
For each virtual gateway reachable via the transit policy:
+-------------------------------+---------------+---------------+
| ADJ AD | VG | UNUSED |
+-------------------------------+---------------+---------------+
| NUM CMP | ADJ CMP |
+-------------------------------+-------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADJ西暦| VG| RQST| +-------------------------------+---------------+---------------+ | ヌムTP| +-------------------------------各運送保険証券のための+は仮想のゲートウェイに関連づけました: +-------------------------------+-------------------------------+ | TP| ヌムVG| +-------------------------------+-------------------------------運送保険証券を通して届いているそれぞれの仮想のゲートウェイへの+: +-------------------------------+---------------+---------------+ | ADJ西暦| VG| 未使用| +-------------------------------+---------------+---------------+ | ヌムCmp| ADJ Cmp| +-------------------------------+-------------------------------+
ADJ AD
(16 bits) Numeric identifier for the adjacent domain.
隣接しているドメインのためのADJ AD(16ビット)の数値識別子。
VG (8 bits) Numeric identifier for the virtual gateway.
仮想のゲートウェイのためのVG(8ビット)の数値識別子。
RQST (8 bits) Request for a PG POLICY message (1 request, 0 no
request) from each recipient peer, contained in the right-most
bit.
最も権利ビットに含まれたそれぞれの受取人同輩からのPG POLICYメッセージ(1つの要求、いいえが要求する0)に関するRQST(8ビット)要求。
NUM TP (8 bits) Number of transit policies configured to include the
virtual gateway.
運送保険証券のNUM TP(8ビット)番号は仮想のゲートウェイを含んでいるのを構成されました。
TP (16 bits) Numeric identifier for a transit policy associated with
the virtual gateway.
仮想のゲートウェイに関連している運送保険証券のためのTP(16ビット)の数値識別子。
Steenstrup [Page 43] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[43ページ]RFC1479IDPRは1993年7月に議定書を作ります。
NUM VG (16 bits) Number of virtual gateways reachable from the
issuing policy gateway, via intra-domain routes supporting the
transit policy.
運送保険証券をサポートするイントラドメインルートを通して発行している方針ゲートウェイから届いている仮想のゲートウェイのNUM VG(16ビット)番号。
UNUSED (8 bits) Not currently used; must be set equal to 0.
現在使用されていないUNUSED(8ビット)。 0と等しい状態で設定しなければなりません。
NUM CMP (16 bits) Number of adjacent domain components reachable via
direct connections through the virtual gateway.
仮想のゲートウェイを通したダイレクト接続を通して届いている隣接しているドメインコンポーネントのNUM CMP(16ビット)番号。
ADJ CMP (16 bits) Numeric identifier for a reachable adjacent domain
component.
届いている隣接しているドメインコンポーネントのためのADJ CMP(16ビット)の数値識別子。
3.5.4. VG CONNECT
3.5.4. VGは接続します。
The VG CONNECT message type is equal to 3.
VG CONNECTメッセージタイプは3に堪えます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADJ AD | VG | RQST |
+-------------------------------+---------------+---------------+
| NUM PG |
+-------------------------------+
For each reach policy gateway in the virtual gateway:
+-------------------------------+-------------------------------+
| PG | NUM CMP |
+-------------------------------+-------------------------------+
| ADJ CMP |
+-------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADJ西暦| VG| RQST| +-------------------------------+---------------+---------------+ | ヌム未成年者不適当映画| +-------------------------------仮想のゲートウェイのそれぞれの範囲方針ゲートウェイへの+: +-------------------------------+-------------------------------+ | 未成年者不適当映画| ヌムCmp| +-------------------------------+-------------------------------+ | ADJ Cmp| +-------------------------------+
ADJ AD
(16 bits) Numeric identifier for the adjacent domain.
隣接しているドメインのためのADJ AD(16ビット)の数値識別子。
VG (8 bits) Numeric identifier for the virtual gateway.
仮想のゲートウェイのためのVG(8ビット)の数値識別子。
RQST (8 bits) Request for a VG CONNECT message (1 request, 0 no
request) from a recipient in each virtual gateway, contained in
the right-most bit.
最も権利ビットに含まれたそれぞれの仮想のゲートウェイの受取人からのVG CONNECTメッセージ(1つの要求、いいえが要求する0)に関するRQST(8ビット)要求。
NUM PG (16 bits) Number of mutually-reachable peer policy gateways in
the virtual gateway.
仮想のゲートウェイの互いに届いている同輩方針ゲートウェイのNUM PG(16ビット)番号。
PG (16 bits) Numeric identifier for a peer policy gateway.
同輩方針ゲートウェイのための未成年者不適当映画(16ビット)の数値識別子。
NUM CMP (16 bits) Number of components of the adjacent domain
reachable via direct connections from the policy gateway.
方針ゲートウェイからのダイレクト接続を通して届いている隣接しているドメインのコンポーネントのNUM CMP(16ビット)番号。
Steenstrup [Page 44] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[44ページ]RFC1479IDPRは1993年7月に議定書を作ります。
ADJ CMP (16 bits) Numeric identifier for a reachable adjacent domain
component.
届いている隣接しているドメインコンポーネントのためのADJ CMP(16ビット)の数値識別子。
3.5.5. VG POLICY
3.5.5. VG方針
The VG POLICY message type is equal to 4. VG POLICY messages are not required for any domain with a single uniform transit policy.
VG POLICYメッセージタイプは4に堪えます。 VG POLICYメッセージはただ一つの一定の運送保険証券でどんなドメインにも必要ではありません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADJ AD | VG | RQST |
+-------------------------------+---------------+---------------+
| NUM TP |
+-------------------------------+
For each transit policy associated with the virtual gateway:
+-------------------------------+-------------------------------+
| TP | NUM GRP |
+-------------------------------+-------------------------------+
For each virtual gateway group reachable via the transit policy:
+-------------------------------+-------------------------------+
| NUM VG | ADJ AD |
+---------------+---------------+-------------------------------+
| VG | UNUSED | NUM CMP |
+---------------+---------------+-------------------------------+
| ADJ CMP |
+-------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADJ西暦| VG| RQST| +-------------------------------+---------------+---------------+ | ヌムTP| +-------------------------------各運送保険証券のための+は仮想のゲートウェイに関連づけました: +-------------------------------+-------------------------------+ | TP| ヌムGRP| +-------------------------------+-------------------------------運送保険証券を通して届いているそれぞれの仮想のゲートウェイグループのための+: +-------------------------------+-------------------------------+ | ヌムVG| ADJ西暦| +---------------+---------------+-------------------------------+ | VG| 未使用| ヌムCmp| +---------------+---------------+-------------------------------+ | ADJ Cmp| +-------------------------------+
ADJ AD
(16 bits) Numeric identifier for the adjacent domain.
隣接しているドメインのためのADJ AD(16ビット)の数値識別子。
VG (8 bits) Numeric identifier for the virtual gateway.
仮想のゲートウェイのためのVG(8ビット)の数値識別子。
RQST (8 bits) Request for a VG POLICY message (1 request, 0 no
request) from a recipient in each virtual gateway, contained in
the right-most bit.
最も権利ビットに含まれたそれぞれの仮想のゲートウェイの受取人からのVG POLICYメッセージ(1つの要求、いいえが要求する0)に関するRQST(8ビット)要求。
NUM TP (16 bits) Number of transit policies configured to include the
virtual gateway.
運送保険証券のNUM TP(16ビット)番号は仮想のゲートウェイを含んでいるのを構成されました。
TP (16 bits) Numeric identifier for a transit policy associated with
the virtual gateway.
仮想のゲートウェイに関連している運送保険証券のためのTP(16ビット)の数値識別子。
NUM GRP (16 bits) Number of groups of virtual gateways, such that all
members in a group are reachable from the issuing virtual
gateway via intra-domain routes supporting the given transit
policy.
仮想のゲートウェイ(グループのすべてのメンバーが与えられた運送保険証券をサポートしながら発行の仮想のゲートウェイからイントラドメインルートで届いているようなもの)のグループのNUM GRP(16ビット)番号。
Steenstrup [Page 45] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[45ページ]RFC1479IDPRは1993年7月に議定書を作ります。
NUM VG (16 bits) Number of virtual gateways in a virtual gateway
group.
仮想のゲートウェイの仮想のゲートウェイのNUM VG(16ビット)番号は分類されます。
UNUSED (8 bits) Not currently used; must be set equal to 0.
現在使用されていないUNUSED(8ビット)。 0と等しい状態で設定しなければなりません。
NUM CMP (16 bits) Number of adjacent domain components reachable via
direct connections through the virtual gateway.
仮想のゲートウェイを通したダイレクト接続を通して届いている隣接しているドメインコンポーネントのNUM CMP(16ビット)番号。
ADJ CMP (16 bits) Numeric identifier for a reachable adjacent domain
component.
届いている隣接しているドメインコンポーネントのためのADJ CMP(16ビット)の数値識別子。
Normally, each VG POLICY message will contain a single virtual gateway group. However, if the issuing virtual gateway becomes partitioned such that peers are mutually reachable with respect to some transit policies but not others, virtual gateway groups may be necessary. For example, let PG X and PG Y be two peers in VG A which configured to support transit policies 1 and 2. Suppose that PG X and PG Y are reachable with respect to transit policy 1 but not with respect to transit policy 2. Furthermore, suppose that PG X can reach members of VG B via intra-domain routes of transit policy 2 and that PG Y can reach members of VG C via intra-domain routes of transit policy 2. Then the entry in the VG POLICY message issued by VG A will include, for transit policy 2, two groups of virtual gateways, one containing VG B and one containing VG C.
通常、それぞれのVG POLICYメッセージはただ一つの仮想のゲートウェイグループを含むでしょう。 しかしながら、発行の仮想のゲートウェイが仕切られるようになるなら、同輩が他のもの、仮想のゲートウェイグループではなく、いくつかの運送保険証券に関して互いに届いているようなものが必要であるかもしれません。 例えば、未成年者不適当映画Xと未成年者不適当映画Yが運送保険証券が1と2であるとサポートするのを構成したVG Aの2人の同輩であることをさせてください。 未成年者不適当映画Xと未成年者不適当映画Yが運送保険証券1に関して届いていると思いますが、運送保険証券2に関して思うというわけではなくなってください。 その上、運送保険証券2のイントラドメインルートで未成年者不適当映画XがVG Bのメンバーに届くことができて、運送保険証券2のイントラドメインルートで未成年者不適当映画YがVG Cのメンバーに届くことができると仮定してください。 そして、VG Aによって発行されたVG POLICYメッセージにおけるエントリーは仮想のゲートウェイのトランジット方針2、twoグループのためにVG Bを含む1つとVG Cを含む1つを含むでしょう。
3.5.6. Negative Acknowledgements
3.5.6. 否定的承認
When a policy gateway receives an unacceptable VGP message that passes the CMTP validation checks, it includes, in its CMTP ACK, an appropriate VGP negative acknowledgement. This information is placed in the INFORM field of the CMTP ACK (described previously in section 2.4); the numeric identifier for each type of VGP negative acknowledgement is contained in the left-most 8 bits of the INFORM field. Negative acknowledgements associated with VGP include the following types:
方針ゲートウェイがCMTP合法化チェックを通過する容認できないVGPメッセージを受け取るとき、それはCMTP ACKに適切なVGP否定的承認を含んでいます。 この情報はCMTP ACK(以前に、セクション2.4で説明される)のINFORM分野に置かれます。 それぞれのタイプのVGPの否定的承認のための数値識別子はINFORM分野の最も左の8ビットに含まれています。 VGPに関連している否定的承認は以下のタイプを含んでいます:
1. Unrecognized VGP message type. Numeric identifier for the
unrecognized message type (8 bits).
1. 認識されていないVGPメッセージタイプ。 認識されていないメッセージタイプ(8ビット)における数値の識別子。
2. Out-of-date VGP message.
2. 時代遅れなVGPメッセージ。
3. Unrecognized virtual gateway source. Numeric identifier for the
unrecognized virtual gateway including the adjacent domain
identifier (16 bits) and the local identifier (8 bits).
3. 認識されていない仮想のゲートウェイソース。 隣接しているドメイン識別子(16ビット)とローカルの識別子(8ビット)を含む認識されていない仮想のゲートウェイのための数値識別子。
Steenstrup [Page 46] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[46ページ]RFC1479IDPRは1993年7月に議定書を作ります。
4. Routing Information Distribution
4. 経路情報分配
Each domain participating in IDPR generates and distributes its routing information messages to route servers throughout an internetwork. IDPR routing information messages contain information about the transit policies in effect across the given domain and the virtual gateway connectivity to adjacent domains. Route servers in turn use IDPR routing information to generate policy routes between source and destination domains.
IDPRに参加する各ドメインが、インターネットワーク中でサーバを発送するルーティング情報メッセージを生成して、分配します。 事実上、IDPRルーティング情報メッセージは与えられたドメインと仮想のゲートウェイの接続性の向こう側に隣接しているドメインに運送保険証券の情報を保管しています。 ルートサーバは、ソースと目的地ドメインの間の方針ルートを生成するのに順番にIDPRルーティング情報を使用します。
There are three different procedures for distributing IDPR routing information:
IDPRルーティング情報を分配するための3つの異なった手順があります:
- The flooding protocol. In this case, a representative policy
gateway in each domain floods its routing information messages to
route servers in all other domains.
- 氾濫プロトコル。 この場合、各ドメインの代表している方針ゲートウェイは他のすべてのドメインでサーバを発送するルーティング情報メッセージをあふれさせます。
- Remote route server communication. In this case, a route server
distributes its domain's routing information messages to route
servers in specific destination domains, by encapsulating these
messages within IDPR data messages. Thus, a domain administrator
may control the distribution of the domain's routing information by
restricting routing information exchange with remote route servers.
Currently, routing information distribution restrictions are not
included in IDPR configuration information.
- リモートルートサーバコミュニケーション。 この場合、ルートサーバは特定の目的地ドメインでサーバを発送するドメインのルーティング情報メッセージを分配します、IDPRデータメッセージの中でこれらのメッセージをカプセル化することによって。 したがって、ドメイン管理者は、リモートルートサーバによるルーティング情報交換を制限することによって、ドメインのルーティング情報の分配を制御するかもしれません。 現在、ルーティング情報流通制限はIDPR設定情報に含まれていません。
- The route server query protocol. In this case, a policy gateway or
route server requests routing information from another route
server, which in turn responds with routing information from its
database. The route server query protocol may be used for quickly
updating the routing information maintained by a policy gateway
or route server that has just been connected or reconnected to an
internetwork. It may also be used to retrieve routing information
from domains that restrict distribution of their routing
information.
- ルートサーバ質問プロトコル。 この場合、方針ゲートウェイかルートサーバが情報が順番にデータベースからルーティングで応じる別のルートサーバからルーティング情報を要求します。 ルートサーバ質問プロトコルは、すぐにちょうどインターネットワークに接続されるか、または再接続された方針ゲートウェイかルートサーバによって保守されたルーティング情報をアップデートするのに使用されるかもしれません。 また、それは、それらのルーティング情報の分配を制限するドメインからのルーティング情報を検索するのに使用されるかもしれません。
In this section, we describe the flooding protocol only. In section 5, we describe the route server query protocol, and in section 5.2, we describe communication between route servers in separate domains.
このセクションで、私たちは氾濫プロトコルだけについて説明します。 セクション5で、私たちはルートサーバ質問プロトコルについて説明します、そして、セクション5.2で、別々のドメインのルートサーバのコミュニケーションについて説明します。
Policy gateways and route servers use CMTP for reliable transport of IDPR routing information messages flooded between peer, neighbor, and adjacent policy gateways and between those policy gateways and route servers. The issuing policy gateway must communicate to CMTP the maximum number of transmissions per routing information message, flood_ret, and the interval between routing information message retransmissions, flood_int microseconds. The recipient policy gateway or route server must determine routing information message
方針ゲートウェイとルートサーバはそれらの同輩と、隣人と、隣接している方針ゲートウェイと方針ゲートウェイとルートサーバの間で水につかっているIDPRルーティング情報メッセージの信頼できる輸送にCMTPを使用します。 発行している方針ゲートウェイはメッセージ、洪水_が浸水するというルーティング情報あたりのトランスミッションの最大数、およびルーティング情報メッセージ「再-トランスミッション」の間隔をCMTPに伝えなければなりません、洪水_intマイクロセカンド。 受取人方針ゲートウェイかルートサーバがルーティング情報メッセージを決定しなければなりません。
Steenstrup [Page 47] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[47ページ]RFC1479IDPRは1993年7月に議定書を作ります。
acceptability, as we describe in section 4.2.3 below.
私たちがセクション4.2.3未満で説明するような受容性。
4.1. AD Representatives
4.1. AD代表
We designate a single policy gateway, the "AD representative", for generating and distributing IDPR routing information about its domain, to ensure that the routing information distributed is consistent and unambiguous and to minimize the communication required for routing information distribution. There is usually only a single AD representative per domain, namely the lowest-numbered operational policy gateway in the domain. Within a domain, policy gateways need no explicit election procedure to determine the AD representative. Instead, all members of a set of policy gateways mutually reachable via intra-domain routes can agree on set membership and therefore on which member has the lowest number.
私たちは1方針門を指定して、情報が分配したルーティングが確実に一貫していて明白になるようにして、コミュニケーションを最小にするためにドメインのIDPRルーティング情報を生成して、分配するための「AD代表」がルーティング情報流通に必要です。 通常1ドメインあたり1人の独身のAD代表だけ、すなわち、最も低く番号付の運用政策ゲートウェイがそのドメインにあります。 ドメインの中では、方針ゲートウェイは、AD代表を決定するためにどんな明白な選挙手順も必要としません。 代わりに、イントラドメインルートを通して互いに届いている方針ゲートウェイの1セットのすべてのメンバーが、セット会員資格に同意できて、したがって、どのメンバーの上で最も下位の数を持っているか。
A partitioned domain has as many AD representatives as it does domain components. In fact, the numeric identifier for an AD representative is identical to the numeric identifier for a domain component. One cannot normally predict when and where a domain partition will occur, and thus any policy gateway within a domain may become an AD representative at any time. To prepare for the role of AD representative in the event of a domain partition, every policy gateway must continually monitor its domain's IDPR routing information, through VGP and through the intra-domain routing procedure.
ドメインコンポーネントをするとき、仕切られたドメインには、同じくらい多くのAD代表がいます。 事実上、AD代表にとっての数値の識別子はドメインコンポーネントのための数値識別子と同じです。 通常、人は、ドメインパーティションがいつ、どこで起こるかを予測できません、そして、その結果、ドメインの中のどんな方針ゲートウェイもいつでも、AD代表になるかもしれません。 ドメインパーティションの場合、AD代表の役割の用意をするために、あらゆる方針ゲートウェイがVGPを通してイントラドメインルーティング手順を通してドメインのIDPRルーティング情報を絶えずモニターしなければなりません。
4.2. Flooding Protocol
4.2. 氾濫プロトコル
An AD representative policy gateway uses unrestricted flooding among all domains to distribute its domain's IDPR routing information messages to route servers in an internetwork. There are two kinds of IDPR routing information messages issued by each AD representative: CONFIGURATION and DYNAMIC messages. Each CONFIGURATION message contains the transit policy information configured by the domain administrator, including for each transit policy, its identifier, its specification, and the sets of virtual gateways configured as mutually reachable via intra-domain routes supporting the given transit policy. Each DYNAMIC message contains information about current virtual gateway connectivity to adjacent domains and about the sets of virtual gateways currently mutually reachable via intra- domain routes supporting the configured transit policies.
AD代表方針ゲートウェイは、インターネットワークにおけるサーバを発送するドメインのIDPRルーティング情報メッセージを分配するのにすべてのドメインの中で無制限な氾濫を使用します。 それぞれのAD代表によって発行された2種類のIDPRルーティング情報メッセージがあります: CONFIGURATIONとDYNAMICメッセージ。 それぞれのCONFIGURATIONメッセージはドメイン管理者によって構成された運送保険証券情報を含んでいます、と仮想のゲートウェイの各運送保険証券、識別子、仕様、およびセットのための包含は与えられた運送保険証券をサポートするイントラドメインルートを通して互いに届くとして構成しました。 それぞれのDYNAMICメッセージは隣接しているドメインへの現在の仮想のゲートウェイの接続性と現在構成された運送保険証券をサポートするイントラドメインルートを通して互いに届いている仮想のゲートウェイのセットの情報を含んでいます。
The IDPR Flooding Protocol is similar to the flooding procedures described in [9]-[11]. Through flooding, the AD representative distributes its routing information messages to route servers in its own domain and in adjacent domains. After generating a routing information message, the AD representative distributes a copy to each
IDPR Floodingプロトコルは[9]で説明された氾濫手順と同様です--[11]。 氾濫を通して、AD代表はそれ自身のドメインと隣接しているドメインでサーバを発送するルーティング情報メッセージを分配します。 ルーティングが情報メッセージであると生成した後に、AD代表はそれぞれにコピーを分配します。
Steenstrup [Page 48] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[48ページ]RFC1479IDPRは1993年7月に議定書を作ります。
of its peers and to a selected VG representative (see section 3.1.4) in all other virtual gateways connected to the domain. Each VG representative in turn distributes a copy of the routing information message to each of its peers. We note that distribution of routing information messages among virtual gateways and among peers within a virtual gateway is identical to distribution of inter-VG messages in VGP, as described in section 3.1.3.
同輩と、そして、そのドメインに接続された他のすべての仮想のゲートウェイの選択されたVG代表(セクション3.1.4を見る)に。 それぞれのVG代表は順番にルーティング情報メッセージのコピーを同輩各人に分配します。 私たちは、仮想のゲートウェイの中の仮想のゲートウェイと同輩の中のルーティング情報メッセージの分配がVGPでの相互VGメッセージの分配と同じであることに注意します、セクション3.1.3で説明されるように。
Within a virtual gateway, each policy gateway distributes a copy of the routing information message:
仮想のゲートウェイの中では、それぞれの方針ゲートウェイはルーティング情報メッセージのコピーを分配します:
- To each route server in its configured set of route servers. A
domain administrator should ensure that each route server not
contained within a policy gateway appears in the set of configured
route servers for at least two distinct policy gateways. Hence,
such a route server will continue to receive routing information
messages, even when one of the policy gateways becomes unreachable.
However, the route server will normally receive duplicate copies of
a routing information message.
- それぞれに、構成されたセットのルートサーバのサーバを発送してください。 ドメイン管理者は、方針ゲートウェイの中に含まれなかったそれぞれのルートサーバが構成されたルートサーバのセットに異なった少なくとも2方針門に現れるのを保証するべきです。 したがって、そのようなルートサーバは、ルーティング情報メッセージを受け取り続けるでしょう、方針ゲートウェイの1つが手が届かなくなると。 しかしながら、通常、ルートサーバはルーティング情報メッセージの写本を受けるでしょう。
- To certain directly-connected adjacent policy gateways. A policy
gateway distributes a routing information message to a
directly-connected adjacent policy gateway in an adjacent domain
component, only when it is the lowest-numbered operational peer
with a direct connection to the given domain component. We note
that each policy gateway knows, through information provided by
VGP, which peers have direct connections to which components of
the adjacent domain. If the policy gateway has direct connections
to more than one adjacent policy gateway in that domain component,
it selects the routing information message recipient according to
the order in which the adjacent policy gateways appear in its
database, choosing the first one encountered. This selection
procedure ensures that a copy of the routing information message
reaches each component of the adjacent domain, while limiting the
number of copies distributed.
- ある直接接続された隣接している方針ゲートウェイに。 方針ゲートウェイは隣接しているドメインコンポーネントで直接接続された隣接している方針ゲートウェイにルーティング情報メッセージを分配します、それが与えられたドメインコンポーネントとのダイレクト接続の最も低く番号付の操作上の同輩であるときにだけ。 私たちは、それぞれの方針ゲートウェイが、VGPによって提供された情報を通して隣接しているドメインのどのコンポーネントにはどの同輩がダイレクト接続がいるかを知っていることに注意します。 そのドメインコンポーネントにダイレクト接続が方針ゲートウェイに隣接している1方針門以上まであるなら、1番目を選んで、隣接している方針ゲートウェイがデータベースに現れる1つが遭遇した注文に従って、それはルーティング情報メッセージ受取人を選びます。 この選択手順は、分配されたコピーの数を制限している間、ルーティング情報メッセージのコピーが隣接しているドメインの各コンポーネントに達するのを確実にします。
Once a routing information message reaches an adjacent policy gateway, that policy gateway distributes copies of the message throughout its domain. The adjacent policy gateway, acting as the first recipient of the routing information message in its domain, follows the same message distribution procedure as the AD representative in the source domain, as described above. The flooding procedure terminates when all reachable route servers in an internetwork receive a copy of the routing information message.
ルーティング情報メッセージがいったん隣接している方針ゲートウェイに達すると、その方針ゲートウェイはメッセージのコピーをドメインに分配します。 ルーティング情報メッセージの最初の受取人としてドメインで機能して、隣接している方針ゲートウェイはソースドメインでAD代表と同じメッセージの振分け手順に従います、上で説明されるように。 インターネットワークにおけるすべての届いているルートサーバがルーティング情報メッセージのコピーを受けるとき、氾濫手順は終わります。
Neighbor policy gateways may receive copies of the same routing information message from different adjoining domains. If two neighbor policy gateways receive the message copies simultaneously,
ゲートウェイが異なった隣接しているドメインから情報メッセージを発送しながら同じようにコピーを受けるかもしれない隣人方針。 2隣人方針門が受信されるなら、メッセージは同時にコピーされます。
Steenstrup [Page 49] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[49ページ]RFC1479IDPRは1993年7月に議定書を作ります。
they will distribute them to VG representatives in other virtual gateways within their domain, resulting in duplicate message distribution. However, each policy gateway stops the spread of duplicate routing information messages as soon as it detects them, as described in section 4.2.3 below. In the Internet, we expect simultaneous message receptions to be the exception rather than the rule, given the hierarchical structure of the current topology.
写しメッセージの振分けをもたらして、彼らはそれらのドメインの中の他の仮想のゲートウェイのVG代表にそれらを分配するでしょう。 しかしながら、それらを検出するとすぐに、それぞれの方針ゲートウェイは写しルーティング情報メッセージの普及を止めます、セクション4.2.3未満で説明されるように。 インターネットでは、私たちは、同時のメッセージレセプションが規則よりむしろ例外であると予想します、現在のトポロジーの階層構造を考えて。
4.2.1. Message Generation
4.2.1. メッセージ世代
An AD representative generates and distributes a CONFIGURATION message whenever there is a configuration change in a transit policy or virtual gateway associated with its domain. This ensures that route servers maintain an up-to-date view of a domain's configured transit policies and adjacencies. An AD representative may also distribute a CONFIGURATION message at a configurable period of conf_per (500) hours. A CONFIGURATION message contains, for each configured transit policy, the identifier assigned by the domain administrator, the specification, and the set of associated "virtual gateway groups". Each virtual gateway group comprises virtual gateways configured to be mutually reachable via intra-domain routes of the given transit policy. Accompanying each virtual gateway listed is an indication of whether the virtual gateway is configured to be a domain entry point, a domain exit point, or both according to the given transit policy. The CONFIGURATION message also contains the set of local route servers that the domain administrator has configured to be available to IDPR clients in other domains.
構成変更がドメインに関連している運送保険証券か仮想のゲートウェイにあるときはいつも、AD代表は、CONFIGURATIONメッセージを生成して、分配します。 これは、ルートサーバがドメインの構成された運送保険証券と隣接番組の最新の眺めを維持するのを確実にします。 また、AD代表は1(500)あたりのconf_の構成可能な期間に時間CONFIGURATIONメッセージを分配するかもしれません。 CONFIGURATIONメッセージはそれぞれの構成された運送保険証券のために関連「仮想のゲートウェイグループ」のドメイン管理者、仕様、およびセットによって割り当てられた識別子を含んでいます。 それぞれの仮想のゲートウェイグループは与えられた運送保険証券のイントラドメインルートで互いに届くように構成された仮想のゲートウェイを包括します。 与えられた運送保険証券によると、それぞれの仮想のゲートウェイが記載した伴走は仮想のゲートウェイがドメインエントリー・ポイント、ドメインエキジットポイント、または両方になるように構成されるかどうかしるしです。 また、CONFIGURATIONメッセージは他のドメインにドメイン管理者がIDPRクライアントにとって利用可能になるように構成したローカルのルートサーバのセットを保管しています。
An AD representative generates and distributes a DYNAMIC message whenever there is a change in currently supported transit policies or in current virtual gateway connectivity associated with its domain. This ensures that route servers maintain an up-to-date view of a domain's supported transit policies and existing adjacencies and how they differ from those configured for the domain. Specifically, an AD representative generates a DYNAMIC message whenever there is a change in the connectivity, through the given domain and with respect to a configured transit policy, between two components of adjoining domains. An AD representative may also distribute a DYNAMIC message at a configurable period of dyn_per (24) hours. A DYNAMIC message contains, for each configured transit policy, its identifier, associated virtual gateway groups, and domain components reachable through virtual gateways in each group. Each DYNAMIC message also contains the set of currently "unavailable", either down or unreachable, virtual gateways in the domain.
現在サポートしている運送保険証券かドメインに関連している現在の仮想のゲートウェイの接続性における変化があるときはいつも、AD代表は、DYNAMICメッセージを生成して、分配します。 これは、ルートサーバが運送保険証券と、既存の隣接番組とそれらがどうドメインに構成されたものと異なっているかということであるとサポートされたドメインのものの最新の眺めを維持するのを確実にします。 明確に、接続性、与えられたドメイン、および構成された運送保険証券に関して変化があるときはいつも、AD代表はDYNAMICメッセージを生成します、隣接しているドメインの2つのコンポーネントの間で。 また、AD代表は1(24)あたりのダイン_の構成可能な期間に時間DYNAMICメッセージを分配するかもしれません。 DYNAMICメッセージはそれぞれの構成された運送保険証券のために仮想のゲートウェイを通して各グループで届いている識別子、関連仮想のゲートウェイグループ、およびドメインコンポーネントを含んでいます。 また、それぞれのDYNAMICメッセージはそのドメインに現在、「入手できません」、そして、下がっているか手の届かなくて、仮想のゲートウェイのセットを保管しています。
We note that each virtual gateway group expressed in a DYNAMIC message may be a proper subset of one of the corresponding virtual gateway groups expressed in a CONFIGURATION message. For example,
私たちは、DYNAMICメッセージで言い表されたそれぞれの仮想のゲートウェイグループがCONFIGURATIONメッセージで言い表された対応する仮想のゲートウェイグループの1つの真部分集合であるかもしれないことに注意します。 例えば
Steenstrup [Page 50] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[50ページ]RFC1479IDPRは1993年7月に議定書を作ります。
suppose that, for a given domain, the virtual gateway group (VG A,...,VG E) were configured for a transit policy such that each virtual gateway was both a domain entry and exit point. Thus, all virtual gateways in this group are configured to be mutually reachable via intra-domain routes of the given transit policy. Now suppose that VG E becomes unreachable because of a power failure and furthermore that the remaining virtual gateways form two distinct groups, (VG A,VG B) and (VG C,VG D), such that although virtual gateways in both groups are still mutually reachable via some intra- domain routes they are no longer mutually reachable via any intra- domain routes of the given transit policy. In this case, the virtual gateway groups for the given transit policy now become (VG A,VG B) and (VG C,VG D); VG E is listed as an unavailable virtual gateway.
それぞれの仮想のゲートウェイが両方であっ仮想のゲートウェイグループ(VG A、…、VG E)が運送保険証券のために与えられたドメインにおいて構成されたと仮定してください。ドメインエントリーとエキジットポイント。 したがって、このグループにおけるすべての仮想のゲートウェイが、与えられた運送保険証券のイントラドメインルートで互いに届くように構成されます。 今、EはそのVGであるなら停電のために手が届かなくなります、そして、その上、(VG C、VG D)、残っている仮想のゲートウェイが2つの異なったグループ、(VG A、VG B)を形成して、いくつかのイントラドメインルートを通して互いに届いているスチール写真が仮想のゲートウェイであるのにもかかわらずの、コネがともに分類されるためのそれらであることはもう当然のことの運送保険証券のどんなイントラドメインルートでも互いに届いていません。 この場合、現在、与えられた運送保険証券のための仮想のゲートウェイグループは(VG A、VG B)と(VG C、VG D)になります。 VG Eは入手できない仮想のゲートウェイとして記載されています。
A route server uses information about the set of unavailable virtual gateways to determine which of its routes are no longer viable, and it subsequently removes such routes from its route database. Although route servers could determine the set of unavailable virtual gateways using information about configured virtual gateways and currently reachable virtual gateways, the associated processing cost is high. In particular, a route server would have to examine all virtual gateway groups listed in a DYNAMIC message to determine whether there are any unavailable virtual gateways in the given domain. To reduce the message processing at each route server, we have chosen to include the set of unavailable virtual gateways in each DYNAMIC message.
ルートサーバはルートのどれがもう実行可能でないかを決定するのに入手できない仮想のゲートウェイのセットの情報を使用します、そして、それは次に、ルートデータベースからそのようなルートを取り外します。 ルートサーバは構成された仮想のゲートウェイと現在届いている仮想のゲートウェイの情報を使用することで入手できない仮想のゲートウェイのセットを決定するかもしれませんが、関連加工費は高いです。 特に、ルートサーバはいくつかの入手できない仮想のゲートウェイが与えられたドメインにあるかを決定するDYNAMICメッセージに記載されたすべての仮想のゲートウェイグループを調べなければならないでしょう。 それぞれのルートサーバでメッセージ処理を抑えるために、私たちは、それぞれのDYNAMICメッセージに入手できない仮想のゲートウェイのセットを含んでいるのを選びました。
In order to construct a DYNAMIC message, an AD representative assembles information gathered from intra-domain routing and from VGP. Specifically, the AD representative uses the following information:
DYNAMICメッセージを構成するために、AD代表はイントラドメインルーティングとVGPから集められた情報を組み立てます。 明確に、AD代表は以下の情報を使用します:
- VG CONNECT and UP/DOWN messages to determine the state, up or down,
of each of its domain's virtual gateways and the adjacent domain
components reachable through a given virtual gateway.
- VG CONNECT、それぞれのドメインの仮想のゲートウェイの上がっているか下がっている州を決定するUP/DOWNメッセージ、および与えられた仮想のゲートウェイを通して届いている隣接しているドメインコンポーネント。
- Intra-domain routing information to determine, for each of its
domain's transit policies, whether a given virtual gateway in the
domain is reachable with respect to that transit policy.
- そのドメインの与えられた仮想のゲートウェイがその運送保険証券に関して届いているか否かに関係なく、それぞれのドメインの運送保険証券のために決定するイントラドメインルーティング情報。
- VG POLICY messages to determine the connectivity of adjoining
domain components, across the given domain and with respect to a
configured transit policy, such that these components are adjacent
to virtual gateways not currently reachable from the AD
representative's virtual gateway according to the given transit
policy.
- 与えられた運送保険証券によると、与えられたドメイン中のドメインコンポーネント、およびこれらのコンポーネントが現在AD代表の仮想のゲートウェイから届いていない仮想のゲートウェイに隣接しているような構成された運送保険証券に関するものに隣接する接続性を決定するVG POLICYメッセージ。
Steenstrup [Page 51] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[51ページ]RFC1479IDPRは1993年7月に議定書を作ります。
4.2.2. Sequence Numbers
4.2.2. 一連番号
Each IDPR routing information message carries a sequence number which, when used in conjunction with the timestamp carried in the CMTP message header, determines the recency of the message. An AD representative assigns a sequence number to each routing information message it generates, depending upon its internal clock time:
それぞれのIDPRルーティング情報メッセージはCMTPメッセージヘッダーで運ばれたタイムスタンプに関連して使用されるとメッセージの新鮮を決定する一連番号を運びます。 内部クロック時によって、AD代表はそれが生成するそれぞれのルーティング情報メッセージに一連番号を割り当てます:
- The AD representative sets the sequence number to 0, if its
internal clock time is greater than the timestamp in its previously
generated routing information message.
- AD代表は0に一連番号を設定します、内部クロック時間が以前に発生しているルーティング情報メッセージのタイムスタンプより大きいなら。
- The AD representative sets the sequence number to 1 greater than
the sequence number in its previously generated routing information
message, if its internal clock time equals the timestamp for its
previously generated routing information message and if the
previous sequence number is less than the maximum value
(currently 2**16 - 1). If the previous sequence number equals the
maximum value, the AD representative waits until its internal clock
time exceeds the timestamp in its previously generated routing
information message and then sets the sequence number to 0.
- AD代表は以前に発生しているルーティングによる一連番号よりすばらしい1つの情報メッセージに一連番号を設定します、内部クロック時間が以前に発生しているルーティング情報メッセージのためのタイムスタンプと等しく、前の一連番号が最大値(現在の2**16--1)より少ないなら。 前の一連番号が最大値と等しいなら、内部クロック時間が以前に発生しているルーティング情報メッセージでタイムスタンプを超えて、次に、0に一連番号を設定するまで、AD代表は待ちます。
In general, we do not expect generation of multiple distinct IDPR routing information messages carrying identical timestamps, and so the sequence number may seem superfluous. However, the sequence number may become necessary during synchronization of an AD representative's internal clock. In particular, the AD representative may need to freeze the clock value during synchronization, and thus distinct sequence numbers serve to distinguish routing information messages generated during the clock synchronization interval.
一般に、私たちが同じタイムスタンプを運ぶ複数の異なったIDPRルーティング情報メッセージの世代を予想しないので、一連番号は余計に見えるかもしれません。 しかしながら、一連番号はAD代表の内部クロックの同期の間、必要になるかもしれません。 特に、AD代表は、同期の間、時計値を凍らせる必要があるかもしれません、そして、その結果、異なった一連番号は時計同期間隔の間に生成されたルーティング情報メッセージを区別するのに役立ちます。
4.2.3. Message Acceptance
4.2.3. メッセージ承認
Prior to a policy gateway forwarding a routing information message or a route server incorporating routing information into its routing information database, the policy gateway or route server assesses routing information message acceptability. An IDPR routing information message is "acceptable" if:
ルーティング情報データベースにルーティング情報を組み入れながらルーティング情報メッセージかルートサーバを転送する方針ゲートウェイの前では、方針ゲートウェイかルートサーバがルーティング情報メッセージの受容性を評価します。 IDPRルーティング情報メッセージが「許容できる」、:
- It passes the CMTP validation checks.
- それはCMTP合法化チェックを通過します。
- Its timestamp is less than conf_old (530) hours behind the
recipient's internal clock time for CONFIGURATION messages and less
than dyn_old (25) hours behind the recipient's internal clock time
for DYNAMIC messages.
- タイムスタンプがCONFIGURATIONメッセージのための受取人の内部クロック時間の(530)時間後ろで古いconf_と以下よりDYNAMICメッセージのための受取人の内部クロック時間の(25)時間後ろで古いダイン_あります。
- Its timestamp and sequence number indicate that it is more recent
- そのタイムスタンプと一連番号は、それが、より最近であるのを示します。
Steenstrup [Page 52] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[52ページ]RFC1479IDPRは1993年7月に議定書を作ります。
than the currently-stored routing information from the given
domain. If there is no routing information currently stored from
the given domain, then the routing information message contains, by
default, the more recent information.
与えられたドメインからの現在保存されたルーティング情報より。 現在与えられたドメインから保存されているルーティング情報が全くなければ、ルーティング情報メッセージはデフォルトでより最近の情報を含んでいます。
Policy gateways acknowledge and forward acceptable IDPR routing information messages, according to the flooding protocol described in section 4.2 above. Moreover, each policy gateway retains the timestamp and sequence number for the most recently accepted routing information message from each domain and uses these values to determine acceptability of routing information messages received in the future. Route servers acknowledge the receipt of acceptable routing information messages and incorporate the contents of these messages into their routing information databases, contingent upon criteria discussed in section 4.2.4 below; however, they do not participate in the flooding protocol. We note that when a policy gateway or route server first returns to service, it immediately updates its routing information database with routing information obtained from another route server, using the route server query protocol described in section 5.
上のセクション4.2で説明された氾濫プロトコルに応じて、方針ゲートウェイは、許容できるIDPRルーティング情報メッセージを承認して、転送します。 そのうえ、それぞれの方針ゲートウェイは、各ドメインからの最も最近受け入れられたルーティング情報メッセージのためにタイムスタンプと一連番号を保有して、将来受け取られたルーティング情報メッセージの受容性を決定するのにこれらの値を使用します。 ルートサーバは、許容できるルーティング情報メッセージの領収書を受け取ったことを知らせて、それらのルーティング情報データベースにこれらのメッセージのコンテンツを組み入れます、セクション4.2.4未満で議論した評価基準次第で。 しかしながら、彼らは氾濫プロトコルに参加しません。 私たちは、方針ゲートウェイかルートサーバが最初にサービスに戻ると、それがすぐに別のルートサーバからルーティング情報を得ていてルーティング情報データベースをアップデートすることに注意します、セクション5で説明されたルートサーバ質問プロトコルを使用して。
An AD representative takes special action upon receiving an acceptable routing information message, supposedly generated by itself but originally obtained from a policy gateway or route server other than itself. There are at least three possible reasons for the occurrence of this event:
AD代表は推定上それ自体で生成されましたが、元々方針ゲートウェイかそれ自体以外のルートサーバから得られた許容できるルーティング情報メッセージを受け取るのに特別な動きを持っていきます。 このイベントの発生の少なくとも3つの可能な理由があります:
- The routing information message has been corrupted in a way that is
not detectable by the integrity/authentication value.
- ルーティング情報メッセージは保全/認証値で検出可能でない方法で腐敗しています。
- The AD representative has experienced a memory error.
- AD代表はメモリ誤りを経験しました。
- Some other entity is generating routing information messages on
behalf of the AD representative.
- ある他の実体は、AD代表を代表してルーティングが情報メッセージであると生成しています。
In any case, the AD representative logs the event for network management. Moreover, the AD representative must reestablish its own routing information messages as the most recent for its domain. To do so, the AD representative waits until its internal clock time exceeds the value of the timestamp in the received routing information message and then generates a new routing information message using the currently-stored domain routing information supplied by VGP and by the intra-domain routing procedure. Note that the length of time the AD representative must wait to generate the new message is at most cmtp_new (300) seconds, the maximum CMTP- tolerated difference between the received message's timestamp and the AD representative's internal clock time.
どのような場合でも、AD代表はネットワークマネージメントのためにイベントを登録します。 そのうえ、AD代表はドメインのための最新であるとしてのそれ自身のルーティング情報メッセージを回復させなければなりません。 AD代表は、そうするために、内部クロック時間が受信されたルーティング情報メッセージのタイムスタンプの値を超えるまで待っていて、次に、新しいルーティングが情報メッセージであるとVGPとイントラドメインルーティング手順で提供された現在保存されたドメインルーティング情報を使用することで生成します。 AD代表が新しいメッセージを生成するのを待たなければならない時の長さが高々cmtp_新しい(300)秒であるというメモ、最大CMTPは受信されたメッセージのタイムスタンプとAD代表の内部クロック時間の違いを許容しました。
Steenstrup [Page 53] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[53ページ]RFC1479IDPRは1993年7月に議定書を作ります。
IDPR routing information messages that pass the CMTP validity checks but appear less recent than stored routing information are unacceptable. Policy gateways do not forward unacceptable routing information messages, and route servers do not incorporate the contents of unacceptable routing information messages into their routing information databases. Instead, the recipient of an unacceptable routing information message acknowledges the message in one of two ways:
バリディティチェックをCMTPに通過しますが、情報を発送しながら保存されるほど最近でないのに見えるIDPRルーティング情報メッセージは容認できません。 方針ゲートウェイは容認できないルーティング情報メッセージを転送しません、そして、ルートサーバは容認できないルーティング情報メッセージのコンテンツをそれらのルーティング情報データベースに取り入れません。 代わりに、容認できないルーティング情報メッセージの受取人は2つの方法の1つでメッセージを承認します:
- If the routing information message timestamp and sequence number
equal to the timestamp and sequence number associated with the
stored routing information for the given domain, the recipient
assumes that the routing information message is a duplicate and
acknowledges the message.
- ルーティング情報メッセージタイムスタンプと一連番号が保存されたルーティングに関連しているタイムスタンプと一連番号と与えられたドメインのための情報と等しいなら、受取人は、ルーティング情報メッセージが写しであると仮定して、メッセージを認めます。
- If the routing information message timestamp and sequence number
indicate that the message is less recent than the stored routing
information for the domain, the recipient acknowledges the message
with an indication that the routing information it contains is
out-of-date. Such a negative acknowledgement is a signal to the
sender of the routing information message to request more up-to-
date routing information from a route server, using the route
server query protocol. Furthermore, if the recipient of the out-
of-date routing information message is a route server, it
regenerates a routing information message from its own routing
information database and forwards the message to the sender. The
sender may in turn propagate this more recent routing information
message to other policy gateways and route servers.
- ルーティング情報メッセージタイムスタンプと一連番号が、メッセージがドメインのための保存されたルーティング情報ほど最近でないのを示すなら、受取人はそれが含むルーティング情報が時代遅れであるという指示があるメッセージを承認します。 そのような否定的承認はルートサーバから上から日付へのルーティングより多くの情報を要求するルーティング情報メッセージの送付者への信号です、ルートサーバ質問プロトコルを使用して。 その上、日付の出ているルーティング情報メッセージの受取人がルートサーバであるなら、それは、それ自身のルーティング情報データベースからルーティング情報メッセージを作り直して、メッセージを送付者に転送します。 送付者は順番に他の方針ゲートウェイとルートサーバにこのより最近のルーティング情報メッセージを伝播するかもしれません。
4.2.4. Message Incorporation
4.2.4. メッセージ編入
A route server usually stores the entire contents of an acceptable IDPR routing information message in its routing information database, so that it has access to all advertised transit policies when generating a route and so that it can regenerate routing information messages at a later point in time if requested to do so by another route server or policy gateway. However, a route server may elect not to store all routing information message contents. In particular, the route server need not store any transit policy that excludes the route server's domain as a source or any routing information from a domain that the route server's domain's source policies exclude for transit. Selective storing of routing information message contents simplifies the route generation procedure since it reduces the search space of possible routes, and it limits the amount of route server memory devoted to routing information. However, selective storing of routing information also means that the route server cannot always regenerate the original routing information message, if requested to do so by another route
通常、ルートサーバはルーティング情報データベースの許容できるIDPRルーティング情報メッセージの全体のコンテンツを保存します、ルートを生成するとき、すべての広告を出している運送保険証券に近づく手段を持って、ルートサーバかもうの1方針門のそばでそうするよう要求されるなら時間内に後のポイントでルーティング情報メッセージを作り直すことができるように。 しかしながら、ルートサーバは、すべてのルーティング情報メッセージ内容を保存するというわけではないのを選ぶかもしれません。 特に、ルートサーバはソースとしてルートサーバのドメインを除くどんな運送保険証券かドメインからのルートサーバのドメインのソース方針がトランジットのために除く少しのルーティング情報も保存する必要はありません。 可能なルートの検索スペースを減少させるので、ルーティング情報メッセージ内容の選択している保存はルート世代手順を簡素化します、そして、それはルーティング情報にささげられたルートサーバメモリの量を制限します。 しかしながら、また、ルーティング情報の選択している保存は、ルートサーバがいつもオリジナルのルーティング情報メッセージを作り直すことができるというわけではないことを意味します、別のルートでそうするよう要求されるなら
Steenstrup [Page 54] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[54ページ]RFC1479IDPRは1993年7月に議定書を作ります。
server or policy gateway.
サーバか方針ゲートウェイ。
An acceptable IDPR routing information message may contain transit policy information that is not well-defined according to the route server's perception. A CONFIGURATION message may contain an unrecognized domain, virtual gateway, or transit policy attribute, such as user class access restrictions or offered service. In this case, "unrecognized" means that the value in the routing information message is not listed in the route server's configuration database, as described previously in section 1.8.2. A DYNAMIC message may contain an unrecognized transit policy or virtual gateway. In this case, "unrecognized" means that the transit policy or virtual gateway was not listed in the most recent CONFIGURATION message for the given domain.
許容できるIDPRルーティング情報メッセージはルートサーバの知覚に従って明確でない運送保険証券情報を含むかもしれません。 CONFIGURATIONメッセージは認識されていないドメイン、仮想のゲートウェイ、または運送保険証券属性を含むかもしれません、ユーザ・クラスアクセス制限や提供サービスのように。 この場合、ルーティング情報メッセージの値をある「認識されていません、な」手段がルートサーバの構成データベースに記載しませんでした、以前にセクション1.8.2で説明されるように。 DYNAMICメッセージは認識されていない運送保険証券か仮想のゲートウェイを含むかもしれません。 この場合、「認識されていません」は、運送保険証券か仮想のゲートウェイが与えられたドメインへの最新のCONFIGURATIONメッセージに記載されなかったことを意味します。
Each route server can always parse an acceptable routing information messsage, even if some of the information is not well-defined, and thus can always use the information that it does recognize. Therefore, a route server can store the contents of acceptable routing information messages from domains in which it is interested, regardless of whether all contents appear to be well-defined at present. If a routing message contains unrecognized information, the route server may attempt to obtain the additional information it needs to decipher the unrecognized information. For a CONFIGURATION message, the route server logs the event for network management; for a DYNAMIC message, the route server requests, from another route server, the most recent CONFIGURATION message for the domain in question.
それぞれのルートサーバはいつも許容できるルーティング情報messsageを分析できます、情報のいくつかが明確でなく、その結果、いつもそれが認識する情報を使用できます。 したがって、ルートサーバはそれが興味を持っているドメインからの許容できるルーティング情報メッセージのコンテンツを保存できます、すべての内容が現在のところ明確であるように見えるかどうかにかかわらず。 ルーティング・メッセージが認識されていない情報を含んでいるなら、ルートサーバは、それが認識されていない情報を解読するために必要とする追加情報を得るのを試みるかもしれません。 CONFIGURATIONメッセージに関しては、ルートサーバはネットワークマネージメントのためにイベントを登録します。 ルートサーバは、別のものから、DYNAMICメッセージに関してはサーバ(問題のドメインへの最新のCONFIGURATIONメッセージ)を発送するよう要求します。
When a domain is partitioned, each domain component has its own AD representative, which generates routing information messages on behalf of that component. Discovery of a domain partition prompts the AD representative for each domain component to generate and distribute a DYNAMIC message. In this case, a route server receives and stores more than one routing information message at a time for the given domain, namely one for each domain component.
ドメインが仕切られるとき、それぞれのドメインコンポーネントにはそれ自身のAD代表がいます。(その代表は、そのコンポーネントを代表してルーティングが情報メッセージであると生成します)。 ドメインパーティションの発見はDYNAMICメッセージを生成して、分配するそれぞれのドメインコンポーネントのためにAD代表をうながします。 この場合、ルートサーバは、一度に、すなわち、与えられたドメイン、それぞれのドメインコンポーネントあたり1つのために受信して、1つ以上のルーティング情報メッセージを保存します。
When the partition heals, the AD representative for the entire domain generates and distributes a DYNAMIC message. In each route server's routing information database, the new DYNAMIC message does not automatically replace all of the currently-stored DYNAMIC messages for the given domain. Instead, the new message only replaces that message whose AD representative matches the AD representative for the new message. The other DYNAMIC messages, generated during the period over which the partition occurred, remain in the routing information database until they attain their maximum lifetime, as described in section 4.2.5 below. Such stale information may lead to the generation of routes that result in path setup failures and hence the
パーティションが回復すると、全体のドメインへのAD代表は、DYNAMICメッセージを生成して、分配します。 それぞれのルートサーバのルーティング情報データベースでは、新しいDYNAMICメッセージは自動的に与えられたドメインへの現在保存されたDYNAMICメッセージのすべてを取り替えません。 代わりに、新しいメッセージは新しいメッセージのために、AD代表がAD代表に合っているそのメッセージを置き換えるだけです。 彼らの最大の生涯に達するまで、パーティションが起こった期間、生成された他のDYNAMICメッセージはルーティング情報データベースに残っています、セクション4.2.5未満で説明されるように。 したがってそして、そのような聞き古した情報が経路セットアップ失敗をもたらすルートの世代につながるかもしれない。
Steenstrup [Page 55] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[55ページ]RFC1479IDPRは1993年7月に議定書を作ります。
selection of alternative routes. To reduce the chances of path setup failures, we will investigate, for a future version of IDPR, mechanisms for removing partition-related DYNAMIC messages immediately after a partition disappears.
代替のルートの品揃え。 経路セットアップ失敗の可能性を小さくするために、私たちは調査するつもりです、IDPRの将来のバージョンのために、パーティションが見えなくなる直後パーティション関連のDYNAMICメッセージを取り除くためのメカニズム。
4.2.5. Routing Information Database
4.2.5. 経路情報データベース
We expect that most of the IDPR routing information stored in a routing information database will remain viable for long periods of time, perhaps until a domain reconfiguration occurs. By "viable", we mean that the information reflects the current state of the domain and hence may be used successfully for generating policy routes. To reduce the probability of retaining stale routing information, a route server imposes a maximum lifetime on each database entry, initialized when it incorporates an accepted entry into its routing information database. The maximum lifetime should be longer than the corresponding message generation period, so that the database entry is likely to be refreshed before it attains its maximum lifetime.
私たちは、ルーティング情報データベースに保存されたIDPRルーティング情報の大部分が長期間の間実行可能なままで残ると予想します、恐らくドメイン再構成が起こるまで。 「実行可能」で、私たちは、情報がドメインの現状を反映することを意味して、したがって、方針ルートを生成するのに首尾よく使用されるかもしれません。 聞き古したルーティング情報を保有するという確率を減少させるために、ルートサーバはルーティング情報データベースに受け入れられたエントリーを組み入れると初期化されたそれぞれのデータベースエントリーに最大の生涯を課します。 最大の寿命は対応するメッセージ世代の期間より長いはずです、最大の生涯に達する前にデータベースエントリーがリフレッシュされそうなように。
Each CONFIGURATION message stored in the routing information database has a maximum lifetime of conf_old (530) hours; each DYNAMIC message stored in the routing information database has a maximum lifetime of dyn_old (25) hours. Periodic generation of routing information messages makes it unlikely that any routing information message will remain in a routing information database for its full lifetime. However, a routing information message may attain its maximum lifetime in a route server that is separated from a internetwork for a long period of time.
ルーティング情報データベースに保存されたそれぞれのCONFIGURATIONメッセージは_の古いconf(530)の最大の生涯を何時間も持っています。 ルーティング情報データベースに保存されたそれぞれのDYNAMICメッセージは_古い(25)ダイン時間の最大の生涯を持っています。 ルーティング情報メッセージの周期的な世代はどんなルーティング情報メッセージも完全な生涯ルーティング情報データベースに残るのをありそうもなくします。 しかしながら、ルーティング情報メッセージは長い年月の間インターネットワークと切り離されるルートサーバの最大の生涯に達するかもしれません。
When an IDPR routing information message attains its maximum lifetime in a routing information database, the route server removes the message contents from its database, so that it will not generate new routes with the outdated routing information nor distribute old routing information in response to requests from other route servers or policy gateways. Nevertheless, the route server continues to dispense routes previously generated with the old routing information, as long as path setup (see section 7) for these routes succeeds.
IDPRルーティング情報メッセージがルーティング情報データベースの最大の生涯に達すると、ルートサーバはデータベースからメッセージ内容を取り除きます、時代遅れのルーティング情報で新しいルートを生成して、他のルートサーバか方針ゲートウェイからの要求に対応して古いルーティング情報を分配しないように。 それにもかかわらず、ルートサーバは、以前に古いルーティング情報で生成されたルートを分配し続けています、これらのルートのための経路セットアップ(セクション7を見る)が成功する限り。
The route server treats routing information message lifetime expiration differently, depending on the type of routing information message. When a CONFIGURATION message expires, the route server requests, from another route server, the most recent CONFIGURATION message issued for the given domain. When a DYNAMIC message expires, the route server does not initially attempt to obtain more recent routing information. Instead, if route generation is necessary, the route server uses the routing information contained in the corresponding CONFIGURATION message for the given domain. Only if
ルーティング情報メッセージのタイプに頼っていて、ルートサーバはルーティング情報メッセージ生涯満了を異なって扱います。 ルートサーバは、CONFIGURATIONメッセージが期限が切れるときには別のものから、サーバを発送するよう要求します、と最新のCONFIGURATIONメッセージが与えられたドメインに発行しました。 DYNAMICメッセージが期限が切れる場合、ルートサーバは、初めは、より最近のルーティング情報を得るのを試みません。 代わりに、ルート世代が必要であるなら、ルートサーバは与えられたドメインに対応するCONFIGURATIONメッセージに含まれたルーティング情報を使用します。 唯一
Steenstrup [Page 56] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[56ページ]RFC1479IDPRは1993年7月に議定書を作ります。
there is a path setup failure (see section 7.4) involving the given domain does the route server request, from another route server, the most recent DYNAMIC message issued for the given domain.
最新のDYNAMICメッセージは、与えられたドメインにかかわるとする経路セットアップ失敗(セクション7.4を見る)が別のルートサーバからのそこでは、ルートサーバ要求であることを与えられたドメインに発行しました。
4.3. Routing Information Message Formats
4.3. 経路情報メッセージ・フォーマット
The flooding protocol number is equal to 1. We describe the contents of each type of routing information message below.
氾濫プロトコル番号は1と等しいです。 私たちは以下のそれぞれのタイプに関するルーティング情報メッセージのコンテンツについて説明します。
4.3.1. CONFIGURATION
4.3.1. 構成
The CONFIGURATION message type is equal to 0.
CONFIGURATIONメッセージタイプは0に堪えます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD CMP | SEQ |
+-------------------------------+-------------------------------+
| NUM TP | NUM RS |
+-------------------------------+-------------------------------+
| RS |
+-------------------------------+
For each transit policy configured for the domain:
+-------------------------------+-------------------------------+
| TP | NUM ATR |
+-------------------------------+-------------------------------+
For each attribute of the transit policy:
+-------------------------------+-------------------------------+
| ATR TYP | ATR LEN |
+-------------------------------+-------------------------------+
For the source/destination access restrictions attribute:
+-------------------------------+
| NUM AD GRP |
+-------------------------------+
For each domain group in the source/destination access restrictions:
+-------------------------------+-------------------------------+
| NUM AD | AD |
+---------------+---------------+-------------------------------+
| AD FLGS | NUM HST | HST SET |
+---------------+---------------+-------------------------------+
For the temporal access restrictions attribute:
+-------------------------------+
| NUM TIM |
+-------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Cmp| SEQ| +-------------------------------+-------------------------------+ | ヌムTP| ヌムRS| +-------------------------------+-------------------------------+ | RS| +-------------------------------各運送保険証券のための+はドメインに構成しました: +-------------------------------+-------------------------------+ | TP| ヌムATR| +-------------------------------+-------------------------------運送保険証券の各属性のための+: +-------------------------------+-------------------------------+ | ATR TYP| ATRレン| +-------------------------------+-------------------------------ソース/目的地アクセス制限属性のための+: +-------------------------------+ | ヌムAD GRP| +-------------------------------ソース/目的地アクセス制限におけるそれぞれのドメイングループのための+: +-------------------------------+-------------------------------+ | ヌム西暦| 西暦| +---------------+---------------+-------------------------------+ | AD FLGS| ヌムHST| HSTはセットしました。| +---------------+---------------+-------------------------------時のアクセス制限属性のための+: +-------------------------------+ | ヌムティム| +-------------------------------+
Steenstrup [Page 57] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[57ページ]RFC1479IDPRは1993年7月に議定書を作ります。
For each set of times in the temporal access restrictions: +---------------+-----------------------------------------------+ | TIM FLGS | DURATION | +---------------+-----------------------------------------------+ | START | +-------------------------------+-------------------------------+ | PERIOD | ACTIVE | +-------------------------------+-------------------------------+ For the user class access restrictions attribute: +-------------------------------+ | NUM UCI | +-------------------------------+ For each UCI in the user class access restrictions: +---------------+ | UCI | +---------------+ For each offered service attribute: +---------------------------------------------------------------+ | OFR SRV | +---------------------------------------------------------------+ For the virtual gateway access restrictions attribute: +-------------------------------+ | NUM VG GRP | +-------------------------------+ For each virtual gateway group in the virtual gateway access restrictions: +-------------------------------+-------------------------------+ | NUM VG | ADJ AD | +---------------+---------------+-------------------------------+ | VG | VG FLGS | +---------------+---------------+
時のアクセス制限における、それぞれのセットの倍のために: +---------------+-----------------------------------------------+ | ティムFLGS| 持続時間| +---------------+-----------------------------------------------+ | 始め| +-------------------------------+-------------------------------+ | 期間| アクティブ| +-------------------------------+-------------------------------ユーザ・クラスアクセス制限属性のための+: +-------------------------------+ | ヌムUCI| +-------------------------------ユーザ・クラスアクセス制限における各UCIのための+: +---------------+ | UCI| +---------------それぞれのための+はサービス属性を提供しました: +---------------------------------------------------------------+ | OFR SRV| +---------------------------------------------------------------仮想のゲートウェイアクセス制限属性のための+: +-------------------------------+ | ヌムVG GRP| +-------------------------------仮想のゲートウェイアクセス制限におけるそれぞれの仮想のゲートウェイグループのための+: +-------------------------------+-------------------------------+ | ヌムVG| ADJ西暦| +---------------+---------------+-------------------------------+ | VG| VG FLGS| +---------------+---------------+
AD CMP
(16 bits) Numeric identifier for the domain component containing
the AD representative policy gateway.
AD代表方針ゲートウェイを含むドメインコンポーネントのためのAD CMP(16ビット)の数値識別子。
SEQ (16 bits) Routing information message sequence number.
SEQ(16ビット)ルート設定情報メッセージ通番。
NUM TP (16 bits) Number of transit policy specifications contained in
the routing information message.
ルーティング情報メッセージに含まれた運送保険証券仕様のNUM TP(16ビット)番号。
NUM RS (16 bits) Number of route servers advertised to serve clients
outside of the domain.
ドメインの外でクライアントに役立つように広告に掲載されたルートサーバのNUM RS(16ビット)番号。
RS (16 bits) Numeric identifier for a route server.
ルートサーバのためのRS(16ビット)の数値識別子。
TP (16 bits) Numeric identifier for a transit policy specification.
運送保険証券仕様のためのTP(16ビット)の数値識別子。
Steenstrup [Page 58] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[58ページ]RFC1479IDPRは1993年7月に議定書を作ります。
NUM ATR (16 bits) Number of attributes associated with the transit
policy.
運送保険証券に関連している属性のNUM ATR(16ビット)番号。
ATR TYP (16 bits) Numeric identifier for a type of attribute. Valid
attributes include the following types:
一種の属性のためのATR TYP(16ビット)の数値識別子。 有効な属性は以下のタイプを含んでいます:
- Set of virtual gateway access restrictions (see section 1.4.2)
associated with the transit policy (variable). This attribute must
be included.
- 仮想のゲートウェイアクセス制限(セクション1.4.2を見る)のセットは運送保険証券(可変)と交際しました。 この属性を含まなければなりません。
- Set of source/destination access restrictions (see section 1.4.2)
associated with the transit policy (variable). This attribute may
be omitted. Absence of this attribute implies that traffic from
any source to any destination is acceptable.
- ソース/目的地アクセス制限(セクション1.4.2を見る)のセットは運送保険証券(可変)と交際しました。 この属性は省略されるかもしれません。 この属性の欠如は、どんなソースからどんな目的地までのトラフィックも許容できるのを含意します。
- Set of temporal access restrictions (see section 1.4.2) associated
with the transit policy (variable). This attribute may be omitted.
Absence of this attribute implies that the transit policy applies
at all times.
- 時のアクセス制限(セクション1.4.2を見る)のセットは運送保険証券(可変)と交際しました。 この属性は省略されるかもしれません。 この属性の欠如は、運送保険証券がいつも適用されるのを含意します。
- Set of user class access restrictions (see section 1.4.2)
associated with the transit policy (variable). This attribute may
be omitted. Absence of this attribute implies that traffic from
any user class is acceptable.
- ユーザ・クラスアクセス制限(セクション1.4.2を見る)のセットは運送保険証券(可変)と交際しました。 この属性は省略されるかもしれません。 この属性の欠如は、どんなユーザ・クラスからのトラフィックも許容できるのを含意します。
- Average delay in milliseconds (16 bits). This attribute may be
omitted.
- ミリセカンド(16ビット)の遅れを平均してください。 この属性は省略されるかもしれません。
- Delay variation in milliseconds (16 bits). This attribute may be
omitted.
- ミリセカンド(16ビット)の変化を遅らせてください。 この属性は省略されるかもしれません。
- Average available bandwidth in bits per second (48 bits). This
attribute may be omitted.
- bps(48ビット)における利用可能な帯域幅を平均してください。 この属性は省略されるかもしれません。
- Available bandwidth variation in bits per second (48 bits). This
attribute may be omitted.
- bps(48ビット)の利用可能な帯域幅変化。 この属性は省略されるかもしれません。
- MTU in bytes (16 bits). This attribute may be omitted.
- バイト(16ビット)で表現されるMTU。 この属性は省略されるかもしれません。
- Charge per byte in thousandths of a cent (16 bits). This attribute
may be omitted.
- 1000第年代に1バイト単位で1セント(16ビット)を充電してください。 この属性は省略されるかもしれません。
- Charge per message in thousandths of a cent (16 bits). This
attribute may be omitted.
- 1000第年代にメッセージ単位で1セント(16ビット)を充電してください。 この属性は省略されるかもしれません。
- Charge for session time in thousandths of a cent per second (16
bits). This attribute may be omitted. Absence of any charge
attribute implies that the domain provides free transit service.
- 1000第年代にセッション時間に秒(16ビット)あたり1セントを充電してください。 この属性は省略されるかもしれません。 どんな充電属性の欠如も、ドメインが無料のトランジットサービスを提供するのを含意します。
Steenstrup [Page 59] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[59ページ]RFC1479IDPRは1993年7月に議定書を作ります。
ATR LEN (16 bits) Length of an attribute in bytes, beginning with the subsequent field.
その後の分野で始まるバイトで表現される属性のATR LEN(16ビット)の長さ。
NUM AD GRP (16 bits) Number of source/destination domain groups (see section 1.4.2) associated with the source/destination access restrictions.
ソース/目的地に関連しているソース/目的地ドメイングループ(セクション1.4.2を見る)のNUM AD GRP(16ビット)番号は制限にアクセスします。
NUM AD (16 bits) Number of domains or sets of domains in a domain group.
ドメインのNUM AD(16ビット)番号かドメインのドメインのセットが分類されます。
AD (16 bits) Numeric identifier for a domain or domain set.
ドメインかドメインのためのAD(16ビット)の数値識別子はセットしました。
AD FLGS (8 bits) Set of five flags indicating how to interpret the AD field, contained in the right-most bits. Proceeding left to right, the first flag indicates whether the transit policy applies to all domains or to specific domains (1 all, 0 specific), and when set to 1, causes the second and third flags to be ignored. The second flag indicates whether the domain identifier signifies a single domain or a domain set (1 single, 0 set). The third flag indicates whether the transit policy applies to the given domain or domain set (1 applies, 0 does not apply) and is used for representing complements of sets of domains. The fourth flag indicates whether the domain is a source (1 source, 0 not source). The fifth flag indicates whether the domain is a destination (1 destination, 0 not destination). At least one of the fourth and fifth flags must be set to 1.
(8ビット)が設定する5のAD FLGSは、最も権利ビットに含まれたAD分野を解釈する方法を示しながら、弛みます。 進行は右にいなくなりました、と運送保険証券がすべてのドメイン、または、特定のドメインに適用されるか否かに関係なく、最初の旗が示す、(1、0詳細、)、そして、1、2番目と3番目が無視されるために旗を揚げさせる原因に設定しているいつ?。 2番目の旗が、ドメイン識別子が単一領域を意味するかどうかを示すか、またはドメインはセットしました(1つのシングル、0セット)。 3番目の旗は、運送保険証券が与えられたドメインかドメインに適用されるかどうかがセットしたのを(1は適用されて、0は適用されません)示して、ドメインのセットの補数を表すのに使用されます。 4番目の旗は、ドメインがソース(ソースではなく、0歳の1つのソース)であるかどうかを示します。 5番目の旗は、ドメインが目的地(目的地ではなく、1つの目的地、0)であるかどうかを示します。 少なくとも4番目と5番目の旗の1つを1に設定しなければなりません。
NUM HST (8 bits) Number of "host sets" (see section 1.4.2) associated with a particular domain or domain set. The value 0 indicates that all hosts in the given domain or domain set are acceptable sources or destinations, as specified by the fourth and fifth AD flags.
特定のドメインかドメインに関連している「ホストセット」(セクション1.4.2を見る)のNUM HST(8ビット)番号はセットしました。 値0は、与えられたドメインかドメインのホストが設定するすべてが許容できるソースか目的地であることを示します、4番目と5番目のAD旗で指定されるように。
HST SET (16 bits) Numeric identifier for a host set.
HST SET(16ビット)のホストにとっての数値の識別子はセットしました。
NUM TIM (16 bits) Number of time specifications associated with the temporal access restrictions. Each time specification is split into a set of continguous identical periods, as we describe below.
時のアクセス制限に関連している時間仕様のNUM TIM(16ビット)番号。 その都度、私たちが以下で説明するように仕様は1セットのcontinguousの同じ期間に分けられます。
TIM FLGS (8 bits) Set of two flags indicating how to combine the time specifications, contained in the right-most bits. Proceeding left to right, the first flag indicates whether the transit policy applies during the periods specified in the time specification (1 applies, 0 does not apply) and is used for representing complements of policy applicability intervals. The second flag indicates whether the time specification takes precedence over the previous time specifications listed (1 precedence, 0 no precedence). Precedence is equivalent to the boolean OR and AND operators, in the following sense. At any given instant, a transit policy either applies or does not apply, according to a given time specification, and we can assign a boolean
(8ビット)が設定する2のTIM FLGSは、最も権利ビットに含まれた時間仕様を結合する方法を示しながら、弛みます。 進行は右にいなくなりました、と運送保険証券が時間仕様(1は適用されて、0は適用されない)で指定された期間、申し込んで、方針適用性間隔の補数を表すのに使用されるか否かに関係なく、最初の旗は示します。 2番目の旗が、時間仕様が前回仕様の上で優先するかどうかが記載したのを示す、(1つの先行、0、先行がない、) 以下の意味における論理演算子ORとANDオペレータにとって、先行は同等です。 少しの与えられた瞬間にも、運送保険証券は、適用するか、または与えられた時間仕様通りに適用されません、そして、私たちは論理演算子を割り当てることができます。
Steenstrup [Page 60] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[60ページ]RFC1479IDPRは1993年7月に議定書を作ります。
value to the state of policy applicability according to a given time specification. If the second flag assumes the value 1 for a given time specification, that indicates the boolean operator OR should be applied to the values of policy applicability, according to the given time specification and to all previously listed time specifications. If the second flag assumes the value 0 for a given time specification, that indicates the boolean operator AND should be applied to the values of policy applicability, according to the given time specification and to all previously listed time specifications.
与えられた時間仕様通りに方針の状態に適用性を評価してください。 2番目の旗が与えられた時間仕様のために値1を仮定するなら、それは、論理演算子オペレータORが方針の適用性の値と、そして、与えられた時間仕様とすべての以前に記載された時間仕様に適用されるべきであるのを示します。 2番目の旗が、与えられた時間仕様のために値が0であると仮定するなら、それは、論理演算子オペレータを示して、方針の適用性の値と、そして、与えられた時間仕様とすべての以前に記載された時間仕様に適用されるべきです。
DURATION (24 bits) Length of the time specification duration, in minutes. A value of 0 indicates an infinite duration.
数分間の時間仕様持続時間のDURATION(24ビット)の長さ。 0の値は無限の持続時間を示します。
START (32 bits) Time at which the time specification first takes effect, in seconds elapsed since 1 January 1970 0:00 GMT.
1970年1月1日のグリニッジ標準時0時0分以来時間仕様が秒に最初に実施するSTART(32ビット)時は経過しました。
PERIOD (16 bits) Length of each time period within the time specification, in minutes.
数分間の時間仕様の中のそれぞれの期間のPERIOD(16ビット)の長さ。
ACTIVE (16 bits) Length of the policy applicable interval during each time period, in minutes from the beginning of the time period.
期間の初めからの数分間の各期間の方針の適切な間隔のACTIVE(16ビット)の長さ。
NUM UCI (16 bits) Number of user classes associated with the user class access restrictions.
ユーザ・クラスに関連しているユーザ・クラスのNUM UCI(16ビット)番号は制限にアクセスします。
UCI (8 bits) Numeric identifier for a user class.
UCI(8ビット)のユーザ・クラスにおける数値の識別子。
NUM VG GRP (16 bits) Number of virtual gateway groups (see section 1.4.2) associated with the virtual gateway access restrictions.
仮想のゲートウェイに関連している仮想のゲートウェイグループ(セクション1.4.2を見る)のNUM VG GRP(16ビット)番号は制限にアクセスします。
NUM VG (16 bits) Number of virtual gateways in a virtual gateway group.
仮想のゲートウェイの仮想のゲートウェイのNUM VG(16ビット)番号は分類されます。
ADJ AD (16 bits) Numeric identifier for the adjacent domain to which a virtual gateway connects.
仮想のゲートウェイが接続する隣接しているドメインのためのADJ AD(16ビット)の数値識別子。
VG (8 bits) Numeric identifier for a virtual gateway.
仮想のゲートウェイのためのVG(8ビット)の数値識別子。
VG FLGS (8 bits) Set of two flags indicating how to interpret the VG field, contained in the right-most bits. Proceeding left to right, the first flag indicates whether the virtual gateway is a domain entry point (1 entry, 0 not entry). The second flag indicates whether the virtual gateway is a domain exit point (1 exit, 0 not exit). At least one of the first and second flags must be set to 1.
(8ビット)が設定する2のVG FLGSは、最も権利ビットに含まれたVG分野を解釈する方法を示しながら、弛みます。 進行は右にいなくなりました、と最初の旗は仮想のゲートウェイがドメインエントリー・ポイント(エントリーではなく、1つのエントリー、0)であるか否かに関係なく、示します。 2番目の旗は、仮想のゲートウェイがドメインエキジットポイント(出口ではなく、1つの出口、0)であるかどうかを示します。 少なくとも1番目と2番目の旗の1つを1に設定しなければなりません。
Steenstrup [Page 61] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[61ページ]RFC1479IDPRは1993年7月に議定書を作ります。
4.3.2. DYNAMIC
4.3.2. 動力
The DYNAMIC message type is equal to 1.
DYNAMICメッセージタイプは1に堪えます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD CMP | SEQ |
+-------------------------------+-------------------------------+
| UNAVL VG | NUM PS |
+-------------------------------+-------------------------------+
For each unavailable virtual gateway in the domain:
+-------------------------------+---------------+---------------+
| ADJ AD | VG | UNUSED |
+-------------------------------+---------------+---------------+
For each set of transit policies for the domain:
+-------------------------------+-------------------------------+
| NUM TP | NUM VG GRP |
+-------------------------------+-------------------------------+
| TP |
+-------------------------------+
For each virtual gateway group associated with the transit policy
set:
+-------------------------------+-------------------------------+
| NUM VG | ADJ AD |
+---------------+---------------+-------------------------------+
| VG | VG FLGS | NUM CMP |
+---------------+---------------+-------------------------------+
| ADJ CMP |
+-------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Cmp| SEQ| +-------------------------------+-------------------------------+ | UNAVL VG| ヌムPS| +-------------------------------+-------------------------------そのドメインのそれぞれの入手できない仮想のゲートウェイへの+: +-------------------------------+---------------+---------------+ | ADJ西暦| VG| 未使用| +-------------------------------+---------------+---------------それぞれのセットのドメインへの運送保険証券のための+: +-------------------------------+-------------------------------+ | ヌムTP| ヌムVG GRP| +-------------------------------+-------------------------------+ | TP| +-------------------------------それぞれの仮想のゲートウェイグループのための+は運送保険証券セットに関連づけました: +-------------------------------+-------------------------------+ | ヌムVG| ADJ西暦| +---------------+---------------+-------------------------------+ | VG| VG FLGS| ヌムCmp| +---------------+---------------+-------------------------------+ | ADJ Cmp| +-------------------------------+
AD CMP
(16 bits) Numeric identifier for the domain component containing
the AD representative policy gateway.
AD代表方針ゲートウェイを含むドメインコンポーネントのためのAD CMP(16ビット)の数値識別子。
SEQ (16 bits) Routing information message sequence number.
SEQ(16ビット)ルート設定情報メッセージ通番。
UNAVL VG (16 bits) Number of virtual gateways in the domain component
that are currently unavailable via any intra-domain routes.
ドメインコンポーネントにおける、仮想のゲートウェイの現在どんなイントラドメインルートでも入手できないUNAVL VG(16ビット)番号。
NUM PS (16 bits) Number of sets of transit policies listed. Transit
policy sets provide a mechanism for reducing the size of DYNAMIC
messages. A single set of virtual gateway groups applies to all
transit policies in a given set.
運送保険証券のNUM PS(16ビット)セット数は記載しました。 運送保険証券セットはDYNAMICメッセージのサイズを減少させるのにメカニズムを提供します。 1セットの仮想のゲートウェイグループは与えられたセットにおけるすべての運送保険証券に適用されます。
ADJ AD (16 bits) Numeric identifier for the adjacent domain to which
a virtual gateway connects.
仮想のゲートウェイが接続する隣接しているドメインのためのADJ AD(16ビット)の数値識別子。
Steenstrup [Page 62] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[62ページ]RFC1479IDPRは1993年7月に議定書を作ります。
VG (8 bits) Numeric identifier for a virtual gateway.
仮想のゲートウェイのためのVG(8ビット)の数値識別子。
UNUSED (8 bits) Not currently used; must be set equal to 0.
現在使用されていないUNUSED(8ビット)。 0と等しい状態で設定しなければなりません。
NUM TP (16 bits) Number of transit policies in a set.
セットにおける、運送保険証券のNUM TP(16ビット)番号。
NUM VGGRP (16 bits) Number of virtual gateway groups currently
associated with the transit policy set.
現在運送保険証券に関連している仮想のゲートウェイグループのNUM VGGRP(16ビット)番号はセットしました。
TP (16 bits) Numeric identifier for a transit policy.
運送保険証券のためのTP(16ビット)の数値識別子。
NUM VG (16 bits) Number of virtual gateways in a virtual gateway
group.
仮想のゲートウェイの仮想のゲートウェイのNUM VG(16ビット)番号は分類されます。
VG FLGS (8 bits) Set of two flags indicating how to interpret the VG
field, contained in the right-most bits. Proceeding left to
right, the first flag indicates whether the virtual gateway is a
domain entry point (1 entry, 0 not entry). The second flag
indicates whether the virtual gateway is a domain exit point (1
exit, 0 not exit). At least one of the first and second flags
must be set to 1.
(8ビット)が設定する2のVG FLGSは、最も権利ビットに含まれたVG分野を解釈する方法を示しながら、弛みます。 進行は右にいなくなりました、と最初の旗は仮想のゲートウェイがドメインエントリー・ポイント(エントリーではなく、1つのエントリー、0)であるか否かに関係なく、示します。 2番目の旗は、仮想のゲートウェイがドメインエキジットポイント(出口ではなく、1つの出口、0)であるかどうかを示します。 少なくとも1番目と2番目の旗の1つを1に設定しなければなりません。
NUM CMP (16 bits) Number of adjacent domain components reachable via
direct connections through the virtual gateway.
仮想のゲートウェイを通したダイレクト接続を通して届いている隣接しているドメインコンポーネントのNUM CMP(16ビット)番号。
ADJ CMP (16 bits) Numeric identifier for a reachable adjacent domain
component.
届いている隣接しているドメインコンポーネントのためのADJ CMP(16ビット)の数値識別子。
4.3.3. Negative Acknowledgements
4.3.3. 否定的承認
When a policy gateway or route server receives an unacceptable IDPR routing information message that passes the CMTP validation checks, it includes, in its CMTP ACK, an appropriate negative acknowledgement. This information is placed in the INFORM field of the CMTP ACK (described previously in section 2.4); the numeric identifier for each type of routing information message negative acknowledgement is contained in the left-most 8 bits of the INFORM field. Negative acknowledgements associated with routing information messages include the following types:
方針ゲートウェイかルートサーバがCMTP合法化チェックを通過する容認できないIDPRルーティング情報メッセージを受け取るとき、それはCMTP ACKに適切な否定的承認を含んでいます。 この情報はCMTP ACK(以前に、セクション2.4で説明される)のINFORM分野に置かれます。 情報メッセージの否定的承認を発送する各タイプにおける数値の識別子はINFORM分野の最も左の8ビットに含まれています。 ルーティング情報メッセージに関連している否定的承認は以下のタイプを含んでいます:
1. Unrecognized IDPR routing information message type. Numeric
identifier for the unrecognized message type (8 bits).
1. 情報メッセージを発送する認識されていないIDPRがタイプします。 認識されていないメッセージタイプ(8ビット)における数値の識別子。
2. Out-of-date IDPR routing information message. This is a signal
to the sender that it may not have the most recent routing
information for the given domain.
2. 時代遅れなIDPRルーティング情報メッセージ。 これは送付者へのそれには与えられたドメインのための最新のルーティング情報がないかもしれないという信号です。
Steenstrup [Page 63] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[63ページ]RFC1479IDPRは1993年7月に議定書を作ります。
5. Route Server Query Protocol
5. ルートサーバ質問プロトコル
Each route server is responsible for maintaining both the routing information database and the route database and for responding to database information requests from policy gateways and other route servers. These requests and their responses are the messages exchanged via the Route Server Query Protocol (RSQP).
それぞれのルートサーバは両方がルーティング情報データベースとルートデータベースであることを支持して、方針ゲートウェイと他のルートサーバからデータベース情報要求に応じるのに原因となります。 これらの要求と彼らの応答はRoute Server Queryプロトコル(RSQP)で交換されたメッセージです。
Policy gateways and route servers normally invoke RSQP to replace absent, outdated, or corrupted information in their own routing information or route databases. In section 4, we discussed some of the situations in which RSQP may be invoked; in this section and in section 7, we discuss other such situations.
通常、方針ゲートウェイとルートサーバは、それら自身のルーティング情報かルートデータベースの休んでいるか、時代遅れの、または、崩壊した情報を置き換えるためにRSQPを呼び出します。 セクション4で、私たちはRSQPが呼び出されるかもしれない状況のいくつかについて議論しました。 このセクションとセクション7で、私たちは他のそのような状況について議論します。
5.1. Message Exchange
5.1. 交換処理
Policy gateways and route servers use CMTP for reliable transport of route server requests and responses. RSQP must communicate to CMTP the maximum number of transmissions per request/response message, rsqp_ret, and the interval between request/response message retransmissions, rsqp_int microseconds. A route server request/response message is "acceptable" if:
方針ゲートウェイとルートサーバはルートサーバ要求と応答の信頼できる輸送にCMTPを使用します。 RSQPは要求/応答メッセージ「再-トランスミッション」の要求/応答メッセージあたりのトランスミッション、_が浸水させるrsqp、および間隔の最大数をCMTPに伝えなければなりません、rsqp_intマイクロセカンド。 ルートサーバ要求/応答メッセージが「許容できる」、:
- It passes the CMTP validation checks.
- それはCMTP合法化チェックを通過します。
- Its timestamp is less than rsqp_old (300) seconds behind the
recipient's internal clock time.
- タイムスタンプは受取人の内部クロック時間の(300)秒後ろで古いrsqp_より少ないです。
With RSQP, a requesting entity expects to receive an acknowledgement from the queried route server indicating whether the route server can accommodate the request. The route server may fail to fill a given request for either of the following reasons:
RSQPと共に、要求実体は、ルートサーバが要求に対応できるかどうかを示す質問されたルートサーバから承認を受けると予想します。 ルートサーバは以下の理由のどちらかを求める与えられた要求をいっぱいにしないかもしれません:
- Its corresponding database contains no entry or only a partial
entry for the requested information.
- 対応するデータベースは求められた情報のためのどんなエントリーも部分的なエントリーだけも含んでいません。
- It is governed by special message distribution rules, imposed by
the domain administrator, that preclude it from releasing the
requested information. Currently, such distribution rules are not
included in IDPR configuration information.
- それは求められた情報を発表するのでそれを排除するドメイン管理者によって課された特別教書分配規則で治められます。 現在、そのような分配規則はIDPR設定情報に含まれていません。
For all requests that it cannot fill, the route server responds with a negative acknowledgement message carried in a CMTP acknowledgement, indicating the set of unfulfilled requests (see section 5.5.4).
いっぱいになることができないというすべての要求のために、否定的確認メッセージがCMTP承認で運ばれている状態で、ルートサーバは反応します、満たされていない要求のセットを示して(セクション5.5.4を見てください)。
If the requesting entity either receives a negative acknowledgement or does not receive any acknowledgement after rsqp_ret attempts directed at the same route server, it queries a different route
rsqp_が同じルートサーバが向けられた試みを浸水させた後に、要求実体が否定的承認を受けるか、または少しの承認も受けないなら、それは異なったルートを質問します。
Steenstrup [Page 64] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[64ページ]RFC1479IDPRは1993年7月に議定書を作ります。
server, as long as the number of attempted requests to different route servers does not exceed rsqp_try (3). Specifically, the requesting entity proceeds in round-robin order through its list of addressable route servers. However, if the requesting entity is unsuccessful after rsqp_try attempts, it abandons the request altogether and logs the event for network management.
異なったルートサーバへの試みられた要求の数がrsqp_トライ(3)を超えていない限り、サーバ。 明確に、要求実体はアドレス可能なルートサーバのリストを通した連続オーダーで続きます。 しかしながら、要求実体が失敗しているならrsqp_の後に試みが試みていて、それは、全体で要求を捨てて、ネットワークマネージメントのためにイベントを登録します。
A policy gateway or a route server can request information from any route server that it can address. Addresses for local route servers within a domain are part of the configuration for each IDPR entity within a domain; addresses for remote route servers in other domains are obtained through flooded CONFIGURATION messages, as described previously in section 4.2.1. However, requesting entities always query local route servers before remote route servers, in order to contain the costs associated with the query and response. If the requesting entity and the queried route server are in the same domain, they can communicate over intra-domain routes, whereas if the requesting entity and the queried route server are in different domains, they must obtain a policy route and establish a path before they can communicate, as we describe below.
方針ゲートウェイかルートサーバがそれが扱うことができるどんなルートサーバからも情報を要求できます。 ドメインの中のローカルのルートサーバのためのアドレスはドメインの中のそれぞれのIDPR実体のための構成の一部です。 以前にセクション4.2.1で説明されるように水につかっているCONFIGURATIONメッセージを通して他のドメインのリモートルートサーバのためのアドレスを得ます。 しかしながら、実体を要求して、リモートルートサーバの前にいつもローカルのルートサーバについて質問してください、質問と応答に関連しているコストを含むように。 要求実体と質問されたルートサーバが同じドメインにあるなら、彼らはイントラドメインルートの上で交信できます、要求実体と質問されたルートサーバが異なったドメインにあるなら、交信できる前に、方針ルートを入手して、経路を確立しなければなりませんが、私たちが以下で説明するように。
5.2. Remote Route Server Communication
5.2. リモートルートサーバコミュニケーション
RSQP communication involving a remote route server requires a policy route and accompanying path setup (see section 7) between the requesting and queried entities, as these entities reside in different domains. After generating a request message, the requesting entity hands to CMTP its request message along with the remote route server's entity and domain identifiers. CMTP encloses the request in a DATAGRAM and hands the DATAGRAM and remote route server information to the path agent. Using the remote route server information, the path agent obtains, and if necessary sets up, a path to the remote route server. Once the path to the remote route server has been successfully established, the path agent encapsulates the DATAGRAM within an IDPR data message and forwards the data message along the designated path.
リモートルートサーバにかかわるRSQPコミュニケーションが要求していて質問された実体の間で方針ルートと付随の経路セットアップを必要とします(セクション7を見ます)、これらの実体が異なったドメインにあるとき。 要求メッセージを生成した後に、要求実体はリモートルートサーバの実体とドメイン識別子に伴う要求メッセージをCMTPに手渡します。 CMTPはデータグラムで要求を同封して、データグラムとリモートルートサーバ情報を経路エージェントに手渡します。 リモートルートサーバ情報を使用して、経路エージェントは、リモートルートサーバに経路を得て、必要なら、セットアップします。リモートルートサーバへの経路がいったん首尾よく確立されると、経路エージェントは、指定された経路に沿ってIDPRデータメッセージとフォワードの中のデータグラムがデータメッセージであるとカプセル化します。
When the path agent in the remote route server receives the IDPR data message, it extracts the DATAGRAM and hands it to CMTP. In addition, the path agent, using the requesting entity and domain identifiers contained in the path identifier, obtains, and if necessary sets up, a path back to the requesting entity.
リモートルートサーバの経路エージェントがIDPRデータメッセージを受け取るとき、それは、データグラムを抜粋して、CMTPを尊敬します。 経路識別子に含まれた要求実体とドメイン識別子を使用して、経路エージェントは、さらに、要求実体に経路を得て、必要なら、セットアップして戻します。
If the DATAGRAM fails any of the CMTP validation checks, CMTP returns a NAK to the requesting entity. If the DATAGRAM passes all of the CMTP validation checks, the remote route server assesses the acceptability of the request message. Provided the request message is acceptable, the remote route server determines whether it can
データグラムがCMTP合法化チェックをいくらかしそこなうなら、CMTPは要求実体にNAKを返します。 データグラムがCMTP合法化チェックのすべてを通過するなら、リモートルートサーバは要求メッセージの受容性を評価します。 要求メッセージが許容できるなら、リモートルートサーバは、それがそうすることができるかどうか決定します。
Steenstrup [Page 65] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[65ページ]RFC1479IDPRは1993年7月に議定書を作ります。
fulfill the request and directs CMTP to return an ACK to the requesting entity. The ACK may contain a negative acknowledgement if the entire request cannot be fulfilled.
要求を実現させて、要求実体にACKを返すようCMTPに指示します。 全体の要求が実現できないなら、ACKは否定的承認を含むかもしれません。
The remote route server generates responses for all requests that it can fulfill and returns the responses to the requesting entity. Specifically, the remote route server hands to CMTP its response and the requesting entity information. CMTP in turn encloses the response in a DATAGRAM.
リモートルートサーバは、それが実現させることができるすべての要求のための応答を生成して、要求実体への応答を返します。 明確に、リモートルートサーバは応答と要求している実体情報をCMTPに手渡します。 CMTPはデータグラムで順番に応答を同封します。
When returning an ACK, a NAK, or a response to the requesting entity, the remote route server hands the corresponding CMTP message and requesting entity information to the path agent. Using the requesting entity information, the path agent retrieves the path to the requesting entity, encapsulates the CMTP message within an IDPR data message, and forwards the data message along the designated path.
要求実体へのACK、NAK、または応答を返すとき、リモートルートサーバは対応するCMTPメッセージと要求に経路エージェントへの実体情報を手渡します。 要求している実体情報を使用して、経路エージェントは、指定された経路に沿って要求実体に経路を検索して、IDPRデータメッセージの中でCMTPメッセージをカプセル化して、データメッセージを転送します。
When the path agent in the requesting entity receives the IDPR data message, it extracts the ACK, NAK, or response to its request and performs the CMTP validation checks for that message. In the case of a response messsage, the requesting entity also assesses message acceptability before incorporating the contents into the appropriate database.
要求実体における経路エージェントがIDPRデータメッセージを受け取るとき、それは、ACK、NAK、または要求への応答を抽出して、そのメッセージのためのCMTP合法化チェックを実行します。 また、応答messsageの場合では、適切なデータベースにコンテンツを組み入れる前に、要求実体はメッセージの受容性を評価します。
5.3 Routing Information
5.3 経路情報
Policy gateways and route servers request routing information from route servers, in order to update their routing information databases. To obtain routing information from a route server, the requesting entity issues a ROUTING INFORMATION REQUEST message containing the type of routing information requested - CONFIGURATION messages, DYNAMIC messages, or both - and the set of domains from which the routing information is requested.
方針ゲートウェイとルートサーバは、それらのルーティング情報データベースをアップデートするためにルートサーバからルーティング情報を要求します。 ルートサーバからルーティング情報を得るために、要求実体は情報が要求したルーティングのタイプ(CONFIGURATIONメッセージ、DYNAMICメッセージ、または両方)とルーティング情報が要求されるドメインのセットを含むROUTING INFORMATION REQUESTメッセージを発行します。
Upon receiving a ROUTING INFORMATION REQUEST message, a route server first assesses message acceptability before proceeding to act on the contents. If the ROUTING INFORMATION REQUEST message is deemed acceptable, the route server determines how much of the request it can fulfill and then instructs CMTP to generate an acknowledgement, indicating its ability to fulfill the request. The route server proceeds to fulfill as much of the request as possible by reconstructing individual routing information messages, one per requested message type and domain, from its routing information database. We note that only a regenerated routing information message whose entire contents match that of the original routing information message may pass the CMTP integrity/authentication checks.
ROUTING INFORMATION REQUESTメッセージを受け取ると、コンテンツに影響しかける前に、ルートサーバは最初に、メッセージの受容性を評価します。 ROUTING INFORMATION REQUESTメッセージが許容できると考えられるなら、ルートサーバは、それが要求のどのくらいを実現させることができるかを決定して、承認を生成するようCMTPに命令します、要求を実現させる性能を示して。 ルートサーバは、個々のルーティング情報メッセージと要求されたメッセージタイプあたり1つとルーティング情報データベースからのドメインを再建することによって、できるだけ多くの要求を実現させかけます。 私たちは、全体のコンテンツがオリジナルのルーティング情報メッセージのものに合っている作り直されたルーティング情報メッセージだけがCMTP保全/認証チェックを通過するかもしれないことに注意します。
Steenstrup [Page 66] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[66ページ]RFC1479IDPRは1993年7月に議定書を作ります。
5.4. Routes
5.4. ルート
Path agents request routes from route servers when they require policy routes for path setup. To obtain routes from a route server, the requesting path agent issues a ROUTE REQUEST message containing the destination domain and applicable service requirements, the maximum number of routes requested, a directive indicating whether to generate the routes or retrieve them from the route database, and a directive indicating whether to refresh the routing information database with the most recent CONFIGURATION or DYNAMIC message from a given domain, before generating the routes. To refresh its routing information database, a route server must obtain routing information from another route server. The path agent usually issues routing information database refresh directives in response to a failed path setup. We discuss the application of these directives in more detail in section 7.4.
彼らが経路セットアップのための方針ルートを必要とするとき、経路エージェントはルートサーバからルートを要求します。 ルートサーバ、要求からルートを入手するために、経路エージェントは目的地ドメインと適切なサービス要件を含むROUTE REQUESTメッセージを発行します、とルートの最大数は要求しました、指示がルートを生成するか、ルートデータベースからそれらを検索して、または与えられたドメインから最新のCONFIGURATIONかDYNAMICメッセージでルーティング情報データベースをリフレッシュするかどうかを示す指示を検索するかを示して、ルートを生成する前に。 ルーティング情報データベースをリフレッシュするために、ルートサーバは別のルートサーバからルーティング情報を得なければなりません。通常、経路エージェントは失敗した経路セットアップに対応して情報データベースがリフレッシュするルーティングに指示を発行します。 私たちはさらに詳細にセクション7.4でこれらの指示の応用について議論します。
Upon receiving a ROUTE REQUEST message, a route server first assesses message acceptability before proceeding to act on the contents. If the ROUTE REQUEST message is deemed acceptable, the route server determines whether it can fulfill the request and then instructs CMTP to generate an acknowledgement, indicating its ability to fulfill the request. The route server proceeds to fulfill the request with policy routes, either retrieved from its route database or generated from its routing information database if necessary, and returns these routes in a ROUTE RESPONSE message.
ROUTE REQUESTメッセージを受け取ると、コンテンツに影響しかける前に、ルートサーバは最初に、メッセージの受容性を評価します。 ROUTE REQUESTメッセージが許容できると考えられるなら、ルートサーバは、それが要求を実現させることができるかどうか決定して、承認を生成するようCMTPに命令します、要求を実現させる性能を示して。 ルートサーバは、ルートデータベースから検索されるか、または必要なら、ルーティング情報データベースから生成された方針ルートによる要求を実現させかけて、ROUTE RESPONSEメッセージでこれらのルートを返します。
5.5. Route Server Message Formats
5.5. ルートサーバメッセージ・フォーマット
The route server query protocol number is equal to 2. We describe the contents of each type of RSQP message below.
ルートサーバ質問プロトコル番号は2と等しいです。 私たちは以下のそれぞれのタイプに関するRSQPメッセージのコンテンツについて説明します。
5.5.1. ROUTING INFORMATION REQUEST
5.5.1. 経路情報要求
The ROUTING INFORMATION REQUEST message type is equal to 0.
ROUTING INFORMATION REQUESTメッセージタイプは0に堪えます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QRY AD | QRY RS |
+-------------------------------+-------------------------------+
| NUM AD | AD |
+---------------+---------------+-------------------------------+
| RIM FLGS | UNUSED |
+---------------+---------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QRY西暦| QRY RS| +-------------------------------+-------------------------------+ | ヌム西暦| 西暦| +---------------+---------------+-------------------------------+ | 縁のFLGS| 未使用| +---------------+---------------+
QRY AD
(16 bits) Numeric identifier for the domain containing the
ドメイン含有のためのQRY AD(16ビット)の数値識別子
Steenstrup [Page 67] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[67ページ]RFC1479IDPRは1993年7月に議定書を作ります。
queried route server.
ルートサーバについて質問しました。
QRY RS (16 bits) Numeric identifier for the queried route server.
質問されたルートサーバのためのQRY RS(16ビット)の数値識別子。
NUM AD (16 bits) Number of domains about which routing information is
requested. The value 0 indicates a request for routing
information from all domains.
ドメインのNUM AD(16ビット)番号はどのルーティング情報に関して要求されているか。 値0はすべてのドメインからルーティング情報に関する要求を示します。
AD (16 bits) Numeric identifier for a domain. This field is absent
when NUM AD equals 0.
ドメインのためのAD(16ビット)の数値識別子。 NUM ADが0と等しいときに、この分野は欠けています。
RIM FLGS (8 bits) Set of two flags indicating the type of routing
information messages requested, contained in the right-most
bits. Proceeding left to right, the first flag indicates
whether the request is for a CONFIGURATION message (1
CONFIGURATION, 0 no CONFIGURATION). The second flag indicates
whether the request is for a DYNAMIC message (1 DYNAMIC, 0 no
DYNAMIC). At least one of the first and second flags must be
set to 1.
(8ビット)が設定する2のRIM FLGSは、最も権利ビットに要求されて、含まれたルーティング情報メッセージのタイプを示しながら、弛みます。 進行は右にいなくなりました、と最初の旗は要求がCONFIGURATIONメッセージ(1CONFIGURATION、0ノーCONFIGURATION)のためのものであるか否かに関係なく、示します。 2番目の旗は、要求がDYNAMICメッセージ(1DYNAMIC、0ノーDYNAMIC)のためのものであるかを示します。 少なくとも1番目と2番目の旗の1つを1に設定しなければなりません。
UNUSED (8 bits) Not currently used; must be set equal to 0.
現在使用されていないUNUSED(8ビット)。 0と等しい状態で設定しなければなりません。
5.5.2. ROUTE REQUEST
5.5.2. ルート要求
The ROUTE REQUEST message type is equal to 1.
ROUTE REQUESTメッセージタイプは1に堪えます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QRY AD | QRY RS |
+-------------------------------+-------------------------------+
| SRC AD | HST SET |
+---------------+---------------+-------------------------------+
| UCI | UNUSED | NUM RQS |
+---------------+---------------+-------------------------------+
| DST AD | PRX AD |
+---------------+---------------+-------------------------------+
| NUM RTS | GEN FLGS | RFS AD |
+---------------+---------------+-------------------------------+
| NUM AD |
+-------------------------------+
For each domain to be favored, avoided, or excluded:
+-------------------------------+---------------+---------------+
| AD | AD FLGS | UNUSED |
+-------------------------------+---------------+---------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QRY西暦| QRY RS| +-------------------------------+-------------------------------+ | SRC西暦| HSTはセットしました。| +---------------+---------------+-------------------------------+ | UCI| 未使用| ヌムRQS| +---------------+---------------+-------------------------------+ | DST西暦| PRX西暦| +---------------+---------------+-------------------------------+ | ヌムRTS| FLGSに情報を得てください。| RFS西暦| +---------------+---------------+-------------------------------+ | ヌム西暦| +-------------------------------各ドメインが支持される+避けられるか、または除かれて、 +-------------------------------+---------------+---------------+ | 西暦| AD FLGS| 未使用| +-------------------------------+---------------+---------------+
Steenstrup [Page 68] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[68ページ]RFC1479IDPRは1993年7月に議定書を作ります。
For each requested service: +-------------------------------+-------------------------------+ | RQS TYP | RQS LEN | +-------------------------------+-------------------------------+ | RQS SRV | +---------------------------------------------------------------+
それぞれがサービスを要求したので: +-------------------------------+-------------------------------+ | RQS TYP| RQSレン| +-------------------------------+-------------------------------+ | RQS SRV| +---------------------------------------------------------------+
QRY AD
(16 bits) Numeric identifier for the domain containing the
queried route server.
質問されたルートサーバを含むドメインのためのQRY AD(16ビット)の数値識別子。
QRY RS (16 bits) Numeric identifier for the queried route server.
質問されたルートサーバのためのQRY RS(16ビット)の数値識別子。
SRC AD (16 bits) Numeric identifier for the route's source domain.
ルートのソースドメインのためのSRC AD(16ビット)の数値識別子。
HST SET (16 bits) Numeric identifier for the source's host set.
HST SET(16ビット)のソースのホストにとっての数値の識別子はセットしました。
UCI (8 bits) Numeric identifier for the source user class. The value
0 indicates that there is no particular source user class.
UCI(8ビット)のソースユーザ・クラスにおける数値の識別子。 値0は、どんな特定のソースユーザ・クラスもないのを示します。
UNUSED (8 bits) Not currently used; must be set equal to 0.
現在使用されていないUNUSED(8ビット)。 0と等しい状態で設定しなければなりません。
NUM RQS (16 bits) Number of requested services. The value 0
indicates that the source requests no special services.
要求されたサービスのNUM RQS(16ビット)番号。 値0は、情報筋が特殊業務を全く要求しないのを示します。
DST AD (16 bits) Numeric identifier for the route's destination
domain.
ルートの目的地ドメインのためのDST AD(16ビット)の数値識別子。
PRX AD (16 bits) Numeric identifier for the destination domain's
proxy (see section 1.3.1). If the destination domain provides
the path agent function for its hosts, then the destination and
proxy domains are identical. A route server constructs routes
between the source domain's proxy and the destination domain's
proxy. We note that the source domain's proxy is identical to
the domain issuing the CMTP message containing the ROUTE REQUEST
message, and hence available in the CMTP header.
PRX AD(16ビット)の目的地ドメインのプロキシ(セクション1.3.1を見る)における数値の識別子。 目的地ドメインが経路エージェント機能をホストに提供するなら、目的地とプロキシドメインは同じです。 ルートサーバはソースドメインのプロキシと目的地ドメインのプロキシの間のルートを構成します。 私たちは、ソースドメインのプロキシがROUTE REQUESTメッセージを含むCMTPメッセージを発行するドメインと同じであって、したがって、CMTPヘッダーに手があいていることに注意します。
NUM RTS (8 bits) Number of policy routes requested.
方針ルートの数が要求したNUM RTS(8ビット)。
GEN FLGS (8 bits) Set of three flags indicating how to obtain the
requested routes, contained in the right-most bits. Proceeding
left to right, the first flag indicates whether the route server
should retrieve existing routes from its route database or
generate new routes (1 retrieve, 0 generate). The second flag
indicates whether the route server should refresh its routing
information database before generating the requested routes (1
refresh, 0 no refresh) and when set to 1, causes the third flag
and the RFS AD field to become significant. The third flag
(8ビット)が設定する3のGEN FLGSは、最も権利ビットに含まれた要求されたルートを入手する方法を示しながら、弛みます。 進行は右にいなくなりました、とルートサーバがルートデータベースから既存のルートを検索するべきであるか、または新しいルートを生成するべきであることにかかわらず最初の旗は示します。(1が検索する、0が生成する、) 2番目の旗は、ルートサーバが要求されたルート(1はリフレッシュして、0ノー、はリフレッシュする)を生成して、前1に設定されるという場合にルーティング情報データベースをリフレッシュするべきであるかどうかを示します、3番目の旗とRFS ADが重要になるようにさばく原因。 3番目の旗
Steenstrup [Page 69] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[69ページ]RFC1479IDPRは1993年7月に議定書を作ります。
indicates whether the routing information database refresh
should include CONFIGURATION messages or DYNAMIC messages (1
configuration, 0 dynamic).
ルーティング情報データベースがリフレッシュするかどうかがCONFIGURATIONメッセージかDYNAMICメッセージ(1つの構成、0動力)を含むべきであるのを示します。
RFS AD (16 bits) Numeric identifier for the domain for which routing
information should be refreshed. This field is meaningful only
if the second flag in the GEN FLGS field is set to 1.
ルーティング情報がリフレッシュされるべきであるドメインのためのRFS AD(16ビット)の数値識別子。 GEN FLGS分野における2番目の旗が1に設定される場合にだけ、この分野は重要です。
NUM AD (16 bits) Number of transit domains that are to be favored,
avoided, or excluded during route selection (see section 1.4.1).
ルート選択(セクション1.4.1を見る)の間に支持されることになっているか、避けられることになっているか、または除かれることになっているトランジットドメインのNUM AD(16ビット)番号。
AD (16 bits) Numeric identifier for a transit domain to be favored,
avoided, or excluded.
トランジットドメインが支持されるか、避けられるか、または除かれるAD(16ビット)の数値識別子。
AD FLGS (8 bits) Three flags indicating how to interpret the AD
field, contained in the right-most bits. Proceeding left to
right, the first flag indicates whether the domain should be
favored (1 favored, 0 not favored). The second flag indicates
whether the domain should be avoided (1 avoided, 0 not avoided).
The third flag indicates whether the domain should be excluded
(1 excluded, 0 not excluded). No more than one of the first,
second, and third flags must set to 1.
最も権利ビットに含まれたAD分野を解釈する方法を示すAD FLGS(8ビット)3個の旗。 ドメインが支持されるべきである(支持された1、支持されなかった0)か否かに関係なく、最初の旗は、進行が右にいなくなったのを示します。 2番目の旗は、ドメインが避けられるべきであるかどうかを(避けられた1、避けられなかった0)示します。 3番目の旗は、ドメインが除かれるべきであるかどうかを(除かれた1、除かれなかった0)示します。 1番目、2番目、および3番目の旗の1つ未満は1にセットしなければなりません。
RQS TYP (16 bits) Numeric identifier for a type of requested service.
Valid requested services include the following types:
一種の要求されたサービスのためのRQS TYP(16ビット)の数値識別子。 有効な要求されたサービスは以下のタイプを含んでいます:
1. Upper bound on delay, in milliseconds (16 bits). This attribute
may be omitted.
1. ミリセカンドの遅れ(16ビット)に関する上限。 この属性は省略されるかもしれません。
2. Minimum delay route. This attribute may be omitted.
2. 最小の遅れルート。 この属性は省略されるかもしれません。
3. Upper bound on delay variation, in milliseconds (16 bits). This
attribute may be omitted.
3. ミリセカンドの遅れ変化(16ビット)に関する上限。 この属性は省略されるかもしれません。
4. Minimum delay variation route. This attribute may be omitted.
4. 最小の遅れ変化ルート。 この属性は省略されるかもしれません。
5. Lower bound on bandwidth, in bits per second (48 bits). This
attribute may be omitted.
5. bpsにおける帯域幅(48ビット)にバウンドを下ろしてください。 この属性は省略されるかもしれません。
6. Maximum bandwidth route. This attribute may be omitted.
6. 最大の帯域幅ルート。 この属性は省略されるかもしれません。
7. Upper bound on monetary cost, in cents (32 bits). This attribute
may be omitted.
7. セントで表現される貨幣原価(32ビット)に関する上限。 この属性は省略されるかもしれません。
8. Minimum monetary cost route. This attribute may be omitted.
8. 最小の貨幣原価ルート。 この属性は省略されるかもしれません。
9. Path lifetime in minutes (16 bits). This attribute may be omitted
but must be present if types 7 or 8 are present. Route servers
9. 数分間(16ビット)の経路生涯。 この属性は、省略されるかもしれませんが、タイプ7か8が出席しているなら、存在していなければなりません。 ルートサーバ
Steenstrup [Page 70] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[70ページ]RFC1479IDPRは1993年7月に議定書を作ります。
use path lifetime information together with domain charging
method to compute expected session monetary cost over a given
domain.
与えられたドメインに関して予想されたセッション貨幣原価を計算するドメイン充電メソッドと共に経路生涯情報を使用してください。
10. Path lifetime in messages (16 bits). This attribute may be
omitted but must be present if types 7 or 8 are present.
10. メッセージ(16ビット)の経路生涯。 この属性は、省略されるかもしれませんが、タイプ7か8が出席しているなら、存在していなければなりません。
11. Path lifetime in bytes (48 bits). This attribute may be omitted
but must be present if types 7 or 8 are present.
11. バイト(48ビット)で表現される経路生涯。 この属性は、省略されるかもしれませんが、タイプ7か8が出席しているなら、存在していなければなりません。
RQS LEN
(16 bits) Length of the requested service, in bytes, beginning
with the next field.
次の分野で始まるバイトで表現される要求されたサービスのRQS LEN(16ビット)の長さ。
RQS SRV
(variable) Description of the requested service.
要求されたサービスのRQS SRVの(可変)の記述。
5.5.3. ROUTE RESPONSE
5.5.3. ルート応答
The ROUTE RESPONSE message type is equal to 2.
ROUTE RESPONSEメッセージタイプは2に堪えます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NUM RTS |
+---------------+
For each route provided:
+---------------+---------------+
| NUM AD | RTE FLGS |
+---------------+---------------+
For each domain in the route:
+---------------+---------------+-------------------------------+
| AD LEN | VG | ADJ AD |
+---------------+---------------+-------------------------------+
| ADJ CMP | NUM TP |
+-------------------------------+-------------------------------+
| TP |
+-------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ヌムRTS| +---------------各ルートへの+は提供しました: +---------------+---------------+ | ヌム西暦| RTE FLGS| +---------------+---------------ルートの各ドメインへの+: +---------------+---------------+-------------------------------+ | ADレン| VG| ADJ西暦| +---------------+---------------+-------------------------------+ | ADJ Cmp| ヌムTP| +-------------------------------+-------------------------------+ | TP| +-------------------------------+
NUM RTS
(16 bits) Number of policy routes provided.
方針ルートのNUM RTS(16ビット)番号は提供されました。
RTE FLGS (8 bits) Set of two flags indicating the directions in which
a route can be used, contained in the right-most bits. Refer to
sections 6.2, 7, and 7.2 for detailed discussions of path
directionality. Proceeding left to right, the first flag
indicates whether the route can be used from source to
destination (1 from source, 0 not from source). The second flag
(8ビット)が設定する2のRTE FLGSは、ルートが最も権利ビットに中古で、含むことができる方向を示しながら、弛みます。 経路の方向性の詳細な論議についてセクション6.2、7、および7.2を参照してください。 進行は右にいなくなりました、とソースから目的地(ソースでないのからのソースからの1、0)までルートを使用できるか否かに関係なく、最初の旗は示します。 2番目の旗
Steenstrup [Page 71] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[71ページ]RFC1479IDPRは1993年7月に議定書を作ります。
indicates whether the route can be used from destination to
source (1 from destination, 0 not from destination). At least
one of the first and second flags must be set to 1, if NUM RTS
is greater than 0.
目的地からソース(目的地でないのからの目的地からの1、0)までルートを使用できるか否かに関係なく、示します。 少なくとも1番目と2番目の旗の1つを1に設定しなければなりません、NUM RTSが0歳以上であるなら。
NUM AD (8 bits) Number of domains in the policy route, not including
the first domain on the route.
ルートの上の最初のドメインを含まない方針ルートによるドメインのNUM AD(8ビット)番号。
AD LEN (8 bits) Length of the information associated with a
particular domain, in bytes, beginning with the next field.
次の分野でバイトで始まる特定のドメインに関連している情報のAD LEN(8ビット)の長さ。
VG (8 bits) Numeric identifier for an exit virtual gateway.
出口の仮想のゲートウェイのためのVG(8ビット)の数値識別子。
ADJ AD (16 bits) Numeric identifier for the adjacent domain connected
to the virtual gateway.
隣接しているドメインのためのADJ AD(16ビット)の数値識別子は仮想のゲートウェイに接続しました。
ADJ CMP (16 bits) Numeric identifier for the adjacent domain
component. Used by policy gateways to select a route across a
virtual gateway connecting to a partitioned domain.
隣接しているドメインコンポーネントのためのADJ CMP(16ビット)の数値識別子。 方針ゲートウェイによって使用されて、仕切られたドメインに接続しながら、仮想のゲートウェイの向こう側にルートを選択します。
NUM TP (16 bits) Number of transit policies that apply to the section
of the route traversing the domain component.
ドメインコンポーネントを横断しながらルートのセクションに適用される運送保険証券のNUM TP(16ビット)番号。
TP (16 bits) Numeric identifier for a transit policy.
運送保険証券のためのTP(16ビット)の数値識別子。
5.5.4. Negative Acknowledgements
5.5.4. 否定的承認
When a policy gateway receives an unacceptable RSQP message that passes the CMTP validation checks, it includes, in its CMTP ACK, an appropriate negative acknowledgement. This information is placed in the INFORM field of the CMTP ACK (described previously in section 2.4); the numeric identifier for each type of RSQP negative acknowledgement is contained in the left-most 8 bits of the INFORM field. Negative acknowledgements associated with RSQP include the following types:
方針ゲートウェイがCMTP合法化チェックを通過する容認できないRSQPメッセージを受け取るとき、それはCMTP ACKに適切な否定的承認を含んでいます。 この情報はCMTP ACK(以前に、セクション2.4で説明される)のINFORM分野に置かれます。 それぞれのタイプのRSQPの否定的承認のための数値識別子はINFORM分野の最も左の8ビットに含まれています。 RSQPに関連している否定的承認は以下のタイプを含んでいます:
1. Unrecognized RSQP message type. Numeric identifier for the
unrecognized message type (8 bits).
1. 認識されていないRSQPメッセージタイプ。 認識されていないメッセージタイプ(8ビット)における数値の識別子。
2. Out-of-date RSQP message.
2. 時代遅れなRSQPメッセージ。
3. Unable to fill requests for routing information from the
following domains. Number of domains for which requests cannot
be filled (16 bits); a value of 0 indicates that the route
server cannot fill any of the requests. Numeric identifier for
each domain for which a request cannot be filled (16 bits).
3. 以下のドメインからのルーティング情報に関する要求をいっぱいにすることができません。 要求をいっぱいにすることができないドメイン(16ビット)の数。 0の値は、ルートサーバが要求のどれかをいっぱいにすることができないのを示します。 要求をいっぱいにすることができない各ドメイン(16ビット)のための数値識別子。
Steenstrup [Page 72] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[72ページ]RFC1479IDPRは1993年7月に議定書を作ります。
4. Unable to fill requests for routes to the following destination
domain. Numeric identifier for the destination domain (16 bits).
4. 以下の目的地ドメインにルートを求める要求をいっぱいにすることができません。 目的地ドメイン(16ビット)のための数値識別子。
6. Route Generation
6. ルート世代
Route generation is the most computationally complex part of IDPR, because of the number of domains and the number and heterogeneity of policies that it must accommodate. Route servers must generate policy routes that satisfy the requested services of the source domains and respect the offered services of the transit domains.
ルート世代はIDPRの最も計算上複雑な部分です、それが収容しなければならない方針のドメインの数、数、および異種性のために。 ルートサーバはソースドメインと敬意の要求されたサービスを満たす方針ルートにトランジットドメインの提供サービスを生成しなければなりません。
We distinguish requested qualities of service and route generation with respect to them as follows:
私たちは以下の通りそれらに関してサービスとルート世代の要求された品質を区別します:
- Requested service limits include upper bounds on route delay, route
delay variation, and session monetary cost and lower bounds on
available route bandwidth. Generating a route that must satisfy
more than one quality of service constraint, for example route delay
of no more than X seconds and available route bandwidth of no less
than Y bits per second, is an NP-complete problem.
- 要求されたサービス限界は利用可能なルート帯域幅におけるルート遅れ、ルート遅れ変化、セッション貨幣原価、下界での上限を含んでいます。 1つ以上のサービスの質の規制を満たさなければならないルート、例えば少なくともY bpsのX秒と利用可能なルート帯域幅だけのルート遅れを生成するのは、NP完全な問題です。
- Optimal requested services include minimum route delay, minimum
route delay variation, minimum session monetary cost, and maximum
available route bandwidth. In the worst case, the computational
complexity of generating a route that is optimal with respect to a
given requested service is O((N + L) log N) for Dijkstra's shortest
path first (SPF) search and O(N + (L * L)) for breadth-first (BF)
search, where N is the number of nodes and L is the number of links
in the search graph. Multi-criteria optimization, for example
finding a route with minimal delay variation and minimal session
monetary cost, may be defined in several ways. One approach to
multi-criteria optimization is to assign each link a single value
equal to a weighted sum of the values of the individual offered
qualities of service and generate a route that is optimal with
respect to this new criterion. However, selecting the weights that
yield the desired route generation behavior is itself an
optimization procedure and hence not trivial.
- 最適の要求されたサービスは最小のルート遅れ、最小のルート遅れ変化、最小のセッション貨幣原価、および最大の利用可能なルート帯域幅を含んでいます。 最悪の場合には、与えられた要求されたサービスに関して最適のルートを生成する計算量は幅-最初(BF)の検索のための最初に、ダイクストラの最短パス(SPF)検索とO(N+(L*L))のためのO(N+L)ログN)です。(そこでは、Nがノードの数であり、検索グラフでLはリンクの数です)。 例えば、最小量の遅れ変化と最小量のセッション貨幣原価でルートを見つけて、マルチ評価基準最適化はいくつかの道で定義されるかもしれません。 マルチ評価基準最適化への1つのアプローチは、個々の提供されたサービスの品質の値の荷重している合計と等しいただ一つの値を各リンクに割り当てて、この新しい評価基準に関して最適のルートを生成することです。 しかしながら、必要なルート世代をもたらす重りを選択して、振舞いは、それ自体で最適化手順であってしたがって、些細ではありません。
To help contain the combinatorial explosion of processing and memory costs associated with route generation, we supply the following guidelines for generation of suitable policy routes:
ルート世代に関連している処理とメモリコストの結合の爆発を含むのを助けるために、私たちは以下の適当な方針ルートの世代ガイドラインを提供します:
- Each route server should only generate policy routes from the
perspective of its own domain as source; it need not generate policy
routes for arbitrary source/destination domain pairs. Thus, we can
distribute the computational burden over all route servers.
- それぞれのルートサーバはソースとしてそれ自身のドメインの見解から方針ルートを生成するだけであるべきです。 それは方針ルートを任意のソース/目的地ドメイン組生成する必要はありません。 したがって、私たちはすべてのルートサーバの上にコンピュータの負担を分配できます。
- Route servers should precompute routes for which they anticipate
- サーバがルートを前計算するべきである彼らが予期するルート
Steenstrup [Page 73] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[73ページ]RFC1479IDPRは1993年7月に議定書を作ります。
requests and should generate routes on demand only in order to
satisfy unanticipated route requests. Hence, a single route server
can distribute its computational burden over time.
思いがけないルート要求を満たすために要求して、オンデマンドのルートだけを生成するべきです。 したがって、ただ一つのルートサーバは時間がたつにつれて、コンピュータの負担を分配できます。
- Route servers should cache the results of route generation, in order
to minimize the computation associated with responding to future
route requests.
- ルートサーバはルート世代の結果をキャッシュするべきです、今後のルート要求に応じると関連している計算を最小にするために。
- To handle requested service limits, a route server should always
select the first route generated that satisfies all of the requested
service limits.
- 要求されたサービス限界を扱うために、ルートサーバはいつも要求されたサービス限界のすべてを満たす生成された最初のルートを選択するべきです。
- To handle multi-criteria optimization in route selection, a route
server should generate routes that are optimal with respect to the
first optimal requested service listed in the ROUTE REQUEST message.
The route server should resolve ties between otherwise equivalent
routes by evaluating these routes according to the other optimal
requested services contained in the ROUTE REQUEST message, in the
order in which they are listed. With respect to the route server's
routing information database, the selected route is optimal
according to the first optimal requested service listed in the ROUTE
REQUEST message but is not necessarily optimal according to any
other optimal requested service listed in the ROUTE REQUEST message.
- ルート選択におけるマルチ評価基準最適化を扱うために、ルートサーバはROUTE REQUESTメッセージに記載された最初の最適の要求されたサービスに関して最適のルートを生成するべきです。 ルートサーバはROUTE REQUESTメッセージに含まれた他の最適の要求されたサービスに従ってこれらのルートを評価することによって、そうでなければ、同等なルートの間の結びつきを決議するべきです、それらが記載されているオーダーで。 ルートサーバのルーティング情報データベースに関して、選択されたルートは、ROUTE REQUESTメッセージに記載された最初の最適の要求されたサービスに従って最適ですが、ROUTE REQUESTメッセージに記載されたいかなる他の最適の要求されたサービスに従っても、必ず最適であるというわけではありません。
ti 2 - To handle a mixture of requested service limits and optimal
requested services, a route server should generate routes that
satisfy all of the requested service limits. The route server
should resolve ties between otherwise equivalent routes by
evaluating these routes as described in the multi-criteria
optimization case above.
ti2--要求されたサービス限界の、そして、最適に要求されたサービスの混合物を扱うために、ルートサーバは要求されたサービス限界のすべてを満たすルートを生成するべきです。 ルートサーバはマルチ評価基準最適化場合で説明されるこれらのルートを評価するのによる上のそうでなければ、同等なルートの間の結びつきを決議するべきです。
ti 2 - All else being equal, a route server should always prefer
minimum-hop routes, because they minimize the amount of network
resources consumed by the routes.
ti2--すべてのほかの存在同輩、ルートサーバはいつも最小のホップルートを好むべきです、ルートで消費されたネットワーク資源の量を最小にするので。
ti 2 - A route server should generate at least one route to each
component of a partitioned destination domain, because it may not
know in which domain component the destination host resides. Hence,
a route server can maximize the chances of providing a feasible
route to a destination within a partitioned domain.
ti2--ルートサーバは仕切られた目的地ドメインの各コンポーネントあたり少なくとも1つのルートを生成するべきです、あて先ホストがどのドメインコンポーネントに住んでいるかを知らないかもしれないので。 したがって、ルートサーバは仕切られたドメインの中の目的地に可能なルートを提供するという可能性を最大にすることができます。
6.1 Searching
6.1 探すこと
All domains need not execute the identical route generation
procedure. Each domain administrator is free to specify the IDPR
route generation procedure for route servers in its own domain,
making the procedure as simple or as complex as desired.
ドメインが必要とするすべてが同じルート世代手順を実行しません。 それぞれのドメイン管理者は自由にそれ自身のドメインのルートサーバにIDPRルート世代手順を指定できます、望まれているのと同じくらい簡単であるか同じくらい複雑であるとして手順を作って。
Steenstrup [Page 74] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[74ページ]RFC1479IDPRは1993年7月に議定書を作ります。
We offer an IDPR route generation procedure as a model. With slight
modification, this procedure can be made to search in either BF or
SPF order. The procedure can be used either to generate a single
policy route from the source to a specified destination domain or to
generate a set of policy routes from the source domain to all
destination domains. If the source or destination domain has a
proxy, then the source or destination endpoint of the policy route
is a proxy domain and not the actual source or destination domain.
私たちはモデルとしてIDPRルート世代手順を提供します。 わずかな変更で、この手順にBFかSPFオーダーのどちらかで探させることができます。 ソースから指定された目的地ドメインまでただ一つの方針ルートを生成するか、またはソースドメインからすべての目的地ドメインまで1セットの方針ルートを生成するのに手順を用いることができます。 ソースか目的地ドメインにプロキシがあるなら、方針ルートのソースか目的地終点が実際のソースか目的地ドメインではなく、プロキシドメインです。
For high-bandwidth traffic flows, BF search is the recommended
search technique, because it produces minimum-hop routes. For low-
bandwidth traffic flows, the route server may use either BF search
or SPF search. The computational complexity of BF search is O(N +
L) and hence it is the search procedure of choice, except when
generating routes with optimal requested services. We recommend
using SPF search only for optimal requested services and never in
response to a request for a maximum bandwidth route.
高帯域交通の流れに関しては、最小のホップルートを作成するので、BF検索はお勧めの検索技術です。 低い帯域幅交通の流れのために、ルートサーバがBFが捜すどちらかを使用するかもしれませんか、またはSPFは探します。 BF検索の計算量はO(N+L)です、そして、したがって、それは選択の調査方法です、最適の要求されたサービスでルートを生成するときに時を除いて。 私たちは、最適の要求されたサービスだけと決して最大の帯域幅ルートを求める要求に対応してSPF検索を使用することを勧めません。
6.1.1. Implementation
6.1.1. 実装
Data Structures:
データ構造:
The routing information database contains the graph of an internetwork, in which virtual gateways are the nodes and intra- domain routes between virtual gateways are the links. During route generation, each route is represented as a sequence of virtual gateways, domains, and relevant transit policies, together with a list of route characteristics, stored in a temporary array and indexed by destination domain.
ルーティング情報データベースはインターネットワークのグラフを含んでいます。(そこでは、仮想のゲートウェイがノードであり、仮想のゲートウェイの間のイントラドメインルートはリンクです)。 ルート世代の間、仮想のゲートウェイの系列(ドメイン、およびルートの特性のリストに伴う関連運送保険証券)が一時的な配列で保存して、目的地ドメインのそばで索引をつけたので、各ルートは表されます。
- Execute the Policy Consistency routine, first with the source
domain the given domain and second with the destination domain as
the given domain. If any policy inconsistency precludes the
requested traffic flow, go to Exit.
- 与えられたドメインとして目的地ドメインで最初に、ソースドメインによるPolicy Consistencyルーチン、与えられたドメイン、および2番目を執行してください。 何か方針矛盾が要求された交通の流れを排除するなら、Exitに行ってください。
- For each domain, initialize a null route, set the route bandwidth
to and set the following route characteristics to infinity: route
delay, route delay variation, session monetary cost, and route
length in hops.
- そして、各ドメインに、ヌルルートを初期化してくださいといって、ルート帯域幅を設定してください、以下のルートの特性を無限で設定してください: ルート遅れ、ルート遅れ変化、セッション貨幣原価、およびホップのルートの長さ。
- With each operational virtual gateway in the source or source proxy
domain, associate the initial route characteristics.
- ソースかソースプロキシドメインのそれぞれの操作上の仮想のゲートウェイと、初期のルートの特性を関連づけてください。
- Initialize a next-node data structure which will contain, for each
route in progress, the virtual gateway at the current endpoint of
the route together with the associated route characteristics. The
next-node data structure determines the order in which routes get
expanded.
- 関連ルートの特性と共にルートの現在の終点に進行中のそれぞれのルートに仮想のゲートウェイを保管している次のノードデータ構造を初期化してください。 次のノードデータ構造はルートが広げられる順番を決定します。
Steenstrup [Page 75] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[75ページ]RFC1479IDPRは1993年7月に議定書を作ります。
BF: A fifo queue.
BF: fifo待ち行列。
SPF: A heap, ordered according to the first optimal requested
service listed in the ROUTE REQUEST message.
SPF: ROUTE REQUESTメッセージに記載された最初の最適の要求されたサービスに従って注文された山。
Remove Next Node: These steps are performed for each virtual gateway
in the next-node data structure.
次のノードを取り除いてください: これらのステップは次のノードデータ構造におけるそれぞれの仮想のゲートウェイに実行されます。
- If there are no more virtual gateways in the next-node data
structure, go to Exit.
- 次のノードデータ構造にそれ以上の仮想のゲートウェイがなければ、Exitに行ってください。
- Extract a virtual gateway and its associated route
characteristics from the next-node data structure, obtain the
adjacent domain, and:
- そして、次のノードデータ構造から仮想のゲートウェイとその関連ルートの特性を抽出してくださいといって、隣接しているドメインを得てください、:
SPF: Remake the heap.
SPF: 山を作り変えてください。
- If there is a specific destination domain and if for the primary
optimal service:
- 特定の目的地ドメインがあって、プライマリ最適のサービスのために:
BF: Route length in hops.
BF: ホップで長さを発送してください。
SPF: First optimal requested service listed in the ROUTE
REQUEST message.
SPF: まず最初に、最適の要求されたサービスはROUTE REQUESTメッセージに記載しました。
the extracted virtual gateway's associated route characteristic
is no better than that of the destination domain, go to Remove
Next Node.
抽出された仮想のゲートウェイの関連ルートの特性は目的地ドメインのものより良いというわけではなく、Remove Next Nodeに行ってください。
- Execute the Policy Consistency routine with the adjacent domain
as given domain. If any policy inconsistency precludes the
requested traffic flow, go to Remove Next Node.
- ドメインを与えるので、隣接しているドメインでPolicy Consistencyルーチンを執行してください。 何か方針矛盾が要求された交通の流れを排除するなら、Remove Next Nodeに行ってください。
- Check that the source domain's transit policies do not preclude
traffic generated by members of the source host set with the
specified user class and requested services, from flowing to the
adjacent domain as destination. This check is necessary because
the route server caches what it considers to be all feasible
routes, to intermediate destination domains, generated during
the computation of the requested route. If there are no policy
inconsistencies, associate the route and its characteristics
with the adjacent domain as destination.
- 目的地として隣接しているドメインに注ぐので、ソースドメインの運送保険証券が指定されたユーザ・クラスと要求されたサービスで送信元ホストセットのメンバーによって生成されたトラフィックを排除しないのをチェックしてください。 ルートサーバが要求されたルートの計算の間、中間的目的地ドメインに生成されるそれが可能なルートであると考えることをキャッシュするので、このチェックが必要です。 方針矛盾が全くなければ、目的地としてルートとその特性を隣接しているドメインに関連づけてください。
- If there is a specific destination domain and if the adjacent
domain is the destination or destination proxy domain, go to
Remove Next Node.
- 隣接しているドメインが特定の目的地ドメインがあって、目的地か目的地プロキシドメインであるなら、Remove Next Nodeに行ってください。
- Record the set of all exit virtual gateways in the adjacent
- 隣接のすべての出口の仮想のゲートウェイのセットを記録してください。
Steenstrup [Page 76] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[76ページ]RFC1479IDPRは1993年7月に議定書を作ります。
domain which the adjacent domain's transit policies permit the
requested traffic flow and which are currently reachable from
the entry virtual gateway.
隣接しているドメインの運送保険証券が要求された交通の流れを可能にするドメインと現在エントリーの仮想のゲートウェイから届いているどれ。
Next Node:
次のノード:
These steps are performed for all exit virtual gateways in the
above set.
これらのステップは上記の仮想のゲートウェイが設定するすべての出口に実行されます。
- If there are no exit virtual gateways in the set, go to Remove
Next Node.
- セットにどんな出口の仮想のゲートウェイもなければ、Remove Next Nodeに行ってください。
- Compute the characteristics for the route to the exit virtual
gateway, and check that all of the route characteristics are
within the requested service limits. If any of the route
characteristics are outside of these limits, go to Next Node.
- 出口の仮想のゲートウェイへのルートに特性を計算してください、そして、要求されたサービス限界の中にルートの特性のすべてがあるのをチェックしてください。 ルートの特性のどれかがこれらの限界の外にあるなら、Next Nodeに行ってください。
- Compare these route characteristics with those already
associated with the exit virtual gateway (there may be none, if
this is the first time the exit virtual gateway has been visited
in the search), according to the primary optimal service.
- 出口の仮想のゲートウェイがあるそれらが既に関連しているこれらのルートの特性を比較してください(なにもないかもしれません、これが出口の仮想のゲートウェイが検索で訪問されたのが、初めてなら)、プライマリ最適のサービスに従って。
- Select the route with the optimal value of the primary optimal
service, resolve ties by considering optimality according to any
other optimal requested services in the order in which they are
listed in the ROUTE REQUEST message, and associate the selected
route and its characteristics with the exit virtual gateway.
- 最適にプライマリサービスの最適値があるルートを選択してください、そして、いかなる他の最適も最適であると考えるのによる結びつきがそれらがROUTE REQUESTメッセージに記載されているオーダーにおけるサービスを要求したと決議してください、そして、選択されたルートとその特性を出口の仮想のゲートウェイに関連づけてください。
- Add the virtual gateway to the next-node structure:
- 次のノード構造に仮想のゲートウェイを追加してください:
BF: Add to the end of the fifo queue.
BF: fifo待ち行列の終わりに加えてください。
SPF: Add to the heap.
SPF: 山に加えてください。
and go to Next Node.
そして、Next Nodeに行ってください。
Exit:
Return a response to the route request, consisting of either a
set of candidate policy routes or an indication that the route
request cannot be fulfilled.
以下を出てください。 ルート要求への応答を返してください、1セットの候補方針ルートかルート要求が実現できないという指示のどちらかから成って。
Policy Consistency: Check policy consistency for the given domain.
方針の一貫性: 与えられたドメインがないかどうか方針の一貫性をチェックしてください。
- Check that the given domain is not specified as an excluded
domain in the route request.
- 与えられたドメインがルート要求における除かれたドメインとして指定されないのをチェックしてください。
- Check that the given domain's transit policies do not preclude
traffic generated by members of the source host set with the
- 与えられたドメインの運送保険証券が用意ができている送信元ホストのメンバーによって生成されたトラフィックを排除しないのをチェックしてください。
Steenstrup [Page 77] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[77ページ]RFC1479IDPRは1993年7月に議定書を作ります。
specified user class and requested services, from flowing to the
destination domain.
目的地ドメインに注ぐので、ユーザ・クラスを指定して、サービスを要求しました。
During the computation of the requested routes, a route server also caches what it considers to be all feasible routes to intermediate destination domains, thus increasing the chances of being able to respond to a future route request without having to generate a new route. The route server does perform some policy consistency checks on the routes, as they are generated, to intermediate destinations. However, these routes may not in fact be feasible; the transit domains contained on the routes may not permit traffic between the source and the given intermediate destinations. Hence, before dispensing such a route in response to a route request, a route server must check that the transit policies of the constituent domains are consistent with the source and destination of the traffic flow.
また、要求されたルートの計算の間、ルートサーバはその結果、中間的目的地ドメインへのすべての可能なルート、それが新しいルートを生成すると考える将来のルートに応じることができる存在の機会がそうする必要はなくて要求する増加であることをキャッシュします。 それらが中間的目的地に生成されるとき、ルートサーバはいくつかの方針一貫性チェックをルートに実行します。 しかしながら、事実上、これらのルートは可能でないかもしれません。 ルートの上に含まれたトランジットドメインはソースと与えられた中間的目的地の間のトラフィックを可能にしないかもしれません。 したがって、ルート要求に対応してそのようなルートを分配する前に、ルートサーバは、構成しているドメインの運送保険証券が交通の流れのソースと目的地と一致しているのをチェックしなければなりません。
6.2. Route Directionality
6.2. ルートの方向性
A path agent may wish to set up a bidirectional path using a route supplied by a route server. (Refer to sections 7.2 and 7.4 for detailed discussions of path directionality.) However, a route server can only guarantee that the routes it supplies are feasible if used in the direction from source to destination. The reason is that the route server, which resides in the source or source proxy domain, does not have access to, and thus cannot account for, the source policies of the destination domain. Nevertheless, the route server can provide the path agent with an indication of its assessment of route feasibility in the direction from destination to source.
経路エージェントは、ルートサーバによって供給されたルートを使用することで双方向の経路をセットアップしたがっているかもしれません。. (経路の方向性の詳細な論議についてセクション7.2と7.4を参照してください。) しかしながら、ルートサーバは、ソースから目的地への方向に使用されるならそれが供給するルートが可能であることを保証できるだけです。 理由はルートサーバ(ソースかソースプロキシドメインにある)が目的地ドメインのソース方針に近づく手段を持たないで、その結果、説明できないということです。 それにもかかわらず、ルートサーバは目的地からソースへの方向へのルートの実行可能性の査定のしるしを経路エージェントに提供できます。
A necessary but insufficient condition for a route to be feasible in the direction from destination to source is as follows. The route must be consistent, in the direction from destination to source, with the transit policies of the domains that compose the route. The transit policy consistency checks performed by the route server during route generation account for the direction from source to destination but not for the direction from destination to source. Only after a route server generates a feasible route from source to destination does it perform the transit policy consistency checks for the route in the direction from destination to source. Following these checks, the route server includes in its ROUTE RESPONSE message to the path agent an indication of its assessment of route feasibility in each direction.
ルートが可能に目的地からソースへの方向になる必要な、しかし、不十分な状態は以下の通りです。 ルートは一貫しているに違いありません、目的地からソースへの方向に、ルートを構成するドメインの運送保険証券で。 ルート世代の間にルートサーバによって実行された運送保険証券一貫性チェックは、ソースから目的地への方向を説明しますが、目的地からソースへの方向を説明するというわけではありません。 ルートサーバがソースから目的地まで可能なルートを生成した後にだけそれはルートのための運送保険証券一貫性チェックを目的地からソースへの方向に実行します。 これらのチェックに続いて、ルートサーバはROUTE RESPONSEメッセージに各方向へのルートの実行可能性の査定のしるしを経路エージェントに含んでいます。
Steenstrup [Page 78] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[78ページ]RFC1479IDPRは1993年7月に議定書を作ります。
6.3. Route Database
6.3. ルートデータベース
A policy route, as originally specified by a route server, is an ordered list of virtual gateways, domains, and transit policies: VG 1 - AD 1 - TP 1 - ... - VG n - AD n - TP n. where VG i is the virtual gateway that serves as exit from AD i-1 and entry to AD i, and TP i is the set of transit policies associated with AD i and relevant to the particular route. Each route is indexed by source and destination domain. Route servers and paths agents store policy routes in route databases maintained as caches whose entries must be periodically flushed to avoid retention of stale policy routes. A route server's route database is the set of all routes it has generated on behalf of its domain as source or source proxy; associated with each route in the database are its route characteristics. A path agent's route database is the set of all routes it has requested and received from route servers on behalf of hosts for which it is configured to act.
元々ルートサーバによって指定される方針ルートは仮想のゲートウェイ、ドメイン、および運送保険証券の規則正しいリストです: VG1(西暦1年(TP1)) - VG n--西暦n年--VG iがAD i-1とエントリーからAD i、およびTP iまでの出口がAD iに関連していて特定のルートに関連している運送保険証券のセットであるので役立つ仮想のゲートウェイであるTP n.。 各ルートはソースと目的地ドメインによって索引をつけられます。 ルートサーバと経路エージェントは聞き古した方針ルートの保有を避けるために定期的にエントリーを洗い流さなければならないキャッシュとして維持されたルートデータベースに方針ルートを保存します。 ルートサーバのルートデータベースはそれがソースかソースプロキシとしてのドメインを代表して生成したすべてのルートのセットです。 データベースの各ルートに関連づけられているのは、そのルートの特性です。 経路エージェントのルートデータベースはそれが行動するのが構成されているホストを代表してルートサーバから要求して、受けたすべてのルートのセットです。
When attempting to locate a feasible route for a traffic flow, a path agent first consults its own route database before querying a route server. If the path agent's route database contains one or more routes between the given source and destination domains and accommodating the given host set and UCI, then the path agent checks each such route against the set of excluded domains listed in the source policy. The path agent either selects the first route encountered that does not include the excluded domains, or, if no such route exists in its route database, requests a route from a route server.
交通の流れのための可能なルートの場所を見つけるのを試みるとき、ルートサーバについて質問する前に、経路エージェントは最初に、それ自身のルートデータベースに相談します。経路エージェントのルートデータベースが与えられたソースと、目的地ドメインと与えられたホストセットとUCIを収容することの間の1つ以上のルートを含んでいるなら、経路エージェントはソース方針で記載された除かれたドメインのセットに対してそのような各ルートをチェックします。 経路エージェントは、除かれたドメインを含んでいない遭遇する最初のルートを選択するか、または何かそのようなルートがルートデータベースに存在しないなら、ルートサーバからルートを要求します。
A path agent must query a route server for routes when it is unable to fulfill a route request from its own route database. Moreover, we recommend that a path agent automatically forward to a route server, all route requests with non-null requested services. The reason is that the path agent retains no route characteristics in its route database. Hence, the path agent cannot determine whether an entry in its route database satisfies the requested services.
それ自身のルートデータベースからのルート要求を実現させることができないとき、経路エージェントはルートサーバについてルートに質問しなければなりません。 そのうえ、私たちは、経路エージェントが非ヌルの要求されたサービスと共にルートサーバ、すべてのルートに要求を自動的に転送することを勧めます。 理由は経路エージェントがルートデータベースにおけるルートの特性を全く保有しないということです。 したがって、経路エージェントは、ルートデータベースにおけるエントリーが要求されたサービスを満たすかどうかと決心できません。
When responding to a path agent's request for a policy route, a route server first consults its route database, unless the ROUTE REQUEST message contains an explicit directive to generate a new route. If its route database contains one or more routes between the given source and destination domains and accommodating the given host set and UCI, the route server checks each such route against the set of excluded domains listed in the ROUTE REQUEST message. The route server either selects all routes encountered that do not include the excluded domains, or, if no such route exists in its route database, attempts to generate such a route. Once the route server selects a set of routes, it then checks each such route against the services
方針ルートを求める経路エージェントの要求に応じるとき、ルートサーバは最初にルートデータベースに相談します、ROUTE REQUESTメッセージが新しいルートを生成する明白な指示を含んでいない場合。 ルートデータベースが与えられたソースと、目的地ドメインと与えられたホストセットとUCIを収容することの間の1つ以上のルートを含んでいるなら、ルートサーバはROUTE REQUESTメッセージに記載された除かれたドメインのセットに対してそのような各ルートをチェックします。 ルートサーバは、除かれたドメインを含んでいないルートが遭遇したすべてを選択するか、または何かそのようなルートがルートデータベースに存在していないなら、そのようなルートを生成するのを試みます。 一度、ルートサーバは1セットのルートを選択して、次に、それはサービスに対してそのような各ルートをチェックします。
Steenstrup [Page 79] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[79ページ]RFC1479IDPRは1993年7月に議定書を作ります。
requested by the path agent and the services offered by the domains composing the route. To obtain the offered services information, the route server consults its routing information database. The route server either selects the first route encountered that is consistent with both the requested and offered services, or, if no such route exists in its route database, attempts to generate such a route.
ルートを構成するドメインによって提供された経路エージェントとサービスで、要求されています。 提供サービス情報を得るために、ルートサーバはルーティング情報データベースに相談します。 ルートサーバは、遭遇する要求されて提供されたサービスと一致した最初のルートを選択するか、または何かそのようなルートがルートデータベースに存在していないなら、そのようなルートを生成するのを試みます。
6.3.1. Cache Maintenance
6.3.1. キャッシュメインテナンス
Each route stored in a route database has a maximum cache lifetime equal to rdb_rs minutes for a route server and rdb_ps minutes for a path agent. Route servers and path agents reclaim cache space by flushing entries that have attained their maximum lifetimes. Moreover, paths agents reclaim cache space for routes whose paths have failed to be set up successfully or have been torn down (see section 7.4).
ルートデータベースに保存された各ルートには、最大のキャッシュ生涯同輩がルートサーバのためのrdb_rs分と経路エージェントのためのrdb_ps分までいます。 サーバを発送してください。そうすれば、経路エージェントは、彼らの最大の生涯に達したエントリーを洗い流すことによって、キャッシュスペースを取り戻します。 そのうえ、経路エージェントは首尾よくセットアップされるか、または経路が取りこわされていないルートにキャッシュスペースを取り戻します(セクション7.4を見てください)。
Nevertheless, cache space may become scarce, even with reclamation of entries. If a cache fills, the route server or path agent logs the event for network management. To obtain space in the cache when the cache is full, the route server or path agent deletes from the cache the oldest entry.
それにもかかわらず、キャッシュスペースはエントリーの改善を伴って不十分になるかもしれません。 キャッシュがいっぱいになるなら、ルートサーバか経路エージェントがネットワークマネージメントのためにイベントを登録します。 キャッシュが完全であるときに、キャッシュにおけるスペースを得るために、ルートサーバか経路エージェントがキャッシュから最も古いエントリーを削除します。
7. Path Control Protocol and Data Message Forwarding Procedure
7. 経路制御プロトコルとデータメッセージ推進手順
Two entities in different domains may exchange IDPR data messages, only if there exists an IDPR path set up between the two domains. Path setup requires cooperation among path agents and intermediate policy gateways. Path agents locate policy routes, initiate the Path Control Protocol (PCP), and manage existing paths between administrative domains. Intermediate policy gateways verify that a given policy route is consistent with their domains' transit policies, establish the forwarding information, and forward messages along existing paths.
異なったドメインの2つの実体がIDPRデータメッセージを交換するかもしれません、2つのドメインの間でセットアップされたIDPR経路が存在している場合にだけ。 経路セットアップは経路エージェントと中間的方針ゲートウェイの中で協力を必要とします。 経路エージェントは、方針ルートの場所を見つけて、Path Controlプロトコル(PCP)を開始して、管理ドメインの間の既存の経路を管理します。 中間的方針ゲートウェイは、与えられた方針ルートがそれらのドメインの運送保険証券と一致していることを確かめて、推進情報を確立して、存在することに沿ったメッセージに経路を送ります。
Each policy gateway and each route server contains a path agent. The path agent that initiates path setup in the source or source proxy domain is the "originator", and the path agent that handles the originator's path setup message in the destination or destination proxy domain is the "target". Every path has two possible directions of traffic flow: from originator to target and from target to originator. Path control messages are free to travel in either direction, but data messages may be restricted to only one direction.
それぞれの方針ゲートウェイとそれぞれのルートサーバは経路エージェントを含みます。 ソースかソースプロキシドメインで経路セットアップに着手する経路エージェントは「創始者」です、そして、目的地か目的地プロキシドメインで創始者の経路セットアップメッセージを扱う経路エージェントは「目標」です。 あらゆる経路には、交通の流れの2つの可能な方向があります: 創始者から目標まで目標から創始者まで。 経路制御メッセージは無料でどちらの方向にも旅行できますが、データメッセージは一方向だけに制限されるかもしれません。
Once a path for a policy route is set up, its physical realization is a set of consecutive policy gateways, with policy gateways or route servers forming the endpoints. Two successive entities in this set belong to either the same domain or the same virtual gateway. A
方針ルートへの経路がいったんセットアップされると、物理的な実現は1セットの連続した方針ゲートウェイです、方針ゲートウェイかルートサーバが終点を形成していて。 このセットにおける2つの連続した実体が同じドメインか仮想のゲートウェイのどちらかに同じの属します。 A
Steenstrup [Page 80] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[80ページ]RFC1479IDPRは1993年7月に議定書を作ります。
policy gateway or route server may, at any time, recover the resources dedicated to a path that goes through it by tearing down that path. For example, a policy gateway may decide to tear down a path that has not been used for some period of time.
方針ゲートウェイかルートサーバがいつでも、その経路を取りこわすことによってひどい目に遭う経路に捧げられたリソースを回復するかもしれません。 例えば、方針ゲートウェイは、いつかの期間の間に使用されていない経路を取りこわすと決めるかもしれません。
PCP may build multiple paths between source and destination domains, but it is not responsible for managing such paths as a group or for eliminating redundant paths.
PCPはソースと目的地ドメインの間の複数の経路を造るかもしれませんが、それはグループのような経路を管理するか、または冗長パスを排除するのに責任がありません。
7.1. An Example of Path Setup
7.1. 経路セットアップに関する例
We illustrate how path setup works by stepping through an example. Suppose host Hx in domain AD X wants to communicate with host Hy in domain AD Y and that both AD X and AD Y support IDPR. Hx need not know the identity of its own domain or of Hy's domain in order to send messages to Hy. Instead, Hx simply forwards a message bound for Hy to one of the gateways on its local network, according to its local forwarding information only. If the recipient gateway is a policy gateway, the resident path agent determines how to forward the message outside of the domain. Otherwise, the recipient gateway forwards the message to another gateway in AD X, according to its local forwading information. Eventually, the message will arrive at a policy gateway in AD X, as policy gateways are the only egress points to other domains, in domains that support IDPR.
私たちは経路セットアップが例を通して踏むことによってどう利くかを例証します。 ドメインAD X必需品のホストHxがドメインでホストHyとコミュニケートすると仮定してください、AD Y、そして、AD XとAD Yの両方がIDPRをサポートします。 Hxは、メッセージをHyに送るためにそれ自身のドメインかHyのドメインのアイデンティティを知る必要はありません。 代わりに、Hxは単にHyに企業内情報通信網のゲートウェイの1つに向かっているメッセージを転送します、ローカルの推進情報だけによると。 受取人ゲートウェイが方針ゲートウェイであるなら、居住している経路エージェントはドメインの外にメッセージを転送する方法を決心しています。 さもなければ、ローカルのforwading情報に応じて、受取人ゲートウェイはAD Xのときにもう1門にメッセージを転送します。 結局、メッセージはAD Xのときに方針ゲートウェイに到着するでしょう、方針ゲートウェイが他のドメインへの唯一の出口ポイントであるので、IDPRをサポートするドメインで。
The path agent resident in the recipient policy gateway uses the message header, including source and destination addresses and any requested service information (for example, type of service), in order to determine whether it is an intra-domain or inter-domain message, and if inter-domain, whether it requires an IDPR policy route. Specifically, the path agent attempts to locate a forwarding information database entry for the given traffic flow, from the information contained in the message header. In the future, for IP messages, the relevant header information may also include special service-specific IP options or even information from higher layer protocols.
受取人方針ゲートウェイの経路エージェントの居住者はメッセージヘッダーを使用します、ソース、送付先アドレス、およびどんな要求されたサービス情報(例えば、サービスのタイプ)も含んでいて、それがイントラドメインか相互ドメインメッセージであるかどうか決定して、相互ドメインであるなら、それがIDPR方針ルートを必要とするか否かに関係なく。 明確に、経路エージェントは、与えられた交通の流れのための推進情報データベースエントリーの場所を見つけるのを試みます、メッセージヘッダーに含まれた情報から。 また、将来、IPメッセージに関して、関連ヘッダー情報は、より高い層のプロトコルからの特別なサービス特有のIPオプションか情報さえ含むかもしれません。
Forwarding database entries exist for all of the following:
推進データベースエントリーは以下のすべてのために存在しています:
- All intra-domain traffic flows. Intra-domain forwarding
information is integrated into the forwarding information database
as soon as it is received.
- すべてのイントラドメイントラフィックが流れます。 それが受け取られているとすぐに、イントラドメイン推進情報は推進情報データベースと統合されます。
- Inter-domain traffic flows that do not require IDPR policy routes.
Non-IDPR forwarding information is integrated into the forwarding
database as soon as it is received.
- IDPR方針ルートを必要としない相互ドメイン交通の流れ。 それが受け取られているとすぐに、非IDPR推進情報は推進データベースと統合されます。
- IDPR inter-domain traffic flows for which a path has already been
- 経路が既にあったIDPR相互ドメイン交通の流れ
Steenstrup [Page 81] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[81ページ]RFC1479IDPRは1993年7月に議定書を作ります。
set up. IDPR forwarding information is integrated into the
forwarding database only during path setup.
セットアップしてください。 IDPR推進情報は経路セットアップだけの間推進データベースと統合されます。
The path agent uses the message header contents to guide the search for a forwarding information database entry for a given traffic flow. We recommend a radix search to locate such an entry. When the search terminates, it produces either an entry, or, in the case of a new IDPR traffic flow, a directive to generate an entry. If the search terminates in an existing forwarding information database entry, the path agent forwards the message according to that entry.
経路エージェントは、与えられた交通の流れのための推進情報データベースエントリーの検索を誘導するのにメッセージヘッダーコンテンツを使用します。 私たちは、基数検索がそのようなエントリーの場所を見つけることを勧めます。 検索が終わると、それは、エントリーを生成するためにエントリーか新しいIDPR交通の流れの場合における指示のどちらかを起こします。 検索が既存の推進情報データベースエントリーで終わるなら、そのエントリーに応じて、経路エージェントはメッセージを転送します。
Suppose that the search terminates indicating that the traffic flow from Hx to Hy requires an IDPR policy route and that no entry in the forwarding information database yet exists for that traffic flow. In this case, the path agent first determines the source and destination domains associated with the message's source and destination addresses, before attempting to obtain a policy route. The path agent relies on the mapping servers to supply the domain information, but it caches all mapping server responses locally to limit the number of future queries. When attempting to resolve an address to a domain, the path agent always checks its local cache before contacting a mapping server.
HxからHyまでの交通の流れがIDPR方針ルートを必要として、推進情報データベースにおけるエントリーが全くその交通の流れのためにまだ存在していないのを示しながら検索が終わると仮定してください。 この場合、経路エージェントは最初にメッセージのソースと送付先アドレスに関連しているソースと目的地ドメインを決心しています、方針ルートを入手するのを試みる前に。 経路エージェントはドメイン情報を提供するためにマッピングサーバを当てにしますが、それは、今後の質問の数を制限するために局所的にすべてのマッピングサーバ応答をキャッシュします。 ドメインにアドレスを決議するのを試みるとき、マッピングサーバに連絡する前に、経路エージェントはいつもローカルなキャッシュをチェックします。
After obtaining the domain information, the path agent attempts to obtain a policy route to carry the traffic from Hx to Hy. The path agent relies on route servers to supply policy routes, but it caches all route server responses locally to limit the number of future queries. When attempting to locate a suitable policy route, the path agent usually consults its local cache before contacting a route server, as described previously in section 6.3.
ドメイン情報を得た後に、経路エージェントは、HxからHyまでトラフィックを運ぶために方針ルートを入手するのを試みます。 経路エージェントは方針ルートを供給するためにルートサーバを当てにしますが、それは、今後の質問の数を制限するために局所的にすべてのルートサーバ応答をキャッシュします。 適当な方針ルートの場所を見つけるのを試みるとき、ルートサーバに連絡する前に通常、経路エージェントはローカルなキャッシュに相談します、以前にセクション6.3で説明されるように。
If no suitable cache entry exists, the path agent queries the route server, providing it with the source and destination domains together with source policy information carried in the host message or specified through configuration. Upon receiving a policy route query, a route server consults its route database. If it cannot locate a suitable route in its route database, the route server attempts to generate at least one route to AD Y, consistent with the requested services for Hx.
どんな適当なキャッシュエントリーも存在していないなら、経路エージェントはルートサーバについて質問します、ホストメッセージで運ばれるか、または構成を通して指定されたソース方針情報と共にソースと目的地ドメインをそれに提供して。 方針ルート質問を受けると、ルートサーバはルートデータベースに相談します。 ルートデータベースで適当なルートの場所を見つけることができないなら、ルートサーバは、AD Yまで少なくとも1つのルートを生成するのを試みます、Hxにおいて要求されたサービスと一致しています。
The route server always returns a response to the path agent, regardless of whether it is successful in locating a suitable policy route. The response to a successful route query consists of a set of candidate routes, from which the path agent makes its selection. We expect that a path agent will normally choose a single route from a candidate set. Nevertheless, IDPR does not preclude a path agent from selecting multiple routes from the candidate set. A path agent may desire multiple routes to support features such as fault
ルートサーバはいつも経路エージェントへの応答を返します、それが適当な方針ルートの場所を見つけるのに成功しているかどうかにかかわらず。 うまくいっているルート質問への応答は1セットの候補ルートから成ります。(経路エージェントはルートから選択をします)。 私たちは、通常、経路エージェントが候補セットからただ一つのルートを選ぶと予想します。 それにもかかわらず、IDPRは、候補セットから複数のルートを選択するので、経路エージェントを排除しません。 経路エージェントは、複数のルートが欠点などの特徴をサポートすることを望むかもしれません。
Steenstrup [Page 82] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[82ページ]RFC1479IDPRは1993年7月に議定書を作ります。
tolerance or load balancing; however, IDPR does not currently specify how the path agent should use multiple routes.
寛容かロードバランシング。 しかしながら、IDPRは現在、経路エージェントがどう複数のルートを使用するべきであるかを指定しません。
If the policy route is a new route provided by the route server, there will be no existing path for the route, and thus the path agent must set up such a path. However, if the policy route is an existing route extracted from the path agent's cache, there may well be an existing path for the route, set up to accommodate a host traffic flow. IDPR permits multiple traffic flows to use the same path, provided that all traffic flows sharing the path travel between the same endpoint domains and have the same service requirements. Nevertheless, IDPR does not preclude a path agent from setting up distinct paths along the same policy route to preserve the distinction between host traffic flows.
方針ルートがルートサーバによって提供された、新しいルートであるなら、ルートへのどんな既存の経路もないでしょう、そして、その結果、経路エージェントはそのような経路をセットアップしなければなりません。 しかしながら、方針ルートが経路エージェントのキャッシュから抜粋された、既存のルートであるなら、たぶん、ルート(ホスト交通の流れに対応するために上がっているセット)には既存の経路があるでしょう。 IDPRは、複数の交通の流れが同じ経路を使用するのを可能にします、経路を共有するすべての交通の流れが同じ終点ドメインの間を伝わって、同じサービス要件を持っていれば。 それにもかかわらず、IDPRは、ホスト交通の流れの区別を保存するために同じ方針ルートに沿って異なった経路をセットアップするので、経路エージェントを排除しません。
The path agent associates an identifier with the path, which is included in each message that travels down the path and is used by the policy gateways along the path in order to determine how to forward the message. If the path already exists, the path agent uses the preexisting identifier. However, for new paths, the path agent chooses a path identifier that is different from those of all other paths that it manages. The path agent also updates its forwarding information database to reference the path identifier and modifies its search procedure to yield the correct entry in the forwarding information database given the data message header.
経路エージェントは識別子を経路に関連づけます。(それは、経路の下側に移動する各メッセージに含まれていて、メッセージを転送する方法を決定するのに経路に沿った方針ゲートウェイによって使用されます)。 経路が既に存在しているなら、経路エージェントは先在の識別子を使用します。 しかしながら、新しい経路に、経路エージェントはそれが管理する他のすべての経路のものと異なった経路識別子を選びます。 経路エージェントは、また、参照への経路識別子を情報データベースに転送するのをアップデートして、データメッセージヘッダーを考えて、推進情報データベースにおける正しいエントリーをもたらすように調査方法を変更します。
For new paths, the path agent initiates path setup, communicating the policy route, in terms of requested services, constituent domains, relevant transit policies, and the connecting virtual gateways, to policy gateways in intermediate domains. Using this information, an intermediate policy gateway determines whether to accept or refuse the path and to which next policy gateway to forward the path setup information. The path setup procedure allows policy gateways to set up a path in both directions simultaneously. Each intermediate policy gateway, after path acceptance, updates its forwarding information database to include an entry that associates the path identifier with the appropriate previous and next hop policy gateways.
新しい経路に、経路エージェントは経路セットアップに着手します、方針ルートを伝えて、要求されたサービス、構成しているドメイン、関連運送保険証券、および接続の仮想のゲートウェイに関して、中間的ドメインの方針ゲートウェイに。 この情報を使用して、中間的方針ゲートウェイは、受け入れるか、または経路セットアップ情報を転送するのを経路とどの隣の方針ゲートウェイに拒否するかを決定します。 経路セットアップ手順で、方針ゲートウェイは同時に、両方の方向に経路をセットアップできます。 それぞれの中間的方針ゲートウェイは、経路承認の後に適切が前であることの状態で経路識別子を関連づけるエントリーと隣のホップ方針ゲートウェイを含むように推進情報データベースをアップデートします。
When a policy gateway in AD Y accepts a path, it notifies the source path agent in AD X. We expect that the source path agent will normally wait until a path has been successfully established before using it to transport data traffic. However, PCP does not preclude a path agent from forwarding messages along a path prior to confirmation of successful path establishment. Paths remain in place until they are torn down because of failure, expiration, or when resources are scarce, preemption in favor of other paths.
AD Yの方針ゲートウェイが経路を受け入れるとき、それは、データ通信量を輸送するのにそれを使用する前に経路が首尾よく確立されるまで通常、ソースの経路エージェントが待つようにX.Weが予想するADのソースの経路エージェントに通知します。 しかしながら、PCPは、うまくいっている経路設立の確認の前に経路に沿ってメッセージを転送するので、経路エージェントを排除しません。 経路は失敗、満了のためにそれらを取りこわすか、またはリソースが不十分であり時適所に残っています、他の経路を支持して先取り。
Steenstrup [Page 83] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[83ページ]RFC1479IDPRは1993年7月に議定書を作ります。
We note that data communication between Hx and Hy may occur over two separate IDPR paths: one from AD X to AD Y and one from AD Y to AD X. The reasons are that within a domain, hosts know nothing about path agents nor IDPR paths, and path agents know nothing about other path agents' existing IDPR paths. Thus, in AD Y, the path agent that terminates the path from AD X may not be the same as the path agent that receives traffic from Hy destined for Hx. In this case, receipt of traffic from Hy forces the second path agent to set up an independent path from AD Y to AD X.
私たちは、HxとHyの間のデータ通信が2つの別々のIDPR経路の上に起こるかもしれないことに注意します: 1つ、AD XからAD YとAD Yからの1〜AD X.まで、理由はドメインの中では、ホストが経路エージェントに関して何も知らないということであり、IDPRは経路です、そして、経路エージェントが他の経路エージェントの既存のIDPR経路に関して何も知りません。 したがって、AD Yのときに、AD Xからの経路を終える経路エージェントはHyからトラフィックを受ける経路エージェントがHxのために運命づけたのと同じでないかもしれません。 この場合、第2代経路エージェントはHyからのトラフィックの領収書によってAD YからAD Xまでやむを得ず独自路線をセットアップします。
7.2. Path Identifiers
7.2. 経路識別子
Each path has an associated path identifier, unique throughout an internetwork. Every IDPR data message travelling along that path includes the path identifier, used for message forwarding. The path identifier is the concatenation of three items: the identifier of the originator's domain, the identifier of the originator's policy gateway or route server, and a 32-bit local path identifier specified by the originator. The path identifier and the CMTP transaction identifier have analogous syntax and play analogous roles in their respective protocols.
各経路には、インターネットワーク中でユニークな関連経路識別子があります。 その経路に沿って移動するあらゆるIDPRデータメッセージがメッセージ推進に使用される経路識別子を含んでいます。 経路識別子は3つの項目の連結です: 創始者のドメインに関する識別子、創始者の方針ゲートウェイかルートサーバに関する識別子、および32ビットのローカルの経路識別子は創始者で指定しました。 経路識別子とCMTPトランザクション識別子は、それらのそれぞれのプロトコルで類似の構文を持って、類似の役割を果たします。
When issuing a new path identifier, the originator always assigns a local path identifier that is different from that of any other active or recently torn-down path originally set up by that path agent. This helps to distinguish new paths from replays. Hence, the originator must keep a record of each extinct path for long enough that all policy gateways on the path will have eliminated any reference to it from their memories. The right-most 30 bits of the local identifier are the same for each path direction, as they are assigned by the originator. The left-most 2 bits of the local identifier indicate the path direction.
新しい経路識別子を発行するとき、創始者はいつも元々その経路エージェントによってセットアップされたいかなる他のアクティブであるか最近取りこわしている経路のものとも異なったローカルの経路識別子を割り当てます。 これは、再生と新しい経路を区別するのを助けます。 したがって、創始者は経路のすべての方針ゲートウェイが彼らの思い出からそれのどんな参照も排除してしまうだろうというくらいの長い間、それぞれの消光している経路に関する記録をつけなければなりません。 それぞれの経路方向に、ローカルの識別子の最も権利30ビットは同じです、それらが創始者によって割り当てられるとき。 ローカルの識別子の最も左の2ビットは経路方向を示します。
At path setup time, the originator specifies which of the path directions to enable contingent upon the information received from the route server in the ROUTE RESPONSE message. By "enable", we mean that each path agent and each intermediate policy gateway establishes an association between the path identifier and the previous and next policy gateways on the path, which it uses for forwarding data messages along that path. IDPR data messages may travel in the enabled path directions only, but path control messages are always free to travel in either path direction. The originator may enable neither path direction, if the entire data transaction can be carried in the path setup message itself. In this case, the path agents and the intermediate policy gateways do not establish forwarding associations for the path, but they do verify consistency of the policy information contained in the path setup message, with their own transit policies, before forwarding the setup message on to the
経路準備時間に、創始者は、ROUTE RESPONSEメッセージのルートサーバから受け取られた情報次第で経路方向のどれを可能にしたらよいかを指定します。 「可能にすること」で、私たちは、それぞれの経路エージェントとそれぞれの中間的方針ゲートウェイが経路識別子と前との協会とそれが推進データメッセージにその経路に沿って使用する経路の隣の方針ゲートウェイを設立すると言っています。 IDPRデータメッセージは可能にされた経路方向だけに移動するかもしれませんが、経路制御メッセージはいつも無料でどちらの経路方向にも旅行できます。 創始者はどちらの経路方向も可能にしないかもしれません、経路セットアップメッセージ自体で全体のデータトランザクションを運ぶことができるなら。 この場合、経路エージェントと中間的方針ゲートウェイは推進協会を経路に設立しません、と彼らだけが経路セットアップメッセージにセットアップメッセージを転送する前のそれら自身の運送保険証券で含まれた方針情報の一貫性について確かめます。
Steenstrup [Page 84] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[84ページ]RFC1479IDPRは1993年7月に議定書を作ります。
next policy gateway.
隣の方針ゲートウェイ。
The path direction portion of the local path identifier has different interpretations, depending upon message type. In an IDPR path setup message, the path direction indicates the directions in which the path should be enabled: the value 01 denotes originator to target, the value 10 denotes target to originator, the value 11 denotes both directions, and the value 00 denotes neither direction. Each policy gateway along the path interprets the path direction in the setup message and sets up the forwarding information as directed. In an IDPR data message, the path direction indicates the current direction of traffic flow: either 01 for originator to target or 10 for target to originator. Thus, if for example, an originator sets up a path enabling only the direction from target to originator, the target sends data messages containing the path identifier selected by the originator together with the path direction set equal to 10.
ローカルの経路識別子の経路方向の部分には、メッセージタイプに頼っていて、異なった解釈があります。 IDPR経路セットアップメッセージでは、経路方向は経路が可能にされるべきである方向を示します: 値01は狙う創始者を指示します、そして、値10は創始者に目標を指示します、そして、値11は両方の方向を指示します、そして、値00はどちらの方向も指示しません。 経路に沿ったそれぞれの方針ゲートウェイは、セットアップメッセージで経路方向を解釈して、指示されるとして推進情報をセットアップします。 IDPRデータメッセージでは、経路方向は交通の流れの現在の方向を示します: 創始者への目標のための創始者が狙う01か10のどちらか。 したがって、例えば、創始者が目標から創始者への方向だけを可能にする経路をセットアップするなら、目標は10と等しい経路方向セットと共に創始者によって選択された経路識別子を含むデータメッセージを送ります。
Instead of using path identifiers that are unique throughout an internetwork, we could have used path identifiers that are unique only between a pair of consecutive policy gateways and that change from one policy gateway pair to the next. The advantage of locally unique path identifiers is that they may be much shorter than globally unique identifiers and hence consume less transmission bandwidth. However, the disadvantage is that the path identifier carried in each IDPR data message must be modified at each policy gateway, and hence if the integrity/authentication information covers the path identifier, it must be recomputed at each policy gateway. For security reasons, we have chosen to include the path identifier in the set of information covered by the integrity/authentication value, and moreover, we advocate public-key based signatures for authentication. Thus, it is not possible for intermediate policy gateways to modify the path identifier and then recompute the correct integrity/authentication value. Therefore, we have decided in favor of path identifiers that do not change from hop to hop and hence must be globally unique. To speed forwarding of IDPR data messages with long path identifiers, policy gateways should hash the path identifiers in order to index IDPR forwarding information.
インターネットワーク中でユニークな経路識別子を使用することの代わりに、私たちは1組の連続した方針ゲートウェイだけの間でユニークであり、1方針ゲートウェイ組から次に変化する経路識別子を使用したかもしれません。 局所的にユニークな経路識別子の利点はグローバルにユニークな識別子よりはるかに短く、したがって、より少ないトランスミッション帯域幅を消費するかもしれないということです。 しかしながら、不都合はそれぞれの方針ゲートウェイでそれぞれのIDPRデータメッセージで運ばれた経路識別子を変更しなければならなくて、したがって、保全/認証情報が経路識別子をカバーしているなら、それぞれの方針ゲートウェイでそれを再計算しなければならないということです。 安全保障上の理由で、私たちは、保全/認証値でカバーされた情報のセットに経路識別子を含んでいるのを選びました、そして、そのうえ、認証のための公開鍵に基づいている署名を支持します。 したがって、中間的方針ゲートウェイは経路識別子を変更して、次に、正しい保全/認証が評価するrecomputeを変更するのは可能ではありません。 したがって、私たちはホップによって変化していない、したがってグローバルにユニークでなければならない経路識別子を支持して決めました。 IDPRデータの速度推進に、長い経路識別子があるメッセージであり、方針ゲートウェイは、IDPR推進情報に索引をつけるために経路識別子を論じ尽くすはずです。
7.3. Path Control Messages
7.3. 経路制御メッセージ
Messages exchanged by the path control protocol are classified into "requests": SETUP, TEARDOWN, REPAIR; and "responses": ACCEPT, REFUSE, ERROR. These messages have significance for intermediate policy gateways as well as for path agents.
経路制御プロトコルによって交換されたメッセージは「要求」に分類されます: セットアップ、分解は修理されます。 「応答」: 受け入れてください、廃物、誤り。 これらのメッセージには、中間的方針ゲートウェイと経路エージェントのための意味があります。
SETUP:
Establishes a path by linking together pairs of policy gateways.
The SETUP message is generated by the originator and propagates
セットアップ: 組の方針ゲートウェイを結びつけることによって、経路を確立します。 SETUPメッセージは、創始者によって生成されて、伝播されます。
Steenstrup [Page 85] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[85ページ]RFC1479IDPRは1993年7月に議定書を作ります。
to the target. In response to a SETUP message, the originator
expects to receive an ACCEPT, REFUSE, or ERROR message. The
SETUP message carries all information necessary to set up the
path including path identifier, requested services, transit
policy information relating to each domain traversed, and
optionally, expedited data.
目標に。 SETUPメッセージに対応して、創始者は、ACCEPT、REFUSE、またはERRORメッセージを受け取ると予想します。 SETUPメッセージは経路識別子を含む経路をセットアップするためにすべての必要情報を運んで、要求されたサービス(任意に横断された各ドメインに関連する運送保険証券情報)はデータを速めました。
ACCEPT: Signals successful path establishment. The ACCEPT message is
generated by the target, in response to a SETUP message, and
propagates back to the originator. Reception of an ACCEPT
message by the originator indicates that the originator can now
safely proceed to send data along the path. The ACCEPT message
contains the path identifier and an optional reason for
conditional acceptance.
受け入れます: うまくいっている経路設立に合図します。 ACCEPTメッセージは、目標によってSETUPメッセージに対応して生成されて、創始者に伝播して戻られます。 創始者によるACCEPTメッセージのレセプションは、創始者が現在経路に沿って安全にデータを送ることができかけるのを示します。 ACCEPTメッセージは経路識別子と条件付きの承認の任意の理由を含んでいます。
REFUSE: Signals that the path could not be successfully established,
either because resources were not available or because there was
an inconsistency between the services requested by the source
and the services offered by a transit domain along the path.
The REFUSE message is generated by the target or by any
intermediate policy gateway, in response to a SETUP message, and
propagates back to the originator. All recipients of a REFUSE
message recover the resources dedicated to the given path. The
REFUSE message contains the path identifier and the reason for
path refusal.
以下を拒否してください。 リソースが利用可能でなかったか、または経路に沿ってトランジットドメインによって提供されたソースとサービスで要求されたサービスの間には、矛盾があったので、首尾よく経路を確立できなかったと合図します。 REFUSEメッセージは、目標かSETUPメッセージに対応したどんな中間的方針ゲートウェイによっても生成されて、創始者に伝播して戻られます。 REFUSEメッセージのすべての受取人が与えられた経路に捧げられたリソースを回復します。 REFUSEメッセージは経路識別子と経路拒否の理由を含んでいます。
TEARDOWN: Tears down a path, typically when a non-recoverable failure
is detected. The TEARDOWN message may be generated by any path
agent or policy gateway in the path and usually propagates in
both path directions. All recipients of a TEARDOWN message
recover the resources dedicated to the given path. The TEARDOWN
message contains the path identifier and the reason for path
teardown.
分解: aであるときに、経路の下側への涙であり、通常、非回復可能な失敗は検出されます。 TEARDOWNメッセージは、経路のどんな経路エージェントや方針ゲートウェイによっても生成されるかもしれなくて、通常、両方の経路方向に伝播されます。 TEARDOWNメッセージのすべての受取人が与えられた経路に捧げられたリソースを回復します。 TEARDOWNメッセージは経路識別子と経路分解の理由を含んでいます。
REPAIR: Establishes a repaired path by linking together pairs of
policy gateways. The REPAIR message is generated by a policy
gateway after detecting that the next policy gateway on one of
its existing paths is unreachable. A policy gateway that
generates a REPAIR message propagates the message forward at
most one virtual gateway. In response to a REPAIR message, the
policy gateway expects to receive an ACCEPT, REFUSE, TEARDOWN,
or ERROR message. The REPAIR message carries the original SETUP
message.
修理: 組の方針ゲートウェイを結びつけることによって、修理された経路を確立します。 それを検出して、既存の経路の1つの隣の方針ゲートウェイが手が届かなくなった後にREPAIRメッセージは方針ゲートウェイによって生成されます。 REPAIRメッセージを生成する方針ゲートウェイはほとんどの仮想の1つの門でメッセージを前方に伝播します。 REPAIRメッセージに対応して、方針ゲートウェイは、ACCEPT、REFUSE、TEARDOWN、またはERRORメッセージを受け取ると予想します。 REPAIRメッセージはオリジナルのSETUPメッセージを伝えます。
ERROR: Transports information about a path error back to the
originator, when a PCP message contains unrecognized
information. The ERROR message may be generated by the target
or by any intermediate policy gateway and propagates back to the
誤り: PCPメッセージが認識されていない情報を含んでいると、経路誤りの情報を創始者に輸送して戻します。 ERRORメッセージは、目標かどんな中間的方針ゲートウェイによっても生成されるかもしれなくて、伝播して戻ります。
Steenstrup [Page 86] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[86ページ]RFC1479IDPRは1993年7月に議定書を作ります。
originator. Most, but not all, ERROR messages are generated in
response to errors encountered during path setup. The ERROR
message includes the path identifier and an explanation of the
error detected.
創始者。 ERRORメッセージは経路セットアップの間に遭遇する誤りに対応して最も生成されます。 ERRORメッセージは経路識別子と検出された誤りに関する説明を含んでいます。
Policy gateways use CMTP for reliable transport of PCP messages, between path agents and policy gateways and between consecutive policy gateways on a path. PCP must communicate to CMTP the maximum number of transmissions per path control message, pcp_ret, and the interval between path contol message retransmissions, pcp_int microseconds. All path control messages, except ERROR messages, may be transmitted up to pcp_ret times; ERROR messages are never retransmitted. A path control message is "acceptable" if:
方針ゲートウェイは経路で経路エージェントと方針ゲートウェイの間と、そして、PCPメッセージの信頼できる輸送と、連続した方針ゲートウェイの間でCMTPを使用します。 PCPは経路contolメッセージ「再-トランスミッション」(pcp_intマイクロセカンド)の経路制御メッセージあたりのトランスミッション、_が浸水させるpcp、および間隔の最大数をCMTPに伝えなければなりません。 ERRORメッセージを除いて、経路制御メッセージがpcp_に送られるかもしれないすべてが回を浸水させます。 ERRORメッセージは決して再送されません。 経路制御メッセージが「許容できる」、:
- It passes the CMTP validation checks.
- それはCMTP合法化チェックを通過します。
- Its timestamp is less than pcp_old (300) seconds behind the
recipient's internal clock time.
- タイムスタンプは受取人の内部クロック時間の(300)秒後ろで古いpcp_より少ないです。
- It carries a recognized path identifier, provided it is not a SETUP
message.
- それはSETUPメッセージでないなら認識された経路識別子を運びます。
An intermediate policy gateway on a path forwards acceptable PCP messages. As we describe in section 7.4 below, SETUP messages must undergo additional tests at each intermediate policy gateway prior to forwarding. Moreover, receipt of an acceptable ACCEPT, REFUSE, TEARDOWN, or ERROR message at either path agent or at any intermediate policy gateway indirectly cancels any active local CMTP retransmissions of the original SETUP message. When a path agent or intermediate policy gateway receives an unacceptable path control message, it discards the message and logs the event for network management. The path control message age limit reduces the likelihood of denial of service attacks based on message replay.
経路の中間的方針ゲートウェイは許容できるPCPメッセージを転送します。 私たちが下のセクション7.4で説明するように、SETUPメッセージは推進の前にそれぞれの中間的方針ゲートウェイで追試を受けなければなりません。 そのうえ、どちらかの経路エージェントにおける、または、どんな中間的方針ゲートウェイの許容できるACCEPT、REFUSE、TEARDOWN、またはERRORメッセージの領収書は間接的にオリジナルのSETUPメッセージのどんなアクティブな地方のCMTP retransmissionsも取り消します。 経路エージェントか中間的方針ゲートウェイが容認できない経路制御メッセージを受け取るとき、それは、メッセージを捨てて、ネットワークマネージメントのためにイベントを登録します。 経路制御メッセージ時代限界はメッセージ再生に基づくサービス不能攻撃の見込みを減少させます。
7.4. Setting Up and Tearing Down a Path
7.4. 経路をセットアップして、取りこわします。
Path setup begins when the originator generates a SETUP message containing:
創始者が以下を含むSETUPメッセージを生成すると、経路セットアップは始まります。
- The path identifier, including path directions to enable.
- 可能にする経路方向を含む経路識別子。
- An indication of whether the message includes expedited data.
- メッセージが速められたデータを含むかどうかしるし。
- The source user class identifier.
- ソースユーザ・クラス識別子。
- The requested services (see section 5.5.2) and source-specific
information (see section 7.6.1) for the path.
- 経路のための要求されたサービス(セクション5.5.2を見る)とソース特殊情報(セクション7.6.1を見ます)。
Steenstrup [Page 87] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[87ページ]RFC1479IDPRは1993年7月に議定書を作ります。
- For each domain on the path, the domain component, applicable
transit policies, and entry and exit virtual gateways.
- 経路、ドメインコンポーネント、適切な運送保険証券、およびエントリーと出口の仮想のゲートウェイの上の各ドメインに。
The only mandatory requested service is the maximum path lifetime, pth_lif, and the only mandatory source-specific information is the data message integrity/authentication type. If these are not specified in the path setup message, each recipient policy gateway assigns them default values, (60) minutes for pth_lif and no authentication for integrity/authentication type. Each path agent and intermediate policy gateway tears down a path when the path lifetime is exceeded. Hence, no single source can indefinitely monopolize policy gateway resources or still functioning parts of partially broken paths.
唯一の義務的な要求されたサービスが最大の経路生涯です、pth_lif、そして、唯一の義務的なソース特殊情報がデータメッセージの保全/認証タイプです。 これらが経路セットアップメッセージで指定されないなら、それぞれの受取人方針ゲートウェイはデフォルト値をそれらに割り当てます、とpth_lifのための(60)分がタイプしますが、保全/認証のためのどんな認証もタイプしません。 経路寿命が超えられているとき、それぞれの経路エージェントと中間的方針ゲートウェイは経路を取りこわします。 したがって、どんな単独のソースも方針ゲートウェイリソースか部分的に起伏の多い経路のまだ機能している地域を無期限に独占できません。
After generating the SETUP message and establishing the proper local forwarding information, the originator selects the next policy gateway on the path and forwards the SETUP message to the selected policy gateway. The next policy gateway selection procedure, described below, applies when either the originator or an intermediate policy gateway is making the selection. We have elected to describe the procedure from the perspective of a selecting intermediate policy gateway.
SETUPメッセージを生成して、適切なローカルの推進情報を確立した後に、創始者は、経路で隣の方針ゲートウェイを選択して、選択された方針ゲートウェイにSETUPメッセージを転送します。 創始者か中間的方針ゲートウェイのどちらかが選択をしているとき、以下で説明された次の方針ゲートウェイ選択手順は適用されます。 私たちは、選択中間的な方針ゲートウェイの見解から手順について説明するのを選びました。
The policy gateway selects the next policy gateway on a path, in round-robin order from its list of policy gateways contained in the present or next virtual gateway, as explained below. In selecting the next policy gateway, the policy gateway uses information contained in the SETUP message and information provided by VGP and by the intra-domain routing procedure.
方針ゲートウェイは経路で隣の方針ゲートウェイを選択します、現在か隣の仮想のゲートウェイに含まれた方針ゲートウェイのリストからの連続オーダーで、以下で説明されるように。 隣の方針ゲートウェイを選択する際に、方針ゲートウェイはVGPとイントラドメインルーティング手順で提供されたSETUPメッセージと情報に含まれた情報を使用します。
If the selecting policy gateway is a domain entry point, the next policy gateway must be:
選択方針であるならゲートウェイがドメインエントリー・ポイントである、隣の方針ゲートウェイは以下の通りであるに違いありません。
- A member of the next virtual gateway listed in the SETUP message.
- 隣の仮想のゲートウェイの部材はSETUPメッセージに記載しました。
- Reachable according to intra-domain routes supporting the transit
policies listed in the SETUP message.
- トランジットがSETUPメッセージに記載された方針であるとサポートするイントラドメインルートによると、届きます。
- Able to reach, according to VGP, the next domain component listed
in the SETUP message.
- VGPによると、達することができて、次のドメインコンポーネントはSETUPメッセージに記載しました。
In addition, the selecting policy gateway may use quality of service information supplied by intra-domain routing to resolve ties between otherwise equivalent next policy gateways in the same domain. In particular, the selecting policy gateway may select the next policy gateway whose connecting intra-domain route is optimal according to the requested services listed in the SETUP message.
さらに、選択している方針ゲートウェイは同じドメインの隣のそうでなければ、同等な方針ゲートウェイの間の結びつきを決議するためにイントラドメインルーティングで提供されたサービスの質情報を使用するかもしれません。 特に、選択している方針ゲートウェイはSETUPメッセージに記載された要求されたサービスに従って接続イントラドメインルートが最適である隣の方針ゲートウェイを選択するかもしれません。
Steenstrup [Page 88] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[88ページ]RFC1479IDPRは1993年7月に議定書を作ります。
If the selecting policy gateway is a domain exit point, the next policy gateway must be:
選択方針であるならゲートウェイがドメインエキジットポイントである、隣の方針ゲートウェイは以下の通りであるに違いありません。
- A member of the current virtual gateway listed in the SETUP message
(which is also the selecting policy gateway's virtual gateway).
- 現在の仮想のゲートウェイの部材はSETUPメッセージ(選択している方針ゲートウェイのも仮想のゲートウェイである)に記載しました。
- Reachable according to VGP.
- VGPによると、届きます。
- A member of the next domain component listed in the SETUP message.
- 次のドメインコンポーネントのメンバーはSETUPメッセージに記載しました。
Once the originator or intermediate policy gateway selects a next policy gateway, it forwards the SETUP message to the selected policy gateway. Each recipient (policy gateway or target) of an acceptable SETUP message performs several checks on the contents of the message, in order to determine whether to establish or reject the path. We describe these checks in detail below from the perspective of a policy gateway as SETUP message recipient.
創始者か中間的方針ゲートウェイがいったん隣の方針ゲートウェイを選択すると、それは選択された方針ゲートウェイにSETUPメッセージを転送します。 許容できるSETUPメッセージの各受取人(方針ゲートウェイか目標)はメッセージのコンテンツにいくつかのチェックを実行します、経路を確立するか、または拒絶するかを決定するために。 私たちは、方針ゲートウェイの見解からの詳細な以下でのこれらのチェックをSETUPメッセージ受取人と説明します。
7.4.1. Validating Path Identifiers
7.4.1. 経路識別子を有効にします。
The recipient of a SETUP message first checks the path identifier, to
make sure that it does not correspond to that of an already existing
or recently extinct path. To detect replays, malicious or otherwise,
path agents and policy gateways maintain a record of each path that
they establish, for max{pth_lif, pcp_old} seconds. If the path
identifier and timestamp carried in the SETUP message match a stored
path identifier and timestamp, the policy gateway considers the
message to be a retransmission and does not forward the message. If
the path identifier carried in the SETUP message matches a stored
path identifier but the two timestamps do not agree, the policy
gateway abandons path setup, logs the event for network management,
and returns an ERROR message to the originator via the previous
policy gateway.
SETUPメッセージの受取人は、最初に、それが既に既存の、または、最近消光している経路のものに対応しないのを確実にするために経路識別子をチェックします。 悪意があるかそうでない再生を検出するために、経路エージェントと方針ゲートウェイはそれらが確立するそれぞれの経路に関する記録を保守します、pthの_のlifであって、pcpな_老人が後援する最大のために。 SETUPメッセージで運ばれた経路識別子とタイムスタンプが保存された経路識別子とタイムスタンプに合っているなら、方針ゲートウェイは、「再-トランスミッション」であるメッセージを考えて、メッセージを転送しません。 経路識別子がSETUPメッセージマッチで保存された経路識別子を運びましたが、2つのタイムスタンプが同意しないなら、方針ゲートウェイは、前の方針ゲートウェイを通して創始者に経路セットアップを捨てて、ネットワークマネージメントのためにイベントを登録して、ERRORメッセージを返します。
7.4.2. Path Consistency with Configured Transit Policies
7.4.2. 構成された運送保険証券がある経路の一貫性
Provided the path identifier in the SETUP message appears to be new, the policy gateway proceeds to determine whether the information contained within the SETUP message is consistent with the transit policies configured for its domain. The policy gateway must locate the source and destination domains, the source host set and user class identifier, and the domain-specific information for its own domain, within the SETUP message, in order to evaluate path consistency. If the policy gateway fails to recognize the source user class (or one or more of the requested services), it logs the event for network management but continues with path setup. If the policy gateway fails to locate its domain within the SETUP message, it abandons path setup, logs the event for network management, and
SETUPメッセージの経路識別子が新しいように見えるなら、方針ゲートウェイは、SETUPメッセージの中に含まれた情報がドメインに構成される運送保険証券と一致しているかどうか決定しかけます。 方針ゲートウェイはソース、目的地ドメイン、送信元ホストセット、ユーザ・クラス識別子、およびそれ自身のドメインのためのドメイン特殊情報の場所を見つけなければなりません、SETUPメッセージの中で、経路の一貫性を評価するために。 方針ゲートウェイがソースユーザ・クラスを認識しないなら(または、要求されたサービスの1つ以上)、それは、ネットワークマネージメントのためにイベントを登録しますが、経路セットアップを続行します。 そして方針ゲートウェイがSETUPメッセージの中でドメインの場所を見つけないなら、経路セットアップを捨てて、ログがネットワークマネージメントのためのイベントである。
Steenstrup [Page 89] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[89ページ]RFC1479IDPRは1993年7月に議定書を作ります。
returns an ERROR message to the originator via the previous policy gateway. The originator responds by tearing down the path and subsequently removing the route from its cache.
前の方針ゲートウェイを通してERRORメッセージを創始者に返します。 創始者は、経路を取りこわして、次にキャッシュからルートを取り外すことによって、応じます。
Once the policy gateway locates its domain-specific portion of the SETUP message, it may encounter the following problems with the contents:
方針ゲートウェイがいったんSETUPメッセージのドメイン特定部位の場所を見つけると、コンテンツに関する以下の問題に行きあたるかもしれません:
- The domain-specific portion lists a transit policy not configured
for the domain.
- ドメイン特定部位はドメインに構成されなかった運送保険証券を記載します。
- The domain-specific portion lists a virtual gateway not configured
for the domain.
- ドメイン特定部位はドメインに構成されなかった仮想のゲートウェイを記載します。
In each case, the policy gateway abandons path setup, logs the event for network management, and returns an ERROR message to the originator via the previous policy gateway. These types of ERROR messages indicate to the originator that the route may have been generated using information from an out-of-date CONFIGURATION message.
その都度、方針ゲートウェイは、前の方針ゲートウェイを通して創始者に経路セットアップを捨てて、ネットワークマネージメントのためにイベントを登録して、ERRORメッセージを返します。 これらのタイプに関するERRORメッセージは、ルートが時代遅れなCONFIGURATIONメッセージからの情報を使用することで生成されたかもしれないのを創始者に示します。
The originator reacts to the receipt of such an ERROR message as follows. First, it tears down the path and removes the route from its cache. Then, it issues to a route server a ROUTE REQUEST message containing a directive to refresh the routing information database, with the most recent CONFIGURATION message from the domain that issued the ERROR message, before generating a new route.
創始者は以下のそのようなERRORメッセージの領収書に反応します。 まず最初に、それは、経路を取りこわして、キャッシュからルートを取り外します。 次に、ルーティング情報データベースをリフレッシュするために指示を含むROUTE REQUESTメッセージをルートサーバに発行します、ERRORメッセージを発行したドメインからの最新のCONFIGURATIONメッセージで、新しいルートを生成する前に。
Once it verifies that its domain-specific information in the SETUP message is recognizable, the policy gateway then checks that the information contained within the SETUP message is consistent with the transit policies configured for its domain. A policy gateway at the entry to a domain checks path consistency in the direction from originator to target, if the enabled path directions include originator to target. A policy gateway at the exit to a domain checks path consistency in the direction from target to originator, if the enabled path directions include target to originator.
一度、SETUPメッセージのドメイン特殊情報が認識可能であることを確かめて、次に、方針ゲートウェイは、SETUPメッセージの中に含まれた情報がドメインに構成される運送保険証券と一致しているのをチェックします。 ドメインへのエントリーの方針ゲートウェイは創始者から目標に方向への経路の一貫性をチェックします、可能にされた経路方向が狙う創始者を含んでいるなら。 ドメインへの出口の方針ゲートウェイは目標から創始者への方向に経路の一貫性をチェックします、可能にされた経路方向が創始者に目標を含んでいるなら。
When evaluating the consistency of the path with the transit policies configured for the domain, the policy gateway may encounter any of the following problems with SETUP message contents:
運送保険証券がドメインに構成にされているので経路の一貫性を評価するとき、方針ゲートウェイはSETUPメッセージ内容に関する以下の問題のどれかに行きあたるかもしれません:
- A transit policy does not apply in the given direction between the
virtual gateways listed in the SETUP message.
- 運送保険証券はSETUPメッセージに記載された仮想のゲートウェイの間の与えられた方向に適用されません。
- A transit policy denies access to traffic from the given host set
between the source and destination domains listed in the SETUP
message.
- 運送保険証券は、与えられたホストからのトラフィックへのアクセスがSETUPメッセージに記載されたソースと目的地ドメインの間にセットしたことを否定します。
Steenstrup [Page 90] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[90ページ]RFC1479IDPRは1993年7月に議定書を作ります。
- A transit policy denies access to traffic from the source user
class listed in the SETUP message.
- 運送保険証券はSETUPメッセージに記載されたソースユーザ・クラスからトラフィックへのアクセスを拒絶します。
- A transit policy denies access to traffic at the current time.
- 運送保険証券は現在の時間にトラフィックへのアクセスを拒絶します。
In each case, the policy gateway abandons path setup, logs the event for network management, and returns a REFUSE message to the originator via the previous policy gateway. These types of REFUSE messages indicate to the originator that the route may have been generated using information from an out-of-date CONFIGURATION message. The REFUSE message also serves to teardown the path.
その都度、方針ゲートウェイは、前の方針ゲートウェイを通して創始者に経路セットアップを捨てて、ネットワークマネージメントのためにイベントを登録して、REFUSEメッセージを返します。 これらのタイプに関するREFUSEメッセージは、ルートが時代遅れなCONFIGURATIONメッセージからの情報を使用することで生成されたかもしれないのを創始者に示します。 また、REFUSEメッセージは分解に経路に役立ちます。
The originator reacts to the receipt of such a REFUSE message as follows. First, it removes the route from its cache. Then, it issues to a route server a ROUTE REQUEST message containing a directive to refresh the routing information database, with the most recent CONFIGURATION message from the domain that issued the REFUSE message, before generating a new route.
創始者は以下のそのようなREFUSEメッセージの領収書に反応します。 まず最初に、それはキャッシュからルートを取り外します。 次に、ルーティング情報データベースをリフレッシュするために指示を含むROUTE REQUESTメッセージをルートサーバに発行します、REFUSEメッセージを発行したドメインからの最新のCONFIGURATIONメッセージで、新しいルートを生成する前に。
7.4.3. Path Consistency with Virtual Gateway Reachability
7.4.3. 仮想のゲートウェイの可到達性がある経路の一貫性
Provided the information contained in the SETUP message is consistent with the transit policies configured for its domain, the policy gateway proceeds to determine whether the path is consistent with the reachability of the virtual gateway containing the potential next hop. To determine virtual gateway reachability, the policy gateway uses information provided by VGP and by the intra-domain routing procedure.
SETUPメッセージに含まれた情報がドメインに構成される運送保険証券と一致しているなら、方針ゲートウェイは、経路が次の潜在的ホップを含んでいる仮想のゲートウェイの可到達性と一致しているかどうか決定しかけます。 仮想のゲートウェイの可到達性を決定するために、方針ゲートウェイはVGPとイントラドメインルーティング手順で提供された情報を使用します。
When evaluating the consistency of the path with virtual gateway reachability, the policy gateway may encounter any of the following problems:
仮想のゲートウェイの可到達性で経路の一貫性を評価するとき、方針ゲートウェイは以下の問題のどれかに行きあたるかもしれません:
- The virtual gateway containing the potential next hop is down.
- 次の潜在的ホップを含む仮想のゲートウェイは下がっています。
- The virtual gateway containing the potential next hop is not
reachable via any intra-domain routes supporting the transit
policies listed in the SETUP message.
- トランジットがSETUPメッセージに記載された方針であるとサポートしながら、次の潜在的ホップを含む仮想のゲートウェイはどんなイントラドメインルートでも届いていません。
- The next domain component listed in the SETUP message is not
reachable.
- SETUPメッセージに記載された次のドメインコンポーネントは届いていません。
Each of these determinations is made from the perspective of a single policy gateway and may not reflect actual reachability. In each case, the policy gateway encountering such a problem returns a REFUSE message to the previous policy gateway which then selects a different next policy gateway, in round-robin order, as described in previously. If the policy gateway receives the same response from
それぞれのこれらの決断は、1方針門の見解から作られて、実際の可到達性を反映しないかもしれません。 その都度、そのような問題に行きあたる方針ゲートウェイは次に隣の異なった方針ゲートウェイを選択する前の方針ゲートウェイにREFUSEメッセージを返します、連続オーダーで、以前に説明されるように。 ゲートウェイが同じ応答を受ける方針です。
Steenstrup [Page 91] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[91ページ]RFC1479IDPRは1993年7月に議定書を作ります。
all next policy gateways selected, it abandons path setup, logs the event for network management, and returns the REFUSE message to the originator via the previous policy gateway. These types of REFUSE messages indicate to the originator that the route may have been generated using information from an out-of-date DYNAMIC message. The REFUSE message also serves to teardown the path.
ゲートウェイが選択した次の方針、それは前の方針ゲートウェイを通して創始者に経路セットアップを捨てて、ネットワークマネージメントのためにイベントを登録して、REFUSEメッセージを返します。 これらのタイプに関するREFUSEメッセージは、ルートが時代遅れなDYNAMICメッセージからの情報を使用することで生成されたかもしれないのを創始者に示します。 また、REFUSEメッセージは分解に経路に役立ちます。
The originator reacts to the receipt of such a REFUSE message as follows. First, it removes the route from its cache. Then, it issues to a route server a ROUTE REQUEST message containing a directive to refresh the routing information database, with the most recent DYNAMIC message from the domain that issued the REFUSE message, before generating a new route.
創始者は以下のそのようなREFUSEメッセージの領収書に反応します。 まず最初に、それはキャッシュからルートを取り外します。 次に、ルーティング情報データベースをリフレッシュするために指示を含むROUTE REQUESTメッセージをルートサーバに発行します、REFUSEメッセージを発行したドメインからの最新のDYNAMICメッセージで、新しいルートを生成する前に。
7.4.4. Obtaining Resources
7.4.4. リソースを得ます。
Once the policy gateway determines that the SETUP message contents are consistent with the transit policies and virtual gateway reachability of its domain, it attempts to gain resources for the new path. For this version of IDPR, path resources consist of memory in the local forwarding information database. However, in the future, path resources may also include reserved link bandwidth.
方針ゲートウェイが、SETUPメッセージ内容がドメインの運送保険証券と仮想のゲートウェイの可到達性と一致していることをいったん決定すると、それは、新しい経路のためのリソースを獲得するのを試みます。 IDPRのこのバージョンのために、経路リソースはローカルの推進情報データベースのメモリから成ります。 しかしながら、また、将来、経路リソースは予約されたリンク帯域幅を含むかもしれません。
If the policy gateway does not have sufficient resources to establish the new path, it uses the following algorithm to determine whether to generate a REFUSE message for the new path or a TEARDOWN message for an existing path in favor of the new path. There are two cases:
方針ゲートウェイに新しい経路を証明できるくらいのリソースがないなら、それは、新しい経路を支持して新しい経路へのREFUSEメッセージか既存の経路へのTEARDOWNメッセージを生成するかどうか決定するのに以下のアルゴリズムを使用します。 2つのケースがあります:
- No paths have been idle for more than pcp_idle (300) seconds. In
this case, the policy gateway returns a REFUSE message to the
previous policy gateway. This policy gateway then tries to select
a different next policy gateway, as described previously, provided
the policy gateway that issued the REFUSE message was not the
target. If the REFUSE message was issued by the target or if there
is no available next policy gateway, the policy gateway returns
the REFUSE message to the originator via the previous policy
gateway and logs the event for network management. The REFUSE
message serves to tear down the path.
- pcp_暇な(300)秒以上には、どんな経路も活動していなくはありません。 この場合、方針ゲートウェイは前の方針ゲートウェイにREFUSEメッセージを返します。 次に、この方針ゲートウェイは隣の異なった方針ゲートウェイを選択しようとします、以前に説明されるように、REFUSEメッセージを発行した方針ゲートウェイが目標でなかったなら。 目標でREFUSEメッセージを発行したか、または隣のどんな利用可能な方針ゲートウェイもなければ、方針ゲートウェイは、前の方針ゲートウェイを通してREFUSEメッセージを創始者に返して、ネットワークマネージメントのためにイベントを登録します。 REFUSEメッセージは、経路を取りこわすのに役立ちます。
- At least one path has been idle for more than pcp_idle seconds. In
this case, the policy gateway tears down an older path in order to
accommodate the newer path and logs the event for network
management. Specifically, the policy gateway tears down the least
recently used path among those that have been idle for longer than
pcp_idle seconds, resolving ties by choosing the oldest such path.
- pcp_暇な秒以上に、少なくとも1つの経路が活動していません。 この場合、方針ゲートウェイは、より新しい経路を収容するために、より古い経路を取りこわして、ネットワークマネージメントのためにイベントを登録します。 明確に、方針ゲートウェイはpcp_暇な秒より長い間活動していないものまで最も最近でない中古の経路を取りこわします、そのような最も古い経路を選ぶことによって結びつきを決議して。
If the policy gateway has sufficient resources to establish the path,
方針ゲートウェイに経路を証明できるくらいのリソースがあるなら
Steenstrup [Page 92] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[92ページ]RFC1479IDPRは1993年7月に議定書を作ります。
it attempts to update its local forwarding information database with information about the path identifier, previous and next policy gateways on the path, and directions in which the path should be enabled for data traffic transport.
それは、経路識別子、経路、および経路がデータ通信量輸送のために可能にされるべきである方向の前で隣の方針ゲートウェイの情報でローカルの推進情報データベースをアップデートするのを試みます。
7.4.5 Target Response
7.4.5 目標応答
When an acceptable SETUP message successfully reaches an entry policy gateway in the destination or destination proxy domain, this policy gateway performs all of the SETUP message checks described in the above sections. The policy gateway's path agent then becomes the target, provided no checks fail, unless there is an explicit target specified in the SETUP message. For example, remote route servers act as originator and target during RSQP message exchanges (see section 5.2). If the recipient policy gateway is not the target, it attempts to forward the SETUP message to the target along an intra- domain route. However, if the target is not reachable via intra- domain routing, the policy gateway abandons path setup, logs the event for network management, and returns a REFUSE message to the originator via the previous policy gateway. The REFUSE message serves to tear down the path.
許容できるSETUPメッセージが首尾よく目的地か目的地プロキシドメインのエントリー方針ゲートウェイに達すると、この方針ゲートウェイは上のセクションで説明されたSETUPメッセージチェックのすべてを実行します。 次に、方針ゲートウェイの経路エージェントは目標になります、チェックが全く失敗しないなら、SETUPメッセージで指定された明白な目標がない場合。 例えば、リモートルートサーバは、交換処理を創始者として機能して、RSQPの間、狙います(セクション5.2を見てください)。 受取人方針ゲートウェイが目標でないなら、それは、イントラドメインルートに沿った目標にSETUPメッセージを転送するのを試みます。 しかしながら、目標がイントラドメインルーティングで届かないなら、方針ゲートウェイは、前の方針ゲートウェイを通して創始者に経路セットアップを捨てて、ネットワークマネージメントのためにイベントを登録して、REFUSEメッセージを返します。 REFUSEメッセージは、経路を取りこわすのに役立ちます。
Once the SETUP message reaches the target, the target determines whether it has sufficient path resources. The target generates an ACCEPT message, provided it has sufficient resources to establish the path. Otherwise, it generates a REFUSE message.
それに十分な経路リソースがあるか否かに関係なく、目標は、一度、SETUPメッセージが目標に達することを決定します。 それに経路を証明できるくらいのリソースがあるなら、目標はACCEPTメッセージを生成します。 さもなければ、それはREFUSEメッセージを生成します。
The target may choose to use the reverse path to transport data traffic to the source domain, if the enabled path directions include 10 or 11. However, the target must first verify the consistency of the reverse path with its own domain's configured transit policies, before sending data traffic over that path.
目標は、ソースドメインへのデータ通信量を輸送するのに逆の経路を使用するのを選ぶかもしれません、可能にされた経路方向が10か11を含んでいるなら。 しかしながら、目標は最初にそれ自身のドメインの構成された運送保険証券で逆の経路の一貫性について確かめなければなりません、その経路の上にデータ通信量を送る前に。
7.4.6. Originator Response
7.4.6. 創始者応答
The originator expects to receive an ACCEPT, REFUSE, or ERROR message in response to a SETUP message and reacts as follows:
創始者は、SETUPメッセージに対応してACCEPT、REFUSE、またはERRORメッセージを受け取ると予想して、以下の通り反応します:
- The originator receives an ACCEPT message, confirming successful
path establishment. To expedite data delivery, the originator may
forward data messages along the path prior to receiving an ACCEPT
message, with the understanding that there is no guarantee that the
path actually exists.
- うまくいっている経路設立を確認して、創始者はACCEPTメッセージを受け取ります。 ACCEPTメッセージを受け取る前にデータ配送を速めるために、創始者は経路に沿ってデータメッセージを転送するかもしれません、経路が実際に存在しているという保証が全くないという条件で。
- The originator receives a REFUSE message or an ERROR message,
implying that the path could not be successfully established. In
response, the originator attempts to set up a different path to the
same destination, as long as the number of selected different paths
- 首尾よく経路を確立できなかったのを含意して、創始者はREFUSEメッセージかERRORメッセージを受け取ります。 応答では、創始者は、同じ目的地に異なった経路をセットアップするのを試みます、選択された異なった経路の数と同じくらい長いです。
Steenstrup [Page 93] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[93ページ]RFC1479IDPRは1993年7月に議定書を作ります。
does not exceed setup_try (3). If the originator is unsuccessful
after setup_try attempts, it abandons path setup and logs the event
for network management.
セットアップ_トライ(3)を超えていません。 創始者がセットアップ_の後に失敗しているなら試みを試みてください、それは、経路セットアップを捨てて、ネットワークマネージメントのためにイベントを登録します。
- The originator fails to receive any response to the SETUP message
within setup_int microseconds after transmission. In this case,
the originator attempts path setup using the same policy route and
a new path identifier, as long as the number of path setup attempts
using the same route does not exceed setup_ret (2). If the
originator fails to receive a response to a SETUP message after
setup_ret attempts, it logs the event for network management and
then proceeds as though it received a negative response, namely a
REFUSE or an ERROR, to the SETUP message. Specifically, it
attempts to set up a different path to the same destination, or it
abandons path setup altogether, depending on the value of
setup_try.
- 創始者はトランスミッションの_intマイクロセカンド後にセットアップの中でSETUPメッセージへの少しの応答も受けません。 _この場合、創始者は同じ方針ルートと新しい経路識別子を使用することで経路セットアップを試みて、同じルートを使用する経路セットアップ試みの数がセットアップを超えていない限り、(2)を浸水させてください。 セットアップ_が試みを浸水させた後に創始者がSETUPメッセージへの応答を受けないなら、それは、ネットワークマネージメントのためにイベントを登録して、まるですなわち、SETUPメッセージへの否定応答、REFUSEまたはERRORを受けるかのように続きます。 明確に、同じ目的地に異なった経路をセットアップするのを試みるか、または全体で経路セットアップを捨てます、_が試みるセットアップの値によって。
7.4.7. Path Life
7.4.7. 経路の寿命
Once set up, a path does not live forever. A path agent or policy gateway may tear down an existing path, provided any of the following conditions are true:
いったんセットアップされると、経路はいつまでも、生きていません。経路エージェントか方針ゲートウェイが既存の経路を取りこわすかもしれません、以下の条件のどれかが本当であるなら:
- The maximum path lifetime (in minutes, bytes, or messages) has been
exceeded at the originator, the target, or an intermediate policy
gateway. In each case, the IDPR entity detecting path expiration
logs the event for network management and generates a TEARDOWN
message as follows:
- 最大の経路寿命(数分、バイト、またはメッセージの)は創始者、目標、または中間的方針ゲートウェイで超えられています。 その都度、経路満了を検出するIDPR実体は、ネットワークマネージメントのためにイベントを登録して、以下のTEARDOWNメッセージを生成します:
o The originator path agent generates a TEARDOWN message for
propagation toward the target.
o 創始者経路エージェントは伝播へのTEARDOWNメッセージを目標に向かって生成します。
o The target path agent generates a TEARDOWN message for
propagation toward the originator.
o 目標経路エージェントは伝播へのTEARDOWNメッセージを創始者に向かって生成します。
o An intermediate policy gateway generates two TEARDOWN messages,
one for propagation toward the originator and one for
propagation toward the target.
o 中間的方針ゲートウェイは2つのTEARDOWNメッセージ、創始者に向かった伝播のためのもの、および伝播のための1つを目標に向かって生成します。
- The previous or next policy gateway becomes unreachable, across a
virtual gateway or across a domain according to a given transit
policy, and the path is not reparable. In either case, the policy
gateway detecting the reachability problem logs the event for
network management and generates a TEARDOWN message as follows:
- 前であるか隣の方針ゲートウェイは与えられた運送保険証券によると、仮想のゲートウェイかドメインの向こう側に手が届かなくなります、そして、経路は補償可能ではありません。 どちらかのケース、方針ゲートウェイ検出における可到達性問題は、ネットワークマネージメントのためにイベントを登録して、以下のTEARDOWNメッセージを生成します:
o If the previous policy gateway is unreachable, an intermediate
policy gateway generates a TEARDOWN message for propagation to
the target.
o 前の方針ゲートウェイが手が届かないなら、中間的方針ゲートウェイは伝播へのTEARDOWNメッセージを目標に生成します。
Steenstrup [Page 94] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[94ページ]RFC1479IDPRは1993年7月に議定書を作ります。
o If the next policy gateway is unreachable, an intermediate
policy gateway generates a TEARDOWN message for propagation to
the originator.
o 隣の方針ゲートウェイが手が届かないなら、中間的方針ゲートウェイは伝播へのTEARDOWNメッセージを創始者に生成します。
- All of the policy gateway's path resources are in use at the
originator, the target, or an intermediate policy gateway, a new
path requires resources, and the given existing path is expendable,
according to the least recently used criterion discussed in section
7.4.4 above. In each case, the IDPR entity initiating path
preemption logs the event for network management and generates a
TEARDOWN message as follows:
- 方針ゲートウェイの経路リソースのすべてが創始者、目標、または中間的方針ゲートウェイで使用中です、そして、新しい経路はリソースを必要とします、そして、与えられた既存の経路は消費してよいです、上のセクション7.4.4で議論した最も最近でない中古の評価基準に従って。 その都度、経路先取りを開始するIDPR実体は、ネットワークマネージメントのためにイベントを登録して、以下のTEARDOWNメッセージを生成します:
o The originator path agent generates a TEARDOWN message for
propagation toward the originator.
o 創始者経路エージェントは伝播へのTEARDOWNメッセージを創始者に向かって生成します。
o The target path agent generates a TEARDOWN message for
propagation toward the originator.
o 目標経路エージェントは伝播へのTEARDOWNメッセージを創始者に向かって生成します。
o An intermediate policy gateway generates two TEARDOWN messages,
one for propagation toward the originator and one for
propagation toward the target.
o 中間的方針ゲートウェイは2つのTEARDOWNメッセージ、創始者に向かった伝播のためのもの、および伝播のための1つを目標に向かって生成します。
Path teardown at a path agent or policy gateway, whether initiated by one of the above events, by receipt of a TEARDOWN message, or by receipt of a REFUSE message during path setup (as discussed in the previous sections), results in the path agent or policy gateway releasing all resources devoted to both directions of the path.
上のイベントの1つ、TEARDOWNメッセージの領収書、または経路セットアップの間のREFUSEメッセージの領収書で開始される(前項で議論するように)か否かに関係なく、経路エージェントか方針ゲートウェイの経路分解は経路の両方の方向にささげられたすべてのリソースを発表する経路エージェントか方針ゲートウェイをもたらします。
7.5. Path Failure and Recovery
7.5. 経路失敗と回復
When a policy gateway fails, it may not be able to save information pertaining to its established paths. Thus, when the policy gateway returns to service, it may have no recollection of the paths set up through it and hence may no longer be able to forward data messages along these paths. We expect that when a policy gateway fails, it will usually be out of service for long enough that the up/down protocol and the intra-domain routing procedure can detect that the particular policy gateway is no longer reachable. In this case, adjacent or neighbor policy gateways that have set up paths through the failed policy gateway and that have detected the failure, attempt local path repair (see section 7.5.2 below), and if unsuccessful, issue TEARDOWN messages for all affected paths.
方針ゲートウェイが失敗するとき、それは確立した経路に関係する情報を保存できないかもしれません。 したがって、方針ゲートウェイがサービスに戻るとき、それは、それを通して経路の回想を全くセットアップさせないで、したがって、もうこれらの経路に沿ってデータメッセージを転送できないかもしれません。 私たちは方針ゲートウェイが失敗して、通常、それが上がるか下がるのが議定書を作るくらいの長い間使われなくなっているそれとルーティング手順が検出できるイントラドメインを予想します。特定の方針ゲートウェイはもう届いていません。 この場合、失敗した方針ゲートウェイを通して経路をセットアップした隣接するか隣人方針ゲートウェイとそれは失敗を検出しました、そして、地方の経路修理を試みてください、そして、(セクション7.5.2未満を見てください)失敗しているなら、すべての影響を受ける経路へのメッセージをTEARDOWNに発行してください。
Steenstrup [Page 95] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[95ページ]RFC1479IDPRは1993年7月に議定書を作ります。
7.5.1. Handling Implicit Path Failures
7.5.1. 暗黙の経路失敗を扱います。
Nevertheless, policy gateways along a path must be able to handle the case in which a policy gateway fails and subsequently returns to service without either the up/down protocol or the intra-domain routing procedure detecting the failure; we do not expect this event to occur often. If the policy gateway, prior to failure, contained forwarding information for several established paths, it may now receive many IDPR data messages containing unrecognized path identifiers. The policy gateway should alert the data sources that their paths through it are no longer viable.
それにもかかわらず、経路に沿った方針ゲートウェイは失敗を検出しながら、方針ゲートウェイが失敗して、次に上がるのも下がるのなしで修理するリターンが議定書を作る場合かイントラドメインルーティング手順を扱うことができなければなりません。 私たちは、このイベントが頻出すると予想しません。 方針ゲートウェイが失敗の前にいくつかの確立した経路のための推進情報を含んだなら、それは現在、認識されていない経路識別子を含む多くのIDPRデータメッセージを受け取るかもしれません。 方針ゲートウェイは、それを通したそれらの経路がもう実行可能でないとデータ送信端末に警告するはずです。
Policy gateways that receive IDPR data messages with unrecognized path identifiers take one of the following two actions, depending upon their past failure record:
認識されていない経路識別子でIDPRデータメッセージを受け取る方針ゲートウェイが以下の2つの動作の1つを取ります、それらの過去の失敗記録によって:
- The policy gateway has not failed in the past pg_up (24) hour
period. In this case, there are at least four possible reasons for
the unrecognized path identifier in the data message:
- 方針ゲートウェイは過去のpg_に(24) 一時間の期間に失敗していません。 この場合、データメッセージには認識されていない経路識別子の少なくとも4つの可能な理由があります:
o The data message path identifier has been corrupted in a way
that is not detectable by the integrity/authentication value, if
one is present.
o データメッセージ経路識別子は保全/認証値で検出可能でない方法で腐敗しています、1つが存在しているなら。
o The policy gateway has experienced a memory error.
o 方針ゲートウェイはメモリ誤りを経験しました。
o The policy gateway failed sometime during the life of the path
and source sent no data on the path for a period of pg_up hours
following the failure. Although paths may persist for more than
pg_up hours, we expect that they will also be used more
frequently than once every pg_up hours.
o 経路とソースの寿命の間のいつか失敗された方針ゲートウェイはしばらく、失敗が何時間も以下であるところでpg_についてデータを全く経路に送りませんでした。 経路はpg_以上で何時間も持続するかもしれませんが、私たちは、また、それらがかつてのあらゆるpg_より頻繁に何時間も使用されると予想します。
o The path was not successfully established, and the originator
sent data messages down the path prior to receiving a response
to its SETUP message.
o 経路は首尾よく確立されませんでした、そして、SETUPメッセージへの応答を受ける前に、創始者はデータメッセージを経路の下側に送りました。
In all cases, the policy gateway discards the data message and
logs the event for network management.
すべての場合では、方針ゲートウェイは、データメッセージを捨てて、ネットワークマネージメントのためにイベントを登録します。
- The policy gateway has failed at least once in the past pg_up hour
period. Thus, the policy gateway assumes that the unrecognized
path identifier in the data message may be attributed to its
failure. In response to the data message, the policy gateway
generates an ERROR message containing the unrecognized path
identifier. The policy gateway then sends the ERROR message back
to the entity from which it received the data message, which should
be equivalent to the previous policy gateway on the path.
- 方針ゲートウェイは少なくとも一度過去のpg_に一時間の期間に失敗したことがあります。 したがって、方針ゲートウェイは、データメッセージの認識されていない経路識別子が失敗の結果と考えられるかもしれないと仮定します。 データメッセージに対応して、方針ゲートウェイは認識されていない経路識別子を含むERRORメッセージを生成します。 そして、方針ゲートウェイはそれが経路の前の方針ゲートウェイに同等であるべきデータメッセージを受け取った実体にERRORメッセージを送り返します。
Steenstrup [Page 96] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[96ページ]RFC1479IDPRは1993年7月に議定書を作ります。
When the previous policy gateway receives such an ERROR message, it decides whether the message is acceptable. If the policy gateway does not recognize the path identifier contained in the ERROR message, it does not find the ERROR message acceptable and subsequently discards the message. However, if the policy gateway does find the ERROR message acceptable, it then determines whether it has already received an ACCEPT message for the given path. If the policy gateway has not received an ACCEPT message for that path, it discards the ERROR message and takes no further action.
前の方針ゲートウェイがそのようなERRORメッセージを受け取るとき、それは、メッセージが許容できるかどうか決めます。 方針ゲートウェイがERRORメッセージに含まれた経路識別子を認識しないなら、それは、ERRORメッセージが許容できるのがわからないで、次に、メッセージを捨てます。 しかしながら、方針ゲートウェイがそうするなら、許容できるERRORメッセージを見つけてください、とそして、既に与えられた経路へのACCEPTメッセージを受け取ったか否かに関係なく、それは決定します。 方針ゲートウェイが受信されていないなら、その経路へのACCEPTメッセージであり、それは、ERRORメッセージを捨てて、さらなる行動を全く取りません。
If the policy gateway has received an ACCEPT message for that path, it then attempts path repair, as described in section 7.5.2 below. Only if path repair is unsuccessful does the previous policy gateway generate a TEARDOWN message for the path and return it to the originator. The TEARDOWN message includes the domain and virtual gateway containing the policy gateway that failed, which aids the originator in selecting a new path that does not include the domain containing the failed policy gateway. This mechanism ensures that path agents quickly discover and recover from disrupted paths, while guarding against unwarranted path teardown.
方針ゲートウェイがその経路へのACCEPTメッセージを受け取ったなら、経路修理を試みます、セクション7.5.2未満で説明されるように。 経路修理が失敗している場合にだけ、前の方針ゲートウェイは、TEARDOWNメッセージを経路に発生させて、それを創始者に返しますか? TEARDOWNメッセージは失敗した方針ゲートウェイを含むドメインと仮想のゲートウェイを含んで、どの援助が失敗した方針ゲートウェイを含むドメインを含んでいない新しい経路を選択することにおいて創始者であるか。 このメカニズムは、保証のない経路分解に用心している間、経路エージェントが混乱させた経路からすぐに発見して、回復するのを確実にします。
7.5.2. Local Path Repair
7.5.2. 地方の経路修理
Failure of one of more entities on a given path may render the path unusable. If the failure is within a domain, IDPR relies on the intra-domain routing procedure to find an alternate route across the domain, which leaves the path unaffected. If the failure is in a virtual gateway, policy gateways must bear the responsibility of repairing the path. Policy gateways nearest to the failure are the first to recognize its existence and hence can react most quickly to repair the path.
与えられた経路の、より多くの実体の1つの失敗は経路を使用不可能にするかもしれません。 ドメインの中に失敗があるなら、IDPRは、ドメインの向こう側に代替経路を見つけるためにイントラドメインルーティング手順を当てにします。ドメインは経路を影響を受けないままにします。 失敗が仮想のゲートウェイにあるなら、方針ゲートウェイは経路を修理する責任を担わなければなりません。 失敗に最も近い方針ゲートウェイは、存在を認識する1番目であり、したがって、経路を修理するために最も急速に反応できます。
Relinquishing control over path repair to policy gateways in other domains may be unacceptable to some domain administrators. The reason is that these policy gateways cannot guarantee construction of a path that satisfies the source policies of the source domain, as they have no knowledge of other domains' source policies.
何人かのドメイン管理者にとって、他のドメインの方針ゲートウェイに経路修理のコントロールを放棄するのは容認できないかもしれません。 理由はこれらの方針ゲートウェイがソースドメインのソース方針を満たす経路の工事を保証できないということです、それらに他のドメインのソース方針に関する知識が全くないとき。
Nevertheless, limited local path repair is feasible, without distributing either source policy information throughout an internetwork or detailed path information among policy gateways in the same domain or in the same virtual gateway. We say that a path is "locally reparable" if there exists an alternate route between two policy gateways, separated by at most one virtual gateway, on the path. This definition covers path repair in the presence of failed routes between consecutive policy gateways as well as failed policy gateways themselves.
それにもかかわらず、限られた地方の経路修理は可能です、同じドメインか同じ仮想のゲートウェイの方針ゲートウェイの中でインターネットワーク中のソース方針情報か詳細な経路情報のどちらかを分配しないで。 私たちは、代替経路が高々仮想の1つの門によって切り離された2方針門の間に存在しているなら経路が「局所的に補償可能である」と言います、経路で。 この定義は失敗した方針ゲートウェイ自体と同様に連続した方針ゲートウェイの間の失敗したルートがあるとき経路修理をカバーしています。
Steenstrup [Page 97] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[97ページ]RFC1479IDPRは1993年7月に議定書を作ります。
An IDPR entity attempts local repair of an established path, in the direction from originator to target, immediately after detecting that the next policy gateway on the path is no longer reachable. To prevent multiple path repairs in response to the same failure, we have stipulated that path repair can only be initiated in the direction from originator to target. The IDPR entity initiating local path repair attempts to find an alternate path to the policy gateway immediately following the unreachable policy gateway on the path.
IDPR実体は創始者からの方向への確立した経路の狙う局部的修繕を試みます、それを検出して、経路の隣の方針ゲートウェイがもう届いていない直後。 同じ失敗に対応して複数の経路修理を防ぐために、私たちは、創始者から目標への方向に経路修理を開始できるだけであるのを規定しました。 経路の手の届かない方針ゲートウェイに続いて、地方の経路修理を開始するIDPR実体は、すぐに方針ゲートウェイに代替パスを見つけるのを試みます。
Local path repair minimizes the disruption of data traffic flow caused by certain types of failures along an established path. Specifically, local path repair can accommodate an individual failed policy gateway or failed direct connection between two adjacent policy gateways. However, it can only be attempted through virtual gateways containing multiple peer policy gateways. Local path repair is not designed to repair paths traversing failed virtual gateways or domain partitions. Whenever local path repair is impossible, the failing path must be torn down.
地方の経路修理は確立した経路に沿ってあるタイプの失敗によって引き起こされたデータ交通の流れの分裂を最小にします。 明確に、地方の経路修理は隣接している2方針門の間の個々の失敗した方針ゲートウェイか失敗したダイレクト接続を収容できます。 しかしながら、複数の同輩方針ゲートウェイを含む仮想のゲートウェイを通してそれを試みることができるだけです。 地方の経路修理は、失敗した仮想のゲートウェイかドメインパーティションを横断する経路を修理するように設計されていません。 地方の経路修理が不可能であるときはいつも、失敗経路を取りこわさなければなりません。
7.5.3. Repairing a Path
7.5.3. 経路を修理します。
When an IDPR entity detects through an ERROR message that the next policy gateway has no knowledge of a given path, it generates a REPAIR message and forwards it to the next policy gateway. This REPAIR message will reestablish the path through the next policy gateway.
IDPR実体が隣の方針ゲートウェイには与えられた経路に関する知識が全くなくて、REPAIRメッセージを発生させるというERRORメッセージに前方に隣の方針ゲートウェイにそれを検出するとき。 このREPAIRメッセージは隣の方針ゲートウェイを通して経路を回復させるでしょう。
When an entity detects that the next policy gateway on a path is no longer reachable, it takes one of the following actions, depending upon whether the entity is a member of the next policy gateway's virtual gateway.
実体がそれを検出するとき、経路の隣の方針ゲートウェイがもう届いていない、以下の動作の1つを取ります、実体が隣の方針ゲートウェイの仮想のゲートウェイの部材であるかどうかに頼っていて。
- If the entity is not a member of the next policy gateway's virtual
gateway, then one of the following two conditions must be true:
- 実体が隣の方針ゲートウェイの仮想のゲートウェイの部材でないなら、以下の2つの条件の1つは本当であるに違いありません:
o The next policy gateway has a peer that is reachable via an
intra-domain route consistent with the requested services. In
this case, the entity generates a REPAIR message containing the
original SETUP message and forwards it to the next policy
gateway's peer.
o 隣の方針ゲートウェイには、要求されたサービスと一致したイントラドメインルートで届いている同輩がいます。 この場合、実体は、オリジナルのSETUPメッセージを含むREPAIRメッセージを発生させて、隣の方針ゲートウェイの同輩にそれを送ります。
o The next policy gateway has no peers that are reachable via
intra-domain routes consistent with the requested services. In
this case, the entity tears down the path back to the
originator.
o 隣の方針ゲートウェイには、どんな要求されたサービスと一致したイントラドメインルートで届いている同輩もいません。 この場合、実体は創始者まで経路を取りこわして戻します。
- If the entity is a member of the next policy gateway's virtual
- 実体が次の方針のメンバーであるなら、ゲートウェイは仮想です。
Steenstrup [Page 98] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[98ページ]RFC1479IDPRは1993年7月に議定書を作ります。
gateway, then one of the following four conditions must be true:
ゲートウェイ、当時以下の4つの条件の1つは本当であるに違いありません:
o The next policy gateway has a peer that belongs to the same
domain component and is directly-connected to and reachable from
the entity. In this case, the entity generates a REPAIR message
and forwards it to the next policy gateway's peer.
o 隣の方針ゲートウェイは、実体から同じドメインコンポーネントに属す同輩がいて、直接接続されていて届いています。 この場合、実体は、REPAIRメッセージを発生させて、隣の方針ゲートウェイの同輩にそれを送ります。
o The next policy gateway has a peer that belongs to the same
domain component, is not directly-connected to the entity, but
is directly-connected to and reachable from one of the entity's
peers, which in turn is reachable from the entity via an intra-
domain route consistent with the requested services. In this
case, the entity generates a REPAIR message and forwards it to
its peer.
o 隣の方針ゲートウェイには、実体の同輩のひとりから同じドメインコンポーネントに属していますが、直接実体に関連していませんが、直接接続されて、届いている同輩がいます(実体から要求されたサービスと一致したイントラドメインルートで順番に届いています)。 この場合、実体は、REPAIRメッセージを発生させて、それを同輩に送ります。
o The next policy gateway has no operational peers within its
domain component, but is directly-connected to and reachable
from one of the entity's peers, which in turn is reachable from
the entity via an intra-domain route consistent with the
requested services. In this case, the entity generates a REPAIR
message and forwards it to its peer.
o 隣の方針ゲートウェイは、実体の同輩のひとりから要求されたサービスと一致していた状態でどんな操作上の同輩もドメインコンポーネントの中にいませんが、直接接続されていて届いています。(順番に、その同輩は、イントラドメインルートで実体から届いた状態でいます)。 この場合、実体は、REPAIRメッセージを発生させて、それを同輩に送ります。
o The next policy gateway has no operational peers within its
domain component, and the entity has no operational peers which
are both reachable via intra-domain routes consistent with the
requested services and directly-connected to and reachable from
the next policy gateway. In this case, the entity tears down
the path back to the originator.
o 隣の方針ゲートウェイには、どんな操作上の同輩もドメインコンポーネントの中にいません、そして、実体では、どんな操作上の同輩もいません(隣の方針ゲートウェイから要求されたサービスと一致したイントラドメインルートを通して届いて、かつ直接接続されて、かつ届いています)。 この場合、実体は創始者まで経路を取りこわして戻します。
A recipient of a REPAIR message takes the following steps, depending upon its relationship to the entity that issued the REPAIR message.
REPAIRメッセージの受取人は以下の方法を採ります、REPAIRメッセージを発行した実体との関係によって。
- The recipient and the issuing entity are in the same domain or in
same virtual gateway. In this case, the recipient extracts the
SETUP message contained within the REPAIR message and treats the
message as it would any other SETUP message. Specifically, the
recipient checks consistency of the path with its domain's transit
policies and virtual gateway reachability. If there are
unrecognized portions of the SETUP message, the recipient generates
an ERROR message, and if there are path inconsistencies, the
recipient generates a REFUSE message. In either case, the
recipient returns the corresponding message to the policy gateway
from which it received the REPAIR message. Otherwise, if the
recipient accepts the REPAIR message, it updates its local
forwarding information database accordingly and forwards the REPAIR
message to a potential next policy gateway, according to the
information contained in the enclosed SETUP message.
- 受取人と発行実体が同じドメインか同じ仮想のゲートウェイにあります。 この場合、受取人は、REPAIRメッセージの中に含まれたSETUPメッセージを抜粋して、いかなる他のSETUPメッセージも扱うようにメッセージを扱います。 明確に、受取人はドメインの運送保険証券と仮想のゲートウェイの可到達性に経路の一貫性について問い合わせます。 SETUPメッセージの認識されていない部分があれば、受取人はERRORメッセージを発生させます、そして、経路矛盾があれば、受取人はREFUSEメッセージを発生させます。 どちらの場合ではも、受取人はそれがREPAIRメッセージを受け取った方針ゲートウェイに対応するメッセージを返します。 さもなければ、受取人がREPAIRメッセージを受け入れるなら、それに従って、ローカルの推進情報データベースをアップデートして、隣の潜在的方針ゲートウェイにREPAIRメッセージを転送します、同封のSETUPメッセージに含まれた情報によると。
Steenstrup [Page 99] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[99ページ]RFC1479IDPRは1993年7月に議定書を作ります。
- The recipient and the issuing entity are in different domains and
different virtual gateways. In this case, the recipient extracts
the SETUP message from the REPAIR message and determines whether
the associated path matches any of its established paths. If the
path does not match an established path, the recipient generates a
REFUSE message and returns it to the policy gateway from which it
received the REPAIR message. In response to the receipt of a
REFUSE message, the policy gateway tries a different next policy
gateway.
- 受取人と発行実体が異なったドメインと異なった仮想のゲートウェイにあります。 この場合、受取人は、REPAIRメッセージからSETUPメッセージを抜粋して、関連経路が確立した経路のどれかに合っているかどうかと決心しています。 経路が確立した経路に合っていないなら、受取人は、それがREPAIRメッセージを受け取った方針ゲートウェイにREFUSEメッセージを発生させて、それを返します。 REFUSEメッセージの領収書に対応して、方針ゲートウェイは隣の異なった方針ゲートウェイを試します。
The path is reparable, if a path match is discovered. In this case, the recipient updates the path entry in the local forwarding information database and issues an ACCEPT message to the policy gateway from which it received the REPAIR message, which in turn returns the message to the entity that issued the REPAIR message. The path is irreparable if all potential next policy gateways have been exhausted and a path match has yet to be discovered. In this case, the policy gateway that fails to locate a next policy gateway issues a TEARDOWN message to return to the originator.
経路マッチが発見されるなら、経路は補償可能です。 この場合、受取人は、ローカルの推進情報データベースで経路エントリーをアップデートして、それがREPAIRメッセージを発行した実体へのメッセージが順番に戻るREPAIRメッセージを受け取った方針ゲートウェイにACCEPTメッセージを発行します。 隣のすべての潜在的方針ゲートウェイが消耗しているというわけではなくて、経路マッチがまだ発見されていないなら、経路は修繕できません。 この場合、隣の方針ゲートウェイの場所を見つけない方針ゲートウェイは創始者に戻るTEARDOWNメッセージを発行します。
An IDPR entity expects to receive an ACCEPT, TEARDOWN, REFUSE, or ERROR message in response to a REPAIR message and reacts to these responses differently as follows:
IDPR実体は、REPAIRメッセージに対応してACCEPT、TEARDOWN、REFUSE、またはERRORメッセージを受け取ると予想して、以下の通りこれらの応答に異なって反応します:
- The entity always returns a TEARDOWN message to the originator via
previous policy gateway.
- 実体は前の方針ゲートウェイを通していつもTEARDOWNメッセージを創始者に返します。
- The entity does not return an ACCEPT message to the originator, but
receipt of such a message indicates that the path has been
successfully repaired.
- 実体はACCEPTメッセージを創始者に返しませんが、そのようなメッセージの領収書は、経路が首尾よく修理されたのを示します。
- The entity infers that the path is irreparable and subsequently
tears down the path and logs the event for network management, upon
receipt of a REFUSE or ERROR message or when no response to the
REPAIR message arrives within setup_int microseconds.
- REFUSEかERRORメッセージを受け取り次第ネットワークマネージメントかそれともREPAIRメッセージへの応答が全くセットアップ_intマイクロセカンドの以内にいつ到着していないか間、実体は、経路が修繕できないと推論して、次に、経路を取りこわして、出来事を登録します。
When an entity detects that the previous policy gateway on a path becomes unreachable, it expects to receive a REPAIR message within setup_wait microseconds. If the entity does not receive a REPAIR message for the path within that time, it infers that the path is irreparable and subsequently tears down the path and logs the event for network management.
実体がそれを検出するとき、経路の前の方針ゲートウェイは手が届かなくなって、それは、セットアップ_待ちマイクロセカンドの以内にREPAIRメッセージを受け取ると予想します。 実体がその時中に経路へのREPAIRメッセージを受け取らないなら、それは、経路が修繕できないと推論して、次に、経路を取りこわして、ネットワークマネージメントのために出来事を登録します。
7.6. Path Control Message Formats
7.6. 経路制御メッセージ・フォーマット
The path control protocol number is equal to 3. We describe the contents of each type of PCP message below.
経路制御プロトコル番号は3と等しいです。 私たちは以下のそれぞれのタイプに関するPCPメッセージのコンテンツについて説明します。
Steenstrup [Page 100] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[100ページ]RFC1479IDPRは1993年7月に議定書を作ります。
7.6.1. SETUP
7.6.1. セットアップ
The SETUP message type is equal to 0.
SETUPメッセージタイプは0に堪えます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH ID |
| |
+-------------------------------+-------------------------------+
| SRC AD | HST SET |
+---------------+---------------+-------------------------------+
| UCI | UNUSED | NUM RQS |
+---------------+---------------+-------------------------------+
| DST AD | TGT ENT |
+-------------------------------+-------------------------------+
| AD PTR |
+-------------------------------+
For each requested service for the path:
+-------------------------------+-------------------------------+
| RQS TYP | RQS LEN |
+-------------------------------+-------------------------------+
| RQS SRV |
+---------------------------------------------------------------+
For each domain contained in the path:
+---------------+---------------+-------------------------------+
| AD LEN | VG | ADJ AD |
+---------------+---------------+-------------------------------+
| ADJ CMP | NUM TP |
+-------------------------------+-------------------------------+
| TP |
+-------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 経路ID| | | +-------------------------------+-------------------------------+ | SRC西暦| HSTはセットしました。| +---------------+---------------+-------------------------------+ | UCI| 未使用| ヌムRQS| +---------------+---------------+-------------------------------+ | DST西暦| TGT ENT| +-------------------------------+-------------------------------+ | AD PTR| +-------------------------------経路のためのそれぞれの要求されたサービスのための+: +-------------------------------+-------------------------------+ | RQS TYP| RQSレン| +-------------------------------+-------------------------------+ | RQS SRV| +---------------------------------------------------------------各ドメインへの+は経路に保管していました: +---------------+---------------+-------------------------------+ | ADレン| VG| ADJ西暦| +---------------+---------------+-------------------------------+ | ADJ Cmp| ヌムTP| +-------------------------------+-------------------------------+ | TP| +-------------------------------+
PATH ID
(64 bits) Path identifier consisting of the numeric identifier
for the originator's domain (16 bits), the numeric identifier
for the originator policy gateway or route server (16 bits), the
path direction (2 bits), and the local path identifier (30
bits).
創始者のドメインのための数値識別子(16ビット)、創始者方針ゲートウェイかルートサーバのための数値識別子(16ビット)、経路指示(2ビット)、およびローカルの経路識別子(30ビット)のPATH ID(64ビット)経路識別子の成ること。
SRC AD (16 bits) Numeric identifier for the source domain, which may
be different from the originator domain if the originator domain
is a proxy for the source.
ソースドメインのためのSRC AD(16ビット)の数値識別子。(それは、創始者ドメインがソースへのプロキシであるなら創始者ドメインと異なっているかもしれません)。
HST SET (16 bits) Numeric identifier for the source's host set.
HST SET(16ビット)のソースのホストにとっての数値の識別子はセットしました。
UCI (8 bits) Numeric identifier for the source user class. The value
0 indicates that there is no particular source user class.
UCI(8ビット)のソースユーザ・クラスにおける数値の識別子。 値0は、どんな特定のソースユーザ・クラスもないのを示します。
Steenstrup [Page 101] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[101ページ]RFC1479IDPRは1993年7月に議定書を作ります。
UNUSED (8 bits) Not currently used; must be set equal to 0.
現在使用されていないUNUSED(8ビット)。 0と等しい状態で設定しなければなりません。
NUM RQS (16 bits) Number of requested services.
要求されたサービスのNUM RQS(16ビット)番号。
DST AD (16 bits) Numeric identifier for the destination domain, which
may be different from the target domain if the target domain is
a proxy for the destination.
目的地ドメインのためのDST AD(16ビット)の数値識別子。(それは、ターゲット・ドメインが目的地へのプロキシであるならターゲット・ドメインと異なっているかもしれません)。
TGT ENT (16 bits) Numeric identifier for the target entity. A value
of 0 indicates that there is no specific target entity.
目標実体のためのTGT ENT(16ビット)の数値識別子。 0の値は、どんな特定の目標実体もないのを示します。
AD PTR (16 bits) Byte offset from the beginning of the message
indicating the location of the beginning of the domain-specific
information, contained in the right-most 15 bits. The left-most
bit indicates whether the message includes expedited data (1
expedited data, 0 no expedited data).
AD PTR(16ビット)バイトはドメイン特殊情報の始まりの位置を示すメールの文頭から相殺されました、最も権利15ビットに含まれて。 最も左のビットは、メッセージが速められたデータを含んでいるかどうかを(1はデータを速めて、0ノー、はデータを速めました)示します。
RQS TYP (16 bits) Numeric identifier for a type of requested service
or source-specific information. Valid requested services are
described in section 5.5.2. Valid source source-specific
information includes the following types:
一種の要求されたサービスかソース特殊情報のためのRQS TYP(16ビット)の数値識別子。 有効な要求されたサービスはセクション5.5.2で説明されます。 有効なソースソース特殊情報は以下のタイプを含んでいます:
12. MD4/RSA data message authentication (see [16]).
12. MD4/RSAデータは認証を通信させます。([16])を見てください。
13. MD5/RSA data message authentication (see [17]).
13. MD5/RSAデータは認証を通信させます。([17])を見てください。
14. Billing address (variable).
14. アドレス(変数)に請求します。
15. Charge number (variable).
15. 数(可変)を請求してください。
RQS LEN (16 bits) Length of the requested service or source-specific
information, in bytes, beginning with the next field.
要求されたサービスのRQS LEN(16ビット)の長さか次の分野で始まるバイトで表現されるソース特殊情報。
RQS SRV (variable) Description of the requested service or source-
specific information.
要求されたサービスかソース特殊情報のRQS SRVの(可変)の記述。
AD LEN (8 bits) Length of the information associated with a
particular domain on the route, in bytes, beginning with the
next field.
ルートの上の次の分野でバイトで始まる特定のドメインに関連している情報のAD LEN(8ビット)の長さ。
VG (8 bits) Numeric identifier for an exit virtual gateway.
出口の仮想のゲートウェイのためのVG(8ビット)の数値識別子。
ADJ AD (16 bits) Numeric identifier for an adjacent domain.
隣接しているドメインのためのADJ AD(16ビット)の数値識別子。
ADJ CMP (16 bits) Numeric identifier for a component of the adjacent
domain. Used to aid a policy gateway in routing across a
virtual gateway connected to a partitioned domain.
隣接しているドメインのコンポーネントのためのADJ CMP(16ビット)の数値識別子。 仕切られたドメインに接続された仮想のゲートウェイの向こう側にルーティングで方針ゲートウェイを支援するのにおいて、使用されています。
Steenstrup [Page 102] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[102ページ]RFC1479IDPRは1993年7月に議定書を作ります。
NUM TP (16 bits) Number of transit policies that apply to the section
of the path traversing the given domain component.
与えられたドメインコンポーネントを横断しながら経路のセクションに適用される運送保険証券のNUM TP(16ビット)番号。
TP (16 bits) Numeric identifier for a transit policy.
運送保険証券のためのTP(16ビット)の数値識別子。
7.6.2. ACCEPT
7.6.2. 受け入れてください。
The ACCEPT message type is equal to 1.
ACCEPTメッセージタイプは1に堪えます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH ID |
| |
+---------------+-----------------------------------------------+
| RSN TYP | REASON |
+---------------+-----------------------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 経路ID| | | +---------------+-----------------------------------------------+ | RSN TYP| 理由| +---------------+-----------------------------------------------+
PATH ID
(64 bits) Path identifier contained in the original SETUP
message.
オリジナルのSETUPメッセージに含まれたPATH ID(64ビット)経路識別子。
RSN TYP (optional, 8 bits) Numeric identifier for the reason for
conditional path acceptance.
条件付きの経路承認の理由によるRSN TYP(8ビット任意の)の数値識別子。
REASON (optional, variable) Description of the reason for conditional
path acceptance. Currently, no reasons have been defined.
条件付きの経路承認の理由のREASONの(任意で、可変)の記述。 現在、理由は全く定義されていません。
7.6.3 REFUSE
7.6.3 廃物
The REFUSE message type is equal to 2.
REFUSEメッセージタイプは2に堪えます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH ID |
| |
+---------------+-----------------------------------------------+
| RSN TYP | REASON |
+---------------+-----------------------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 経路ID| | | +---------------+-----------------------------------------------+ | RSN TYP| 理由| +---------------+-----------------------------------------------+
PATH ID
(64 bits) Path identifier contained in the original SETUP
message.
オリジナルのSETUPメッセージに含まれたPATH ID(64ビット)経路識別子。
RSN TYP (8 bits) Numeric identifier for the reason for path refusal.
経路拒否の理由によるRSN TYP(8ビット)の数値識別子。
REASON (variable) Description of the reason for path refusal. Valid
経路拒否の理由のREASONの(可変)の記述。 有効
Steenstrup [Page 103] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[103ページ]RFC1479IDPRは1993年7月に議定書を作ります。
reasons include the following types:
理由は以下のタイプを含んでいます:
1. Transit policy does not apply between the virtual gateways in a
given direction. Numeric identifier for the transit policy (16
bits).
1. 運送保険証券は与えられた方向の仮想のゲートウェイの間で適用されません。 運送保険証券(16ビット)のための数値識別子。
2. Transit policy denies access to traffic from the host set between
the source and destination domains. Numeric identifier for the
transit policy (16 bits).
2. 運送保険証券は、ホストからのトラフィックへのアクセスがソースと目的地ドメインの間にセットしたことを否定します。 運送保険証券(16ビット)のための数値識別子。
3. Transit policy denies access to traffic from the source user
class. Numeric identifier for the transit policy (16 bits).
3. 運送保険証券はソースユーザ・クラスからトラフィックへのアクセスを拒絶します。 運送保険証券(16ビット)のための数値識別子。
4. Transit policy denies access to traffic at the current time.
Numeric identifier for the transit policy (16 bits).
4. 運送保険証券は現在の時間にトラフィックへのアクセスを拒絶します。 運送保険証券(16ビット)のための数値識別子。
5. Virtual gateway is down. Numeric identifier for the virtual
gateway (8 bits) and associated adjacent domain (16 bits).
5. 仮想のゲートウェイは下がっています。 仮想のゲートウェイ(8ビット)と関連隣接しているドメイン(16ビット)のための数値識別子。
6. Virtual gateway is not reachable according to the given transit
policy. Numeric identifier for the virtual gateway (8 bits),
associated adjacent domain (16 bits), and transit policy (16
bits).
6. 与えられた運送保険証券によると、仮想のゲートウェイは届いていません。 仮想のゲートウェイ(8ビット)、関連隣接しているドメイン(16ビット)、および運送保険証券(16ビット)のための数値識別子。
7. Domain component is not reachable. Numeric identifier for the
domain (16 bits) and the component (16 bits).
7. ドメインコンポーネントは届いていません。 ドメイン(16ビット)とコンポーネント(16ビット)のための数値識別子。
8. Insufficient resources to establish the path.
8. 経路を確立する不十分なリソース。
9. Target is not reachable via intra-domain routing.
9. 目標はイントラドメインルーティングで届いていません。
10. No existing path with the given path identifier, in response to
a REPAIR message only.
10. REPAIRメッセージだけに対応した与えられた経路識別子がある既存の経路がありません。
7.6.4. TEARDOWN
7.6.4. 分解
The TEARDOWN message type is equal to 3.
TEARDOWNメッセージタイプは3に堪えます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH ID |
| |
+---------------+-----------------------------------------------+
| RSN TYP | REASON |
+---------------+-----------------------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 経路ID| | | +---------------+-----------------------------------------------+ | RSN TYP| 理由| +---------------+-----------------------------------------------+
Steenstrup [Page 104] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[104ページ]RFC1479IDPRは1993年7月に議定書を作ります。
PATH ID
(64 bits) Path identifier contained in the original SETUP
message.
オリジナルのSETUPメッセージに含まれたPATH ID(64ビット)経路識別子。
RSN TYP (8 bits) Numeric identifier for the reason for path teardown.
経路分解の理由によるRSN TYP(8ビット)の数値識別子。
REASON (variable) Description of the reason for path teardown. Valid
reasons include the following types:
経路分解の理由のREASONの(可変)の記述。 正当な理由は以下のタイプを含んでいます:
1. Virtual gateway is down. Numeric identifier for the virtual
gateway (8 bits) and associated adjacent domain (16 bits).
1. 仮想のゲートウェイは下がっています。 仮想のゲートウェイ(8ビット)と関連隣接しているドメイン(16ビット)のための数値識別子。
2. Virtual gateway is not reachable according to the given transit
policy. Numeric identifier for the virtual gateway (8 bits),
associated adjacent domain (16 bits), and transit policy (16
bits).
2. 与えられた運送保険証券によると、仮想のゲートウェイは届いていません。 仮想のゲートウェイ(8ビット)、関連隣接しているドメイン(16ビット)、および運送保険証券(16ビット)のための数値識別子。
3. Domain component is not reachable. Numeric identifier for the
domain (16 bits) and the component (16 bits).
3. ドメインコンポーネントは届いていません。 ドメイン(16ビット)とコンポーネント(16ビット)のための数値識別子。
4. Maximum path lifetime exceeded.
4. 超えられていた最大の経路生涯。
5. Preempted path.
5. 経路を先取りしました。
6. Unable to repair path.
6. 経路を修理できません。
7.6.5. ERROR
7.6.5. 誤り
The ERROR message type is equal to 4.
ERRORメッセージタイプは4に堪えます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH ID |
| |
+---------------+---------------+-------------------------------+
| MSG | RSN TYP | REASON |
+---------------+---------------+-------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 経路ID| | | +---------------+---------------+-------------------------------+ | エムエスジー| RSN TYP| 理由| +---------------+---------------+-------------------------------+
PATH ID
(64 bits) Path identifier contained in the path control or data
message in error.
経路制御かデータメッセージに間違って含まれたPATH ID(64ビット)経路識別子。
MSG (8 bits) Numeric identifier for the type of path control message
in error. This field is ignored for error type 5.
MSG(8ビット)の間違い経路制御メッセージのタイプにおける数値の識別子。 この分野は誤りタイプ5のために無視されます。
RSN TYP (8 bits) Numeric identifier for the reason for the PCP
message error.
PCPメッセージ誤りの理由によるRSN TYP(8ビット)の数値識別子。
Steenstrup [Page 105] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[105ページ]RFC1479IDPRは1993年7月に議定書を作ります。
REASON (variable) Description of the reason for the PCP message
error. Valid reasons include the following types:
PCPメッセージ誤りの理由のREASONの(可変)の記述。 正当な理由は以下のタイプを含んでいます:
1. Path identifier is already currently active.
1. 経路識別子は現在、既にアクティブです。
2. Domain does not appear in the SETUP message.
2. ドメインはSETUPメッセージに現れません。
3. Transit policy is not configured for the domain. Numeric
identifer for
the transit policy (16 bits).
3. 運送保険証券はドメインに構成されません。 運送保険証券(16ビット)のための数値identifer。
4. Virtual gateway not configured for the domain. Numeric
identifier
for the virtual gateway (8 bits) and associated adjacent domain
(16
bits).
4. ドメインに構成されなかった仮想のゲートウェイ。 仮想のゲートウェイ(8ビット)と関連隣接しているドメイン(16ビット)のための数値識別子。
5. Unrecognized path identifier in an IDPR data message.
5. IDPRデータメッセージの認識されていない経路識別子。
7.6.6. REPAIR
7.6.6. 修理
The REPAIR message type is equal to 5. A REPAIR message contains the original SETUP message only.
REPAIRメッセージタイプは5に堪えます。 REPAIRメッセージはオリジナルのSETUPメッセージだけを含んでいます。
7.6.7. Negative Acknowledgements
7.6.7. 否定的承認
When a policy gateway receives an unacceptable PCP message that passes the CMTP validation checks, it includes, in its CMTP ACK, an appropriate negative acknowledgement. This information is placed in the INFORM field of the CMTP ACK (described previously in section 2.4); the numeric identifier for each type of PCP negative acknowledgement is contained in the left-most 8 bits of the INFORM field. Negative acknowledgements associated with PCP include the following types:
方針ゲートウェイがCMTP合法化チェックを通過する容認できないPCPメッセージを受け取るとき、それはCMTP ACKに適切な否定的承認を含んでいます。 この情報はCMTP ACK(以前に、セクション2.4で説明される)のINFORM分野に置かれます。 それぞれのタイプのPCPの否定的承認のための数値識別子はINFORM分野の最も左の8ビットに含まれています。 PCPに関連している否定的承認は以下のタイプを含んでいます:
1. Unrecognized PCP message type. Numeric identifier for the
unrecognized message type (8 bits).
1. 認識されていないPCPメッセージタイプ。 認識されていないメッセージタイプ(8ビット)における数値の識別子。
2. Out-of-date PCP message.
2. 時代遅れなPCPメッセージ。
3. Unrecognized path identifier (for all PCP messages except SETUP).
Numeric identifier for the unrecognized path (64 bits).
3. 認識されていない経路識別子(SETUP以外のすべてのPCPメッセージのための)。 認識されていない経路(64ビット)のための数値識別子。
8. Security Considerations
8. セキュリティ問題
Refer to sections 1.6, 1.7, and 2.3 for details on security in IDPR.
IDPRのセキュリティに関する詳細についてセクション1.6、1.7、および2.3を参照してください。
Steenstrup [Page 106] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[106ページ]RFC1479IDPRは1993年7月に議定書を作ります。
9. Author's Address
9. 作者のアドレス
Martha Steenstrup BBN Systems and Technologies 10 Moulton Street Cambridge, MA 02138
マーサステーンストルプBBN Systemsと技術10モールトン・通りケンブリッジ、MA 02138
Phone: (617) 873-3192 Email: msteenst@bbn.com
以下に電話をしてください。 (617) 873-3192 メールしてください: msteenst@bbn.com
References
参照
[1] Clark, D., "Policy Routing in Internet Protocols", RFC 1102, May
1989.
[1] クラーク(D.、「インターネットプロトコルにおける方針ルート設定」、RFC1102)は1989がそうするかもしれません。
[2] Estrin, D., "Requirements for Policy Based Routing in the
Research Internet", RFC 1125, November 1989.
[2]Estrin、D.、「研究インターネットの方針のベースのルート設定のための要件」、RFC1125、1989年11月。
[3] Little, M., "Goals and Functional Requirements for Inter-
Autonomous System Routing", RFC 1126, July 1989.
[3] 少しと、M.と、「相互自律システムルート設定のための目標と機能条件書」、RFC1126、7月1989日
[4] Breslau, L. and Estrin, D., "Design of Inter-Administrative
Domain Routing Protocols", Proceedings of the ACM SIGCOMM '90
Symposium, September 1990.
[4] ブレスラウとL.とEstrin、D.、「相互管理のドメインルーティング・プロトコルのデザイン」、ACM SIGCOMM90年のシンポジウム(1990年9月)の議事。
[5] Steenstrup, M., "An Architecture for Inter-Domain Policy Rout-
ing", RFC 1478, July 1993.
[5] ステーンストルプ、1993年7月、M.、「Inter-ドメインPolicy Rout- ingのためのArchitecture」RFC1478。
[6] Austein, R., "DNS Support for IDPR", Work in Progress, March
1993.
[6] R.、「IDPRのDNSサポート」というAusteinは進歩、1993年3月に働いています。
[7] Bowns, H. and Steenstrup, M., "Inter-Domain Policy Routing Con-
figuration and Usage", Work in Progress, July 1991.
[7]Bowns、H.、ステーンストルプ、M.、および「相互Domain Policyルート設定Conの形づけとUsage」、Progress、7月1991日のWork
[8] Woodburn, R., "Definitions of Managed Objects for Inter-Domain
Policy Routing (Version 1)", Work in Progress, March 1993.
[8] R.、「相互ドメイン方針ルート設定(バージョン1)のための管理オブジェクトの定義」というWoodburnは進歩、1993年3月に働いています。
[9] McQuillan, J., Richer, I., Rosen, E., and Bertsekas, D.,
"ARPANET Routing Algorithm Improvements: Second Semiannual
Technical Report", BBN Report No. 3940, October 1978.
[9] マッキランとJ.とリシェとI.とローゼン、E.とBertsekas、D.、「アルパネットルーティング・アルゴリズム改良:」 「第2半年ごとの技術報告書」、BBNレポートNo.3940、1978年10月。
[10] Moy, J., "The OSPF Specification", RFC 1131, October 1989.
[10]Moy、J.、「OSPF仕様」、RFC1131、1989年10月。
[11] Oran, D. (editor), "Intermediate System to Intermediate System
Routeing Exchange Protocol for Use in Conjunction with the Pro-
tocol for Providing the Connectionless-mode Network Service (ISO
8473)", ISO/IEC JTC1/SC6/WG2, October 1989.
[11] オラン、D.(エディタ)、「Providing Connectionless-モードNetwork ServiceのためのPro- tocolとConjunctionのUseのためのIntermediate System Routeing Exchangeプロトコルへの中間的System、(ISO8473)、」、ISO/IEC JTC1/SC6/WG2(1989年10月)
Steenstrup [Page 107] RFC 1479 IDPR Protocol July 1993
ステーンストルプ[107ページ]RFC1479IDPRは1993年7月に議定書を作ります。
[12] Estrin, D., and Tsudik, G., "Secure Control of Transit Internet-
work Traffic, TR-89-15, Computer Science Department, University
of Southern California.
[12] Estrin、D.、およびTsudik、G.は「Transitインターネット仕事TrafficのControl、TR-89-15、コンピュータ理学部、南カリフォルニア大学を機密保護します」。
[13] Linn, J., "Privacy Enhancement for Internet Electronic Mail:
Part I - Message Encipherment and Authentication Procedures",
RFC 1113, August 1989.
[13] リン、J.、「インターネット電子メールのためのプライバシー増進:」 「Iを分けてください--暗号文と認証手順を通信させてください」、RFC1113、1989年8月。
[14] Kent, S., and Linn, J., "Privacy Enhancement for Internet Elec-
tronic Mail: Part II - Certificate-based Key Management", RFC
1114, August 1989.
[14] ケント、S.とリン、J.、「インターネットElec- tronicメールのためのプライバシーEnhancement:」 「IIを分けてください--証明書ベースのKey Management」、RFC1114、8月1989日
[15] Linn, J., "Privacy Enhancement for Internet Electronic Mail:
Part III - Algorithms, Modes, and Identifiers", RFC 1115, August
1989.
[15] リン、J.、「インターネット電子メールのためのプライバシー増進:」 「IIIを分けてください--アルゴリズム、モード、および識別子」、RFC1115、8月1989日
[16] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, April
1992.
[16] 1992年4月、最もRivestなR.、「MD4メッセージダイジェストアルゴリズム」RFC1320。
[17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[17] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
Steenstrup [Page 108]
ステーンストルプ[108ページ]
一覧
スポンサーリンク
