RFC831 日本語訳
0831 Backup access to the European side of SATNET. R.T. Braden. December 1982. (Format: TXT=11735 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Braden Request for Comments: 831 University College London December 1982
コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 831 ユニバーシティ・カレッジロンドン1982年12月
Backup Access to the European Side of SATNET
SATNETのヨーロッパの側面へのバックアップアクセス
Robert Braden
ロバート・ブレーデン
DISCUSSION
議論
The purpose of this RFC is to focus discussion on a particular Internet problem: a backup path for software maintenance of the European sector of the Internet, for use when SATNET is partitioned. We propose a mechanism, based upon the Source Routing option of IP, to reach European Internet sites via the VAN Gateway and UCL.
このRFCの目的は特定のインターネット問題に議論の焦点を合わせることです: インターネットのヨーロッパのセクターのソフトウェア・メンテナンス、SATNETが仕切られるときの使用のためのバックアップ道。 私たちは、VANゲートウェイとUCLを通してヨーロッパのインターネット・サイトに達するようにIPのSourceルート設定オプションに基づくメカニズムを提案します。
This proposal is not intended as a standard at this time.
この提案はこのとき、規格として意図しません。
Network Working Group R. Braden Request for Comments: 831 University College London December 1982
コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 831 ユニバーシティ・カレッジロンドン1982年12月
1. Introduction
1. 序論
During several previous SATNET meetings, it has been observed that it would be useful for BBN to be able to access the European side of SATNET indirectly via the VAN Gateway, when direct SATNET connectivity has been lost. This short paper proposes a possible approach to such "backup" access, using the source routing option of IP.
前のいくつかのSATNETミーティングの間、BBNが間接的にVANゲートウェイを通してSATNETのヨーロッパの側面にアクセスできるのが、役に立つと認められています、ダイレクトSATNETの接続性が失われたとき。 IPのソースルーティングオプションを使用して、この短期証券はそのような「バックアップ」アクセスへの可能なアプローチを提案します。
Figure 1 illustrates the problem we wish to solve. The US host H is used for diagnosis and control of the SATNET SIMP's S1 and S2 as well as the gateways B and G and the UCL TAC (not shown, but connected to G).
図1は解決したいと思う問題を例証します。 米国のホストHはゲートウェイBと同様にSATNET SIMPのS1とS2、G、およびUCL TAC(示されませんが、Gに接続される)の診断とコントロールに使用されます。
SATNET (partitioned) ARPANET/SATNET __ __ UCL Gateway Simp ( \ \ ) Simp Gateway ____ ___( / / )____ ____ | B |__| S1 | \ \ | S2 |________| G |_____ rsre |____| |____| / / |____| |____| | ( \ \ ) | | (__ / /__) _______|____ ________|____ ( ) ( ) ( ) ( ARPANET ) ( UCL NET ) ( ) ( ) (_____________) ( ) | | (_____________) __|_ | VAN/ . | H | | Public Data Nets . |____| | _____________ . Diagnostic | ( ) . Host __|__ ( VANNET ) _.___ | VAN |* * (* * * * * * * * *)* * * * | | | gw------(--- IP Tunnel -----)--------| U | |_____|* * (* * * * * * * * *)* * * |_____| VAN ( ) Gateway (_____________)
SATNET(仕切られる)アルパネット/SATNET__ __UCLゲートウェイSimp(\\)Simpゲートウェイ____ ___( / / )____ ____ | B|__| S1| \ \ | S2|________| G|_____ rsre|____| |____| / / |____| |____| | ( \ \ ) | | (__ / /__) _______|____ ________|____ ( ) ( ) ( ) (アルパネット) (UCLネット) ( ) ( ) (_____________) ( ) | | (_____________) __|_ | ヴァン/。| H| | 公衆データは網状になります。|____| | _____________ . 病気の特徴| ( ) . ホスト__|__ (VANNET) _.___ | ヴァン|* * (* * * * * * * * *)* * * * | | | gw------(-、--、IPがトンネルである-、-、-、--、)--------| U| |_____|* * (* * * * * * * * *)* * * |_____| VAN( )ゲートウェイ(_____________)
Figure 1. US/UK Connectivity with Partitioned SATNET
図1。 仕切られたSATNETがある米国/イギリスの接続性
RFC 831 - 1 - [Braden] Network Working Group R. Braden Request for Comments: 831 University College London December 1982
RFC831--1--[ブレーデン] コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 831 ユニバーシティ・カレッジロンドン1982年12月
VANgw is the VAN Gateway which encapsulates IP datagrams in X25 packets for transmission over VAN/PTT virtual circuits. The collection of these paths, called "IP tunnels" by UCL, is addressed from the Internet as a distinct network, VANNET.
VANgwはトランスミッションのためにX25パケットでVAN/PTTの仮想のサーキットの上にIPデータグラムを要約するVANゲートウェイです。 UCLによって「IPトンネル」と呼ばれたこれらの経路の収集は異なったネットワーク、VANNETとしてインターネットから記述されます。
U is a UCL host, the Terminal Protocol Converter, which provides a path to UK X25 networks. However, to the Internet world U looks like a host on VANNET, so the path from U to UCLNET (shown dotted) does not appear to exist.
UはUCLホスト、UK X25ネットワークに経路を提供するTerminalプロトコルConverterです。 しかしながら、したがって、UからUCLNET(点を打たれた状態で、目立つ)までの経路は存在するようにVANNETの上のホストのようなインターネットの世界U面相に、見えません。
Now suppose SATNET is partitioned between S1 and S2. Then we wish host H to be able to exchange IP datagrams with S2 via the "back door" path:
今度は、SATNETがS1とS2の間で仕切られると仮定してください。 次に、私たちは、ホストHに「裏口」経路を通してIPデータグラムをS2と交換できて欲しいと思います:
H - Internet - VANgw - VANNET - U - UCLNET - G - S2
H--インターネット--VANgw--VANNET--U--UCLNET--G--S2
There are some important rules in this game, however.
しかしながら、このゲームにはいくつかの重要な規則があります。
(1) U may only be a host, not a gateway.
(1) Uはゲートウェイではなく、ホストであるにすぎないかもしれません。
This is because we do not want the Internet to route ALL its traffic (e.g. rsre traffic and UCL traffic that is required to use SATNET) via the IP Tunnel. So the VAN Gateway (VANgw) must not discover it can get to UCLNET through U.
これは私たちが、インターネットにIP Tunnelを通してすべての交通(SATNETを使用するのに必要である例えば、rsre交通とUCL交通)を発送して欲しいと思わないからです。 それで、VANゲートウェイ(VANgw)は、それがUを通してUCLNETを始めることができると発見してはいけません。
(2) To implement the back door path to S2, we are willing to have some special code in H and/or in U, but not in G, S2, or VANgw.
(2) 私たちは、裏口経路をS2に実行するために、H Uに何らかの特別なコードを持っていることを望んでいますが、G、S2、またはVANgwで望んでいるというわけではありません。
Note: Jack Haverty is allowed to violate this assumption, though we doubt that he will want to. But we must stick to it.
以下に注意してください。 私たちは、彼がそうしたくなるのを疑問に思っていますが、ジャックHavertyはこの仮定に違反できます。 しかし、私たちはがんばらなければなりません。
Given these constraints, we claim that the only possible solution is to "mung" the headers of IP datagrams at UCL. Thus, when SATNET is partitioned:
これらの規制を考えて、私たちは、「唯一の可能な解決策がUCLでIPデータグラムのヘッダーに変更を加える」ことであると主張します。 したがって、いつSATNETは仕切られるか:
(1) The IP addresses of S2, G, and the UCL TAC are unreachable from all US gateways. Therefore, if H sends a packet addressed to one of these destinations, it will be discarded and an ICMP unreachable message returned.
(1) S2、G、およびUCL TACのIPアドレスはすべての米国ゲートウェイから手が届きません。 したがって、Hがこれらの目的地の1つまで記述されたパケットを送ると、捨てられて、ICMPの手の届かないメッセージは返されます。
RFC 831 - 2 - [Braden] Network Working Group R. Braden Request for Comments: 831 University College London December 1982
RFC831--2--[ブレーデン] コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 831 ユニバーシティ・カレッジロンドン1982年12月
(2) Similarly, the IP address of H is unreachable from the UK side. Hence, if the XNET debugger in a UK host emits a return packet addressed to H, that packet will be dropped.
(2) 同様に、HのIPアドレスはイギリスの側から手が届きません。 したがって、イギリスのホストのXNETデバッガがHに記述されたリターンパケットを放つと、そのパケットは落とされるでしょう。
Therefore, the destination address of each packet from H must be changed in order to reach the UCL side of SATNET (S2 or G), and the source address of each of these packets must be changed so that return packets can reach H. For this purpose, we introduce the Munger host M (see Figure 2).
したがって、SATNET(S2かG)のUCL側面に達するようにHからのそれぞれのパケットの送付先アドレスを変えなければなりません、そして、それぞれのこれらのパケットのソースアドレスはそれがパケット缶の範囲H.Forにこの目的を返して、変えて、私たちがミュンガーホストMを紹介するという(図2を見てください)ことであるに違いありません。
SATNET (partitioned) BBN __ __ UCL Gateway Simp ( \ \ ) Simp Gateway ____ ___( / / )____ ____ | B |__| S1 | \ \ | S2 |________| G |_____ rsre |____| |____| / / |____| |____| | ( \ \ ) | | (__ / /__) _______|____ ________|____ ( ) ( ) ( ) ( ARPANET ) ( UCL NET ) ( ) ( ) (_____________) ( ) | | (_____________) __|_ | | | H | | Public Data Nets | |____| | _______________ _|___ Diagnostic | ( ) | M1 | Host __|__ ( ) |:::::| | VAN |* * (* * * * * * * * * *) * * |:::::| | gw------(--- IP Tunnel -----)------------| M2 | |_____|* * (* * * * * * * * * *) * * |_____| VAN ( VANNET ) M Gateway (_______________) "Header Munger"
SATNET(仕切られる)BBN__ __UCLゲートウェイSimp(\\)Simpゲートウェイ____ ___( / / )____ ____ | B|__| S1| \ \ | S2|________| G|_____ rsre|____| |____| / / |____| |____| | ( \ \ ) | | (__ / /__) _______|____ ________|____ ( ) ( ) ( ) (アルパネット) (UCLネット) ( ) ( ) (_____________) ( ) | | (_____________) __|_ | | | H| | 公衆データネット| |____| | _______________ _|___ 病気の特徴| ( ) | M1| ホスト__|__ ( ) |:::::| | ヴァン|* * (* * * * * * * * * *) * * |:::::| | gw------(-、--、IPがトンネルである-、-、-、--、)------------| M2| |_____|* * (* * * * * * * * * *) * * |_____| ヴァン(VANNET)Mゲートウェイ(_______________)「ヘッダーミュンガー」
Figure 2. Introduction of Header Munger at UCL
図2。 UCLのヘッダーミュンガーの導入
Host "M" (M1/M2) is mulit-homed, appearing as host M2 on VANNET and as host M1 on UCLNET. Like host U (shown in Figure 1), host M2 is the end of an IP Tunnel which communicates with VANgw over an X25 virtual call.
ホスト「M」(M1/M2)は、UCLNETにmulit家へ帰って、VANNETの上のホストM2としてホストM1として現れる予定です。 ホストU(図1では、目立ちます)のように、ホストM2はX25バーチャルコールの上でVANgwとコミュニケートするIP Tunnelの端です。
RFC 831 - 3 - [Braden]
RFC831--3、-[ブレーデン]
Network Working Group R. Braden Request for Comments: 831 University College London December 1982
コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 831 ユニバーシティ・カレッジロンドン1982年12月
Suppose for example that host H desiollege London December 1982
1982年12月に例えば、そのホストH desiollegeがロンドンであると仮定してください。
Suppose for example that host H desires to reach the XNET debugger in the SIMP S2. H must send its packets with destination address M1; these will be routed to M1 via VANgw and the IP Tunnel. Host M will change the headers of these datagrams to contain source address M1 and destination S2. S2 will return packets to M1, and M1 will change them back to M2->H packets and launch them back through the VANNET to H.
例えば、ホストHが、SIMP S2のXNETデバッガに達することを望んでいると仮定してください。 Hは送付先アドレスM1があるパケットを送らなければなりません。 これらはVANgwとIP Tunnelを通してM1に発送されるでしょう。 ホストMは、ソースアドレスM1と目的地S2を含むようにこれらのデータグラムのヘッダーを変えるでしょう。 S2がパケットをM1に返して、M1はM2>Hパケットにそれらのもとに戻って、VANNETを通してそれらをHに始めるでしょう。
How does M know how to change the headers?
Mはどのようにヘッダーを変える方法を知っていますか?
(1) M could respond to a range of M1 and M2 addresses, and have a fixed table of correspondence.
(1) Mは、さまざまなM1とM2アドレスに応じて、通信の固定テーブルを持っているかもしれません。
(2) We propose instead to use the SOURCE ROUTING option in the datagrams. This assumes that H is able to build source-routed datagrams, and is not upset that the intermediate host in the route is not a gateway.
(2) 私たちは、代わりにデータグラムでSOURCE ROUTINGオプションを使用するよう提案します。これは、Hがソースによって発送されたデータグラムを組立てることができると仮定して、ルートによる中間的ホストがゲートウェイでないことがひっくり返されていません。
If we further assume that the IP layers in G and S2 can handle source and return routes, then the task is simple. M must contain the source routing algorithm of a gateway, but otherwise act as two hosts (no routing updates, etc).
私たちが、GとS2のIP層がソースと戻り経路を扱うことができるとさらに思うなら、タスクは簡単です。 Mはゲートウェイのソースルーティング・アルゴリズムを含まなければなりませんが、さもなければ、2人のホスト(ルーティングアップデートがありませんなど)として務めてください。
(3) Although G supports source routing, S2 and the TAC may not. In that case, S2 and the TAC will not be able to recognise the return route in a received packet and use it as a source route in packets sent in reply.
(3) Gはソースルーティングを支持しますが、S2とTACは支持するかもしれないというわけではありません。 その場合、S2とTACは、容認されたパケットの戻り経路を認識して、パケットの送信元経路が回答を送ったので、それを使用できないでしょう。
This possibility calls for additional complexity in M, a combination of (1) and (2):
この可能性はMの追加複雑さ、(1)と(2)の組み合わせを求めます:
* In the US -> UK direction, the Source Routing option would be used.
* 米国の->イギリスの方向に、Sourceルート設定オプションは使用されるでしょう。
* In the reverse direction (UK -> US), mapping of datagram addresses would be controlled by a table in M.
* 反対の方向(イギリスの->米国)に、データグラムアドレスに関するマッピングはMでテーブルによって制御されるでしょう。
RFC 831 - 4 - [Braden] Network Working Group R. Braden Request for Comments: 831 University College London December 1982
RFC831--4--[ブレーデン] コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 831 ユニバーシティ・カレッジロンドン1982年12月
We suggest that M use source routing to get packets from H to S2, and meanwhile build a "soft state" table showing this mapping. When a packet comes from S2 without source routing, M would consult this soft state table to discover how to alter the addresses to reach H again. This would allow only one US host at a time to access a given SATNET host, but surely this is no restriction.
私たちは、MがHからS2までパケットを得て、一方、「軟性国家」テーブル表示にこのマッピングを築き上げるのにソースルーティングを使用することを提案します。 パケットがS2からソースルーティングなしで来るとき、Mは、再びHに達するようにアドレスを変更する方法を発見するためにこの軟性国家テーブルに相談するでしょう。 これで、一度に1人の米国のホストだけが与えられたSATNETホストにアクセスできるでしょうが、確実に、これは制限ではありません。
In practice, M2 and U should have different IP tunnels and hence different DTE addresses. Since the caller pays the X25 charges, the IP Tunnel for U will normally be opened only by UCL. On the other hand, the IP Tunnel to M2 will be opened from the US end. Since UCL has only one PSS line, this requires the use of separate X25 subaddresses. The VAN gateway must handle 14 digit X121 addresses, as well as 12 digit addresses.
M2とUには、実際には、異なったIPトンネルとしたがって、異なったDTEアドレスがあるべきです。 訪問者がX25料金を支払うので、通常、UのためのIP Tunnelは単にUCLによって開かれるでしょう。 他方では、M2へのIP Tunnelは米国終わりから開かれるでしょう。 UCLには1つのPSS線しかないので、これは別々のX25 subaddressesの使用を必要とします。 VANゲートウェイはX121が12のケタアドレスと同様に記述する14ケタを扱わなければなりません。
2. Acknowledgment
2. 承認
Robert Cole of UCL has made major contributions to the contents of this paper. In particular, he suggested the use of the Source Routing option.
UCLのロバート・コールはこの紙のコンテンツへの主要な貢献をしました。 特に、彼はSourceルート設定オプションの使用を勧めました。
RFC 831 - 5 - [Braden]
RFC831--5、-[ブレーデン]
一覧
スポンサーリンク