RFC1307 日本語訳
1307 Dynamically Switched Link Control Protocol. J. Young, A.Nicholson. March 1992. (Format: TXT=24145 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Young
Request for Comments: 1307 A. Nicholson
Cray Research, Inc.
March 1992
コメントを求めるワーキンググループのJ.の若い要求をネットワークでつないでください: 1307 1992年のA.ニコルソンクレイ・リサーチの行進
Dynamically Switched Link Control Protocol
ダイナミックに切り換えられたリンク制御プロトコル
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo describes an experimental protocol developed by a project team at Cray Research, Inc., in implementing support for circuit- switched T3 services. The protocol is used for the control of network connections external to a host, but known to the host. It is documented here for the benefit of others who may wish to perform further research.
このメモは回路がT3サービスを切り換えたのでクレイ・リサーチでサポートを実装する際にプロジェクト・チームによって開発された実験プロトコルについて説明します。 プロトコルは、ホストにとっての、外部のネットワーク接続のコントロールに使用されますが、ホストにとって知られています。 ここに、他のものの利益のために、だれがさらなる研究を実行したがっているかもしれないかは記録されます。
While working with circuit-switched T3 networks, developers at Cray Research, Inc., defined a model wherein a host would generate control messages for a network switch. This work is described in RFC 1306, "Experiences Supporting By-Request Circuit-Switched T3 Networks". In order to simplify the model it was decided that the inconsistencies of switch control should be hidden from the host generating the control messages. To that end, a protocol was defined and implemented. This RFC documents the Dynamically Switched Link Control Protocol (DSLCP), which is used for creation and control of downstream network links by a host.
回路で切り換えられたT3と共に働いている間、ネットワーク(クレイ・リサーチの開発者)はホストがコントロールがネットワークスイッチへのメッセージであると生成するモデルを定義しました。 RFC1306、「要求による回路で切り換えられたT3ネットワークをサポートするという経験」でこの仕事は説明されます。 モデルを簡素化するために、コントロールメッセージを生成するホストスイッチ制御装置の矛盾を隠されるべきであると決められました。 そのために、プロトコルは、定義されて、実装されました。 このRFCはDynamically Switched Link Controlプロトコル(DSLCP)を記録します。(それは、ホストによる川下のネットワークリンクの作成とコントロールに使用されます)。
1.0 INTRODUCTION
1.0 序論
The Dynamically Switched Link Control Protocol (DSLCP) allows a host with knowledge of a special downstream network link to issue messages to control the status of that link.
Dynamically Switched Link Controlプロトコル(DSLCP)で、特別な川下のネットワークリンクに関する知識をもっているホストはそのリンクの状態を制御するメッセージを発行できます。
This document describes the functions of the DSLCP to control external network connections.
このドキュメントは、外部のネットワーク接続を監督するためにDSLCPの機能について説明します。
Young & Nicholson [Page 1] RFC 1307 Dynamically Switched Link Control Protocol March 1992
1992年のリンク制御プロトコル行進のときにダイナミックに切り換えられたヤングとニコルソン[1ページ]RFC1307
1.1 Motivation
1.1 動機
Circuit Switched Networks are becoming available to the Internet community. These networks are made available by requesting a connection through a switch. Normally circuit switched network links are disconnected, and their prohibitive cost suggests that it is very costly to leave them connected at all times.
回路Switched Networksはインターネットコミュニティに利用可能になっています。 スイッチを通して接続を要求することによって、これらのネットワークを利用可能にします。 通常、回路交換網リンク切断されます、そして、それらのひどく高い費用はそれらをいつも接続されたままにするのが非常に高価であると示唆します。
Internet users and hosts wish to send data over a circuit switched networks, but only connect the network links when a transport connection is to be established. While it would be possible to use packet routers to identify the need for switching a connection on and off, only the transport provider can positively identify the beginning and end of a transport session. There must be a mechanism to activate and deactivate the link at the beginning and end of a transport session.
インターネットユーザとホストは回路交換網の上にデータを送りたがっていますが、輸送接続が確立されることになっているとき、単にネットワークリンクを接続してください。 断続的に接続を切り換える必要性を特定するのにパケット・ルータを使用するのが可能であるだろうという間、輸送プロバイダーだけが明確に輸送セッションの首尾を特定できます。 輸送セッションの首尾でリンクを動かして、非活性化するメカニズムがあるに違いありません。
The DSLCP assumes that a transport provider has knowledge of a downstream link which must be setup before data transfer may take place. However, the details of link setup may vary by the type of link (circuit-switched or other), specific hardware, or administrative differences. The DSLCP hides these details from the transport provider by offering a simple request/release model of link preparation. The model assumes an entity in control of the link which handles the details of connection preparation while responding to the DSLCP commands of the transport provider. This entity is called the link controller.
DSLCPは、輸送プロバイダーにはデータ転送が行われるかもしれない前にセットアップであるに違いない川下のリンクに関する知識があると仮定します。 しかしながら、リンクセットアップの詳細はリンク(回路で切り換えられたか他の)のタイプ、特定のハードウェア、または管理違いで異なるかもしれません。 DSLCPは、リンク準備の簡単な要求/リリースモデルを提供することによって、輸送プロバイダーからこれらの詳細に隠します。 モデルは輸送プロバイダーのDSLCPコマンドに応じている間に接続準備の詳細を扱うリンクのコントロールにおける実体を仮定します。 この実体はリンクコントローラと呼ばれます。
The DSLCP allows internet hosts to dynamically change the fabric of the internet by sending messages through the internet in advance of data which is to travel across the newly created links.
DSLCPは、インターネットホストに新たに作成されたリンクの向こう側に旅行することであるデータの前のインターネットを通してメッセージを送ることによって、インターネットの骨組みをダイナミックに変えさせます。
1.2 Scope
1.2 範囲
DSLCP is intended to provide an interface between transport providers and arbitrary network links requiring creation, control, setup, or conditioning before data communications may take place.
DSLCPがデータ通信が行われるかもしれない前に作成、コントロール、セットアップ、または調節を必要とする輸送プロバイダーと任意のネットワークリンクとのインタフェースを提供することを意図します。
1.3 Interfaces
1.3 インタフェース
There are no specific user level interfaces to DSLCP, although they are not precluded. Link control is a function of the network layer, initiated by requests from the transport provider.
それらは排除されませんが、DSLCPへのどんなユーザの特定のレベルインタフェースもありません。 リンク制御は輸送プロバイダーからの要求で開始されたネットワーク層の関数です。
A DSLCP transaction is defined as a transport provider communicating with a link controller for the duration of transport session. A network path between the host providing transport services and the link controller must exist in advance of the DSLCP transaction.
DSLCPトランザクションは輸送セッションの持続時間のためにリンクコントローラとコミュニケートする輸送プロバイダーと定義されます。 輸送サービスを提供するホストとリンクコントローラの間のネットワーク経路はDSLCPトランザクションの前に存在しなければなりません。
Young & Nicholson [Page 2] RFC 1307 Dynamically Switched Link Control Protocol March 1992
1992年のリンク制御プロトコル行進のときにダイナミックに切り換えられたヤングとニコルソン[2ページ]RFC1307
Either party to an DSLCP transaction may asynchronously generate messages.
DSLCPトランザクションへの何れの当事者はメッセージを非同期に生成するかもしれません。
1.4 Operation
1.4 操作
The purpose of the DSLCP is to allow a transport provider to request the setup of a downstream network link so that data transfer may take place through that link. DSLCP messages are assumed to be communicated between the transport provider and the link controller through a transport service, such as UDP or TCP, or through a network service such as IP.
DSLCPの目的はデータ転送がそのリンクを通して行われることができるように輸送プロバイダーが川下のネットワークリンクのセットアップを要求するのを許容することです。 DSLCPメッセージが輸送プロバイダーとリンクコントローラの間でUDPかTCPなどの輸送サービスを通して、または、IPなどのネットワーク・サービスを通してコミュニケートすると思われます。
DSLCP provides messages for link setup and teardown. All the details of link management are left to the link controller. The transport provider is interested only whether the link is ready to carry data.
DSLCPはリンクセットアップと分解へのメッセージを提供します。 リンク管理に関する一部始終はリンクコントローラに任せます。 リンクがデータを運ぶ準備ができているか否かに関係なくだけ、輸送プロバイダーは興味を持っています。
1.5 Transmission
1.5 トランスミッション
DSLCP messages are carried through the network in datagrams using either IP or UDP. DSLCP is designed to not require a reliable transport protocol.
DSLCPメッセージは、データグラムでネットワークを通してIPかUDPのどちらかを使用することで伝えられます。 DSLCPは、信頼できるトランスポート・プロトコルを必要としないように設計されています。
2.0 DSLCP Architecture
2.0 DSLCPアーキテクチャ
DSLCP is used in a host environment. Normally, transport users on the host will make requests of a transport provider to carry data to other hosts. Some of these requests may require the preparation of a downstream network link. The transport provider has knowledge of these special network links, and issues a request to DSLCP that the link be prepared to carry data. This happens transparently to the transport user.
DSLCPはホスト環境に使用されます。 通常、ホストの上の輸送ユーザは輸送プロバイダーが他のホストまでデータを運ぶという要求をするでしょう。 これらの要求のいくつかが川下のネットワークリンクの準備を必要とするかもしれません。 輸送プロバイダーは、これらの特別なネットワークリンクに関する知識を持って、リンクがデータを運ぶように準備されるというDSLCPへの要求を出します。 これは透過的に輸送ユーザに起こります。
When a transport user requests transport services, the transport provider will normally attempt to establish a connection. In the event the transport provider discovers that the connection requires special link control, the transport provider will call upon DSLCP to send a link setup message to the link controller. The transport provider does not attempt to use the connection until DSLCP informs the transport provider that the link is setup or that the setup attempt failed. If the setup failed, then the transport provider is free to attempt to find another way to create a connection.
輸送ユーザが輸送サービスを要求するとき、通常、輸送プロバイダーは、取引関係を築くのを試みるでしょう。 イベントでは、輸送プロバイダーは、接続が特別なリンク制御を必要とすると発見して、輸送プロバイダーは、DSLCPがリンクセットアップメッセージをリンクコントローラに送るのを要求するでしょう。 輸送プロバイダーは、DSLCPが、リンクがセットアップであるかセットアップ試みが失敗したことを輸送プロバイダーに知らせるまで接続を使用するのを試みません。 セットアップが失敗したなら、輸送プロバイダーは、接続を創造する別の方法を見つけるのを無料で試みることができます。
When the transport user is finished using the services, then the transport provider will call DSLCP to release the link. The transport provider may now assume that the link is no longer available.
輸送ユーザがサービスを利用し終わっていると、輸送プロバイダーは、リンクをリリースするためにDSLCPと呼ぶでしょう。 輸送プロバイダーは、現在、リンクがもう利用可能でないと仮定するかもしれません。
In general, DSLCP maintains and hides the status of link control
一般に、DSLCPはリンク制御の状態を維持して、隠します。
Young & Nicholson [Page 3] RFC 1307 Dynamically Switched Link Control Protocol March 1992
1992年のリンク制御プロトコル行進のときにダイナミックに切り換えられたヤングとニコルソン[3ページ]RFC1307
transactions from the transport provider. This way the transport provider does not need to keep track of multiple DSLCP transactions. For example, if the transport provider requests a link be setup for a new transport user while another transport user has the link active, the DSLCP may inform the transport provider that the link is ready without delay, provided that the link can support multiple transport connections.
輸送プロバイダーからのトランザクション。 このように、輸送プロバイダーは複数のDSLCPトランザクションの動向をおさえる必要はありません。 例えば、輸送プロバイダーが、別の輸送ユーザがリンクをアクティブにする間リンクが新しい輸送ユーザのためのセットアップであるよう要求するなら、DSLCPは、リンクが即刻準備ができていることを輸送プロバイダーに知らせるかもしれません、リンクが複数の輸送の接続をサポートすることができれば。
3.0 FUNCTIONAL SPECIFICATION
3.0 機能的な仕様
This document specifies both a message format and a state machine for DSLCP protocol transactions.
このドキュメントはメッセージ・フォーマットと州のマシンの両方をDSLCPプロトコルトランザクションに指定します。
3.1 Control Message Format
3.1 コントロールメッセージ・フォーマット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Total length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Function | Event Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Body |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子| 全長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 機能| イベント状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 終点1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 終点2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ボディー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identifier: 16 bits
識別子: 16ビット
The identifier is a value assigned by the DSLCP used to uniquely
identify link setup transactions. It is intended to be used with
the endpoint addresses by a link controller to identify a
transaction.
識別子は唯一リンクセットアップトランザクションを特定するのに使用されるDSLCPによって割り当てられた値です。 トランザクションを特定するのにリンクコントローラによる終点アドレスと共に使用されるのは意図しています。
Total length: 16 bits
全長: 16ビット
The total length, in octets, including the header of this DSLCP
control message.
このDSLCPコントロールメッセージのヘッダーを含む八重奏における全長。
Function: 16 bits
機能: 16ビット
The operation to be processed or being responded to.
処理されるか、または応じることへの操作。
Functions currently defined are:
現在定義されている機能は以下の通りです。
Young & Nicholson [Page 4] RFC 1307 Dynamically Switched Link Control Protocol March 1992
1992年のリンク制御プロトコル行進のときにダイナミックに切り換えられたヤングとニコルソン[4ページ]RFC1307
Bring up value 0
Bring down value 1
値0のBringを値1の下側に持って来てください。
Event Status: 16 bits
イベント状態: 16ビット
The state of the controlled link, relative to the last function
request.
最後の機能要求に比例した制御リンクの状態。
The possible event states are:
Setup request succeeded value 2
Setup request failed value 3
Teardown request succeeded value 4
Teardown request failed value 5
Asynchronous network down value 7
可能なイベント州は以下の通りです。 引き継がれた値2のSetupが、失敗した値3のTeardownが要求するよう要求するセットアップ要求は失敗した値5のAsynchronousが値7の下側にネットワークでつなぐ値4のTeardown要求を引き継ぎました。
Endpoint addresses: 32 bits each
終点アドレス: それぞれ32ビット
The internet addresses of the two communicating parties for which
the link is being prepared.
リンクが準備されているパーティーを伝える2つのもののインターネットアドレス。
Message body: arbitrary length up to 65499 octets
メッセージ本体: 65499の八重奏までの任意の長さ
An ascii string which is meaningful the link controller. When the
requesting host is configured, the system administrator sets the
control strings for each network link that may be accessed by the
requesting host.
ASCIIは重要なものを結びます。リンクコントローラ。 要求ホストが構成されるとき、システム管理者は要求ホストによってアクセスされるかもしれないそれぞれのネットワークリンクにコントロールストリングを設定します。
3.2 State Machine
3.2 州のマシン
The transport provider is aware of only 2 possible states for the controlled link: up or down. Furthermore, transport users may request or release transport services from the transport provider at any time. Thus, there must be a state machine employed by DSLCP when communicating between the transport provider and the controlled link. This state machine hides the details of link control transactions from the transport provider. The state machine has 6 possible states.
制御リンクにおいて、輸送プロバイダーは2つの可能な州だけを意識しています: 上がるか、または下がっています。 その上、輸送ユーザは、いつでも、輸送プロバイダーから輸送サービスを要求するか、またはリリースするかもしれません。 したがって、輸送プロバイダーと制御リンクの間で交信するときDSLCPによって使われた州のマシンがあるに違いありません。 この州のマシンはリンク制御トランザクションの詳細に輸送プロバイダーから隠します。 州のマシンには、6つの可能な州があります。
Down: There is no active transport connection and the controlled
link is not setup.
以下より倒してください。 能動輸送接続が全くありません、そして、制御リンクはセットアップではありません。
Coming Up: A transport user has requested a connection for which
the transport provider has given a setup request to the DSLCP.
The DSLCP has sent a setup request to the link controller and is
awaiting a response.
来ます: 輸送ユーザは輸送プロバイダーがセットアップ要求をDSLCPに与えた接続を要求しました。 DSLCPはセットアップ要求をリンクコントローラに送って、応答を待っています。
Up: At least one transport connection is active and the
controlled link is setup.
上がる: 少なくとも1つの輸送接続が活発です、そして、制御リンクはセットアップです。
Young & Nicholson [Page 5] RFC 1307 Dynamically Switched Link Control Protocol March 1992
1992年のリンク制御プロトコル行進のときにダイナミックに切り換えられたヤングとニコルソン[5ページ]RFC1307
Going Down: All transport connections have been terminated and
the transport provider has sent an equivalent number of up
requests and down requests to the DSLCP. The DSLCP has sent a
teardown request to the link controller and is awaiting a
response.
落ちます: すべての輸送の接続が終えられました、そして、輸送プロバイダーは要求とDSLCPへの要求の下側に上の同等な数を送りました。 DSLCPは分解要求をリンクコントローラに送って、応答を待っています。
Bring Down: While DSLCP is in the Coming Up state, the transport
provider requested link teardown. As soon as a response is
received from the link controller, the DSLCP will send a
teardown request if the link setup was successful.
降ろします: DSLCPがComing Up状態にありましたが、輸送プロバイダーはリンク分解を要求しました。 リンクコントローラから応答を受けるとすぐに、リンクセットアップがうまくいったなら、DSLCPは分解要求を送るでしょう。
Bring Up: While in the Going Down state, the transport provider
requested connection setup. As soon as a response is received
from the link controller, the DSLCP will send a setup request.
持って来ます: 輸送プロバイダーはGoing Down状態で接続設定を要求しましたが。 リンクコントローラから応答を受けるとすぐに、DSLCPはセットアップ要求を送るでしょう。
Young & Nicholson [Page 6] RFC 1307 Dynamically Switched Link Control Protocol March 1992
1992年のリンク制御プロトコル行進のときにダイナミックに切り換えられたヤングとニコルソン[6ページ]RFC1307
DSLCP state diagram:
DSLCPはダイヤグラムを述べます:
------- +----------------+
Transport | Down |<---------\
Connect ---->+----------------+ \
Request / ^ ^ \
------- Setup | | \
Send Failed | | Teardown \ Response Timeout
Setup /------ | | Success \ ---------------
/ / | | -------- |
| | | | |
| | | | |
| | Teardown Response | | |
| | Success Timeout | | |
| | ----------------- | | +----------+ |
| | Send---------|--|-----| Bring Up |--|----\
| | Setup | | +----------+ | | Transport
| | / | | ^ | | Teardown
| | / | | Transport | | Request
| | / | | Connect| | | ---------
| | / Setup | Request| | |
| | | Failed | -------| | |
v | v ------ | | | v
+--------------+ | | +-------------+
| Coming Up |----------+----|--|--Response--->| Going Down |
+--------------+ ^ | | Timeout +-------------+
| ^ | | | | -------- ^ ^
| | Transport | | | Send | |
| Transport Teardown | | | Teardown | |
| Connect Request | | | / |
| Request ------- | | | / |
| ------- v | | | / /
| \ +------------+ - | | / /
| -| Bring Down | ------ | / /
\ +------------+ --------|--Setup----- /
\ | Success /
\ | ------- /
\ Setup Network | Send / Transport
\ Success Is Down | Teardown / Teardown
\ ------- ------- | / Request
\ | / --------
\ | / Send
\ +---------------+ / Teardown
\----------->| Up |---
+---------------+
------- +----------------+ 輸送| 下に| <、-、-、-、-、-、-、-、--\は接続します。---->+----------------+ \要求/^ ^ \------- セットアップ| | \は失敗されていた状態で発信します。| | 分解\応答タイムアウトセットアップ/------ | | 成功、\--------------- / / | | -------- | | | | | | | | | | | | | 分解応答| | | | | 成功タイムアウト| | | | | ----------------- | | +----------+ | | | 発信してください。---------|--|-----| 持って来ます。|--|----\ | | セットアップ| | +----------+ | | 輸送| | / | | ^ | | 分解| | / | | 輸送| | 要求| | / | | 接続してください。| | | --------- | | /セットアップ| 要求| | | | | | 失敗されます。| -------| | | v| v------ | | | +に対して--------------+ | | +-------------+ | 来ます。|----------+----|--|--応答--->| 落ちます。| +--------------+ ^ | | タイムアウト+-------------+ | ^ | | | | -------- ^ ^ | | 輸送| | | 発信してください。| | | 輸送分解| | | 分解| | | 要求を接続してください。| | | / | | 要求------- | | | / | | ------- v| | | / / | \ +------------+ - | | / / | -| 降ろします。| ------ | / / \ +------------+ --------|--セットアップ----- / \ | 成功/\| ------- /\セットアップネットワーク| 成功がある\を送るか、または輸送してください。| 分解/分解\------- ------- | /要求\| / -------- \ | /は\+を送ります。---------------+/分解\----------->| 上がる|--- +---------------+
Young & Nicholson [Page 7] RFC 1307 Dynamically Switched Link Control Protocol March 1992
1992年のリンク制御プロトコル行進のときにダイナミックに切り換えられたヤングとニコルソン[7ページ]RFC1307
Events and State Transitions
イベントと状態遷移
The DSLCP will process three type of events:
DSLCPはイベントの3タイプを処理するでしょう:
A link control request from the transport provider
An DSLCP message from the link controller
DSLCP message timeout
リンクコントローラDSLCPメッセージタイムアウトからの輸送プロバイダーAn DSLCPメッセージからのリンク制御要求
The transport provider will make link setup and and teardown requests to the DSLCP when transport users request and release services requiring link control operations. The transport provider should not keep track of the status of a particular link, as this is a function of the DSLCP. The transport provider may be unaware of redirection or other processing of link setup requests performed by DSLCP, so this is a function best left to DSLCP. The DSLCP will inform the transport provider as to the success or failure of a particular setup request, and transport providers may assume the success of teardown requests (the DSLCP will always return a success response to a teardown request).
そして、輸送プロバイダーがリンクセットアップをする、そして、輸送ユーザがリンク制御機能を必要とするサービスを要求して、リリースするときのDSLCPへの分解要求。 輸送プロバイダーは特定のリンクの状態の動向をおさえるべきではありません、これがDSLCPの機能であるので。 輸送プロバイダーがDSLCPによって実行されたリンクセットアップ要求のリダイレクションか他の処理に気づかないかもしれないのでこれが機能であることはDSLCPまで最もよく残っています。 DSLCPは特定のセットアップ要求の成否に関して輸送プロバイダーを知らせるでしょう、そして、輸送プロバイダーは分解要求の成功を仮定するかもしれません(DSLCPはいつも分解要求への成功応答を返すでしょう)。
The DSLCP will engage in link control transactions with link controllers. This will include accepting messages from link controllers in response to requests as well as unexpected messages from the link controller. Unexpected messages may include redundant responses to redundant requests sent as a result of timeouts.
DSLCPはリンクコントローラと共にリンク制御トランザクションに従事するでしょう。 これは、リンクコントローラからの予期していなかったメッセージと同様に要求に対応してリンクコントローラからメッセージを受け入れるのを含むでしょう。 予期していなかったメッセージはタイムアウトの結果、送られた余分な要求への余分な応答を含むかもしれません。
Because of the possibility of unavailable links and link controllers, DSLCP should not wait indefinitely for message responses from link controllers to which it has sent messages. Since DSLCP does not require the use of a reliable transport protocol to carry DSLCP messages, DSLCP must have a timeout and retransmission mechanism. Since we have used DSLCP in a local network context with switch controllers which offer a quick turnaround (on the order of 1 second), we use a 5 second timeout with a 3 retransmit limit. These figures would require adaptation to different network and link controller configurations, and a self-adapting algorithm would be most appropriate for a general solution.
入手できないリンクとリンクコントローラの可能性のために、DSLCPはそれが送信されたメッセージを持っているリンクコントローラからメッセージ応答を無期限に待つはずがありません。 DSLCPがDSLCPメッセージを伝えるために信頼できるトランスポート・プロトコルの使用を必要としないので、DSLCPには、タイムアウトと「再-トランスミッション」メカニズムがなければなりません。 迅速なターンアラウンド(1秒の注文での)を提供するスイッチコントローラと共に企業内情報通信網文脈でDSLCPを使用したので、私たちは3があるタイムアウトが限界を再送する5秒を費やします。 これらの数字は、異なったネットワークへの適合を必要として、コントローラ構成をリンクするでしょう、そして、一般解に、自己を適合させるアルゴリズムは最も適切でしょう。
The specific events of interest to the DSLCP are:
DSLCPに興味がある特定のイベントは以下の通りです。
Transport provider link setup request
Transport provider link teardown request
輸送プロバイダーリンクセットアップ要求Transportプロバイダーリンク分解要求
Link setup request failed
Link setup request succeeded
Link teardown request succeeded
Link teardown request failed
Network link is down
失敗したLinkセットアップ要求の引き継がれたLink分解要求の引き継がれたLink分解要求の失敗したNetworkがリンクするリンクセットアップ要求は下がっています。
Young & Nicholson [Page 8] RFC 1307 Dynamically Switched Link Control Protocol March 1992
1992年のリンク制御プロトコル行進のときにダイナミックに切り換えられたヤングとニコルソン[8ページ]RFC1307
Timeout waiting for DSLCP response from link controller
リンクコントローラからDSLCP応答を待つタイムアウト
The necessary processing for each event while in each state is as follows:
各イベントのための状態はそれぞれで以下の通り間の必要な処理:
Transport provider link setup request
輸送プロバイダーリンクセットアップ要求
Down:
Send setup request to link controller.
Enter Coming Up state.
Notify transport provider to wait until link is up.
以下より倒してください。 コントローラをリンクするというセットアップ要求を送ってください。 Coming Up状態に入ってください。 リンクが上がるまで、輸送プロバイダーが待つように通知してください。
Coming Up:
Bring Up:
Notify transport provider to wait until link is up.
来ます: 持って来ます: リンクが上がるまで、輸送プロバイダーが待つように通知してください。
Up:
Notify transport provider that link is up.
上がる: リンクが上がっているように輸送プロバイダーに通知してください。
Bring Down:
Enter Coming Up state.
Notify transport provider to wait until link is up.
降ろします: Coming Up状態に入ってください。 リンクが上がるまで、輸送プロバイダーが待つように通知してください。
Going Down:
Enter Bring Up state.
Notify transport provider to wait until link is up.
落ちます: Bring Up状態に入ってください。 リンクが上がるまで、輸送プロバイダーが待つように通知してください。
Discussion:
議論:
If the controlled link is not capable to support multiple
transport connections, then the DSLCP must return
appropriate errors when it detects multiple transport setup
requests for that link.
そのリンクを求める複数の輸送セットアップ要求を検出するとき、制御リンクが複数の輸送の接続をサポートすることができないなら、DSLCPは適切な誤りを返さなければなりません。
Transport provider link teardown request.
プロバイダーリンク分解要求を輸送してください。
Down:
Bring Down:
Going Down:
Notify transport provider that link is down.
以下より倒してください。 降ろします: 落ちます: リンクが下がっているように輸送プロバイダーに通知してください。
Coming Up:
Enter Bring Down state.
Notify transport provider that link is down.
来ます: Bring Down状態に入ってください。 リンクが下がっているように輸送プロバイダーに通知してください。
Bring Down:
Notify transport provider that link is down.
降ろします: リンクが下がっているように輸送プロバイダーに通知してください。
Young & Nicholson [Page 9] RFC 1307 Dynamically Switched Link Control Protocol March 1992
1992年のリンク制御プロトコル行進のときにダイナミックに切り換えられたヤングとニコルソン[9ページ]RFC1307
Up:
Send teardown request.
Enter Going Down state.
Notify transport provider that link is down.
上がる: 分解要求を送ってください。 Going Down状態に入ってください。 リンクが下がっているように輸送プロバイダーに通知してください。
Link setup request failed
リンクセットアップ要求は失敗しました。
Down:
Going Down:
Bring Up:
Unexpected message, possibly due to duplicate requests -
ignore it.
以下より倒してください。 落ちます: 持って来ます: ことによると写し要求による予期していなかったメッセージ--それを無視してください。
Up:
Unexpected message, link controller may be refusing
multiple setup requests sent because of timeout - ignore
it.
上がる: 予期していなかったメッセージ、リンクコントローラはタイムアウトのために送られた複数のセットアップ要求を拒否しているかもしれません--それを無視してください。
Coming Up:
Bring Down:
Enter down state.
来ます: 降ろします: 状態で入ってください。
Link setup request succeeded
リンクセットアップ要求は成功しました。
Down:
Unexpected message, possibly due to duplicate requests
and reordering of request packets by network.
Send teardown request.
以下より倒してください。 ことによるとネットワークによるリクエスト・パケットに関する写し要求と再命令による予期していなかったメッセージ。 分解要求を送ってください。
Going Down:
Bring Up:
Up:
Unexpected message, possibly due to duplicate requests -
ignore it.
落ちます: 持って来ます: 上がる: ことによると写し要求による予期していなかったメッセージ--それを無視してください。
Coming Up:
Enter Up state.
Notify transport provider(s) waiting for link that it is
available.
来ます: 状態について記入してください。 それが利用可能であるようにリンクを待つ輸送プロバイダーに通知してください。
Bring Down:
Send teardown request.
Enter Going Down state.
降ろします: 分解要求を送ってください。 Going Down状態に入ってください。
Link teardown request succeeded
リンク分解要求は成功しました。
Down:
Coming Up:
以下より倒してください。 来ます:
Young & Nicholson [Page 10] RFC 1307 Dynamically Switched Link Control Protocol March 1992
1992年のリンク制御プロトコル行進のときにダイナミックに切り換えられたヤングとニコルソン[10ページ]RFC1307
Bring Down:
Unexpected message, possibly due to duplicate requests -
ignore it.
降ろします: ことによると写し要求による予期していなかったメッセージ--それを無視してください。
Up:
Unexpected message, possibly due to duplicate requests
and reordering of request packets by network.
Send teardown request.
Enter Going Down state.
Notify transport providers that link has gone down.
上がる: ことによるとネットワークによるリクエスト・パケットに関する写し要求と再命令による予期していなかったメッセージ。 分解要求を送ってください。 Going Down状態に入ってください。 リンクが落ちたことを輸送プロバイダーに通知してください。
Bring Up:
Send setup request
Enter Coming Up state
持って来ます: セットアップ要求Enter Coming Up状態を送ってください。
Going Down:
Enter Down state
落ちます: Down状態に入ってください。
Discussion:
議論:
If a teardown request succeeded message arrives when the
DSLCP is in the UP state, then some error has occurred, and
the conservative approach is to bring down the connection
and resynchronize. However, it may be satisfactory to
ignore the message without ill effect.
DSLCPがUP状態にあるとき、分解要求が成功したならメッセージが到着して、次に、何らかの誤りが発生して、保守的なアプローチは、接続を落ち込ませて、再連動することです。 しかしながら、害なしでメッセージを無視するのは満足できるかもしれません。
Link teardown request failed
リンク分解要求は失敗しました。
Down:
Coming up:
Bring Down:
Bring Up:
Going Down:
Up:
DSLCP sent a teardown request message for an invalid
transaction. The link controller has no
identifier/endpoints transaction record for the request.
Continue as if request had succeeded.
以下より倒してください。 来ます: 降ろします: 持って来ます: 落ちます: 上がる: DSLCPは無効のトランザクションへの分解要求メッセージを送りました。 リンクコントローラには、要求のための識別子/終点トランザクション・レコードが全くありません。 まるで要求が成功したかのように、続いてください。
Network link is down
ネットワークリンクは下がっています。
Down:
Ignore message.
以下より倒してください。 メッセージを無視してください。
Bring Down:
Going Down:
Enter Down state.
降ろします: 落ちます: Down状態に入ってください。
Young & Nicholson [Page 11] RFC 1307 Dynamically Switched Link Control Protocol March 1992
1992年のリンク制御プロトコル行進のときにダイナミックに切り換えられたヤングとニコルソン[11ページ]RFC1307
Coming up:
Bring Up:
Up:
Enter down state.
Notify transport provider that link is down.
来ます: 持って来ます: 上がる: 状態で入ってください。 リンクが下がっているように輸送プロバイダーに通知してください。
Timeout waiting for DSLCP response from controller
コントローラからDSLCP応答を待つタイムアウト
Down:
Up:
DSLCP protocol error - fix bug, don't set timer when
there are no outstanding requests.
以下より倒してください。 上がる: DSLCPプロトコル誤り--バグを修理してください、そして、どんな傑出している要求もないとき、タイマを設定しないでください。
Coming Up:
Bring Down:
Send teardown request.
Enter Going down state.
来ます: 降ろします: 分解要求を送ってください。 状態でGoingに入ってください。
Going Down:
Enter Down state.
落ちます: Down状態に入ってください。
Bring Up:
Send setup request.
Enter Coming Up state.
持って来ます: セットアップ要求を送ってください。 Coming Up状態に入ってください。
References
参照
[1] Nicholson, et. al., "High Speed Networking at Cray Research",
Computer Communications Review, January, 1991.
[1] etニコルソン、アル、「クレイリサーチの高速ネットワーキング」、コンピュータCommunications Review、1月、1991
[2] Nicholson, A., and J. Young, "Experiences Supporting By-Request
Circuit-Switched T3 Networks", RFC 1306, Cray Research, Inc.,
March 1992.
[2] ニコルソン、A.とJ.ヤング、「要求による回路で切り換えられたT3ネットワークをサポートするという経験」RFC1306、クレイ・リサーチ、1992年3月。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Young & Nicholson [Page 12] RFC 1307 Dynamically Switched Link Control Protocol March 1992
1992年のリンク制御プロトコル行進のときにダイナミックに切り換えられたヤングとニコルソン[12ページ]RFC1307
Authors' Addresses
作者のアドレス
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
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
Young & Nicholson [Page 13]
ヤングとニコルソン[13ページ]
一覧
スポンサーリンク
