RFC3568 日本語訳

3568 Known Content Network (CN) Request-Routing Mechanisms. A. Barbir,B. Cain, R. Nair, O. Spatscheck. July 2003. (Format: TXT=42443 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

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

Barbirがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3568 ノーテルはカテゴリをネットワークでつなぎます: 情報のB.のナイアコンサルタントO.Spatscheck AT&TカインStorigenシステムR.2003年7月

         Known Content Network (CN) Request-Routing Mechanisms

知られている満足しているネットワーク(CN)要求ルート設定メカニズム

Status of this Memo

この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)インターネット協会(2003)。 All rights reserved。

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.

このドキュメントは様々な方針と可能なセットの測定基準に基づく代理にクライアント要求を向けるのに使用されるRequest-ルート設定のテクニックの概要を提示します。 ドキュメントは2000年12月以前産業に一般的に使用されたテクニックをカバーしています。 このメモでは、用語Request-ルート設定は一般的に満足しているルーティングか満足しているリダイレクションと呼ばれるテクニックを表します。 原則として、以下の下で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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 DNSはRequest-ルート設定Mechanisms. . . . . . . . . . . . 3 2.1を基礎づけました。 ただ一つの回答. . . . . . . . . . . . . . . . . . . . . 3 2.2。 倍数は.32.3に返答します。 マルチレベル解決. . . . . . . . . . . . . . . . 4 2.3.1。 ナノ秒リダイレクション. . . . . . . . . . . . . . . . 4 2.3.2。 CNAMEリダイレクション。 . . . . . . . . . . . . . . 5 2.4. Anycast。 . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. オブジェクトコード化。 . . . . . . . . . . . . . . . . . . . 6 2.6. DNS要求ルート設定制限。 . . . . . . . . . . . 6 3. トランスポート層要求ルート設定.7

Barbir, et al.               Informational                      [Page 1]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[1ページ]のRFC3568

   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

4. 応用層要求ルート設定.84.1。 ヘッダー点検。 . . . . . . . . . . . . . . . . . . 8 4.1.1. URLベースの要求ルート設定。 . . . . . . . . . . 8 4.1.2. ヘッダーベースの.94.1に要求して掘っている.3。 サイト特有の識別子。 . . . . . . . . . .10 4.2. 満足している変更. . . . . . . . . . . . . . . . .10 4.2.1。 先験的なURLの書き直. . . . . . . . . . . .11 4.2し.2。 要求次第のURLの書き直し。 . . . . . . . . . . .11 4.2.3. 満足している変更制限. . . . . . .11 5。 複数のメカニズム. . . . . . . . . . . . .11 6の組み合わせ セキュリティ問題. . . . . . . . . . . . . . . . . .12 7。 追加作者と承認.12………A.測定値. . . . . . . . . . . . . . . . . . . . . . . .13A.1。 近接測定.13……………A.1.1。 アクティブな調べ.13……………A.1.2。 メートル法のタイプ… .14 A.1.3。 代理のフィードバック. . . . . . . . . . . . . .14 8。 引用規格. . . . . . . . . . . . . . . . . . . .15 9。 有益な参照. . . . . . . . . . . . . . . . . . .15 10。 知的所有権と著作権宣言文. . . . . . .17 11。 作者のアドレス. . . . . . . . . . . . . . . . . . . . .18 12。 完全な著作権宣言文. . . . . . . . . . . . . . . . . .19

1.  Introduction

1. 序論

   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-ルート設定、Contentルート設定またはContent Redirectionと呼ばれます。

   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.

要求ルート設定のテクニックはContent Networks(また、Content Delivery Networksとして、知られている)[8]で一般的に使用されます。 内容Networksは層に4〜7に存在するネットワークインフラを含んでいます。 内容Networksは内容のための要求と応答のルーティングと推進に対処します。 内容Networksは輸送のための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].

一般に、要求ルート設定のテクニックは、その内容に最もよく勤めることができた代理の代理かセットにオブジェクトを求めるクライアント要求を向けるのに使用されます。 Content Network(CN)[8]の中にいる代理にクライアント要求を向けるのに要求ルート設定メカニズムを使用できました。

