RFC1306 日本語訳

Network Working Group                                       A. Nicholson
Request for Comments: 1306                                      J. Young
                                                     Cray Research, Inc.
                                                              March 1992

コメントを求めるワーキンググループA.ニコルソン要求をネットワークでつないでください: 1306 1992年のJ.の若いクレイ・リサーチの行進

     Experiences Supporting By-Request Circuit-Switched T3 Networks

要求による回路で切り換えられたT3ネットワークをサポートするという経験

Status of this Memo

このMemoの状態

   This RFC provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

このRFCはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。

Abstract

要約

   This memo describes the experiences of a project team at Cray
   Research, Inc., in implementing support for circuit-switched T3
   services.  While the issues discussed may not be directly relevant to
   the research problems of the Internet, they may be interesting to a
   number of researchers and implementers.

このメモはクレイ・リサーチで回路で切り換えられたT3サービスのサポートを実装する際にプロジェクト・チームの経験について説明します。 議論した問題が直接インターネットの研究課題に関連していないかもしれない間、それらは多くの研究者とimplementersにおもしろいかもしれません。

   Developers at Cray Research, Inc. were presented with an opportunity
   to use a circuit-switched T3 network for wide area networking.  They
   devised an architectural model for using this new resource.  This
   involves activating the circuit-switched connection when an
   application program engages in a bulk data transfer, and releasing
   the connection when the transfer is complete.

広い領域ネットワークに回路で切り換えられたT3ネットワークを使用する機会をクレイ・リサーチの開発者に与えました。 彼らは、この新しいリソースを使用するために建築モデルについて工夫しました。 これは、アプリケーション・プログラムがバルク・データ転送に従事しているとき、回線交換接続を起動して、転送が完全であるときに接続を釈放することを伴います。

   Three software implementations for this feature have been tested, and
   the results documented here.  A variety of issues are involved, and
   further research is necessary.  Network users are beginning to
   recognize the value of this service, and are planning to make use of
   by-request circuit-switched networks.  A standard method of access
   will be needed to ensure interoperability among vendors of circuit-
   switched network support products.

この特徴のための3つのソフトウェア実行が、テストされていてここに記録された結果です。 さまざまな問題がかかわります、そして、さらなる研究が必要です。 ネットワーク利用者は、このサービスの価値を認識し始めていて、要求による回路交換ネットワークを利用するのを計画しています。 アクセスの標準方法が、回路交換網サポート製品のベンダーの中で相互運用性を確実にするのに必要でしょう。

Acknowledgements

承認

   The authors thank the T3 project team and other members of the
   Networking Group at Cray Research, Inc., for their efforts: Wayne
   Roiger, Gary Klesk, Joe Golio, John Renwick, Dave Borman and Craig
   Alesso.

作者はクレイ・リサーチでNetworking GroupのT3のプロジェクト・チームの、そして、他のメンバーに感謝します、彼らの取り組みのために: ウェインRoiger、ゲーリーKlesk、ジョーGolio、ジョン・レンウィック、デーヴ・ボーマン、およびクレイグAlesso。

Nicholson & Young                                               [Page 1]

RFC 1306          Experiences with Circuit-Switched T3        March 1992

回路で切り換えられたT3 March 1992のニコルソンと若い[1ページ]RFC1306経験

Overview

概要

   Users of wide-area networks often must make a compromise between low
   cost and high speed when accessing long haul connections.  The high
   money cost of dedicated high speed connections makes them
   uneconomical for scientists and engineers with limited budgets.  For
   many traditional applications this has not been a problem.  Datasets
   can be maintained on the remote computer and results were presented
   in a text-only form where a low-speed connection would suffice.
   However, for visualization and other data transfer intensive
   applications, this limitation can severely impact the usability of
   high performance computing tools which are available only through
   long-haul network connections.

長期接続にアクセスするとき、広域ネットワークのユーザは低価格と高速の間でしばしば妥協しなければなりません。 ひたむきな高速接続の高い貨幣的原価で、彼らは科学者と技術者にとって限られた予算で不経済になります。 多くの伝統的なアプリケーションのために、これは問題ではありません。 リモート・コンピュータでデータセットを維持できました、そして、低速接続が十分であるだろうところに結果はテキストのみフォームに提示されました。 しかしながら、想像と他のデータ転送の徹底的なアプリケーションのために、この制限は厳しく長期ネットワーク接続だけで利用可能なツールを計算する高性能のユーザビリティに影響を与えることができます。

   Supercomputers are one such high performance tool.  Many users who
   can benefit from access to supercomputers are limited by slow network
   connections to a centrally located supercomputer.  A solution to this
   problem is to use a circuit-switched network to provide high speed
   network connectivity at a reduced cost by allocating the network only
   when it is needed.

スーパーコンピュータはそのようなツールの高性能1つです。 スーパーコンピュータへのアクセスの利益を得ることができる多くのユーザが中心に位置しているスーパーコンピュータへの遅いネットワーク接続によって制限されます。 この問題への解決はそれが必要であるときにだけネットワークを割り当てることによって割引料金における高速ネットワークの接続性を提供するのに回路交換ネットワークを使用することです。

   Consider how a researcher using a visualization application might
   efficiently use a dedicated low speed link and a circuit switched
   high speed link.  The researcher logs in to the remote supercomputer
   over the low speed link.  After running whatever programs are
   necessary to prepare the visualization, the high speed connection is
   activated and used to transfer the graphics data to the researcher's
   workstation.

