[要約] RFC 3568は、既知のコンテンツネットワーク（CN）のリクエストルーティングメカニズムに関する情報を提供するものです。その目的は、CNの効率的なリクエスト処理とネットワークトラフィックの最適化を支援することです。
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
既知のコンテンツネットワーク（CN）リクエストルーティングメカニズム
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.
Copyright（c）The Internet Society（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月以前に業界で一般的に使用されていた手法をカバーしています。このメモでは、リクエストルーティングという用語は、一般的にコンテンツルーティングまたはコンテンツリダイレクトと呼ばれる手法を表しています。原則として、リクエストルーティング手法は、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].
リクエストルーティング手法は、一般に、オブジェクトのクライアントリクエストを、そのコンテンツに最適なサロゲートまたは一連のサロゲートに向けるために使用されます。リクエストルーティングメカニズムを使用して、コンテンツネットワーク（CN）内にあるサロゲートにクライアントリクエストを向けることができます[8]。
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では、リクエストルーティングシステムのパフォーマンスを最適化するために、以前のセクションで説明したさまざまな方法を組み合わせることに関する洞察を提供します。付録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ベースの手法の適切な使用を示唆しています。次のセクションでは、使用されている手法のいくつかの概要を説明します。
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サーバーは、Aレコードで最高の代理のIPアドレスを要求DNSサーバーに返します。サロゲートの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サーバーは、さまざまな代理のレコードなどの複数の返信を返します。クライアントサイト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解像度で複数のリクエストルーティングDNSサーバーを利用する理論的根拠は、単一のサーバーから複数のより特殊なリクエストルーティングDNSサーバーに、より複雑な決定をより複雑な決定を配布できるようにすることです。単一のDNS解像度で複数のリクエストルーティング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サーバーは、NSレコードを使用して、次のレベルドメインの権限を別のリクエストルーティングDNSサーバーにリダイレクトできます。この手法により、複数のDNSサーバーを名前解決プロセスに関与させることができます。たとえば、A.B.example.com [10]を解決するクライアントサイトDNSサーバーは、最終的には、a.b.example.comの解像度を、たとえばa.b.example.comの解像度を要求します。このドメインの権威ある名前サーバーは、リクエストルーティングNSサーバーである可能性があります。この場合、リクエストルーティングDNSサーバーは、レコードのセットを返すか、要求a.b.example.comの解像度を、NSレコードを使用してcomが権威あるDNSサーバーにリダイレクトできます。
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つの欠点は、リクエストルーティングDNSサーバーの数がDNS名のパーツの数によって制限されることです。この問題は、DNS Serverが権威ある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.
2番目の欠点は、最後の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.
別の欠点は、Bindのいくつかの実装により、NSレベルのリダイレクトが有効なレコードが返されたりキャッシュされたりしない名前サーバーをリダイレクトする場合、タイムアウトが実装を単純化することです。この場合、DNS応答で渡される可能性のあるAレコードがセキュリティ上の理由で破棄されるため、これは、名前サーバーのドメインが現在解決されているドメインと一致しない場合に特に問題です。もう1つの欠点は、複数の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レコードを返し、解像度をまったく新しいドメインに直接解決します。原則として、新しいドメインは、リクエストルーティング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.
このアプローチの欠点の1つは、新しいドメイン名を解決する追加のオーバーヘッドです。このアプローチの主な利点は、リクエストルーティング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.
Anycast [5]は、ホスト、アプリケーション、またはユーザーが特定のサービスをサポートするホストを見つけたいと考えているネットワーク状況に適用されるネットワーク間サービスですが、いくつかのサーバーがサービスを利用している場合、どのサーバーがどのサーバーを使用しないかを気にしません使用されている。Anycastサービスでは、ホストはデータグラムをAnycastアドレスに送信し、ネットワーク間は、データグラムの最良の努力をDatagramsを受け入れるサーバーの少なくとも1つ、できれば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.
Anycastの動機は、適切なサーバーを見つけるタスクを大幅に簡素化することです。たとえば、ユーザーは、サーバーのリストに相談して最も近いサーバーを選択する代わりに、サーバーの名前を入力して最寄りの名前に接続するだけです。Anycastを使用することにより、DNSリゾルバーはサーバーのIPアドレスで構成する必要がなくなり、よく知られているDNS Anycastアドレスにクエリを送信することができます。
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サーバーは、AnycastアドレスをIPアドレスとして宣伝できます。同じアドレスが複数の物理DNSサーバーで使用されます。このシナリオでは、OSPFおよびBGPルーティングに関してクライアントサイトDNSサーバーに最も近いリクエストルーティングDNSサーバーは、DNS解像度リクエストを含むパケットを受け取ります。サーバーはこの情報を使用して、リクエストルーティングの決定を下すことができます。
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.A.B.Example.comやStreaming.A.B.Example.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.
o DNSリクエストルーティングは、クライアントアドレスが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ベースの要求ルーティング手法は、深刻な制限に苦しむ可能性があります。たとえば、そのような手法の使用は、サードパーティのDNSサーバーを過剰に負担する可能性がありますが、これは許可されるべきではありません[19]。[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]などの一部のアプリケーションレベルプロトコルは、クライアント要求の指示方法についてのセッションの最初の部分でヒントを提供します。これらのヒントは、Cookieなどの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.
このアプローチでは、クライアントの要求は最初に仮想サロゲートに解決されます。その結果、Surrogateは302（HTTP [4]またはRTSP [3]の場合）などのアプリケーション固有のコードを返し、クライアントを実際の配信ノードにリダイレクトします。
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.
この手法では、クライアントの要求の転送パスのネットワークにインパス要素が存在します。インパス要素は、輸送接続の透明な傍受を提供します。インパス要素は、クライアントのコンテンツリクエストを調べ、リクエストルーティングの決定を実行します。
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.
その後、インパス要素は、適切な配信ノードとの接続へのクライアント接続をスプライブし、コンテンツリクエストに沿って渡します。一般に、リターンパスはパス内の要素を通過します。ただし、アドレス変換情報をいくつかの独自の手段を介して代理ノードまたは配信ノードに渡すことにより、直接返品を手配することができます。
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.
この手法には、代理を選択するために、Cookie、言語、ユーザーエージェントなどのHTTP [4]を使用するタスクが含まれます。[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.
Cookieは、Webサイトで顧客またはセッションを識別するために使用できます。Cookieベースのリクエストルーティングは、クライアントに基づいたコンテンツサービスの差別化を提供します。Cookieがクライアントに属している場合、このアプローチは機能します。さらに、マルチセッショントランザクションから同じサーバーに接続を向けて、セッションレベルの永続性を実現することができます。
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.
言語ヘッダーを使用して、トラフィックを言語固有の配信ノードに向けることができます。ユーザーエージェントヘッダーは、クライアントデバイスのタイプを識別するのに役立ちます。たとえば、音声ブラウザー、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クライアントによって使用され、それ自体を識別し、セキュリティ認証交換全体を回避します。セッション識別子を検査するために、パス内の要素が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.
この手法により、コンテンツプロバイダーは、クライアントとOriginサーバーの間のパスで特定の魔女デバイスまたはディレクトリサービスを必要とせずに、リクエストルーティングの決定を直接制御できます。基本的に、コンテンツプロバイダーは、リクエストを提供できる最高の代理をクライアントに直接通信できます。最良の代理に関する決定は、オブジェクトごとに行うことができます。または、一連のメトリックに依存することもできます。全体的な目標は、スケーラビリティと、すべての組み込みオブジェクトを含む変更されたコンテンツを配信するためのパフォーマンスを向上させることです。
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ディレクティブは、クライアントにOrigin Serverから埋め込まれたオブジェクトを取得するよう指示します。コンテンツプロバイダーは、埋め込みオブジェクトへの参照を変更して、最高の代理から取得できるようにすることができます。この手法は、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.
このスキームでは、コンテンツがOrigin Serverに配置される前に、コンテンツプロバイダーが組み込み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.
A-Priori URLの書き換えだけでは、リクエストルーティングのクライアントの詳細を考慮することはできません。ただし、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書き換えは、クライアント要求がOrigin Serverに到達したときにコンテンツを変更します。この時点で、クライアントの身元は既知であり、埋め込まれた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 クライアントから特定のサイトへの最初のリクエストは、Origin Serverから提供する必要があります。
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 Origin Serverではなく、近くの代理人への参照を含むように変更されたコンテンツは、キャッシュできないものとしてマークする必要があります。あるいは、そのようなページは、比較的短期間だけキャッシュ可能であるとマークすることができます。キャッシュされたページに書き換えられた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リクエストルーティングと一緒に使用できます。コンテンツの変更により、同じOrigin Server上の異なるオブジェクトへの参照を書き換えて、異なるドメイン名スペースを指すことができます。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テクニックに焦点を当てています。コンテンツピアリングゲートウェイ[8]でTLSセッションの終了を必要とするTLSベースの手法は、このドキュメントの範囲を超えています。
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.
以下の人々は、この文書の執筆の課題に貢献しています：フレッド・ダグリス（IBM Research）、マーク・グリーン、マルクス・ホフマン（ルーセント）、ダグ・ポッター。
The authors acknowledge the contributions and comments of Ian Cooper, Nalin Mistry (Nortel), Wayne Ding (Nortel) and Eric Dean (CrystalBall).
著者は、イアン・クーパー、ナリン・ミストリー（ノルテル）、ウェイン・ディン（ノルテル）、エリック・ディーン（クリスタルボール）の貢献とコメントを認めています。
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.
リクエストルーティングシステムは、クライアントの要求に応えることができる最高の代理を決定するために、さまざまなメトリックを使用できます。一般に、これらのメトリックは、ネットワーク測定と代理からのフィードバックに基づいています。最適な代理選択のために、近接フィードバックとサロゲートフィードバックの両方を使用して複数のメトリックを組み合わせることができます。次のセクションでは、いくつかのよく知られている指標と、それらを取得するための主要な手法について説明します。
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.
一連の近接測定値を取得するために、ネットワークはアクティブな調査手法を採用する場合があります。
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 多くの場合、プローブは侵入検知システムでセキュリティアラームをトリガーします。
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.
o BGP情報：PATHおよびMED属性としてのBGPを使用して、特定のプレフィックス/長さのペアに対する「BGP距離」を決定できます。近接測定にBGP情報を使用するには、各代理サイト/場所で取得する必要があります。
It is important to note that the value of BGP AS PATH information can be meaningless as a good selection metric [24].
パス情報としてのBGPの値は、優れた選択メトリックとして無意味である可能性があることに注意することが重要です[24]。
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.
「最小ロードされた」配信ノードを選択するため。フィードバックは、各代理から配信することも、サイトまたは場所で集約することもできます。
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] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1", RFC 2246, January 1999.
[2] Dierks、T。およびC. Allen、「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.、Rao、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[5] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[5] Partridge、C.、Mendez、T。、およびW. Milliken、「Host Anycciding Service」、RFC 1546、1993年11月。
[6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[6] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators（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] Day、M.、Cain、B.、Tomlinson、G。and P. Rzewski、「コンテンツインターネットワーク（CDI）のモデル」、RFC 3466、2003年2月。
[9] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[9] Floyd、S。and L. Daigle、「Open Pluggable Edge ServicesのIAB建築および政策上の考慮事項」、RFC 3238、2002年1月。
[10] Eastlake, D. and A, Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[10] Eastlake、D。and 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。and 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] Elz、R。、およびR. Bush、「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.、Chiu、A.、Elwalid、A.、Widjaja、I。およびX. Xiao、「概要とインターネットトラフィックエンジニアリングの原則」、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] Crawley、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] Huston、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. Welsh et al。、「Seda：十分に条件付きのスケーラブルなインターネットサービスのためのアーキテクチャ」、2001年10月、オペレーティングシステム原則に関する第88回シンポジウム（SOSP-18）2001年の議事録。
[19] A. Shaikh, "On the effectiveness of DNS-based Server Selection", INFOCOM 2001, August 2001.
[19] A. Shaikh、「DNSベースのサーバー選択の有効性に関する」、Infocom 2001、2001年8月。
[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 et al。、「スケーラブルなWebサーバークラスターでのコンテンツベースのルーティングをサポートするための効果的なメカニズム」、Proc。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. Liston et al。、「クライアント側の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. Jiang et al。、「パケット損失と遅延のモデリング、およびリアルタイムマルチメディアサービス品質への影響」、2000年6月のノスダブ2000の議事録。
[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 et al。、「コンテンツ配信ネットワークの測定されたパフォーマンス」、2000年5月、5番目の国際Webキャッシングワークショップおよびコンテンツ配信ワークショップ2000の議事録。
[24] V. Paxson, "End-to-end Internet packet dynamics", IEEE/ACM Transactions 1999, June 1999.
[24] V. Paxson、「エンドツーエンドのインターネットパケットダイナミクス」、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 et al。、「安全なルーティングプロトコル：理論と実践」、技術レポート、ノースカロライナ州立大学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
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean、オンタリオK2H 8E9カナダ
Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com
Brad Cain Storigen Systems 650 Suffolk Street Lowell, MA 01854 USA
Brad Cain Storigen Systems 650 Suffolk Street Lowell、MA 01854 USA
Phone: +1 978-323-4454
EMail: bcain@storigen.com
Raj Nair 6 Burroughs Rd Lexington, MA 02420 USA
Raj Nair 6 Burroughs Rd Lexington、MA 02420 USA
EMail: nair_raj@yahoo.com
Oliver Spatscheck AT&T 180 Park Ave, Bldg 103 Florham Park, NJ 07932 USA
Oliver Spatscheck AT＆T 180 Park Ave、BLDG 103 Florham Park、NJ 07932 USA
EMail: spatsch@research.att.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。