Barbir, et al.               Informational                      [Page 2]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[2ページ]のRFC3568

   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.

要求ルート設定のテクニックは、Content Delivery Networksの範囲とスケールを広げるのに乗り物として使用されます。 複数のRequest-ルート設定メカニズムが存在しています。aでは、ハイレベルであることで、これらは分類された下であるかもしれません: DNS Request-ルート設定、トランスポート層Request-ルート設定、および応用層Request-ルート設定。

   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.

要求ルーティングシステムは要求に最もよく勤めることができる代理にユーザを向ける試みに1セットの測定基準を使用します。 例えば、代理の選択は内容のネットワークの近接、帯域幅の有用性、代理の負荷、および有用性に基づくことができました。 付録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ベースのRequest-ルート設定のテクニックの概要を提供します。 セクション3はトランスポート層Request-ルーティング方式を論じます。 セクション4応用層Request-ルート設定では、メカニズムは探られます。 Request-ルート設定Systemの性能を最適化するために以前のセクションで議論した様々なメソッドを結合するとき、セクション5は洞察を提供します。 付録AはRequest-ルート設定システムによって使用される、選ぶことができた可能な測定基準と測定のテクニックの概要に与えられた代理を提供します。

2.  DNS based Request-Routing Mechanisms

2. DNSはRequest-ルート設定Mechanismsを基礎づけました。

   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のベースのRequest-ルート設定のテクニックはDNSシステム[10][12][13]の偏在のために一般的です。 DNSのベースのRequest-ルート設定のテクニックで、専門化しているDNSサーバはDNS解決プロセスに挿入されます。 サーバは両方のユーザの定義された方針、測定基準、または組み合わせに基づく異なったセットのA、NSまたはCNAME記録を返すことができます。 [11] RFC2782年に、(DNS SRV)はDNSのロードバランシングの使用のときに指導を提供します。 RFCは、制限のいくつかについて説明して、DNSの適切なuseageがテクニックを基礎づけたと示唆します。 次のセクションは中古のテクニックのいくつかの概要を提供します。

2.1.  Single Reply

2.1. ただ一つの回答

   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)アドレスであるかもしれません。

Barbir, et al.               Informational                      [Page 3]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[3ページ]のRFC3568

2.2.  Multiple Replies

2.2. 複数の回答

   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.

このアプローチでは、Request-ルート設定DNSサーバは様々な代理へのいくつかのA記録などの複数の回答を返します。 Round-ロビンファッションにおける複数の回答によるクライアントサイトDNSサーバのサイクルの一般的な実装。 ただ一つのクライアントサイトDNSサーバを使用することで複数のクライアントを指示するのに、記録が返されるオーダーを使用できます。

2.3.  Multi-Level Resolution

2.3. マルチレベル解決

   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.

このアプローチでは、複数のRequest-ルート設定DNSサーバがただ一つのDNS解決にかかわることができます。 ただ一つのDNS解決で複数のRequest-ルート設定DNSサーバを利用する原理は1つが、より複雑なただ一つのサーバから複数の、そして、より専門化しているRequest-ルート設定DNSサーバまでの決定を広げるのを許容することです。 複数のRequest-ルート設定DNSサーバをただ一つのDNS解決に挿入するのに使用される中で最も一般的なメカニズムはNSとCNAME記録の使用です。 例は、より高い平らなDNSサーバが領土の中で作動するケースでしょう、より正確な解決を提供するようその領土の中の、より特定のDNSサーバへのDNSルックアップに指示して。

2.3.1.  NS Redirection

2.3.1. ナノ秒、リダイレクション

   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サーバが別のRequest-ルート設定DNSサーバに次の平らなドメインの権威を向け直すのにNS記録を使用できる、テクニックで、複数のDNSサーバが名前解決プロセスにかかわります。 例えば、a.b.example.com[10]を決議するクライアントサイトDNSサーバは結局、ネームサーバの正式のfor example.comからa.b.example.comの解決を要求するでしょう。 このドメインに、正式のネームサーバはRequest-ルート設定NSサーバであるかもしれません。この場合、Request-ルート設定DNSサーバは、1セットのA記録を返すことができるか、またはNS記録を使用することで要求a.b.example.comの解決を正式のfor example.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つの欠点は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.