想像アプリケーションを使用している研究者がどのように効率的に専用低速リンクと回路の切り換えられた高速リンクを使用するかもしれないか考えてください。 研究者は低速リンクの上にリモートスーパーコンピュータにログインします。 どんな想像を準備するのに必要なプログラムも動かした後に、高速接続は、グラフィックスデータを研究者のワークステーションに移すのに起動されて、使用されます。

   We built and demonstrated this capability in September, 1990, at the
   Telecommunications Association show in San Diego, using this type of
   visualization application.  Further, it will be available in a
   forthcoming release of our system software.

私たちは、1990年9月にこの能力を築き上げて、示しました、サンディエゴのTelecommunications Associationショーで、このタイプの想像適用を使用して。 さらに、それは私たちのシステムソフトの今度のリリースで利用可能になるでしょう。

Architectural Model

建築モデル

   We developed our support for circuit switched services around a
   simple model of a switched network.  At some point in the path
   between two hosts, there is a switched network connection.  This
   connection is likely to connect two enterprise networks operated by
   the same organization.  Administrative overlap between the two
   networks is useful for accounting and configuration purposes.  We
   believe that with further investigation circuit switched network
   support could be extended to multiple switched links in an internet
   environment.

私たちは交換網の単純モデルの周りで回路の切り換えられたサービスのサポートを開発しました。 2人のホストの間の経路の何らかのポイントに、交換網接続があります。 この接続は同じ組織によって経営された2つの企業網を接続しそうです。 2つのネットワークの間の管理オーバラップは会計と構成目的の役に立ちます。 私たちは、インターネット環境でさらなる調査回路交換網サポートがあるそれを複数の切り換えられたリンクに広げることができたと信じています。

   The switch which makes the network connection operates on a "by-
   request" basis (also called "on-demand").  When it receives a request

ネットワーク接続がaでそれの造を操作するスイッチは基礎(また、「要求次第である」と呼ばれる)を「要求します」。 それが要求を受け取るとき

Nicholson & Young                                               [Page 2]

RFC 1306          Experiences with Circuit-Switched T3        March 1992

回路で切り換えられたT3 March 1992のニコルソンと若い[2ページ]RFC1306経験

   to make a network connection it will do so (if possible), and breaks
   the connection when requested.  The switch will not activate
   automatically if there is an attempt to transfer data over an
   incomplete connection.

それは、ネットワーク接続を作るために、そう(できれば)して、要求されると、電話を切ります。 不完全な接続の上にデータを移す試みがあると、スイッチは自動的に動かさないでしょう。

   We also made the assumption that the circuit would be switched on a
   connection basis rather than a packet basis.  When an application
   begins sending data utilizing the switched connection, it will send
   all the data it has, without stopping, until it is finished.  At this
   time it will release the connection.  It is assumed that the quantity
   of data will be large enough that the circuit setup time is
   negligible relative to the period of the transfer.  Otherwise, it is
   not worth the effort to support the circuit switched network for
   small data transfers.

また、私たちは回路がパケット基礎よりむしろ接続ベースで切り換えられるだろうという仮定をしました。 データがアプリケーションで切り換えられた接続を利用し始めると、持っているすべてのデータを送るでしょう、止まらないで、それが終わるまで。 このとき、それは接続を釈放するでしょう。 データの量が転送の一区切りに比例して回路準備時間が取るにたらないほど大きくなると思われます。 さもなければ、小さいデータ転送のために回路交換網をサポートするのは取り組みの価値がありません。

   This model requires that just before the application begins a large
   bulk transfer of data, a request message is sent to the switch asking
   that the switched network connection be activated.  Once the link is
   up, the application begins sending data, and the network routes all
   the data from the application through the switched network.  As soon
   as all the data has been sent, a message is sent to the switch to
   turn off the switched link, and the network returns to routing data
   through the slower link.

このモデルは、アプリケーションがデータの大きいバルク転送を始めるすぐ前に要求メッセージが交換網接続が起動されるように頼むスイッチに送られるのを必要とします。 リンクがいったん上がるようになると、アプリケーションはデータを送り始めます、そして、ネットワークはアプリケーションから交換網まですべてのデータを発送します。 すべてのデータを送るとすぐに、切り換えられたリンクをオフにするためにメッセージをスイッチに送ります、そして、ネットワークは、より遅いリンクを通してルーティングデータに戻ります。

   The prototype system we built for the TCA show was designed around
   this model of circuit switched services.  We connected a FDDI
   backbone at Cray Research in Eagan, Minnesota to the TCA show's FDDI
   network through 2 NSC 703 FDDI/T1/T3 routers.  MCI provided a
   dedicated T1 line and a switched T3 line, using a DSC DS3 T3 switch
   located in Dallas, Texas.  These networks provided connectivity
   between a Cray Research computer in Eagan to a Sun workstation on the
   show floor in San Diego.

TCAショーが回路のこのモデルの周りで設計されたので、私たちが組立てたプロトタイプ装置はサービスを切り換えました。 私たちはイーガンでクレイリサーチでFDDIバックボーンを接続して、2を通したTCAショーのFDDIネットワークへのミネソタはNSC703FDDI/T1/T3ルータです。 MCIはひたむきなT1系列と切り換えられたT3系列を提供しました、ダラス(テキサス)に位置するDSC DS3 T3スイッチを使用して。 これらのネットワークはサンディエゴの展示会場でSunワークステーションへのイーガンのクレイリサーチコンピュータの間に接続性を供給しました。

Alternative Solution Strategies

