Network Working Group A. Barbir
Request for Comments: 3568 Nortel Networks
Category: Informational B. Cain
Storigen Systems
R. Nair
Consultant
O. Spatscheck
AT&T
July 2003
Known Content Network (CN) Request-Routing Mechanisms
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or before December 2000. In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layer Request-Routing, and Application-layer Request-Routing.
この文書では、さまざまなポリシーやメトリクスの可能なセットに基づいて、サロゲートへの直接のクライアントの要求に使用されているリクエスト・ルーティング技術の概要を示します。文書は、一般的にこのメモでは2000年12月日以前に業界で使用された技術をカバーし、用語のRequest-ルーティングは、一般的にコンテンツルーティング、またはコンテンツのリダイレクトと呼ばれる技術を表しています。 DNSリクエスト・ルーティング、トランスポート・レイヤ・リクエスト・ルーティング、およびアプリケーション層の要求-ルーティング：原則として、リクエスト・ルーティング技術は、下に分類することができます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. DNS based Request-Routing Mechanisms . . . . . . . . . . . . 3
2.1. Single Reply . . . . . . . . . . . . . . . . . . . . . 3
2.2. Multiple Replies . . . . . . . . . . . . . . . . . . . 3
2.3. Multi-Level Resolution . . . . . . . . . . . . . . . . 4
2.3.1. NS Redirection . . . . . . . . . . . . . . . . 4
2.3.2. CNAME Redirection. . . . . . . . . . . . . . . 5
2.4. Anycast. . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Object Encoding. . . . . . . . . . . . . . . . . . . . 6
2.6. DNS Request-Routing Limitations. . . . . . . . . . . . 6
3. Transport-Layer Request-Routing . . . . . . . . . . . . . . 7
4. Application-Layer Request-Routing . . . . . . . . . . . . . 8
4.1. Header Inspection. . . . . . . . . . . . . . . . . . . 8
4.1.1. URL-Based Request-Routing. . . . . . . . . . . 8
4.1.2. Header-Based Request-Routing . . . . . . . . . 9
4.1.3. Site-Specific Identifiers. . . . . . . . . . .10
4.2. Content Modification . . . . . . . . . . . . . . . . .10
4.2.1. A-priori URL Rewriting . . . . . . . . . . . .11
4.2.2. On-Demand URL Rewriting. . . . . . . . . . . .11
4.2.3. Content Modification Limitations . . . . . . .11
5. Combination of Multiple Mechanisms . . . . . . . . . . . . .11
6. Security Considerations . . . . . . . . . . . . . . . . . .12
7. Additional Authors and Acknowledgements . . . . . . . . . .12
A. Measurements . . . . . . . . . . . . . . . . . . . . . . . .13
A.1. Proximity Measurements . . . . . . . . . . . . . . . .13
A.1.1. Active Probing . . . . . . . . . . . . . . . .13
A.1.2. Metric Types . . . . . . . . . . . . . . . . .14
A.1.3. Surrogate Feedback . . . . . . . . . . . . . .14
8. Normative References . . . . . . . . . . . . . . . . . . . .15
9. Informative References . . . . . . . . . . . . . . . . . . .15
10. Intellectual Property and Copyright Statements . . . . . . .17
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . .18
12. Full Copyright Statement . . . . . . . . . . . . . . . . . .19
This document provides a summary of known request routing techniques that are used by the industry before December 2000. Request routing techniques are generally used to direct client requests to surrogates based on various policies and a possible set of metrics. The task of directing clients' requests to surrogates is also called Request-Routing, Content Routing or Content Redirection.
この文書では、一般的に、様々な政策やメトリクスの可能なセットに基づいて代理し、直接クライアントの要求に使用されている2000年12月のリクエストルーティング技術の前に業界で使用される既知の要求ルーティング技術の概要を提供します。サロゲートにクライアントの要求を向けるのタスクは、リクエスト・ルーティング、コンテンツルーティングやコンテンツリダイレクトと呼ばれています。
Request-Routing techniques are commonly used in Content Networks (also known as Content Delivery Networks) [8]. Content Networks include network infrastructure that exists in layers 4 through 7. Content Networks deal with the routing and forwarding of requests and responses for content. Content Networks rely on layer 7 protocols such as HTTP [4] for transport.
リクエストルーティング技術は、一般に（また、コンテンツ配信ネットワークとしても知られている）コンテンツネットワークで使用されている[8]。コンテンツネットワークは、コンテンツの要求と応答のルーティングおよび転送と層4~7を介してコンテンツネットワークの契約に存在するネットワークインフラストラクチャを含みます。コンテンツネットワークは層の上に、このようなHTTP [4]輸送用として7つのプロトコルを利用しています。
Request-Routing techniques are generally used to direct client requests for objects to a surrogate or a set of surrogates that could best serve that content. Request-Routing mechanisms could be used to direct client requests to surrogates that are within a Content Network (CN) [8].
リクエスト・ルーティング技術は、一般的に代理または最善そのコンテンツを提供することができサロゲートのセットにオブジェクトに対する直接のクライアントの要求に使用されています。リクエスト・ルーティングメカニズムは、[8]コンテンツネットワーク（CN）内にあるサロゲートへの直接のクライアントの要求に使用することができます。
Request-Routing techniques are used as a vehicle to extend the reach and scale of Content Delivery Networks. There exist multiple Request-Routing mechanisms. At a high-level, these may be classified under: DNS Request-Routing, transport-layer Request-Routing, and application-layer Request-Routing.
リクエストのルーティング技術は、コンテンツ配信ネットワークのリーチと規模を拡張するための車両として使用されています。複数のリクエスト・ルーティングメカニズムが存在します。 DNS要求のルーティング、トランスポート層リクエストルーティング、およびアプリケーション層リクエストルーティング：高レベルでは、これらは下に分類することができます。
A request routing system uses a set of metrics in an attempt to direct users to surrogate that can best serve the request. For example, the choice of the surrogate could be based on network proximity, bandwidth availability, surrogate load and availability of content. Appendix A provides a summary of metrics and measurement techniques that could be used in the selection of the best surrogate.
リクエストルーティングシステムは、それが最善の要求に応じることができ代理する直接ユーザーへの試みで、メトリックのセットを使用しています。たとえば、サロゲートの選択は、ネットワークプロキシミティ、帯域幅の可用性、代理負荷およびコンテンツの利用可能性に基づくことができます。付録Aは、最高のサロゲートの選択に使用することができメトリクスと測定技術の概要を提供します。
The memo is organized as follows: Section 2 provides a summary of known DNS based Request-Routing techniques. Section 3 discusses transport-layer Request-Routing methods. In section 4 application layer Request-Routing mechanisms are explored. Section 5 provides insight on combining the various methods that were discussed in the earlier sections in order to optimize the performance of the Request-Routing System. Appendix A provides a summary of possible metrics and measurements techniques that could be used by the Request-Routing system to choose a given surrogate.
次のようにメモが編成されている：第2節では知られているDNSベースのリクエスト・ルーティング技術の概要を提供します。第3節では、トランスポート・レイヤ・リクエスト・ルーティング方法について説明します。セクション4アプリケーション層リクエスト・ルーティングメカニズムが探求されています。セクション5は、Request-ルーティングシステムの性能を最適化するために、以前のセクションで説明した様々な方法を組み合わせることについての洞察を提供します。付録Aは、所与の代理を選択するリクエスト・ルーティングシステムによって使用することができる可能メトリックおよび測定技術の概要を提供します。
DNS based Request-Routing techniques are common due to the ubiquity of the DNS system [10][12][13]. In DNS based Request-Routing techniques, a specialized DNS server is inserted in the DNS resolution process. The server is capable of returning a different set of A, NS or CNAME records based on user defined policies, metrics, or a combination of both. In [11] RFC 2782 (DNS SRV) provides guidance on the use of DNS for load balancing. The RFC describes some of the limitations and suggests appropriate useage of DNS based techniques. The next sections provides a summary of some of the used techniques.
DNSベースのリクエストルーティング技術が原因DNSシステム[10] [12] [13]の普及に共通です。 DNSベースのリクエストルーティング技術では、特殊なDNSサーバは、DNS解決プロセスに挿入されます。サーバは、ユーザ定義のポリシー、メトリック、またはその両方の組み合わせに基づいて、A、NSまたはCNAMEレコードの異なるセットを返すことが可能です。 [11] RFC 2782（DNSのSRV）でロードバランシングのためのDNSの使用に関するガイダンスを提供します。 RFCは、制限のいくつかを説明し、DNSベースの技術の適切なuseageを示唆しています。次のセクションでは、使用される技術のいくつかの要約を提供します。
In this approach, the DNS server is authoritative for the entire DNS domain or a sub domain. The DNS server returns the IP address of the best surrogate in an A record to the requesting DNS server. The IP address of the surrogate could also be a virtual IP(VIP) address of the best set of surrogates for requesting DNS server.
このアプローチでは、DNSサーバーは、全体のDNSドメインまたはサブドメインの権威です。 DNSサーバは、要求元のDNSサーバーにAレコードで最高の代理のIPアドレスを返します。代理のIPアドレスもDNSサーバーを要求するためのサロゲートの最良のセットの仮想IP（VIP）アドレスである可能性があります。
In this approach, the Request-Routing DNS server returns multiple replies such as several A records for various surrogates. Common implementations of client site DNS server's cycles through the multiple replies in a Round-Robin fashion. The order in which the records are returned can be used to direct multiple clients using a single client site DNS server.
このアプローチでは、要求ルーティングDNSサーバは、様々な代理のためのいくつかのAレコードとして、複数の応答を返します。ラウンドロビン方式で複数の応答を介してクライアントサイトのDNSサーバーのサイクルの一般的な実装。レコードが返される順序は、単一のクライアントサイトのDNSサーバーを使用して複数のクライアントを指示するために使用することができます。
In this approach multiple Request-Routing DNS servers can be involved in a single DNS resolution. The rationale of utilizing multiple Request-Routing DNS servers in a single DNS resolution is to allow one to distribute more complex decisions from a single server to multiple, more specialized, Request-Routing DNS servers. The most common mechanisms used to insert multiple Request-Routing DNS servers in a single DNS resolution is the use of NS and CNAME records. An example would be the case where a higher level DNS server operates within a territory, directing the DNS lookup to a more specific DNS server within that territory to provide a more accurate resolution.
このアプローチでは、複数のリクエスト・ルーティングDNSサーバーは、単一のDNS解決に関与することができます。単一のDNS解決に複数のRequest-ルーティングDNSサーバを利用する根拠は1つが、複数の、より特化した、リクエスト・ルーティングのDNSサーバーを単一のサーバーから、より複雑な意思決定を配布できるようにすることです。単一のDNS解決に複数のRequest-ルーティングDNSサーバを挿入するために使用される最も一般的なメカニズムは、NSレコードとCNAMEレコードの使用です。例では、より高いレベルのDNSサーバは、より正確な解像度を提供するために、その地域内のより具体的なDNSサーバにDNSルックアップを導く、領域内で動作する場合です。
A DNS server can use NS records to redirect the authority of the next level domain to another Request-Routing DNS server. The, technique allows multiple DNS server to be involved in the name resolution process. For example, a client site DNS server resolving a.b.example.com [10] would eventually request a resolution of a.b.example.com from the name server authoritative for example.com. The name server authoritative for this domain might be a Request-Routing NS server. In this case the Request-Routing DNS server can either return a set of A records or can redirect the resolution of the request a.b.example.com to the DNS server that is authoritative for example.com using NS records.
DNSサーバは別の要求-ルーティングDNSサーバーに次のレベルのドメインの権限をリダイレクトするためにNSレコードを使用することができます。 、この技術は、複数のDNSサーバが名前解決プロセスに関与することができます。例えば、クライアントサイトのDNSサーバーはa.b.example.comを解決する[10]最終的にexample.comの権威ネームサーバからa.b.example.comの解像度を要求します。このドメインの権威ネームサーバは、Request-ルーティングNSサーバーかもしれません。この場合、リクエスト・ルーティングDNSサーバはレコードのセットを返すことができるいずれかまたはNSレコードを使用して、example.comに対して権限のあるDNSサーバに要求a.b.example.comの解像度をリダイレクトすることができます。
One drawback of using NS records is that the number of Request-Routing DNS servers are limited by the number of parts in the DNS name. This problem results from DNS policy that causes a client site DNS server to abandon a request if no additional parts of the DNS name are resolved in an exchange with an authoritative DNS server.
NSレコードを使用しての欠点の1つは、Request-ルーティングDNSサーバーの数がDNS名に部品の数によって制限されていることです。この問題は、DNS名の追加の部品が権威DNSサーバとのやり取りで解決されていない場合は、クライアントサイトのDNSサーバが要求を放棄する原因となるDNS政策に起因します。
A second drawback is that the last DNS server can determine the TTL of the entire resolution process. Basically, the last DNS server can return in the authoritative section of its response its own NS record. The client will use this cached NS record for further request resolutions until it expires.
第二の欠点は、最後のDNSサーバが全体解決プロセスのTTLを決定することができるということです。基本的には、最後のDNSサーバは、その応答、独自のNSレコードの権威セクションに戻ることができます。期限が切れるまで、クライアントはさらに要求決議のために、このキャッシュされたNSレコードを使用します。
Another drawback is that some implementations of bind voluntarily cause timeouts to simplify their implementation in cases in which a NS level redirect points to a name server for which no valid A record is returned or cached. This is especially a problem if the domain of the name server does not match the domain currently resolved, since in this case the A records, which might be passed in the DNS response, are discarded for security reasons. Another drawback is the added delay in resolving the request due to the use of multiple DNS servers.
別の欠点は、バインドのいくつかの実装が自発的にタイムアウトがNSレベルが有効なレコードが返されないか、キャッシュに書き込まれているネームサーバにポイントをリダイレクトする場合には、その実装を簡素化する原因となるということです。この場合には、DNS応答で渡されるかもしれないAレコードは、セキュリティ上の理由で破棄されるので、ネームサーバのドメインが、現在解決ドメインと一致しない場合、これは特に問題です。別の欠点は、複数のDNSサーバーを使用しているため、要求の解決に追加遅延です。
In this scenario, the Request-Routing DNS server returns a CNAME record to direct resolution to an entirely new domain. In principle, the new domain might employ a new set of Request-Routing DNS servers.
このシナリオでは、リクエスト・ルーティングDNSサーバーは完全に新しいドメインへの直接の解像度にCNAMEレコードを返します。原則的には、新しいドメインは、Request-ルーティングDNSサーバの新しいセットを採用するかもしれません。
One disadvantage of this approach is the additional overhead of resolving the new domain name. The main advantage of this approach is that the number of Request-Routing DNS servers is independent of the format of the domain name.
このアプローチの一つの欠点は、新しいドメイン名を解決する追加のオーバーヘッドです。このアプローチの主な利点は、Request-ルーティングDNSサーバの数は、ドメイン名の形式に依存しないことです。
Anycast [5] is an inter-network service that is applicable to networking situations where a host, application, or user wishes to locate a host which supports a particular service but, if several servers utilizes the service, it does not particularly care which server is used. In an anycast service, a host transmits a datagram to an anycast address and the inter-network is responsible for providing best effort delivery of the datagram to at least one, and preferably only one, of the servers that accept datagrams for the anycast address.
エニーキャストは、[5]ホスト、アプリケーション、またはユーザーが特定のサービスをサポートするホストを見つけるしたいネットワークの状況に適用されますが、複数のサーバがサービスを利用した場合、それは特にどのサーバーを気にしない間のネットワークサービスです使用されている。エニーキャストサービスでは、ホストは、エニーキャストアドレスにデータグラムを送信し、ネットワーク間は、少なくとも1つ、エニーキャストアドレスのためのデータグラムを受け入れるサーバの好ましくは一つだけ、にデータグラムのベストエフォートを提供する責任があります。
The motivation for anycast is that it considerably simplifies the task of finding an appropriate server. For example, users, instead of consulting a list of servers and choosing the closest one, could simply type the name of the server and be connected to the nearest one. By using anycast, DNS resolvers would no longer have to be configured with the IP addresses of their servers, but rather could send a query to a well-known DNS anycast address.
エニーキャストのための動機は、それはかなり適切なサーバーを見つける作業を簡素化することです。たとえば、ユーザーは、代わりにサーバのリストをコンサルティングし、最も近いものを選択するのは、単にサーバーの名前を入力でき、最寄りの一つに接続すること。エニーキャストを使用することにより、DNSリゾルバは、もはや自分のサーバのIPアドレスを設定する必要がないだろうが、むしろ、よく知られているDNSのエニーキャストアドレスにクエリを送信することができます。
Furthermore, to combine measurement and redirection, the Request-Routing DNS server can advertise an anycast address as its IP address. The same address is used by multiple physical DNS servers. In this scenario, the Request-Routing DNS server that is the closest to the client site DNS server in terms of OSPF and BGP routing will receive the packet containing the DNS resolution request. The server can use this information to make a Request-Routing decision.
さらに、計測およびリダイレクトを組み合わせることが、リクエスト・ルーティングDNSサーバーは、そのIPアドレスとしてエニーキャストアドレスを広告することができます。同じアドレスが複数の物理DNSサーバーで使用されます。このシナリオでは、OSPFやBGPルーティングの観点からクライアントサイトのDNSサーバーに最も近いリクエスト・ルーティングのDNSサーバは、DNS解決要求を含むパケットを受信します。サーバーは、Request-ルーティング決定を行うために、この情報を使用することができます。
Drawbacks of this approach are listed below:
このアプローチの欠点は次のとおりです。
o The DNS server may not be the closest server in terms of routing to the client.
O DNSサーバーは、クライアントへのルーティングの観点から最も近いサーバーではないかもしれません。
o Typically, routing protocols are not load sensitive. Hence, the closest server may not be the one with the least network latency.
O典型的には、ルーティングプロトコルが敏感にロードされていません。したがって、最も近いサーバは、少なくともネットワークの待ち時間を有するものでなくてもよいです。
o The server load is not considered during the Request-Routing process.
Oサーバーの負荷が要求-ルーティングプロセスの間に考慮されていません。
Since only DNS names are visible during the DNS Request-Routing, some solutions encode the object type, object hash, or similar information into the DNS name. This might vary from a simple division of objects based on object type (such as images.a.b.example.com and streaming.a.b.example.com) to a sophisticated schema in which the domain name contains a unique identifier (such as a hash) of the object. The obvious advantage is that object information is available at resolution time. The disadvantage is that the client site DNS server has to perform multiple resolutions to retrieve a single Web page, which might increase rather than decrease the overall latency.
唯一のDNS名がDNS要求ルーティング中に表示されているので、いくつかのソリューションは、DNS名にオブジェクトタイプ、オブジェクトのハッシュ、または類似の情報を符号化します。これは、ドメイン名（例えば、ハッシュのような）一意の識別子が含まれている洗練されたスキーマに（例えばimages.abexample.comとstreaming.abexample.comなど）オブジェクト・タイプに基づいて、オブジェクトの単純な分割によって異なるかもしれませんオブジェクト。明らかな利点は、オブジェクト情報は解像度の時点で利用可能であるということです。欠点は、クライアントサイトのDNSサーバが増えるのではなく全体的な待ち時間を減らすかもしれない単一のWebページを取得するために複数の解像度を実行しなければならないことです。
This section lists some of the limitations of DNS based Request-Routing techniques.
このセクションでは、DNSベースのリクエスト・ルーティング技術のいくつかの制限を示しています。
o DNS only allows resolution at the domain level. However, an ideal request resolution system should service requests per object level.
O DNSはドメインレベルでのみ解決することができます。しかし、理想的な要求解決システムは、オブジェクトレベルごとの要求にサービスを提供すべきです。
o In DNS based Request-Routing systems servers may be required to return DNS entries with a short time-to-live (TTL) values. This may be needed in order to be able to react quickly in the face of outages. This in return may increase the volume of requests to DNS servers.
O DNSベースのリクエスト・ルーティング・システムのサーバは、短い生存時間（TTL）値を使用してDNSエントリを返すために必要とされ得ます。これは、機能停止の顔に素早く反応できるようにするために必要な場合があります。これは、見返りにDNSサーバへの要求の量を増加させることができます。
o Some DNS implementations do not always adhere to DNS standards. For example, many DNS implementations do not honor the DNS TTL field.
O一部のDNS実装は常にDNS標準に準拠していません。例えば、多くのDNS実装は、DNSのTTLフィールドを尊重していません。
o DNS Request-Routing is based only on knowledge of the client DNS server, as client addresses are not relayed within DNS requests. This limits the ability of the Request-Routing system to determine a client's proximity to the surrogate.
クライアントのアドレスがDNS要求内に中継されていないとして、OのDNSリクエスト・ルーティングは、クライアントのみのDNSサーバーの知識に基づいています。これは、サロゲートに、クライアントの近接性を決定するために要求 - ルーティングシステムの能力を制限します。
o DNS servers can request and allow recursive resolution of DNS names. For recursive resolution of requests, the Request-Routing DNS server will not be exposed to the IP address of the client's site DNS server. In this case, the Request-Routing DNS server will be exposed to the address of the DNS server that is recursively requesting the information on behalf of the client's site DNS server. For example, imgs.example.com might be resolved by a CN, but the request for the resolution might come from dns1.example.com as a result of the recursion.
O DNSサーバは、DNS名の再帰的解決を要求し、許可することができます。リクエストの再帰的な解決のために、リクエスト・ルーティングのDNSサーバは、クライアントのサイトのDNSサーバーのIPアドレスにさらされることはありません。この場合、リクエスト・ルーティングDNSサーバーは、再帰的にクライアントのサイトのDNSサーバーに代わって情報を要求しているDNSサーバーのアドレスにさらされることになります。例えば、imgs.example.comはCNによって解決されるかもしれないが、解像度の要求は、再帰の結果としてdns1.example.comから来るかもしれません。
o Users that share a single client site DNS server will be redirected to the same set of IP addresses during the TTL interval. This might lead to overloading of the surrogate during a flash crowd.
O単一のクライアントサイトのDNSサーバーを共有するユーザーは、TTL間隔の間にIPアドレスの同じセットにリダイレクトされます。これは、フラッシュ群衆の間に代理の過負荷につながる可能性があります。
o Some implementations of bind can cause DNS timeouts to occur while handling exceptional situations. For example, timeouts can occur for NS redirections to unknown domains.
Oバインドの実装によっては、例外的な状況の処理中にDNSタイムアウトが発生する可能性があります。たとえば、タイムアウトが未知のドメインへのNSリダイレクトのために発生する可能性があります。
DNS based request routing techniques can suffer from serious limitations. For example, the use of such techniques can overburden third party DNS servers, which should not be allowed [19]. In [11] RFC 2782 provides warnings on the use of DNS for load balancing. Readers are encouraged to read the RFC for better understanding of the limitations.
DNSベースのリクエストのルーティング技術は、重大な制限を受けることができます。例えば、そのような技術の使用は[19]許されるべきではないサードパーティのDNSサーバーを過負荷することができます。 [11]にRFC 2782は、ロードバランシングのためのDNSの使用に関する警告を提供します。読者は限界をより良く理解するためにRFCを読むことをお勧めします。
At the transport-layer finer levels of granularity can be achieved by the close inspection of client's requests. In this approach, the Request-Routing system inspects the information available in the first packet of the client's request to make surrogate selection decisions. The inspection of the client's requests provides data about the client's IP address, port information, and layer 4 protocol. The acquired data could be used in combination with user-defined policies and other metrics to determine the selection of a surrogate that is better suited to serve the request. The techniques [20][18][15] are used to hand off the session to a more appropriate surrogate are beyond the scope of this document.
トランスポート層では粒度の細かいレベルは、クライアントの要求を精査することによって達成することができます。このアプローチでは、リクエスト・ルーティング・システムは、サロゲートの選択の決定を行うために、クライアントの要求の最初のパケットで利用可能な情報を検査します。クライアントの要求の検査は、クライアントのIPアドレス、ポート情報、およびレイヤ4プロトコルに関するデータを提供します。取得されたデータは、要求にサービスを提供するために適している代理の選択を決定するために、ユーザ定義のポリシーおよび他の指標と組み合わせて使用することができます。 [20] [18] [15]は、より適切な代用にセッションをハンドオフするために使用される技術は、本文書の範囲を超えています。
In general, the forward-flow traffic (client to newly selected surrogate) will flow through the surrogate originally chosen by DNS. The reverse-flow (surrogate to client) traffic, which normally transfers much more data than the forward flow, would typically take the direct path.
一般的には、前進流のトラフィック（新しく選択されたサロゲートのクライアント）は、もともとDNSによって選ばれた代理流れます。逆流通常、順流よりはるかに多くのデータを転送するトラフィック、（クライアントへの代理）は、典型的には、直接パスを取るだろう。
The overhead associated with transport-layer Request-Routing [21][19] is better suited for long-lived sessions such as FTP [1] and RTSP [3]. However, it also could be used to direct clients away from overloaded surrogates.
トランスポート層リクエストルーティング[21] [19]に関連するオーバーヘッドは、FTPのような長命セッションのために適している[1]及びRTSP [3]。しかし、また離れて過負荷にサロゲートからクライアントを指示するために使用することができます。
In general, transport-layer Request-Routing can be combined with DNS based techniques. As stated earlier, DNS based methods resolve clients requests based on domains or sub domains with exposure to the client's DNS server IP address. Hence, the DNS based methods could be used as a first step in deciding on an appropriate surrogate with more accurate refinement made by the transport-layer Request-Routing system.
一般に、トランスポート層リクエストルーティングは、DNSベースの技術と組み合わせることができます。先に述べたように、DNSベースの方法は、クライアントのDNSサーバーのIPアドレスへの曝露とのドメインやサブドメインに基づいてクライアント要求を解決します。したがって、DNSベースの方法は、トランスポート層リクエスト・ルーティング・システムによって行われたより正確な洗練された適切な代用物を決定するための最初のステップとして使用することができます。
Application-layer Request-Routing systems perform deeper examination of client's packets beyond the transport layer header. Deeper examination of client's packets provides fine-grained Request-Routing control down to the level of individual objects. The process could be performed in real time at the time of the object request. The exposure to the client's IP address combined with the fine-grained knowledge of the requested objects enable application-layer Request-Routing systems to provide better control over the selection of the best surrogate.
アプリケーション層の要求 - ルーティングシステムは、トランスポート層ヘッダを越えて、クライアントのパケットのより深い検討を行います。クライアントのパケットのより深い検査はダウン個々のオブジェクトのレベルまできめ細かいリクエスト・ルーティング制御を提供します。プロセスは、オブジェクト要求の時点でリアルタイムに実行することができます。要求されたオブジェクトの細かな知識と組み合わせて、クライアントのIPアドレスへの暴露は、最高のサロゲートの選択をよりよく制御を提供するために、アプリケーション層の要求 - ルーティングシステムを有効にします。
Some application level protocols such as HTTP [4], RTSP [3], and SSL [2] provide hints in the initial portion of the session about how the client request must be directed. These hints may come from the URL of the content or other parts of the MIME request header such as Cookies.
いくつかのアプリケーションレベルのHTTPなどのプロトコル[4]、RTSP [3]、及びSSL [2]クライアント要求が指示されなければならない方法についてのセッションの最初の部分にヒントを提供します。これらのヒントは、クッキーなどMIME要求ヘッダーのコンテンツまたは他の部分のURLから来るかもしれません。
Application level protocols such as HTTP and RTSP describe the requested content by its URL [6]. In many cases, this information is sufficient to disambiguate the content and suitably direct the request. In most cases, it may be sufficient to make Request-Routing decision just by examining the prefix or suffix of the URL.
例えばHTTP及びRTSPなどのアプリケーションレベルのプロトコルは、そのURLによって要求されたコンテンツを記述する[6]。多くの場合、この情報は、コンテンツを明確にし、適切に要求を指示するのに十分です。ほとんどの場合、それだけでURLの接頭辞や接尾辞を調べることによって、リクエスト・ルーティングの決定を行うのに十分であり得ます。
In this approach, the client's request is first resolved to a virtual surrogate. Consequently, the surrogate returns an application-specific code such as the 302 (in the case of HTTP [4] or RTSP [3]) to redirect the client to the actual delivery node.
このアプローチでは、クライアントの要求は、最初の仮想代理に解決されます。したがって、サロゲートは（[4]またはRTSP [3] HTTPの場合）実際の配信ノードにクライアントをリダイレクトするために302のようなアプリケーション固有のコードを返します。
This technique is relatively simple to implement. However, the main drawback of this method is the additional latency involved in sending the redirect message back to the client.
この技術は、実装が比較的簡単です。しかし、この方法の主な欠点は、クライアントにリダイレクトメッセージを送信するに関与し、追加のレイテンシがあります。
In this technique, an In-Path element is present in the network in the forwarding path of the client's request. The In-Path element provides transparent interception of the transport connection. The In-Path element examines the client's content requests and performs Request-Routing decisions.
この技術では、インパス要素は、クライアントの要求の転送パス内のネットワークに存在しています。では-Path要素は、トランスポート接続の透過代行を提供します。では-Path要素は、クライアントのコンテンツ要求を調べ、リクエスト・ルーティングの決定を行います。
The In-Path element then splices the client connection to a connection with the appropriate delivery node and passes along the content request. In general, the return path would go through the In-Path element. However, it is possible to arrange for a direct return by passing the address translation information to the surrogate or delivery node through some proprietary means.
インPath要素は、次いで、適切な送達ノードとの接続へのクライアント接続をスプライスし、コンテンツ要求に沿って通過します。一般に、リターンパスは、In-Path要素を通過するでしょう。しかし、いくつかの独自の手段で代理または配信ノードにアドレス変換情報を渡すことによって、直接のリターンのために配置することが可能です。
The primary disadvantage with this method is the performance implications of URL-parsing in the path of the network traffic. However, it is generally the case that the return traffic is much larger than the forward traffic.
この方法の主な欠点は、ネットワークトラフィックのパスでURL構文解析のパフォーマンスへの影響です。しかし、それはリターントラフィックが前方のトラフィックよりもはるかに大きい場合は、一般的です。
The technique allows for the possibility of partitioning the traffic among a set of delivery nodes by content objects identified by URLs. This allows object-specific control of server loading. For example, requests for non-cacheable object types may be directed away from a cache.
技術は、URLによって識別されるコンテンツオブジェクトによる送達ノードのセット間でトラフィックを分割する可能性を可能にします。これは、サーバーの負荷のオブジェクト固有の制御が可能になります。例えば、非キャッシュ可能オブジェクトタイプの要求はキャッシュから離れて向けられてもよいです。
This technique involves the task of using HTTP [4] such as Cookie, Language, and User-Agent, in order to select a surrogate. In [20] some examples of using this technique are provided.
この技術は、サロゲートを選択するために、そのようなクッキー、言語、およびユーザエージェントとして[4] HTTPを使用しての作業を含みます。この技術を使用する[20]いくつかの実施例において提供されます。
Cookies can be used to identify a customer or session by a web site. Cookie based Request-Routing provides content service differentiation based on the client. This approach works provided that the cookies belong to the client. In addition, it is possible to direct a connection from a multi-session transaction to the same server to achieve session-level persistence.
クッキーは、ウェブサイトによって顧客やセッションを識別するために使用することができます。クッキーベースのリクエスト・ルーティングは、クライアントに基づくコンテンツサービスの差別化を提供します。このアプローチの作品はクッキーをクライアントに属していることを条件とします。また、セッションレベルの持続性を達成するために、同じサーバーにマルチセッショントランザクションからの接続を指示することが可能です。
The language header can be used to direct traffic to a language-specific delivery node. The user-agent header helps identify the type of client device. For example, a voice-browser, PDA, or cell phone can indicate the type of delivery node that has content specialized to handle the content request.
言語ヘッダは、言語固有の配信ノードへトラフィックを導くために使用することができます。 User-Agentヘッダは、クライアントデバイスのタイプを識別するのに役立ちます。例えば、音声ブラウザ、PDA、または携帯電話は、コンテンツがコンテンツ要求を処理するために特化した送達ノードのタイプを示すことができます。
Site-specific identifiers help authenticate and identify a session from a specific user. This information may be used to direct a content request.
サイト固有の識別子は、特定のユーザーからのセッションを認証し、識別するのに役立ちます。この情報は、コンテンツ要求を指示するために使用することができます。
An example of a site-specific identifier is the SSL Session Identifier. This identifier is generated by a web server and used by the web client in succeeding sessions to identify itself and avoid an entire security authentication exchange. In order to inspect the session identifier, an In-Path element would observe the responses of the web server and determine the session identifier which is then used to associate the session to a specific server. The remaining sessions are directed based on the stored session identifier.
サイト固有の識別子の例は、SSLセッション識別子です。この識別子は、Webサーバによって生成され、それ自体を識別し、全体のセキュリティ認証交換を避けるために、セッションを、後続のWebクライアントによって使用されます。セッション識別子を検査するために、インPath要素は、Webサーバの応答を観察した後、特定のサーバへのセッションを関連付けるために使用されるセッション識別子を決定するであろう。残りのセッションは、記憶されたセッション識別子に基づいて導かれます。
This technique enables a content provider to take direct control over Request-Routing decisions without the need for specific witching devices or directory services in the path between the client and the origin server. Basically, a content provider can directly communicate to the client the best surrogate that can serve the request. Decisions about the best surrogate can be made on a per-object basis or it can depend on a set of metrics. The overall goal is to improve scalability and the performance for delivering the modified content, including all embedded objects.
この技術は、クライアントとオリジンサーバ間のパス内の特定のwitchingデバイスまたはディレクトリサービスを必要とせずにリクエスト・ルーティングの決定を直接制御を取るために、コンテンツプロバイダを可能にします。基本的には、コンテンツプロバイダは、クライアントに直接リクエストを果たすことができる最高のサロゲートを通信することができます。最高の代理に関する決定は、オブジェクトごとに行うことができるか、それは、メトリックのセットに依存することができます。全体的な目標は、スケーラビリティとすべての埋め込みオブジェクトを含む変更されたコンテンツを、提供するためのパフォーマンスを改善することです。
In general, the method takes advantage of content objects that consist of basic structure that includes references to additional, embedded objects. For example, most web pages, consist of an HTML document that contains plain text together with some embedded objects, such as GIF or JPEG images. The embedded objects are referenced using embedded HTML directives. In general, embedded HTML directives direct the client to retrieve the embedded objects from the origin server. A content provider can now modify references to embedded objects such that they could be fetched from the best surrogate. This technique is also known as URL rewriting.
一般に、この方法は、追加の、埋め込まれたオブジェクトへの参照を含む基本的な構造から成りコンテンツオブジェクトを利用します。たとえば、ほとんどのWebページは、GIFやJPEG画像などの一部の埋め込みオブジェクト、一緒にプレーンテキストを含むHTML文書で構成されています。埋め込みオブジェクトは、埋め込まれたHTMLディレクティブを使用して参照されています。一般的には、埋め込まれたHTMLディレクティブは、オリジンサーバからの埋め込まれたオブジェクトを取得するために、クライアントに指示します。コンテンツプロバイダは、今、彼らは最高のサロゲートからフェッチすることができることを、このような埋め込みオブジェクトへの参照を変更することができます。この技術はまた、URLの書き換えとして知られています。
Content modification techniques must not violate the architectural concepts of the Internet [9]. Special considerations must be made to ensure that the task of modifying the content is performed in a manner that is consistent with RFC 3238 [9] that specifies the architectural considerations for intermediaries that perform operations or modifications on content.
コンテンツ改質技術は、インターネットのアーキテクチャの概念に違反してはならない[9]。特別な考慮事項は、コンテンツを変更するタスクは、RFC 3238と一致している方法で行われることを確実にするために行われなければならない[9]コンテンツに対する操作又は改変を行う仲介するためのアーキテクチャの考慮事項を指定します。
The basic types of URL rewriting are discussed in the following subsections.
URL書き換えの基本的なタイプは、以下のサブセクションで説明されています。
In this scheme, a content provider rewrites the embedded URLs before the content is positioned on the origin server. In this case, URL rewriting can be done either manually or by using software tools that parse the content and replace embedded URLs.
コンテンツをオリジンサーバ上に配置される前に、この方式では、コンテンツプロバイダは、埋め込まれたURLを書き換えます。この場合は、URLの書き換えは、手動またはコンテンツを解析し、埋め込まれたURLを置き換えるソフトウェアツールを使用して行うことができます。
A-priori URL rewriting alone does not allow consideration of client specifics for Request-Routing. However, it can be used in combination with DNS Request-Routing to direct related DNS queries into the domain name space of the service provider. Dynamic Request-Routing based on client specifics are then done using the DNS approach.
単独の書き換え先験的URLは、Request-ルーティングのためのクライアントの仕様を考慮することはできません。しかし、サービスプロバイダのドメイン名空間に関連するDNSクエリを指示するためにDNSリクエスト・ルーティングと組み合わせて使用することができます。クライアントの仕様に基づいた動的な要求-ルーティングは、DNSのアプローチを使用して行われます。
On-Demand or dynamic URL rewriting, modifies the content when the client request reaches the origin server. At this time, the identity of the client is known and can be considered when rewriting the embedded URLs. In particular, an automated process can determine, on-demand, which surrogate would serve the requesting client best. The embedded URLs can then be rewritten to direct the client to retrieve the objects from the best surrogate rather than from the origin server.
オンデマンドまたは動的URLの書き換え、クライアントの要求がオリジンサーバに到達した内容を変更。このとき、クライアントの身元が知られており、埋め込まれたURLを書き換える際に考慮することができます。特に、自動化されたプロセスは、サロゲートが最高の要求元のクライアントにサービスを提供思われる、オンデマンド、決定することができます。埋め込まれたURLは、最高の代理からではなく、オリジンサーバからオブジェクトを取得するために、クライアントに指示するために書き換えることができます。
Content modification as a Request-Routing mechanism suffers from many limitation [23]. For example:
リクエスト・ルーティングメカニズムなどのコンテンツ修飾多くの制限に苦しんでいる[23]。例えば：
o The first request from a client to a specific site must be served from the origin server.
特定のサイトへのクライアントからの最初のリクエストoをオリジンサーバから提供されなければなりません。
o Content that has been modified to include references to nearby surrogates rather than to the origin server should be marked as non-cacheable. Alternatively, such pages can be marked to be cacheable only for a relatively short period of time. Rewritten URLs on cached pages can cause problems, because they can get outdated and point to surrogates that are no longer available or no longer good choices.
近くのサロゲートのではなく、オリジンサーバーへの参照を含むように変更されたO含有量は、非キャッシュ可能としてマークする必要があります。また、このようなページは、比較的短い時間のためにキャッシュ可能であることをマークすることができます。彼らはもはや利用可能か、もはや適していますサロゲートに時代遅れとポイントを得ることができるので、キャッシュされたページの書き換えURLは、問題を引き起こす可能性があります。
There are environments in which a combination of different mechanisms can be beneficial and advantageous over using one of the proposed mechanisms alone. The following example illustrates how the mechanisms can be used in combination.
異なるメカニズムの組み合わせは、単独で提案されたメカニズムのいずれかを使用して、上有益かつ有利できる環境があります。次の例では、メカニズムは組み合わせて使用することができる方法を示す図です。
A basic problem of DNS Request-Routing is the resolution granularity that allows resolution on a per-domain level only. A per-object redirection cannot easily be achieved. However, content modification can be used together with DNS Request-Routing to overcome this problem. With content modification, references to different objects on the same origin server can be rewritten to point into different domain name spaces. Using DNS Request-Routing, requests for those objects can now dynamically be directed to different surrogates.
DNSリクエスト・ルーティングの基本的な問題は、ドメインごとのレベルで解決することができます解像度の細かさです。オブジェクトごとのリダイレクトは容易に達成することができません。しかし、コンテンツの変更は、この問題を克服するためにDNSリクエスト・ルーティングと一緒に使用することができます。コンテンツの変更で、同じオリジンサーバ上の別のオブジェクトへの参照は、別のドメイン名空間に指すように書き換えることができます。 DNSリクエスト・ルーティングを使用して、それらのオブジェクトに対する要求は、動的に別の代理に向けることができます。
The main objective of this document is to provide a summary of current Request-Routing techniques. Such techniques are currently implemented in the Internet. However, security must be addressed by any entity that implements any technique that redirects client's requests. In [9] RFC 3238 addresses the main requirements for entities that intend to modify requests for content in the Internet.
このドキュメントの主な目的は、現在のリクエスト・ルーティング技術の概要を提供することです。このような技術は、現在、インターネットで実装されています。しかし、セキュリティは、クライアントの要求をリダイレクトする任意の技術を実装する任意のエンティティによって対処されなければなりません。では[9] RFC 3238は、インターネットでのコンテンツに対する要求を変更しようとするエンティティのための主な要件に対応しています。
Some active probing techniques will set off intrusion detection systems and firewalls. Therefore, it is recommended that implementers be aware of routing protocol security [25].
いくつかのアクティブなプロービング技術は、侵入検知システムとファイアウォールをオフに設定します。したがって、[25]実装は、ルーティングプロトコルのセキュリティを認識することが推奨されます。
It is important to note the impact of TLS [2] on request routing in CNs. Specifically, when TLS is used the full URL is not visible to the content network unless it terminates the TLS session. The current document focuses on HTTP techniques. TLS based techniques that require the termination of TLS sessions on Content Peering Gateways [8] are beyond the of scope of this document.
CNSにおけるルーティングリクエストにTLS [2]の影響に留意することが重要です。 TLSを使用する場合、それはTLSセッションを終了しない限り、具体的には、完全なURLは、コンテンツネットワークに表示されません。現在のドキュメントは、HTTP技術に焦点を当てています。 TLSコンテンツピアリングゲートウェイ上のTLSセッションの終了を要求する技術をベース[8]この文書の範囲を超えています。
The details of security techniques are also beyond the scope of this document.
セキュリティ技術の詳細は、このドキュメントの範囲を超えています。
The following people have contributed to the task of authoring this document: Fred Douglis (IBM Research), Mark Green, Markus Hofmann (Lucent), Doug Potter.
フレッドDouglis（IBMリサーチ）、マーク・グリーン、マーカス・ホフマン（ルーセント）、ダグ・ポッター：次の人はこの文書をオーサリングする作業に貢献してきました。
The authors acknowledge the contributions and comments of Ian Cooper, Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean (CrystalBall).
著者はイアン・クーパー、ナリンMistryさん（ノーテル）、ウェイン・丁（ノーテル）とエリック・ディーン（CrystalBall）の貢献とコメントを認めます。
Appendix A. Measurements
付録A.測定
Request-Routing systems can use a variety of metrics in order to determine the best surrogate that can serve a client's request. In general, these metrics are based on network measurements and feedback from surrogates. It is possible to combine multiple metrics using both proximity and surrogate feedback for best surrogate selection. The following sections describe several well known metrics as well as the major techniques for obtaining them.
リクエスト・ルーティング・システムは、クライアントのリクエストを処理することができる最高のサロゲートを決定するために、さまざまなメトリックを使用することができます。一般に、これらの指標は、サロゲートからネットワーク測定及びフィードバックに基づいています。近接性と最高のサロゲート選択のための代理のフィードバックの両方を使用して複数のメトリックを組み合わせることが可能です。次のセクションでは、いくつかのよく知られたメトリックだけでなく、それらを得るための主要な技術が記載されています。
A.1. Proximity Measurements
A.1。近接測定
Proximity measurements can be used by the Request-Routing system to direct users to the "closest" surrogate. In this document proximity means round-trip time. In a DNS Request-Routing system, the measurements are made to the client's local DNS server. However, when the IP address of the client is accessible more accurate proximity measurements can be obtained [24].
近接測定は、「最も近い」サロゲートへの直接ユーザにリクエスト・ルーティングシステムで使用することができます。この文書では近接は、ラウンドトリップ時間を意味します。 DNSリクエスト・ルーティングシステムでは、測定値は、クライアントのローカルDNSサーバに作られています。しかし、クライアントのIPアドレスがあるときにアクセス、より正確な近接測定を得ることができる[24]。
Proximity measurements can be exchanged between surrogates and the requesting entity. In many cases, proximity measurements are "one-way" in that they measure either the forward or reverse path of packets from the surrogate to the requesting entity. This is important as many paths in the Internet are asymmetric [24].
近接測定は、サロゲートと要求側エンティティの間で交換することができます。多くの場合、近接の測定は、それらが要求エンティティへサロゲートからのパケットの順方向または逆の経路のいずれかを測定するという点で、「一方通行」です。インターネットで多くのパスが[24]非対称であるので、これは重要です。
In order to obtain a set of proximity measurements, a network may employ active probing techniques.
近接測定値のセットを取得するために、ネットワークは、アクティブプロービング技術を採用してもよいです。
A.1.1. Active Probing
A.1.1。アクティブプロービング
Active probing is when past or possible requesting entities are probed using one or more techniques to determine one or more metrics from each surrogate or set of surrogates. An example of a probing technique is an ICMP ECHO Request that is periodically sent from each surrogate or set of surrogates to a potential requesting entity.
アクティブなプロービングは、過去や可能性を要求するエンティティは、各代理またはサロゲートのセットから1つのまたは複数のメトリックを決定するために1つ以上の技術を用いてプローブされるときです。プロービング技術の例は、周期的に電位要求エンティティに各サロゲートまたはサロゲートのセットから送信されるICMPエコー要求です。
In any active probing approach, a list of potential requesting entities need to be obtained. This list can be generated dynamically. Here, as requests arrive, the requesting entity addresses can be cached for later probing. Another potential solution is to use an algorithm to divide address space into blocks and to probe random addresses within those blocks. Limitations of active probing techniques include:
任意のアクティブなプロービングのアプローチでは、潜在的な要求エンティティのリストを取得する必要があります。このリストは、動的に生成することができます。要求が到着したときにここでは、要求エンティティのアドレスは、後のプロービングのためにキャッシュすることができます。別の潜在的な解決策は、ブロックにアドレス空間を分割し、それらのブロック内のランダムなアドレスを調べるために、アルゴリズムを使用することです。アクティブなプロービング技術の制限事項は次のとおりです。
o Measurements can only be taken periodically.
Oの測定は、定期的に撮影することができます。
o Firewalls and NATs disallow probes.
OファイアウォールとNATは、プローブを禁止します。
o Probes often cause security alarms to be triggered on intrusion detection systems.
Oプローブは、多くの場合、セキュリティアラームは、侵入検知システムでトリガさせることが。
A.1.2. Metric Types
A.1.2。メトリックタイプ
The following sections list some of the metrics, which can be used for proximity calculations.
次のセクションでは、近接計算に使用することができメトリックのいくつかをリストアップ。
o Latency: Network latency measurements metrics are used to determine the surrogate (or set of surrogates) that has the least delay to the requesting entity. These measurements can be obtained using active probing techniques.
Oレイテンシー：ネットワーク遅延の測定指標は、要求側エンティティに少なくとも遅延を有するサロゲート（またはサロゲートセット）を決定するために使用されます。これらの測定は、アクティブプロービング技術を用いて得ることができます。
o Hop Counts: Router hops from the surrogate to the requesting entity can be used as a proximity measurement.
Oホップカウント：ルータは、近接測定として使用することができる要求エンティティにサロゲートからホップ。
o BGP Information: BGP AS PATH and MED attributes can be used to determine the "BGP distance" to a given prefix/length pair. In order to use BGP information for proximity measurements, it must be obtained at each surrogate site/location.
BGP情報O：PATH AS BGPおよびMED属性は、指定されたプレフィックス/長さのペアに「BGPの距離」を決定するために使用することができます。近接測定のためのBGP情報を使用するためには、各代理サイト/位置で得られなければなりません。
It is important to note that the value of BGP AS PATH information can be meaningless as a good selection metric [24].
PATH情報AS BGPの値は良い選択メトリック[24]のように無意味にできることに注意することが重要です。
A.1.3. Surrogate Feedback
A.1.3。サロゲートフィードバック
In order to select a "least-loaded" delivery node. Feedback can be delivered from each surrogate or can be aggregated by site or by location.
「最小負荷」配信ノードを選択するために。フィードバックは、各サロゲートから送達され得るか、またはサイトによって、または位置によって集約することができます。
A.1.3.1. Probing
A.1.3.1。プロービング
Feedback information may be obtained by periodically probing a surrogate by issuing an HTTP request and observing the behavior. The problems with probing for surrogate information are:
フィードバック情報は、定期的にHTTP要求を発行し、行動を観察することにより、サロゲートをプロービングすることにより得ることができます。代理については、プロービングの問題点は以下のとおりです。
o It is difficult to obtain "real-time" information.
O「リアルタイム」の情報を得ることは困難です。
o Non-real-time information may be inaccurate.
O非リアルタイムの情報が不正確になることがあります。
Consequently, feedback information can be obtained by agents that reside on surrogates that can communicate a variety of metrics about their nodes.
したがって、フィードバック情報は、そのノードについてのメトリックの様々な通信することができるサロゲートに常駐するエージェントによって得ることができます。
[1] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[1]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1", RFC 2246, January 1999.
[2]ダークス、T.及びC.アレン、 "TLSプロトコルバージョン1"、RFC 2246、1999年1月。
[3] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol", RFC 2326, April 1998.
[3] SchulzrinneとH.とラオとA.とR. Lanphier、 "リアルタイムストリーミングプロトコル"、RFC 2326、1998年4月。
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[4]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、1999年6月。
[5] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[5]ウズラ、C.、メンデス、T.およびW.ミリケン、 "ホストエニーキャストサービス"、RFC 1546、1993年11月。
[6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[6]バーナーズ=リー、T.、Masinter、LとM. McCahill、 "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
[7] Schulzrinne, H., Casner, S., Federick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[7] Schulzrinneと、H.、Casner、S.、Federick、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[8] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003.
[8日目、M.、カイン、B.、トムリンソン、G.およびP. Rzewski、RFC 3466、2003年2月 "コンテンツインターネットワーキング（CDI）のためのモデル"。
[9] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[9]フロイド、S.とL. Daigle氏、 "オープン・プラグイン可能なエッジサービスのためのIAB建築・ポリシーに関する注意事項"、RFC 3238、2002年1月。
[10] Eastlake, D. and A, Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[10]イーストレイク、D.およびA、Panitz、 "予約トップレベルDNS名"、BCP 32、RFC 2606、1999年6月。
[11] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2002.
[11] Gulbrandsenの、A.、いるVixie、P.及びL. Esibov、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2782、2002年2月。
[12] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[12] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1035, November 1987.
[13] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1035、1987年11月。
[14] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[14]エルツ、R.とR.ブッシュ大統領、 "DNS仕様の明確化"、RFC 2181、1997年7月。
[15] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[15] Awduche、D.、チウ、A.、Elwalid、A.、Widjaja、I.およびX.シャオ、 "インターネットトラフィックエンジニアリングの概要と原則"、RFC 3272、2002年5月。
[16] Crawley, E., Nair, R., Rajagopalan, B. and H. Sandick, "A Framework for QoS-based Routing in the Internet", RFC 2386, August 1998.
[16]クローリー、E.、Nairさん、R.、Rajagopalan、B.及びH. Sandick、 "インターネットにおけるQoSベースのルーティングの枠組み"、RFC 2386、1998年8月。
[17] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[17]ヒューストン、G.、 "インターネットにおけるドメイン間ルーティングの解説"、RFC 3221、2001年12月。
[18] M. Welsh et al., "SEDA: An Architecture for Well-Conditioned, Scalable Internet Services", Proceedings of the Eighteenth Symposium on Operating Systems Principles (SOSP-18) 2001, October 2001.
[18] M.ウェールズら、「SEDA：良条件、スケーラブルなインターネットサービスのためのアーキテクチャ」、オペレーティングシステムの原理に八シンポジウム（SOSP-18）2001、2001年10月の議事録。
[19] A. Shaikh, "On the effectiveness of DNS-based Server Selection", INFOCOM 2001, August 2001.
[19] A. Shaikhさん、インフォコム2001年、2001年8月 "DNSベースのサーバ選択の有効性について"。
[20] C. Yang et al., "An effective mechanism for supporting content-based routing in scalable Web server clusters", Proc. International Workshops on Parallel Processing 1999, September 1999.
[20] C. Yangら、PROC「スケーラブルなWebサーバクラスタ内のコンテンツベースのルーティングをサポートするための効果的なメカニズム」。並列処理1999に関する国際ワークショップ、1999年9月。
[21] R. Liston et al., "Using a Proxy to Measure Client-Side Web Performance", Proceedings of the Sixth International Web Content Caching and Distribution Workshop (WCW'01) 2001, August 2001.
[21] R.リストンら、「クライアント側のWebパフォーマンスを測定するためにプロキシを使用」、第6回国際Webコンテンツのキャッシングと配信ワークショップの議事録（WCW'01）2001、2001年8月。
[22] W. Jiang et al., "Modeling of packet loss and delay and their effect on real-time multimedia service quality", Proceedings of NOSSDAV 2000, June 2000.
[22] W.江沢民ら、NOSSDAV 2000、2000年6月の議事録、「パケットロスや遅延、リアルタイムのマルチメディアサービスの品質に及ぼす影響のモデル化」。
[23] K. Johnson et al., "The measured performance of content distribution networks", Proceedings of the Fifth International Web Caching Workshop and Content Delivery Workshop 2000, May 2000.
[23] K. Johnsonら、「コンテンツ配信ネットワークの測定された性能」、第5回国際ウェブキャッシュワークショップおよびコンテンツ配信ワークショップ2000、2000年5月の議事。
[24] V. Paxson, "End-to-end Internet packet dynamics", IEEE/ACM Transactions 1999, June 1999.
[24] V.パクソン、 "エンドツーエンドのインターネットパケットダイナミクス"、IEEE / ACMの取引1999年、1999年6月。
[25] F. Wang et al., "Secure routing protocols: Theory and Practice", Technical report, North Carolina State University 1997, May 1997.
[25] F. Wangら、「セキュアルーティングプロトコル：理論と実践」。テクニカルレポート、ノースカロライナ州立大学1997年、1997年5月。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada
アビーBarbir Nortel Networksの3500カーリングアベニューオタワ、オンタリオK2H 8E9カナダ
Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com
電話：+1 613 763 5229 Eメール：abbieb@nortelnetworks.com
Brad Cain Storigen Systems 650 Suffolk Street Lowell, MA 01854 USA
ブラッドカインStorigenシステム650サフォークストリートローウェル、MA 01854 USA
Phone: +1 978-323-4454 EMail: bcain@storigen.com
電話：+1 978-323-4454電子メール：bcain@storigen.com
Raj Nair 6 Burroughs Rd Lexington, MA 02420 USA
ラジ・ナイール6バローズRdのレキシントン、MA 02420 USA
EMail: nair_raj@yahoo.com
メールアドレス：nair_raj@yahoo.com
Oliver Spatscheck AT&T 180 Park Ave, Bldg 103 Florham Park, NJ 07932 USA
オリバーSpatscheck AT＆T 180パークアベニュー、ビル103フローハムパーク、NJ 07932 USA
EMail: spatsch@research.att.com
メールアドレス：spatsch@research.att.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。