2番目の欠点は最後のDNSサーバが全体の解決プロセスのTTLを決定できるということです。 基本的に、最後のDNSサーバは応答の正式のセクションでそれ自身のNS記録を返すことができます。 クライアントはさらなる要求解決に期限が切れるまでこのキャッシュされたNS記録を使用するでしょう。

Barbir, et al.               Informational                      [Page 4]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[4ページ]のRFC3568

   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がどんな有効なA記録も返しもしませんし、キャッシュもしないネームサーバに再直接のポイントを平らにする場合におけるそれらの実装を簡素化するということです。 ネームサーバのドメインが現在決議されているドメインに合っていないなら、これは特に問題です、A記録(DNS応答で通過されるかもしれない)がこの場合安全保障上の理由で捨てられるので。 別の欠点は複数のDNSサーバの使用による要求を決議する加えられた遅れです。

2.3.2.  CNAME Redirection

2.3.2. CNAMEリダイレクション

   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.

このシナリオでは、Request-ルート設定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.

このアプローチの1つの不都合が新しいドメイン名を決議する追加オーバーヘッドです。 このアプローチの主な利点はRequest-ルート設定DNSサーバの数がドメイン名の形式から独立しているということです。

2.4.  Anycast

2.4. Anycast

   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アドレスにデータグラムを送ります、そして、インターネットワークはanycastアドレスのためにデータグラムを受け入れるサーバの少なくとも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.

その上、測定とリダイレクションを結合するために、Request-ルート設定DNSサーバはIPアドレスとしてanycastアドレスの広告を出すことができます。 同じアドレスは複数の物理的なDNSサーバによって使用されます。 このシナリオでは、クライアントサイトDNSサーバの最も近くにOSPFとBGPルーティングであるRequest-ルート設定DNSサーバはDNS解決要求を含むパケットを受けるでしょう。 サーバは、Request-ルート設定決定をするのにこの情報を使用できます。

Barbir, et al.               Informational                      [Page 5]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[5ページ]のRFC3568

   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 サーバ負荷はRequest-ルート設定プロセスの間、考えられません。

2.5.  Object Encoding

2.5. オブジェクトコード化

   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 Request-ルート設定の間、目に見えるので、何らかの解決法はオブジェクト・タイプ、オブジェクトハッシュ、または同様の情報をDNS名にコード化します。 これはオブジェクト・タイプ(images.a.b.example.comやstreaming.a.b.example.comなどの)に基づくオブジェクトの簡単な分裂から精巧なドメイン名がオブジェクトのユニークな識別子(ハッシュなどの)を含む図式に異なるかもしれません。 明白な利点はオブジェクト情報が時間分解能に利用可能であるということです。 不都合はクライアントサイトDNSサーバがただ一つのウェブページを検索する複数の解決を実行しなければならないということです。ウェブページは減少するよりむしろ総合的な潜在を増強するかもしれません。

2.6.  DNS Request-Routing Limitations

2.6. DNS要求ルート設定制限

   This section lists some of the limitations of DNS based
   Request-Routing techniques.

このセクションはDNSのベースのRequest-ルート設定のテクニックの制限のいくつかを記載します。

   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のベースのRequest-ルート設定では、システムサーバが、生きる短い間(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 Request-ルート設定はクライアントDNSサーバに関する知識だけに基づいています、クライアントアドレスがDNS要求の中でリレーされないとき。 これはRequest-ルート設定システムがクライアントの代理の近接を決定する能力を制限します。

Barbir, et al.               Informational                      [Page 6]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[6ページ]のRFC3568

   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名の再帰的な解決を要求して、許すことができます。 要求の再帰的な解決において、Request-ルート設定DNSサーバはクライアントのサイトDNSサーバのIPアドレスに暴露されないでしょう。この場合、Request-ルート設定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]はサーバに許容されるべきではありません)。 RFC2782はDNSのロードバランシングの使用に関する警告を[11]に提供します。 読者が制限の、より良い理解のためにRFCを読むよう奨励されます。