代替のソリューション戦略

   The first aspect of using the switched services involved the circuit
   switch.  The DS3 switch available to us was accessed via a dial up
   modem, and it communicated using a subset of the CCITT Q.295
   protocol.  Activating the switch required a 4 message exchange and
   deactivation required a 3 message exchange.  We felt the protocol was
   awkward and might be different for other switch hardware.
   Furthermore, we believed that the dial up aspect of communicating
   with the switch suffered from the same drawbacks.  A good solution
   would require a cleaner method of controlling the switch from the
   source host requesting the switched line.

切り換えられたサービスを利用する最初の局面は回線交換機にかかわりました。 私たちにとって、利用可能なDS3スイッチはダイヤルアップモデムを通してアクセスされました、そして、それは、CCITT Q.295プロトコルの部分集合を使用することで交信しました。 スイッチを動かすのは4交換処理を必要としました、そして、非活性化は3交換処理を必要としました。 私たちはプロトコルが厄介であり、他のスイッチハードウェアにおいて、異なるかもしれないと感じました。 その上、私たちは、スイッチとコミュニケートするダイヤルアップ局面が同じ欠点に苦しんだと信じていました。 良いソリューションは交換回線を要求する送信元ホストからスイッチを制御するクリーナーメソッドを必要とするでしょう。

   The next aspect of using switched services involves the source host
   software which requests and releases the switched network.  Ideally,

切り換えられたサービスを利用する次の局面は交換網を要求して、リリースする送信元ホストソフトウェアにかかわります。 理想的に

Nicholson & Young                                               [Page 3]

RFC 1306          Experiences with Circuit-Switched T3        March 1992

回路で切り換えられたT3 March 1992のニコルソンと若い[3ページ]RFC1306経験

   the switched network is activated just before data transfer takes
   place and it is released as soon as all data has been sent.  We
   considered using special utility programs which a user could execute
   to control the link, special system libraries which application
   programs could call, or building the capability into the kernel.  We
   also considered the possibility that these methods could send
   messages to a daemon running on the source host which would then
   communicate with another entity actually controlling the switch.

データ転送が行われるすぐ前に交換網は活性です、そして、すべてのデータを送るとすぐに、それはリリースされます。 私たちは、ユーザがリンク、それのアプリケーション・プログラムが呼ぶことができた特別なシステムライブラリを制御するために作成できた特別なユティリティプログラムを使用するか、または能力をカーネルに組み込むと考えました。 また、私たちはこれらのメソッドが送信元ホストでの次に実際にスイッチを制御する別の実体で交信するデーモン実行にメッセージを送るかもしれない可能性を考えました。

   The last aspect of using switched services we considered is selection
   of the switch controlled network.  This involves both policy issues
   and routing issues.  Policy issues include which users running which
   applications will be able to use higher cost switched links.  And
   packets must be routed amongst multiple connections offering varying
   levels of service after they leave their source.

私たちがスイッチの選択であると考えた切り換えられたサービスを利用する最後の局面はネットワークを制御しました。 これは政策問題とルーティング問題の両方にかかわります。 政策問題は、どのアプリケーションを実行するかと、より高く使用できるどちらのユーザが切り換えられたリンクかかるかを含んでいます。 そして、彼らのソースを出た後に異なったレベルのサービスを提供する複数の接続の中でパケットを発送しなければなりません。

Implementations

実装

   We have developed a model for switch control through the internetwork
   which we believe to be reasonable.  However, we have experimented
   with three different source host implementations.  These different
   implementations are detailed here.

私たちは私たちが妥当であると信じているインターネットワークを通したスイッチ制御装置のためにモデルを開発しました。 しかしながら、私たちは3つの異なったソースホスト導入を実験しました。 これらの異なった実装はここで詳細です。

Switch control

スイッチ制御装置

   Our simplest design decisions involved the switch itself.  We decided
   that the complex protocol and dial up line must be hidden from the
   source host requesting the switched link.  We decided that the source
   host would use a simple request/release protocol with messages sent
   through the regular network (as opposed to dial up lines or other
   connections).  Some host accessible through the local network would
   run a program translating the simple request and release messages
   into the more complicated switch protocol and also have the modem to
   handle the dial up connection.

私たちの最も簡単なデザイン決定はスイッチ自体にかかわりました。 私たちは、切り換えられたリンクを要求する送信元ホストから複雑なプロトコルとダイヤルアップ系列を隠さなければならないと決めました。 私たちは、送信元ホストがレギュラー・ネットワーク(ダイヤルアップ系列か他の接続と対照的に)を通して送るメッセージと共に簡単な要求/リリースプロトコルを使用すると決めました。 企業内情報通信網を通してアクセスしやすいホストは、簡単な要求とリリースメッセージをより複雑なスイッチプロトコルに翻訳するプログラムを動かして、また、ダイヤルアップ接続を扱うモデムを持っているでしょう。

   This has a variety of advantages.  First, it isolates differences in
   switch hardware.  Second, multiple hosts may access the switch
   without requiring multiple modems for the dial up line.  And it
   provides a central point of control for switch access.  We did not
   consider any alternatives to this model of switch control.

これには、さまざまな利点があります。 まず最初に、それはスイッチハードウェアの違いを隔離します。 2番目に、ダイヤルアップ系列のために複数のモデムを必要としないで、複数のホストがスイッチにアクセスするかもしれません。 そして、それはスイッチアクセサリーのためのコントロールの主要なポイントを提供します。 私たちはスイッチ制御装置のこのモデルへのどんな選択肢も考えませんでした。

   Our initial implementation used a simple translator daemon running on
   a Sun workstation.  Listening on a raw IP port, this program would
   wait for switch control messages.  Upon receipt of such a message, it
   would dial up the switch and attempt to handle the request.  It would
   then send back a success or failure response.  This host, in
   conjunction with the translator daemon software, is referred to as
   the switch controller.  The switch controller we used was local to

