RFC2170 日本語訳
2170 Application REQuested IP over ATM (AREQUIPA). W. Almesberger, J.Le Boudec, P. Oechslin. July 1997. (Format: TXT=22874 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Almesberger
Request for Comments: 2170 J. Le Boudec
Category: Informational P. Oechslin
LRC, DI-EPFL, Switzerland
July 1997
Almesbergerがコメントのために要求するワーキンググループW.をネットワークでつないでください: 2170年のJ.Le Boudecカテゴリ: 情報のP.Oechslin Lrc、ディ-EPFL、スイス1997年7月
Application REQuested IP over ATM (AREQUIPA)
アプリケーションは気圧でIPを要求しました。(アレキパ)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
IESG Note:
IESGは以下に注意します。
This RFC has not had the benefit of the rigorous peer review that is part of the process in an IETF working group. The technology it describes has been implemented and is now undergoing testing. It would be wise to analyze the results of this testing as well as to understand alternatives before committing to this approach for IP over ATM with QoS guarantees.
このRFCはIETFワーキンググループでプロセスの一部である厳しいピア・レビューの利益を持っていません。 それが説明する技術は、実装されて、現在、受けるテストです。 これがテストされるという結果を分析して、ATMの上でQoS保証でIPのためのこのアプローチに公約する前に代替手段を理解しているのは賢明でしょう。
Abstract
要約
This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This allows the requesting applications to benefit in a straightforward way from ATM's inherent ability to guarantee the quality of service (QoS).
このドキュメントは届いているATM雲の中にATM接続の上に終わらせる終わりに設定するダイレクトATMの接続性を持っているATMが付属しているホストにIPを許容するためのメソッドを指定します、アプリケーション、および要求アプリケーションによる専用を求める要求に関して。 これで、要求アプリケーションはサービスの質(QoS)を保証するATMの生来備わっている能力から簡単な方法で利益を得ます。
Given a mapping from service classes, as defined by INTSERV[6], to ATM traffic descriptors, Arequipa can be used to implement integrated services over ATM link layers. Usage of Arequipa to provide integrated services even if ATM is only available for intermediate links is not discussed in this document but should be straight- forward.
サービスのクラスからのマッピングを考えて、INTSERV[6]によって定義されるATMトラフィック記述子に、ATMリンクレイヤの上の統合サービスを実装するのにアレキパを使用できます。 ATMが単に中間的リンクに利用可能であっても、統合サービスを提供するアレキパの用法は、本書では議論しませんが、前方でまっすぐであるべきです。
The major advantage of using an approach like Arequipa is that it needs to be implemented only on the hosts using it. It requires no extra service (eg. NHRP or RSVP) to be deployed on the switches or routers of the ATM cloud.
アレキパのようなアプローチを使用する主要な利点はホストだけの上でそれを使用することで実装されるのが必要であるということです。 ATM雲のスイッチかルータで配布されるのが追加サービス(例えば、NHRPかRSVP)を全く必要としません。
Almesberger, et. al. Informational [Page 1] RFC 2170 AREQUIPA July 1997
et Almesberger、アル。 [1ページ]情報のRFC2170アレキパ1997年7月
We discuss the implementation of Arequipa for hosts running IPv4 and IPv6. As an illustration, we also discuss how World-Wide-Web applications can use Arequipa to deliver documents with a guaranteed quality of service.
私たちはホストの実行しているIPv4とIPv6のためにアレキパの実装について議論します。 また、イラストとして、私たちはWWWアプリケーションが保証されたサービスの質で書類を引き渡すのにどうアレキパを使用できるかについて議論します。
In particular we show how
特に、私たちはその方法を示しています。
- Arequipa can be implemented in IPv4 by slightly modifying the
- Arequipa can be implemented in IPv6[3] by the appropriate use of
flow labels and the extension of the neighbour cache,
- Arequipa can be used in the Web by adding extra information in
the headers of HTTP requests and responses.
- IPv4でわずかに変更することによってアレキパを実装することができる、--IPv6[3]で流れラベルの適切な使用と隣人キャッシュの拡大でアレキパを実装することができます--ウェブにHTTP要求と応答のヘッダーでその他の情報を加えることによって、アレキパを使用できます。
Finally, we address safety and security implications.
最終的に、私たちは、安全とセキュリティが含意であると扱います。
1. Introduction
1. 序論
QoS guarantees are important for delivery of multi-media data and commercial services on the Internet. When two applications on machines running IP over ATM need to transfer data, all the necessary gears to guarantee QoS can be found in the ATM layer. We consider the case where it is desired to use end-to-end ATM connections between applications residing on ATM hosts that have end-to-end ATM connectivity.
マルチメディアデータと商業サービスの配送に、QoS保証はインターネットで重要です。 ATMの上のマシン実行IPにおける2つのアプリケーションが、データを移す必要があるとき、ATM層の中でQoSを保証するすべての必要なギヤを見つけることができます。 私たちは、終わりから終わりへのATM接続性を持っているATMホストの上に住みながら、アプリケーションの間で終わりから終わりとのATM接続を使用するのが必要であるケースを考えます。
Opening direct ATM connections between two applications is possible, but then the already available transport protocols, like TCP, can not be reused.
2つのアプリケーションの間のダイレクトATM関係を開くのは可能ですが、TCPのように、既に利用可能なトランスポート・プロトコルを再利用できません。
This is why we propose Application REQuested IP over ATM (AREQUIPA). Arequipa allows applications to request that two machines be connected by a direct ATM connection with given QoS at the link level. Arequipa makes sure that only data from the applications that requested the connection actually goes through that connection. After setup of the Arequipa connection, the applications can use the standard IP protocol suite to exchange data.
これは私たちがATM(アレキパ)の上でApplication REQuested IPを提案する理由です。 アレキパは2台のマシンがリンク・レベルにおける与えられたQoSとのダイレクトATM接続によって接続されるようアプリケーションを要求させます。 アレキパは、接続を要求したアプリケーションからのデータだけが実際にその接続に直面しているのを確実にします。 アレキパの接続のセットアップの後に、アプリケーションは、データを交換するのに標準のIPプロトコル群を使用できます。
2. API semantics
2. API意味論
We now define a semantical API for Arequipa. Note that an actual API may perform additional functions (eg. mapping of a given service specification to ATM traffic descriptors)
私たちは現在、意味APIをアレキパと定義します。 実際のAPIが追加機能を実行するかもしれないことに注意してください。(例えば、ATMトラフィック記述子への与えられたサービス仕様に関するマッピング)
We define the three new API functions for the TCP/IP stack:
私たちはTCP/IPスタックのために3つの新しいAPI関数を定義します:
Arequipa_preset (socket_descriptor, destination IP address,
destination protid/port, destination ATM Address,
ATM service and QoS parameters)
あらかじめセットされたアレキパ_(ソケット_記述子、送付先IPアドレス、目的地protid/港、目的地ATM Address、ATMサービス、およびQoSパラメタ)
Almesberger, et. al. Informational [Page 2] RFC 2170 AREQUIPA July 1997
et Almesberger、アル。 [2ページ]情報のRFC2170アレキパ1997年7月
Arequipa_preset establishes or prepares establishment of a new ATM
connection to the given address with the given ATM service and QoS.
It makes sure that any further data sent on the specified socket
will use the new ATM connection.
あらかじめセットされたアレキパ_は与えられたATMサービスとQoSで新しいATM接続の設立を与えられたアドレスに設立するか、または準備します。 それは、どんな詳しいデータも、指定されたソケットが新しいATM接続を使用するのを転送したのを確実にします。
Arequipa_preset is invoked before a TCP/IP connection is
established or before sending data(grams), respectively. (Active
open.)
TCP/IP接続が確立される前かそれぞれ、データ(グラム)を送る前に、あらかじめセットされたアレキパ_は呼び出されます。 (アクティブな戸外。)
Arequipa_expect (socket_descriptor, allow)
アレキパ_は予想します。(ソケット_記述子、許容、)
Arequipa_expect prepares the system to use an expected incoming
Arequipa connection for outgoing traffic of a given socket. If
allow equals TRUE then, as soon as the socket receives data from an
incoming Arequipa connection, all its return traffic is sent over
that Arequipa connection. If allow equals FALSE the traffic from
that socket is always sent over the standard IP route. Note that
Arequipa_expect is only applicable to connection oriented sockets,
eg. TCP sockets or connected UDP sockets.
_が与えられたソケットの外向的なトラフィックに予想された入って来るアレキパの接続を使用するためにシステムを準備すると予想するアレキパ。 その時同輩にTRUEを許容してください、ソケットが入って来るアレキパの接続からデータを受け取って、そのアレキパの接続の上にすべてのリターントラフィックを送るとすぐに。 標準のIPルートの上にそのソケットからのトラフィックがいつも送られるFALSEを同輩に許容してください。 アレキパ_が接続だけに適切であると予想する注意は、ソケット、例えばTCPソケットを適応させたか、またはUDPソケットを接続しました。
Arequipa_expect is invoked by the peer which is expecting
data(grams) or accepting connections. (Passive open.) It is
typically called immediately after a socket has been created. It
may also be called when a data transfer is already going on.
データ(グラム)を予想している同輩によって呼び出されるか、または接続を受け入れていますアレキパ_が、予想する。 (受け身の戸外。) ソケットが作成された直後それは通常呼ばれます。 また、データ転送が既に先へ進むことであるとき、それは呼ばれるかもしれません。
Arequipa_close (socket_descriptor)
アレキパ_は閉じます。(ソケット_記述子)
Closes the corresponding ATM connection. Any further traffic
between the endpoints is routed like other traffic. Arequipa_close
is implied when closing the socket.
対応するATM接続を終えます。 終点の間のどんなさらなるトラフィックも他のトラフィックのように発送されます。 ソケットを閉じるとき、アレキパ_閉鎖は含意されます。
Note that the use of Arequipa_expect or _preset only reflects the direction of the initial dialog in the Arequipa connection. Actual data can flow in both directions.
アレキパ_の使用が予想するか、または_があらかじめセットした注意は初期の対話の方向をアレキパの接続に反映するだけです。 実際のデータは両方の方向に流れることができます。
An actual implementation may use less arguments for Arequipa_preset if some of the information is already passed by other networking operations.
実際の実装は何らかの情報が他のネットワーク操作で既に通過されるならあらかじめセットされたアレキパ_により少ない議論を使用するかもしれません。
3. Implementation with IPv4
3. IPv4がある実装
To implement Arequipa with IPv4, ATMARP must be able not only to handle associations of ATM addresses and IP addresses, but also associations of one ATM address with an IP address plus endpoint (socket). This allows to dedicate an ATM connection for the traffic between two endpoints.
ATMARPはIPv4と共にアレキパを実装するためには、ATMアドレスの協会を扱うために唯一でなくてIPのできるアドレスでなければなりませんが、1ATMの協会は、IPと共にアドレスがプラス終点(ソケット)であるとまた扱います。 これで、2つの終点の間のトラフィックのためのATM接続を捧げます。
Almesberger, et. al. Informational [Page 3] RFC 2170 AREQUIPA July 1997
et Almesberger、アル。 [3ページ]情報のRFC2170アレキパ1997年7月
For the active open, a destination ATM address must be associated with a socket. In systems using per-socket route and ARP caching, this can be done by presetting the caches with the appropriate values. Establishment of the SVC is delegated to ATMARP. Care must be taken that routing and ARP information obtained through Arequipa does not leak to other parts of the system.
アクティブな戸外に関しては、送付先ATMアドレスはソケットに関連しているに違いありません。 1ソケットあたりのルートを使用するシステムとARPキャッシュでは、適切な値でキャッシュをあらかじめセットすることによって、これができます。 SVCの設立をATMARPへ代表として派遣します。 注意は取って、アレキパを通って得られたそのルーティングとARP情報がシステムの他の部分に漏れないということであるに違いありません。
For the passive open, an incoming SVC must be associated with the socket that terminates the corresponding connection or data flow. Most of this functionality is already available in the existing protocol stack. To avoid an incoming Arequipa SVC to be mistaken for an IP-over-ATM SVC, the setup message uses a specific Broadband High Layer Identifier (BHLI), see below. Seeing the BHLI, ATMARP knows that the SVC is of the dedicated type. The socket to which it has to be associated is identified as soon as a datagram is received through the SVC. If an Arequipa_expect has been done for that socket, then the SVC is used for all return traffic of that socket.
受け身の戸外に関しては、入って来るSVCは対応する接続かデータフローを終えるソケットに関連しているに違いありません。 この機能性の大部分は既存のプロトコル・スタックで既に利用可能です。 IP過剰ATM SVCのために間違われます、セットアップメッセージが特定のBroadband High Layer Identifierを使用するという(BHLI)ことであるSVC、入って来るアレキパを避けるには、以下を見てください。 BHLIを見て、ATMARPは、ひたむきなタイプにはSVCがあるのを知っています。 SVCを通してデータグラムを受け取るとすぐに、それが関連していなければならないソケットは特定されます。 そのソケットのためにアレキパをしたなら、_が、予想するそのソケットのすべてのリターントラフィックにSVCを使用します。
If application A1 on host H1 wants a direct ATM connection to application A2 on host H2 it does the following:
ホストH1の上のアプリケーションA1がホストH2でダイレクトATM接続がアプリケーションA2に欲しいなら、以下をします:
Both applications first get in contact using the standard IP over ATM to exchange the ATM address of the receiver (atm2) and the endpoints (S1, S2) (i.e. protocol and port number; we assume that a protocol with ports, such as TCP or UDP, is used) at both hosts between which communication will occur. How this is performed depends on the application protocols. In Section 5 we give an example for HTTP.
両方のアプリケーションは、最初に、コミュニケーションが現れる両方のホストで受信機(atm2)と終点(S1、S2)(すなわち、数を議定書の中で述べて、移植してください; 私たちは、TCPかUDPなどのポートがあるプロトコルが使用されていると思う)のATMアドレスを交換するのにATMの上で標準のIPを使用することで接触に入ります。 これがどう実行されるかはアプリケーション・プロトコルによります。 セクション5では、私たちはHTTPのために作例を示します。
A2 invokes Arequipa_expect to indicate that it wants to make use of an expected incoming ATM connection.
A2はアレキパを呼び出します。_予想された入って来るATM接続を利用したがっているのを示すと予想してください。
A1 invokes Arequipa_preset to open or prepare opening of an ATM connection to H2 using ATM address atm2 and the QoS desired by A1 as soon as data is sent through S1. The connection is associated with S1 such that no other traffic (e.g. generated by other applications) uses the new ATM connection.
A1はATMアドレスatm2を使用することでATM接続の始まりをH2に開けるか、または準備するためにあらかじめセットされたアレキパ_とS1を通してデータを送るとすぐに、A1によって望まれていたQoSを呼び出します。 接続がS1に関連しているので、他のどんなトラフィック(例えば、他のアプリケーションで、生成される)も新しいATM接続を使用しません。
Almesberger, et. al. Informational [Page 4] RFC 2170 AREQUIPA July 1997
et Almesberger、アル。 [4ページ]情報のRFC2170アレキパ1997年7月
An Arequipa connection shall be signaled by using the procedures and codings described in RFC1755 [7], with the addition that the BHLI information element be included in the SETUP message, with the following coding:
RFC1755[7]で追加で説明された手順とコーディングを用いることによって、アレキパの接続はBHLI情報要素がSETUPメッセージに含まれていると合図されるものとします、以下のコード化で:
------------------------------------------------------------------
| bb_high_layer_information |
------------------------------------------------------------------
| high_layer_information_type 3 (vendor-specific |
| application id.) |
| high_layer_information 00-60-D7 (EPFL OUI) |
| 01-00-00-01 (Arequipa) |
------------------------------------------------------------------
------------------------------------------------------------------ | bbの_の高い_層_情報| ------------------------------------------------------------------ | 高い_層_情報_タイプ3(ベンダー詳細| | アプリケーションイド。) | | 高_層_情報00-60-D7(EPFL OUI)| | 01-00-00-01 (アレキパ)| ------------------------------------------------------------------
As soon as data arrives from H1:S1 at H2:S2, the ATM connection the data has arrived on is identified as the dedicated connection for this data flow and S2 is changed to exclusively send on that connection.
データがH1: S1からH2: S2に到着するとすぐに、排他的にその接続を転送するためにこのデータフローとS2のためのひたむきな接続を変えるとき、データが到着したATM接続を特定します。
From this point on all traffic exchanged between S1 of A1 and S2 of A2 will use the new ATM connection with the desired QoS.
A1のS1とA2のS2の間で交換されたこの地点から先はすべてのトラフィックが必要なQoSとの新しいATM接続を使用するでしょう。
Note that it is possible for H1 and H2 to belong to the same LIS [2] and still decide to use an Arequipa connection between applications, in addition to one or several other, non-Arequipa ATM connections between hosts H1 and H2. There may also exist several Arequipa connections between two hosts.
H1とH2が、同じLIS[2]に属して、1に加えたアプリケーションの間のアレキパの関係、またはホストのH1とH2とのいくつかの他の、そして、非アレキパのATM関係を使用するとまだ決めているのが、可能であることに注意してください。 また、2の間のアレキパの関係が接待する数個が存在するかもしれません。
4. Implementation with IPv6
4. IPv6がある実装
With IPv6, sources take advantage of the Flow Label field in the IPv6 header [3].
IPv6と共に、ソースはIPv6ヘッダー[3]のFlow Label分野を利用します。
We assume as in [4] that the conceptual host model uses, among others, a neighbour cache and a destination cache. The destination cache holds entries about destinations to which traffic has been sent recently, while the neighbour cache holds entries about neighbours to which traffic has been sent recently. With the classical IP over ATM model [1], entries in the neighbour cache can only refer to systems in the same LIS; we propose to go beyond this limitation and allow systems beyond the LIS to appear there and be treated as neighbours, in the case where a direct link level connection (here, an ATM connection) can be established.
私たちは概念的なホストモデルが使用する[4]、特に隣人キャッシュ、および目的地キャッシュのように仮定します。 目的地キャッシュは最近トラフィックを送る目的地に関してエントリーを保持します、隣人キャッシュがトラフィックが最近送られた隣人に関してエントリーを保持しますが。 ATMモデル[1]の上に古典的なIPがある状態で、隣人キャッシュにおけるエントリーは同じLISのシステムを示すことができるだけです。 私たちは、この制限を越えて、LISを超えたシステムがそこに現れて、隣人として扱われるのを許容するよう提案します、直リンクが接続を平らにする場合で(ここ、ATM接続) 設立できます。
The destination is keyed in [4] by the IP (destination) address. We replace this by the IP (destination) address and flow label.
目的地は[4]でIP(目的地)アドレスによって合わせられます。 私たちはこれをIP(目的地)アドレスと流れラベルに取り替えます。
Almesberger, et. al. Informational [Page 5] RFC 2170 AREQUIPA July 1997
et Almesberger、アル。 [5ページ]情報のRFC2170アレキパ1997年7月
We assume that with IPv6, a mechanism will be provided for applications to request flow labels which, at the host, form a unique flow-label/destination-address pair. This will prevent two different flows which go to the same destination from accidentally using the same flow label. Such a uniqueness requirement is also desirable for other applications which rely on flow-label/destination-address pairs, like for example RSVP.
私たちは、アプリケーションがホストで送付先ユニークな流れラベル/アドレス組を形成する流れラベルを要求するようにIPv6に、メカニズムが提供されると思います。 これは、同じ目的地に行く2回の異なった流れが偶然同じ流れラベルを使用するのを防ぐでしょう。 また、そのようなユニークさの要件も送付先流れラベル/アドレス組を当てにする他のアプリケーション、例えば、RSVPのように望ましいです。
A typical scenario is:
典型的なシナリオは以下の通りです。
Application A1 on host H1 and application A2 on host H2 first get in contact using the standard IP over ATM to exchange their ATM address (atm1, atm2) and to define a protocol, port number pair (S1, S2) and flow labels (L1, L2) for the communication over the ATM connection. (We assume that a protocol with ports, such as TCP or UDP, is used). How this is performed depends on the application protocols. In Section 5 we give an example for HTTP.
ホストH1の上のアプリケーションA1とホストH2の上のアプリケーションA2は最初にそれらのATMアドレス(atm1、atm2)を交換して、プロトコルを定義するのにATMの上で標準のIPを使用することで接触に入ります、そして、ポート番号は(S1、S2)を対にします、そして、流れはコミュニケーションのためにATM接続の上に(L1、L2)をラベルします。 (私たちは、TCPかUDPなどのポートがあるプロトコルが使用されていると思います。) これがどう実行されるかはアプリケーション・プロトコルによります。 セクション5では、私たちはHTTPのために作例を示します。
A2 tells its networking entity that it wants to send its outgoing packets with flow label L2 over an expected incoming ATM connection. A1 tells its data link entity to open an ATM connection to H2 using ATM address atm2, with the QoS desired by A1. The connection is associated with L1 and L2 as explained below so that no other traffic generated by other applications uses the new ATM connection.
A2は、予想された入って来るATM接続の上の流れラベルL2と共に出発しているパケットを送りたがっているとネットワーク実体に言います。 A1はATMアドレスatm2を使用することでATM接続をH2に開くためにデータ・リンク実体を言います、QoSがA1によって望まれている状態で。 接続が以下で説明されるようにL1とL2に関連しているので、他のアプリケーションで生成されなかった他のトラフィックは全く新しいATM接続を使用します。
From this point on all traffic exchanged between applications A1 on H1 and application A2 on H2 will use this ATM connection.
この地点から先はすべてのトラフィックがアプリケーションの間でA1をH1と交換しました、そして、H2の上のアプリケーションA2はこのATM接続を使用するでしょう。
An example of destination and neighbour cache entries at H1 is given below.
H1の目的地と隣人キャッシュエントリーに関する例は以下に出されます。
Destination Cache
IPAddr flowLabel neighbourCache pathMTU
H2 L1 ptr1 (1)
H2 * ptr2 (2)
目的地Cache IPAddr flowLabel neighbourCache pathMTU H2 L1 ptr1(1)H2*ptr2(2)
Neighbour Cache IPAddr linkLayerAddr isRouter reachabilityState invalidationTimer H2 v2 no (3) t2 R3 v3 yes REACHABLE t3
隣人Cache IPAddr linkLayerAddr isRouter reachabilityState invalidationTimer H2 v2いいえ(3)t2 R3 v3はいのREACHABLE t3
In the example, the route to destination H2 for all traffic other than the one using the ATM connection requested between application A1 and A2 uses the default route (perhaps set up by the classical IP model), with router R3 as the next hop; v2 is a pointer to an ATM interface and a VPCI/VCI that identifies the Arequipa connection. Similarly, v3 points to the ATM connection to router R3. ptr1 points
例では、アプリケーションA1とA2の間で要求されたATM接続を使用するもの以外のすべてのトラフィックのための目的地H2へのルートはデフォルトルートを使用します(恐らく古典的なIPモデルでセットアップしてください)、次のホップとしてのルータR3と共に。 v2はATMインタフェースとVPCI/VCIへのアレキパの接続を特定する指針です。 同様に、v3はATM接続をルータR3に示します。ptr1は指します。
Almesberger, et. al. Informational [Page 6] RFC 2170 AREQUIPA July 1997
et Almesberger、アル。 [6ページ]情報のRFC2170アレキパ1997年7月
to the first line in Neighbour Cache, and ptr2 to the second one. Path MTUs (1) and (2) are obtained by ATM signaling; they may be different. Reachability state (3) is determined as usual by the reachability protocol [4].
1日に、Neighbour Cache、および2番目のものへのptr2に立ち並んでください。 ATMシグナリングは経路MTUs(1)と(2)を得ます。 それらは異なっているかもしれません。 可到達性状態(3)は可到達性プロトコル[4]でいつものように決定しています。
Host H1 must restrict the use of this ATM connection to datagrams with flow label L1. Other traffic from H1 to H2 must use the generic entry in the destination table (flow label = "*"). Host H1 must restrict the use of flow label L1 for destination H2 to traffic generated by application A1 on port S1. (The same holds by analogy for host H2).
ホストH1は流れラベルL1と共にこのATM接続の使用をデータグラムに制限しなければなりません。 他のH1からH2までのトラフィックは目的地テーブル(流れラベル=「*」)でジェネリックエントリーを使用しなければなりません。 ホストH1は流れラベルL1の目的地H2の使用をポートS1でアプリケーションA1によって生成されたトラフィックに制限しなければなりません。 (同じくらいはホストH2のための類推を固守します。)
On the receiving side, host H2 may use label L1 for routing internally the IP packets to the appropriate entity.
受信側では、ホストH2が、内部的にIPパケットを適切な実体に発送するのにラベルL1を使用するかもしれません。
5. Example: Arequipa for the Web
5. 例: ウェブのためのアレキパ
This is a brief explanation of how Web [5] servers and browsers can use Arequipa to transmit documents with a guaranteed QoS.
これはウェブ[5]サーバとブラウザが保証されたQoSがあるドキュメントを伝えるのにどうアレキパを使用できるかに関する短い説明です。
What we describe below does not violate the standards of HTML and HTTP but makes use of their built-in extensibility. The server and client we describe can thus interact seamlessly with non-modified servers or clients. A similar extension could be used if Web documents were to be exchanged using RSVP.
私たちが以下で説明することは、HTMLとHTTPの規格に違反しませんが、彼らの内蔵の伸展性を利用します。 その結果、私たちが説明するサーバとクライアントはシームレスに非変更されたサーバかクライアントと対話できます。 ウェブドキュメントがRSVPを使用することで交換することであるなら同様の拡張子を使用できます。
Browsers add one extra field in all their requests or responses to indicate their ATM address. Web documents are extended with meta information to describe the ATM service and corresponding QoS needed to transmit them. Note that this information could be in form of an intserv flowspec and mapped to ATM traffic descriptors.
ブラウザは、それらのATMアドレスを示すために彼らのすべての要求か応答における1つの付加的な分野を加えます。 ウェブドキュメントはメタ情報で広げられて、ATMサービスについて説明した、対応するQoSは彼らを伝える必要がありました。 この情報がintserv flowspecの形にあったかもしれなくて、トラフィック記述子をATMに写像したことに注意してください。
If a browser always wants documents with QoS meta-information to be delivered using Arequipa, it adds an additional field in its request to indicate the port on which it is expecting the data.
ブラウザはアレキパを使用することでQoSメタ情報があるドキュメントを提供するのをいつも必要があるなら、それがそれがデータを予想しているポートを示すという要求における追加分野を加えます。
If a browser wants to decide whether Arequipa should be used or not, it does not give the port on which the server should send the data.
ブラウザが、アレキパが使用されるべきであるかどうか決めたいなら、それはサーバがデータを送るべきであるポートを与えません。
When a server gets a request with an ATM address, it checks whether the requested document has QoS meta-information. If this is not the case, it delivers the document like a standard server. If the document has QoS meta-information, the server looks for a port information in the request. If it finds a port, it opens an Arequipa socket (Arequipa_preset) to the ATM address of the client with the QoS given in the document. It sends the reply through this new connection. If the server finds no port information, it sends only the header of the reply (which includes meta-information) over the
サーバがATMアドレスによる要求を得るとき、それは、要求されたドキュメントにはQoSメタ情報があるかどうかチェックします。 これがそうでないなら、それは標準のサーバのようにドキュメントを提供します。ドキュメントにQoSメタ情報があるなら、サーバは要求におけるポート情報を探します。 ポートを見つけるなら、それはアレキパソケット(あらかじめセットされたアレキパ_)をドキュメントでQoSを与えていてクライアントのATMアドレスに開けます。 それはこの新しい接続で回答を送ります。 サーバがポート情報を全く見つけないなら、回答(メタ情報を含んでいる)のヘッダーだけを送る、終わっている。
Almesberger, et. al. Informational [Page 7] RFC 2170 AREQUIPA July 1997
et Almesberger、アル。 [7ページ]情報のRFC2170アレキパ1997年7月
standard HTTP connection, as if the client had issued a HEAD or GET- IF-MODIFIED request.
クライアントがHEADかGETを発行した標準のHTTP接続、-、MODIFIED、要求。
When a client receives the header of a document it can decide whether it wants the document to be transmitted using Arequipa or not. A client without a priori knowledge about the document, may therefore always want to retrieve the header before requesting the full document.
クライアントがドキュメントのヘッダーを受け取るとき、それは、アレキパを使用することでドキュメントを伝えて欲しいかどうか決めることができます。 ドキュメントに関する先験的な知識のないクライアント、したがって、完全なドキュメントを要求する前に、いつもヘッダーを救済したいかもしれません。
Illustration:
イラスト:
A client requests some documents but wants to decide if QoS sensitive documents should be sent using Arequipa or not. Thus it adds to its requests its ATM address but not the socket information.
クライアントは、いくつかのドキュメントを要求しますが、QoS機密書類はアレキパを使用させられるべきであるかどうか決めたがっています。 したがって、それはソケット情報ではなく、そのATMアドレスを要求に追加します。
GET batman.mpeg
UserAgent: MyAgent/1.0
ATM-address: my_public_address.my_private_address
GET batman.mpeg UserAgent: MyAgent/1.0気圧アドレス: 私の公共の_の_address.my_個人的な_アドレス
The server checks batman.mpeg for QoS meta info. It finds the meta info and sees an ATM address, but no socket pragma in the request. It only returns the header of the document, which includes the meta- information:
サーバはQoSメタインフォメーションがないかどうかbatman.mpegをチェックします。 それは、メタインフォメーションを見つけて、要求でATMアドレスにもかかわらず、ソケットがないpragmaを見ます。 それはメタ情報を含んでいるドキュメントのヘッダーを返すだけです:
HTTP/1.0 200 OK
Server: MyAgent/1.0
ATM-Service: CBR
ATM-QoS-PCR: 2000
Content-type: video/mpeg
HTTP/1.0 200OKサーバ: MyAgent/1.0気圧サービス: CBR気圧-QoS-PCR: 2000年の文書内容: ビデオ/mpeg
The client sees the QoS info and decides that it wants to download the document using Arequipa. It opens a TCP socket for listening, makes the Arequipa_expect call and sends the following request:
クライアントは、QoSインフォメーションを見て、アレキパを使用することでドキュメントをダウンロードしたがっていると決めます。 それは、聴取のためのTCPソケットを開けて、アレキパ_に電話をするように予想させて、以下の要求を送ります:
GET batman.mpeg
UserAgent: MyAgent/1.0
ATM-address: my_public_address.my_private_address
Pragma: socket=TCP.8090
GET batman.mpeg UserAgent: MyAgent/1.0気圧アドレス: 私の公共の_の_address.my_個人的な_アドレスPragma: ソケットはTCP.8090と等しいです。
Almesberger, et. al. Informational [Page 8] RFC 2170 AREQUIPA July 1997
et Almesberger、アル。 [8ページ]情報のRFC2170アレキパ1997年7月
Again the server checks batman.mpeg for QoS meta info. It finds the meta info and sees the ATM address and the socket pragma in the request. It creates a TCP socket, makes the Arequipa_preset call, connects its TCP socket to the one of the client and sends the response over the new TCP connection:
一方、サーバはQoSメタインフォメーションがないかどうかbatman.mpegをチェックします。 それは、要求でメタインフォメーションを見つけて、ATMアドレスとソケットpragmaを見ます。 それは、TCPソケットを作成して、_があらかじめセットしたアレキパを呼ばせて、TCPソケットをクライアントのひとりに接続して、新しいTCP接続の上に応答を送ります:
HTTP/1.0 200 OK
Server: MyAgent/1.0 ATM.address
ATM-Service: CBR
ATM-QoS-PCR: 2000
Content-type: video/mpeg
HTTP/1.0 200OKサーバ: MyAgent/1.0ATM.address気圧サービス: CBR気圧-QoS-PCR: 2000年の文書内容: ビデオ/mpeg
<mpeg data>
<mpegデータ>。
When the server sends the data over the new TCP connection it also sends a copy of the response header over the TCP connection on which the request was made. For example, this allows a browser to spawn a viewer before requesting the data, to give the Arequipa connection to the viewer and to still get the status of the request over the normal TCP connection.
また、サーバが新しいTCP接続の上にデータを送るとき、それは要求がされたTCP接続の上に応答ヘッダのコピーを送ります。 例えば、これで、ブラウザは、データを要求する前に、ビューアーを量産して、ビューアーとのアレキパの接続に与えて、まだ普通のTCP接続の上に要求の状態を届けています。
6. Safety considerations (loops)
6. 安全問題(輪)
A major concern about ATM shortcuts in IP networks are routing loops. Arequipa is not prone to such dangers since it establishes connections between applications and not between hosts. All datagrams traveling through an Arequipa connection are destined for a given socket on the machine at the end of the connection and don't need to be forwarded by the IP layer. Therefore, neither hosts nor routers implementing Arequipa as described in this document must ever forward IP packets received over Arequipa connections.
IPネットワークにおけるATM近道に関する主要な関心事はルーティング輪です。 アレキパは、ホストの間に関係を樹立するのではなく、アプリケーションの間に関係を樹立するので、そのような危険の傾向がありません。 アレキパの接続で移動するすべてのデータグラムは、与えられたソケットのために接続の終わりのマシンの上で運命づけられていて、IP層のそばで進められる必要はありません。 したがって、説明されるようにアレキパを実装しないホストもルータも本書ではアレキパの接続の上に受け取られたIPパケットを進めなければなりません。
7. Security considerations
7. セキュリティ問題
The main security problem we see with Arequipa is that it could be used to bypass IP firewalls.
私たちがアレキパと共に見る主な警備上の問題はIPファイアウォールを迂回させるのにそれを使用できたということです。
IP firewalls are used to protect private networks connected to untrusted IP networks. The network is configured such that all traffic going into or coming from the protected network has to go through the machine(s) acting as a firewall.
IPファイアウォールは、信頼されていないIPネットワークに接続された私設のネットワークを保護するのに使用されます。 ネットワークが構成されるので、保護されたネットワークから入るか、または来るすべてのトラフィックがファイアウォールとして機能しながら、マシンを通らなければなりません。
If hosts in a network protected by a firewall are able to establish direct ATM connections to hosts outside the protected network, then Arequipa could be used to bypass the firewall. To avoid this, hosts inside a protected network should not be given direct connectivity to the outside of the network.
ファイアウォールによって保護されたネットワークのホストが保護されたネットワークの外でダイレクトATM接続をホストに確立できるなら、アレキパは、ファイアウォールを迂回させるのに使用されるかもしれません。 これを避けるために、保護されたネットワークにおけるホストはダイレクト接続性をネットワークの外部に与えるべきではありません。
Almesberger, et. al. Informational [Page 9] RFC 2170 AREQUIPA July 1997
et Almesberger、アル。 [9ページ]情報のRFC2170アレキパ1997年7月
Arequipa can be used in a safe way by machines inside and outside a protected network, if an application proxy is installed on the firewall. In the Web, this is a typical scenario. Proxy HTTP servers are often found on firewalls, not only for security reasons, but also for caching. If an application proxy is used, each host can establish an Arequipa connection to the proxy which can then relay and monitor the traffic across the firewall.
ネットワークの中と、そして、保護されたネットワークの外でマシンで安全な方法でアレキパを使用できます、アプリケーションプロキシがファイアウォールの上にインストールされるなら。 ウェブでは、これは典型的なシナリオです。 プロキシHTTPサーバはセキュリティ理由に関して見つけられるだけではなく、ファイアウォールの上にしばしばキャッシュに関しても見つけられます。 アプリケーションプロキシが使用されているなら、各ホストはアレキパの接続をプロキシに確立できます(次に、ファイアウォールの向こう側にトラフィックをリレーして、モニターできます)。
Note that hosts can easily identify (and refuse) unsolicited Arequipa connections by the BHLI identifier that is passed at connection setup.
ホストが接続設定で通過されるBHLI識別子で容易に求められていないアレキパの接続を特定できることに(拒否してください)注意してください。
8. References
8. 参照
[1] Laubach, M., Classical IP and ARP over ATM, RFC1577,
January 1994.
[1]LaubachとM.と古典的なIPと気圧でのARP、RFC1577、1994年1月。
[2] Cole, R. G., D. H. Shur, C. Villamizar, IP over ATM: A Framework
Document, RFC1932, April 1996.
[2] コール、R.G.、D.H.シュル、C.Villamizar、気圧でのIP: フレームワークドキュメント、RFC1932、1996年4月。
[3] Hinden, R. and S. Deering, Internet Protocol Version (IPv6)
Addressing Architecture, RFC1884, December 1995.
[3] 1995年12月をアーキテクチャ、RFC1884に扱って、HindenとR.とS.デアリング、インターネットはバージョン(IPv6)について議定書の中で述べます。
[4] Narten, T., E. Nordmark and W.A. Simpson, Neighbour Discovery for
IPv6 (IPv6), RFC1970, August 1996.
[4] Narten(T.、E.Nordmark、およびW.A.シンプソン)は1996年8月にIPv6(IPv6)、RFC1970のための発見に近くに住みます。
[5] Berners-Lee, T., R. Fielding, H. Nielsen, Hypertext Transfer
Protocol -- HTTP/1.0, RFC1945, May 1996.
[5] バーナーズ・リー、T.、R.フィールディング、H.ニールセン、ハイパーテキストはプロトコルを移します--RFC1945、5月1996HTTP/1.0、日。
[6] Shenker, S./J. Wroclawski, Network Element Service Specification
Template, Work in Progess, November, 1995.
[6]Shenker、S./J。 Wroclawski(ネットワーク要素サービス仕様テンプレート)はProgess、1995年11月に働いています。
[7] Perez, M., F.-C. Liaw, A. Mankin, E. Hoffman, D. Grossman, A.
Malis, ATM Signaling Support for IP over ATM, RFC1755, February
1995.
[7] ペレス、M.、F.C。 Liaw、A.マンキン、E.ホフマン、D.グロースマン、A.Malis、気圧シグナリングはIPのために気圧、RFC1755の上で2月が1995であるとサポートします。
9. Authors' Address
9. 作者のアドレス
Werner Almesberger,
Jean-Yves Le Boudec,
Philippe Oechslin (contact author)
ヴェルナーAlmesberger、ジーン-イヴLe Boudec、フィリップOechslin(接触作者)
Laboratoire de Reseaux de Communication
Swiss Federal Institute of Technology (EPFL)
1015 Lausanne
Switzerland
Laboratoire de Reseaux de Communicationスイス連邦工科大学(EPFL)1015ローザンヌスイス
email: {almesber, leboudec, oechslin}@di.epfl.ch
メール: よりalmesberであって、leboudecであって、oechslinな@di.epfl.ch
Almesberger, et. al. Informational [Page 10]
et Almesberger、アル。 情報[10ページ]
一覧
スポンサーリンク