3.  Transport-Layer Request-Routing

3. トランスポート層要求ルート設定

   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.

トランスポート層では、クライアントの要求の厳重な検査で、よりすばらしいレベルの粒状を達成できます。 このアプローチでは、Request-ルート設定システムは代理の選択決定をするというクライアントの要求の最初のパケットで利用可能な情報を点検します。 クライアントの要求の点検はクライアントの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によって選ばれた代理を通して流れるでしょう。 逆流動(クライアントにとっての代理の)トラフィック(通常前進の流れよりはるかに多くのデータを移す)は直接路を通常取るでしょう。

Barbir, et al.               Informational                      [Page 7]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[7ページ]のRFC3568

   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.

トランスポート層Request-ルート設定[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.

一般に、トランスポート層Request-ルート設定をDNSのベースのテクニックに結合できます。 より早く述べられるように、DNSのベースのメソッドは暴露があるドメインか潜水艦ドメインに基づくクライアント要求をクライアントのDNSサーバIPアドレスに決議します。 したがって、第一歩としてトランスポート層Request-ルート設定系でするより正確な気品で適切な代理を決める際にDNSのベースのメソッドを使用できました。

4.  Application-Layer Request-Routing

4. 応用層要求ルート設定

   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.

応用層Request-ルート設定系はトランスポート層ヘッダーを超えてクライアントのパケットのより掘り下げた調査を実行します。 クライアントのパケットのより掘り下げた調査はきめ細かに粒状のRequest-ルート設定コントロールを個々のオブジェクトのレベルまで提供します。 オブジェクト要求時点で、リアルタイムで、プロセスを実行できました。 クライアントのIPアドレスへの暴露はオブジェクトが、応用層Request-ルート設定系が最も良い代理の選択の、より良いコントロールを提供するのを可能にする要求に関するきめ細かに粒状の知識に結合しました。

4.1.  Header Inspection

4.1. ヘッダー点検

   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要求ヘッダーのCookiesなどの内容か他の一部のURLから来るかもしれません。

4.1.1.  URL-Based Request-Routing

4.1.1. 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の接頭語か接尾語を調べるだけでRequest-ルート設定決定をするのは十分であるかもしれません。

4.1.1.1.  302 Redirection

4.1.1.1. 302リダイレクション

   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.

このアプローチでは、クライアントの要求は最初に、事実上の代理に決議されています。 その結果、代理は302のなどもののアプリケーション特有のコードを返します。(クライアントの実際の配送ノードを向け直すHTTP[4]かRTSP[3])の場合で。

Barbir, et al.               Informational                      [Page 8]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[8ページ]のRFC3568

   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.

このテクニックは実装するのが比較的簡単です。 しかしながら、このメソッドの主な欠点はクライアントへの再直接のメッセージ後部を送るのにかかわる追加潜在です。

4.1.1.2.  In-Path Element

4.1.1.2. 経路の要素

   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.

このテクニックで、In-経路要素はクライアントの要求の推進経路のネットワークで存在しています。 In-経路要素は輸送接続のわかりやすい妨害を提供します。 In-経路要素は、クライアントの満足している要求を調べて、Request-ルート設定決定を実行します。

   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.

In-経路要素は、次に、適切な配送ノードとの接続にクライアント接続を継いで、満足している要求を伝えます。 一般に、リターンパスはIn-経路要素に直面しているでしょう。 しかしながら、いくつかの独占手段を通して代理か配送ノードにアドレス変換情報を渡すことによってダイレクトリターンを準備するのは可能です。

   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.

テクニックは1セットの配送ノードの中でURLによって特定された満足しているオブジェクトでトラフィックを仕切る可能性を考慮します。 これはサーバローディングのオブジェクト特有のコントロールを許します。 例えば、非「キャッシュ-可能」オブジェクト・タイプを求める要求はキャッシュから遠くで指示されるかもしれません。

4.1.2.  Header-Based Request-Routing

4.1.2. ヘッダーベースの要求ルート設定

   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や、Languageや、User-エージェントなどの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.

ウェブサイトのそばで顧客かセッションを特定するのにクッキーを使用できます。 クッキーに基づいているRequest-ルート設定はクライアントに基づくコンテンツサービス分化を提供します。 このアプローチはクッキーがクライアントのものであれば働いています。 さらに、セッションレベル固執を達成するようマルチセッショントランザクションから同じサーバまでの接続に指示するのは可能です。

   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、または携帯電話が満足している要求を扱うために内容を専門にする配送ノードのタイプを示すことができます。

Barbir, et al.               Informational                      [Page 9]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[9ページ]のRFC3568

4.1.3.  Site-Specific Identifiers

4.1.3. サイト特有の識別子

   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 Session Identifierです。 この識別子は、それ自体を特定して、全体のセキュリティ認証交換を避けるのにウェブサーバーによって生成されて、続くセッションのときにウェブクライアントによって使用されます。 セッション識別子を点検するために、In-経路要素は、ウェブサーバーの応答を観測して、次に使用されるセッション識別子が特定のサーバにセッションを関連づけることを決定するでしょう。残っているセッションは保存されたセッション識別子に基づいて指示されます。

4.2.  Content Modification

4.2. 満足している変更

   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.

このテクニックは、コンテンツプロバイダーがクライアントと発生源サーバの間の経路で特定の魔法をかけるデバイスかディレクトリサービスの必要性なしでRequest-ルート設定決定の上に直轄を取るのを可能にします。基本的に、コンテンツプロバイダーは直接クライアントへの要求に勤めることができる最も良い代理を伝えることができます。 aで最も良い代理に関する決定をすることができる、-、対象分類かそれが測定基準のセットに依存できます。 全体的な目的はすべての埋め込みオブジェクトを含む変更された内容を提供するためにスケーラビリティと性能を向上させることです。

   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.

一般に、方法は追加していて、埋め込まれた物の指示するものを含んでいる基本構造から成る満足している物を利用します。 例えば、ほとんどのウェブページ、いくつかの埋め込みオブジェクトと共にプレーンテキストを含むHTMLドキュメントから成ってください、GIFやJPEGイメージのように。 埋め込みオブジェクトは、埋め込まれた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]に関するアーキテクチャ概念に違反してはいけません。 特別な問題に内容を変更するタスクが内容に操作か変更を実行する仲介者に建築問題を指定するRFC3238[9]と一致した方法で実行されるのを保証させなければなりません。

   The basic types of URL rewriting are discussed in the following
   subsections.