私たちの初期の実装は、Sunワークステーションで動きながら、簡単な翻訳者デーモンを使用しました。 生のIPポートの上で聴いて、このプログラムはスイッチコントロールメッセージを待っているでしょう。 そのようなメッセージを受け取り次第そうするだろう、ダイヤルアップ、スイッチと要求を扱う試み。 そして、それは成否応答を返送するでしょう。 翻訳者デーモンソフトウェアに関連して、このホストはスイッチコントローラと呼ばれます。 私たちが使用したスイッチコントローラは地元でした。

Nicholson & Young                                               [Page 4]

RFC 1306          Experiences with Circuit-Switched T3        March 1992

回路で切り換えられたT3 March 1992のニコルソンと若い[4ページ]RFC1306経験

   our enterprise network; however, it could reside anywhere in the
   Internet.

私たちの企業網。 しかしながら、それはインターネットでどこでも住むことができました。

   Later we designed a simple protocol for switch control, which was
   implemented in the translator daemon.  This protocol is documented in
   RFC 1307, "Dynamically Switched Link Control Protocol".

その後、私たちは翻訳者デーモンで実施されたスイッチ管理のために簡単なプロトコルを設計しました。 RFC1307、「ダイナミックに切り換えられたリンク制御プロトコル」でこのプロトコルは記録されます。

Source Control of the Switched Link

切り換えられたリンクのソースコントロール

   This problem involves a decision regarding what entity on the source
   host will issue the switch request and release messages to the switch
   controller, and when those messages will be issued.  Because we do
   not have very much field experience with this service, we do not feel
   that it is appropriate to recommend one method over the others.  They
   all have advantages and disadvantages.

この問題は送信元ホストの上のどんな実体がスイッチ要求とリリースメッセージをスイッチコントローラに出すだろうか、そして、いつそれらのメッセージを発行するかに関する決定にかかわります。 このサービスの非常に多くの実地経験がないので、私たちは、他のものの上で1つのメソッドを推薦するのが適切であると感じません。 彼らには皆、利点と損失があります。

   What we did do is make 3 different implementations of the request
   software and can report our experiences with each.  These are one set
   of special utility programs which communicate with the switch
   controller, and 2 kernel implementations.  We did not experiment with
   special libraries, nor did we implement a daemon for switch control
   messages on the source host.

私たちがしたことは、要求の3つの異なった実装をソフトウェアにすることであり、それぞれの私たちの経験を報告できます。 これらは、スイッチコントローラとコミュニケートする1セットの特別なユティリティプログラムと、2つのカーネル実装です。 私たちは専門図書館を実験しませんでした、そして、送信元ホストに関するスイッチコントロールメッセージのためにデーモンを実装しませんでした。

Switch control user programs

スイッチ制御ユーザ・プログラム

   This implementation of source host control of the switch is the
   simplest.  Two programs were written which would communicate requests
   to the switch controller; one for activating the connection, and
   another to deactivate the connection.  The applications using this
   feature were then put into shell scripts with the switch control
   programs for simple execution.

スイッチの送信元ホストコントロールのこの実装は最も簡単です。 スイッチコントローラに要求を伝える2つのプログラムが書かれました。 接続を非活性化するために接続、および別のものを起動するためのもの。 そして、簡単な実行のためのスイッチ制御プログラムと共にこの特徴を使用するアプリケーションをシェルスクリプトに入れました。

   This approach has the significant advantage of not requiring any
   kernel modifications to any machine.  Furthermore, application
   programs do not need to be modified to access this feature.  And
   access to the circuit-switched links can be controlled using the
   access permissions for the switch-control programs.

このアプローチには、どんなマシンへの少しのカーネル変更も必要としない重要な利点があります。 その上、この特徴にアクセスするようにアプリケーション・プログラムは変更される必要はありません。 そして、スイッチ制御プログラムにアクセス許容を使用することで回路で切り換えられたリンクへのアクセスを制御できます。

   However, there are disadvantages as well.  First, there is
   significant potential for the switch to be active (and billing the
   user) for the dead time while the application program is doing tasks
   other than transferring bulk data.  The granularity of turning the
   switch on and off is limited to a per-application basis.

しかしながら、また、難点があります。 まず最初に、スイッチがアクティブな(ユーザに請求して)嵩を移すのを除いて、アプリケーション・プログラムが仕事している間の不動作時間の間、データである大きな潜在的可能性があります。 断続的にスイッチをターンする粒状は1アプリケーションあたり1つの基礎に制限されます。

   Another disadvantage is that most applications use only the
   destination host's address for transfer, and this is the only
   information available to the transport and network layers for routing
   data packets.  Some other method must be used to distinguish between

別の不都合はほとんどのアプリケーションが転送にあて先ホストだけのアドレスを使用するということです、そして、これはルーティングデータ・パケットに、輸送とネットワーク層に利用可能な唯一の情報です。 ある他のメソッドは見分けるのにおいて使用されているに違いありません。

Nicholson & Young                                               [Page 5]

RFC 1306          Experiences with Circuit-Switched T3        March 1992

回路で切り換えられたT3 March 1992のニコルソンと若い[5ページ]RFC1306経験

   traffic which should use the circuit-switched connection and lower-
   priority traffic.  This problem can be addressed using route aliases,
   described below.

回線交換接続を使用するべきであるトラフィックと下側の優先権トラフィック。 以下で説明されたルート別名を使用することでこの問題を扱うことができます。

Kernel switch control

