RFC1621 日本語訳
1621 Pip Near-term Architecture. P. Francis. May 1994. (Format: TXT=128905 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Francis Request for Comments: 1621 NTT Category: Informational May 1994
コメントを求めるワーキンググループP.フランシスの要求をネットワークでつないでください: 1621年のNTTカテゴリ: 情報の1994年5月
Pip Near-term Architecture
種の短期間アーキテクチャ
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Preamble
序文
During 1992 and 1993, the Pip internet protocol, developed at Belclore, was one of the candidate replacments for IP. In mid 1993, Pip was merged with another candidate, the Simple Internet Protocol (SIP), creating SIPP (SIP Plus). While the major aspects of Pip-- particularly its distinction of identifier from address, and its use of the source route mechanism to achieve rich routing capabilities-- were preserved, many of the ideas in Pip were not. The purpose of this RFC and the companion RFC "Pip Header Processing" are to record the ideas (good and bad) of Pip.
1992と1993の間、Belcloreで開発されたPipインターネットプロトコルはIPの候補replacmentsの1つでした。 1993年中頃に、SIPP(SIP Plus)を作成して、Pipは別の候補、Simpleインターネットプロトコル(SIP)に合併されました。 Pipの主要な局面(特にアドレスからの識別子の区別、および豊かなルーティング能力を達成する送信元経路メカニズムのその使用)は保持されましたが、Pipの考えの多くは保持されたというわけではありません。 このRFCの目的と仲間RFC「種のヘッダー処理」はPipにおける(良く悪い)の考えを記録することです。
This document references a number of Pip draft memos that were in various stages of completion. The basic ideas of those memos are presented in this document, though many details are lost. The very interested reader can obtain those internet drafts by requesting them directly from me at <francis@cactus.ntt.jp>.
数のこのドキュメント参照Pipは様々なステージの完成中であるメモを作成します。 多くの詳細が無くなりますが、それらのメモの基本的な考え方は本書では提示されます。 まさしくその興味のある読者が直接私からの要求しているそれらによるそれらのインターネット草稿 at <francis@cactus.ntt.jp を入手できる、gt。
The remainder of this document is taken verbatim from the Pip draft memo of the same title that existed when the Pip project ended. As such, any text that indicates that Pip is an intended replacement for IP should be ignored.
このドキュメントの残りはPipプロジェクトが終わったとき存在した同じタイトルに関するPip草稿メモから逐語的に抜粋されます。 そういうものとして、PipがIPへの意図している交換品であることを示すどんなテキストも無視されるべきです。
Abstract
要約
Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to evolve to all forseeable internet protocol requirements. This specification describes the routing and addressing architecture for near-term Pip deployment. We say near-term only because Pip is designed with evolution in mind, so other architectures are expected in the future. This document, however, makes no reference to such future architectures.
種はIPバージョン4との交換として意図するインターネットプロトコルです。 種はインターネットプロトコル要件をすべてforseeableするように発展するように設計された汎用のインターネットプロトコルです。 この仕様は短期間Pip展開のためにルーティングとアドレッシング体系について説明します。 単にPipが発展で念頭に設計されているので私たちが短期間を言うので、他のアーキテクチャは将来、予想されます。 しかしながら、このドキュメントはそのような将来のアーキテクチャについて言及します。
Francis [Page 1] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[1ページ]RFC1621種
Table of Contents
目次
1. Pip Architecture Overview ................................... 4 1.1 Pip Architecture Characteristics ........................... 4 1.2 Components of the Pip Architecture ......................... 5
1. アーキテクチャ概要に種をとってください… 4 1.1 アーキテクチャの特性に種をとってください… 4 種のアーキテクチャの1.2の成分… 5
2. A Simple Example ............................................ 6
2. 簡単な例… 6
3. Pip Overview ................................................ 7
3. 概要に種をとってください… 7
4. Pip Addressing .............................................. 9 4.1 Hierarchical Pip Addressing ................................ 9 4.1.1 Assignment of (Hierarchical) Pip Addresses ............... 12 4.1.2 Host Addressing .......................................... 14 4.2 CBT Style Multicast Addresses .............................. 15 4.3 Class D Style Multicast Addresses .......................... 16 4.4 Anycast Addressing ......................................... 16
4. アドレシングに種をとってください… 9 4.1 階層的な種のアドレシング… 9 4.1 (階層的)の種のアドレスの.1課題… 12 4.1 .2 アドレシングをホスティングしてください… 14 4.2 CBTはマルチキャストアドレスを流行に合わせます… 15 4.3 クラスDはマルチキャストアドレスを流行に合わせます… 16 4.4 Anycastアドレシング… 16
5. Pip IDs ..................................................... 17
5. IDに種をとってください… 17
6. Use of DNS .................................................. 18 6.1 Information Held by DNS .................................... 19 6.2 Authoritative Queries in DNS ............................... 20
6. DNSの使用… 18 6.1 情報はDNSを固守しました… 19 6.2 DNSでの正式の質問… 20
7. Type-of-Service (TOS) (or lack thereof) ..................... 21
7. サービスのタイプ(TOS)(または、それの不足)… 21
8. Routing on (Hierarchical) Pip Addresses ..................... 22 8.1 Exiting a Private Domain ................................... 23 8.2 Intra-domain Networking .................................... 24
8. (階層的)の種のアドレスにおけるルート設定… 22 8.1 個人的なドメインを出ます… 23 8.2イントラドメインネットワーク… 24
9. Pip Header Server ........................................... 25 9.1 Forming Pip Headers ........................................ 25 9.2 Pip Header Protocol (PHP) .................................. 27 9.3 Application Interface ...................................... 27
9. ヘッダーサーバに種をとってください… 25 9.1 種のヘッダーを形成します… 25 9.2 ヘッダープロトコル(PHP)に種をとってください… 27 9.3HTTPサーバとNETSCAPE間のインタフェース… 27
10. Routing Algorithms in Pip .................................. 28 10.1 Routing Information Filtering ............................. 29
10. 種のルート設定アルゴリズム… 28 10.1経路情報フィルタリング… 29
11. Transition ................................................. 30
11.1 Justification for Pip Transition Scheme ................... 31
11.2 Architecture for Pip Transition Scheme .................... 31
11.3 Translation between Pip and IP packets .................... 33
11.4 Translating between PCMP and ICMP ......................... 34
11.5 Translating between IP and Pip Routing Information ........ 34
11.6 Old TCP and Application Binaries in Pip Hosts ............. 34
11.7 Translating between Pip Capable and non-Pip Capable DNS
Servers ................................................... 35
11. 変遷… 種の変遷体系のための30 11.1正当化… 種の変遷体系のための31 11.2アーキテクチャ… PipとIPパケットの間の31 11.3翻訳… 33 11.4 PCMPとICMPの間で翻訳します… 34 11.5 IPと種の経路情報の間で翻訳します… 34 11.6 種のホストの古いTCPとアプリケーション2種混合毒ガス… 34 11.7 種のできて非種のできるDNSサーバの間で翻訳します… 35
Francis [Page 2] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[2ページ]RFC1621種
12. Pip Address and ID Auto-configuration ...................... 37 12.1 Pip Address Prefix Administration ......................... 37 12.2 Host Autoconfiguration .................................... 38 12.2.1 Host Initial Pip ID Creation ............................ 38 12.2.2 Host Pip Address Assignment ............................. 39 12.2.3 Pip ID and Domain Name Assignment ....................... 39
12. アドレスとID自動構成に種をとってください… 37 12.1 アドレス接頭語政権に種をとってください… 37 12.2 自動構成を接待してください… 38 12.2.1 初期の種のID作成を接待してください… 38 12.2.2 種のアドレス課題を主催してください… 39 12.2.3 IDとドメイン名課題に種をとってください… 39
13. Pip Control Message Protocol (PCMP) ........................ 40
13. 規制メッセージプロトコル(PCMP)に種をとってください… 40
14. Host Mobility .............................................. 42 14.1 PCMP Mobile Host message .................................. 43 14.2 Spoofing Pip IDs .......................................... 44
14. 移動性を接待してください… 42 14.1のPCMPのモバイルHostメッセージ… 43 14.2 種が免疫不全症候群であると偽造します… 44
15. Public Data Network (PDN) Address Discovery ................ 44 15.1 Notes on Carrying PDN Addresses in NSAPs .................. 46
15. 公衆データネットワーク(PDN)は発見を扱います… PDNがNSAPsで扱う携帯に関する44 15.1の注… 46
16. Evolution with Pip ......................................... 46 16.1 Handling Directive (HD) and Routing Context (RC) Evolution. 49 16.1.1 Options Evolution ....................................... 50 References ..................................................... 51 Security Considerations ........................................ 51 Author's Address ............................................... 51
16. 種がある発展… 46 16.1 指示(HD)とルート設定文脈(RC)発展を扱います。 49 16.1.1 オプション発展… 50の参照箇所… 51 セキュリティ問題… 51作者のアドレス… 51
Francis [Page 3] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[3ページ]RFC1621種
Introduction
序論
Pip is an internet protocol intended as the replacement for IP version 4. Pip is a general purpose internet protocol, designed to handle all forseeable internet protocol requirements. This specification describes the routing and addressing architecture for near-term Pip deployment. We say near-term only because Pip is designed with evolution in mind, so other architectures are expected in the future. This document, however, makes no reference to such future architectures (except in that it discusses Pip evolution in general).
種はIPバージョン4との交換として意図するインターネットプロトコルです。 種はすべてのforseeableインターネットプロトコル要件を扱うように設計された汎用のインターネットプロトコルです。 この仕様は短期間Pip展開のためにルーティングとアドレッシング体系について説明します。 単にPipが発展で念頭に設計されているので私たちが短期間を言うので、他のアーキテクチャは将来、予想されます。 しかしながら、このドキュメントはそのような将来のアーキテクチャについて言及します(それを除いて、それは一般に、Pip発展について議論します)。
This document gives an overall picture of how Pip operates. It is provided primarily as a framework within which to understand the total set of documents that comprise Pip.
このドキュメントはPipがどう作動するかに関する全体像を与えます。 主としてPipを包括するドキュメントの全体集合を理解しているフレームワークとしてそれを提供します。
1. Pip Architecture Overview
1. 種のアーキテクチャ概要
The Pip near-term architecture is an incremental step from IP. Like IP, near-term Pip is datagram. Pip runs under TCP and UDP. DNS is used in the same fashion it is now used to distribute name to Pip Address (and ID) mappings. Routing in the near-term Pip architecture is hop-by-hop, though it is possible for a host to create a domain- level source route (for policy reasons).
Pip短期間アーキテクチャはIPからの増加のステップです。 IPのように、短期間Pipはデータグラムです。 種はTCPとUDPで実行されます。 DNSによる同じファッションで使用されて、それが現在Pip Address(そして、ID)マッピングに名前を分配するのに使用されるということです。 ホストがドメインレベル送信元経路(方針理由による)を作成するのが、可能ですが短期間Pipアーキテクチャにおけるルート設定がホップであることごとに。
Pip Addresses have more hierarchy than IP, thus improving scaling on one hand, but introducing additional addressing complexities, such as multiple addresses, on the other. Pip, however, uses hierarchical addresses to advantage by making them provider-based, and using them to make policy routing (in this case, provider selection) choices. Pip also provides mechanisms for automatically assigning provider prefixes to hosts and routers in domains. This is the main difference between the Pip near-term architecture and the IP architecture. (Note that in the remainder of this paper, unless otherwise stated, the phrase "Pip architecture" refers to the near- term Pip architecture described herein.)
種のAddressesには、IPより多くの階層構造があります、その結果、一方では比例しますが、追加アドレシングの複雑さを導入しながら、向上します、複数のアドレスなどのように、もう片方で。 しかしながら、種は、それらをプロバイダーベースにして、方針ルーティング(この場合プロバイダー選択)選択をするのにそれらを使用することによって、階層的なアドレスを利点に使用します。 また、種はドメインで自動的にプロバイダー接頭語をホストとルータに割り当てるのにメカニズムを提供します。 これはPip短期間アーキテクチャとIPアーキテクチャの主な違いです。 (別の方法で述べられない場合、この紙の残りでは、「種のアーキテクチャ」という句がここに説明された近い用語Pipアーキテクチャを示すことに注意してください。)
2. Pip Architecture Characteristics
2. 種のアーキテクチャの特性
The proposed architecture for near-term Pip has the following characteristics:
短期間Pipのための提案されたアーキテクチャには、以下の特性があります:
1. Provider-rooted hierarchical addresses.
1. プロバイダーで根づいている階層的なアドレス。
2. Automatic domain-wide address prefix assignment.
2. 自動ドメイン全体のアドレス接頭語課題。
3. Automatic host address and ID assignment.
3. 自動ホスト・アドレスとID課題。
Francis [Page 4] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[4ページ]RFC1621種
4. Exit provider selection.
4. プロバイダー選択を出てください。
5. Multiple defaults routing (default routing, but to multiple exit
points).
5. 倍数は、(しかし、複数のエキジットポイントに掘られるデフォルト)を発送しながら、デフォルトとします。
6. Equivalent of IP Class D style addressing for multicast.
6. マルチキャストのためのIP Class Dスタイルアドレシングの同等物。
7. CBT style multicast.
7. CBTはマルチキャストを流行に合わせます。
8. "Anycast" addressing (route to one of a group, usually the
nearest).
8. "Anycast"アドレシング(グループの1つ、通常最もほぼ発送します)。
9. Providers support forwarding on policy routes (but initially will
not provide the support for sources to calculate policy routes).
9. プロバイダーは方針ルート(しかし、ソースが方針ルートを計算するように、初めは、サポートを提供しない)の上で推進をサポートします。
10. Mobile hosts.
10. モバイルホスト。
11. Support for routing across large Public Data Networks (PDN).
11. ルーティングには、大きいPublic Data Networksの向こう側に(PDN)をサポートしてください。
12. Inter-operation with IP hosts (but, only within an IP-address
domain where IP addresses are unique). In particular, an IP
address can be explicitly carried in a Pip header.
12. IPホスト(しかしIP-アドレスドメインだけで中IPアドレスがユニークである)との相互操作。 特に、Pipヘッダーで明らかにIPアドレスを運ぶことができます。
13. Operation with existing transport and application binaries
(though if the application contains IP context, like FTP, it may
only work within a domain where IP addresses are unique).
13. 既存の輸送とアプリケーション2種混合毒ガス(アプリケーションがFTPのようにIP文脈を含んでいる場合にだけ、IPアドレスがユニークであるドメインの中で働くかもしれませんが)がある操作。
14. Mechanisms for evolving Pip beyond the near-term architecture.
14. 短期間アーキテクチャを超えてPipを発展するためのメカニズム。
1.2 Components of the Pip Architecture
1.2 種のアーキテクチャの成分
The Pip Architecture consists of the following five systems:
Pip Architectureは以下の5台のシステムから成ります:
1. Host (source and sink of Pip packets)
1. ホスト(Pipパケットのソースと流し台)
2. Router (forwards Pip packets)
2. ルータ(パケットをPipに送ります)
3. DNS
3. DNS
4. Pip/IP Translator
4. 種/IP翻訳者
5. Pip Header Server (formats Pip headers)
5. 種のヘッダーサーバ(Pipヘッダーをフォーマットします)
The first three systems exist in the IP architecture, and require no explanation here. The fourth system, the Pip/IP Translator, is required solely for the purpose of inter-operating with current IP systems. All Pip routers are also Pip/IP translators.
最初の3台のシステムは、IPアーキテクチャで存在していて、ここで説明を全く必要としません。 4番目のシステム(Pip/IP Translator)が唯一現在のIPシステムで共同利用する目的に必要です。また、すべてのPipルータがPip/IP翻訳者です。
Francis [Page 5] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[5ページ]RFC1621種
The fifth system, the Pip Header Server, is new. Its function is to format Pip headers on behalf of the source host (though initially hosts will be able to do this themselves). This use of the Pip Header Server will increase as policy routing becomes more sophisticated (moves beyond near-term Pip Architecture capabilities).
5番目のシステム(Pip Header Server)は新しいです。 機能は送信元ホストを代表して形式Pipヘッダーにいます(ホストが初めは、自分たちでこれができるでしょうが)。 方針ルーティングが、より洗練されるようになるのに従って(短期間Pip Architecture能力を超えて動きます)、Pip Header Serverのこの使用は増加するでしょう。
To handle future evolution, a Pip Header Server can be used to "spoon-feed" Pip headers to old hosts that have not been updated to understand new uses of Pip. This way, the probability that the internet can evolve without changing all hosts is increased.
今後の発展を扱うなら、PipヘッダーをPipの新しい用途を理解するためにアップデートされていない年取ったホストに「さじで食べさせること」にPip Header Serverを使用できます。 このように、インターネットがすべてのホストを変えるというわけではなくて発展できるという確率は増強されます。
2. A Simple Example
2. 簡単な例
A typical Pip "exchange" is as follows: An application initiates an exchange with another host as identified by a domain name. A request for one or more Pip Headers, containing the domain name of the destination host, goes to the Pip Header Server. The Pip Header Server generates a DNS request, and receive back a Pip ID, multiple Pip Addresses, and possibly other information such as a mobile host server or a PDN address. Given this information, plus information about the source host (its Pip Addresses, for instance), plus optionally policy information, plus optionally topology information, the Pip Header Server formats an ordered list of valid Pip headers and give these to the host. (Note that if the Pip Header Server is co-resident with the host, as will be common initially, the host behavior is similar to that of an IP host in that a DNS request comes from the host, and the host forms a Pip header based on the answer from DNS.)
典型的なPip「交換」は以下の通りです: アプリケーションは別のホストと共にドメイン名によって特定されるように交換を起こします。 あて先ホストのドメイン名を含んでいて、1Pip Headersを求める要求はPip Header Serverに行きます。Pip Header ServerはDNS要求を生成します、そして、モバイルホストサーバかPDNアドレスの後部Pip ID、複数のPip Addresses、およびことによると他の情報を受け取ってください。 そのうえ、任意にこの情報、および送信元ホスト(例えば、Pip Addresses)の情報を教える、方針情報、任意に、トポロジー情報、Pip Header Serverは有効なPipヘッダーの規則正しいリストをフォーマットして、これらをホストに与えます。 (Pip Header Serverがホストと一緒にいるコレジデントであるならそれに注意してください、初めは、一般的であり、ホストの振舞いがDNS要求がホストから来るという点においてIPホストのものと同様であり、ホストがDNSから答えに基づくPipヘッダーを形成するとき。)
The source host then begins to transmit Pip packets to the destination host. If the destination host is an IP host, then the Pip packet is translated into an IP packet along the way. Assuming that the destination host is a Pip host, however, the destination host uses the destination Pip ID alone to determine if the packet is destined for it. The destination host generates a return Pip header based either on information in the received Pip header, or the destination host uses the Pip ID of the source host to query the Pip Header Server/DNS itself. The latter case involves more overhead, but allows a more informed decision about how to return packets to the originating host.
そして、送信元ホストはPipパケットをあて先ホストに伝え始めます。 あて先ホストがIPホストであるなら、Pipパケットは道に沿ってIPパケットに翻訳されます。 しかしながら、あて先ホストがPipホストであると仮定して、あて先ホストはパケットがそれのために運命づけられているかどうか決定するために単独の目的地Pip IDを使用します。 あて先ホストが容認されたPipヘッダーで情報で基づくリターンPipヘッダーを生成するか、またはあて先ホストは、Pip Header Server/DNS自身について質問するのに送信元ホストのPip IDを使用します。 後者のケースは、どうパケットを送信元ホストに返すかに関して、より多くのオーバーヘッドを伴いますが、より知識がある決定を許します。
If either host is mobile, and moves to a new location, thus getting a new Pip Address, it informs the other host of its new address directly. Since host identification is based on the Pip ID and not the Pip Address, this doesn't cause transport level to fail. If both hosts are mobile and receive new Pip Addresses at the same time (and thus cannot exchange packets at all), then they can query each other's respective mobile host servers (learned from DNS). Note that
どちらのホストもモバイルであり、新しい位置に移行して、その結果、新しいPip Addressを手に入れる場合、それは新しいアドレスについて直接もう片方のホストに知らせます。 ホスト識別がPip Addressではなく、Pip IDに基づいているので、これは輸送レベルに失敗されません。 両方のホストが同時に(そして、その結果、全くパケットを交換できない)モバイルであり、新しいPip Addressesを受け取るなら、それらは互いのそれぞれのモバイルホストサーバ(DNSから、学習される)について質問できます。 それに注意してください。
Francis [Page 6] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[6ページ]RFC1621種
keeping track of host mobility is completely confined to hosts. Routers never get involved in tracking mobile hosts (though naturally they are involved in host discovery and automatic host address assignment).
ホストの移動性の動向をおさえるのはホストに完全に閉じ込められます。 ルータは追跡モバイルホストに決してかかわりません(彼らが当然ホスト発見と自動ホスト・アドレス課題にかかわりますが)。
3. Pip Overview
3. 種の概要
Here, a brief overview of the Pip protocol is given. The reader is encouraged to read [2] for a complete description.
ここに、Pipプロトコルの簡潔な概要を与えます。 読者が完全な記述のための[2]を読むよう奨励されます。
The Pip header is divided into three parts:
Pipヘッダーは3つの部品に分割されます:
Initial Part
Transit Part
Options Part
初期の部分のトランジット部分のオプション一部
The Initial Part contains the following fields:
Initial Partは以下の分野を含んでいます:
Version Number
Options Offset, OP Contents, Options Present (OP)
Packet SubID
Protocol
Dest ID
Source ID
Payload Length
Host Version
Payload Offset
Hop Count
バージョン数のオプションは相殺されます、オプアートコンテンツ、オプションプレゼント(オプアート)パケットSubIDプロトコルDest IDソースIDペイロード長ホストバージョン有効搭載量オフセットホップカウント
All of the fields in the Initial Part are of fixed length. The Initial Part is 8 32-bit words in length.
Initial Partの分野のすべてが固定長のものです。 Initial Partは長さが8つの32ビットの単語です。
The Version Number places Pip as a subsequent version of IP. The Options Offset, OP Contents, and Options Present (OP) fields tell how to process the options. The Options Offset tells where the options are The OP tells which of up to 8 options are in the options part, so that the Pip system can efficiently ignore options that don't pertain to it. The OP Contents is like a version number for the OP field. It allows for different sets of the (up to 8) options.
バージョンNumberはIPのその後のバージョンとしてPipを置きます。 Options Offset、OP Contents、およびOptions Present(OP)分野はオプションを処理する方法を教えます。 Options Offsetは、オプションがOPは、最大8つのオプションのどれがオプション一部にあるかを言います、Pipシステムが効率的にそれに関係しないオプションを無視できるようにどこのことであるかを言います。 OP ContentsはOP分野のバージョン番号に似ています。 それは(最大8)オプションの異なったセットを考慮します。
The Packet SubID is used to relate a received PCMP message to a previously sent Pip packet. This is necessary because, since routers in Pip can tag packets, the packet returned to a host in a PCMP message may not be the same as the packet sent. The Payload Length and Protocol take the place of IP's Total Length and Protocol fields respectively. The Dest ID identifies the destination host, and is not used for routing, except for where the final router on a LAN uses ARP to find the physical address of the host identified by the dest
Packet SubIDは、以前に送られたPipパケットに受信されたPCMPメッセージに関連するのに使用されます。 Pipのルータがパケットにタグ付けをすることができるのでPCMPメッセージのホストに返されたパケットがパケットが発信したのと同じでないかもしれないので、これが必要です。 有効搭載量LengthとプロトコルはそれぞれIPのTotal Lengthとプロトコル分野の代理をします。 Dest IDは、あて先ホストを特定して、ルーティングに使用されません、LANの最終的なルータがdestによって特定されたホストの物理アドレスを見つけるのにARPを使用するところを除いて
Francis [Page 7] RFC 1621 Pip Near-term Architecture May 1994
構造1994年5月の用語のフランシス[7ページ]RFC1621種
ID. The Source ID identifies the source of the packet. The Host Version tells what control algorithms the host has implemented, so that routers can respond to hosts appropriately. This is an evolution mechanism. The Hop Count is similar to IP's Time-to-Live.
アイダホ州 Source IDはパケットの源を特定します。 Hostバージョンは、ルータが適切にホストに応じることができるように、ホストがどんなコントロールアルゴリズムを実行したかを言います。 これは発展メカニズムです。 Hop Countは生きるIPのTimeと同様です。
The Transit Part contains the following fields:
Transit Partは以下の分野を含んでいます:
Transit Part Offset
HD Contents
Handling Directive (HD)
Active FTIF
RC Contents
Routing Context (RC)
FTIF Chain (FTIF = Forwarding Table Index Field)
トランジット部分はHDコンテンツ取り扱い指示(HD)のアクティブなFTIF RCコンテンツルート設定文脈(RC)FTIFチェーンを相殺しました。(推進テーブルFTIF=インデックス部)
Except for the FTIF Chain, which can have a variable number of 16-bit FTIF fields, the fields in the Transit Part are of fixed length, and are three 32-bit words in length.
Transit Partの分野は、固定長があって、FTIF Chain以外の長さが3つの32ビットの単語です。FTIF Chainは可変数の16ビットのFTIF分野を持つことができます。
The Transit Part Offset gives the length of the Transit Part. This is used to determine the location of the subsequent Transit Part (in the case of Transit Part encapsulation).
Transit Part OffsetはTransit Partの長さを与えます。 これは、その後のTransit Part(Transit Partカプセル化の場合における)の位置を決定するのに使用されます。
The Handling Directive (HD) is a set of subfields, each of which indicates a specific handling action that must be executed on the packet. Handling directives have no influence on routing. The HD Contents field indicates what subfields are in the Handling Directive. This allows the definition of the set of handling directives to evolve over time. Example handling directives are queueing priority, congestion experienced bit, drop priority, and so on.
Handling Directive(HD)は1セットの部分体です。それのそれぞれがパケットの上で実行しなければならない特定の取り扱い動作を示します。 取り扱い指示は影響を全くルーティングに与えません。 HD Contents分野は、どんな部分体がHandling Directiveにあるかを示します。 これで、取り扱い指示のセットの定義は時間がたつにつれて、発展します。 例の取り扱い指示が待ち行列優先権である、混雑はビット、低下優先権などになりました。
The remaining fields comprise the Routing Directive. This is where the routing decision gets made. The basic algorithm is that the router uses the Routing Context to choose one of multiple forwarding tables. The Active FTIF indicates which of the FTIFs to retrieve, which is then used as an index into the forwarding table, which either instructs the router to look at the next FTIF, or returns the forwarding information.
残っているフィールドはルート設定Directiveを包括します。 これはルーティング決定が新調するところです。 基本的なアルゴリズムはルータが複数の推進テーブルの1つを選ぶのにルート設定Contextを使用するということです。 Active FTIFは、FTIFsのどれを検索したらよいかを示します(次に、インデックスとして次のFTIFを見るようルータに命令するか、または推進情報を返す推進テーブルに使用されます)。
Examples of Routing Context uses are; to distinguish address families (multicast vs. unicast), to indicate which level of the hierarchy a packet is being routed at, and to indicate a Type of Service. In the near-term architecture, the FTIF Chain is used to carry source and destination hierarchical unicast addresses, policy route fragments, multicast addresses (all-of-group), and anycast (one-of-group) addresses. Like the OP Contents and HD Contents fields, the RC Contents field indicates what subfields are in the Routing Context.
Contextが使用するルート設定に関する例はそうです。 アドレス家族(マルチキャスト対ユニキャスト)を区別して、パケットが階層構造のどのレベルに発送されているかを示して、ServiceのTypeを示すために。 短期間構造に、FTIF Chainはソースと送付先の階層的なユニキャストアドレスを運ぶのに使用されます、方針ルート断片、マルチキャストアドレス、(オール、グループ、)、そして、anycast(グループの1つ)アドレス。 OP ContentsとHD Contents分野のように、RC Contents分野は、ルート設定Contextにはどんな部分体があるかを示します。
Francis [Page 8] RFC 1621 Pip Near-term Architecture May 1994
構造1994年5月の用語のフランシス[8ページ]RFC1621種
This allows the definition of the Routing Context to evolve over time.
これで、ルート設定Contextの定義は時間がたつにつれて、発展します。
The Options Part contains the options. The options are preceded by an array of 8 fields that gives the offset of each of up to 8 options. Thus, a particular option can be found without a serial search of the list of options.
Options Partはオプションを含んでいます。 それぞれの最大8つのオプションのオフセットを与える8つの分野の勢ぞろいはオプションに先行します。 したがって、オプションのリストの連続の検索なしで特定のオプションを見つけることができます。
4. Pip Addressing
4. 種のアドレシング
Addressing is the core of any internet architecture. Pip Addresses are carried in the Routing Directive (RD) of the Pip header (except for the Pip ID, which in certain circumstances functions as part of the Pip Address). Pip Addresses are used only for routing packets. They do not identify the source and destination of a Pip packet. The Pip ID does this. Here we describe and justify the Pip Addressing types.
アドレシングはどんなインターネット構造のコアです。 種のAddressesはPipヘッダー(Pip Addressの一部としてある特定の状況では機能するPip IDを除いた)のルート設定Directive(RD)で運ばれます。 種のAddressesはルーティングパケットにだけ使用されます。 彼らはPipパケットのソースと目的地を特定しません。 Pip IDはこれをします。 ここで、私たちは、Pip Addressingタイプを説明して、正当化します。
There are four Pip Address types [11]. The hierarchical Pip Address (referred to simply as the Pip Address) is used for scalable unicast and for the unicast part of a CBT-style multicast and anycast. The multicast part of a CBT-style multicast is the second Pip address type. The third Pip address type is class-D style multicast. The fourth type of Pip address is the so-called "anycast" address. This address causes the packet to be forwarded to one of a class of destinations (such as, to the nearest DNS server).
4つのPip Addressタイプ[11]があります。 階層的なPip Address(単にPip Addressに言及される)はスケーラブルなユニキャストとCBT-スタイルマルチキャストとanycastのユニキャスト部分に使用されます。 CBT-スタイルマルチキャストのマルチキャスト部分は2番目のPipアドレスタイプです。 3番目のPipアドレスタイプはクラスDスタイルマルチキャストです。 4番目のタイプのPipアドレスはいわゆる"anycast"アドレスです。 このアドレスで、目的地(最も近いDNSサーバにそのような)のクラスの1つにパケットを送ります。
Bits 0 and 1 of the RC defined by RC Contents value of 1 (that is, for the near-term Pip architecture) indicate which of four address families the FTIFs and Dest ID apply to. The values are:
1(すなわち、短期間Pip構造のための)のRC Contents値によって定義されたRCのビット0と1は、FTIFsとDest IDが、4アドレス家族のどれがそうするのに申し込むかを示します。 値は以下の通りです。
Value Address Family
----- --------------
00 Hierarchical Unicast Pip Address
01 Class D Style Multicast Address
10 CBT Style Multicast Address
11 Anycast Pip Address
値のアドレス家族----- -------------- 00 階層的なユニキャスト種のアドレス01クラスD様式マルチキャストアドレス10CBT様式マルチキャストアドレス11Anycast種のアドレス
The remaining bits are defined differently for different address families, and are defined in the following sections.
残っているビットは、異なったアドレス家族のために異なって定義されて、以下のセクションで定義されます。
4.1 Hierarchical Pip Addressing
4.1 階層的な種のアドレシング
The primary purpose of a hierarchical address is to allow better scaling of routing information, though Pip also uses the "path" information latent in hierarchical addresses for making provider selection (policy routing) decisions.
階層的なアドレスの第一の目的はルーティング情報の、より良いスケーリングを許すことです、また、Pipがプロバイダー選択(方針ルーティング)を決定にするのに階層的なアドレスに潜在している「経路」情報を使用しますが。
Francis [Page 9] RFC 1621 Pip Near-term Architecture May 1994
構造1994年5月の用語のフランシス[9ページ]RFC1621種
The Pip Header encodes addresses as a series of separate numbers, one number for each level of hierarchy. This can be contrasted to traditional packet encodings of addresses, which places the entire address into one field. Because of Pip's encoding, it is not necessary to specify a format for a Pip Address as it is with traditional addresses (for instance, the SIP address is formatted such that the first so-many bits are the country/metro code, the next so-many bits are the site/subscriber, and so on). Pip's encoding also eliminates the "cornering in" effect of running out of space in one part of the hierarchy even though there is plenty of room in another. No "field sizing" decisions need be made at all with Pip Addresses. This makes address assignment easier and more flexible than with traditional addresses.
Pip Headerは一連の別々の数、それぞれのレベルの階層構造の1つの数としてアドレスをコード化します。 アドレスの伝統的なパケットencodingsに対してこれを対照できます。(encodingsは全体のアドレスを1つの分野に置きます)。 Pipのコード化のために、それが伝統的なアドレスと共にあるとき(次のしたがって、多くのビットが、例えば、SIPアドレスがフォーマットされるので、したがって、多くの最初のビットが国/地下鉄コードであり、サイト/加入者などです)、Pip Addressに形式を指定するのは必要ではありません。 また、種のコード化は多くの余地が別のものにありますが、階層構造の一部のスペースを使い果たすという効果が「追い詰めます」であることを排除します。 Pip Addressesと共に「分野サイズ処理」決定を全くする必要はありません。 これはアドレスを伝統的なアドレスよりさらに簡単でフレキシブルな課題にします。
Pip Addresses are carried in DNS as a series of numbers, usually with each number representing a layer of the hierarchy [1], but optionally with the initial number(s) representing a "route fragment" (the tail end of a policy route--a source route whose elements are providers). The route fragments would be used, for instance, when the destination network's directly attached (local access) provider is only giving access to other (long distance) providers, but the important provider-selection policy decision has to do the long distance providers.
初期の数が「ルート断片」(方針ルートの末端--要素がプロバイダーである送信元経路)を表していて、種のAddressesは一連の数、通常それぞれの数の表すときの階層構造[1]の層としてのDNS、しかし、任意に運ばれます。 送信先ネットワークの直接付属している(地方のアクセス)プロバイダーが他の(長距離)プロバイダーへのアクセスを与えているだけであるとき、例えば、ルート断片は使用されるでしょうが、重要なプロバイダー選択政策決定は長距離のプロバイダーをしなければなりません。
The RC for (hierarchical) Pip Addresses is defined as:
(階層的)の種のAddressesのためのRCは以下と定義されます。
bits meaning
---- -------
0,1 Pip Address (= 00)
2,3 level
4,5 metalevel
6 exit routing type
ビット意味---- ------- 0、1Pip Address(= 00)の2、3レベル4、5 メタレベル6出口ルーティングタイプ
The level and metalevel subfields are used to indicate what level of the hierarchy the packet is currently at (see section 8). The exit routing type subfield is used to indicate whether host-driven (hosts decide exit provider) or router-driven (routers decide exit provider) exit routing is in effect (see section 8.1).
レベルとメタレベル部分体は、現在、パケットが階層構造のどんなレベルにあるかを示すのに使用されます(セクション8を見てください)。 出口ルーティングタイプ部分体は、ホストによる駆動(ホストは出口プロバイダーについて決める)の、または、ルータ駆動(ルータは出口プロバイダーについて決める)の出口ルーティングが有効であるかどうかを(セクション8.1を見てください)示すのに使用されます。
Each FTIF in the FTIF Chain is 16 bits in length. The low-order part of each FTIF in a (hierarchical unicast) Pip Address indicates the relationship of the FTIF with the next FTIF. The three relators are Vertical, Horizontal, and Extension. The Vertical and Horizontal relators indicate if the subsequent FTIF is hierarchically above or below (Vertical) or hierarchically unrelated (Horizontal). The Extension relator is used to encode FTIF values longer than 16 bits.
FTIF Chainの各FTIFは長さが16ビットです。 (階層的なユニキャスト)種のAddressのそれぞれのFTIFの下位の一部が次のFTIFと共にFTIFの関係を示します。 3人の語り手が、Verticalと、Horizontalと、Extensionです。 VerticalとHorizontal語り手はその後のFTIFが上に階層的にあるか、(垂直)の下か階層的で関係ない(水平面)を示します。 Extension語り手は、16ビットより長い間FTIF値をコード化するのに使用されます。
Francis [Page 10] RFC 1621 Pip Near-term Architecture May 1994
構造1994年5月の用語のフランシス[10ページ]RFC1621種
FTIF values 0 - 31 are reserved for special purposes. That is, they cannot be assigned to normal hierarchical elements. FTIF value 1 is defined as a flag to indicate a switch from the unicast phase of packet forwarding to the anycast phase of packet forwarding.
FTIF値0--31は特別な目的のために予約されます。 標準の階層的な要素にすなわち、それらを割り当てることができません。 FTIF値1は、パケット推進のユニキャストフェーズからパケット推進のanycastフェーズまでスイッチを示すために旗と定義されます。
Note that Pip Addresses do not need to be seen by protocol layers above Pip (though layers above Pip can provide a Pip Address if desired). Transport and above use the Pip ID to identify the source and destination of a Pip packet. The Pip layer is able to map the Pip IDs (and other information received from the layer above, such as QOS) into Pip Addresses.
Pipの上のプロトコル層によってPip Addressesが見られる必要はないことに注意してください(望まれているなら、Pipの上の層はPip Addressを提供できますが)。 輸送と上は、Pipパケットのソースと目的地を特定するのにPip IDを使用します。 Pip層はPip ID(他の情報はQOSなどのような上の層から受信された)をPip Addressesに写像できます。
The Pip ID can serve as the lowest level of a Pip Address. While this "bends the principal" of separating Pip Addressing from Pip Identification, it greatly simplifies dynamic host address assignment. The Pip ID also serves as a multicast ID. Unless otherwise stated, the term "Pip Address" refers to just the part in the Routing Directive (that is, excludes the Pip ID).
Pip IDはPip Addressの最も低いレベルとして機能できます。 これはPip IdentificationとPip Addressingを切り離すのについて「校長を曲げます」が、それはダイナミックなホスト・アドレス課題を大いに簡素化します。 また、Pip IDはマルチキャストIDとして機能します。 別の方法で述べられない場合、「種のアドレス」という用語はまさしくルート設定Directive(すなわち、Pip IDを除く)の部分について言及します。
Pip Addresses are provider-rooted (as opposed to geographical). That is, the top-level of a Pip Address indicates a network service provider (even when the service provided is not Pip). (A justification of using provider-rooted rather than geographical addresses is given in [12].)
種のAddressesはプロバイダーで根づいています(地理的と対照的に)。 すなわち、Pip Addressのトップレベルはネットワークサービスプロバイダーを示します(サービスがいつ提供さえされたかは、Pipではありません)。 ([12]で地理的であるというよりむしろプロバイダーで根づいているアドレスを使用する正当化を与えます。)
Thus, the basic form of a Pip address is:
したがって、Pipアドレスの基本的なフォームは以下の通りです。
providerPart,subscriberPart
providerPart、subscriberPart
where both the providerPart and subscriberPart can have multiple layers of hierarchy internally.
providerPartとsubscriberPartの両方が内部的に複数の層の階層構造を持つことができるところ。
A subscriber may be attached to multiple providers. In this case, a host can end up with multiple Pip Addresses by virtue of having multiple providerParts:
加入者は複数のプロバイダーに付けられるかもしれません。 この場合、複数のproviderPartsを持っていることによってホストは複数のPip Addressesで終わることができます:
providerPart1,subscriberPart
providerPart2,subscriberPart
providerPart3,subscriberPart
providerPart1、subscriberPart providerPart2、subscriberPart providerPart3、subscriberPart
This applies to the case where the subscriber network spans many different provider areas, for instance, a global corporate network. In this case, some hosts in the global corporate network will have certain providerParts, and other hosts will have others. The subscriberPart should be assigned such that routing can successfully take place without a providerPart in the destination Pip Address of the Pip Routing Directive (see section 8.2).
これは加入者ネットワークが多くの異なったプロバイダー領域、例えばグローバルな企業ネットワークにかかるケースに適用されます。 この場合、グローバルな企業ネットワークの何人かのホストが、あるproviderPartsを持つでしょう、そして、他のホストには、他のものがいるでしょう。 subscriberPartは、ルーティングがPipルート設定Directiveの目的地Pip AddressでproviderPartなしで首尾よく行われることができる(セクション8.2を見る)ように、割り当てられるべきです。
Francis [Page 11] RFC 1621 Pip Near-term Architecture May 1994
構造1994年5月の用語のフランシス[11ページ]RFC1621種
Note that, while there are three providerParts shown, there is only one subscriberPart. Internal subscriber numbering should be independent of the providerPart. Indeed, with the Pip architecture, it is possible to address internal packets without including any of the providerPart of the address.
見せられた3providerPartsがありますが、1subscriberPartしかないことに注意してください。 内部の加入者付番はproviderPartから独立しているべきです。 本当に、Pip構造では、アドレスのproviderPartのいずれも含んでいなくて内部のパケットを記述するのは可能です。
Top-level Pip numbers can be assigned to subscriber networks as well as to providers.
プロバイダーに関してトップレベルPip番号をまた、加入者ネットワークに配属できます。
privatePart,subscriberPart
privatePart、subscriberPart
In this case, however, the top-level number (privatePart) would not be advertised globally. The purpose of such an assignment is to give a private network "ownership" of a globally unique Pip Address space. Note that the privatePart is assigned as an extended FTIF (that is, from numbers greater than 2^15). Because the privatePart is not advertised globally, and because internal packets do not need the prefix (above the subscriberPart), the privatePart actually never appears in a Pip packet header.
しかしながら、この場合、最高レベル番号(privatePart)はグローバルに広告を出さないでしょう。 そのような課題の目的はグローバルにユニークなPip Addressスペースの個人的なネットワーク「所有権」を与えることです。 privatePartが拡張FTIF(すなわち、2^15より大きい数からの)として割り当てられることに注意してください。 内部のパケットが接頭語(subscriberPartの上の)を必要としないのでprivatePartがグローバルに広告に掲載されていないので、privatePartは実際にPipパケットのヘッダーに決して現れません。
Pip Addresses can be prepended with a route fragment. That is, one or more Pip numbers that are all at the top of the hierarchy.
ルート断片で種のAddressesをprependedされることができます。 すなわち、階層構造の最上部にある1つ以上のPip番号。
longDistanceProvider.localAccessProvider.subscriber
(top-level) (top-level) (next level)
longDistanceProvider.localAccessProvider.subscriber(トップレベル)(トップレベル)(次のレベル)
This is useful, for instance, when the subscriber's directly attached provider is a "local access" provider, and is not advertised globally. In this case, the "long distance" provider is prepended to the address even though the local access provider number is enough to provide global uniqueness.
例えば、加入者の直接付属しているプロバイダーが「地方のアクセス」プロバイダーであり、グローバルに広告に掲載されていないとき、これは役に立ちます。 この場合、地方のアクセスプロバイダ番号はグローバルなユニークさを提供するために十分ですが、「長距離」プロバイダーはアドレスにprependedされます。
Note that no coordination is required between the long distance and local access providers to form this address. The subscriber with a prefix assigned to it by the local access provider can autonomously form and use this address. It is only necessary that the long distance provider know how to route to the local access provider.
コーディネートは全くこのアドレスを形成するのに長距離とローカルのアクセスプロバイダーの間で必要でないことに注意してください。 接頭語が地方のアクセスプロバイダによってそれに割り当てられている加入者は、自主的にこのアドレスを形成して、使用できます。 長距離のプロバイダーがアクセスプロバイダを地方に発送する方法を知るのが必要であるだけです。
4.1.1 Assignment of (Hierarchical) Pip Addresses
4.1.1 (階層的)の種のアドレスの課題
Administratively, Pip Addresses are assigned as follows [3]. There is a root Pip Address assignment authority. Likely choices for this are IANA or ISOC. The root authority assigns top-level Pip Address numbers. (A "Pip Address number" is the number at a single level of the Pip Address hierarchy. A Pip Address prefix is a series of contiguous Pip Address numbers, starting at the top level but not including the entire Pip Address. Thus, the top-level prefix is the same thing as the top-level number.)
行政上、以下の通りの[3]はPip Addressesに割り当てられます。 根のPip Address課題権威があります。 これのためのありそうな選択は、IANAかISOCです。 根の権威はトップレベルPip Address番号を割り当てます。 (「種のAddress番号」はPip Address階層構造のただ一つのレベルにおいて数です。 Pip Address接頭語は一連の隣接のPip Address番号です、トップレベルで始まりますが、全体のPip Addressを含んでいなくて。 したがって、トップレベル接頭語は最高レベル番号と同じものです。)
Francis [Page 12] RFC 1621 Pip Near-term Architecture May 1994
構造1994年5月の用語のフランシス[12ページ]RFC1621種
Though by-and-large, and most importantly, top-level assignments are made to providers, each country is given an assignment, each existing address space (such as E.164, X.121, IP, etc.) is given an assignment, and private networks can be given assignments. Thus, existing addresses can be grandfathered in. Even if the top-level Pip address number is an administrative rather than topological assignment, the routing algorithm still advertises providers at the top (provider) level of routing. That is, routing will advertise enough levels of hierarchy that providers know how to route to each other.
概して、最も重要にトップレベル課題をプロバイダーにしますが、課題を各国に与えます、そして、それぞれの既存のアドレス空間(E.164、X.121、IPなどの)に課題を与えます、そして、私設のネットワークに課題を与えることができます。 その結果、アドレスを除外できる存在。 トップレベルPipアドレス番号が位相的であるというよりむしろ管理の課題であっても、ルーティング・アルゴリズムはトップ(プロバイダー)レベルのルーティングでまだプロバイダーの広告を出しています。 すなわち、ルーティングはプロバイダーが、どのようにが互いに発送するかを知っている十分なレベルの階層構造の広告を出すでしょう。
There must be some means of validating top-level number requests from providers (basically, those numbers less than 2^15). That is, top- level assignments must be made only to true providers. While designing the best way to do this is outside the scope of this document, it seems off hand that a reasonable approach is to charge for the top-level prefixes. The charge should be enough to discourage non-serious requests for prefixes, but not so much that it becomes an inhibitor to entry in the market. The charge might include a yearly "rent", and top-level prefixes could be reclaimed when they are no longer used by the provider. Any profit made from this activity could be used to support the overall role of number assignment. Since roughly 32,000 top-level assignments can be made before having to increase the FTIF size in the Pip header from 16 bits to 32 bits, it is envisioned that top-level prefixes will not be viewed as a scarce resource.
プロバイダー(基本的に2^15より少ないそれらの数)からの最高レベル番号要求を有効にするいくつかの手段があるに違いありません。 すなわち、トップレベルの課題を本当のプロバイダーだけにしなければなりません。 このドキュメントの範囲の外にこれをする最も良い方法を設計するのがありますが、手では、合理的なアプローチがトップレベル接頭語に課金することであるように思えます。 料金は、とても多くではなく、接頭語を求める抑制剤になるという非重大な要求に市場でのエントリーに水をさしているために十分であるべきです。 料金は年一度の「使用料」を含むかもしれません、そして、それらがもうプロバイダーによって使用されないとき、トップレベル接頭語は取り戻すことができました。 数の課題の総合的な役割を支持するのにこの活動から上げられるどんな利益も使用できました。 PipヘッダーでFTIFサイズを16ビットから32ビットまで増加させなければならない前におよそ3万2000のトップレベル課題をすることができるので、そんなにトップレベルで思い描かれて、接頭語が不十分なリソースとして見なされないということです。
After a provider obtains a top-level prefix, it becomes an assignment authority with respect to that particular prefix. The provider has complete control over assignments at the next level down (the level below the top-level). The provider may either assign top-level minus one prefixes to subscribers, or preferably use that level to provide hierarchy within the provider's network (for instance, in the case where the provider has so many subscribers that keeping routing information on all of them creates a scaling problem). It is envisioned that the subscriber will have complete control over number assignments made at levels below that of the prefix assigned it by the provider.
プロバイダーがトップレベル接頭語を得た後に、それはその特定の接頭語に関して課題権威になります。 プロバイダーで、次のレベルにおける課題の完全なコントロールは下がるように(トップレベルの下におけるレベル)なります。 望ましくは、プロバイダーは、加入者への1つの接頭語を引いてトップレベルを割り当てるか、またはプロバイダーのネットワークの中で階層構造を提供するのにそのレベルを使用するかもしれません(例えば彼らのすべての情報を発送し続けるとプロバイダーにはとても多くの加入者がいるのでスケーリング問題が生じる場合で)。 それは思い描かれます。加入者が接頭語のものの下でレベルで数の課題の完全なコントロールを作らせるのはプロバイダーでそれを割り当てました。
Assigning top level prefixes directly to providers leaves the number of top-level assignments open-ended, resulting in the possibility of scaling problems at the top level. While it is expected that the number of providers will remain relatively small (say less than 10000 globally), this can't be guaranteed. If there are more providers than top-level routing can handle, it is likely that many of these providers will be "local access" providers--providers whose role is to give a subscriber access to multiple "long-distance" providers. In this case, the local access providers need not appear at the top
最高平らな接頭語を直接プロバイダーに割り当てると、トップレベル課題の数は制限のない状態でおかれます、トップレベルで問題をスケーリングする可能性をもたらして。 プロバイダーの数が比較的小さいままで残る(10000未満をグローバルに言う)と予想されている間、これを保証できません。 トップレベルルーティングが扱うことができるより多くのプロバイダーがあれば、これらのプロバイダーの多くがなる「地方のアクセス」プロバイダーはありそうです--複数の「長距離」のプロバイダーへの加入者アクセスを与える役割がことであるプロバイダー。 この場合、ローカルのアクセスプロバイダーは先端に現れる必要はありません。
Francis [Page 13] RFC 1621 Pip Near-term Architecture May 1994
構造1994年5月の用語のフランシス[13ページ]RFC1621種
level of routing, thus mitigating the scaling problem at that level.
掘って、その結果、そのレベルでスケーリング問題を緩和するレベル。
In the worst case, if there are too many top-level "long-distance" providers for top-level routing to handle, a layer of hierarchy above the top-level can be created. This layer should probably conform to some policy criteria (as opposed to a geographical criteria). For instance, backbones with similar access restrictions or type-of- service can be hierarchically clustered. Clustering according to policy criteria rather than geographical allows the choice of address to remain an effective policy routing mechanism. Of course, adding a layer of hierarchy to the top requires that all systems, over time, obtain a new providerPart prefix. Since Pip has automatic prefix assignment, and since DNS hides addresses from users, this is not a debilitating problem.
最悪の場合には、トップレベルルーティングが扱うあまりに多くのトップレベルの「長距離」のプロバイダーがあれば、トップレベルを超えた階層構造の層を作成できます。 この層はたぶんいくつかの方針評価基準(地理的な評価基準と対照的に)に一致しているはずです。 例えば、同様であるのがある背骨は、制限にアクセスするか、またはタイプします。-サービス缶には、群生して、階層的にいてください。 地理的であるよりむしろ方針評価基準に従って群生するのに、アドレスの選択は有効な政策ルーティングメカニズムのままで残っています。 もちろん、階層構造の層を先端に加えるのはすべてのシステムが時間がたつにつれて新しいproviderPart接頭語を得るのを必要とします。 Pipには自動接頭語課題があって、DNSがユーザからアドレスを隠すので、これは弱らせる問題ではありません。
4.1.2 Host Addressing
4.1.2 ホストアドレシング
Hosts can have multiple Pip Addresses. Since Pip Addresses are topologically significant, a host has multiple Pip Addresses because it exists in multiple places topologically. For instance, a host can have multiple Pip addresses because it can be reached via multiple providers, or because it has multiple physical interfaces. The address used to reach the host influences the path to the host.
ホストは複数のPip Addressesを持つことができます。 Pip Addressesが位相的にそうときに、複数の場所に位相的に存在しているので、重要であることで、ホストは複数のPip Addressesを持っています。 例えば、複数のプロバイダーで達することができるか、またはそれには複数の物理インターフェースがあるので、ホストは複数のPipアドレスを持つことができます。 ホストに届くのに使用されるアドレスはホストに経路に影響を及ぼします。
Locally, Pip Addressing is similar to IP Addressing. That is, Pip prefixes are assigned to subnetworks (where the term subnetwork here is meant in the OSI sense. That is, it denotes a network operating at a lower layer than the Pip layer, for instance, a LAN). Thus, it is not necessary to advertise individual hosts in routing updates-- routers only need to advertise and store routes to subnetworks.
局所的に、Pip AddressingはIP Addressingと同様です。 すなわち、Pip接頭語はサブネットワークに割り当てられます。(ここの用語サブネットワークがOSI意味で意味されるところ。 すなわち、それはPip層より低い層、例えば、LANでネットワーク操作を指示します。). したがって、ルーティングアップデートで個々のホストの広告を出すのは必要ではありません--ルータは、ルートをサブネットワークに広告を出して、格納する必要があるだけです。
Unlike IP, however, a single subnetwork can have multiple prefixes. (Strictly speaking, in IP a single subnetwork can have multiple prefixes, but a host may not be able to recognize that it can reach another host on the same subnetwork but with a different prefix without going through a router.)
しかしながら、IPと異なって、単一のサブネットワークは複数の接頭語を持つことができます。 (厳密に言うと、IPでは、単一のサブネットワークが複数の接頭語を持つことができますが、同じサブネットワークの上に別のホストに届くことができると認めることができるのではなく、ホストはルータに直面していることのない異なった接頭語で認めるかもしれません。)
There are two styles of local Pip Addressing--one where the Pip Address denotes the host, and another where the Pip Address denotes only the destination subnetwork. The latter style is called ID- tailed Pip Addressing. With ID-tailed Pip Addresses, the Pip ID is used by the last router to forward the packet to the host. It is expected that ID-tailed Pip Addressing is the most common, because it greatly eases address administration.
地方のPip Addressingには2つのスタイルがあります--Pip Addressが目的地サブネットワークだけを指示するところでPip Addressがホスト、および別のものを指示するもの。 後者のスタイルはIDの尾のPip Addressingと呼ばれます。 ID尾をしたPip Addressesと共に、Pip IDはパケットをホストに送る最後のルータによって使用されます。 アドレス管理を大いに緩和するので、ID尾をしたPip Addressingが最も一般的であると予想されます。
(Note that the Pip Routing Directive can be used to route a Pip packet internal to a host. For instance, the RD can be used to direct a packet to a device in a host, or even a certain memory
ホストにとっての、内部のPipパケットを発送するのにPipルート設定Directiveを使用できることに注意してください。(例えば、ホスト、またはあるメモリさえの装置にパケットを向けるのにRDは使用できます。
Francis [Page 14] RFC 1621 Pip Near-term Architecture May 1994
構造1994年5月の用語のフランシス[14ページ]RFC1621種
location. The use of the RD for this purpose is not part of this near-term Pip architecture. We note, however, that this use of the RD could be locally done without effecting any other Pip systems.)
位置。 RDの使用はこのためにこの短期間Pip構造の一部ではありません。 しかしながら、私たちは、局所的にいかなる他のPipシステムにも作用しないでRDのこの使用ができたことに注意します。)
When a router receives a Pip packet and determines that the packet is destined for a host on one of its' attached subnetworks (by examining the appropriate FTIF), it then examines the destination Pip ID (which is in a fixed position) and forwards based on that. If it does not know the subnetwork address of the host, then it ARPs, using the Pip ID as the "address" in the ARP query.
'ルータが、Pipパケットを受けて、パケットがホストのために'付属サブネットワーク(適切なFTIFを調べるのによる)の1つで運命づけられていることを決定すると、それはPip ID(固定位置にある)とフォワードがそれに基礎づけた目的地を調べます。 それはホストのサブネットワークアドレスを知らないで、次に、それはARPsです、「アドレス」としてARP質問にPip IDを使用して。
4.2 CBT Style Multicast Addresses
4.2 CBT様式マルチキャストアドレス
When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 10, the FTIF and Dest ID indicate CBT (Core Based Tree) style multicast. The remainder of the bits are defined as follows:
1と0RCがRC Contents=1で定義したビットが10に設定されるとき、FTIFとDest IDはCBT(コアBased Tree)スタイルマルチキャストを示します。 ビットの残りは以下の通り定義されます:
bits meaning
---- -------
0,1 CBT Multicast (= 10)
2,3 level
4,5 metalevel
6 exit routing type
7 on-tree bit
8,9 scoping
ビット意味---- ------- 0 1つのCBT Multicast(= 10)2、3レベル4、5のメタレベル6出口ルーティングタイプ7木のビット8、9の見ること
With CBT (Core-based Tree) multicast, there is a single multicast tree connecting the members (recipients) of the multicast group (as opposed to Class-D style multicast, where there is a tree per source). The tree emanates from a single "core" router. To transmit to the group, a packet is routed to the core using unicast routing. Once the packet reaches a router on the tree, it is multicast using a group ID.
CBT(コアベースのTree)マルチキャストと共に、マルチキャストグループ(Class-Dスタイルマルチキャストと対照的に1ソースあたり1本の木があるところで)のメンバー(受取人)に接する単一のマルチキャスト木があります。 木はただ一つの「コア」ルータから発します。 グループに伝わるように、パケットはユニキャストルーティングを使用することでコアに発送されます。 パケットがいったん木の上のルータに達すると、それはグループIDを使用するマルチキャストです。
Thus, the FTIF Chain for CBT multicast contains the (Unicast) Hierarchical Pip Address of the core router. The Dest ID field contains the group ID.
したがって、CBTマルチキャストのためのFTIF Chainはコアルータの(ユニキャスト)階層的なPip Addressを含んでいます。 Dest ID分野はグループIDを含んでいます。
A Pip CBT packet, then, has two phases of forwarding, a unicast phase and a multicast phase. The "on-tree" bit of the RC indicates which phase the packet is in. While in the unicast phase, the on-tree bit is set to 0, and the packet is forwarded similarly to Pip Addresses. During this phase, the scoping bits are ignored.
そして、Pip CBTパケットには、推進の二相、ユニキャストフェーズ、およびマルチキャストフェーズがあります。 「木」のRCのビットは、パケットがどのフェーズにあるかを示します。 ユニキャストフェーズでは、木のビットを0に設定します、そして、同様にパケットをPip Addressesに送りますが。 この段階の間、見るビットは無視されます。
Francis [Page 15] RFC 1621 Pip Near-term Architecture May 1994
構造1994年5月の用語のフランシス[15ページ]RFC1621種
Once the packet reaches the multicast tree, it switches to multicast routing by changing the on-tree bit to 1 and using the Dest ID group address for forwarding. During this phase, bits 2-6 are ignored.
パケットがいったんマルチキャスト木に達すると、それは、木のビットを1に変えて、推進にDest IDグループアドレスを使用することによって、マルチキャストルーティングに切り替わります。 この段階の間、ビット2-6は無視されます。
4.3 Class D Style Multicast Addresses
4.3 クラスD様式マルチキャストアドレス
When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 01, the FTIF and Dest ID indicate Class D style multicast. The remainder of the RC is defined as:
1と0RCがRC Contents=1で定義したビットが01に設定されるとき、FTIFとDest IDはClass Dスタイルマルチキャストを示します。 RCの残りは以下と定義されます。
bits meaning
---- -------
0,1 Class D Style Multicast (= 01)
2-5 Scoping
ビット意味---- ------- 0 1つのクラスDの様式マルチキャストの(= 01)2-5見ること
By "class D" style multicast, we mean multicast using the algorithms developed for use with Class D addresses in IP (class D addresses are not used per se). This style of routing uses both source and destination information to route the packet (source host address and destination multicast group).
「クラスD」スタイルマルチキャストで、私たちは、Class DアドレスがIPにある状態で使用のために開発されたアルゴリズムを使用することでマルチキャストを言っています(クラスDアドレスはそういうものとして使用されません)。 このスタイルのルーティングは、パケット(送信元ホストアドレスと目的地マルチキャストグループ)を発送するのにソースと目的地情報の両方を使用します。
For Pip, the FTIF Chain holds the source Pip Address, in order of most significant hierarchy level first. The reason for putting the source Pip Address rather than the Source ID in the FTIF Chain is that use of the source Pip Address allows the multicast routing to take advantage of the hierarchical source address, as is being done with IP. The Dest ID field holds the multicast group. The Routing Context indicates Class-D style multicast. All routers must first look at the FTIF Chain and Dest ID field to route the packet on the tree.
Pipに関しては、FTIF Chainは最初に、最も重要な階層構造レベルの順にソースPip Addressを持っています。 Source IDよりむしろソースPip AddressをFTIF Chainに置く理由はマルチキャストルーティングがソースPip Addressの使用で階層的なソースアドレスを利用できるということです、IPと共にするように。 Dest ID分野はマルチキャストグループを保持します。 ルート設定ContextはClass-Dスタイルマルチキャストを示します。 すべてのルータが、最初に、木の上でパケットを発送するためにFTIF ChainとDest ID分野を見なければなりません。
Bits 2 through 5 of the RC are the scoping bits.
RCのビット2〜5は見るビットです。
4.4 Anycast Addressing
4.4 Anycastアドレシング
When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 11, the FTIF and Dest ID indicate Anycast addressing. The remainder of the RC is defined as:
1と0RCがRC Contents=1で定義したビットが11に設定されるとき、FTIFとDest IDはAnycastアドレシングを示します。 RCの残りは以下と定義されます。
Francis [Page 16] RFC 1621 Pip Near-term Architecture May 1994
構造1994年5月の用語のフランシス[16ページ]RFC1621種
bits meaning
---- -------
0,1 Anycast Address (= 11)
2,3 level
4,5 metalevel
6 exit routing type
7 anycast active
8,9 scoping
ビット意味---- ------- 0、1Anycast Address(= 11)の2、3レベル4、5 9が見られて、メタレベル6はルーティングタイプ7anycastアクティブな8を出ます。
With anycast routing, the packet is unicast, but to the nearest of a group of destinations. This type of routing is used by Pip for autoconfiguration. Other applications, such as discovery protocols, may also use anycast routing.
anycastルーティングで、ユニキャストですが、パケットは目的地の最も近いグループのそうです。 このタイプのルーティングは自動構成にPipによって使用されます。 また、発見プロトコルなどの他の応用はanycastルーティングを使用するかもしれません。
Like CBT, Pip anycast has two phases of operation, in this case the unicast phase and the anycast phase. The unicast phase is for the purpose of getting the packet into a certain vicinity. The anycast phase is to forward the packet to the nearest of a group of destinations in that vicinity.
CBTのように、Pip anycastには、この場合操作の二相、ユニキャストフェーズ、およびanycastフェーズがあります。 ユニキャストフェーズはある一定の付近にパケットを届ける目的のためのものです。 anycastフェーズはその付近で目的地のグループで最も近くパケットを送ることです。
Thus, the RC has both unicast and anycast information in it. During the unicast phase, the anycast active bit is set to 0, and the packet is forwarded according to the rules of Pip Addressing. The scoping bits are ignored.
したがって、RCはそれにユニキャストとanycast情報の両方を持っています。 ユニキャスト段階の間、anycast活性ビットを0に設定します、そして、Pip Addressingの規則に従って、パケットを送ります。 見るビットは無視されます。
The switch from the unicast phase to the anycast phase is triggered by the presence of an FTIF of value 1 in the FTIF Chain. When this FTIF is reached, the anycast active bit is set to 1, the scoping bits take effect, and bits 2 through 6 are ignored. When in the anycast phase, forwarding is based on the Dest ID field.
ユニキャストフェーズからanycastフェーズまでのスイッチはFTIF Chainでの価値1のFTIFの存在によって引き起こされます。 このFTIFに達しているとき、anycast活性ビットは1に設定されます、そして、見るビットは実施します、そして、ビット2〜6は無視されます。 anycastフェーズでは、推進がDest ID分野に基づいているとき。
5. Pip IDs
5. 種のID
The Pip ID is 64-bits in length [4].
Pip IDは長さ[4]は64ビットです。
The basic role of the Pip ID is to identify the source and destination host of a Pip Packet. (The other role of the Pip ID is for allowing a router to find the destination host on the destination subnetwork.)
Pip IDの基本的な役割はPip Packetのソースとあて先ホストを特定することです。 (Pip IDのもう片方の役割はルータが目的地サブネットワークの上であて先ホストを見つけるのを許容するものです。)
This having been said, it is possible for the Pip ID to ultimately identify something in addition to the host. For instance, the Pip ID could identify a user or a process. For this to work, however, the Pip ID has to be bound to the host, so that as far as the Pip layer is concerned, the ID is that of the host. Any additional use of the Pip ID is outside the scope of this Pip architecture.
これが言われていて、Pip IDが結局ホストに加えて何かを特定するのは、可能です。 例えば、Pip IDはユーザか過程を特定できました。 これが働くように、Pip IDはホストに縛られなければなりません、Pip層が関係があるのとそれ同じくらい遠いので、しかしながら、IDはホストのものです。 このPip構造の範囲の外にPip IDのどんな追加使用もあります。
Francis [Page 17] RFC 1621 Pip Near-term Architecture May 1994
構造1994年5月の用語のフランシス[17ページ]RFC1621種
The Pip ID is treated as flat. When a host receives a Pip packet, it compares the destination Pip ID in the Pip header with its' own. If there is a complete match, then the packet has reached the correct destination, and is sent to the higher layer protocol. If there is not a complete match, then the packet is discarded, and a PCMP Invalid Address packet is returned to the originator of the packet [7].
Pip IDはアパートとして扱われます。 'いつとホストがPipパケットを受けて、Pipヘッダーで目的地Pip IDを比較するか、それ、'自己です。 完全なマッチがあれば、パケットに正しい目的地に達して、より高い層のプロトコルに送ります。 完全なマッチがなければ、パケットは捨てます、そして、パケット[7]の生成元にPCMP Invalid Addressパケットを返します。
It is something of an open issue as to whether or not Pip IDs should contain significant organizational hierarchy information. Such information could be used for inverse DNS lookups and allowing a Pip packet to be associated with an organization. (Note that the use of the Pip ID alone for this purpose can be easily spoofed. By cross checking the Pip ID with the Pip Address prefix, spoofing is harder- -as hard as it is with IP--but still easy. Section 14.2 discusses methods for making spoofing harder still, without requiring encryption.)
それはPip IDが重要な組織階層情報を含むべきであるかどうかに関するある種の未解決の問題です。 そのような情報は、逆さのDNSルックアップに使用されて、Pipパケットが組織に関連しているのを許容しているかもしれません。 (このために容易にPip IDの使用しかだますことができないことに注意してください。 Pip Address接頭語でPip IDにクロスチェックすることによって、スプーフィングが、より困難である、-、IPと共にそれとして困難であるのは、そうです--しかし、まだ簡単。 セクション14.2はまだ暗号化を必要としないでスプーフィングをより困難にしているための方法を論じます。)
However, relying on organizational information in the Pip header generally complicates ID assignment. This complication has several ramifications. It makes host autoconfiguration of hosts harder, because hosts then have to obtain an assignment from some database somewhere (versus creating one locally from an IEEE 802 address, for instance). It means that a host has to get a new assignment if it changes organizations. It is not clear what the ramifications of this might be in the case of a mobile host moving through different organizations.
しかしながら、Pipヘッダーで組織的な情報を当てにすると、一般に、ID課題は複雑にされます。 この複雑さには、いくつかの分岐があります。 それで、ホストのホスト自動構成は、より困難になります、次に、ホストがどこか(IEEE802アドレスから1つを局所的に作成することに対して例えば)で何らかのデータベースから課題を得なければならないので。 それは、それが組織を変えるならホストが新しい課題を得なければならないことを意味します。 この分岐が異なった組織によるモバイルホスト運動の場合で何であるかが明確ではありません。
Because of these difficulties, the use of flat Pip IDs is currently favored.
これらの困難のために、平坦なPip IDの使用は現在、支持されます。
Blocks of Pip ID numbers have been reserved for existing numbering spaces, such as IP, IEEE 802, and E.164. Pip ID numbers have been assigned for such special purposes such as "any host", "any router", "all hosts on a subnetwork", "all routers on a subnetwork", and so on. Finally, 32-bit blocks of Pip ID numbers have been reserved for each country, according to ISO 3166 country code assignments.
ブロックのPip ID番号はIPや、IEEE802や、E.164などの既存の付番空間に予約されました。 「どんなホストも」、「どんなルータも」、「サブネットワークの上のすべてのホスト」、「サブネットワークの上のすべてのルータ」などなどのそのような特別な目的のために種のID番号を割り当ててあります。 最終的に、ISO3166国名略号課題によると、32ビットのブロックのPip ID番号は各国に予約されました。
6. Use of DNS
6. DNSの使用
The Pip near-term architecture uses DNS in roughly the same style that it is currently used. In particular, the Pip architecture maintains the two fundamental DNS characteristics of 1) information stored in DNS does not change often, and 2) the information returned by DNS is independent of who requested it.
Pip短期間構造は現在、使用されていた状態でおよそ同じスタイルにおけるDNSを使用します。 特に、Pip構造は、1の2つの基本的なDNSの特性) DNSに格納された情報がしばしば変化するというわけではないと主張します、そして、だれがそれを要求したかから情報がDNSで返した2は)独立しています。
While the fundamental use of DNS remains roughly the same, Pip's use of DNS differs from IP's use by degrees. First, Pip relies on DNS to
DNSの基本的な使用はおよそ同じままで残っていますが、DNSのPipの使用はIPの使用と次第に異なっています。 最初に、PipはDNSを当てにします。
Francis [Page 18] RFC 1621 Pip Near-term Architecture May 1994
構造1994年5月の用語のフランシス[18ページ]RFC1621種
hold more types of information than IP [1]. Second, Pip Addresses in DNS are expected to change more often than IP addresses, due to reassignment of Pip Address prefixes (the providerPart). To still allow aggressive caching of DNS records in the face of more quickly changing addressing, Pip has a mechanism of indicating to hosts when an address is no longer assigned. This triggers an authoritative query, which overrides DNS caches. The mechanism consists of PCMP Packet Not Delivered messages that indicate explicitly that the Pip Address is invalid.
IP[1]より情報のタイプを保持してください。 2番目に、IPアドレスよりDNSのPip Addressesがさらにしばしば変化すると予想されます、Pip Address接頭語(providerPart)の再割当てのため。 急速により変化しているアドレシングに直面してまだDNS記録の攻撃的なキャッシュを許しているために、Pipには、アドレスがいつもう割り当てられないかをホストに示すメカニズムがあります。 これは正式の質問の引き金となります。(それは、DNSキャッシュをくつがえします)。 メカニズムはPip Addressが無効であることを明らかに示すPCMP Packet Not Deliveredメッセージから成ります。
In what follows, we first discuss the information contained in DNS, and then discuss authoritative queries.
続くことでは、私たちは、最初にDNSに含まれた情報について議論して、次に、正式の質問について議論します。
6.1 Information Held by DNS
6.1 情報はDNSを固守しました。
The information contained in DNS for the Pip architecture is:
PipアーキテクチャのためのDNSに含まれた情報は以下の通りです。
1. The Pip ID.
1. Pip ID。
2. Multiple Pip Addresses
2. 複数の種のアドレス
3. The destination's mobile host address servers.
3. 目的地のモバイルホストアドレスサーバ。
4. The Public Data Network (PDN) addresses through which the
destination can be reached.
4. 目的地に達することができるPublic Data Network(PDN)アドレス。
5. The Pip/IP Translators through which the destination (if the
destination is IP-only) can be reached.
5. 目的地(目的地がIP専用であるなら)に達することができるPip/IP Translators。
6. Information about the providers represented by the destination's
Pip addresses. This information includes provider name, the type
of provider network (such as SMDS, ATM, or SIP), and access
restrictions on the provider's network.
6. 目的地のPipアドレスによって表されたプロバイダーに関する情報。 この情報はプロバイダー名、プロバイダーネットワーク(SMDS、ATM、またはSIPなどの)のタイプ、およびプロバイダーのネットワークにおけるアクセス制限を含んでいます。
The Pip ID and Addresses are the basic units of information required for carriage of a Pip packet.
Pip IDとAddressesはPipパケットの運搬に必要である情報の原単位です。
The mobile host address server tells where to send queries for the current address of a mobile Pip host. Note that usually the current address of the mobile host is conveyed by the mobile host itself, thus a mobile host server query is not usually required.
モバイルホストアドレスサーバは、モバイルPipホストの現在のアドレスのための質問をどこに送るかを言います。 通常、モバイルホストの現在のアドレスがモバイルホスト自身によって伝えられて、その結果、通常、モバイルホストサーバ質問は必要でないことに注意してください。
The PDN address is used by the entry router of a PDN to learn the PDN address of the next hop router. The entry router obtains the PDN address via an option in the Pip packet. If there are multiple PDNs associated with a given Pip Address, then there can be multiple PDN addresses carried in the option. Note that the option is not sent on every packet, and that only the PDN entry router need examine the
PDNアドレスはPDNのエントリールータによって使用されて、次のホップルータのPDNアドレスを学びます。 エントリールータはPipパケットのオプションを通したPDNアドレスを得ます。 与えられたPip Addressに関連している複数のPDNsがあれば、オプションで運ばれた複数のPDNアドレスがあることができます。 PDNエントリールータだけがあらゆるパケットでオプションを送るというわけではなくて、調べなければならないそれに注意してください。
Francis [Page 19] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[19ページ]RFC1621種
option.
オプション。
The Pip/IP translator information is used to know how to translate an IP address into a Pip Address so that the packet can be carried across the Pip infrastructure. If the originating host is IP, then the first IP/Pip translator reached by the IP packet must query DNS for this information.
Pip/IP翻訳者情報は、Pipインフラストラクチャの向こう側にパケットを運ぶことができるようにIPアドレスをPip Addressに翻訳する方法を知るのに使用されます。 送信元ホストがIPであるなら、第1代IPパケットによって連絡されたIP/種の翻訳者はこの情報のためにDNSについて質問しなければなりません。
The information about the destination's providers is used to help the "source" (either the source host or a Pip Header Server near the source host) format an appropriate Pip header with regards to choosing a Pip Address [14]. The choice of one of multiple Pip Addresses is essentially a policy routing choice.
目的地のプロバイダーの情報は、「ソース」(送信元ホストの近くの送信元ホストかPip Header Serverのどちらか)があいさつでPip Address[14]を選ぶのに適切なPipヘッダーをフォーマットするのを助けるのに使用されます。 複数のPip Addressesの1つの選択は本質的には方針ルーティング選択です。
More detailed descriptions of the use of the information carried in DNS is contained in the relevant sections.
DNSで運ばれた情報の使用の、より詳細な記述は関連セクションに含まれています。
6.2 Authoritative Queries in DNS
6.2 DNSでの正式の質問
In general, Pip treats addresses as more dynamic entities than does IP. One example of this is how Pip Address prefixes change when a subscriber network attaches to a new provider. Pip also carries more information in DNS, any of which can change for various reasons. Thus, the information in DNS is more dynamic with Pip than with IP.
一般に、PipはIPよりダイナミックな実体としてアドレスを扱います。 この1つの例はPip Address接頭語が、加入者ネットワークがいつ新しいプロバイダーに付くかをどう変えるかということです。 また、種はDNSの詳しい情報を運びます。そのいずれも様々な理由で変化できます。 したがって、DNSの情報はPipと共にIPよりダイナミックです。
Because of the increased reliance on DNS, there is a danger of increasing the load on DNS. This would be particularly true if the means of increasing DNS' dynamicity is by shortening the cache holding time by decreasing the DNS Time-to-Live (TTL). To counteract this trend, Pip provides explicit network layer (Pip layer) feedback on the correctness of address information. This allows Pip hosts to selectively over-ride cached DNS information by making an authoritative query. Through this mechanism, we actually hope to increase the cache holding time of DNS, thus improving DNS' scaling characteristics overall.
DNSへの増強された信用のために、DNSで負荷を増強するという危険があります。 DNSのdynamicityを増強する手段が生きるDNS Time(TTL)を減少させることによってキャッシュ把持時間を短くすることであるなら、これは特に本当でしょう。 この傾向を打ち消すために、Pipはアドレス情報の正当性の明白なネットワーク層(種の層)フィードバックを提供します。 これで、Pipホストは、正式の質問をすることによって、選択的にキャッシュされたDNS情報をくつがえすことができます。 このメカニズムを通して、私たちは、DNSの時間を保持する、その結果、全体的に見てDNSのスケーリングの特性を改良するキャッシュを増強することを実際に望んでいます。
The network layer feedback is in the form of a type of PCMP Packet Not Delivered (PDN) message that indicates that the address used is known to be out-of-date. Routers can be configured with this information, or it can be provided through the routing algorithm (when an address is decommissioned, the routing algorithm can indicate that this is the reason that it has become unreachable, as opposed to becoming "temporarily" unreachable through equipment failure).
ネットワーク層フィードバックが使用されるアドレスが時代遅れであることが知られているのを示す一種のPCMP Packet Not Delivered(PDN)メッセージの形にあります。 この情報でルータを構成できますか、またはルーティング・アルゴリズムでそれを提供できます(アドレスが使用を中止されるとき、ルーティング・アルゴリズムは、これが手が届かなくなった理由であることを示すことができます、設備故障を通して「一時」手が届かなくなることと対照的に)。
Pip hosts consider destination addresses to be in one of four states:
種のホストは、送付先アドレスが4つの州の1つにあると考えます:
Francis [Page 20] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[20ページ]RFC1621種
1. Unknown, but assumed to be valid.
1. 未知にもかかわらず、有効になるように、想定されています。
2. Reachable (and therefore valid).
2. 届くのと(したがって、有効。)です。
3. Unreachable and known to be invalid.
3. 手が届かなく無効になるように知られています。
4. Unreachable, but weakly assumed to be valid.
4. 手の届かないのですが、有効な状態で弱々しく想定されています。
The first state exists before a host has attempted communication with another host. In this state, the host queries DNS as normal (that is, does not make an authoritative query).
ホストが別のホストとのコミュニケーションを試みる前に最初の状態は存在しています。 この状態では、ホストは正常な同じくらいDNS(すなわち、正式の質問をしない)について質問します。
The second state is reached when a host has successfully communicated with another host. Once a host has reached this state, it can stay in it for an arbitrarily long time, including after the DNS TTL has expired. When in this state, there is no need to query DNS.
ホストが首尾よく別のホストとコミュニケートしたとき、2番目の状態に達しています。 ホストがいったんこの状態に着くと、それは任意に長い時間、DNS TTLが期限が切れた後に包含のためにそれに滞在できます。 DNSについて質問する必要は全くこの状態にないとき。
A host enters the third state after a failed attempt at communicating with another host where the PCMP PND message indicates explicitly that the address is known to be invalid. In this case, the host makes an authoritative query to DNS whether or not the TTL has expired. It is this case that allows lengthy caching of DNS information while still allowing addresses to be reassigned frequently.
ホストは別のホストとコミュニケートすることへの未遂の後のPCMP PNDメッセージがアドレスが無効であることが知られているのを明らかに示す3番目の状態に入ります。 この場合、ホストはTTLが期限が切れたか否かに関係なく、正式の質問をDNSにします。 アドレスが頻繁に再選任されるのをまだ許容している間、それがDNS情報の長いキャッシュを許すのは、本件です。
A host enters the fourth state after a failed attempt at communicating with another host, but where the address is not explicitly known to be invalid. In this state, the host weakly assumes that the address of the destination is still valid, and so can requery DNS with a normal (non-authoritative) query.
ホストは別のホストとコミュニケートすることへの未遂にもかかわらず、どこでアドレスが無効であることが明らかに知られなかったかの後の4番目の状態に入ります。 この状態では、ホストは通常(非正式の)の質問で目的地のアドレスがまだ有効であり、requery DNSもそうすることができると弱々しく仮定します。
7. Type-of-Service (TOS) (or lack thereof)
7. サービスのタイプ(TOS)(または、それの不足)
One year ago it probably would have been adequate to define a handful (4 or 5) of priority levels to drive a simple priority FIFO queue. With the advent of real-time services over the Internet, however, this is no longer sufficient. Real-time traffic cannot be handled on the same footing as non-real-time. In particular, real-time traffic must be subject to access control so that excess real-time traffic does not swamp a link (to the detriment of other real-time and non- real-time traffic alike).
1年前に、簡単な優先権先入れ先出し法待ち行列を追い立てるために優先順位の一握り(4か5)を定義するのはたぶん適切だったでしょう。 しかしながら、リアルタイムでインターネットの上のサービスの到来では、これはもう十分ではありません。 非リアルタイムと同じ立脚地でリアルタイムのトラフィックを扱うことができません。 リアルタイムのトラフィックはコントロールにアクセスするために特に、なることがなければならないので、余分なリアルタイムのトラフィックはリンク(一様な他のリアルタイムで非リアルタイムのトラフィックの損傷への)を浸しません。
Given that a consensus solution to real- and non-real-time traffic management in the internet does not exist, this version of the Pip near-term architecture does not specify any classes of service (and related queueing mechanisms). It is expected that Pip will define classes of service (primarily for use in the Handling Directive) as solutions become available.
インターネットにおける本当の、そして、非リアルタイムの輸送管理へのコンセンサス解決が存在していないなら、Pip短期間アーキテクチャのこのバージョンはどんなクラスのサービス(そして、待ち行列メカニズムを関係づける)も指定しません。 Pipがサービス(主としてHandling Directiveにおける使用のための)のクラスをソリューションが利用可能になると定義すると予想されます。
Francis [Page 21] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[21ページ]RFC1621種
8. Routing on (Hierarchical) Pip Addresses
8. (階層的)の種のアドレスにおけるルート設定
Pip forwarding in a single router is done based on one or a small number of FTIFs. What this means with respect to hierarchical Pip Addresses is that a Pip router is able to forward a packet based on examining only part of the Pip Address--often a single level.
1かFTIFsの少ない数に基づいてただ一つのルータにおける種の推進をします。 これが階層的なPip Addressesに関して意味することはPip Addressの一部だけを調べることに基づいてPipルータがパケットを進めることができるということです--しばしばただ一つのレベル。
One advantage to encoding each level of the Pip Address separately is that it makes handling of addresses, for instance address assignment or managing multiple addresses, easier. Another advantage is address lookup speed--the entire address does not have to be examined to forward a packet (as is necessary, for instance, with traditional hierarchical address encoding). The cost of this, however, is additional complexity in keeping track of the active hierarchical level in the Pip header.
別々にPip Addressの各レベルをコード化する1つの利点はアドレス、例えば課題か管理倍数が扱うアドレスの取り扱いをするということです、より簡単です。 別の利点はアドレスルックアップ速度です--全体のアドレスがパケットを進めるために調べられる必要はない、(例えば、伝統的な階層的なアドレスコード化によって必要である、) しかしながら、この費用はPipヘッダーでアクティブな階層レベルの動向をおさえることにおいて追加複雑さです。
Since Pip Addresses allow reuse of numbers at each level of the hierarchy, it is necessary for a Pip router to know which level of the hierarchy it is acting at when it retrieves an FTIF. This is done in part with a hierarchy level indicator in the Routing Context (RC) field. RC level is numbered from the top of the hierarchy down. Therefore, the top of the hierarchy is RC level = 0, the next level down is RC level = 1, and so on.
Pip Addressesが階層構造の各レベルにおける数の再利用を許すので、それがFTIFを検索する時階層構造のどのレベルを活動させているかを知るのがPipルータに必要です。 一部ルート設定Context(RC)分野で階層構造レベル指示語でこれをします。 付番されたRCレベルは階層構造の最上部からダウンします。 下に次のレベルは、したがって、階層構造の最上部がRCレベル=0であり、RCレベル=1などです。
The RC level alone, however, is not adequate to keep track of the appropriate level in all cases. This is because different parts of the hierarchy may have different numbers of levels, and elements of the hierarchy (such as a domain or an area) may exist in multiple parts of the hierarchy. Thus, a hierarchy element can be, say, level 3 under one of its parents and level 2 under another.
しかしながら、RCレベルだけが、すべての場合における適正水準の動向をおさえるために適切ではありません。 これが階層構造の異なった部分には異なった数のレベルがあるかもしれないからである階層構造(ドメインか領域などの)の原理は階層構造の複数の部分に存在するかもしれません。 レベル3 たとえば、両親のひとり、したがって、階層構造要素はそうであることができ、レベル2下は別です。
To resolve this ambiguity, the topological hierarchy is superimposed with another set of levels--metalevels [11]. A metalevel boundary exists wherever a hierarchy element has multiple parents with different numbers of levels, or may with reasonable probability have multiple parents with different numbers of levels in the future.
このあいまいさを取り除くために、位相的な階層構造はもう1セットのレベルで重ねられます--メタレベル[11]。 階層構造要素に、どこに複数の両親が異なった数のレベルと共にいる、または複数の両親が将来異なった数のレベルと共にいても、妥当な確率と共にメタレベル境界は存在しています。
Thus, a metalevel boundary exists between a subscriber network and its provider. (Note that in general the metalevel represents a significant administrative boundary between two levels of the topological hierarchy. It is because of this administrative boundary that the child is likely to have multiple parents.) Lower metalevels may exist, but usually will not.
したがって、メタレベル境界は加入者ネットワークとそのプロバイダーの間に存在しています。 (一般に、メタレベルが位相的な階層構造の2つのレベルの間の重要な管理境界を表すことに注意してください。 この管理境界のために、子供は複数の両親がいそうです。) 下側のメタレベルは存在するかもしれませんが、通常、望んでください。
The RC, then, contains a level and a metalevel indicator. The level indicates the number of levels from the top of the next higher metalevel. The top of the global hierarchy is metalevel 0, level 0. The next level down (for instance, the level that provides a level of
そして、RCはレベルとメタレベルインディケータを含んでいます。 レベルは次の、より高いメタレベルの先端からレベルの数を示します。 グローバルな階層構造の最上部はメタレベル0、平らな0です。 下に次のレベル、(例えば、それがレベルを提供するレベル
Francis [Page 22] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[22ページ]RFC1621種
hierarchy within a provider) is metalevel 0, level 1. The first level of hierarchy under a provider is metalevel 1, level 0, and so on.
プロバイダーの中の階層構造) メタレベルは0、レベル1ですか? プロバイダーの下における、最初のレベルの階層構造は、メタレベル1、レベル0などです。
To determine the RC level and RC metalevel in a transmitted Pip packet, a host (or Pip Header Server) must know where the metalevels are in its own Pip Addresses.
伝えられたPipパケットでRCレベルとRCメタレベルを測定するために、ホスト(または、Pip Header Server)は、メタレベルがそれ自身のPip Addressesにどこにあるかを知らなければなりません。
The host compares its source Pip Address with the destination Pip Address. The highest Pip Address component that is different between the two addresses determines the level and metalevel. (No levels higher than this level need be encoded in the Routing Directive.)
ホストは目的地Pip AddressとソースPip Addressを比べます。 2つのアドレスの間で異なった最も高いPip Addressの部品はレベルとメタレベルを測定します。 (このレベルより高いどんなレベルもルート設定Directiveでコード化される必要はありません。)
Neighbor routers are configured to know if there is a level or metalevel boundary between them, so that they can modify the RC level and RC metalevel in a transmitted packet appropriately.
隣人ルータはそれらの間には、レベルかメタレベル境界があるかを知るために構成されます、伝えられたパケットで適切にRCレベルとRCメタレベルを変更できるように。
8.1 Exiting a Private Domain
8.1 個人的なドメインを出ること。
The near-term Pip Architecture provides two methods of exit routing, that is, routing inter-domain Pip packets from a source host to a network service provider of a private domain [12,15]. In the first method, called transit-driven exit routing, the source host leaves the choice of provider to the routers. In the second method, called host-driven exit routing, the source host explicitly chooses the provider. In either method, it is possible to prevent internal routers from having to carry external routing information. The exit routing bit of the RC indicates which type of exit routing is in effect.
短期間Pip Architectureは出口ルーティング(すなわち、送信元ホストから個人的なドメイン[12、15]のネットワークサービスプロバイダーまでのルーティング相互ドメインPipパケット)の2つのメソッドを提供します。 トランジット駆動の出口ルーティングと呼ばれる最初のメソッドで、送信元ホストはプロバイダーの選択をルータに残します。 ホスト駆動の出口ルーティングと呼ばれる2番目のメソッドで、送信元ホストは明らかにプロバイダーを選びます。 メソッドで、内部のルータが外部のルーティング情報を運ばなければならないのを防ぐのは可能です。 RCの出口ルーティングビットは、どのタイプの出口ルーティングが有効であるかを示します。
With host-driven exit routing, it is possible for the host to choose a provider through which the destination cannot be reached. In this case, the host receives the appropriate PCMP Packet Not Delivered message, and may either fallback on transit-driven exit routing or choose a different provider.
ホスト駆動の出口ルーティングで、ホストが目的地に達することができないプロバイダーを選ぶのは、可能です。 この場合、ホストが、適切なPCMP Packet Not Deliveredメッセージを受け取って、トランジット駆動の出口のどちらの後退も掘られて、受け取るかもしれませんか、または異なったプロバイダーを選んでください。
When using transit-driven exit routing, there are two modes of operation. The first, called destination-oriented, is used when the routers internal to a domain have external routing information, and the host has only one provider prefix. The second, called provider- oriented, is used when the routers internal to a domain do not have any external routing information or when the host has multiple provider prefixes. (With IP, this case is called default routing. In the case of IP, however, default routing does not allow an intelligent choice of multiple exit points.)
トランジット駆動の出口ルーティングを使用するとき、2つの運転モードがあります。 ドメインへの内部のルータに外部のルーティング情報があるとき、目的地指向であると呼ばれる第1は使用されています、そして、ホストには、1つのプロバイダー接頭語しかありません。 ドメインへの内部のルータには少しの外部のルーティング情報もないか、またはホストに複数のプロバイダー接頭語があるとき、適応するプロバイダーと呼ばれる2番目は使用されています。 (IPと共に、本件はデフォルトルーティングと呼ばれます。 しかしながら、IPの場合では、デフォルトルーティングは複数のエキジットポイントの利口な選択を許容しません。)
With provider-oriented exit routing, the host arbitrarily chooses a source Pip Address (and therefore, a provider). (Note that if the
プロバイダー指向の出口ルーティングで、ホストは任意に、ソースPip Address(そして、したがって、プロバイダー)を選びます。 (それに注意してください。
Francis [Page 23] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[23ページ]RFC1621種
Pip Header Server is tracking inter-domain routing, then it chooses the appropriate provider.) If the host chooses the wrong provider, then the border router will redirect the host to the correct provider with a PCMP Provider Redirect message.
種のHeader Serverは相互ドメインルーティングを追跡しています、次に、それは適切なプロバイダーを選びます。) ホストが間違ったプロバイダーを選ぶと、境界ルータはPCMP Provider Redirectメッセージで正しいプロバイダーにホストを向け直すでしょう。
8.2 Intra-domain Networking
8.2 イントラドメインネットワーク
With intra-domain networking (where both source and destination are in the private network), there are two scenarios of concern. In the first, the destination address shares a providerPart with the source address, and so the destination is known to be intra-domain even before a packet is sent. In the second, the destination address does not share a providerPart with the source address, and so the source host doesn't know that the destination is reachable intra-domain. Note that the first case is the most common, because the private top-level number assignment acts as the common prefix even though it isn't advertised globally (see section 4.1).
イントラドメインネットワーク(私設のネットワークにはソースと目的地の両方があるところ)と共に、関心の2つのシナリオがあります。 1番目では、送付先アドレスがソースアドレスとproviderPartを共有するので、目的地はパケットを送る前のさえイントラドメインであることが知られています。 2番目では、送付先アドレスがソースアドレスとproviderPartを共有しないので、送信元ホストは、目的地が届いているイントラドメインであることを知りません。 最初のケースが最も一般的であることに注意してください、それがグローバルに広告に掲載されていませんが(セクション4.1を見てください)、個人的な最高レベル番号課題が一般的な接頭語として機能するので。
In the first case, the Pip Addresses in the Routing Directive need not contain the providerPart. Rather, it contains only the address part below the metalevel boundary. (A Pip Address in an FTIF Chain always starts at a metalevel boundary).
前者の場合、Directiveが必要とするルート設定におけるPip AddressesはproviderPartを含んでいません。 むしろ、それはメタレベル境界の下にアドレス部だけを含んでいます。 (FTIF ChainのPip Addressはメタレベル境界でいつも始まります。)
For instance, if the source Pip Address is 1.2.3,4.5.6 and the destination Pip Address is 1.2.3,4.7.8, then only 4.7.8 need be included for the destination address in the Routing Directive. (The comma "," in the address indicates the metalevel boundary between providerPart and subscriberPart.) The metalevel and level are set accordingly.
例えば、ソースであるならPip Addressがそうである、1.2、.3、4.5に、.6と目的地Pip Addressがそうである、1.2、.3、4.7 .8 そして、4.7だけに、.8はルート設定Directiveにおける送付先アドレスのために含まれなければなりません。 「(コンマ、」、」 アドレスでproviderPartとsubscriberPartの間のメタレベル境界を示す、) メタレベルとレベルはそれに従って、設定されます。
In the second case, it is desirable to use the Pip Header Server to determine if the destination is intra-domain or inter-domain. The Pip Header Server can do this by monitoring intra-domain routing. (This is done by having the Pip Header Server run the intra-domain routing algorithm, but not advertise any destinations.) Thus, the Pip Header Server can determine if the providerPart can be eliminated from the address, as described in the last paragraph, or cannot and must conform to the rules of exit routing as described in the previous section.
2番目の場合では、目的地がイントラドメインかそれとも相互ドメインであるかを決定するのにPip Header Serverを使用するのは望ましいです。 Pip Header Serverは、イントラドメインルーティングをモニターすることによって、これができます。 (Pip Header Serverがイントラドメインルーティング・アルゴリズムを実行しますが、どんな目的地も広告を出さないのを持っていることによって、これをします。) したがって、Pip Header Serverは前項で説明されるように従うことができないで、最後のパラグラフで説明されるようにアドレスからproviderPartを排除できるかどうか決定できなければならないか、または出口ルーティングの規則に従わなければなりません。
If the Pip Header Server does not monitor intra-domain routing, however, then the following actions occur. In the case of host- driven exit routing, the packet will be routed to the stated provider, and an external path will be used to reach an internal destination. (The moral here is to not use host-driven exit routing unless the Pip Header Server is privy to routing information, both internal and external.)
しかしながら、Pip Header Serverがイントラドメインルーティングをモニターしないなら、以下の動作は起こります。 ホストの駆動出口ルーティングの場合では、パケットは述べられたプロバイダーに発送されるでしょう、そして、外部の経路は、内部の目的地に達するのに使用されるでしょう。 (ここの教訓はPip Header Serverがルーティング情報に関与して、かつ内部で、かつ外部でないならホスト駆動の出口ルーティングを使用しないことです。)
Francis [Page 24] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[24ページ]RFC1621種
In the case of transit-driven exit routing, the packet sent by the host will eventually reach a router that knows that the destination is intra-domain. This router will forward the packet towards the destination, and at the same time send a PCMP Reformat Transit Part message to the host. This message tells the host how much of the Pip Address is needed to route the packet.
トランジット駆動の出口ルーティングの場合では、ホストによって送られたパケットは結局、目的地がイントラドメインであることを知っているルータに達するでしょう。 このルータは、目的地に向かってパケットを送って、同時に、PCMP Reformat Transit Partメッセージをホストに送るでしょう。 このメッセージは、Pip Addressのどのくらいがパケットを発送するのに必要であるかをホストに言います。
9. Pip Header Server
9. 種のヘッダーサーバ
Two new components of the Pip Architecture are the Pip/IP Translator and the Pip Header Server. The Pip/IP Translator is only used for transition from IP to Pip, and otherwise would not be necessary. The Pip Header Server, however, is a new architectural component.
Pip Architectureの2つの新しい部品が、Pip/IP TranslatorとPip Header Serverです。IPからPipまでの変遷に使用されるだけです。そうでなければ、Pip/IP Translatorは必要でないでしょう。 しかしながら、Pip Header Serverは新しい建築コンポーネントです。
The purpose of the Pip Header Server is to form a Pip Header. It is useful to form the Pip header in a separate box because 1) in the future (as policy routing matures, for instance), significant amounts of information may be needed to form the Pip header--too much information to distribute to all hosts, and 2) it won't be possible to evolve all hosts at the same time, so the existence of a separate box that can spoon-feed Pip headers to old hosts is necessary. (It is impossible to guarantee that no modification of Pip hosts is necessary for any potential evolution, but being able to form the header in a server, and hand it to an outdated host, is a large step in the right direction.)
Pip Header Serverの目的はPip Headerを形成することです。 未来(例えば、方針ルーティングが熟すとき)、かなりの量の情報の1が)Pipヘッダーを形成するのに必要であるかもしれないので、別々の箱の中にPipヘッダーを形成するのは役に立ちます--同時にすべてのホストを発展するのにおいて可能にならないので、Pipヘッダーを年取ったホストにさじで食べさせることができる別々の箱の存在が必要です。 (Pipホストの変更がどんな潜在的発展にも必要ですが、サーバでヘッダーを形成して、時代遅れのホストを尊敬できて、正しい方向には大きいステップがないのを保証するのが不可能です。)
(Note that policy routing architectures commonly if not universally require the use of some kind of "route server" for calculating policy routes. The Pip Header Server is, among other things, just this server. Thus, the Pip Header Server does not so much result from the fact that Pip itself is more complex than IP or other "IPv7" proposals. Rather, the Pip Header Server reflects the fact that the Pip Architecture has more functionality than ROAD architectures supported by the simpler proposals.)
(方針ルーティングアーキテクチャが一般的にか一般にある種の「ルートサーバ」の計算の方針ルートの使用を必要とすることに注意してください。 Pip Header Serverはただ特にこのサーバです。その結果、Pip Header Serverが事実からあまり生じないので、Pip自身はIPか他の「IPv7"提案」より複雑です。 むしろ、Pip Header ServerはPip Architectureが、より簡単な提案でROADアーキテクチャより多くの機能性をサポートさせるという事実を反映します。)
We note that for the near-term architecture hosts themselves will by-and-large have the capability of forming Pip headers. The exception to this will be the case where the Pip Header Server wishes to monitor inter-domain routing to enhance provider selection. Thus, the Pip Header Server role will be largely limited to evolution (see section 16).
私たちは、短期間アーキテクチャホスト自身のためのそれにはPipヘッダーを形成する能力が概してあることに注意します。 これへの例外はPip Header Serverがプロバイダー選択を機能アップするために相互ドメインルーティングをモニターしたがっているケースになるでしょう。 したがって、Pip Header Serverの役割は発展に主に制限されるでしょう(セクション16を見てください)。
9.1 Forming Pip Headers
9.1 種のヘッダーを形成すること。
Forming a Pip header is more complex than forming an IP header because there are many more choices to make. At a minimum, one of multiple Pip Addresses (both source and destination) must be chosen [14]. In the near future, it will also be necessary to choose a TOS.
Pipヘッダーを形成するのはするずっと多くの選択があるのでIPヘッダーを形成するより複雑です。 最小限では、複数のPip Addresses(ソースと目的地の両方)の1つに[14]を選ばなければなりません。 また、近い将来、TOSを選ぶのも必要でしょう。
Francis [Page 25] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[25ページ]RFC1621種
After DNS information about the destination has been received, the the following information is available to the Pip header formation function.
DNSの後に目的地の情報を受け取った、以下の情報はPipヘッダー構成機能に利用可能です。
1. From DNS: The destination's providers (either directly connected
or nearby enough to justify making a policy decision about), and
the names, types, and access restrictions of those providers.
1. DNSから: それらのプロバイダーの目的地のプロバイダー(政策決定をするのを正当化するほど直接接続されたか、近い)、名前、タイプ、およびアクセス制限。
2. From the source host: The application type (and thus, the desired
service), and the user access restriction classes.
2. ソースから、以下を接待してください。 アプリケーションタイプ(そして、その結果、必要なサービス)、およびユーザアクセス制限のクラス。
3. From local configuration: The source's providers, and the names,
types, and access restrictions of those providers.
3. 地方の構成から: それらのプロバイダーのソースのプロバイダー、名前、タイプ、およびアクセス制限。
4. Optionally from inter-domain routing: The routes chosen by
inter-domain to all top level providers. (Note that inter-domain
routing in the Pip near-term architecture is path-vector.
Because of this, the Pip Header Server does not obtain enough
information from inter-domain routing to form a policy route.
When the technology to do this matures, it can be installed into
Pip Header Servers.)
4. 任意に以下を掘る相互ドメインから 相互ドメインによってすべての先端に選ばれたルートはプロバイダーを平らにします。 (Pip短期間アーキテクチャでの相互ドメインルーティングが経路ベクトルであることに注意してください。 これのために、Pip Header Serverは相互ドメインルーティングからの方針ルートを形成できるくらいの情報を得ません。 これをする技術が熟すとき、それをPip Header Serversにインストールできます。)
The inter-domain routing information is optional. If it is used,
then probably a Pip Header Server is necessary, to limit this
information to a small number of systems.
相互ドメインルーティング情報は任意です。 それが使用されているなら、たぶん、Pip Header Serverが、この情報を少ない数のシステムに制限するのに必要です。
There may also be arbitrary policy information available to the Pip header formation function. This architecture does not specify any such information.
また、Pipヘッダー構成機能に利用可能な任意の方針情報があるかもしれません。 このアーキテクチャは少しのそのような情報も指定しません。
The Pip header formation function then goes through a process of forming an ordered list of source/destination Pip Addresses to use. The ordering is based on knowledge of the application service requirements, the service provided by the source providers, guesses or learned information about the service provided by the destination providers or by source/destination provider pairs, and the cost of using source providers to reach destination providers. It is assumed that the sophistication of forming the ordered list will grow as experienced is gained with internet commercialization and real-time services.
そして、Pipヘッダー構成機能は使用するソース/目的地Pip Addressesの規則正しいリストを形成するプロセスを通ります。 注文はアプリケーションサービス要件に関する知識に基づいています、とサービスがソースプロバイダーで前提としました、とサービスに関する推測か経験から学んだ知識が目的地プロバイダーかソース/目的地プロバイダー組と、目的地プロバイダーに達するのにソースプロバイダーを使用する費用で前提としました。 規則正しいリストが経験されるように育てる形成に関する洗練がインターネット商業化とリアルタイムのサービスで獲得されると思われます。
The Pip Header formation function then returns the ordered pairs of source and destination addresses to the source host in the PHP response message, along with an indication of what kind of exit routing to use with each pair. Any additional information, such as PDN Address, is also returned. With this information, the source host can now establish communications and properly respond to PCMP messages. Based on information received from PCMP messages,
次に、Pip Header構成機能はPHP応答メッセージでソースと送付先アドレスの順序対を送信元ホストに返します、各組と共にどういう出口ルーティングを使用したらよいかしるしと共に。 また、PDN Addressなどのどんな追加情報も返します。 この情報で、送信元ホストは、現在、コミュニケーションを確立して、適切にPCMPメッセージに応じることができます。 PCMPメッセージから受け取られた情報に基づいて
Francis [Page 26] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[26ページ]RFC1621種
particularly PCMP Packet Not Delivered messages but also Mobile Host messages, the host is able to choose appropriately from the ordered list.
特にPCMP Packet Not Deliveredメッセージにもかかわらず、モバイルHostメッセージも、ホストは規則正しいリストから適切に選ぶことができます。
Note that if Pip evolves to the point where the Transit Part of the Pip header is no longer compatible with the current Transit Part, and the querying host has not been updated to understand the new Transit Part, then the PHP response message contains a bit map of the Transit Part. The host puts this bit map into the Transit Part of the transmitted Pip header even though it does not understand the semantics of the Transit Part. The Host Version field indicates to the Pip Header Server what kinds of transit parts the host can understand.
PipがPipヘッダーのTransit Partはもう現在のTransit Partと互換性がないポイントに発展して、新しいTransit Partを理解するために質問しているホストをアップデートしていないならPHP応答メッセージがTransit Partの地図を少し含むことに注意してください。 Transit Partの意味論を理解していませんが、ホストは伝えられたPipヘッダーのTransit Partにこのビットマップを入れます。 Hostバージョン分野は、ホストがどんな種類のトランジット部分を理解できるかをPip Header Serverに示します。
9.2 Pip Header Protocol (PHP)
9.2 種のヘッダープロトコル(PHP)
The Pip Header Protocol (PHP) is a simple query/response protocol used to exchange information between the Pip host and the Pip Header Server [6]. In the query, the Pip host includes (among other things) the domain name of the destination it wishes to send Pip packets to. (Thus, the PHP query serves as a substitute for the DNS query.)
Pip Headerプロトコル(PHP)はPipホストとPip Header Server[6]の間で情報交換するのに使用される簡単な質問/応答プロトコルです。 質問では、Pipホストは(特に)それがPipパケットを送りたがっている目的地のドメイン名を入れます。 (その結果、PHP質問はDNS質問のために代わりになります。)
The PHP query also contains 1) User Access Restriction Classes, 2) Application Types, and 3) host version. The host version tells the Pip Header Server what features are installed in the host. Thus, the Pip Header Server is able to determine if the host can format its own Pip header based on DNS information, or whether the Pip Header Server needs to do it on behalf of the host. In the future, the PHP query will also contain desired TOS (possibly in lieu of Application Type). (Note that this information could come from the application. Thus, the application interface to PHP (the equivalent of gethostbyname()) must pass this information.)
また、PHP質問は1を)含んでいます。 ユーザアクセス制限のクラス、2) アプリケーションTypes、および3) バージョンをホスティングしてください。 ホストバージョンは、どんな特徴がホストにインストールされるかをPip Header Serverに言います。 したがって、Pip Header Serverは、ホストがDNS情報に基づくそれ自身のPipヘッダーをフォーマットできるかどうか、またはPip Header Serverが、ホストを代表してそれをする必要であるかどうか決定できます。 また、将来、PHP質問は必要なTOS(ことによるとApplication Typeの代わりに)を含むでしょう。 (この情報がアプリケーションから来ることができたことに注意してください。 その結果、PHP(gethostbyname())の同等物はこの情報を通過しなければなりません。)へのアプリケーション・インターフェース
9.3 Application Interface
9.3 HTTPサーバとNETSCAPE間のインタフェース
In order for a Pip host to generate the information required in the PHP query, there must be a way for the application to convey the information to the PHP software. The host architecture for doing this is as follows.
PipホストがPHP質問で必要である情報を生成するように、アプリケーションがPHPソフトウェアに情報を伝える方法があるに違いありません。 これをするためのホストアーキテクチャは以下の通りです。
A local "Pip Header Client" (the source host analog to the Pip Header Server) is called by the application (instead of the current gethostbyname()). The application provides the Pip Header Client with either the destination host domain name or the destination host Pip ID, and other pertinent information such as user access restriction class and TOS. The Pip Header Client, if it doesn't have the information cached locally, queries the Pip Header Server and receives an answer. (Remember that the Pip Header Server can be co-
地方の「種のヘッダークライアント」(Pip Header Serverにアナログの送信元ホスト)はアプリケーションで呼ばれます。(現在のgethostbyname())の代わりに。 アプリケーションは目的地ホスト・ドメイン名かあて先ホストPip IDのどちらか、およびユーザアクセスの制限のクラスやTOSの他の適切な情報をPip Header Clientに提供します。 それで局所的に情報をキャッシュしないなら、Pip Header ClientはPip Header Serverについて質問して、答えを受けます。 (Pip Header Serverがそうであることができることを覚えていてください、共同
Francis [Page 27] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[27ページ]RFC1621種
resident with the host.)
ホストと共に居住しています。)
Once the Pip Header Client has determined what the Pip header(s) are, it assigns a local handle to the headers, returns the handle to the application, and configures the Pip packet processing engine with the handle and related Pip Headers. The application then issues packets to the Pip layer (via intervening layers such as transport) using the local handle.
Pip Header Clientが、Pipヘッダーが何であるかをいったん決定すると、それは、地方のハンドルをヘッダーに割り当てて、ハンドルをアプリケーションに返して、ハンドルと関連するPip HeadersでPipパケット処理エンジンを構成します。 そして、アプリケーションは、地方のハンドルを使用することでPip層(輸送などの層に介入することを通した)にパケットを発行します。
10. Routing Algorithms in Pip
10. 種のルーティング・アルゴリズム
This section discusses the routing algorithm for use with (hierarchical) Pip Addresses.
このセクションは(階層的)の種のAddressesに使用のためのルーティング・アルゴリズムを論じます。
The architecture for operating routing algorithms in Pip reflects the clean partitioning of routing contexts in the Pip header. Thus, routing in the Pip architecture is nicely modularized.
Pipの操作ルーティング・アルゴリズムのためのアーキテクチャはPipヘッダーのルーティング文脈の清潔な仕切りを反映します。 したがって、Pipアーキテクチャでのルーティングはうまくmodularizedされます。
Within the Hierarchical Pip Address, there are multiple hierarchical levels. Wherever two routers connect, or two levels interface (either in a single router or between routers), two decisions must be made: 1) what information should be exchanged (that is, what of one side's routing table should be propagated to the other side), and 2) what routing algorithm should be used to exchange the information? The first decision is discussed in section 10.1 below (Routing Information Filtering). The latter decision is discussed here.
Hierarchical Pip Addressの中に、複数の階層レベルがあります。 どこに2つのルータが接続する、または2つのレベルが連結しても(ただ一つのルータかルータの間で)、2つの決定をしなければなりません: 1) どんな情報を交換するべきであるか、そして、(すなわち、半面の経路指定テーブルの何が反対側に伝播されるべきですか)2は)どんなルーティングを交換するか。アルゴリズムは、情報を交換するのに使用されるべきですか? (経路情報Filtering)の下のセクション10.1で最初の決定について議論します。 ここで後者の決定について議論します。
Conceptually, and to a large extent in practice, the routing algorithms at each level are cleanly partitioned. This partition is much like the partition between "egp" and "igp" level routing in IP, but with Pip it exists at each level of the hierarchy.
概念的、および大体において習慣では、各レベルにおけるルーティング・アルゴリズムは清潔に仕切られます。 このパーティションはIPで"egp"と"igp"平らなルーティングの間のパーティションに似ていますが、Pipと共に、それは階層構造の各レベルで存在しています。
At the top-level of the Pip Address hierarchy, a path-vector routing algorithm is used. Path-vector is more appropriate at the top level than link-state because path-vector does not require agreement between top-level entities (providers) on metrics in order to be loop-free. (Agreement between the providers is likely to result in better paths, but the Pip Architecture does not assume such agreement.)
Pip Address階層構造のトップレベルでは、経路ベクトルルーティング・アルゴリズムは使用されています。 経路ベクトルが輪なしであるために測定基準でトップレベル実体(プロバイダー)の間の協定を必要としないので、経路ベクトルはリンク状態より先端で適切なレベルです。 (プロバイダーの間の協定は、より良い経路をもたらしそうですが、Pip Architectureはそのような協定を仮定しません。)
The top-level path-vector routing algorithm is based on IDRP, but enhanced to handle Pip addresses and Pip idiosyncrasies such as the Routing Context. At any level below the top level, it is a local decision as to what routing algorithm technology to run. However, the path-vector routing algorithm is generalized so that it can run at multiple levels of the Pip Address hierarchy. Thus, a lower level domain can choose to take advantage of the path-vector algorithm, or run another, such as a link-state algorithm. The modified version of
トップレベル経路ベクトルルーティング・アルゴリズムは、IDRPに基づいていますが、ルート設定ContextなどのPipアドレスとPip特異性を扱うために高められます。 トップレベルの下におけるどんなレベルにおいても、それはどんなルーティング・アルゴリズム技術を実行したらよいかに関するローカルの決定です。 しかしながら、経路ベクトルルーティング・アルゴリズムは、Pip Address階層構造の複数のレベルで稼働できるように広められます。 したがって、下のレベルドメインは、経路ベクトルアルゴリズムを利用するか、または別のものを実行するのを選ぶことができます、リンク州のアルゴリズムのように。 バージョンを変更します。
Francis [Page 28] RFC 1621 Pip Near-term Architecture May 1994
アーキテクチャ1994年5月の用語のフランシス[28ページ]RFC1621種
IDRP is called MLPV [10], for Multi-Level Path-Vector (pronounced "milpiv").
IDRPはMulti-レベルPath-ベクトル("milpiv"であると断言される)のためにMLPV[10]と呼ばれます。
Normally, information is exchanged between two separate routing algorithms by virtue of the two algorithms co-existing in the same router. For instance, a border router is likely to participate in an exchange of routing information with provider routers, and still run the routing algorithm of the internal routers. If the two algorithms are different routing technologies (for instance, link-state versus distance-vector) then internal conversion translates information from one routing algorithm to the form of the other.
通常、同じルータで共存している2つのアルゴリズムによって2つの別々のルーティング・アルゴリズムの間で情報を交換します。 例えば、境界ルータは、プロバイダールータがあるルーティング情報の交換に参加して、まだ内部のルータのルーティング・アルゴリズムを実行していそうです。 2つのアルゴリズムが異なるなら、ルーティング技術(例えば、距離ベクトルに従ったリンク状態)の当時の内部の変換は1つのルーティング・アルゴリズムからもう片方のフォームまで情報を翻訳します。
In some cases, however, two routing algorithms that exchange information will exist in different routers, and will have to exchange information over a link. If these two algorithms are different technologies, then they need a common means of exchanging routing information. While strictly speaking this is a local matter, MLPV can also serve as the interface between two disparate routing algorithms. Thus, all routers should be able to run MLPV, if for no other reason than to exchange information with other, perhaps proprietary, routing protocols.
いくつかの場合、しかしながら、情報交換する2つのルーティング・アルゴリズムが、異なったルータで存在して、リンクの上に情報交換しなければならないでしょう。 これらの2つのアルゴリズムが異なった技術であるなら、彼らはルーティング情報を交換する一般的な手段を必要とします。 これは厳密に言うと地域にかかわる事柄ですが、また、MLPVは2つの異種のルーティング・アルゴリズムの間のインタフェースとして機能できます。その結果、すべてのルータがMLPVを実行できるべきです、他のどんな理由でもそうしないなら他の、そして、恐らく独占であるルーティング・プロトコルで情報交換するより。
MLPV is designed to be extendible with regards to the type of routes that it calculates. It uses the Pip Object parameter identification number space to identify what type of route is being advertised and calculated [9]. Thus, to add new types of routes (for instance, new types of service), it is only necessary to configure the routers to accept the new route type, define metrics for that type, and criteria for preferring one route of that type over another.
MLPVは、あいさつでそれが計算するルートのタイプに拡張可能になるように設計されています。 それは、どんなタイプのルートが広告を出しているかを特定するのにPip Objectパラメタ識別番号スペースを使用して、[9]について計算しました。 したがって、単に新しいタイプのルート(例えば、新しいタイプのサービス)はそのタイプのために測定基準を定義して、その1つのルートを好むために評価基準を定義すると言い足すには、新しいルートタイプを受け入れるためにルータを構成するのが必要である別のものの上でタイプしてください。
10.1 Routing Information Filtering
10.1 経路情報フィルタリング
Of course, the main point behind having hierarchical routing is so that information from one part of the hierarchy can be reduced when passed to another. In general, reduction (in the form of aggregation) takes place when passing information from the bottom of the hierarchy up. However, Pip uses tunneling and exit routing to, if desired, allow information from the top to be reduced when it goes down.
もちろん、階層型ルーティングを持っている後ろの要点はしたがって、別のものに通過されると階層構造の一部からのその情報を減らすことができるということです。 階層構造の下部より上に情報を移るとき、一般に、減少(集合の形の)は起こります。 しかしながら、落ちるとき、Pipは、望まれているなら先端からの情報が減らされるのを許容するのにトンネリングと出口ルーティングを使用します。
When two routers become neighbors, they can determine what hierarchical levels they have in common by comparing Pip Addresses. For instance, if two neighbor routers have Pip Addresses 1.2.3,4 and 1.2.8,9.14 respectively, then they share levels 0 and 1, and are different at levels below that. (0 is the highest level, 1 is the next highest, and so on.) As a general rule, these two routers exchange level 0, level 1, and level 2 routing information, but not level 3 or lower routing information. In other words, both routers
2つのルータが隣人になると、彼らは、それらがPip Addressesを比較することによってどんな階層レベルが共通であるかを決定できます。 そして、例えば、2つの隣人ルータであるならPip Addressesを持ってください、1.2、.3、4、1.2 .8 9.14 それぞれ、次に、彼らは、レベル0と1を共有して、それの下のレベルにおいて異なっています。 (0が最高水準である、1は最も高くて、とてもオンな次です。) 概して、これらの2つのルータが、レベル3ではなく、情報を発送しながらレベル0、レベル1、およびレベル2を交換するか、またはルーティング情報を下ろします。 言い換えれば、両方のルータ
一覧
スポンサーリンク