以下の小区分でURLの書き直しの基本型について議論します。

Barbir, et al.               Informational                     [Page 10]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[10ページ]のRFC3568

4.2.1.  A-priori URL Rewriting

4.2.1. 先験的な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 Request-ルート設定と組み合わせてサービスプロバイダーのドメイン名スペースに関連するDNS質問を向けるのにそれを使用できます。 ダイナミックなRequest-ルート設定は、DNSアプローチを使用することで次に詳細が行われるクライアントを基礎づけました。

4.2.2.  On-Demand URL Rewriting

4.2.2. 要求次第のURLの書き直し

   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を書き直すことができます。

4.2.3.  Content Modification Limitations

4.2.3. 満足している変更制限

   Content modification as a Request-Routing mechanism suffers from many
   limitation [23].  For example:

Request-ルート設定メカニズムとしての満足している変更は多くの制限[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は問題を起こすことができます、彼らが時代遅れになって、もう手があいていない代理かもう良い選択を示すことができないので。

5.  Combination of Multiple Mechanisms

5. 複数のメカニズムの組み合わせ

   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.

単独で提案されたメカニズムの1つを使用する上で、異なったメカニズムの組み合わせが有益であって、有利である場合がある環境があります。 以下の例は組み合わせにどうメカニズムを使用できるかを例証します。

Barbir, et al.               Informational                     [Page 11]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[11ページ]のRFC3568

   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 Request-ルート設定の基本的問題は1ドメインあたり1つのレベルだけで解決を許す解決粒状です。 容易に1物あたり1つのリダイレクションを達成できません。 しかしながら、この問題を克服するのにDNS Request-ルート設定と共に満足している変更を使用できます。 満足している変更で、異なったドメイン名空間に指すために同じ起源サーバの異なった物の参照を書き直すことができます。 DNS Request-ルート設定を使用して、現在、ダイナミックにそれらの物を求める要求を異なった代理に向けることができます。

6.  Security Considerations

6. セキュリティ問題

   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.

このドキュメントの主な目標は現在のRequest-ルート設定のテクニックの概要を提供することです。 そのようなテクニックは現在、インターネットで実行されます。 しかしながら、クライアントの要求を向け直すどんなテクニックも実行するどんな実体でもセキュリティを記述しなければなりません。 [9]では、RFC3238はインターネットの内容に関する要求を変更するつもりである実体のための主な要件を記述します。

   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].