カーネルスイッチ制御装置

   We have made two different implementations of switch control
   facilities within the operating system kernel.  Both rely upon the
   routing lookup code in the kernel to send switch connect and tear
   down messages.  The difference is in how the time delay between
   request of the switch and a response is handled.

私たちはオペレーティングシステムカーネルの中でスイッチ制御装置の2つの異なった実装を施設にしました。 両方が、発信するためにカーネルにおけるルーティングルックアップコードを当てにされます。スイッチは、メッセージを接続して、取りこわします。 違いがスイッチの要求と応答の間の時間遅れがどう扱われるかであります。

   For starters, routing table entries were expanded to include the
   internet address of the switch controller and state information for
   the switched connection.  If there is a switch controller address
   specified, then the connection must be set up before packets may be
   sent on this route.  We also added a separate module to handle the
   sending and receiving of the switch control messages.

手初めに、経路指定テーブルエントリーは、切り換えられた接続へのスイッチコントローラと州の情報のインターネットアドレスを含むように広げられました。 スイッチがあれば、コントローラアドレスは指定しました、このルートでパケットを送るかもしれない前に接続が用意ができなければならないその時。 また、私たちは、スイッチコントロールメッセージの送受信を扱うために別々のモジュールを加えました。

   When a routing lookup is satisfied, the routing code would check
   whether the routing table entry specified a switch controller.  If
   so, then the routine requesting switch setup would be called.  This
   would send a message on the Internet to the switch controller to
   setup the connection.

ルーティングルックアップが満たされているとき、ルーティングコードは、経路指定テーブルエントリーがスイッチコントローラを指定したかどうかチェックするでしょう。 そうだとすれば、そして、スイッチセットアップを要求するルーチンは呼ばれるでしょう。 これは接続をセットアップするスイッチコントローラへのインターネットに関するメッセージを送るでしょう。

   In our first implementation, the routing lookup call would return
   immediately after sending the switch connection request message.  It
   would be the responsibility of the transport protocol to deal with
   the time delay while the connection is setup, and to tear down if the
   switched connection could not be made.  This has significant
   ramifications.  In the case of UDP and IP, packets must be buffered
   for later transmission or face almost certain extermination as they
   will probably start arriving at the switched connection before it is
   ready to carry traffic.  Because of this problem, we decided that
   this feature would not be available for UDP or IP traffic.

私たちの最初の実装では、スイッチ接続要求メッセージを送る直後ルーティングルックアップ呼び出しは戻るでしょう。 切り換えられた接続を作ることができないなら、それは接続がセットアップであるのにもかかわらずの、遅れは時間を取扱って、取りこわすトランスポート・プロトコルの責任でしょうに。 これには、重要な分岐があります。 UDPとIPの場合では、それがトラフィックを運ぶ準備ができている前にたぶん切り換えられた接続に到達し始めるのに従って、パケットは、後のトランスミッションのためにバッファリングされなければならないか、またはほとんどある撲滅に直面しなければなりません。 この問題のために、私たちは、この特徴がUDPかIPトラフィックに利用可能でないと決めました。

   We did make this work for TCP.  Since TCP is already designed to work
   so that it buffers all data for possible later retransmission, this
   was not a problem.  Our first cut was to change TCP to check that the
   route it was using was up if it is a switch controlled route.  TCP
   would not send any data until the route was complete, and it would
   close the connection if the switch did not come up.

私たちはTCPのためにこの仕事をしました。 以来、可能な後の「再-トランスミッション」のためのすべてのデータをバッファリングして、TCPは働くように既に設計されて、これは問題ではありませんでした。 私たちの最初のカットはスイッチがルートを制御したということであるならそれが使用していたルートが上がっていたのをチェックするためにTCPを変えることでした。 ルートが完全になるまで、TCPは少しのデータも送らないでしょう、そして、スイッチが来ないなら、それは接続を終えるでしょうに。

   This did not work well at first because every time TCP tried to send
   data before the switch came up, the retransmit time would be reset
   and backed off.  The rtt estimate, retransmit timeouts and the
   congestion control mechanism were seriously skewed before any data
   was ever sent.  The retransmit timer would expire as many as 3 times

スイッチが来る前に毎回のTCPがデータを送ろうとしたのでこれが初めにうまくいかなかった、リセットされて、支持された時間を下に再送してください。 rttは、タイムアウトを再送するように見積もっています、そして、今までにどんなデータも送る前に真剣に混雑制御機構を歪曲しました。 再送信タイマは最大3回期限が切れるでしょう。

Nicholson & Young                                               [Page 6]

RFC 1306          Experiences with Circuit-Switched T3        March 1992

回路で切り換えられたT3 March 1992のニコルソンと若い[6ページ]RFC1306経験

   before data could be transmitted.  We solved this problem by adding
   another timer for handling the delay while the route came up, and not
   allowing the delay to affect any of the normal rtt timers.

以前、データを送ることができました。 ルートが来ていた間、遅れを扱うための別のタイマを言い足して、遅れが正常なrttタイマのどれかに影響するのを許容しないことによって、私たちはこの問題を解決しました。

   Our experiences with this approach were not particularly positive,
   and we decided to try another.  We also felt that unreliable datagram
   protocols should be able to use the service without excessive
   reworking.  Our alternative still sends the switch control message
   when a routing lookup finds a controlled route.  However, we now
   suspend execution of the thread of control until a response comes
   back from the switch controller.

