Loading article…
| 国際標準 | RFC 7285 |
|---|---|
| 開発者 | 国際電気通信連合 |
アプリケーション層トランスポート最適化( ALTO ) は、インターネットクライアントが他のエンドポイントへのパスのネットワークプロパティを比較する情報を取得できるようにするプロトコルです。通常、これは何らかのコンテンツのコピーにアクセスするための最も低コストの場所を特定するために使用されます。[1]
ALTO 基本プロトコルは、RFC 7285 で規定されています。[2]ネットワーク プロパティ (多くの場合、さまざまなエンドポイントへのルーティングコスト)に関する知識を備えた「ALTO サーバー」をネットワーク内に展開する必要があります。[3]通常、リソースを取得しようとするユーザー エージェントに関連付けられた「ALTO クライアント」は、 HTTP経由で ALTO サーバーにクエリを実行し、リソースを取得する最適な場所を取得します。
歴史
2005年頃から、 BitTorrentなどのピアツーピアアプリケーションの普及は、多くのネットワーク事業者にとって深刻な懸念事項となりました。これらのアプリケーションによって発生する膨大な量のネットワークトラフィックが、トラフィックエンジニアリングと収益に大きな影響を与えたからです。一部のネットワーク事業者は、このトラフィックを抑制しようとしました。[4]
2008年5月、IETFのピアツーピアインフラストラクチャに関するワークショップでは、いくつかの作業領域が特定されました。[5]
- 基盤となる IP ネットワークとオーバーレイ ネットワーク (ピアツーピアネットワークなど)の間で情報を交換するための標準化されたインターフェイス。基本的な考え方は、オーバーレイ ネットワークが基盤となるIP ネットワークを介したトラフィックの送信のトポロジとコストを認識していれば、オーバーレイ ネットワークのトポロジ (ピアの選択など) に関する決定とオーバーレイ ネットワークを介したトラフィックのルーティングを最適化できるというものです。その結果、基盤となるネットワーク インフラストラクチャの使用率を削減しながら、アプリケーションのパフォーマンスやエクスペリエンスの品質が向上します。この作業項目により、IETF ALTO ワーキング グループの設立が行われました。
- ネットワーク内のコンテンツキャッシュ。これはIETF DECADEワーキンググループで研究されてきました。しかし、新しいプロトコルは開発され標準化されていません。 [6]
- バックグラウンドトラフィック用のトランスポート層における新しい輻輳制御メカニズム。標準TCPに「従う」 。これはIETF LEDBATワーキンググループで開発され、RFC 6817で標準化されました。[7]
- IPパケットをデフォルトの「ベストエフォート」カテゴリよりも低い優先度にマークするための新しいDiffServコードポイントがRFC 8622で標準化されました。[8]
IETF ALTOワーキンググループは2008年11月に設立されました。[9]最初の成果物は、問題ステートメント、[1]要件ドキュメント、[3]コアALTOプロトコルの仕様[2]およびALTOサーバー検出メカニズムでした。[10]それ以来、さまざまな拡張機能が指定されており（以下を参照）、現在も作業中です（IETF ALTO Datatracker [11]を参照）。
もともとピアツーピアのファイル共有をサポートするために設計されたこの概念は、多くのネットワークの問題に広く適用できます。[12]しかし、2021年現在、インターネットでは広く導入されていません。ただし、インターネットサービスプロバイダー（ISP）ネットワークでの実験や、 CERNの大型ハドロン衝突型加速器の大規模データ転送をサポートするための導入が行われています。[13]
プロトコルの概要
ALTO サーバーは通常、ISP 内で動作し、ISP ネットワークのトポロジに関する情報を収集します。この情報を収集する手段は ALTO 設計の範囲外ですが、通常はルーティング プロトコルの情報交換に参加し、ネットワーク管理からのポリシー入力やさまざまなネットワーク監視システムからのデータを受信します。
ALTO サーバーはこの情報を使用してクライアントにサービスを提供します。
ALTO 情報を取得する最初のステップは、ALTO サーバーを見つけることです。ALTO クライアントが、最適化されるデータ転送のエンドポイントでもあるホスト上にある場合は、RFC 7286 [10]で指定されている ALTO サーバー検出手順を使用できます。一方、ALTO クライアントが別のホスト上にある場合 (たとえば、 ALTO クライアントが組み込まれたBitTorrent トラッカーが、別のネットワーク ドメインにある可能性のあるピアの代わりにピア選択を最適化したい場合)、RFC 8686 [14]で指定されているクロスドメイン サーバー検出手順を使用する必要があります。クライアントは、サービス検出ドメイン名を直接構成することもできますが、通常はネットワークに参加するときにDHCP経由で名前を取得します。次に、そのサービス検出ホストに対して "ALTO:https" または "ALTO:http" アプリケーション サービス タグのDDDSクエリを作成し、使用可能な ALTO サーバー情報リソース ディレクトリ (IRD) の URLを返します。
その後、クライアントは ALTO サーバーの 1 つから IRD を取得します。IRD には、利用可能なサービス、サポートされているパラメータ、およびそれらのサービスの場所の詳細がリストされます。
基本プロトコルには 4 つのサービス タイプがあります。
マップサービスは、サーバーが追跡するすべてのエンドポイントまたは PID をリストするファイルを提供します。「ネットワーク マップ」は、クライアントがより具体的なクエリを作成するために使用できる「目次」として機能します。これらのエンドポイントは IPv4 または IPv6 アドレスによって識別され、同様のプロパティを持つ他のエンドポイントとともにプロバイダー定義識別子 (PID) にグループ化され、将来のクエリと応答のサイズが削減されます。「コスト マップ」には、各 PID ペアのルーティング コストがリストされます。
マップフィルタリング サービスは、クライアントが提供するパラメータに基づいて、ネットワーク マップまたはコスト マップのサブセットを提供します。
エンドポイント プロパティ サービスを使用すると、クライアントは特定のエンドポイントの接続タイプやカプセル化 PID などのプロパティを照会できます。
エンドポイント コスト サービスは、特定のエンドポイントへのルーティング コストをクライアントに提供します。これは、絶対コスト メトリックまたは各エンドポイントの相対コストのランキングとして表現される場合があります。
以降の仕様では、追加のサービスが指定されます。
RFC 8895 [15]で規定されている更新ストリームサービスは、情報が変更されるとサーバーが更新メッセージのストリームを提供できるように接続を開いたままにします。同じRFCでは、クライアントが更新メッセージの要求を変更できるように、 ストリーム制御サービスも規定しています。
すべての ALTO クライアント メッセージは、 ALTO サーバーからHTTP応答を引き出すREST HTTP 要求です。これらの要求と応答のペイロードは、階層的なキーと値のペアを含む JSONテキストで構成されます。
プロトコル構文
クライアントは、HTTP GET メッセージを介して IRD を取得します。RFC 7285 の次の例は、IRD の要求を示しています。要求されたターゲット (/directory) は、上記の DDDS サービス検出プロセスから取得されました。この IRD は、このサーバーで利用可能なサービスのターゲットと、許容されるパラメータを提供します。
GET /directory HTTP / 1.1
ホスト: alto.example.com
Accept : application/alto-directory+json、application/alto-error+json
HTTP / 1.1 200 OK
コンテンツ長: 2333
コンテンツタイプ: application/alto-directory+json
{
"meta" : { "cost-types" : { "num-routing" : { "cost-mode" : "numerical" 、"cost-metric" : "routingcost" 、"description" : "My default" }, "num-hop" : { "cost-mode" : "numerical" 、"cost-metric" : "hopcount" }, "ord-routing" : { "cost-mode" : "ordinal" 、"cost-metric" : "routingcost" }, "ord-hop" : { "cost-mode" : "ordinal" 、"cost-metric" : "hopcount" } }, "default-alto-network-map" : "my-default-network-map" }, "resources" : { "my-default-network-map" : { "uri" : "http://alto.example.com/networkmap" 、"メディアタイプ" ："application/alto-networkmap+json" }、"数値ルーティングコストマップ" ：{ "uri" ："http://alto.example.com/costmap/num/routingcost" 、"メディアタイプ" ："application/alto-costmap+json" 、"機能" ：{ "コストタイプ名" ：[ "num-routing" ] }、"使用" ：[ "my-default-network-map" ] }、"数値ホップカウントコストマップ" ：{ "uri" ："http://alto.example.com/costmap/num/hopcount" 、"メディアタイプ" ："application/alto-costmap+json" 、"機能" ：{ "コストタイプ名" ：[ "ホップ数" ] }, "uses" : [ "my-default-network-map" ] },「カスタムマップリソース」: { 「uri」: "http://custom.alto.example.com/maps」、「メディアタイプ」: "application/alto-directory+json" }、「エンドポイントプロパティ」: { 「uri」: "http://alto.example.com/endpointprop/lookup」、
"メディア タイプ" : "application/alto-endpointprop+json" 、"受け入れ" : "application/alto-endpointpropparams+json" 、"機能" : { "prop-types" : [ "my-default-network-map.pid" 、"priv:ietf-example-prop" ] }, }, "エンドポイント コスト" : { "uri" : "http://alto.example.com/endpointcost/lookup" 、"メディア タイプ" : "application/alto-endpointcost+json" 、"受け入れ" : "application/alto-endpointcostparams+json" 、"機能" : { "コスト制約" : true 、"コスト タイプ名" : [ "数値ルーティング" 、"ホップ数" 、"ord-routing" 、"ord-hop" ] } } } }
クライアントは、HTTP GET メッセージを介してマップ サービスを取得します。RFC 7285 の次の例は、ネットワーク マップの要求と、5 つのエンドポイントを 3 つの PID にグループ化する応答を示しています。
GET /networkmap HTTP / 1.1
ホスト: alto.example.com
Accept : application/alto-networkmap+json、application/alto-error+json
HTTP / 1.1 200 OK
コンテンツ長: 449
コンテンツタイプ: application/alto-networkmap+json
{
"meta" : { "vtag" : { "resource-id" : "my-default-network-map" , "tag" : "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" } }, "network-map" : { "PID1" : { "ipv4" : [ "192.0.2.0/24" , "198.51.100.0/25" ] }, "PID2" : { "ipv4" : [ "198.51.100.128/25" ] }, "PID3" : { "ipv4" : [ "0.0.0.0/0" ], "ipv6" : [ "::/0" ] } } }
他の 3 つのサービスは、クライアントがリクエスト ペイロードで提供する追加情報に依存します。HTTP GET にはリクエスト ペイロードがないため、クライアントは HTTP POST メソッドを使用してこれらのサービスにアクセスします。RFC 7285 の次の例は、1 つのソースから 3 つの潜在的な宛先までのコストのリクエストと応答を示しています。
POST /endpointcost/lookup HTTP / 1.1
ホスト: alto.example.com
コンテンツ長: 248
コンテンツタイプ: application/alto-endpointcostparams+json
Accept : application/alto-endpointcost+json、application/alto-error+json
{
"コストタイプ" : { "コストモード" : "序数" , "コストメトリック" : "ルーティングコスト" }, "エンドポイント" : { "srcs" : [ "ipv4:192.0.2.2" ], "dsts" : [ "ipv4:192.0.2.89" , "ipv4:198.51.100.34" , "ipv4:203.0.113.45" ] } }
HTTP / 1.1 200 OK
コンテンツ長: 274
コンテンツタイプ: application/alto-endpointcost+json
{
"meta" : { "cost-type" : { "cost-mode" : "ordinal" 、"cost-metric" : "routingcost" } }、"endpoint-cost-map" : { "ipv4:192.0.2.2" : { "ipv4:192.0.2.89" : 1 、"ipv4:198.51.100.34" : 2 、"ipv4:203.0.113.45" : 3 } } }
その他の拡張機能
数多くの追加標準により、プロトコルの使いやすさと機能セットが拡張されました。
- RFC 8189 [16]では、クライアントが1回の要求で複数のコストタイプ（ルーティングコストやホップ数など）を要求できる。
- RFC 8896 [17]では、「コストカレンダー」の概念が導入されており、サーバーはエンドポイントに到達するためのコストが時間の経過とともにどのように変化するかを表現できます。
- ALTOワーキンググループのIETFデータトラッカー[11]には、まだ作業中の文書が示されています。
参考文献
- ^ ab Seedorf, Jan; Burger, Eric (2009 年 10 月). アプリケーション層トラフィック最適化 (ALTO) 問題ステートメント. IETF . doi : 10.17487/RFC5693 . RFC 5693.
- ^ ab Alimi, Richard; Penno, Reinaldo; Yang, Richard; Kiesel, Sebastian; Prevedi, Stefano; Roome, Wendy; Shalunov, Stanislav; Woundy, Richard (2014 年 9 月). アプリケーション層トラフィック最適化 (ALTO) プロトコル. IETF . doi : 10.17487/RFC7285 . RFC 7285.
- ^ ab Kiesel, Sebastian; Prevedi, Stefano; Stiemerling, Martin; Woundy, Richard; Yang, Richard (2012 年 9 月). アプリケーション層トラフィック最適化 (ALTO) 要件. IETF . doi : 10.17487/RFC6708 . RFC 6708.
- ^ Kravets, David (2008年9月19日). 「Comcastがスロットリング慣行を公表 - BitTorrentが標的に」. wired.com . 2021年7月9日閲覧。
- ^ Peterson, Jon; Cooper, Alissa (2009 年 7 月). IETF ピアツーピア (P2P) インフラストラクチャに関するワークショップのレポート、2008 年 5 月 28 日。IETF . doi : 10.17487 /RFC5594 . RFC 5594.
- ^ 「Decoupled Application Data Enroute (decade)」. ietf.org . IETF . 2021年10月10日閲覧。
- ^ Shalunov, Stanislav; Hazel, Greg; Iyengar, Janardhan; Kuehlewind, Mirja (2012 年 12 月). Low Extra Delay Background Transport (LEDBAT). IETF . doi : 10.17487/RFC6817 . RFC 6817.
- ^ Bless, Roland (2019 年 6 月)。差別化サービス のための低労力ホップ単位動作 (LE PHB) 。IETF。doi : 10.17487 / RFC8622。RFC 8622 。
- ^ 「WGアクション：アプリケーション層トラフィック最適化（alto）」IESG事務局長。2008年11月12日。 2021年10月10日閲覧。
- ^ ab Kiesel, Sebastian; Stiemerling, Martin; Schwan , Nico; Scharf , Michael; Song, Haibin (2014 年 11 月). アプリケーション層トラフィック最適化 (ALTO) サーバー検出。IETF。doi : 10.17487 / RFC7286。RFC 7286。
- ^ ab 「IETF Datatracker: アプリケーション層トラフィック最適化 (ALTO)」。ietf.org。IETF 。 2021年10月10日閲覧。
- ^ Stiemerling, Martin; Kiesel, Sebastian; Scharf, Michael; Seidel , Hans; Prevedi, Stefano (2016 年 10 月)。アプリケーション層トラフィック最適化 (ALTO) の導入に関する考慮事項。IETF。doi : 10.17487 / RFC7971。RFC 7971 。
- ^ Gurbani, Vijay K.; Seedorf, Jan (2020年6月). 「IETFアプリケーション層トラフィック最適化（ALTO）プロトコルの進化」. IEEE Communications Standards Magazine . 4 (2): 9. doi : 10.1109/MCOMSTD.2020.9139037 .
- ^ Kiesel, Sebastian; Stiemerling, Martin (2020 年 2 月). アプリケーション層トラフィック最適化 (ALTO) クロスドメイン サーバー検出. IETF . doi : 10.17487/RFC8686 . RFC 8686.
- ^ Roome, Wendy; Yang, Richard (2020 年 11 月). Server-Sent Events (SSE) を使用したアプリケーション層トラフィック最適化 (ALTO) 増分更新. IETF . doi : 10.17487/RFC8895 . RFC 8895.
- ^ Randriamasy, Sabine; Roome, Wendy; Schwan, Nico (2017 年 10 月). マルチコスト アプリケーション層トラフィック最適化 (ALTO). IETF . doi : 10.17487/RFC8189 . RFC 8189.
- ^ Randriamasy, Sabine; Yang, Richard; Wu, Qin; Deng, Lingli; Schwan, Nico (2020 年 11 月). アプリケーション層トラフィック最適化 (ALTO) コストカレンダー. IETF . doi : 10.17487/RFC8896 . RFC 8896.