いくつかのアクティブな調べのテクニックが侵入検知システムとファイアウォールを引きたたせるでしょう。 したがって、implementersがルーティング・プロトコルセキュリティ[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のテクニックに焦点を合わせます。 Content Peering Gateways[8]におけるTLSセッションの終了を必要とするTLSのベースのテクニックが向こうにある、このドキュメントの範囲について。

   The details of security techniques are also beyond the scope of this
   document.

セキュリティのテクニックの詳細はこのドキュメントの範囲を超えてもいます。

7.  Additional Authors and Acknowledgements

7. 追加作者と承認

   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).

作者はイアン・クーパー、Nalinミストリ(ノーテル)、ウェインDing(ノーテル)、およびエリック・ディーン(CrystalBall)の貢献とコメントを承諾します。

Barbir, et al.               Informational                     [Page 12]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[12ページ]のRFC3568

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].

近接測定はRequest-ルート設定システムによって使用されて、「最も近い」代理にユーザを向けることができます。 本書では近接は往復の時間を意味します。 DNS Request-ルート設定システムでは、測定をクライアントのローカルの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.

1セットの近接測定を得るために、ネットワークはアクティブな調べのテクニックを使うかもしれません。

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 ECHO Requestです。

   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 ファイアウォールとNATsは徹底的調査を禁じます。

Barbir, et al.               Informational                     [Page 13]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[13ページ]のRFC3568

   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.

o BGP情報: 「BGP距離」を与えられた接頭語/長さの組まで決定するのにBGP AS PATHとMED属性を使用できます。 近接測定にBGP情報を使用するために、それぞれの代理のサイト/位置でそれを得なければなりません。

   It is important to note that the value of BGP AS PATH information can
   be meaningless as a good selection metric [24].

BGP AS PATH情報の値が良い選択メートル法の[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.

その結果、彼らのノードに関するさまざまな測定基準を伝えることができる代理の上に住んでいるエージェントはフィードバック情報を得ることができます。

Barbir, et al.               Informational                     [Page 14]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[14ページ]のRFC3568

8.  Normative References

8. 引用規格

   [1]  Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
        959, October 1985.

[1] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。

   [2]  Dierks, T. and C. Allen, "The TLS Protocol Version 1", RFC 2246,
        January 1999.

[2] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。

   [3]  Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
        Protocol", RFC 2326, April 1998.

[3]SchulzrinneとH.とラオとA.とR.Lanphier、「リアルタイムのストリーミングのプロトコル」、RFC2326、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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。

   [5]  Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting
        Service", RFC 1546, November 1993.

[5] ヤマウズラとC.とメンデスとT.とW.ミリケン、「ホストAnycastingサービス」、RFC1546、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、「Uniform Resource Locator(URL)」、RFC1738、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.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、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.ルゼフスキー、「満足しているインターネットワーキング(CDI)のためのモデル」、RFC3466、2003年2月。

   [9]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
        Considerations for Open Pluggable Edge Services", RFC 3238,
        January 2002.

[9] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、2002年1月。

9.  Informative References

9. 有益な参照

   [10] Eastlake, D. and A, Panitz, "Reserved Top Level DNS Names", BCP
        32, RFC 2606, June 1999.

[10] イーストレークとD.とA、パニツ、「予約された最高平らなDNS名」、BCP32、RFC2606、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 SRV)の位置を指定するためのDNS RR」、RFC2782、2002年2月。

   [12] Mockapetris, P., "Domain names - concepts and facilities", STD
        13, RFC 1034, November 1987.