このアプローチの私たちの経験は特に確信していませんでした、そして、私たちは別のものを試みると決めました。 また、私たちは、頼り無いデータグラムプロトコルが過度の作りなおすのなしでサービスを利用できるべきであると感じました。 ルーティングルックアップが制御ルートを見つけるとき、私たちの代替手段はまだスイッチコントロールメッセージを送ります。 しかしながら、応答がスイッチコントローラから戻るまで、私たちは現在、コントロールのスレッドの実行を中断させます。

   This proved to be easier to implement in many ways.  However, there
   were two major areas requiring changes outside the routing code.
   First, we decided that if the switch refused to activate the
   connection, it was pointless to try again.  So we changed the routing
   lookup interface so that it could return an error specifying a
   permanent error condition.  The transport layer could then return an
   appropriate error such as a host unreachable condition.

これは様々な意味で実装するのが、より簡単であると判明しました。 しかしながら、ルーティングコードの外で釣り銭がいる2つの主要な領域がありました。 まず最初に、私たちは、スイッチが、接続を起動するのを拒否したなら、再試行するのが無意味であると決めました。 それで、私たちがルーティングルックアップインタフェースを変えたので、それは永続エラー状態を指定する誤りを返すことができます。 そして、トランスポート層はホストの手の届かない状態などの適切な誤りを返すかもしれません。

   The other, more complex issue deals with the suspension of the thread
   of execution.  Our operating system, UNICOS, is an ATT System V
   derivative, and our networking subsystem is based on the BSD tahoe
   and reno releases.  The only way to suspend execution is to sleep.
   This is fine, as long as there is a user context to put to sleep.
   However, it is not a good idea to go to sleep when processing network
   interrupts, as when forwarding a packet.

他の、そして、より複雑な問題は実行のスレッドのサスペンションに対処します。 私たちのオペレーティングシステム(UNICOS)はATT System V派生物です、そして、私たちのネットワークサブシステムはBSD tahoeとrenoリリースに基づいています。 執行を中止する唯一の方法は眠ることです。 寝かすユーザ文脈がある限り、これはすばらしいです。 しかしながら、いつとしてネットワーク中断を処理するかは、眠りに行く名案であっても、パケットを進めません。

   We solved this problem by using a global flag regarding whether it
   was ok for the switch control message code to sleep.  If it is
   necessary to send a message and sleep, then the flag must be set and
   an error is returned if sleeping is not allowed.  User system calls
   which might cause a switch control message to be sent set and clear
   the flag upon entrance and exit.  We also made it impossible to
   forward packets on a switch controlled route.  We feel that this is
   reasonable since the overhead of switch control should be incurred
   only when an application program has made an explicit request to
   begin transfer of data.

私たちは、スイッチ規制メッセージコードに、眠るのが間違いなかったかどうかに関するグローバルな旗を使用することによって、この問題を解決しました。 メッセージと睡眠を送るのが必要であるなら、旗を設定しなければなりません、そして、睡眠が許されていないなら、誤りは返されます。 送られるべきスイッチコントロールメッセージを引き起こすかもしれないユーザシステムコールが、セットして、入り口で旗をきれいにして、出ます。 また、私たちはスイッチの制御ルートでパケットを進めるのを不可能にしました。 私たちは、アプリケーション・プログラムがデータ転送を始めるという明白な要求をしたときだけ、スイッチ制御装置のオーバーヘッドが被られるべきであるのでこれが妥当であると感じます。

   The one other change we made was to make sure that TCP freed the
   route it is using upon entering TIME_WAIT state.  There is no point
   in holding the circuit open for two minutes in case we need to
   retransmit the final ack.  Of course, this assumes that an alternate
   path exists for the the peer to retransmit its fin.

私たちが行った他の1つの変更が、TCPがそれがタイム誌_WAIT状態に入るとき使用するルートを解放したのを確実にすることになっていました。 私たちが、最終的なackを再送する必要があるといけないので2分間回路を開けておく意味が全くありません。 もちろん、これは同輩がフィンを再送するように代替パスが存在すると仮定します。

   The advantage of building this facility into the kernel is that it
   allows a fine degree of control over when the switch will and will
   not need to be activated.  Many applications which open a data

この施設をカーネルに組み込む利点はスイッチが必要であり、動かされるために必要としないいつのコントロールのすばらしい度合いは許容するかということです。 データを開く多くのアプリケーション

Nicholson & Young                                               [Page 7]

RFC 1306          Experiences with Circuit-Switched T3        March 1992

回路で切り換えられたT3 March 1992のニコルソンと若い[7ページ]RFC1306経験

   connection, transmit their bulk data, and then close the connection
   will not require modifications and will make efficient use of the
   resource.  It also opens the possibility that applications written to
   use type-of-service can use the same network connection for low-
   bandwidth interactive traffic, change the type-of-service (thus
   activating the switched connection) for bulk transfers, and then
   release the switch upon returning to interactive traffic.

接続、それらの大量のデータを送ってください、そして近くでは、接続は変更を必要としなく、リソースの効率的な使用をするでしょう。 また、それはサービスのタイプを使用するために書かれたアプリケーションが帯域幅の低いインタラクティブトラフィックに同じネットワーク接続を使用して、バルク転送のためにサービスのタイプを変えて(その結果、切り換えられた接続を起動します)、次に、対話的な通信に戻るときスイッチをリリースできる可能性を開きます。

   Putting this feature into the kernel also allows strong control over
   when and how the switched link can be used, keeping accounting
   information, and limiting multiple use access to the switched link.

また、この特徴をカーネルに入れると、いつ、どう切り換えられたリンクを使用できるかの強いコントロールは許されます、課金情報、および制限複数の使用が切り換えられたリンクへのアクセスであることを保って。

   The disadvantage is that significant kernel modifications are
   required, and some implementation details can be very difficult to
   handle.

不都合は重要なカーネル変更が必要であり、いくつかの実装の詳細は扱うのが非常に難しい場合があるということです。

Switch control libraries

スイッチ規制ライブラリ

   The switch control programs we used were built on a library of simple
   switch control routines; however, we did not alter any standard
   applications to use this library.  We did consider some advantages
   and disadvantages.  On the plus side, it is possible to achieve a
   satisfactory degree of switch control without requiring any kernel
   modifications.

私たちが使用したスイッチ制御プログラムは簡単なスイッチ規制ルーチンの図書館で組立てられました。 しかしながら、私たちは、このライブラリを使用するために少しの標準のアプリケーションも変更しませんでした。 私たちはいくつかの利点と損失を考えました。 プラス側では、カーネル変更を必要としないで満足できる度合いのスイッチ制御装置を達成するのが可能です。

   The primary disadvantage of this approach is that all applications
   must be altered and recompiled.  This is particularly inconvenient
   when source is not available.

このアプローチのプライマリ不都合はすべてのアプリケーションを変更されて、再コンパイルしなければならないということです。 ソースが手があいていないとき、これは特に不便です。

Link Selection

リンク選択

   When an application wishes to send data over a circuit-switched
   connection, it will be necessary to select the switched link over
   other links.  This selection process may need to take place many
   times, depending on the local network between the source host and the
   bridge to the circuit switched connection.

アプリケーションが回路で切り換えられた接続の上にデータを送りたがっているとき、他のリンクの上に切り換えられたリンクを選択するのが必要でしょう。 この選択プロセスは、何回も行われる必要があるかもしれません、回線交換接続への送信元ホストとブリッジの間の企業内情報通信網によって。

   For example, if the kernel routing code is controlling the link, then
   there must be a way to choose a controlled route over another route.
   Further downstream, there must be a way to route packets to the
   switched link rather than other links.

例えば、カーネルルーティングコードがリンクを制御しているなら、別のルートに関して制御ルートを選ぶ方法があるに違いありません。 さらに川下に、他のリンクよりむしろ切り換えられたリンクにパケットを発送する方法があるに違いありません。

   This issue has the potential for great complexity, and we avoided as
   much of the complexity as possible.  Policy routing and local routing
   across multiple connections are fertile areas for work and it is
   outside the scope of this work to address those issues.  Instead we
   opted for simple answers to difficult questions.

この問題には、すばらしい複雑さの可能性があります、そして、私たちはできるだけ多くの複雑さを避けました。 複数の接続の向こう側の方針ルーティングとローカルのルーティングは仕事のための肥よくな領域です、そして、それらの問題を扱うために、この仕事の範囲の外にそれはあります。 代わりに、私たちは難問題の簡単な答えを選びました。

Nicholson & Young                                               [Page 8]

RFC 1306          Experiences with Circuit-Switched T3        March 1992

回路で切り換えられたT3 March 1992のニコルソンと若い[8ページ]RFC1306経験

   First of all, we added no special policies to link accessibility
   beyond that already found in UNICOS.  And we handled local routing
   issues to the NSC FDDI/T1/T3 routers with routing table manipulation
   and IP Type-of-Service.

まず、私たちは、UNICOSで既に見つけられたそれを超えてアクセシビリティをリンクするために個別保険証券を全く加えませんでした。 そして、私たちは経路指定テーブル操作とサービスのIP Typeと共にNSC FDDI/T1/T3ルータにローカルのルーティング問題を扱いました。

   We came up with three solutions for selecting a routing table entry.
   The first possibility is to use the type-of-service bits, which
   seemed natural to us.  We changed the routing table to include type-
   of-service values associated with routing entries, and the routing
   lookups would select using the type-of-service.  UNICOS already
   supports a facility to mark connections with a type-of-service value.
   A controlled route could be marked with high throughput type-of-
   service and an application wishing to transfer bulk data could set
   the socket for high throughput before making the connection.  It
   could also be possible to change the type-of-service on an existing
   connection and start using the switched link if one is available.

私たちは、経路指定テーブルエントリーを選択するために3つのソリューションを思いつきました。 最初の可能性はサービス・ビットのタイプを使用することです。(タイプは私たちにとって自然に見えました)。 私たちは、サービスのタイプを使用することでルーティングエントリー、およびルーティングルックアップに関連しているサービスの値が選ぶタイプを含むように経路指定テーブルを変えました。 UNICOSは、サービスのタイプ値を接続に付けるために既に施設をサポートします。 高生産性タイプで制御ルートをマークできるだろう、-、-接続を作る前に、大量のデータを移したがっているサービスとアプリケーションは高生産性にソケットを設定するかもしれません。 また、既存の接続のサービスのタイプを変えて、1つが利用可能であるなら切り換えられたリンクを使用し始めるのも可能であるかもしれません。

   Using the type-of-service bits have the advantage that downstream
   routers can also use this information.  In our demonstration system,
   the NSC FDDI/T1/T3 routers were configured to transfer packets with
   high throughput type-of-service over the T3 connection and all others
   over the T1 connection.

サービス・ビットのタイプを使用して、川下のルータが持つことができる利点を持ってください、そして、また、この情報を使用してください。 私たちのデモンストレーションシステムでは、NSC FDDI/T1/T3ルータはパケットを移すために構成されて、高生産性で、T3接続とT1接続の上のすべての他のものがサービスオーバーをタイプしているということでした。

   Another possibility is to take advantage of the multiple addresses of
   a multi-homed host.  Routing tables could be set up so that packets
   for one of the addresses get special treatment by traveling over the
   switched link.  The routing table in the source host would have an
   entry for accessing the switch controller when sending to the high
   throughput destination address.