[12]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

   [13] Mockapetris, P., "Domain names - concepts and facilities", STD
        13, RFC 1035, November 1987.

[13]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1035、11月1987日

Barbir, et al.               Informational                     [Page 15]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[15ページ]のRFC3568

   [14] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
        RFC 2181, July  1997.

[14]ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、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.、ウィジャヤ、I.、X.Xiao、および「概観とインターネットプリンシプルズ交通工学」(RFC3272)は2002がそうするかもしれません。

   [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.とナイアとR.とRajagopalanとB.とH.Sandick、「インターネットのQoSベースのルート設定のための枠組み」、RFC2386、1998年8月。

   [17] Huston, G., "Commentary on Inter-Domain Routing in the
        Internet", RFC 3221, December 2001.

[17] ヒューストン、G.、「インターネットの相互ドメインルート設定の論評」、RFC3221、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における第18シンポジウムの議事、2001年10月。

   [19] A. Shaikh, "On the effectiveness of DNS-based Server Selection",
        INFOCOM 2001, August 2001.

[19] A.Shaikh、「DNSベースのServer Selectionの有効性」、INFOCOM2001、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.陽の他、「内容を支持するための有効なメカニズムはスケーラブルなウェブサーバクラスタでルーティングを基礎づけた」Proc。 1999年9月の並列処理1999に関する国際ワークショップ。

   [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.リストン他、「クライアントサイドウェブパフォーマンスを測定するのにプロキシを使用します」、Sixthの国際ウェブContent CachingとDistribution Workshop(WCW'01)2001年のProceedings(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.江他、「リアルタイムのマルチメディアサービス品質へのパケット損失、遅れ、およびそれらの効果のモデル」、NOSSDAV2000(2000年6月)のProceedings。

   [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.ジョンソン他、「満足している流通機構の測定性能」、黙秘権の国際ウェブCaching WorkshopとContent Delivery Workshop2000のProceedings(2000年5月)。

   [24] V. Paxson, "End-to-end Internet packet dynamics", IEEE/ACM
        Transactions 1999, June 1999.

[24] V.パクソン、「終わりから終わりへのインターネットパケット力学」、IEEE/ACM Transactions1999、1999年6月。

   [25] F. Wang et al., "Secure routing protocols: Theory and Practice",
        Technical report, North Carolina State University 1997, May
        1997.

[25] F.ワング他、「ルーティング・プロトコルを保証してください」 Technicalが、「理論とPractice」と報告して、ノースカロライナ州立大学が1997であり、5月は1997です。

Barbir, et al.               Informational                     [Page 16]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[16ページ]のRFC3568

10.  Intellectual Property Statement

10. 知的所有権声明

   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はどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を記述してください。

Barbir, et al.               Informational                     [Page 17]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[17ページ]のRFC3568

11.  Authors' Addresses

11. 作者のアドレス

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9
   Canada

アビーBarbirノーテルは3500縦梁アベニューネピアン、オンタリオのK2H8の9Eのカナダをネットワークでつなぎます。

   Phone: +1 613 763 5229
   EMail: abbieb@nortelnetworks.com

以下に電話をしてください。 +1 5229年の613 763メール: abbieb@nortelnetworks.com

   Brad Cain
   Storigen Systems
   650 Suffolk Street
   Lowell, MA  01854
   USA

ブラッドカインStorigen Systems650サフォーク通りMA01854ローウェル(米国)

   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バローズMA02420第レキシントン(米国)

   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&T180公園Ave、Bldg103Florham公園、ニュージャージー07932米国

   EMail: spatsch@research.att.com

メール: spatsch@research.att.com

Barbir, et al.               Informational                     [Page 18]

RFC 3568          Known CN Request-Routing Mechanisms          July 2003

Barbir、他 CN要求ルート設定メカニズム2003年7月に知られていた情報[18ページ]のRFC3568

12.  Full Copyright Statement

12. 完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

Barbir, et al.               Informational                     [Page 19]

Barbir、他 情報[19ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

layoutの種類と使用方法

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る