別の可能性がaの複数のアドレスを利用することである、マルチ、家へ帰り、ホスト。 アドレスの1つのパケットが切り換えられたリンクの上に旅行することによって特別な処理を得るように、経路指定テーブルをセットアップできました。 送信元ホストの経路指定テーブルには、高生産性送付先アドレスに発信するときスイッチコントローラにアクセスするためのエントリーがあるでしょう。

   We also derived a method we call route aliasing.  Route aliasing
   involves associating extra addresses to a single host.  However,
   rather than the destination being an actual multi-homed host, the
   alias is known only to the source host and is used as an alternative
   lookup key.  When an application tries to connect to the alias
   address the routing lookup returns an aliased route.  The route alias
   contains the actual address of the host, but because of looking up
   the special address, the switch is activated.  The alias could also
   specify a type-of-service value to send in the packets so that
   downstream routers could properly route the packets to the switched
   link.  We realize that some may bemoan the waste of the limited
   Internet address space for aliases; however, only the source host is
   aware of the alias, and the primary shortage is with Internet network
   addresses rather than host addresses.  In fact, we argue that this is
   a more efficient use of the already sparse allocation of host
   addresses available with each network address.

また、私たちはルートエイリアシングと呼ぶメソッドを引き出しました。 ルートエイリアシングは、付加的なアドレスを独身のホストに関連づけることを伴います。 目的地よりしかしながら、むしろある、実際、マルチ、家へ帰り、ホスト、別名は、送信元ホストだけにおいて知られていて、代替のルックアップキーとして使用されます。 アプリケーションが別名アドレスに接続しようとするとき、ルーティングルックアップはaliasedルートを返します。 ルート別名はホストの絶対番地を含んでいますが、特別なアドレスを調べるので、スイッチは活性です。 また、別名は、川下のルータが適切に切り換えられたリンクにパケットを発送できるようにパケットを送るためにサービスのタイプ値を指定するかもしれません。 私たちは、或るものが別名のために限られたインターネット・アドレススペースの浪費を悲しむかもしれないとわかります。 しかしながら、送信元ホストだけが別名を意識しています、そして、プライマリ不足がホスト・アドレスよりむしろインターネットネットワーク・アドレスと共にあります。 事実上、私たちは、これが各ネットワーク・アドレスで利用可能なホスト・アドレスの既にまばらな配分の、より効率的な使用であると主張します。

Nicholson & Young                                               [Page 9]

RFC 1306          Experiences with Circuit-Switched T3        March 1992

回路で切り換えられたT3 March 1992のニコルソンと若い[9ページ]RFC1306経験

Future considerations

将来の問題

   We believe that by-request services will become increasingly
   important to certain classes of users.  Many data centers make high
   performance resources available over a wide area, and these will be
   the first users to take advantage of wide-area circuit-switched
   networks.  Some users, such as CICNet ([2]), are already interested
   in deploying this capability and telecom vendors are working to
   satisfy this need.  However, there are a lot of issues involved in
   providing this functionality.  We are working to involve others in
   this process.

私たちは、要求によるサービスがますますあるクラスのユーザには重要になると信じています。 多くのデータセンターが高性能を広い領域にわたって利用可能なリソースにします、そして、これらは広い領域回路交換ネットワークを利用するために最初のユーザになるでしょう。 CICNet([2])などのユーザの中には既にベンダーがこの需要を満たすために扱っているこの能力とテレコムを配布したがっている人もいます。 しかしながら、この機能性を提供するのにかかわる多くの問題があります。 私たちは、このプロセスに他のものにかかわるために働いています。

References

参照

   [1]  Nicholson, et. al., "High Speed Networking at Cray Research",
        Computer Communications Review, January 1991.

[1] etニコルソン、アル、「クレイリサーチの高速ネットワーキング」、コンピュータCommunications Review、1月1991日

   [2]  CICNet DS3 Working Group, "High Performance Applications on
        CICNet: Impact on Design and Capacity", public report, CICNet,
        Inc., June 1991.

[2] CICNet DS3作業部会、「CICNetにおける高性能アプリケーション:」 公衆が、「DesignとCapacityで影響を与えてください」と報告して、CICNetがInc.であり、6月は1991です。

   [3]  Young, J., and A. Nicholson, "Dynamically Switched Link Control
        Protocol", RFC 1307, Cray Research, Inc., March 1992.

[3] ヤング、J.とA.ニコルソン、「ダイナミックに切り換えられたリンク制御プロトコル」、RFC1307、クレイ・リサーチ、1992年3月。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Authors' Addresses

作者のアドレス

   Andy Nicholson
   Cray Research, Inc.
   655F Lone Oak Drive
   Eagan, MN 55123

アンディ・ニコルソン・クレイ・リサーチ655FひとりのオークDriveイーガン、Mn55123

   Phone: (612) 452-6650
   EMail: droid@cray.com

以下に電話をしてください。 (612) 452-6650 メールしてください: droid@cray.com

   Jeff Young
   Cray Research, Inc.
   655F Lone Oak Drive
   Eagan, MN 55123

ジェフ・ヤング・クレイ・リサーチ655FひとりのオークDriveイーガン、Mn55123

   Phone: (612) 452-6650
   EMail: jsy@cray.com

以下に電話をしてください。 (612) 452-6650 メールしてください: jsy@cray.com

Nicholson & Young                                              [Page 10]

ニコルソンとヤング[10ページ]