RFC1795 日本語訳
1795 Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSwClosed Pages, DLSw Standard Version 1. L. Wells, Chair, A. Bartky,Ed.. April 1995. (Format: TXT=214848 bytes) (Obsoletes RFC1434) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group L. Wells, Chair
Request for Comments: 1795 Internetwork Technology Institute
Obsoletes: 1434 A. Bartky, Editor
Category: Informational Sync Research, Inc.
April 1995
ワーキンググループのL.ウェルズ、コメントを求める議長Requestをネットワークでつないでください: 1795年のインターネットワーク技術研究所は以下を時代遅れにします。 1434A.Bartky、エディタカテゴリ: 情報の同時性研究Inc.1995年4月
Data Link Switching: Switch-to-Switch Protocol
AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1.0
データは切り換えをリンクします: スイッチからスイッチへのプロトコルAIW DLSwは装備します: DLSwはページ、DLSw標準版1.0を閉じました。
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.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This RFC describes use of Data Link Switching over TCP/IP. The RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it. 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.
このRFCはTCP/IPの上でData Link Switchingの使用について説明します。 RFCは、それに含まれた提案への彼らの反応に請求するためにインターネットコミュニティのメンバーに分配されています。 議論した問題が直接インターネットの研究課題に関連していないかもしれない間、それらは多くの研究者とImplementersにおもしろいかもしれません。
This RFC was created as a joint effort of the Advanced Peer-to-Peer Networking (APPN) Implementers Workshop (AIW) Data Link Switching (DLSw) Related Interest Group (RIG). The APPN Implementers Workshop is a group sponsored by IBM and consists of representatives of member companies implementing current and future IBM Networking interoperable products. The DLSw Related Interest Group was formed in this forum in order to produce a single version of the Switch to Switch Protocol (SSP) which could be implemented by all vendors, which would fix documentation problems with the existing RFC 1434, and which would enhance and evolve the protocol to add new functions and features.
Advanced Peerから同輩へのNetworking(APPN)Implementers Workshop(AIW)データLink Switching(DLSw)の共同努力がInterest Group(RIG)を関係づけたとき、このRFCは作成されました。 APPN Implementers WorkshopはIBMによって後援されたグループであり、現在の、そして、将来のIBMがNetworkingの共同利用できる製品であると実装するメンバー会社の代表から成ります。 DLSwの関連Interest Groupは、新しい機能と特徴を加えるプロトコルをすべてのベンダーが実装することができて、既存のRFC1434に関するドキュメンテーション問題を修正して、高めて、発展するSwitchプロトコル(SSP)にSwitchのただ一つのバージョンを生産するためにこのフォーラムで形成されました。
This document is based on RFC 1434. This document contains significant changes to RFC 1434 and therefore obsoletes that document.
このドキュメントはRFC1434に基づいています。 このドキュメントは、RFC1434への著しい変化を含んでいて、したがって、そのドキュメントを時代遅れにします。
Any questions or comments relative to the contents of this RFC should be sent to the following Internet address: aiw-dlsw@networking.raleigh.ibm.com.
このRFCのコンテンツに比例したどんな質問やコメントも以下のインターネット・アドレスに送るべきです: aiw-dlsw@networking.raleigh.ibm.com 。
NOTE 1: This is a widely subscribed mailing list and messages sent to this address will be sent to all members of the DLSw mailing list. For specific questions relating to subscribing to the AIW and any of
注意1: これは広く申し込まれたメーリングリストです、そして、このアドレスに送られたメッセージをDLSwメーリングリストのすべてのメンバーに送るでしょう。 詳細はAIWに加入するのに関係して、いずれにも質問します。
Wells & Bartky [Page 1] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[1ページ]RFC1795データ・リンク
it's working groups send email to: appn@vnet.ibm.com
ワーキンググループが以下のことのためにメールを送るということです。 appn@vnet.ibm.com
Information regarding all of the AIW working groups and the work they are producing can be obtained by copying, via anonymous ftp, the file aiwinfo.psbin or aiwinfo.txt from the Internet host networking.raleigh.ibm.com, located in directory aiw.
コピーすることによって、AIWワーキンググループのすべてに関する情報とそれらが作り出している仕事を得ることができます、ディレクトリaiwに位置するインターネット・ホストnetworking.raleigh.ibm.comからのファイルのアノニマスFTP、aiwinfo.psbinまたはaiwinfo.txtを通して。
NOTE 2: These mailing lists and addresses are subject to change.
注意2: メーリングリストとアドレスを条件としているこれらが変化します。
1. Introduction
1. 序論
Data Link Switching (DLSw) is a forwarding mechanism for the IBM SNA (Systems Network Architecture) and IBM NetBIOS (Network Basic Input Output Services) protocols. This memo documents the Switch-to-Switch Protocol (SSP) that is used between Data Link Switches. This protocol does not provide full routing, but instead provides switching at the SNA Data Link layer (i.e., layer 2 in the SNA architecture) and encapsulation in TCP/IP for transport over the Internet. This RFC documents the frame formats and protocols for multiplexing data between Data Link Switches. The initial implementation of SSP uses TCP as the reliable transport between Data Link Switches. However, other transport connections such as OSI TP4 could be used in the future.
データLink Switching(DLSw)はIBM SNA(システム・ネットワーク・アーキテクチャ)とIBM NetBIOS(ネットワークBasic Input Output Services)プロトコルのための推進メカニズムです。 このメモはSwitchからスイッチへのData Link Switchesの間で使用されるプロトコル(SSP)を記録します。 このプロトコルは、完全なルーティングを提供しませんが、代わりにインターネットの上の輸送のためにTCP/IPにおけるSNA Data Link層(すなわち、SNAアーキテクチャの層2)とカプセル化で切り替わりながら、提供されます。 このRFCは、Data Link Switchesの間にデータを多重送信するためにフレーム形式とプロトコルを記録します。 SSPの初期の実装はData Link Switchesの間の信頼できる輸送としてTCPを使用します。 しかしながら、将来、OSI TP4などの他の輸送の接続を使用できました。
A Data Link Switch (abbreviated also as DLSw in this document) can support SNA (Physical Unit (PU) 2, PU 2.1 and PU 4) systems and optionally NetBIOS systems attached to IEEE 802.2 compliant Local Area Networks, as well as SNA (PU 2 (primary or secondary) and PU2.1) systems attached to IBM Synchronous Data Link Control (SDLC) links. For the latter case, the SDLC attached systems are provided with a LAN appearance within the Data Link Switch (each SDLC PU is presented to the SSP protocol as a unique MAC/SAP address pair). For the Token-Ring LAN attached systems, the Data Link Switch appears as a source-routing bridge. Token-Ring Remote systems that are accessed through the Data Link Switch appear as systems attached to an adjacent ring. This ring is a virtual ring that is manifested within each Data Link Switch.
Data Link Switch(また、DLSwが本書では簡略化されている)はSNA(物理的なUnit(PU)2、PU2.1、およびPU4)システムをサポートできます、そして、任意に、NetBIOSシステムは802.2の対応するローカル・エリア・ネットワークをIEEEに付けました、IBM Synchronous Data Link Control(SDLC)リンクに取り付けられたSNA(PU2(プライマリの、または、セカンダリの)とPU2.1)システムと同様に。 後者のケースにおいて、Data Link Switchの中でSDLC付属しているシステムにLAN外観を提供します(ユニークなMAC/SAPアドレス組として各SDLC PUをSSPプロトコルに寄贈します)。 Token-リングLAN付属しているシステムに関しては、Data Link Switchはソースルーティングブリッジとして現れます。 システムが隣接しているリングに付いたので、Data Link Switchを通してアクセスされるトークンリングRemoteシステムは現れます。 このリングは各Data Link Switchの中に表される仮想リングです。
1.1 Backwards Compatibility with RFC 1434
1.1 RFC1434との遅れている互換性
This document defines significant changes to RFC 1434 and does not state details on how to interoperate with RFC 1434 or "enhanced" implementations (e.g., those that added enter and exit busy flow control). It is up to the implementer to refer to RFC 1434 and/or any other vendor's documentation in order to interoperate with a given vendor's implementation, if interoperability with pre-AIW DLSw RIG standards is desired.
このドキュメントは、RFC1434への著しい変化を定義して、RFC1434と共にどう共同利用するかに関する詳細か「高められた」実装を述べません(例えば加えたものは、忙しいフロー制御に入って、出ます)。 与えられたベンダーの実装で共同利用するためにRFC1434、そして/または、いかなる他のベンダーのドキュメンテーションも参照するのは、implementer次第です、プレAIW DLSw RIG規格がある相互運用性が望まれているなら。
Wells & Bartky [Page 2] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[2ページ]RFC1795データ・リンク
2. Overview
2. 概要
Data Link Switching was developed to provide support for SNA and NetBIOS in multi-protocol routers. Since SNA and NetBIOS are basically connection oriented protocols, the Data Link Control procedure that they use on the LAN is IEEE 802.2 Logical Link Control (LLC) Type 2. Data Link Switching also accommodates SNA protocols over WAN (Wide Area Network) links via the SDLC protocol.
データLink Switchingは、SNAとNetBIOSのサポートをマルチプロトコルルータに提供するために開発されました。 SNAとNetBIOSが基本的に接続指向のプロトコルであるので、それらがLANで用いるData Link Control手順はIEEE802.2Logical Link Control(LLC)タイプ2です。 また、データLink SwitchingはWAN(ワイドエリアネットワーク)リンクの上にSDLCプロトコルでSNAプロトコルを収容します。
IEEE 802.2 LLC Type 2 was designed with the assumption that the network transit delay would be predictable (i.e., a local LAN). Therefore the LLC Type 2 elements of procedure use a fixed timer for detecting lost frames. When remote bridging is used over wide area lines (especially at lower speeds), the network delay is larger and it can vary greatly based upon congestion. When the delay exceeds the time-out value LLC Type 2 attempts to retransmit. If the frame is not actually lost, only delayed, it is possible for the LLC Type 2 procedures to become confused. And as a result, the link may be eventually taken down if the delay exceeds the T1 timer times N2 retry count.
IEEE802.2LLC Type2はネットワークトランジット遅れが予測できるだろうという仮定(すなわち、地方のLAN)で設計されました。 したがって、手順のLLC Type2要素は、無くなっているフレームを検出するのに固定タイマを使用します。 リモートブリッジするのが広い領域線(特に下側の速度における)の上で使用されているとき、ネットワーク遅延は、より大きいです、そして、それは混雑に大いに基づいた状態で異なることができます。 遅れがタイムアウトを超えていると、値のLLC Type2は、再送するのを試みます。 遅らせられるだけであって、フレームが実際になくされていないなら、LLC Type2手順が混乱するようになるのは、可能です。 そして、その結果、遅れがT1タイマ回のN2再試行カウントを超えているなら、リンクは結局、降ろされるかもしれません。
Given the use of LLC Type 2 services, Data Link Switching addresses the following bridging problems:
LLC Type2サービスの使用を考えて、Data Link Switchingは問題をブリッジしながら、以下を扱います:
DLC Time-outs
DLC Acknowledgments over the WAN
Flow and Congestion Control
Broadcast Control of Search Packets
Source-Route Bridging Hop Count Limits
ホップカウント限界をブリッジする検索パケット送信元経路の青白い流れと輻輳制御放送制御装置の上のDLCタイムアウトDLC承認
NetBIOS also makes extensive use of datagram services that use connectionless LLC Type 1 service. In this case, Data Link Switching addresses the last two problems in the above list.
また、NetBIOSはコネクションレスなLLC Type1サービスを利用するデータグラムサービスの大規模な使用をします。 この場合、Data Link Switchingは上記のリストにおける最後のその2つの問題を訴えます。
The principal difference between Data Link Switching and bridging is that for connection-oriented data DLSw terminates the Data Link Control whereas bridging does not. The following figure illustrates this difference based upon two end systems operating with LLC Type 2 services.
Data Link Switchingとブリッジするところの主要な違いは接続指向のデータに関して、DLSwがData Link Controlを終えますが、ブリッジするのが終えるというわけではないということです。 以下の図はLLC Type2サービスで作動する2台のエンドシステムに基づくこの違いを例証します。
Wells & Bartky [Page 3] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[3ページ]RFC1795データ・リンク
Bridging --------
ブリッジします。--------
Bridge Bridge
+------+ +----+ +----+ +------+
| End | +-----+ | +-----/ | | +-----+ | End |
|System+-+ LAN +-+ | /------+ +-+ LAN +-+System|
| | +-----+ | | TCP/IP | | +-----+ | |
+------+ +----+ +----+ +------+
Info----------------------------------------------->
<-----------------------------------------------RR
ブリッジが+であるとブリッジしてください。------+ +----+ +----+ +------+ | 終わり| +-----+ | +-----/ | | +-----+ | 終わり| |システム++、LAN、++| /------+ ++LAN、++、システム| | | +-----+ | | TCP/IP| | +-----+ | | +------+ +----+ +----+ +------+ インフォメーション-----------------------------------------------><。-----------------------------------------------RR
Data Link Switching -------------------
データ・リンクの切り換え-------------------
+------+ +----+ +----+ +------+
| End | +-----+ | +-----/ | | +-----+ | End |
|System+-+ LAN +-+DLSw| /------+DLSw+-+ LAN +-+System|
| | +-----+ | | TCP/IP | | +-----+ | |
+------+ +----+ +----+ +------+
Info---------------> -------------> Info
<---------------RR ------------>
<------------RR
+------+ +----+ +----+ +------+ | 終わり| +-----+ | +-----/ | | +-----+ | 終わり| |システム++LAN++DLSw| /------+ DLSw++、LAN、++、システム| | | +-----+ | | TCP/IP| | +-----+ | | +------+ +----+ +----+ +------+ インフォメーション--------------->。------------->インフォメーション<。---------------RR------------><。------------RR
In traditional bridging, the Data Link Control is end-to-end. Data Link Switching terminates the LLC Type 2 connection at the switch. This means that the LLC Type 2 connections do not cross the wide area network. The DLSw multiplexes LLC connections onto a TCP connection to another DLSw. Therefore, the LLC connections at each end are totally independent of each other. It is the responsibility of the Data Link Switch to deliver frames that it has received from a LLC connection to the other end. TCP is used between the Data Link Switches to guarantee delivery of frames.
伝統的なブリッジするのに、Data Link Controlは終わらせる終わりです。 データLink SwitchingはスイッチでLLC Type2接続を終えます。 これは、LLC Type2接続が広域ネットワークを横断しないことを意味します。 DLSwは別のDLSwとのTCP接続にLLC接続を多重送信します。 したがって、各端のLLC接続は互いから完全に独立しています。 それがLLC接続からもう一方の端まで受けたフレームを提供するのは、Data Link Switchの責任です。 TCPは、フレームの配送を保証するのにData Link Switchesの間で使用されます。
As a result of this design, LLC time-outs are limited to the local LAN (i.e., they do not traverse the wide area). Also, the LLC Type 2 acknowledgments (RR's) do not traverse the WAN, thereby reducing traffic across the wide area links. For SDLC links, polling and poll response occurs locally, not over the WAN. Broadcast of search frames is controlled by the Data Link Switches once the location of a target system is discovered. Finally, the switches can now apply back pressure to the end systems to provide flow and congestion control.
このデザインの結果、LLCタイムアウトは地方のLANに制限されます(すなわち、それらは広い領域を横断しません)。 また、LLC Type2承認(RRのもの)はWANを横断して、その結果、広い領域のリンクの向こう側にトラフィックを減少させることがないです。 SDLCリンクに関しては、世論調査と投票応答はいずれのWANの上にも局所的に起こりません。 目標システムの位置がいったん発見されると、検索フレームの放送はData Link Switchesによって制御されます。 最終的に、スイッチは、現在、流れと輻輳制御を供給するためにエンドシステムに逆圧を適用できます。
Only one copy of an Link Protocol Data Unit (LPDU) is sent between Data Link Switches in SSP messages (XIDFRAME and INFOFRAME). Retries of the LPDU are absorbed by Data Link Switch that receives it. The
LinkプロトコルData Unit(LPDU)のコピー1部だけをSSPメッセージ(XIDFRAMEとINFOFRAME)のData Link Switchesの間に送ります。 LPDUの再試行はそれを受けるData Link Switchによって吸収されます。 The
Wells & Bartky [Page 4] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[4ページ]RFC1795データ・リンク
Data Link Switch that transmits the LPDU received in an SSP message to a local DLC, will perform retries in a manner appropriate for the local DLC. This may involve running a reply timer and maintaining a poll retry count. The length of the timer and the number of retries is an implementation choice based on user configuration parameters and the DLC type.
SSPメッセージに地方のDLCに受け取られたLPDUを伝えるデータLink Switch、地方のDLCに、適切な方法で再試行を実行するでしょう。 これは、回答タイマを動かして、投票再試行カウントを維持することを伴うかもしれません。 タイマの長さと再試行の数はユーザ設定パラメータに基づく実装選択です、そして、DLCはタイプします。
Data Link Switching uses LAN addressing to set up connections between SNA systems. SDLC attached devices are defined with MAC and SAP addresses to enable them to communicate with LAN attached devices. For NetBIOS systems, Data Link Switching uses the NetBIOS name to forward datagrams and to set up connections for NetBIOS sessions. For LLC type 2 connection establishment, SNA systems send TEST (or in some cases, XID) frames to the null (0x00) SAP. NetBIOS systems have an address resolution procedure, based upon the Name Query and Name Recognized frames, that is used to establish an end-to-end circuit.
データLink Switchingは、SNAシステムの間の接続をセットアップするのにLANアドレシングを使用します。SDLC付属しているデバイスはMACと共に定義されました、そして、LANとコミュニケートするのを可能にするSAPアドレスはデバイスを取り付けました。 NetBIOSシステムのために、Data Link Switchingはデータグラムを進めて、NetBIOSセッションのために接続をセットアップするNetBIOS名を使用します。 LLCタイプ2コネクション確立のために、SNAシステムはヌル(0×00)のSAPへのフレームをTEST(または、いくつかの場合XID)に送ります。 NetBIOSシステムには、終わりから端への回路を証明するのに用いられるName QueryとName Recognizedフレームに基づくアドレス解決手順があります。
Since Data Link Switching may be implemented in multi-protocol routers, there may be situations where both bridging and switching are enabled. SNA frames can be identified by their link SAP. Typical SAP values for SNA are 0x04, 0x08, and 0x0C. NetBIOS always uses a link SAP value of 0xF0.
Data Link Switchingがマルチプロトコルルータで実装されるかもしれないので、状況がブリッジするのと切り換えの両方が可能にされるところにあるかもしれません。 それらのリンクSAPはSNAフレームを特定できます。 SNAのための典型的なSAP値は、0×04と、0×08と、0x0Cです。 NetBIOSはいつも0xF0のリンクSAP価値を使用します。
Wells & Bartky [Page 5] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[5ページ]RFC1795データ・リンク
3. Transport Connection
3. 輸送接続
Data Link Switches can be in used in pairs or by themselves.
対になっている自分たちで使用されて、Link Switchesがいることができるデータ。
A Single DLSw internally switches one data link to another without using TCP (DLC(1) to DLC(2) in the figure below). This RFC does not go into details on how to implement this feature and it is not a requirement to support this RFC.
TCP(以下の図のDLC(2)へのDLC(1))を使用しないで、Single DLSwは内部的に1個のデータ・リンクを別のものに切り換えます。 このRFCはこの特徴とそれを実装するのが、どうこのRFCをサポートするという要件でないかに関する詳細を調べません。
A paired DLSw multiplexes data links over a reliable transport using a Switch-to-Switch Protocol (SSP).
対にされたDLSwは、Switchからスイッチへのプロトコル(SSP)を使用することで信頼できる輸送の上にデータ・リンクを多重送信します。
+-------------------------------------------+Switch-to-Switch | DLC Interfaces | Protocol (SSP) |+-----------+ DLC Request +-----------+ | || Data |<---------------| | |Send SSP Frame || Link | DLC Indication | | |--------------> || Control 1 |--------------->| | | |+-----------+ | Data Link | | |+-----------+ DLC Request | Switch | | || Data |<-------------- | | |Rec. SSP Frame || Link | DLC Indication | | |<------------- || Control 2 | -------------->| | | |+-----------+ +-----------+ | | Multi-Protocol Router | +-------------------------------------------+
+-------------------------------------------+ 切り換えるスイッチ| DLCインタフェース| プロトコル(SSP)|+-----------+ DLC要求+-----------+ | || データ| <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |フレームをSSPに送ってください。|| リンク| DLC指示| | |-------------->|| コントロール1|、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |+-----------+ | データ・リンク| | |+-----------+ DLC要求| スイッチ| | || データ| <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |Rec。 SSPフレーム|| リンク| DLC指示| | | <、-、-、-、-、-、-、-、-、-、-、-、-- || コントロール2| -------------->|、|、| |+-----------+ +-----------+ | | マルチプロトコルルータ| +-------------------------------------------+
Before Data Link Switching can occur between two routers, they must establish two TCP connections between them. Each Data Link Switch will maintain a list of DLSw capable routers and their status (active/inactive). After the TCP connection is established, SSP messages are exchanged to establish the capabilities of the two Data Link Switches. Once the exchange is complete, the DLSw will employ SSP control messages to establish end-to-end circuits over the transport connection. Within the transport connection, DLSw SSP messages are exchanged. The message formats and types for these SSP messages are documented in the following sections.
Data Link Switchingが2つのルータの間に起こることができる前に、それらは彼らの間の2つのTCP接続を確立しなければなりません。 各Data Link Switchは、DLSwのリストができるルータとそれらの状態(アクティブであるか不活発な)であることを支持するでしょう。 TCP接続を確立した後に、2Data Link Switchesの能力を証明するためにSSPメッセージを交換します。 交換がいったん完全になると、DLSwは輸送接続の上で終わりから端への回路を確立するSSPコントロールメッセージを使うでしょう。 輸送接続の中では、DLSw SSPメッセージを交換します。 これらのSSPメッセージのためのメッセージ・フォーマットとタイプは以下のセクションで記録されます。
The default parameters associated with the TCP connections between Data Link Switches are as follows:
Data Link Switchesの間のTCP接続に関連しているデフォルトパラメタは以下の通りです:
Socket Family AF_INET (Internet protocols) Socket Type SOCK_STREAM (stream socket) Read Port Number 2065 Write Port Number 2067
ソケットFamily AF_INET(インターネットプロトコル)ソケットType SOCK_STREAM(ストリームソケット)はPort Number2065Write Port Number2067を読みます。
Wells & Bartky [Page 6] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[6ページ]RFC1795データ・リンク
Two or more Data Link Switches may be attached to the same LAN, consisting of a number of token-ring segments interconnected by source-routing bridges. In this case, a TCP connection is not defined between bridges attached to the same LAN. This will allow using systems to select one of the possible Data Link Switches in a similar manner to the selection of a bridge path through a source- routed bridged network. The virtual ring segment in each Data Link Switch attached to a common LAN must be configured with the same ring number. This will prevent LAN frames sent by one Data Link Switch from being propagated through the other Data Link Switches.
2Data Link Switchesが同じLANに取り付けられるかもしれません、ソースルーティングブリッジによってインタコネクトされた多くのトークンリングセグメントから成って。 この場合、TCP接続は同じLANに付けられたブリッジの間で定義されません。 これで、同じようにソースの発送されたブリッジしているネットワークを通したブリッジ経路の選択するのに可能なData Link Switchesの1つを選択するのにシステムを使用するでしょう。 同じリング番号で一般的なLANに取り付けられた各Data Link Switchの仮想リングセグメントを構成しなければなりません。 これは、1Data Link Switchによって送られたLANフレームが他のData Link Switchesを通して伝播されるのを防ぐでしょう。
Wells & Bartky [Page 7] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[7ページ]RFC1795データ・リンク
3.1 SSP Frame Formats
3.1 SSPフレーム形式
The following diagrams show the two message header formats exchanged between Data Link Switches, Control and Information. The Control message header is used for all messages except Information Frames (INFOFRAME) and Independent Flow Control Messages (IFCM), which are sent in Information header format. The INFOFRAME, KEEPALIVE and IFCM message headers are 16 bytes long, and the control message header is 72 bytes long. The fields in the first sixteen bytes of all message headers are the same.
以下のダイヤグラムはData Link Switchesと、Controlと情報の間で交換された2つのメッセージヘッダー形式を示しています。 Controlメッセージヘッダーは情報Frames(INFOFRAME)と無党派Flow Control Messages(IFCM)以外のすべてのメッセージに使用されます。Flow Control Messagesは情報ヘッダー形式で送られます。 INFOFRAME、KEEPALIVE、およびIFCMメッセージヘッダーは16バイト長です、そして、コントロールメッセージヘッダーは72バイト長です。 すべてのメッセージヘッダーの最初の16バイトにおける分野は同じです。
CONTROL MESSAGES (72 Bytes)
(zero based offsets below shown in decimal (xx) )
+-----------------------------+-----------------------------+
| (00) Version Number | (01) Header Length (= 72) |
+-----------------------------+-----------------------------+
| (02) Message Length |
+-----------------------------+-----------------------------+
| (04) Remote Data Link Correlator |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (08) Remote DLC Port ID |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (12) Reserved Field |
+-----------------------------+-----------------------------+
| (14) Message Type | (15) Flow Control Byte |
+-----------------------------+-----------------------------+
| (16) Protocol ID | (17) Header Number |
+-----------------------------+-----------------------------+
| (18) Reserved |
+-----------------------------+-----------------------------+
| (20) Largest Frame Size | (21) SSP Flags |
+-----------------------------+-----------------------------+
| (22) Circuit Priority | (23) Message Type (see note)|
+-----------------------------+-----------------------------+
| (24) Target MAC Address (non-canonical format) |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -|
| |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (30) Origin MAC Address (non-canonical format) |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -|
CONTROL MESSAGES(72Bytes)(ゼロは小数(xx)で示された状態で以下でのオフセットを基礎づけた)+-----------------------------+-----------------------------+ | (00) バージョン番号| (01) ヘッダ長(= 72)| +-----------------------------+-----------------------------+ | (02) メッセージ長| +-----------------------------+-----------------------------+ | (04) リモートデータ・リンク相関器| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +-----------------------------+-----------------------------+ | (08) 遠く離れたDLC Port ID| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +-----------------------------+-----------------------------+ | (12) 予約された分野| +-----------------------------+-----------------------------+ | (14) メッセージタイプ| (15) フロー制御バイト| +-----------------------------+-----------------------------+ | (16) プロトコルID| (17) ヘッダー番号| +-----------------------------+-----------------------------+ | (18) 予約されます。| +-----------------------------+-----------------------------+ | (20) 最も大きいフレーム・サイズ| (21) SSP旗| +-----------------------------+-----------------------------+ | (22) 回路優先権| (23) メッセージType(注意を見ます)| +-----------------------------+-----------------------------+ | (24) 目標マックーアドレス(正典外の形式)| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -| | | +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +-----------------------------+-----------------------------+ | (30) 発生源マックーアドレス(正典外の形式)| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -|
Wells & Bartky [Page 8] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[8ページ]RFC1795データ・リンク
| |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| . . |
+-----------------------------+-----------------------------+
| (36) Origin Link SAP | (37) Target Link SAP |
+-----------------------------+-----------------------------+
| (38) Frame Direction | (39) Reserved |
+-----------------------------+-----------------------------+
| (40) Reserved |
+-----------------------------+-----------------------------+
| (42) DLC Header Length |
+-----------------------------+-----------------------------+
| (44) Origin DLC Port ID |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (48) Origin Data Link Correlator |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (52) Origin Transport ID |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (56) Target DLC Port ID |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (60) Target Data Link Correlator |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (64) Target Transport ID |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (68) Reserved Field |
+-----------------------------+-----------------------------+
| (70) Reserved Field |
+-----------------------------+-----------------------------+
(Even Byte) (Odd Byte)
| | +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | . . | +-----------------------------+-----------------------------+ | (36) 発生源リンク体液| (37) 目標リンク体液| +-----------------------------+-----------------------------+ | (38) フレーム方向| (39) 予約されます。| +-----------------------------+-----------------------------+ | (40) 予約されます。| +-----------------------------+-----------------------------+ | (42) DLCヘッダ長| +-----------------------------+-----------------------------+ | (44) 発生源DLCポートID| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +-----------------------------+-----------------------------+ | (48) 発生源データ・リンク相関器| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +-----------------------------+-----------------------------+ | (52) 発生源輸送ID| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +-----------------------------+-----------------------------+ | (56) 目標DLCはIDを移植します。| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +-----------------------------+-----------------------------+ | (60) 目標データ・リンク相関器| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +-----------------------------+-----------------------------+ | (64) Transport IDを狙ってください。| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +-----------------------------+-----------------------------+ | (68) 予約された分野| +-----------------------------+-----------------------------+ | (70) 予約された分野| +-----------------------------+-----------------------------+ (バイトさえ)(奇数バイト)
Wells & Bartky [Page 9] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[9ページ]RFC1795データ・リンク
INFORMATION MESSAGE (16 Bytes)
+-----------------------------+-----------------------------+
| (00) Version Number | (01) Header Length (= 16) |
+-----------------------------+-----------------------------+
| (02) Message Length |
+-----------------------------+-----------------------------+
| (04) Remote Data Link Correlator |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (08) Remote DLC Port ID |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| (12) Reserved Field |
+-----------------------------+-----------------------------+
| (14) Message Type | (15) Flow Control Byte |
+-----------------------------+-----------------------------+
(Even Byte) (Odd Byte)
情報メッセージ(16バイト)+-----------------------------+-----------------------------+ | (00) バージョン番号| (01) ヘッダ長(= 16)| +-----------------------------+-----------------------------+ | (02) メッセージ長| +-----------------------------+-----------------------------+ | (04) リモートデータ・リンク相関器| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +-----------------------------+-----------------------------+ | (08) 遠く離れたDLC Port ID| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +-----------------------------+-----------------------------+ | (12) 予約された分野| +-----------------------------+-----------------------------+ | (14) メッセージタイプ| (15) フロー制御バイト| +-----------------------------+-----------------------------+ (バイトさえ)(奇数バイト)
The first sixteen bytes of control and information message headers contain identical fields. A brief description of some of the fields in an SSP message are shown below (if not defined below, the fields and/or their values are described in subsequent sections).
最初の16バイトのコントロールと情報メッセージヘッダーは同じ分野を含んでいます。 SSPメッセージにおける、いくつかの分野の簡単な説明は以下に示されます(以下で定義されないなら、分野、そして/または、それらの値はその後のセクションで説明されます)。
The Version Number field (offset 0) is set to 0x31 (ASCII '1'), indicating a decimal value of 49. This is used to indicate DLSw version 1.
49のデシマル値を示して、バージョンNumber分野(0を相殺する)は0×31(ASCII'1')に設定されます。 これは、DLSwバージョン1を示すのに使用されます。
The Header Length field (offset 1) is 0x48 for control messages, indicating a decimal value of 72 bytes, and 0x10 for information and Independent Flow Control messages, indicating a decimal value of 16 bytes.
Header Length分野(1を相殺する)はコントロールメッセージのための0×48です、72バイトのデシマル値、および情報と無党派Flow Controlメッセージのための0×10を示して、16バイトのデシマル値を示して。
The Message Length field (offset 2) defines the number of bytes within the data field following the header.
ヘッダーに続いて、Message Length分野(2を相殺する)はデータ・フィールドの中でバイト数を定義します。
The Flow Control Byte field (offset 15) is described in section 8.
Flow Control Byte分野(15を相殺する)はセクション8で説明されます。
The Header Number field (offset 17) is 0x01, indicating a value of one.
1の値を示して、Header Number分野(17を相殺する)は0×01です。
The Circuit Priority field (offset 22) is described in section 4.
Circuit Priority分野(22を相殺する)はセクション4で説明されます。
The Frame Direction field (offset 38) is set to 0x01 for frames sent from the origin DLSw to the target DLSw, and is set to 0x02 for frames sent from the target DLSw to the origin DLSw.
Frame Direction分野(38を相殺する)は、発生源DLSwから目標DLSwに送られたフレームのために0×01に設定されて、目標DLSwから発生源DLSwに送られたフレームのために0×02に設定されます。
Wells & Bartky [Page 10] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[10ページ]RFC1795データ・リンク
Note: The Remote Data Link Correlator and Remote DLC Port ID are set equal to the Target Data Link Correlator and Target DLC Port ID if the Frame Direction field is set to 0x01, and are set equal to the Origin Data Link Correlator and Origin DLC Port ID if the Direction Field is set to 0x02.
以下に注意してください。 Direction Fieldが0×02に用意ができているなら、Remote Data Link CorrelatorとRemote DLC Port IDは、Frame Direction分野が0×01に設定されるなら、Target Data Link Correlatorと等しいセットとTarget DLC Port IDであり、Origin Data Link Correlatorと等しいセットとOrigin DLC Port IDです。
The Protocol ID field is set to 0x42, indicating a decimal value of 66.
66のデシマル値を示して、プロトコルID分野は0×42に設定されます。
The DLC Header Length is set to zero for SNA and is set to 0x23 for NetBIOS datagrams, indicating a length of 35 bytes. This includes the Access Control (AC) field, the Frame Control (FC) field, Destination MAC Address (DA), the Source MAC Address (SA), the Routing Information (RI) field (padded to 18 bytes), the Destination link SAP (DSAP), the Source link SAP (SSAP), and the LLC control field (UI).
DLC Header LengthはSNAのためにゼロに用意ができていて、NetBIOSデータグラムのために0×23に用意ができています、35バイトの長さを示して。 これはAccess Control(西暦)分野、Frame Control(FC)分野、Destinationマックーアドレス(DA)、Sourceマックーアドレス(SA)、経路情報(ロードアイランド)分野(18バイトに、そっと歩く)、DestinationリンクSAP(DSAP)、SourceリンクSAP(SSAP)、およびLLC制御フィールド(UI)を含んでいます。
NOTE: The values for the Message Type field are defined in section 3.5. Note that this value is specified in two different fields (offset 14 and 23 decimal) of the control message header. Only the first field is to be used when parsing a received SSP message. The second field is to be ignored by new implementations on reception. The second field was left in for backwards compatibility with RFC 1434 implementations and this field may be used in future versions if needed.
以下に注意してください。 Message Type分野への値はセクション3.5で定義されます。 この値がコントロールメッセージヘッダーの2つの異なった分野(14と23小数を相殺する)で指定されることに注意してください。 最初の唯一の分野は受信されたSSPメッセージを分析するとき、使用されていることです。 2番目の分野はレセプションで新しい実装によって無視されることです。 2番目の分野は後方に出られて、必要であるならRFC1434実装とこの分野との互換性が将来のバージョンで使用されるかもしれないということでした。
The SSP Flags field contains additional information related to the SSP message. The flags are defined as follows (bit 7 being the most significant bit and bit 0 the least significant bit of the octet):
SSP Flags分野はSSPメッセージに関連する追加情報を含んでいます。 旗が以下の通り定義される、(最も重要なビットであるビット7とビット0、八重奏の最下位ビット)、:
Bit(s) 76543210 Name Meaning --------- ----- ------- x....... SSPex 1 = explorer message (CANUREACH and ICANREACH)
ビット76543210名前意味--------- ----- ------- x.… SSPex1=探検家メッセージ(CANUREACHとICANREACH)
Reserved fields are set to zero upon transmission and should be ignored upon receipt.
予約された分野は、トランスミッションのゼロに設定されて、領収書で無視されるべきです。
3.2 Address Parameters
3.2 アドレスパラメタ
A data link is defined as a logical association between the two end stations using Data Link Switching. It is identified by a Data Link ID (14 bytes) consisting of the pair of attachment addresses associated with each end system. Each attachment address is represented by the concatenation of the MAC address (6 bytes) and the LLC address (1 byte). Each attachment address is classified as either "Target" in the context of the Destination MAC/SAP addresses of an explorer frame sent in the first frame used to establish a
データ・リンクは、Data Link Switchingを使用することで2つの端のステーションの間の論理的な協会と定義されます。 それは、それぞれのエンドシステムに関連している付属アドレスの組から成りながら、Data Link ID(14バイト)によって特定されます。 それぞれの付属アドレスはMACアドレス(6バイト)とLLCアドレス(1バイト)の連結で表されます。 探検家フレームのDestination MAC/SAPアドレスの文脈のどちらかの「目標」が、最初のフレームが以前はよくaを設立していたのを送ったので、それぞれの付属アドレスは分類されています。
Wells & Bartky [Page 11] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[11ページ]RFC1795データ・リンク
circuit, or "Origin" in the context of the Source MAC/SAP addresses. All MAC addresses are expressed in non-canonical (Token-Ring) format.
サーキット、またはSource MAC/SAPアドレスの文脈の「起源。」 すべてのMACアドレスが正典外(象徴リング)の形式で表されます。
DATA LINK ID (14 Bytes @ Control message offset 24 decimal)
+-----------------------------+-----------------------------+
| Target MAC Address |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| Origin MAC Address |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| Origin Link SAP | Target Link SAP |
+-----------------------------+-----------------------------+
DATA LINK ID(14Bytes@Controlメッセージは24小数を相殺した)+-----------------------------+-----------------------------+ | 目標マックーアドレス| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +-----------------------------+-----------------------------+ | 起源マックーアドレス| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +-----------------------------+-----------------------------+ | 起源リンク体液| 目標リンク体液| +-----------------------------+-----------------------------+
An end-to-end circuit is identified by a pair of Circuit ID's. A Circuit ID is a 64 bit number that identifies the DLC circuit within a single DLSw. It consists of a DLC Port ID (4 bytes), and a Data Link Correlator (4 bytes). The Circuit ID must be unique in a single DLSw and is assigned locally. The pair of Circuit ID's along with the Data Link IDs, uniquely identify a single end-to-end circuit. Each DLSw must keep a table of these Circuit ID pairs, one for the local end of the circuit and the other for the remote end of the circuit. In order to identify which Data Link Switch originated the establishment of a circuit, the terms, "Origin" DLSw and "Target" DLSw, will be employed in this document.
終わりから端へのサーキットは1組のCircuit IDのものによって特定されます。 Circuit IDは独身のDLSwの中でDLCサーキットを特定する64ビットの数です。 それはDLC Port ID(4バイト)、およびData Link Correlator(4バイト)から成ります。 Circuit IDは、独身のDLSwでユニークでなければならなく、局所的に割り当てられます。 組、Data Link IDに伴うCircuit IDのものでは、唯一ただ一つの終わりから端へのサーキットを特定してください。 各DLSwはサーキットのリモートエンドのためにこれらのCircuit ID組のテーブル、サーキットともう片方の地方の終わりのものを保たなければなりません。 どのData Link Switchがサーキットの設立を溯源したかを特定するために、用語(「起源」DLSwと「目標」DLSw)は、本書では使われるでしょう。
CIRCUIT ID (8 Bytes)
+-----------------------------+-----------------------------+
| DLC Port ID |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
| Data Link Correlator |
+- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
| |
+-----------------------------+-----------------------------+
サーキットID(8バイト)+-----------------------------+-----------------------------+ | DLC Port ID| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +-----------------------------+-----------------------------+ | データ・リンク相関器| +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+ | | +-----------------------------+-----------------------------+
The Origin Transport ID and the Target Transport ID fields in the message header are used to identify the individual TCP/IP port on a Data Link Switch. The values have only local significance. However, each Data Link Switch is required to reflect the values contained in
メッセージヘッダーのOrigin Transport IDとTarget Transport ID分野は、Data Link Switchの上の個々のTCP/IPポートを特定するのに使用されます。 値には、ローカルの意味しかありません。 しかしながら、各Data Link Switchが、中に含まれた値を反映するのに必要です。
Wells & Bartky [Page 12] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[12ページ]RFC1795データ・リンク
these two fields, along with the associated values for DLC Port ID and the Data Link Correlator, when returning a message to the other Data Link Switch.
もう片方のData Link Switchにメッセージを返すときのDLC Port IDとData Link Correlatorのための関連値に伴うこれらの2つの分野。
The following figure shows the use of the addressing parameters during the establishment of an end-to-end connection. The CANUREACH, ICANREACH, and REACH_ACK message types all carry the Data Link ID, consisting of the MAC and Link SAP addresses associated with the two end stations. The CANUREACH and ICANREACH messages are qualified by the SSPex flag into CANUREACH_ex, ICANREACH_ex (explorer messages) and CANUREACH_cs, ICANREACH_cs (circuit start). The CANUREACH_ex is used to find a remote MAC and Link SAP address without establishing an SSP circuit. Upon receipt of a CANUREACH_cs message, the target DLSw starts a data link for each port, thereby obtaining a Data Link Correlator. If the target station can be reached, an ICANREACH_cs message is returned to the origin DLSw containing the Target Circuit ID parameter. Upon receipt, the origin DLSw starts a data link and returns the Origin Circuit ID to the target DLSw within the REACH_ACK message. (Note for a full list of message types, see section 3.5.)
以下の図は終わりから終わりとの接続の設立の間、アドレシングパラメタの使用を示しています。 CANUREACH、ICANREACH、およびREACH_ACKメッセージタイプは皆、Data Link IDを運びます、2つの端のステーションに関連しているMACとLink SAPアドレスから成って。 SSPex旗でCANUREACHとICANREACHメッセージはCANUREACH_元の連れ合い、ICANREACH_元の連れ合い(探検家メッセージ)、およびCANUREACH_Csに資格があります、ICANREACH_Cs(サーキット始め)。 CANUREACH_元の連れ合いは、SSPサーキットを確立しないでリモートMACとLinkがSAPアドレスであることがわかるのに使用されます。 CANUREACH_Csメッセージを受け取り次第、目標DLSwは各ポートにデータ・リンクを始動します、その結果、Data Link Correlatorを入手します。 目標ステーションに達することができるなら、Target Circuit IDパラメタを含む起源DLSwにICANREACH_Csメッセージを返します。 領収書で、起源DLSwはREACH_ACKメッセージの中の目標DLSwにデータ・リンクを始動して、Origin Circuit IDを返します。 (メッセージに関する完全リストによってタイプに注意してください、そして、セクション3.5を見てください。)
+------------+ +------------+
|Disconnected| |Disconnected|
+------------+ CANUREACH_cs (Data Link ID) +------------+
------------------------------------------------->
ICANREACH_cs (Data Link ID, Target Circuit ID)
<------------------------------------------------
REACH_ACK (Data Link ID, Origin Cir ID, Target Cir ID)
------------------------------------------------->
+------------+ +------------+
|Circuit Est.| |Circuit Est.|
+------------+ +------------+
XIDFRAME (Data Link ID, Origin Cir ID, Target Cir ID)
<------------------------------------------------>
CONTACT (Data Link ID, Origin Cir ID, Target Cir ID)
------------------------------------------------->
CONTACTED (Data Link ID, Origin Cir ID, Target Cir ID)
<-------------------------------------------------
+------------+ +------------+
| Connected | | Connected |
+------------+ +------------+
INFOFRAME (Remote Circuit ID = Target Circuit ID)
------------------------------------------------->
INFOFRAME (Remote Circuit ID = Origin Circuit ID)
<-------------------------------------------------
+------------+ +------------+ |連絡を断ちます。| |連絡を断ちます。| +------------+ CANUREACH_Cs(データ・リンクID)+------------+ ------------------------------------------------->ICANREACH_Cs(データ・リンク目標Circuit ID(ID))<。------------------------------------------------ _ACK(データ・リンク起源Cir目標Cir ID(ID)(ID))に達してください。------------------------------------------------->+------------+ +------------+ |サーキットエスト、||サーキット、エスト| +------------+ +------------+ XIDFRAME(データ・リンク起源Cir目標Cir ID(ID)(ID))<。------------------------------------------------>接触(データ・リンク起源Cir目標Cir ID(ID)(ID))------------------------------------------------->は(データ・リンク起源Cir目標Cir ID(ID)(ID))<に連絡しました。------------------------------------------------- +------------+ +------------+ | 接続されます。| | 接続されます。| +------------+ +------------+ INFOFRAME(遠く離れたCircuit IDは目標Circuit IDと等しいです)------------------------------------------------->INFOFRAME(遠く離れたCircuit IDは起源Circuit IDと等しい)<。-------------------------------------------------
During the exchange of the XIDFRAME, CONTACT, and CONTACTED messages, the pair of Circuit ID parameters is included in the message format along with the DATA LINK ID parameter. Once the connection has been
XIDFRAME、CONTACT、およびCONTACTEDメッセージの交換の間、Circuit IDパラメタの組はDATA LINK IDパラメタに伴うメッセージ・フォーマットで含まれています。 一度、接続がありました。
Wells & Bartky [Page 13] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[13ページ]RFC1795データ・リンク
established, the INFOFRAME messages are exchanged with the shorter header. This header contains only the Circuit ID associated with the remote DLSw. The Remote Data Link Correlator and the Remote DLC Port ID are set equal to the Data Link Correlator and the DLC Port ID that are associated with the origin or target Data Link Switch, dependent upon the direction of the packet.
確立していて、より脆いヘッダーと共にINFOFRAMEメッセージを交換します。 このヘッダーはリモートDLSwに関連しているCircuit IDだけを含んでいます。 Remote Data Link CorrelatorとRemote DLC Port IDは、起源に関連しているData Link CorrelatorとDLC Port IDと等しいセットか目標Data Link Switchです、パケットの方向に依存しています。
3.3 Correlators
3.3 相関器
The local use, and contents of the Data Link Correlator, Port ID and Transport ID fields in SSP messages is an implementation choice. These fields have local significance only. The values received from a partner DLSw must not be interpreted by the DLSw that receives them and should be echoed "as is" to a partner DLSw in subsequent messages. All implementations must obey the following rules in this section (3.3) on the assignment and fixing of these correlator fields for each transport connection or circuit:
地方の使用、およびSSPメッセージのData Link Correlator、Port IDとTransport ID分野のコンテンツは実現選択です。 これらの分野には、ローカルの意味しかありません。 パートナーDLSwから受け取られた値は、それらを受けるDLSwによって解釈されてはいけなくて、「そのままで」その後のメッセージのパートナーDLSwに反響されるべきです。 すべての実現がこれらの相関器分野の課題と修理のこのセクション(3.3)の以下の規則に各輸送接続かサーキットに従わなければなりません:
The Transport ID fields are learned from the first SSP message exchanged with a DLSw partner (the Capabilities exchange). This field should not be varied by a DLSw after the capabilities exchange and must be reflected to the partner DLSw in every SSP control message.
Transport ID分野はDLSwパートナー(Capabilities交換)と共に交換された最初のSSPメッセージから学習されます。 この分野をDLSwが能力交換の後に変えるはずがなくて、あらゆるSSPコントロールメッセージのパートナーDLSwに反映しなければなりません。
The Target Data Link Correlator, Target Port ID and Target Transport ID must remain the same once the Target DLSw has sent the ICANREACH_cs for a given circuit. The Origin DLSw must store the values specified in the ICANREACH_cs and use these on all subsequent SSP messages for this circuit.
Target DLSwがいったんICANREACH_Csを与えられたサーキットに送ると、Target Data Link Correlator、Target Port ID、およびTarget Transport IDは同じままで残らなければなりません。 Origin DLSwはICANREACH_Csで指定された値を格納して、このサーキットにすべてのその後のSSPメッセージでこれらを使用しなければなりません。
The Origin DLSw must allow these fields to vary until the ICANREACH_cs is received. Each SSP message issued for a circuit must reflect the values specified by the Target DLSw in the last SSP message for this circuit received by the Origin DLSw. Binary zero should be used if no such message has yet been received for a given circuit (apart from the Target Transport ID which will have been learnt as specified above).
ICANREACH_Csが受け取られているまで、Origin DLSwはこれらの分野を異ならせなければなりません。 サーキットに発行されたそれぞれのSSPメッセージはOrigin DLSwによって受け取られたこのサーキットへの最後のSSPメッセージのTarget DLSwによって指定された値を反映しなければなりません。 まだ与えられたサーキット(上で指定されるとして学習されてしまうだろうTarget Transport IDは別として)にどんなそのようなメッセージも受け取っていないなら、バイナリーゼロを使用するべきです。
The Origin Data Link Correlator, Origin Port ID and Origin Transport ID must remain the same once the Origin DLSw has issued the REACH_ACK for a given circuit. The Target DLSw must store the values specified in the REACH_ACK and use these on all subsequent SSP messages for this circuit.
Origin DLSwがいったんREACH_ACKを与えられたサーキットに発行すると、Origin Data Link Correlator、Origin Port ID、およびOrigin Transport IDは同じままで残らなければなりません。 Target DLSwはREACH_ACKで指定された値を格納して、このサーキットにすべてのその後のSSPメッセージでこれらを使用しなければなりません。
The Target DLSw must allow these fields to vary until the REACH_ACK is received. Each SSP message issued for a circuit must reflect the values specified by the Origin DLSw in the last SSP message for this circuit received by the Target DLSw. Binary zero should be used if
REACH_ACKが受け取られているまで、Target DLSwはこれらの分野を異ならせなければなりません。 サーキットに発行されたそれぞれのSSPメッセージはTarget DLSwによって受け取られたこのサーキットへの最後のSSPメッセージのOrigin DLSwによって指定された値を反映しなければなりません。 バイナリーゼロは使用されるべきです。
Wells & Bartky [Page 14] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[14ページ]RFC1795データ・リンク
no such message has yet been received for a given circuit (apart from the Origin Transport ID which will have been learnt as specified above).
まだ与えられたサーキット(上で指定されるとして学習されてしまうだろうOrigin Transport IDは別として)にどんなそのようなメッセージも受け取っていません。
For the purposes of correlator exchange, explorer messages form a separate circuit. Both DLSw partners must reflect the last received correlator values as specified above. However correlators learned on explorer messages need not be carried over to a subsequent circuit setup attempt. In particular, the Origin DLSw may elect to use the same values for the Origin Data Link Correlator and Origin Port ID when it issues a CANUREACH_cs after receiving an ICANREACH_ex or NETBIOS_NR_ex. However the Target DLSw must not assume that the CANUREACH_cs will specify any of the Target Data Link Correlator or Target Port ID that were exchanged on the explorer messages.
相関器交換の目的のために、探検家メッセージは別々のサーキットを形成します。 両方のDLSwパートナーは上で指定されるとして最後の容認された相関器値を反映しなければなりません。 しかしながら、探検家メッセージで学習された相関器はその後のサーキットセットアップ試みに持ち越される必要はありません。 特に、Origin DLSwが、ICANREACH_元の連れ合いかNETBIOS_NR_を受けた後にCANUREACH_Csを発行するとき、Origin Data Link CorrelatorとOrigin Port IDに同じ値を使用するのを選ぶかもしれない、例えば。 しかしながら、Target DLSwは、CANUREACH_Csが探検家メッセージで交換されたTarget Data Link CorrelatorかTarget Port IDのどれかを指定すると仮定してはいけません。
Received SSP messages that require a valid Remote Circuit ID but cannot be associated with an existing circuit should be rejected with a HALT_DL_NOACK message. This is done to prevent a situation where one DLSw partner has a circuit defined while the other partner does not. The exception would be a HALT_DL_NOACK message with an invalid Remote Circuit ID. The HALT_DL_NOACK message is typically used in error situations where a response is not appropriate.
有効なRemote Circuit IDを必要とするSSPメッセージを受け取りますが、既存のサーキットに関連づけられて、HALT_DL_ノアクメッセージで拒絶されるべきであるということであることができません。 1人のDLSwパートナーがもう片方のパートナーが定義されませんが、定義されたサーキットを持っている状況を防ぐためにこれをします。 例外は無効のRemote Circuit IDがあるHALT_DL_ノアクメッセージでしょう。 HALT_DL_ノアクメッセージは応答が適切でないエラー状態に通常使用されます。
The SSP messages requiring a valid Remote Circuit ID are all messages except the following: CANUREACH_ex, CANUREACH_cs, ICANREACH_ex, ICANREACH_cs, NETBIOS_NQ_cs, NETBIOS_NR_cs, DATAFRAME, NETBIOS_ANQ, NETBIOS_ANR, KEEPALIVE and CAP_EXCHANGE.
以下を除いて、有効なRemote Circuit IDを必要とするSSPメッセージはすべてメッセージです: CANUREACH_元の連れ合い、CANUREACH_Cs、ICANREACH_元の連れ合い、ICANREACH_Cs、NETBIOS_NQ_Cs、NETBIOS_NR_Cs、DATAFRAME、NETBIOS_ANQ、NETBIOS_ANR、KEEPALIVE、およびキャップ_交換。
3.4 Largest Frame Size Field
3.4 最も大きいフレーム・サイズ分野
The Largest Frame Size (LF Size) field in the SSP Control Header is used to carry the LF Size bits across the DLSw connection. This should be used to ensure that the two end-stations always negotiate a frame size to be used on a circuit that does not require the Origin and Target DLSw partners to re-segment frames.
SSP Control HeaderのLargest Frame Size(LF Size)分野は、DLSw接続の向こう側にLF Sizeビットを運ぶのに使用されます。 これは、2つの端ステーションが再セグメントフレームにOriginとTarget DLSwパートナーを必要としないサーキットの上に使用されるためにいつもフレーム・サイズを交渉するのを保証するのに使用されるべきです。
This field is valid on CANUREACH_ex, CANUREACH_cs, ICANREACH_ex, ICANREACH_cs, NETBIOS_NQ_ex and NETBIOS_NR_ex messages only. The contents of this field should be ignored on all other frames.
この分野はCANUREACH_元の連れ合い、CANUREACH_Cs、ICANREACH_元の連れ合い、ICANREACH_Cs、NETBIOS_NQ_元の連れ合い、およびNETBIOS_NR_の元のメッセージだけで有効です。 この分野のコンテンツは他のすべてのフレームの上に無視されるべきです。
Every DLSw forwarding a SSP frame to its DLSw partner must ensure that the contents of this frame reflect the minimum capability of the route to its local end-station or any limit imposed by the DLSw itself.
SSPフレームをDLSwパートナーに送るあらゆるDLSwが、このフレームの内容が地方の端ステーションかDLSw自身によって課されたどんな限界にもルートの最小の能力を反映するのを確実にしなければなりません。
The bit-wise definition of this field is as follows (bit 7 is the most significant bit, bit 0 is the least significant bit):
この分野のビット的な定義は以下の通りです(ビット7が最も重要なビットである、ビット0は最下位ビットです):
Wells & Bartky [Page 15] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[15ページ]RFC1795データ・リンク
7 6 5 4 3 2 1 0
+-------------------------------+
| c | r | b | b | b | e | e | e |
+-------------------------------+
7 6 5 4 3 2 1 0 +-------------------------------+ | c| r| b| b| b| e| e| e| +-------------------------------+
c . . . . . . . LF Size Control flag
(significant on messages
from Origin to Target
DLSw only)
c… LF Size Controlは弛みます。(メッセージで重要OriginからTarget DLSwだけまで)です。
0=fail circuit if route
obtained requires a
smaller LF size
1=don't fail the circuit
but return the LF size
obtained even if it is
smaller
0 = 入手されたルートが、より小さいLFサイズ1=を必要とするなら、それがさらに小さいなら、やり損ないサーキットはサーキットではなく、LFサイズが得たリターンに失敗します。
. r . . . . . . Reserved
. . b . . . . . Largest Frame Bit Base
. . . b . . . . Largest Frame Bit Base
. . . . b . . . Largest Frame Bit Base
. . . . . e . . Largest Frame Bit Extended
. . . . . . e . Largest Frame Bit Extended
. . . . . . . e Largest Frame Bit Extended
. r… 予約されている、b… Largest Frame Bit基地…e最も大きいFrame Bit Extended e……最も大きいFrame Bit Extended……最も大きいFrame Bit基地の…b… 最も大きいFrame Bit基地…b…e Largest Frame Bit Extended
<----- LF Bits ----->
<。----- LFビット----->。
Refer to IEEE 802.1D Standard, Annex C for encoding of Largest Frame base and extended bit values.
Largest Frameベースと拡張ビット値のコード化についてIEEE 802.1D Standard、Annex Cを参照してください。
The Origin DLSw "Size Control" flag informs a Target DLSw that chooses to reply to *_cs messages on the basis of cached information that it may safely return a smaller LF Size on the ICANREACH_cs frame if it has had to choose an alternative route on which to initialize the circuit. If this bit is set to 1, the Origin DLSw takes responsibility for ensuring that the end-stations negotiate a suitable frame size for the circuit. If this bit is set to 0, the Target DLSw must not reply to the CANUREACH_cs if it cannot obtain a route to the Target end station that support an LF Size at least as large as that specified in the CANUREACH_cs frame.
The Origin DLSw "Size Control" flag informs a Target DLSw that chooses to reply to *_cs messages on the basis of cached information that it may safely return a smaller LF Size on the ICANREACH_cs frame if it has had to choose an alternative route on which to initialize the circuit. このビットが1に設定されるなら、端ステーションが適当なフレーム・サイズにサーキットを交渉するのを確実にするのにOrigin DLSwは責任を取ります。 このビットが0に設定されて、ルートをCANUREACH_Csフレームのそんなに指定されているのと少なくとも同じくらい大きいLF Sizeを支持するTarget端のステーションまで入手できないなら、Target DLSwはCANUREACH_Csに答えてはいけません。
3.5 Message Types
3.5 メッセージタイプ
The following table lists the protocol data units that are exchanged between Data Link Switches. All values not listed are reserved for potential use in follow-on releases.
以下のテーブルはData Link Switchesの間で交換されるプロトコルデータ単位を記載します。 値が記載しなかったすべてがフォローオンリリースにおける潜在的使用のために予約されます。
Wells & Bartky [Page 16] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[16ページ]RFC1795データ・リンク
Command Description Type flags/notes ------- -------- ------ ----------- CANUREACH_ex Can U Reach Station-explorer 0x03 SSPex CANUREACH_cs Can U Reach Station-circuit start 0x03 ICANREACH_ex I Can Reach Station-explorer 0x04 SSPex ICANREACH_cs I Can Reach Station-circuit start 0x04 REACH_ACK Reach Acknowledgment 0x05 DGRMFRAME Datagram Frame 0x06 (note 1) XIDFRAME XID Frame 0x07 CONTACT Contact Remote Station 0x08 CONTACTED Remote Station Contacted 0x09 RESTART_DL Restart Data Link 0x10 DL_RESTARTED Data Link Restarted 0x11 ENTER_BUSY Enter Busy 0x0C (note 2) EXIT_BUSY Exit Busy 0x0D (note 2) INFOFRAME Information (I) Frame 0x0A HALT_DL Halt Data Link 0x0E DL_HALTED Data Link Halted 0x0F NETBIOS_NQ_ex NETBIOS Name Query-explorer 0x12 SSPex NETBIOS_NQ_cs NETBIOS Name Query-circuit setup 0x12 (note 3) NETBIOS_NR_ex NETBIOS Name Recognized-explorer 0x13 SSPex NETBIOS_NR_cs NETBIOS Name Recog-circuit setup 0x13 (note 3) DATAFRAME Data Frame 0x14 (note 1) HALT_DL_NOACK Halt Data Link with no Ack 0x19 NETBIOS_ANQ NETBIOS Add Name Query 0x1A NETBIOS_ANR NETBIOS Add Name Response 0x1B KEEPALIVE Transport Keepalive Message 0x1D (note 4) CAP_EXCHANGE Capabilities Exchange 0x20 IFCM Independent Flow Control Message 0x21 TEST_CIRCUIT_REQ Test Circuit Request 0x7A TEST_CIRCUIT_RSP Test Circuit Response 0x7B
コマンド記述Type旗/注意------- -------- ------ ----------- CANUREACH元のCan U Reach駅_探検家0×03SSPex CANUREACH_Cs Can U Reach駅サーキットスタート0x03ICANREACH_元のI Can Reach駅探検家0×04SSPex ICANREACH_Cs I Can Reach駅サーキットスタート0x04REACH_ACK Reach Acknowledgment0x05DGRMFRAME; 連絡された接触の接触のリモート駅0x08の遠隔局の連絡された0×09再開_dl再開データ・リンク0x10のdlの_の再開しているデータがリンクするデータグラムフレーム0x06(注意1)XIDFRAME XIDフレーム0x07が0×11を再開した、忙しい状態で_に入ってください、忙しい0x0C(注意2)の出口の_の忙しい出口に忙しい状態で入ってください; 0x0D(注意2)INFOFRAME情報(I)はAck0x19NETBIOS_ANQ NETBIOS Add Name Query 0x1A NETBIOS_ANR NETBIOS Add Name Response 0x1B KEEなしで元の0x0A HALT_DL Halt Data Link 0x0E DLのSSPex NETBIOS_NQ_Cs NETBIOS Name Query-サーキット_HALTED Data Link Halted 0x0F NETBIOS_NQ_NETBIOS Name Query-探検家0×12セットアップ0x12(注意3)のNETBIOS_NR_元のNETBIOS Name Recognized-探検家0×13SSPex NETBIOS_NR_Cs NETBIOS Name Recog-サーキットセットアップ0x13(注意3)DATAFRAME Data Frame0x14(注意1)HALT_DL_ノアクHalt Data Linkを縁どっています。_PALIVE輸送Keepaliveメッセージ0x1D(注意4)キャップ_交換能力交換0x20IFCMの独立しているフロー制御メッセージ0x21テスト_サーキット_REQテストサーキット要求0x7Aテストサーキット_RSPテストサーキット応答0x7B
Note 1: Both the DGRMFRAME and DATAFRAME messages are used to carry information received by the DLC entity within UI frames. The DGRMFRAME message is addressed according to a pair of Circuit IDs, while the DATAFRAME message is addressed according to a Data Link ID, being composed of a pair of MAC addresses and a pair of link SAP addresses. The latter is employed prior to the establishment of an end-to-end circuit when Circuit IDs have yet to be established or during circuit restart when Data Links are reset.
注意1: DGRMFRAMEとDATAFRAMEメッセージの両方が、UIフレームの中にDLC実体によって受け取られた情報を運ぶのに使用されます。 1組のCircuit IDによると、DGRMFRAMEメッセージは記述されます、Data Link IDによると、DATAFRAMEメッセージが記述されますが、1組のMACアドレスと1組のリンクSAPアドレスで構成されて。 Circuit IDがまだ設立されていないか、Dataリンクスであることのサーキット再開の間リセットであるときに、後者は終わりから端へのサーキットの設立の前に使われます。
Note 2: These messages are not used for the DLSw Standard but may be used by older DLSw implementations. They are listed here for informational purposes. These messages were added after publication of RFC 1434 and were deleted in this standard (adaptive pacing is now used instead).
注意2: これらのメッセージは、DLSw Standardに使用されませんが、より古いDLSw実現で使用されるかもしれません。 それらは情報の目的のためにここに記載されています。 これらのメッセージは、RFC1434の公表の後に加えられて、この規格で削除されました(適応型のペースは現在、代わりに使用されます)。
Wells & Bartky [Page 17] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[17ページ]RFC1795データ・リンク
Note 3: These messages are not normally issued by a Standard DLSw, which uses the NB_*_ex messages as shown in section 5.4. However if a Standard DLSw attempts to interoperate with older DLSw implementations, these messages correspond to the NETBIOS_NQ and NETBIOS_NR messages used in RFC1434 both to locate the resource and to setup a circuit. This document does not attempt to provide a complete specification of the use of these messages.
注意3: 通常、これらのメッセージはStandard DLSwによって発行されません。(Standard DLSwはセクション5.4で示されるようにネブラスカの_*_の元のメッセージを使用します)。 しかしながら、Standard DLSwが、より古いDLSw実現で共同利用するのを試みるなら、これらのメッセージはメッセージがともにリソースの場所を見つけて、サーキットをセットアップするのにRFC1434で使用したNETBIOS_NQとNETBIOS_NRに対応しています。 このドキュメントは、これらのメッセージの使用の完全な仕様を提供するのを試みません。
Note 4: A KEEPALIVE message may be sent by a DLSw to a partner DLSw in order to verify the TCP connection (or other future SSP carrying protocol) is still functioning. If received by a DLSw, this message is discarded and ignored. Use of this message is optional.
注意4: KEEPALIVEメッセージはTCPについて確かめるためにDLSwによってパートナーDLSwに送られて、接続(または、プロトコルを運ぶ他の将来のSSP)がまだ機能しているということであるかもしれません。 DLSwによって受け取られるなら、このメッセージは、捨てられて、無視されます。 このメッセージの使用は任意です。
For the exchange of NetBIOS control messages, the entire DLC header is carried as part of the message unit. This includes the MAC header, with the routing information field padded to 18 bytes, and the LLC header. The following message types are affected: NETBIOS_NQ, NETBIOS_NR, NETBIOS_ANQ, NETBIOS_ANR, and DATAFRAME when being used by NetBIOS systems. The routing information in the DLC header is not used by the remote Data Link Switch upon receiving the above five messages.
NetBIOSコントロールメッセージの交換において、全体のDLCヘッダーはメッセージユニットの一部として運ばれます。 これはルーティング情報フィールドが18バイトに水増しされているMACヘッダー、およびLLCヘッダーを含んでいます。 以下のメッセージタイプは影響を受けます: 上記の5つのメッセージを受け取るときNetBIOSシステムDLCヘッダーのルーティング情報によって使用されるのがリモートData Link Switchによって使用されないNETBIOS_NQ、NETBIOS_NR、NETBIOS_ANQ、NETBIOS_ANR、およびDATAFRAME。
Any SSP message types not defined above if received by a DLSw are to be ignored (i.e., no error action is to be performed). A Data Link Switch should quietly drop any SSP message with a Message Type that is not recognized or not supported. Receipt of such a message should not cause the termination of the transport connection to the message sender.
DLSwによって受け取られるなら上で定義されなかった少しのSSPメッセージタイプも無視されることになっています(すなわち、どんな誤り動作も実行されないことです)。 Data Link Switchは認識されないか、または支持されないMessage Typeと共にどんなSSPメッセージも静かに落とすはずです。 そのようなメッセージの領収書は輸送接続の終了をメッセージ送付者に引き起こすはずがありません。
4. Circuit Priority
4. サーキット優先権
At circuit start time, each circuit end point will provide priority information to its circuit partner. The initiator of the circuit will choose which circuit priority will be effective for the life of the circuit. If Priority is not implemented by the Data Link Switch, then "Unsupported" priority is used.
サーキット開始時刻に、それぞれのサーキットエンドポイントは優先権情報をサーキットパートナーに提供するでしょう。 サーキットの創始者は、どのサーキット優先権がサーキットの人生で有効になるかを選ぶでしょう。 PriorityがData Link Switchによって実行されないなら、「サポートされない」優先権は使用されています。
4.1 Frame format
4.1 フレーム形式
Circuit priority will be valid in the CANUREACH_cs, ICANREACH_cs, and REACH_ACK frames only. The relevant header field is shown below. The Circuit Priority value is a byte value at offset 22 in an SSP Control Message.
サーキット優先権はCANUREACH_Cs、ICANREACH_Cs、およびREACH_ACKフレームだけで有効になるでしょう。 関連ヘッダーフィールドは以下に示されます。 Circuit Priority値はSSP Control Messageのオフセット22時にバイト値です。
Wells & Bartky [Page 18] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[18ページ]RFC1795データ・リンク
The following describes the format of the Circuit Priority byte.
以下はCircuit Priorityバイトの形式について説明します。
7 6 5 4 3 2 1 0
+-------------------+-----------+
| reserved | CP |
+-------------------+-----------+
7 6 5 4 3 2 1 0 +-------------------+-----------+ | 予約されます。| CP| +-------------------+-----------+
CP: Circuit Priority bits
000 - Unsupported (note 1)
001 - Low Priority
010 - Medium Priority
011 - High Priority
100 - Highest Priority
101 to 111 are reserved for future use
CP: サーキットPriorityビット000--サポートされない(注意1)001--低いPriority010--中型のPriority011--高いPriority100--最も高いPriority101〜111は今後の使用のために予約されます。
Note 1: Unsupported means that the Data Link Switch that originates the circuit does not implement priority. Actions taken on Unsupported priority are vendor specific.
注意1: 道具優先権ではなく、サーキットを溯源するData Link Switchがそうするサポートされない手段。 Unsupported優先権で取られた行動は業者特有です。
4.2 Circuit Startup
4.2 サーキット始動
The sender of a CANUREACH_cs is responsible for setting the CP bits to reflect the priority it would like to use for the circuit being requested. The mechanism for choosing an appropriate value is implementation dependent. The sender of an ICANREACH_cs frame will set the CP bits to reflect the priority it would like to use for the circuit being requested, with the mechanism for choosing the appropriate value being implementation dependent. The receiver of the ICANREACH_cs will select from the priorities in the CANUREACH_cs and ICANREACH_cs frames, and will set the value in the CP field of the REACH_ACK frame that follows to the value to be used for this circuit. This priority will be used for the life of the circuit. A CANUREACH_cs or ICANREACH_cs with the circuit priority value set to Unsupported (CP=000) indicates that the sender does not support the circuit priority function.
CPビットにそれが要求されているサーキットに使用したがっている優先権を反映するように設定するのにCANUREACH_Csの送付者は責任があります。 適切な値を選ぶためのメカニズムは実現に依存しています。 ICANREACH_Csフレームの送付者は、CPビットにそれが要求されているサーキットに使用したがっている優先権を反映するように設定するでしょう、適切な値を選ぶためのメカニズムが実現に依存していた状態で。 ICANREACH_Csの受信機は、CANUREACH_CsとICANREACH_Csフレームでプライオリティから選び抜いて、値に続くREACH_ACKフレームのCP分野の値にこのサーキットに使用されるように設定するでしょう。 この優先権はサーキットの人生に使用されるでしょう。 Unsupported(CP=000)に設定されたサーキット優先順位の値があるCANUREACH_CsかICANREACH_Csが、送付者がサーキット優先権機能をサポートしないのを示します。
Wells & Bartky [Page 19] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[19ページ]RFC1795データ・リンク
Flow:
流れ:
DLSw A DLSw B
DLSwはDLSw Bです。
CANUREACH_cs (CP=011) -----> Circuit initiator requests
high Priority.
CANUREACH_Cs(CP=011)----->サーキット創始者は高いPriorityを要求します。
<--------- ICANREACH_cs (CP=010) Circuit target requests
medium priority.
<。--------- ICANREACH_Cs(CP=010)サーキット目標は中型の優先権を要求します。
REACH_ACK (CP=010) --------> Circuit initiator sets
the priority for this
circuit to medium. The
circuit initiator could
choose either high or
medium in this example.
_ACK(CP=010)に達してください。-------->サーキット創始者は媒体へのこのサーキットに優先権を設定します。 サーキット創始者はこの例で高値か媒体のどちらかを選ぶことができました。
5. DLSw State Machine
5. DLSw州のマシン
The following state tables describe the states for a single circuit through the Data Link Switch. State information is kept for each connection. The initial state for a connection is DISCONNECTED. The steady state is either CIRCUIT_ESTABLISHED or CONNECTED. In the former state, an end-to-end circuit has been established allowing the support of Type 1 LLC between the end systems. The latter state exists when an end-to-end connection has been established for the support of Type 2 LLC services between the end systems.
以下のステートテーブルはData Link Switchを通してただ一つのサーキットに州について説明します。 州の情報は各接続のために保たれます。 接続のための初期状態はDISCONNECTEDです。 定常状態は、CIRCUIT_ESTABLISHEDかCONNECTEDのどちらかです。 前の状態に、終わりから端へのサーキットは、エンドシステムの間の1LLCをTypeのサポートに許容しながら、確立されました。終わりから終わりとの接続がエンドシステムの間のType2LLCサービスのサポートのために確立されたとき、後者の状態は存在しています。
For SNA, LLC type 2 connection establishment is via the use of IEEE 802.2 Test or XID frames. SNA devices send these frames to the null SAP in order to determine the source route information in support of bridging. Normally SNA devices use SAP 0x04, 0x08, or 0x0C (most SNA LLC2 devices that have a single PU per MAC address use a default of 0x04). Typically the SAP would be used to determine if the Test frames should be sent to the DLSw code in the router. If both bridging and DLSw are enabled, this allows the product to ensure that SNA frames are not both bridged and switched. Note that although typically SNA uses a DSAP and SSAP of 0x04, it allows for other SAPs to be configured and supports unequal SAPs. This allows multiple PUs to share connections between two given MAC addresses (each PU to PU session uses one LLC2 connection).
SNAのために、IEEE802.2TestかXIDフレームの使用でLLCタイプ2コネクション確立はものです。 SNA装置は、橋を架けることを支持してソース経由地案内を決定するためにこれらのフレームをヌルSAPに送ります。 通常、SNA装置はSAP0×04、0x08、または0x0C(MACアドレスあたり1独身のPUが0×04のデフォルトを使用するほとんどのSNA LLC2装置)を使用します。 通常、SAPは、TestフレームがルータにおけるDLSwコードに送られるべきであるかどうか決定するのに使用されるでしょう。 橋を架けるのとDLSwの両方が有効にされるなら、これで、製品は、SNAフレームが橋を架けられて、切り換えられないのを保証できます。 SNAが0×04のDSAPとSSAPを通常使用しますが、他のSAPsが構成されるのを許容して、不平等なSAPsを支持することに注意してください。 これで、MACアドレスを考えて、複数のPUsが2の間の関係を共有できます(各PUセッションまでのPUは1つのLLC2接続を使用します)。
For NetBIOS, LLC type 2 connection establishment is via the Name Query and Name Recognized frames. These frames are used for both address resolution and source route determination. NetBIOS devices use SAP 0xF0.
NetBIOSに関しては、Name QueryとName Recognizedフレームを通してLLCタイプ2コネクション確立があります。 これらのフレームはアドレス解決と送信元経路決断の両方に使用されます。 NetBIOS装置はSAP0xF0を使用します。
Wells & Bartky [Page 20] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[20ページ]RFC1795データ・リンク
5.1 Data Link Switch States
5.1 データ・リンクスイッチ州
The Switch-to-Switch Protocol is formally defined through the state machines described in this chapter. The following table lists the thirteen possible states for the main circuit FSM. A separate state machine instance is employed for each end-to-end circuit that is maintained by the Data Link Switch.
Switchからスイッチへのプロトコルは本章で説明された州のマシンを通して正式に定義されます。 以下のテーブルは13の可能な州を主なサーキットFSMに記載します。 別々の州のマシン例は終わりから端へのData Link Switchによって維持されるそれぞれのサーキットに使われます。
State Name Description
---------- -----------
CIRCUIT_ESTABLISHED The end-to-end circuit has been
established. At this time LLC Type 1
services are available from end-to-end.
州の名前記述---------- ----------- CIRCUIT_ESTABLISHED終わらせる端のサーキットは確立されました。 このとき、LLC Type1サービスは終わらせる終わりから利用可能です。
CIRCUIT_PENDING The target DLSw is awaiting a REACH_ACK
response to an ICANREACH_cs message.
CIRCUIT_PENDING目標DLSwはICANREACH_CsメッセージへのREACH_ACK応答を待っています。
CIRCUIT_RESTART The DLSw that originated the reset is
awaiting the restart of the data link
and the DL_RESTARTED response to a
RESTART_DL message.
リセットを溯源したCIRCUIT_RESTART DLSwはデータ・リンクの再開とRESTART_DLメッセージへのDL_RESTARTED応答を待っています。
CIRCUIT_START The origin DLSw is awaiting a
ICANREACH_cs in response to a
CANUREACH_cs message.
CIRCUIT_START起源DLSwはCANUREACH_Csメッセージに対応してICANREACH_Csを待っています。
CONNECTED The end-to-end connection has
been established thereby allowing
LLC Type 2 services from end-to-end
in addition to LLC Type 1 services.
CONNECTED終わらせる終わりの接続は、その結果、LLC Type1サービスに加えて終わらせる終わりからLLC Type2にサービスを許しながら、確立されました。
CONNECT_PENDING The origin DLSw is awaiting the
CONTACTED response to a CONTACT
message.
CONNECT_PENDING起源DLSwはCONTACTメッセージへのCONTACTED応答を待っています。
CONTACT_PENDING The target DLSw is awaiting the
DLC_CONTACTED confirmation to a
DLC_CONTACT signal (i.e., DLC
is waiting for a UA response to
an SABME command).
CONTACT_PENDING目標DLSwはDLC_CONTACT信号にDLC_CONTACTED確認を待っています(すなわち、DLCはSABMEコマンドへのUA応答を待っています)。
DISCONNECTED The initial state with no circuit
or connection established, the
DLSw is awaiting either a
CANUREACH_cs, or an ICANREACH_cs.
どんなサーキットも接続も確立されていない初期状態、DISCONNECTED DLSwはCANUREACH_CsかICANREACH_Csのどちらかを待っています。
DISCONNECT_PENDING The DLSw that originated the
disconnect is awaiting the DL_HALTED
分離を溯源したDISCONNECT_PENDING DLSwはDL_HALTEDを待っています。
Wells & Bartky [Page 21] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[21ページ]RFC1795データ・リンク
response to a HALT_DL message.
HALT_DLメッセージへの応答。
HALT_PENDING The remote DLSw is awaiting the
DLC_DL_HALTED indication following
the DLC_HALT_DL request (i.e., DLC
is waiting for a UA response to a
DISC command), due to receiving a
HALT_DL message.
DLが要求するDLC_HALT_に続いて、HALT_PENDINGのリモートDLSwはDLC_DL_HALTED指示を待っています(すなわち、DLCはDISCコマンドへのUA応答を待っています)、HALT_DLメッセージを受け取るため。
HALT_PENDING_NOACK The remote DLSw is awaiting the
DLC_DL_HALTED indication following
the DLC_HALT_DL request (i.e., DLC
is waiting for a UA response to a
DISC command), due to receiving a
HALT_DL_NOACK message.
DLが要求するDLC_HALT_に続いて、リモートHALT_PENDING_ノアクのDLSwはDLC_DL_HALTED指示を待っています(すなわち、DLCはDISCコマンドへのUA応答を待っています)、HALT_DL_ノアクメッセージを受け取るため。
RESTART_PENDING The remote DLSw is awaiting the
DLC_DL_HALTED indication following
the DLC_HALT_DL request (i.e., DLC
is waiting for a UA response to a
DISC command), and the restart of
the data link.
DLが要求する(すなわち、DLCはDISCコマンドへのUA応答を待っています)DLC_HALT_、およびデータ・リンクの再開に続いて、RESTART_PENDINGのリモートDLSwはDLC_DL_HALTED指示を待っています。
RESOLVE_PENDING The target DLSw is awaiting
the DLC_DL_STARTED indication
following the DLC_START_DL request
(i.e., DLC is waiting for a Test
response as a result of sending a
Test command).
DLが要求するDLC_START_に続いて、RESOLVE_PENDING目標DLSwはDLC_DL_STARTED指示を待っています(Testコマンドを送ることの結果、すなわち、DLCはTest応答を待っています)。
The DISCONNECTED state is the initial state for a new circuit. One end station starts the connection via an XID or SABME command (i.e., DLC_XID or DLC_CONTACTED). Upon receipt, the Data Link Switches exchange a set of CANUREACH_cs, ICANREACH_cs and REACH_ACK messages. Upon completion of this three-legged exchange both Data Link Switches will be in the CIRCUIT_ESTABLISHED state. Three pending states also exist during this exchange. The CIRCUIT_START state is entered by the origin Data Link Switch after it has sent the CANUREACH_cs message. The RESOLVE_PENDING state is entered by the target Data Link Switch awaiting a Test response to a Test Command. And lastly, the CIRCUIT_PENDING state is entered by the target DLSw awaiting the REACH_ACK reply to an ICANREACH_cs message.
DISCONNECTED状態は新しいサーキットへの初期状態です。 XIDかSABMEコマンド(すなわち、DLC_XIDかDLC_CONTACTED)で片端ステーションは接続を始めます。 領収書で、Data Link Switchesは1セットのCANUREACH_Cs、ICANREACH_Cs、およびREACH_ACKメッセージを交換します。 この三脚の交換の完成には、両方のData Link SwitchesがCIRCUIT_ESTABLISHED状態にあるでしょう。 また、3つの未定の州がこの交換の間、存在しています。 CANUREACH_Csメッセージを送った後にCIRCUIT_START状態は起源Data Link Switchによって入られます。 RESOLVE_PENDING状態はTest CommandへのTest応答を待つ目標Data Link Switchによって入られます。 そして、最後に、CIRCUIT_PENDING状態はICANREACH_CsメッセージにREACH_ACK回答をお待ちしている目標DLSwによって入られます。
The CIRCUIT_ESTABLISHED state allows for the exchange of LLC Type 1 frames such as the XID exchanges between SNA stations that occurs prior to the establishment of a connection. Also, datagram traffic (i.e., UI frames) may be sent and received between the end stations. These exchanges use the XIDFRAME and DGRMFRAME messages sent between
CIRCUIT_ESTABLISHED州は接続の設立の前に起こるSNAステーションの間のXID交換などのLLC Type1フレームの交換を考慮します。 また、データグラム交通(すなわち、UIフレーム)を端のステーションの間に送って、受けるかもしれません。 これらの交換はメッセージが発信したXIDFRAMEとDGRMFRAMEを使用します。
Wells & Bartky [Page 22] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[22ページ]RFC1795データ・リンク
the Data Link Switches.
データ・リンクは切り替わります。
In the CIRCUIT_ESTABLISHED state, the receipt of a SABME command (i.e., DLC_CONTACTED) causes the origin DLSw to issue a CONTACT message, to send an RNR supervisory frame (i.e., DLC_ENTER_BUSY) to the origin station, and to enter the CONNECT_PENDING state awaiting a CONTACTED message. The target DLSw, upon the receipt of a CONTACT message, will issue a SABME command (i.e., DLC_CONTACT) and enter the Contact Pending state. Once the UA response is received (i.e., DLC_CONTACTED), the target DLSw sends a CONTACTED message and enters the CONNECTED state. When received, the origin DLSw enters the CONNECTED state and sends an RR supervisory frame (i.e., DLC_EXIT_BUSY).
CIRCUIT_ESTABLISHED状態では、SABMEコマンド(すなわち、DLC_CONTACTED)の領収書は、起源DLSwがRNRの管理のフレーム(すなわち、DLC_ENTER_BUSY)を起源ステーションに送るCONTACTメッセージを発行して、CONTACTEDメッセージを待つCONNECT_PENDING州に入力することを引き起こします。 CONTACTメッセージの領収書で、目標DLSwはSABMEコマンド(すなわち、DLC_CONTACT)を発行して、Contact Pending状態に入力するでしょう。 UA応答がいったん受け取られているように(すなわち、DLC_CONTACTED)なると、目標DLSwはCONTACTEDメッセージを送って、CONNECTED状態に入力します。 受け取ると、起源DLSwはCONNECTED状態に入って、RRの管理のフレーム(すなわち、DLC_EXIT_BUSY)を送ります。
The CONNECTED state is the steady state for normal data flow once a connection has been established. Information frames (i.e., INFOFRAME messages) are simply sent back and forth between the end points of the connection. This is the path that should be optimized for performance.
接続がいったん確立されると、CONNECTED状態は正常なデータフローのための定常状態です。 単に、前後に、情報フレーム(すなわち、INFOFRAMEメッセージ)を接続のエンドポイントの間に送ります。 これは性能のために最適化されるべきである経路です。
The connection is terminated upon the receipt of a DISC frame or under some other error condition detected by DLC (i.e., DLC_ERROR). Upon receipt of this indication, the DLSw will halt the local data link, send a HALT_DL message to the remote DLSw, and enter the DISCONNECT_PENDING State. When the HALT_DL frame is received by the other DLSw, the local DLC is halted for this data link, a DL_HALTED message is returned, and the DISCONNECTED state is entered. Receipt of this DL_HALTED message causes the other DLSw to also enter the DISCONNECTED state.
接続はDISCフレームの領収書、または、DLC(すなわち、DLC_ERROR)によって検出されたある他のエラー条件の下で終えられます。 この指示を受け取り次第、DLSwは地方のデータ・リンクを止めて、HALT_DLメッセージをリモートDLSwに送って、DISCONNECT_PENDING州を入れるでしょう。 もう片方のDLSwがHALT_DLフレームを受け取るとき、地方のDLCをこのデータ・リンクに止めます、そして、DL_HALTEDメッセージを返します、そして、DISCONNECTED状態を入れます。 また、このDL_HALTEDメッセージの領収書で、もう片方のDLSwはDISCONNECTED状態に入ります。
The CIRCUIT_RESTART state is entered if one of the Data Link Switches receives a SABME command (i.e., DLC_RESET) after data transfer while in the CONNECTED state. This causes a DM command to be returned to the origin station and a RESTART_DL message to be sent to the remote Data Link Switch. This causes the remote data link to be halted and then restarted. The remote DLSw will then send a DL_RESTARTED message back to the first DLSw. The receipt of the DL_RESTARTED message causes the first DLSw to issue a new CONTACT message, assuming that the local DLC has been contacted (i.e., the origin station has resent the SABME command). This is eventually responded to by a CONTACTED message. Following this exchange, both Data Link Switches will return to the CONNECTED state. If the local DLC has not been contacted, the receipt of a DL_RESTARTED command causes the Data Link Switch to enter the CIRCUIT_ESTABLISHED state awaiting the receipt of a SABME command (i.e., DLC_CONTACTED signal).
Data Link Switchesのひとりがデータ転送の後にSABMEコマンド(すなわち、DLC_RESET)を受け取るなら、CIRCUIT_RESTART状態はCONNECTED状態にある間、入られます。 これは起源ステーションに返されるべきDMコマンドとリモートData Link Switchに送られるべきRESTART_DLメッセージを引き起こします。 これはリモートデータ・リンクが止められて、次に、再開されることを引き起こします。 そして、リモートDLSwはDL_RESTARTEDメッセージを最初のDLSwに送り返すでしょう。 最初のDLSwはDL_RESTARTEDメッセージの領収書で新しいCONTACTメッセージを発行します、地方のDLCが連絡されたと仮定して(すなわち、起源ステーションはSABMEコマンドを再送しました)。 結局、CONTACTEDメッセージによってこれに応じられます。 この交換に続いて、両方のData Link SwitchesはCONNECTED状態に戻るでしょう。 地方のDLCが連絡されていないなら、DL_RESTARTEDコマンドの領収書で、Data Link SwitchはSABMEコマンドの領収書を待つCIRCUIT_ESTABLISHED州に入ります(すなわち、DLC_CONTACTEDは合図します)。
The HALT_PENDING, HALT_PENDING_NOACK and RESTART_PENDING states correspond to the cases when the Data Link Switch is awaiting
HALT_PENDING、_PENDING_ノアクとRESTART_PENDINGがData Link Switchが待っているとき、ケースに対応すると述べるHALT
Wells & Bartky [Page 23] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[23ページ]RFC1795データ・リンク
responses from the local station on the adjacent LAN (e.g., a UA response to a DISC command). Also in the RESTART_PENDING state, the Data Link Switch will attempt to restart the data link prior to sending a DL_RESTARTED message. For some implementations, the start of a data link involves the exchange of a Test command/response on the adjacent LAN (i.e., DLC_START_DL). For other implementations, this additional exchange may not be required.
隣接しているLAN(例えば、DISCコマンドへのUA応答)の地方局からの応答。 RESTART_PENDING状態でも、Data Link Switchは、DL_RESTARTEDメッセージを送る前にデータ・リンクを再開するのを試みるでしょう。 いくつかの実現のために、データ・リンクの始まりは隣接しているLAN(すなわち、DLC_START_DL)におけるTestコマンド/応答の交換にかかわります。 他の実現において、この追加交換は必要でないかもしれません。
5.2 State Transition Tables
5.2 状態遷移テーブル
This section provides a detailed representation of the Data Link Switch, as documented by a single state machine. Many of the transitions are dependent upon local signals between the Data Link Switch entity and one of the DLC entities. These signals and their definitions are given in the following tables.
このセクションは単一の州のマシンによって記録されるようにData Link Switchの詳細な表現を提供します。 変遷の多くがData Link Switch実体とDLC実体の1つの間のローカルの信号に依存しています。 以下のテーブルでこれらの信号と彼らの定義を与えます。
DLC Events:
DLC出来事:
Event Name Description
---------- -----------
DLC_CONTACTED Contact Indication: DLC has received an SABME
command or DLC has received a UA response as a
result of sending an SABME command.
イベント名前記述---------- ----------- DLC_は接触指示に連絡しました: DLCがSABMEコマンドを受け取ったか、またはSABMEコマンドを送ることの結果、DLCはUA応答を受けました。
DLC_DGRM Datagram Indication: DLC has received a UI frame.
DLC_DGRMデータグラム指示: DLCはUIフレームを受けました。
DLC_ERROR Error condition indicated by DLC: Such a
condition occurs when a DISC command is received
or when DLC experiences an unrecoverable error.
DLCによって示されたDLC_ERROR Error状態: DISCコマンドが受け取られているか、またはDLCが回復不能エラーを経験するとき、そのような状態は現れます。
DLC_INFO Information Indication: DLC has received an
Information (I) frame.
DLC_インフォメーション情報指示: DLCは情報(I)フレームを受けました。
DLC_DL_HALTED Data Link Halted Indication: DLC has
received a UA response to a DISC command.
DLC_dlの_の停止しているデータ・リンクは指示を止めました: DLCはDISCコマンドへのUA応答を受けました。
DLC_DL_STARTED Data Link Started Indication: DLC has
received a Test response from the null SAP.
DLC_dlの_の始められたデータ・リンクは指示を始めました: DLCはヌルSAPからTest応答を受けました。
DLC_RESET Reset Indication: DLC has received an SABME
command during the time a connection is
currently active and has responded with DM.
DLC_リセットは指示をリセットしました: DLCは接続が現在活発である時SABMEコマンドを受け取っていて、DMと共に応じました。
DLC_RESOLVE_C Resolve Command Indication: DLC has received
a Test command addressed to the null SAP, or an
XID command addressed to the null SAP.
DLC_決心_Cはコマンド指示を決議します: DLCはヌルSAPに記述されたTestコマンド、またはヌルSAPに記述されたXIDコマンドを受け取りました。
Wells & Bartky [Page 24] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[24ページ]RFC1795データ・リンク
DLC_RESOLVED Resolve request: DLC has received a TEST response
frame (or equivalent for non-LAN DLCs) but has not
reserved the resources required for a circuit yet.
DLC_RESOLVED Resolveは以下を要求します。 DLCはTESTレスポンス・フレーム(または、非LAN DLCsのための同等物)を受けましたが、まだサーキットに必要であったリソースを予約していません。
DLC_XID XID Indication: DLC has received an XID command
or response to a non-null SAP.
DLC_XID XID指示: DLCは非ヌルSAPへのXIDコマンドか応答を受け取りました。
Other Events:
他の出来事:
Event Name Description
---------- -----------
XPORT_FAILURE Failure of the transport connection used by the
circuit.
イベント名前記述---------- ----------- サーキットによって使用される輸送接続のXPORT_FAILURE Failure。
CS_TIMER_EXP The CIRCUIT_START timer (started when the circuit
went into CIRCUIT_START state) has expired.
_STARTタイマ(サーキットがCIRCUIT_START状態に入ったとき、始められる)が吐き出したCS_TIMER_EXP CIRCUIT。
DLC Actions:
DLC動作:
Action Name Description
----------- -----------
DLC_CONTACT Contact Station Request: DLC will send a SABME
command or a UA response to an outstanding SABME
command.
動作名前記述----------- ----------- DLC_連絡連絡駅の要求: DLCはSABMEコマンドかUA応答を傑出しているSABMEコマンドに送るでしょう。
DLC_DGRM Datagram Request: DLC will send a UI frame.
DLC_DGRMデータグラム要求: DLCはUIフレームを送るでしょう。
DLC_ENTER_BUSY Enter Link Station Busy: DLC will send an
RNR supervisory frame.
DLC_は忙しい状態で_に入ります。リンク駅の忙しい状態で、入ってください: DLCはRNRの管理のフレームを送るでしょう。
DLC_EXIT_BUSY Exit Link Station Busy: DLC will send an RR
supervisory frame.
DLC_出口_は忙しい状態で出口リンク駅と忙しくします: DLCはRRの管理のフレームを送るでしょう。
DLC_HALT_DL Halt Data Link Request: DLC will send a DISC
command.
DLC_停止_dl停止データは要求をリンクします: DLCはDISCコマンドを送るでしょう。
DLC_INFO Information Request: DLC will send an I frame.
DLC_インフォメーション情報要求: DLCはIフレームを送るでしょう。
DLC_RESOLVE Resolve request: DLC should issue a TEST (or
appropriate equivalent for non-LAN DLCs) but need
not reserve the resources required for a circuit yet.
DLC_RESOLVE Resolveは以下を要求します。 DLCはTEST(または、非LAN DLCsのための適切な同等物)を発行するべきですが、まだサーキットに必要であったリソースを予約する必要はありません。
DLC_RESOLVE_R Resolve Response Request: DLC will send a
Test response or XID response from the null SAP.
DLC_決心_Rは応答要求を決議します: DLCはヌルSAPからTest応答かXID応答を送るでしょう。
DLC_START_DL Start Data Link Request: DLC will send a Test
command to the null SAP.
DLC_スタート_dlスタートデータは要求をリンクします: DLCはTestコマンドをヌルSAPに送るでしょう。
Wells & Bartky [Page 25] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[25ページ]RFC1795データ・リンク
DLC_XID XID Request: DLC will send an XID command or an
XID response.
DLC_XID XIDは以下を要求します。 DLCはXIDコマンドかXID応答を送るでしょう。
Other Actions:
他の動作:
Action Name Description ---------- ----------- START_CS_TIMER Start the CIRCUIT_START timer.
動作名前記述---------- ----------- START_CS_TIMER Start CIRCUIT_START、タイマ。
DLC_RESOLVE_R and DLC_START_DL actions require the DLC to reserve the resources necessary for a link station as they are used only when a circuit is about to be started. The DLC_RESOLVE action is used for topology explorer traffic and does not require such resources to be reserved, though a DLC implementation may choose not to distinguish this from the DLC_START_DL action. See section 5.4 for details of the actions and events for explorer frames.
サーキットが始動されようとしているときだけ、それらが使用されているとき、DLC_RESOLVE_RとDLC_START_DL動作は、DLCがリンクステーションに必要なリソースを予約するのを必要とします。 DLC_RESOLVE動作は、トポロジー探検家交通に使用されて、そのようなリソースが予約されるのを必要としません、DLC実現は、DLC_START_DL動作とこれを区別しないのを選ぶかもしれませんが。 動作と出来事の詳細に関して探検家フレームにセクション5.4を見てください。
The Data Link Switch is described by a state transition table as documented in the following sections. Each of the states is described below in terms of the events, actions, and next state for each transition. If a particular event is not listed for a given state, no action and no state transition should occur for that event. Any significant comments concerning the transitions within a given state are given immediately following the table representing the state.
Data Link Switchは以下のセクションで記録されるように状態遷移テーブルによって説明されます。 それぞれの州は各変遷のために以下で出来事、動作、および次の状態で説明されます。 特定の出来事が与えられた状態に記載されないなら、動作がなくて状態遷移は全くその出来事のために起こるべきではありません。 すぐに状態を表すテーブルに続いて、与えられた州の中の変遷に関するどんな重要なコメントも与えます。
A separate state machine instance is maintained by the Data Link Switch for each end-to-end circuit. The number of circuits that may be supported by each Data Link Switch is a local implementation option.
別々の州のマシン例はData Link Switchによって終わりから端へのそれぞれのサーキットに維持されます。 各Data Link Switchによって支えられるかもしれないサーキットの数はローカルの実現オプションです。
The CANUREACH_ex, ICANREACH_ex, NETBIOS_NQ_ex, and NETBIOS_NR_ex are SSP messages that are not associated with a particular circuit. The processing of these messages is covered in section 5.4.
CANUREACH_元の連れ合い、ICANREACH_元の連れ合い、NETBIOS_NQ_元の連れ合い、およびNETBIOS_NR_元の連れ合いは特定のサーキットに関連づけられないSSPメッセージです。 これらのメッセージの処理はセクション5.4でカバーされています。
Wells & Bartky [Page 26] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[26ページ]RFC1795データ・リンク
5.2.1 DISCONNECTED State
5.2.1 外された状態
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive CANUREACH_cs | DLC_START_DL | RESOLVE_PENDING | +----------------------+---------------------+----------------------+ | Receive DATAFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | DLC_XID | If source route | If CANUREACH_cs was | | | bridged frame with | sent: | | | broadcast indicated:| CIRCUIT_START | | | Send CANUREACH_ex | | | | else: | | | | Send CANUREACH_cs | | | | START_CS_TIMER | | +----------------------+---------------------+----------------------+ | DLC_DGRM | If NETBIOS | | | | NAME_QUERY: | | | | Send NETBIOS_NQ_ex | | | | else: | | | | Send DATAFRAME | | +----------------------+---------------------+----------------------+ | DLC_CONTACTED | Send CANUREACH_cs | CIRCUIT_START | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | CANUREACH_Csを受け取ってください。| DLC_スタート_dl| 未定の_を決議してください。| +----------------------+---------------------+----------------------+ | DATAFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | DLC_XID| ルートの出典を明示してくださいなら| CANUREACH_Csがそうであったなら| | | フレームに橋を架けます。| 送られる: | | | 示された放送: | CIRCUIT_START| | | CANUREACH_元の連れ合いを送ってください。| | | | ほかに: | | | | CANUREACH_Csを送ってください。| | | | _Cs_タイマを始動してください。| | +----------------------+---------------------+----------------------+ | DLC_DGRM| NETBIOSです。| | | | _を質問と命名してください: | | | | NETBIOS_NQ_元の連れ合いを送ってください。| | | | ほかに: | | | | DATAFRAMEを送ってください。| | +----------------------+---------------------+----------------------+ | 連絡されたDLC_| CANUREACH_Csを送ってください。| サーキット_は始まります。| +----------------------+---------------------+----------------------+
It is assumed that each Data Link Switch will build a set of topology tables giving the identity of each Data Link Switch that can reach a specific MAC address or a specific NetBIOS name. This table can be built using the explorer frames, as per the Explorer FSM in section 5.4. As a consequence, the amount of search traffic can be kept to a minimum.
各Data Link Switchが特定のMACアドレスか特定のNetBIOS名に達することができるそれぞれのData Link Switchのアイデンティティを与える1セットのトポロジーテーブルを組立てると思われます。 セクション5.4のエクスプローラーFSMに従って探検家フレームを使用することでこのテーブルを組立てることができます。 結果として、検索トラフィックの量を最小限に保つことができます。
Upon receipt of a TEST command, broadcast XID or NetBIOS NAME_QUERY, the Data Link Switch checks the topology table for the target MAC/SAP or NetBIOS name. If there is no matching entry in the table, the Data Link Switch uses the explorer FSMs in section 5.4 to locate the target MAC/SAP or NetBIOS name.
TESTコマンド、放送XIDまたはNetBIOS NAME_QUERYを受け取り次第、Data Link Switchは目標MAC/SAPやNetBIOS名がないかどうかトポロジーテーブルをチェックします。 合っているエントリーが全くテーブルになければ、Data Link Switchは、目標MAC/SAPかNetBIOS名の場所を見つけるのにセクション5.4で探検家FSMsを使用します。
When the first non-broadcast XID or SABME flows, the Data Link Switch issues a CANUREACH_cs to attempt to start a circuit. The CANUREACH_cs message is sent to only those Data Link Switches that are known to be able to reach the given MAC address. The mechanism by which a topology table entry is determined to be out-of-date and is deleted from the table is implementation specific.
最初の非放送のXIDかSABMEが流れるとき、Data Link Switchは、サーキットを始動するのを試みるためにCANUREACH_Csを発行します。 与えられたMACアドレスに達することができるのが知られているそれらのData Link SwitchesだけにCANUREACH_Csメッセージを送ります。 トポロジーテーブル項目が時代遅れであると決心していて、テーブルから削除されるメカニズムは実現特有です。
The DISCONNECTED state is exited upon the sending of a CANUREACH_cs by the origin DLSw or the receipt of a CANUREACH_cs message by a
DISCONNECTED状態はCANUREACH_Csメッセージの起源DLSwか領収書によるCANUREACH_Csの発信のときにaによって出られます。
Wells & Bartky [Page 27] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[27ページ]RFC1795データ・リンク
prospective target Data Link Switch. In the latter case, the Data Link Switch will issue a Test command to the target station (i.e., DLC_START_DL signal is presented to DLC).
将来の目標Data Link Switch。 後者の場合では、Data Link Switchは目標ステーションにTestコマンドを発行するでしょう(すなわち、DLC_START_DL信号はDLCに提示されます)。
5.2.2 RESOLVE_PENDING State
5.2.2 _未定の状態を決議してください。
+-------------------+-----------------------+-----------------------+ | Event | Action(s) | Next State | +-------------------+-----------------------+-----------------------+ | Receive DATAFRAME | DLC_DGRM | | +-------------------+-----------------------+-----------------------+ | DLC_DL_STARTED | If LF value of | If LF value of | | | DLC_DL_STARTED | DLC_DL_STARTED | | | is greater than or | is greater than or | | | equal to LF Size of | equal to LF Size of | | | CANUREACH_cs or LF | CANUREACH_cs or LF | | | Size Control bit set: | Size Control bit set: | | | Send ICANREACH_cs | CIRCUIT_PENDING | | | else: | else: | | | Send DLC_HALT_DL | HALT_PENDING_NOACK | +-------------------+-----------------------+-----------------------+ | DLC_ERROR | | DISCONNECTED | +-------------------+-----------------------+-----------------------+ | DLC_DGRM | Send DATAFRAME | | +-------------------+-----------------------+-----------------------+
+-------------------+-----------------------+-----------------------+ | 出来事| 動作| 次の状態| +-------------------+-----------------------+-----------------------+ | DATAFRAMEを受けてください。| DLC_DGRM| | +-------------------+-----------------------+-----------------------+ | DLC_dl_は始まりました。| LF価値です。| LF価値です。| | | DLC_dl_は始まりました。| DLC_dl_は始まりました。| | | またはよりすばらしい。| またはよりすばらしい。| | | LF Sizeと等しさ| LF Sizeと等しさ| | | CANUREACH_CsかLF| CANUREACH_CsかLF| | | サイズControlビットはセットしました: | サイズControlビットはセットしました: | | | ICANREACH_Csを送ってください。| 未定のサーキット_| | | ほかに: | ほかに: | | | _停止_dlをDLCに送ってください。| _ノアクまで_を止めてください。| +-------------------+-----------------------+-----------------------+ | DLC_誤り| | 連絡を断ちます。| +-------------------+-----------------------+-----------------------+ | DLC_DGRM| DATAFRAMEを送ってください。| | +-------------------+-----------------------+-----------------------+
The RESOLVE_PENDING state is entered upon receipt of a CANUREACH_cs message by the target DLSw. A data link is started, causing a Test command to be sent by the DLC.
RESOLVE_PENDING状態は目標DLSwによるCANUREACH_Csメッセージを受け取り次第入られます。 DLCによって送られるべきTestコマンドを引き起こして、データ・リンクは始動されます。
Several CANUREACH_cs messages can be received in the RESOLVE_PENDING state. The Data Link Switch may update its topology information based upon the origin MAC address information in each CANUREACH_cs message.
RESOLVE_PENDING状態にいくつかのCANUREACH_Csメッセージを受け取ることができます。 Data Link SwitchはそれぞれのCANUREACH_Csメッセージの起源MACアドレス情報に基づくトポロジー情報をアップデートするかもしれません。
Upon the receipt of a DLC_DL_STARTED signal in the RESOLVE_PENDING state, the Data Link Switch may update its topology table base upon the remote MAC address information. The ICANREACH_cs message must be returned to the first partner DLSw from which a CANUREACH_cs was received for this circuit, or an implementation may optionally reply to all partners from which the CANUREACH_cs was received.
RESOLVE_PENDING状態のDLC_DL_STARTED信号の領収書では、Data Link SwitchはリモートMACアドレス情報のトポロジーテーブルベースをアップデートするかもしれません。 CANUREACH_Csがこのサーキットに受け取られた最初のパートナーDLSwにICANREACH_Csメッセージを返さなければならない、さもなければ、実現は任意にCANUREACH_Csが受け取られたすべてのパートナーに答えるかもしれません。
The RESOLVE_PENDING state is exited once the data link has been started (i.e., a DLC_DL_STARTED signal is received as a result of a Test response received by the DLC). The target Data Link Switch then enters the CIRCUIT_PENDING state.
データ・リンクがいったん始動されると(DLCによって受けられたTest応答の結果、すなわち、DLC_DL_STARTED信号を受信します)、RESOLVE_PENDING状態は出られます。 そして、目標Data Link SwitchはCIRCUIT_PENDING状態に入ります。
Wells & Bartky [Page 28] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[28ページ]RFC1795データ・リンク
5.2.3 CIRCUIT_START State
5.2.3 サーキット_は状態を始めます。
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive CANUREACH_cs | If origin MAC addr | If DLC_START_DL | | for circuit in | in CANUREACH_cs is | issued: | | opposite direction | greater than origin | RESOLVE_PENDING | | | MAC addr of circuit:| | | | DLC_START_DL | | | | else: | | | | no action taken | | +----------------------+---------------------+----------------------+ | Receive ICANREACH_cs | If LF Size Control | If LF Size Control | | | bit set and LF Size | bit set and LF Size | | | is not negotiable: | is not negotiable: | | | Send HALT_DL_NOACK| DISCONNECTED | | | else: | else if Connected: | | | Send REACH_ACK, | CONNECT_PENDING | | | Send appropriate | else: | | | SSP message based | CIRCUIT_ESTABLISHED| | | on the event | | | | that generated | | | | CANUREACH_cs | | | | (see Note) | | +----------------------+---------------------+----------------------+ | DLC_DGRM | Send DATAFRAME | | +----------------------+---------------------+----------------------+ | DLC_ERROR | | DISCONNECTED | +----------------------+---------------------+----------------------+ | CS_TIMER_EXP | | DISCONNECTED | +----------------------+---------------------+----------------------+ | XPORT_FAILURE | | DISCONNECTED | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | CANUREACH_Csを受け取ってください。| 起源MAC addrです。| _DLCであるなら、_dlを始めてください。| | 中のサーキットに| CANUREACHでは、_Csはそうです。| 発行される: | | 逆方向| 起源よりすばらしいです。| 未定の_を決議してください。| | | サーキットのMAC addr:、|| | | DLC_スタート_dl| | | | ほかに: | | | | 取られなかった行動全く| | +----------------------+---------------------+----------------------+ | ICANREACH_Csを受け取ってください。| LFサイズであるなら、制御してください。| LFサイズであるなら、制御してください。| | | ビットのセットとLF Size| ビットのセットとLF Size| | | 交渉可能ではありません: | 交渉可能ではありません: | | | dl_ノアクを停止_に送ってください。| 連絡を断ちます。| | | ほかに: | ほか、Connectedであるなら: | | | 範囲_ACKを送ってください。| 未定の_を接続してください。| | | 適切な状態で、発信してください。| ほかに: | | | 基づくSSPメッセージ| _が確立したサーキット| | | 出来事に関して| | | | そんなに発生しています。| | | | CANUREACH_Cs| | | | (注意を見ます) | | +----------------------+---------------------+----------------------+ | DLC_DGRM| DATAFRAMEを送ってください。| | +----------------------+---------------------+----------------------+ | DLC_誤り| | 連絡を断ちます。| +----------------------+---------------------+----------------------+ | _Csタイマ_EXP| | 連絡を断ちます。| +----------------------+---------------------+----------------------+ | XPORT_失敗| | 連絡を断ちます。| +----------------------+---------------------+----------------------+
The CIRCUIT_START state is entered by the origin Data Link Switch when a DLC_XID or DLC_CONTACTED signal has been received from the DLC.
DLCからDLC_XIDかDLC_CONTACTED信号を受信したとき、起源Data Link SwitchはCIRCUIT_START状態に入ります。
The CIRCUIT_START state is exited upon receipt of an ICANREACH_cs message. A REACH_ACK message is returned to the target Data Link Switch. If the CIRCUIT_START state was entered due to a DLC_XID signal, an XIDFRAME message containing the XID is sent to the target Data Link Switch. If the CIRCUIT_START state was entered due to a DLC_CONTACTED signal, a CONTACT message is sent to the target Data Link Switch.
CIRCUIT_START状態はICANREACH_Csメッセージを受け取り次第出られます。 REACH_ACKメッセージを目標Data Link Switchに返します。 DLC_XID信号のためCIRCUIT_START状態に入ったなら、XIDを含むXIDFRAMEメッセージを目標Data Link Switchに送ります。 DLC_CONTACTED信号のためCIRCUIT_START状態に入ったなら、CONTACTメッセージを目標Data Link Switchに送ります。
Wells & Bartky [Page 29] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[29ページ]RFC1795データ・リンク
5.2.4 CIRCUIT_PENDING State
5.2.4 状態までサーキット_
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive CONTACT | DLC_CONTACT | CONTACT_PENDING | +----------------------+---------------------+----------------------+ | Receive HALT_DL | DLC_HALT_DL | HALT_PENDING | +----------------------+---------------------+----------------------+ | Receive HALT_DL_NOACK| DLC_HALT_DL | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+ | Receive REACH_ACK | If Connected: | If Connected: | | | Send CONTACT | CONNECT_PENDING, | | | | else: | | | | CIRCUIT_ESTABLISHED | +----------------------+---------------------+----------------------+ | Receive XIDFRAME | DLC_XID | | +----------------------+---------------------+----------------------+ | Receive DGRMFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | Receive DATAFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | DLC_CONTACTED | If UA is sent in | | | | response to SABME: | | | | DLC_ENTER_BUSY | | | | else: | | | | no action taken | | +----------------------+---------------------+----------------------+ | DLC_ERROR | | DISCONNECTED | +----------------------+---------------------+----------------------+ | DLC_XID | Drop or hold until | | | | REACH_ACK received | | +----------------------+---------------------+----------------------+ | DLC_DGRM | Send DATAFRAME | | +----------------------+---------------------+----------------------+ | XPORT_FAILURE | DLC_HALT_DL | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | 接触を受けてください。| DLC_接触| 未定の接触_| +----------------------+---------------------+----------------------+ | 停止_dlを受け取ってください。| DLC_停止_dl| 未定の_を止めてください。| +----------------------+---------------------+----------------------+ | HALT_dl_ノアクを受けてください。| DLC_停止_dl| _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+ | 範囲_ACKを受けてください。| 接続されるなら: | 接続されるなら: | | | 接触を送ってください。| 未定の_を接続してください。| | | | ほかに: | | | | _が確立したサーキット| +----------------------+---------------------+----------------------+ | XIDFRAMEを受けてください。| DLC_XID| | +----------------------+---------------------+----------------------+ | DGRMFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | DATAFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | 連絡されたDLC_| UAが送られるなら| | | | SABMEへの応答: | | | | DLC_は忙しい状態で_に入ります。| | | | ほかに: | | | | 取られなかった行動全く| | +----------------------+---------------------+----------------------+ | DLC_誤り| | 連絡を断ちます。| +----------------------+---------------------+----------------------+ | DLC_XID| 低下するか、または成立してください。| | | | REACH_ACKは受信しました。| | +----------------------+---------------------+----------------------+ | DLC_DGRM| DATAFRAMEを送ってください。| | +----------------------+---------------------+----------------------+ | XPORT_失敗| DLC_停止_dl| _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+
The CIRCUIT_PENDING state is entered by the target Data Link Switch following the sending of an ICANREACH_cs message. In this state it is awaiting the reception of a REACH_ACK message from the origin Data Link Switch.
ICANREACH_Csメッセージの発信に続いて、CIRCUIT_PENDING状態は目標Data Link Switchによって入られます。 この状態では、それは起源Data Link SwitchからのREACH_ACKメッセージのレセプションを待っています。
If the target Data Link Switch happens to receive a SABME command from the target station while in the CIRCUIT_PENDING state (i.e., a DLC_CONTACTED signal received from the DLC), the reception of the REACH_ACK message causes the target Data Link Switch to enter the CONNECT_PENDING state and to send a CONTACT message to the origin
REACH_ACKメッセージのレセプションが、CIRCUIT_PENDING状態(すなわち、DLCから受信されたDLC_CONTACTED信号)で目標Data Link SwitchがCONNECT_PENDING状態に入力して、CONTACTメッセージを起源に送ることを引き起こしますが、目標Data Link Switchが目標ステーションからSABMEコマンドをたまたま受け取るなら
Wells & Bartky [Page 30] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[30ページ]RFC1795データ・リンク
Data Link Switch.
データはスイッチをリンクします。
If no such SABME is received, the receipt of the REACH_ACK causes the Data Link Switch to enter CIRCUIT_ESTABLISHED state.
そのようなどれかSABMEが受け取られていないなら、REACH_ACKの領収書で、Data Link SwitchはCIRCUIT_ESTABLISHED状態に入ります。
5.2.5 CONNECT_PENDING State
5.2.5 _未定の状態をつなげてください。
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive CONTACTED | If UA was sent in | CONNECTED | | | response to SABME: | | | | DLC_EXIT_BUSY | | | | else: | | | | DLC_CONTACT | | +----------------------+---------------------+----------------------+ | Receive HALT_DL | DLC_HALT_DL | HALT_PENDING | +----------------------+---------------------+----------------------+ | Receive HALT_DL_NOACK| DLC_HALT_DL | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+ | Receive DGRMFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | Receive DATAFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | Receive ICANREACH_cs | Send HALT_DL_NOACK | | +----------------------+---------------------+----------------------+ | DLC_RESET | Send RESTART_DL | CIRCUIT_RESTART | +----------------------+---------------------+----------------------+ | DLC_ERROR | Send HALT_DL | DISCONNECT_PENDING | +----------------------+---------------------+----------------------+ | DLC_DGRM | Send DGRMFRAME | | +----------------------+---------------------+----------------------+ | XPORT_FAILURE | DLC_HALT_DL | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | 連絡されていた状態で、受信してください。| UAが送られたなら| 接続されます。| | | SABMEへの応答: | | | | DLC_出口_忙しいです。| | | | ほかに: | | | | DLC_接触| | +----------------------+---------------------+----------------------+ | 停止_dlを受け取ってください。| DLC_停止_dl| 未定の_を止めてください。| +----------------------+---------------------+----------------------+ | HALT_dl_ノアクを受けてください。| DLC_停止_dl| _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+ | DGRMFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | DATAFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | ICANREACH_Csを受け取ってください。| dl_ノアクを停止_に送ってください。| | +----------------------+---------------------+----------------------+ | DLC_リセット| 再開_dlを送ってください。| サーキット_再開| +----------------------+---------------------+----------------------+ | DLC_誤り| 停止_dlを送ってください。| 未定の_を外してください。| +----------------------+---------------------+----------------------+ | DLC_DGRM| DGRMFRAMEを送ってください。| | +----------------------+---------------------+----------------------+ | XPORT_失敗| DLC_停止_dl| _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+
The CONNECT_PENDING state is entered when a DLC_CONTACTED signal has been received from the DLC (i.e., a SABME command has been received). A CONTACT message it then issued. The state is exited upon the receipt of a CONTACTED message. If a DLC_RESET signal is received, the local data link is restarted and a RESTART_DL message is sent to the remote DLSw.
DLCからDLC_CONTACTED信号を受信したとき(すなわち、SABMEコマンドを受け取りました)、CONNECT_PENDING状態に入ります。 次にそれが発行したCONTACTメッセージ。 状態はCONTACTEDメッセージの領収書で出られます。 DLC_RESET信号が受信されているなら、地方のデータ・リンクを再開します、そして、RESTART_DLメッセージをリモートDLSwに送ります。
An ICANREACH_cs received after the transition to CONNECT_PENDING state indicates that more than one CANUREACH_cs was sent at circuit establishment time and the target station was found by more than one Data Link Switch partner. A HALT_DL_NOACK is sent to halt the circuit started by the Data Link Switch partner that originated each such ICANREACH_cs.
CONNECT_PENDING状態への変遷が、サーキット設立時間に1CANUREACHの_Csを送って、1人以上のData Link Switchパートナーが目標ステーションを見つけたのを示した後にICANREACH_Csは受信されました。 そのような各ICANREACH_Csを溯源したData Link Switchパートナーによって始動されたサーキットを止めるためにHALT_DL_ノアクを送ります。
Wells & Bartky [Page 31] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[31ページ]RFC1795データ・リンク
Note: Some implementations will also send a Test command in order to restart the data link to the station that sent the SABME command (i.e., a DLC_START_DL will be issued).
以下に注意してください。 また、いくつかの実現が、SABMEコマンドを送ったステーションにデータ・リンクを再開するためにTestコマンドを送るでしょう(すなわち、DLC_START_DLは発行されるでしょう)。
5.2.6 CIRCUIT_ESTABLISHED State
5.2.6 サーキット_は状態を設置しました。
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive CONTACT | DLC_CONTACT | CONTACT_PENDING | +----------------------+---------------------+----------------------+ | Receive HALT_DL | DLC_HALT_DL | HALT_PENDING | +----------------------+---------------------+----------------------+ | Receive HALT_DL_NOACK| DLC_HALT_DL | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+ | Receive XIDFRAME | DLC_XID | | +----------------------+---------------------+----------------------+ | Receive DGRMFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | Receive DATAFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | Receive ICANREACH_cs | Send HALT_DL_NOACK | | +----------------------+---------------------+----------------------+ | DLC_CONTACTED | Send CONTACT | CONNECT_PENDING | | | If UA is sent in | | | | response to SABME: | | | | DLC_ENTER_BUSY | | | | else: | | | | no action taken | | +----------------------+---------------------+----------------------+ | DLC_ERROR | Send HALT_DL | DISCONNECT_PENDING | +----------------------+---------------------+----------------------+ | DLC_DGRM | Send DGRMFRAME | | +----------------------+---------------------+----------------------+ | DLC_XID | Send XIDFRAME | | +----------------------+---------------------+----------------------+ | XPORT_FAILURE | DLC_HALT_DL | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | 接触を受けてください。| DLC_接触| 未定の接触_| +----------------------+---------------------+----------------------+ | 停止_dlを受け取ってください。| DLC_停止_dl| 未定の_を止めてください。| +----------------------+---------------------+----------------------+ | HALT_dl_ノアクを受けてください。| DLC_停止_dl| _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+ | XIDFRAMEを受けてください。| DLC_XID| | +----------------------+---------------------+----------------------+ | DGRMFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | DATAFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | ICANREACH_Csを受け取ってください。| dl_ノアクを停止_に送ってください。| | +----------------------+---------------------+----------------------+ | 連絡されたDLC_| 接触を送ってください。| 未定の_を接続してください。| | | UAが送られるなら| | | | SABMEへの応答: | | | | DLC_は忙しい状態で_に入ります。| | | | ほかに: | | | | 取られなかった行動全く| | +----------------------+---------------------+----------------------+ | DLC_誤り| 停止_dlを送ってください。| 未定の_を外してください。| +----------------------+---------------------+----------------------+ | DLC_DGRM| DGRMFRAMEを送ってください。| | +----------------------+---------------------+----------------------+ | DLC_XID| XIDFRAMEを送ってください。| | +----------------------+---------------------+----------------------+ | XPORT_失敗| DLC_停止_dl| _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+
The CIRCUIT_ESTABLISHED state is entered by the origin Data Link Switch from the CIRCUIT_START state, and by the target Data Link Switch from the CIRCUIT_PENDING state. The state is exited when a connection is started (i.e., DLC receives a SABME command) or CONTACT is received. The next state is CONTACT_PENDING or CONNECT_PENDING.
_ESTABLISHEDがあると述べるCIRCUITはCIRCUIT_START状態、およびCIRCUIT_PENDING状態からの目標Data Link Switchで起源Data Link Switchから入りました。 接続が始められるとき(すなわち、DLCはSABMEコマンドを受け取ります)、状態が出られるか、またはCONTACTは受け取られています。 次の状態は、CONTACT_PENDINGかCONNECT_PENDINGです。
An ICANREACH_cs received after the transition to CIRCUIT_ESTABLISHED state indicates that more than one CANUREACH_cs was sent at circuit establishment time and the target station was found by more than one
CIRCUIT_ESTABLISHED状態への変遷が、サーキット設立時間に1CANUREACHの_Csを送って、1つ以上が目標ステーションを見つけたのを示した後に受け取られたICANREACH_Cs
Wells & Bartky [Page 32] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[32ページ]RFC1795データ・リンク
Data Link Switch partner. A HALT_DL_NOACK is sent to halt the circuit started by the Data Link Switch partner that originated each such ICANREACH_cs.
データLink Switchパートナー。 そのような各ICANREACH_Csを溯源したData Link Switchパートナーによって始動されたサーキットを止めるためにHALT_DL_ノアクを送ります。
5.2.7 CONTACT_PENDING State
5.2.7 _未定の状態に接触してください。
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive HALT_DL | DLC_HALT_DL | HALT_PENDING | +----------------------+---------------------+----------------------+ | Receive HALT_DL_NOACK| DLC_HALT_DL | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+ | Receive RESTART_DL | DLC_HALT_DL | RESTART_PENDING | +----------------------+---------------------+----------------------+ | Receive DGRMFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | Receive DATAFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | DLC_CONTACTED | Send CONTACTED | CONNECTED | +----------------------+---------------------+----------------------+ | DLC_ERROR | Send HALT_DL | DISCONNECT_PENDING | +----------------------+---------------------+----------------------+ | DLC_DGRM | Send DGRMFRAME | | +----------------------+---------------------+----------------------+ | XPORT_FAILURE | DLC_HALT_DL | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | 停止_dlを受け取ってください。| DLC_停止_dl| 未定の_を止めてください。| +----------------------+---------------------+----------------------+ | HALT_dl_ノアクを受けてください。| DLC_停止_dl| _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+ | 再開_dlを受け取ってください。| DLC_停止_dl| 未定の再開_| +----------------------+---------------------+----------------------+ | DGRMFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | DATAFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | 連絡されたDLC_| 連絡されていた状態で、発信してください。| 接続されます。| +----------------------+---------------------+----------------------+ | DLC_誤り| 停止_dlを送ってください。| 未定の_を外してください。| +----------------------+---------------------+----------------------+ | DLC_DGRM| DGRMFRAMEを送ってください。| | +----------------------+---------------------+----------------------+ | XPORT_失敗| DLC_停止_dl| _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+
The CONTACT_PENDING state is entered upon the receipt of a CONTACT message, which causes the Data Link Switch to issue a DLC_CONTACT signal to the DLC (i.e., DLC sends a SABME command). This state is then exited upon the receipt of a DLC_CONTACTED signal from the DLC (i.e., a UA response received).
入られる_PENDINGがData Link SwitchがDLC_CONTACTを発行するCONTACTメッセージの領収書で述べるCONTACTはDLCに合図します(すなわち、DLCはSABMEコマンドを送ります)。 そして、この状態はDLCからのDLC_CONTACTED信号の領収書で出られます(すなわち、UA応答は受信されました)。
If a RESTART_DL message is received, indicating that the remote Data Link Switch has received a DLC_RESET signal, the local Data Link Switch sends a DISC command frame on the adjacent LAN (i.e., DLC_HALT_DL signal) and enter the RESTART_PENDING state.
リモートData Link SwitchがDLC_RESET信号を受信したのを示して、RESTART_DLメッセージが受信されているなら、地方のData Link Switchは隣接しているLAN(すなわち、DLC_HALT_DL信号)にDISCコマンド・フレームを送って、RESTART_PENDING状態に入れます。
An ICANREACH_cs received after the transition to CONTACT_PENDING state indicates that more than one CANUREACH_cs was sent at circuit establishment time and the target station was found by more than one Data Link Switch partner. A HALT_DL_NOACK is sent to halt the data link started by the Data Link Switch partner that originated this ICANREACH_cs.
CONTACT_PENDING状態への変遷が、サーキット設立時間に1CANUREACHの_Csを送って、1人以上のData Link Switchパートナーが目標ステーションを見つけたのを示した後にICANREACH_Csは受信されました。 このICANREACH_Csを溯源したData Link Switchパートナーによって始動されたデータ・リンクを止めるためにHALT_DL_ノアクを送ります。
Wells & Bartky [Page 33] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[33ページ]RFC1795データ・リンク
5.2.8 CONNECTED State
5.2.8 関連状態
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive HALT_DL | DLC_HALT_DL | HALT_PENDING | +----------------------+---------------------+----------------------+ | Receive HALT_DL_NOACK| DLC_HALT_DL | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+ | Receive RESTART_DL | DLC_HALT_DL | RESTART_PENDING | +----------------------+---------------------+----------------------+ | Receive DGRMFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | Receive INFOFRAME | DLC_INFO | | +----------------------+---------------------+----------------------+ | Receive DATAFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | Receive XIDFRAME | If non-activation | | | | XID3: | | | | DLC_XID | | +----------------------+---------------------+----------------------+ | Receive ICANREACH_cs | Send HALT_DL_NOACK | | +----------------------+---------------------+----------------------+ | Receive ENTER_BUSY | DLC_ENTER_BUSY | | +----------------------+---------------------+----------------------+ | Receive EXIT_BUSY | DLC_EXIT_BUSY | | +----------------------+---------------------+----------------------+ | Rec TEST_CIRCUIT_REQ | Snd TEST_CIRCUIT_RSP| | +----------------------+---------------------+----------------------+ | DLC_RESET | Send RESTART_DL | CIRCUIT_RESTART | +----------------------+---------------------+----------------------+ | DLC_ERROR | Send HALT_DL | DISCONNECT_PENDING | +----------------------+---------------------+----------------------+ | DLC_DGRM | Send DGRMFRAME | | +----------------------+---------------------+----------------------+ | DLC_INFO | Send INFOFRAME | | +----------------------+---------------------+----------------------+ | DLC_XID | If non-activation | | | | XID3: | | | | Send XIDFRAME | | +----------------------+---------------------+----------------------+ | XPORT_FAILURE | DLC_HALT_DL | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | 停止_dlを受け取ってください。| DLC_停止_dl| 未定の_を止めてください。| +----------------------+---------------------+----------------------+ | HALT_dl_ノアクを受けてください。| DLC_停止_dl| _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+ | 再開_dlを受け取ってください。| DLC_停止_dl| 未定の再開_| +----------------------+---------------------+----------------------+ | DGRMFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | INFOFRAMEを受けてください。| DLC_インフォメーション| | +----------------------+---------------------+----------------------+ | DATAFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | XIDFRAMEを受けてください。| 非起動| | | | XID3: | | | | DLC_XID| | +----------------------+---------------------+----------------------+ | ICANREACH_Csを受け取ってください。| dl_ノアクを停止_に送ってください。| | +----------------------+---------------------+----------------------+ | 受信、忙しい状態で_に入ってください。| DLC_は忙しい状態で_に入ります。| | +----------------------+---------------------+----------------------+ | 忙しい状態で出口_を受けてください。| DLC_出口_忙しいです。| | +----------------------+---------------------+----------------------+ | _Recテスト_サーキットREQ| _Sndテスト_サーキットRSP| | +----------------------+---------------------+----------------------+ | DLC_リセット| 再開_dlを送ってください。| サーキット_再開| +----------------------+---------------------+----------------------+ | DLC_誤り| 停止_dlを送ってください。| 未定の_を外してください。| +----------------------+---------------------+----------------------+ | DLC_DGRM| DGRMFRAMEを送ってください。| | +----------------------+---------------------+----------------------+ | DLC_インフォメーション| INFOFRAMEを送ってください。| | +----------------------+---------------------+----------------------+ | DLC_XID| 非起動| | | | XID3: | | | | XIDFRAMEを送ってください。| | +----------------------+---------------------+----------------------+ | XPORT_失敗| DLC_停止_dl| _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+
The CONNECTED state is entered from the CONNECT_PENDING state upon the receipt of a CONTACTED message or from the CONTACT_PENDING state upon the receipt of a DLC_CONTACTED signal.
CONNECTED状態はCONTACTEDメッセージの領収書のCONNECT_PENDING州かDLC_CONTACTED信号の領収書のCONTACT_PENDING状態から入られます。
Wells & Bartky [Page 34] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[34ページ]RFC1795データ・リンク
The CONNECTED state is exited usually under one of two conditions: a DLC_ERROR signal received from the DLC (e.g., a DISC command received by the local DLC), or a HALT_DL message received from the other Data Link Switch (e.g., a DISC command received by the remote DLC).
CONNECTED状態は通常2つの状態の1つの下で出られます: DLC_ERROR信号がDLCから受信されたか(例えばDISCコマンドは地方のDLCのそばで受信されました)、またはHALT_DLメッセージはもう片方のData Link Switchから受信されました(例えばDISCコマンドはリモートDLCのそばで受信されました)。
A SABME command (i.e., a DLC_RESET signal) received by either Data Link Switch will also cause the two Data Link Switches to leave the CONNECTED state and attempt to restart the circuit. Following the receipt of a SABME, the local Data Link Switch sends a RESTART_DL message to the other Data Link Switch and enters the CIRCUIT_RESTART state. Upon the receipt of the RESTART_DL message, the remote Data Link Switch sends a DISC command (i.e., DLC_HALT_DL signal) and enters the RESTART_PENDING state.
また、Data Link Switchによって受け取られたSABMEコマンド(すなわち、DLC_RESET信号)は、2Data Link Switchesが、CONNECTEDを状態に残して、サーキットを再開するのを試みることを引き起こすでしょう。 SABMEの領収書に従って、地方のData Link SwitchはRESTART_DLメッセージをもう片方のData Link Switchに送って、CIRCUIT_RESTART状態に入力します。 RESTART_DLメッセージの領収書で、リモートData Link Switchはコマンド(すなわち、DLC_HALT_DL信号)をDISCに送って、RESTART_PENDING状態に入力します。
An ICANREACH_cs received after the transition to CONNECTED state indicates that more than one CANUREACH_cs was sent at circuit establishment time and the target station was found by more than one Data Link Switch partner. A HALT_DL_NOACK is sent to halt the circuit started by the Data Link Switch partner that originated each such ICANREACH_cs.
CONNECTED状態への変遷が、サーキット設立時間に1CANUREACHの_Csを送って、1人以上のData Link Switchパートナーが目標ステーションを見つけたのを示した後にICANREACH_Csは受信されました。 そのような各ICANREACH_Csを溯源したData Link Switchパートナーによって始動されたサーキットを止めるためにHALT_DL_ノアクを送ります。
Note: Some implementations will also send a Test command in order to restart the data link to the station that sent the SABME command (i.e., a DLC_START_DL will be issued).
以下に注意してください。 また、いくつかの実現が、SABMEコマンドを送ったステーションにデータ・リンクを再開するためにTestコマンドを送るでしょう(すなわち、DLC_START_DLは発行されるでしょう)。
5.2.9 CIRCUIT_RESTART State
5.2.9 サーキット_再開状態
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive DL_RESTARTED | If Connected: | If Connected: | | | Send CONTACT | CONNECT_PENDING, | | | | else: | | | | CIRCUIT_ESTABLISHED | +----------------------+---------------------+----------------------+ | Receive HALT_DL_NOACK| DLC_HALT_DL | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+ | Receive DGRMFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | DLC_ERROR | Send HALT_DL | DISCONNECT_PENDING | +----------------------+---------------------+----------------------+ | DLC_DGRM | Send DGRMFRAME | | +----------------------+---------------------+----------------------+ | XPORT_FAILURE | DLC_HALT_DL | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | _が再開したdlを受け取ってください。| 接続されるなら: | 接続されるなら: | | | 接触を送ってください。| 未定の_を接続してください。| | | | ほかに: | | | | _が確立したサーキット| +----------------------+---------------------+----------------------+ | HALT_dl_ノアクを受けてください。| DLC_停止_dl| _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+ | DGRMFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | DLC_誤り| 停止_dlを送ってください。| 未定の_を外してください。| +----------------------+---------------------+----------------------+ | DLC_DGRM| DGRMFRAMEを送ってください。| | +----------------------+---------------------+----------------------+ | XPORT_失敗| DLC_停止_dl| _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+
Wells & Bartky [Page 35] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[35ページ]RFC1795データ・リンク
The CIRCUIT_RESTART state is entered if a DLC_RESET signal is received from the local DLC. This was caused by the receipt of a SABME command while a connection was currently active. A DM response will be issued to the SABME command and the Data Link Switch will attempt to restart the end-to-end circuit.
地方のDLCからDLC_RESET信号を受信するなら、CIRCUIT_RESTART状態に入ります。 接続が現在活発であった間、これはSABMEコマンドの領収書で引き起こされました。 DM応答はSABMEコマンドに発行されるでしょう、そして、Data Link Switchは終わりから端へのサーキットを再開するのを試みるでしょう。
The CIRCUIT_RESTART state is exited through one of two transitions. The next state depends upon the time the local DLC has reached the contacted state (i.e., a DLC_CONTACTED signal is presented) relative to the receipt of the DL_RESTARTED message. This signal is caused by the origin station resending the SABME command that initially caused the Data Link Switch to enter the CIRCUIT_RESTART state. The two cases are as follows:
CIRCUIT_RESTART状態は2つの変遷の1つで出られます。 地方のDLCがDL_RESTARTEDメッセージの領収書に比例して連絡された状態(すなわち、DLC_CONTACTED信号は提示される)に達したとき、次の状態は依存します。 この信号はData Link Switchが初めはCIRCUIT_RESTART状態に入ったSABMEコマンドを再送する起源ステーションによって引き起こされます。 2つのケースは以下の通りです:
1) DL_RESTARTED message received before the DLC_CONTACTED signal-
In this case, the CIRCUIT_ESTABLISHED state is entered.
1) この場合CIRCUIT_ESTABLISHEDが述べるDLC_CONTACTED信号の前に受け取られたDL_RESTARTEDメッセージは入力されます。
2) DL_RESTARTED message received after the DLC_CONTACTED signal-
In this case, the CONNECT_PENDING state is entered.
2) この場合CONNECT_PENDINGが述べるDLC_CONTACTED信号の後に受け取られたDL_RESTARTEDメッセージは入力されます。
5.2.10 DISCONNECT_PENDING State
5.2.10 _未定の状態を外してください。
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive DL_HALTED | | DISCONNECTED | +----------------------+---------------------+----------------------+ | Receive HALT_DL | Send DL_HALTED | | +----------------------+---------------------+----------------------+ | Receive HALT_DL_NOACK| | DISCONNECTED | +----------------------+---------------------+----------------------+ | Receive DATAFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | DLC_DGRM | Send DATAFRAME | | +----------------------+---------------------+----------------------+ | XPORT_FAILURE | | DISCONNECTED | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | _が止めたdlを受け取ってください。| | 連絡を断ちます。| +----------------------+---------------------+----------------------+ | 停止_dlを受け取ってください。| _が止めたdlを送ってください。| | +----------------------+---------------------+----------------------+ | HALT_dl_ノアクを受けてください。| | 連絡を断ちます。| +----------------------+---------------------+----------------------+ | DATAFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | DLC_DGRM| DATAFRAMEを送ってください。| | +----------------------+---------------------+----------------------+ | XPORT_失敗| | 連絡を断ちます。| +----------------------+---------------------+----------------------+
The DISCONNECT_PENDING state is entered when a DLC_ERROR signal is received from the local DLC. Upon receipt of this signal, a HALT_DL message is sent. Once an DL_HALTED message is received, the state is exited, and the Data Link Switch enters the DISCONNECTED state.
地方のDLCからDLC_ERROR信号を受信するとき、DISCONNECT_PENDING状態に入ります。 この信号を受け取り次第、HALT_DLメッセージを送ります。 DL_HALTEDメッセージがいったん受信されるようになると、状態は出られます、そして、Data Link SwitchはDISCONNECTED状態に入ります。
Wells & Bartky [Page 36] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[36ページ]RFC1795データ・リンク
5.2.11 RESTART_PENDING State
5.2.11 _未定の状態を再開してください。
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive HALT_DL_NOACK| | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+ | Receive DGRMFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | DLC_DL_HALTED | Send DL_RESTARTED | CIRCUIT_ESTABLISHED | +----------------------+---------------------+----------------------+ | DLC_ERROR | Send HALT_DL | DISCONNECT_PENDING | +----------------------+---------------------+----------------------+ | DLC_DGRM | Send DGRMFRAME | | +----------------------+---------------------+----------------------+ | XPORT_FAILURE | DLC_HALT_DL | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | HALT_dl_ノアクを受けてください。| | _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+ | DGRMFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | DLC_dl_は停止しました。| _が再開したdlを送ってください。| _が確立したサーキット| +----------------------+---------------------+----------------------+ | DLC_誤り| 停止_dlを送ってください。| 未定の_を外してください。| +----------------------+---------------------+----------------------+ | DLC_DGRM| DGRMFRAMEを送ってください。| | +----------------------+---------------------+----------------------+ | XPORT_失敗| DLC_停止_dl| _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+
The RESTART_PENDING state is entered upon the receipt of a RESTART_DL message from the remote DLSw while the local Data Link Switch is in either the CONTACT_PENDING state or the CONNECTED state, which causes the local DLSw to issue a DISC command to the DLC. Upon the receipt of the UA response (DLC_DL_HALTED), the data link is restarted, a DL_RESTARTED message is returned to the remote DLSw, and the CIRCUIT_ESTABLISHED state is entered.
地方のData Link SwitchがCONTACT_PENDING州かCONNECTED州(地方のDLSwにDISCコマンドをDLCに発行させる)のどちらかにある間、RESTART_PENDING状態はリモートDLSwからのRESTART_DLメッセージの領収書で入られます。 UA応答(DLC_DL_HALTED)の領収書では、データ・リンクを再開します、そして、DL_RESTARTEDメッセージをリモートDLSwに返します、そして、CIRCUIT_ESTABLISHED状態を入れます。
Note: Some implementations will send a Test command in order to restart the data link to the target station (i.e., a DLC_START_DL will be issued) prior to sending the DL_RESTARTED message.
以下に注意してください。 いくつかの実現が、DL_RESTARTEDメッセージを送る前に目標ステーション(すなわち、DLC_START_DLは発行される)にデータ・リンクを再開するためにTestコマンドを送るでしょう。
5.2.12 HALT_PENDING State
5.2.12 _未定の状態を止めてください。
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive HALT_DL_NOACK| | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+ | Receive DATAFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | DLC_DL_HALTED | Send DL_HALTED | DISCONNECTED | +----------------------+---------------------+----------------------+ | DLC_ERROR | Send DL_HALTED | DISCONNECTED | +----------------------+---------------------+----------------------+ | DLC_DGRM | Send DATAFRAME | | +----------------------+---------------------+----------------------+ | XPORT_FAILURE | | HALT_PENDING_NOACK | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | HALT_dl_ノアクを受けてください。| | _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+ | DATAFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | DLC_dl_は停止しました。| _が止めたdlを送ってください。| 連絡を断ちます。| +----------------------+---------------------+----------------------+ | DLC_誤り| _が止めたdlを送ってください。| 連絡を断ちます。| +----------------------+---------------------+----------------------+ | DLC_DGRM| DATAFRAMEを送ってください。| | +----------------------+---------------------+----------------------+ | XPORT_失敗| | _ノアクまで_を止めてください。| +----------------------+---------------------+----------------------+
Wells & Bartky [Page 37] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[37ページ]RFC1795データ・リンク
The HALT_PENDING state is entered upon the receipt of a HALT_DL message. This causes the local DLC to issue a DISC command. Upon the receipt of the UA response (DLC_DL_HALTED), a DL_HALTED message is returned to the remote DLSw and the DISCONNECTED state is entered.
HALT_PENDING状態はHALT_DLメッセージの領収書で入られます。 これで、地方のDLCはDISCコマンドを発行します。 UA応答(DLC_DL_HALTED)の領収書で、DL_HALTEDメッセージをリモートDLSwに返します、そして、DISCONNECTED状態を入れます。
5.2.13 HALT_PENDING_NOACK State
5.2.13 _未定の_ノアク状態を止めてください。
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive DATAFRAME | DLC_DGRM | | +----------------------+---------------------+----------------------+ | DLC_DL_HALTED | | DISCONNECTED | +----------------------+---------------------+----------------------+ | DLC_ERROR | | DISCONNECTED | +----------------------+---------------------+----------------------+ | DLC_DGRM | Send DATAFRAME | | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | DATAFRAMEを受けてください。| DLC_DGRM| | +----------------------+---------------------+----------------------+ | DLC_dl_は停止しました。| | 連絡を断ちます。| +----------------------+---------------------+----------------------+ | DLC_誤り| | 連絡を断ちます。| +----------------------+---------------------+----------------------+ | DLC_DGRM| DATAFRAMEを送ってください。| | +----------------------+---------------------+----------------------+
The HALT_PENDING_NOACK state is entered upon the receipt of a HALT_DL_NOACK message. This causes the local DLC to issue a DISC command. Upon the receipt of the UA response (DLC_DL_HALTED), the DISCONNECTED state is entered.
HALT_PENDING_ノアク状態はHALT_DL_ノアクメッセージの領収書で入られます。 これで、地方のDLCはDISCコマンドを発行します。 UA応答(DLC_DL_HALTED)の領収書で、DISCONNECTED状態は入られます。
5.3 NetBIOS Datagrams
5.3 NetBIOSデータグラム
The NetBIOS protocols use a number of UI frames for directory services and the transmission of datagrams. Most of these frames are directed to a group MAC address (GA) with the routing information field indicating spanning tree explorer (STE) (a.k.a. Single Route Broadcast). The NB_Add_Name_Response and NB_Name_Recognized frames are directed to a specific MAC address with the routing information field indicating an all routes explorer frame (ARE) (a.k.a. All Routes Broadcast) The NB_Status_Response frame, is directed to a specific MAC address with the routing information field indicating a specifically routed frame (SRF). The handling of these frames is summarized in the following table.
NetBIOSプロトコルは電話番号案内のための多くのUIフレームとデータグラムのトランスミッションを使用します。ルーティング情報フィールドがスパニングツリー探検家(STE)(通称Single Route Broadcast)を示していて、これらのフレームの大部分はグループMACアドレス(ジョージア)に向けられます。 ルーティング情報フィールドが明確に発送されたフレーム(SRF)を示していて、ネブラスカ_Add_Name_Responseとネブラスカ_Name_Recognizedフレームは特定のMACアドレスへのルーティング情報フィールドが、ネブラスカ_Status_Responseが縁どるすべてのルート探検家フレーム(あります)(通称All Routes Broadcast)が指示されているのを示している特定のMACアドレスに向けられます。 これらのフレームの取り扱いは以下のテーブルにまとめられます。
Wells & Bartky [Page 38] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[38ページ]RFC1795データ・リンク
+---------------------------+------------------+--------------------+ | Event | Action(s) | Comment | +---------------------------+------------------+--------------------+ | DLC_DGRM for NETBIOS | Send NETBIOS_ANQ | Transmitted to all | | group address: | | remote DLSw | | NB_Add_Name_Query | | | +---------------------------+------------------+--------------------+ | DLC_DGRM for a specific | Send NETBIOS_ANR | Transmitted to | | address: | | specific DLSw | | NB_Add_Name_Response | | | +---------------------------+------------------+--------------------+ | DLC_DGRM for a specific | Send DATAFRAME | Transmitted to all | | address: | | remote DLSw | | NB_Status_Response | | | +---------------------------+------------------+--------------------+ | DLC_DGRM for NETBIOS | Send DATAFRAME | Transmitted to all | | group address: | | remote DLSw | | NB_Name_in_Conflict | | | | NB_Add_Group_Name_Query | | | | NB_Datagram, | | | | NB_Datagram_Broadcast | | | | NB_Status_Query | | | | NB_Terminate_Trace | | | +---------------------------+------------------+--------------------+
+---------------------------+------------------+--------------------+ | 出来事| 動作| コメント| +---------------------------+------------------+--------------------+ | NETBIOSのためのDLC_DGRM| NETBIOS_ANQを送ってください。| すべてに伝えられます。| | アドレスを分類してください: | | リモートDLSw| | ネブラスカ_は_名前_質問を加えます。| | | +---------------------------+------------------+--------------------+ | 詳細のためのDLC_DGRM| NETBIOS_ANRを送ってください。| 伝えられます。| | アドレス: | | 特定のDLSw| | ネブラスカ_は_名前_応答を加えます。| | | +---------------------------+------------------+--------------------+ | 詳細のためのDLC_DGRM| DATAFRAMEを送ってください。| すべてに伝えられます。| | アドレス: | | リモートDLSw| | ネブラスカ_状態_応答| | | +---------------------------+------------------+--------------------+ | NETBIOSのためのDLC_DGRM| DATAFRAMEを送ってください。| すべてに伝えられます。| | アドレスを分類してください: | | リモートDLSw| | _闘争におけるネブラスカ_名前_| | | | ネブラスカ_は_グループ_名前_質問を加えます。| | | | ネブラスカ_データグラム| | | | ネブラスカ_データグラム_放送| | | | ネブラスカ_状態_質問| | | | ネブラスカ_は_跡を終えます。| | | +---------------------------+------------------+--------------------+
The above actions do not apply in the following states: CIRCUIT_ESTABLISHED, CONTACT_PENDING, CONNECT_PENDING, CONNECTED, and CIRCUIT_PENDING. The handling of the remaining two UI frames used by NetBIOS systems, NB_Name_Query and NB_Name_Recognized, are documented as part of the DLSw state machine in the previous section (i.e., DISCONNECTED and RESOLVE_PENDING states). Furthermore, the handling of NetBIOS datagrams (i.e., NB_Datagram) sent to a specific MAC address is also governed by the DLSw state machine.
上の動作は以下の州で適用されません: _が確立したサーキット、未定の接触_は未定の_、未定の接続されるのとサーキットの_を接続します。 システム_ネブラスカName_Queryと_(ネブラスカName_Recognized)が記録されるNetBIOSが使用された2個の残っているUIフレームの取り扱いは前項(すなわち、DISCONNECTEDとPENDINGが述べるRESOLVE_)でDLSw州のマシンを離れさせます。 その上、また、特定のMACアドレスに送られたNetBIOSデータグラム(すなわち、ネブラスカ_データグラム)の取り扱いはDLSw州のマシンによって治められます。
Note: Some implementations also issue Test frames during the exchange of the NetBIOS, NB_Name_Query and NB_Name_Recognized. This exchange of protocol data units occurs during the start of a data link and is used to determine the routing information. Most other implementations of NetBIOS will use the NB_Name_Query/NB_Name_Recognized exchange to determine routes in conjunction with resolving the NetBIOS names. These differences are not reflected in the SSP protocols.
以下に注意してください。 また、いくつかの実現がNetBIOS、ネブラスカの_Name_Queryと_ネブラスカName_Recognizedの交換の間、Testにフレームを発行します。 プロトコルデータ単位のこの交換は、データ・リンクの始まりの間、起こって、ルーティング情報を決定するのに使用されます。 NetBIOSの他のほとんどの実現が、NetBIOS名を決議することに関連してルートを決定するのにネブラスカ_Name_Query/ネブラスカ_Name_Recognized交換を使用するでしょう。 これらの違いはSSPプロトコルに反映されません。
Wells & Bartky [Page 39] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[39ページ]RFC1795データ・リンク
The handling of the NetBIOS specific SSP messages is given in the following table.
以下のテーブルでNetBIOSの特定のSSPメッセージの取り扱いを与えます。
+---------------+-------------------------+-------------------------+ | Event | Action(s) | Comment | +---------------+-------------------------+-------------------------+ | NETBIOS_ANQ | DLC_DGRM: | Routed STE | | | NB_Add_Name_Query | (NETBIOS Group Address) | +---------------+-------------------------+-------------------------+ | NETBIOS_ANR | DLC_DGRM: | Routed ARE | | | NB_Add_Name_Response | (Specific MAC Address) | +---------------+-------------------------+-------------------------+ | NETBIOS_NQ_ex | DLC_DGRM: | Routed STE | | | NB_Name_Query | (NETBIOS Group Address) | +---------------+-------------------------+-------------------------+ | NETBIOS_NQ_cs | DLC_DGRM: | Routed STE | | | NB_Name_Query | (NETBIOS Group Address) | +---------------+-------------------------+-------------------------+ | NETBIOS_NR_ex | DLC_DGRM: | Routed ARE | | | NB_Name_Recognized | (Specific MAC Address) | +---------------+-------------------------+-------------------------+ | NETBIOS_NR_cs | DLC_DGRM: | Routed ARE | | | NB_Name_Recognized | (Specific MAC Address) | +---------------+-------------------------+-------------------------+ | DATAFRAME | DLC_DGRM | If NB_Status_Response: | | | | Routed ARE | | | | (Specific MAC Address) | | | | Else: | | | | Routed STE | | | | (NETBIOS Group Address)| +---------------+-------------------------+-------------------------+
+---------------+-------------------------+-------------------------+ | 出来事| 動作| コメント| +---------------+-------------------------+-------------------------+ | NETBIOS_ANQ| DLC_DGRM: | 発送されたSTE| | | ネブラスカ_は_名前_質問を加えます。| (NETBIOSグループアドレス) | +---------------+-------------------------+-------------------------+ | NETBIOS_ANR| DLC_DGRM: | 掘る| | | ネブラスカ_は_名前_応答を加えます。| (特定のマックーアドレス) | +---------------+-------------------------+-------------------------+ | NETBIOS_NQ_元の連れ合い| DLC_DGRM: | 発送されたSTE| | | ネブラスカ_名前_質問| (NETBIOSグループアドレス) | +---------------+-------------------------+-------------------------+ | NETBIOS_NQ_Cs| DLC_DGRM: | 発送されたSTE| | | ネブラスカ_名前_質問| (NETBIOSグループアドレス) | +---------------+-------------------------+-------------------------+ | NETBIOS_NR_元の連れ合い| DLC_DGRM: | 掘る| | | _が認識したネブラスカ_名前| (特定のマックーアドレス) | +---------------+-------------------------+-------------------------+ | NETBIOS_NR_Cs| DLC_DGRM: | 掘る| | | _が認識したネブラスカ_名前| (特定のマックーアドレス) | +---------------+-------------------------+-------------------------+ | DATAFRAME| DLC_DGRM| Nb_状態_応答であるなら: | | | | 掘る| | | | (特定のマックーアドレス) | | | | ほかに: | | | | 発送されたSTE| | | | (NETBIOSグループアドレス)| +---------------+-------------------------+-------------------------+
The above actions apply to all DLSw states. The handling of NetBIOS datagrams sent within DGRMFRAME messages is governed by the DLSw state machine. The DGRMFRAME message type is employed instead of the DATAFRAME message type once the end-to-end circuit has been established. At that time, the message is addressed according to the pair of Circuit IDs in the message header instead of relying upon the MAC address information in the token ring header.
上の動作はすべてのDLSw州に適用されます。 DGRMFRAMEメッセージの中で送られたNetBIOSデータグラムの取り扱いはDLSw州のマシンによって治められます。 終わりから端へのサーキットがいったん確立されると、DGRMFRAMEメッセージタイプはDATAFRAMEメッセージタイプの代わりに雇われます。 その時、Circuit IDの組に従って、メッセージはトークンリングヘッダーでMACアドレス情報を当てにすることの代わりにメッセージヘッダーに記述されます。
5.4 Explorer Traffic
5.4 エクスプローラー交通
The CANUREACH_ex, ICANREACH_ex, NETBIOS_NQ_ex, and NETBIOS_NR_ex SSP messages explore the topology of the DLSw cloud and the networks attached to it. These explorer frames are used to determine the DLSw partners through which a MAC or NetBIOS name can be accessed. This information may optionally be cached to reduce explorer traffic in the DLSw cloud.
CANUREACH_元の連れ合い、ICANREACH_元の連れ合い、NETBIOS_NQ_元の連れ合い、およびNETBIOSの_のNRの_の元のSSPメッセージはDLSw雲とそれに付けられたネットワークのトポロジーを探検します。 これらの探検家フレームは、MACかNetBIOS名にアクセスできるDLSwパートナーを決定するのに使用されます。 この情報は、DLSw雲で探検家交通を抑えるために任意にキャッシュされるかもしれません。
Wells & Bartky [Page 40] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[40ページ]RFC1795データ・リンク
If a DLSw is aware from cached information that a given MAC address or NetBIOS name is accessible through a given partner DLSw, it should direct all circuit setup attempts to that partner. If the circuit setup fails, or no such data is available in the MAC or name cache database, the DLSw may fallback to issuing the setup attempt to all DLSw partners on the assumption that the cached data is now out of date. The mechanism for determining when to use such a fallback is implementation defined.
DLSwが与えられたMACアドレスかNetBIOS名が与えられたパートナーDLSwを通してアクセスしやすいというキャッシュされた情報から意識しているなら、それはすべてのサーキットセットアップ試みをそのパートナーに向けるべきです。 サーキットセットアップが失敗するか、またはそのような何かデータがMACか名前キャッシュデータベースで利用可能でないなら、DLSwはキャッシュされたデータが現在時代遅れであるという前提でのすべてのDLSwパートナーにセットアップ試みを発行することへの後退が利用可能です。 いつそのような後退を使用するかを決定するためのメカニズムは定義された実現です。
DLSw implementations may also use a local MAC cache to enable responses to CANUREACH_ex requests to be issued without the need for TEST frame exchange (or equivalent) until the CANUREACH_cs is received. Again, the fallback mechanism for determining when such local cache data is out-of-date is implementation defined.
また、DLSw実現は、CANUREACHの_の元の要求CANUREACH_Csが受け取られているまで、発行されるのとTESTフレーム交換の必要なしで(同等)であるへの応答を可能にするのにローカルなMACキャッシュを使用するかもしれません。 一方、そのようなローカルのキャッシュデータがいつ時代遅れであるかを決定するための後退メカニズムは定義された実現です。
The use of either cache is an optional function in DLSw. An implementation may choose to always issue explorer frames or to use either or both types of cache.
どちらかのキャッシュの使用はDLSwでの任意の機能です。 実現は、キャッシュがいつも探検家にフレームを発行するか、使用するか、またはともにタイプされるのを選ぶかもしれません。
The following sections describe the FSMs used for explorer frames. The DLC events and actions are a subset of those described in section 5.2 for the main circuit FSM.
以下のセクションは探検家フレームに使用されるFSMsについて説明します。 DLC出来事と動作はセクション5.2で主なサーキットFSMに説明されたものの部分集合です。
5.4.1 CANUREACH/ICANREACH Explorer FSM
5.4.1 CANUREACH/ICANREACHエクスプローラーFSM
The FSM described below is used to handle explorer frames routed by MAC address. There is one instance of this FSM for each Data Link ID (Target and Origin MAC/SAP pair) for which explorer traffic is flowing. The states in this FSM are as follows.
以下で説明されたFSMは、MACアドレスによって発送された探検家フレームを扱うのに使用されます。 探検家交通が流れているそれぞれのData Link ID(目標とOrigin MAC/SAP組)へのこのFSMの1つの例があります。 このFSMの州は以下の通りです。
State Name Description ---------- ----------- RESET The initial state.
州の名前記述---------- ----------- 初期のRESETは述べます。
SENT_EX Local DLSw has issued an explorer message
SENT_EX Local DLSwは探検家メッセージを発行しました。
RECEIVED_EX Local DLSw has received an explorer message
RECEIVED_EX Local DLSwは探検家メッセージを受け取りました。
Wells & Bartky [Page 41] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[41ページ]RFC1795データ・リンク
5.4.1.1 RESET State
5.4.1.1 リセット状態
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive CANUREACH_ex | If replying from | If DLC_RESOLVE sent, | | | cache, send | RECEIVED_EX | | | ICANREACH_ex | | | | else if allowed to | | | | test availability, | | | | issue DLC_RESOLVE. | | | | Optionally update | | | | cache. | | +----------------------+---------------------+----------------------+ | Receive ICANREACH_ex | Optionally update | RESET | | | cache | | +----------------------+---------------------+----------------------+ | DLC_RESOLVE_C | Send CANUREACH_ex | SENT_EX | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | CANUREACH_元の連れ合いを受けてください。| 返信します。| DLC_RESOLVEが発信したなら| | | キャッシュ、発信してください。| 容認された_元の連れ合い| | | ICANREACH_元の連れ合い| | | | ほかにもかかわらず、許容にされる| | | | 有用性をテストしてください。| | | | DLC_RESOLVEを発行してください。 | | | | 任意に、アップデートします。| | | | キャッシュします。 | | +----------------------+---------------------+----------------------+ | ICANREACH_元の連れ合いを受けてください。| 任意に、アップデートします。| リセット| | | キャッシュ| | +----------------------+---------------------+----------------------+ | DLC_決心_C| CANUREACH_元の連れ合いを送ってください。| _元の連れ合いに送ります。| +----------------------+---------------------+----------------------+
RESET is the initial state for the CANUREACH/ICANREACH explorer FSM. This state is exited when a DLC_RESOLVE_C request is received from the DLC or a CANUREACH_ex is received from a remote DLSw.
RESETはCANUREACH/ICANREACH探検家FSMのための初期状態です。 DLCからDLC_RESOLVE_C要求を受け取るか、またはリモートDLSwからCANUREACH_元の連れ合いを受け取るとき、この状態を出ます。
A DLSw implementation may optionally reply from to CANUREACH_ex messages on the basis of cached topology information, in which case the DLC_RESOLVE exchange (i.e., TEST) is not required. If cache is not used, or no match is found, and the DLC permits the use of TEST, DLC_RESOLVE is issued to locate the target MAC and the state changes to RECEIVED_EX. If no cache entry is available and TEST is not allowed by the DLC, a received CANUREACH_ex frame is ignored.
キャッシュされたトポロジー情報、コネに基づいたCANUREACHの_の元のメッセージへのDLC_RESOLVEが交換するどのケース(すなわち、TEST)は必要でないかからDLSw実現が任意に返答するかもしれません。 キャッシュが使用されていないか、マッチが全く見つけられないで、またはDLCがTESTの使用を可能にするなら、DLC_RESOLVEは、RECEIVED_EXへの目標MACと州の変化の場所を見つけるように発行されます。 どんなキャッシュエントリーも利用可能でなく、またTESTがDLCによって許容されていないなら、容認されたCANUREACH_元のフレームは無視されます。
5.4.1.2 SENT_EX State
5.4.1.2 送られた_元の状態
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive ICANREACH_ex | DLC_RESOLVE_R | RESET | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+ | DLC_RESOLVE_C | | SENT_EX | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | ICANREACH_元の連れ合いを受けてください。| DLC_決心_R| リセット| | | 任意に、アップデートします。| | | | キャッシュ| | +----------------------+---------------------+----------------------+ | DLC_決心_C| | _元の連れ合いに送ります。| +----------------------+---------------------+----------------------+
SENT_EX is entered when the DLSw has issued a CANUREACH_ex message to locate a MAC address. This state is exited when a remote DLSw returns a matching ICANREACH_ex, or after an implementation defined timeout. DLC_RESOLVE events received in this state correspond to TEST
DLSwがMACアドレスの場所を見つけるCANUREACHの_の元のメッセージを発行したとき、SENT_EXは入られます。 この状態はリモートDLSwが合っているICANREACH_元の連れ合いを返すときに時か実現の定義されたタイムアウトの後に出られます。 この状態に受け取られたDLC_RESOLVE出来事はTESTに対応しています。
Wells & Bartky [Page 42] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[42ページ]RFC1795データ・リンク
retries by the origin DLC station and are absorbed.
起源DLCステーションのそばで再試行して、吸収します。
An implementation may choose whether to handle explorer frame crossover either by using entirely separate FSM instances and simply allowing both ends to issue TEST frames, or by detecting a reverse CANUREACH_ex frame here and issuing an ICANREACH_ex message and DLC_RESOLVE_R action.
実現は、完全に別々のFSM例を使用して、両端がTESTにフレームを発行するのを単に許容するか、ここに逆のCANUREACH_元のフレームを検出して、またはICANREACHの_の元のメッセージとDLC_RESOLVE_R動きを発行することによって探検家フレーム横断歩道を扱うかどうかを選ぶかもしれません。
5.4.1.3 RECEIVED_EX State
5.4.1.3 容認された_元の状態
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive CANUREACH_ex | Optionally update | RECEIVED_EX | | | cache | | +----------------------+---------------------+----------------------+ | Receive ICANREACH_ex | | RECEIVED_EX | +----------------------+---------------------+----------------------+ | DLC_RESOLVED | Send ICANREACH_ex | RESET | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | CANUREACH_元の連れ合いを受けてください。| 任意に、アップデートします。| 容認された_元の連れ合い| | | キャッシュ| | +----------------------+---------------------+----------------------+ | ICANREACH_元の連れ合いを受けてください。| | 容認された_元の連れ合い| +----------------------+---------------------+----------------------+ | 決議されたDLC_| ICANREACH_元の連れ合いを送ってください。| リセット| | | 任意に、アップデートします。| | | | キャッシュ| | +----------------------+---------------------+----------------------+
RECEIVED_EX is entered when the DLSw has received a CANUREACH_ex from a remote DLSw and has issued a DLC_RESOLVE to locate the MAC address. This state is exited when the DLC_RESOLVED response is received, or after an implementation defined timeout.
DLSwがリモートDLSwからCANUREACH_元の連れ合いを受けて、MACアドレスの場所を見つけるようにDLC_RESOLVEを発行したとき、RECEIVED_EXは入られます。 この状態はDLC_RESOLVED応答が受け取られている時か実現の定義されたタイムアウトの後に出られます。
If the target MAC is located, the DLSw must reply to the first received CANUREACH_ex that caused the move to this state. If additional CANUREACH_ex messages are received in this state from other remote DLSw partners, the DLSw may optionally reply to these messages too but it is not required to do so.
目標MACが見つけられているなら、DLSwはこの状態に移動を引き起こした最初の容認されたCANUREACH_元の連れ合いに答えなければなりません。 この状態に他のリモートDLSwパートナーから追加CANUREACH_元のメッセージを受け取るなら、DLSwは任意にこれらのメッセージにも答えるかもしれませんが、それは、そうするのに必要ではありません。
An implementation may choose whether to handle explorer frame crossover either by using entirely separate FSM instances and simply allowing both ends to issue TEST frames, or by detecting such a reverse DLC_RESOLVE_C event here and issuing an ICANREACH_ex message and DLC_RESOLVE_R action.
実現は、完全に別々のFSM例を使用して、両端がTESTにフレームを発行するのを単に許容するか、ここにそのような逆のDLC_RESOLVE_Cイベントを検出して、またはICANREACHの_の元のメッセージとDLC_RESOLVE_R動きを発行することによって探検家フレーム横断歩道を扱うかどうかを選ぶかもしれません。
Wells & Bartky [Page 43] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[43ページ]RFC1795データ・リンク
5.4.2 NETBIOS_NQ/NR Explorer FSM
5.4.2 NETBIOS_NQ/NRエクスプローラーFSM
The FSM described below is used to handle explorer frames routed by NetBIOS names There is one instance of this FSM for each unique combination of Source Name, Destination Name, Data 2 field and Response Correlator.
以下で説明されたFSMによるNetBIOS名によって発送された探検家フレームを扱うのに使用されて、ThereはSource Nameのそれぞれのユニークな組み合わせのためのこのFSMの1つの例です、Destination Nameということであり、Data2は分野とResponse Correlatorです。
State Name Description ---------- ----------- RESET The initial state.
州の名前記述---------- ----------- 初期のRESETは述べます。
SENT_EX Local DLSw has issued an explorer
message
SENT_EX Local DLSwは探検家メッセージを発行しました。
RECEIVED_EX Local DLSw has received an explorer
message
RECEIVED_EX Local DLSwは探検家メッセージを受け取りました。
SENT_REC_EX An explorer frame has been both sent
and received for the same (potential)
NetBIOS circuit.
SENT_REC_EX An探検家フレームを同じ(潜在的)のNetBIOSサーキットに送って、受け取りました。
5.4.2.1 RESET State
5.4.2.1 リセット状態
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| RECEIVED_EX | | | Optionally update | | | | cache. | | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NR_ex| Optionally update | RESET | | | cache | | +----------------------+---------------------+----------------------+ | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex | SENT_EX | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | NETBIOS_NQ_元の連れ合いを受けてください。| DLC_DGRM(名前_質問)| 容認された_元の連れ合い| | | 任意に、アップデートします。| | | | キャッシュします。 | | +----------------------+---------------------+----------------------+ | NETBIOS_NR_元の連れ合いを受けてください。| 任意に、アップデートします。| リセット| | | キャッシュ| | +----------------------+---------------------+----------------------+ | DLC_DGRM(名前_質問)| NETBIOS_NQ_元の連れ合いを送ってください。| _元の連れ合いに送ります。| +----------------------+---------------------+----------------------+
The RESET state is the initial state for the NETBIOS_NQ/NR explorer FSM. It is exited when the DLC receives either a NETBIOS_NQ_ex or a DLC_DGRM containing a NetBIOS NAME_QUERY frame. If a NETBIOS_NQ_ex message is received, the NAME_QUERY is propagated to the DLC and this FSM moves to state RECEIVED_EX. If a NetBIOS NAME_QUERY frame is received, the NETBIOS_NQ_ex is propagated either to the appropriate DLSw partners (see below), and this FSM moves to state SENT_EX.
RESET状態はNETBIOS_NQ/NR探検家FSMのための初期状態です。 DLCがNetBIOS NAME_QUERYフレームを含むNETBIOS_NQ_元の連れ合いかDLC_DGRMのどちらかを受けるとき、それは出られます。 NETBIOS_NQの_の元のメッセージが受信されているなら、NAME_QUERYはDLCに伝播されます、そして、このFSMはRECEIVED_EXを述べるために動きます。 NetBIOS NAME_QUERYフレームが受け取られているなら、NETBIOS_NQ_元の連れ合いは適切なDLSwパートナーに伝播されます、そして、(以下を見てください)このFSMはSENT_EXを述べるために動きます。
Unlike SNA traffic where the CANUREACH_ex/ICANREACH_ex exchange can be omitted if the MAC location is already cached, NETBIOS_NQ_ex/NETBIOS_NR_ex frames must always be issued during NetBIOS session setup in order that the NetBIOS session numbers are
MAC位置が既にキャッシュされるならCANUREACH_元の連れ合い/ICANREACHの_の元の交換を省略できるSNA交通と異なって、NetBIOSセッション番号があるようにNetBIOSセッションセットアップの間、いつもNETBIOS_NQの元の連れ合い/NETBIOSの_のNRの_の元の_フレームを発行しなければなりません。
Wells & Bartky [Page 44] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[44ページ]RFC1795データ・リンク
exchanged correctly between the DLC end stations. If the location of a NetBIOS name is known from cached data, the NETBIOS_NQ_ex need only be issued to the cached DLSw partners. Otherwise the NETBIOS_NQ_ex should be issued to all partners that support NetBIOS.
正しく、DLC端のステーションの間で交換します。 NetBIOS名の位置がキャッシュされたデータから知られているなら、NETBIOS_NQ_元の連れ合いはキャッシュされたDLSwパートナーに発行されるだけでよいです。 さもなければ、NETBIOS_NQ_元の連れ合いはNetBIOSを支持するすべてのパートナーに発行されるべきです。
5.4.2.2 SENT_EX State
5.4.2.2 送られた_元の状態
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| SENT_REC_EX | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NR_ex| DLC_DGRM(NAME_RECOG)| RESET | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+ | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex | SENT_EX | | (different local | Optionally update | | | session number than | cache | | | existing searches) | | | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | NETBIOS_NQ_元の連れ合いを受けてください。| DLC_DGRM(名前_質問)| _REC_元の連れ合いに送ります。| | | 任意に、アップデートします。| | | | キャッシュ| | +----------------------+---------------------+----------------------+ | NETBIOS_NR_元の連れ合いを受けてください。| DLC_DGRM(名前_RECOG)| リセット| | | 任意に、アップデートします。| | | | キャッシュ| | +----------------------+---------------------+----------------------+ | DLC_DGRM(名前_質問)| NETBIOS_NQ_元の連れ合いを送ってください。| _元の連れ合いに送ります。| | (異なったローカル| | キャッシュより任意に| | | セッション番号をアップデートしてください| | | 既存の検索) | | | +----------------------+---------------------+----------------------+
SENT_EX is entered when the local DLSw issues a NETBIOS_NQ_ex to its remote DLSw partners. This state is exited when a NETBIOS_NR_ex is received from a remote DLSw, or if a matching NETBIOS_NQ_ex is received from a remote DLSw (i.e., a NETBIOS_NQ_ex crossover case). If the local NetBIOS end station issues a NAME_QUERY with a different session number from any previous NAME_QUERY for this search, the NAME_QUERY is propagated to the DLSw partners to ensure that the exchange of NetBIOS session numbers is handled correctly.
地方のDLSwがNETBIOS_NQ_元の連れ合いをリモートDLSwパートナーに発行するとき、SENT_EXは入られます。 リモートDLSwからNETBIOS_NR_元の連れ合いを受け取るとき、この状態を出て、リモートDLSw(すなわち、NETBIOS_NQの_の元の横断歩道ケース)から合っているNETBIOS_NQ_元の連れ合いを受け取るかどうかはそうします。 地方のNetBIOS端のステーションがこの検索のためにどんな前のNAME_QUERYとも異なったセッション番号でNAME_QUERYを発行するなら、NAME_QUERYは、NetBIOSセッション番号の交換が正しく扱われるのを保証するためにDLSwパートナーに伝播されます。
Wells & Bartky [Page 45] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[45ページ]RFC1795データ・リンク
5.4.2.3 RECEIVED_EX State
5.4.2.3 容認された_元の状態
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| RECEIVED_EX | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NR_ex| | RECEIVED_EX | +----------------------+---------------------+----------------------+ | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex | SENT_REC_EX | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+ | DLC_DGRM (NAME_RECOG)| Send NETBIOS_NR_ex | RESET | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | NETBIOS_NQ_元の連れ合いを受けてください。| DLC_DGRM(名前_質問)| 容認された_元の連れ合い| | | 任意に、アップデートします。| | | | キャッシュ| | +----------------------+---------------------+----------------------+ | NETBIOS_NR_元の連れ合いを受けてください。| | 容認された_元の連れ合い| +----------------------+---------------------+----------------------+ | DLC_DGRM(名前_質問)| NETBIOS_NQ_元の連れ合いを送ってください。| _REC_元の連れ合いに送ります。| | | 任意に、アップデートします。| | | | キャッシュ| | +----------------------+---------------------+----------------------+ | DLC_DGRM(名前_RECOG)| NETBIOS_NR_元の連れ合いを送ってください。| リセット| | | 任意に、アップデートします。| | | | キャッシュ| | +----------------------+---------------------+----------------------+
RECEIVED_EX is entered when the local DLSw receives a NETBIOS_NQ_ex message from a remote DLSw. This state is exited when a NAME_RECOGNIZED NetBIOS frame is received from the DLC, completing the query, or when a matching NAME_QUERY is received from DLC (i.e., NAME_QUERY crossover).
地方のDLSwがリモートDLSwからNETBIOS_NQの_の元のメッセージを受け取るとき、RECEIVED_EXは入られます。 DLCからNAME_RECOGNIZED NetBIOSフレームを受け取るとき、この状態を出ます、質問を終了していつDLC(すなわち、NAME_QUERY横断歩道)から合っているNAME_QUERYを受け取るかをそうされます。
5.4.2.4 SENT_REC_EX State
5.4.2.4 送られた_REC_元の状態
+----------------------+---------------------+----------------------+ | Event | Action(s) | Next State | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NQ_ex| DLC_DGRM(NAME_QUERY)| SENT_REC_EX | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+ | Receive NETBIOS_NR_ex| DLC_DGRM(NAME_RECOG)| RECEIVED_EX | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+ | DLC_DGRM (NAME_QUERY)| Send NETBIOS_NQ_ex | SENT_REC_EX | | (different local | Optionally update | | | session number than | cache | | | existing searches) | | | +----------------------+---------------------+----------------------+ | DLC_DGRM (NAME_RECOG)| Send NETBIOS_NR_ex | SENT_EX | | | Optionally update | | | | cache | | +----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+ | 出来事| 動作| 次の状態| +----------------------+---------------------+----------------------+ | NETBIOS_NQ_元の連れ合いを受けてください。| DLC_DGRM(名前_質問)| _REC_元の連れ合いに送ります。| | | 任意に、アップデートします。| | | | キャッシュ| | +----------------------+---------------------+----------------------+ | NETBIOS_NR_元の連れ合いを受けてください。| DLC_DGRM(名前_RECOG)| 容認された_元の連れ合い| | | 任意に、アップデートします。| | | | キャッシュ| | +----------------------+---------------------+----------------------+ | DLC_DGRM(名前_質問)| NETBIOS_NQ_元の連れ合いを送ってください。| _REC_元の連れ合いに送ります。| | (異なったローカル| | キャッシュより任意に| | | セッション番号をアップデートしてください| | | 既存の検索) | | | +----------------------+---------------------+----------------------+ | DLC_DGRM(名前_RECOG)| NETBIOS_NR_元の連れ合いを送ってください。| _元の連れ合いに送ります。| | | 任意に、アップデートします。| | | | キャッシュ| | +----------------------+---------------------+----------------------+
Wells & Bartky [Page 46] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[46ページ]RFC1795データ・リンク
This state is required if an implementation wishes to manage NQ/NR crossover cases from a single FSM instance by detecting 'opposite' NAME_QUERY attempts between the same two NetBIOS names. If separate FSM instances are used instead, this state is not required and the transitions to it from other states can be removed.
実現がNAME'反対側'にQUERYが同じ2つのNetBIOS名の間で試みる_を検出することによってただ一つのFSM例からのNQ/NR横断歩道ケースを管理したいなら、この状態が必要です。 代わりに別々のFSM例を使用するなら、この状態を必要としません、そして、他の州からのそれへの変遷を取り除くことができます。
SENT_RCV_EX is exited when the NAME_QUERY search in either direction is resolved. If the local NetBIOS end station issues a NAME_QUERY with a different session number from any previous NAME_QUERY it has issued for this search, the NAME_QUERY is propagated to the DLSw partners to ensure that the exchange of NetBIOS session numbers is correctly handled.
どちらかの方向へのNAME_QUERY検索が決議されているとき、SENT_RCV_EXは出られます。 地方のNetBIOS端のステーションがそれがこの検索のために発行したどんな前のNAME_QUERYとも異なったセッション番号でNAME_QUERYを発行するなら、NAME_QUERYは、NetBIOSセッション番号の交換が正しく扱われるのを保証するためにDLSwパートナーに伝播されます。
5.4.2.5 NetBIOS Session Numbers
5.4.2.5 NetBIOSセッション番号
NetBIOS NAME_QUERY and NAME_RECOGNIZED frames exchange NetBIOS session numbers between the end stations. For correct NetBIOS operation over DLSw, it is important that all SSP NETBIOS_NQ_ex frames received by a DLSw cause NetBIOS NAME_QUERY frames to flow on the LAN with the new session number from the NETBIOS_NQ_ex. These frames cannot be replied to from a cache of locally available NetBIOS names in the same way that MAC addresses and CANUREACH_ex messages can be handled.
NetBIOS NAME_QUERYとNAME_RECOGNIZEDフレームは端のステーションの間のNetBIOSセッション番号を交換します。 DLSwの上の正しいNetBIOS操作に、NetBIOS NAME_QUERYフレームがLANをDLSwによって受け取られたすべてのSSP NETBIOS_NQの_の元のフレームで新しいセッション番号でNETBIOS_NQ_から流れるのが、重要である、例えば。 局所的に利用可能なNetBIOS名のキャッシュからこれらのフレームについてMACが記述するのと同じように答えることができません、そして、CANUREACHの_の元のメッセージを扱うことができます。
Also, NAME_QUERY messages are normally retried several times on the LAN. The generation and absorption of such frames is outside the scope of the FSM defined above.
また、通常、NAME_QUERYメッセージはLANで何度か再試行されます。 上で定義されたFSMの範囲の外にそのようなフレームの世代と吸収があります。
6. Protocol Flow Diagrams
6. プロトコルフローチャート
The Switch-to-Switch Protocol is used to setup and take down circuits between a pair of Data Link Switches. Once a circuit is established, the end stations on the local networks can employ LLC Type 1 (connectionless UI frames) protocols end-to-end. In addition, the end systems can establish an end-to-end connection for support of LLC Type 2 (connection oriented I frames) protocols (Type 2 I frames go end-to-end, supervisory frames are handled locally).
Switchからスイッチへのプロトコルは、1組のData Link Switchesの間のサーキットをセットアップして、降ろすのに使用されます。 サーキットがいったん確立されると、企業内情報通信網の端のステーションはLLC Type1(コネクションレスなUIフレーム)のプロトコルの終わりからエンドを使うことができます。 さらに、エンドシステムはLLC Type2(指向の私が罪に陥れる接続)プロトコルのサポートのための終わりから終わりとの接続を確立できます(私が罪に陥れる2タイプは終わるために終わるのに行って、管理のフレームは局所的に扱われます)。
The term, Data Link, is used in this document to refer to both a "logical data link" when supporting Type 1 LLC services, and a "data link connection" when supporting Type 2 LLC services. In both cases, the Data Link is identified by the Data Link ID defined in section 3.2.
2つのLLCが修理する1、およびTypeを支持するときの「データリンク接続」のType LLCサービスを支持するとき、用語(Data Link)は、両方への「論理的なデータ・リンク」を参照するのに本書では使用されます。 どちらの場合も、Data Linkはセクション3.2で定義されたData Link IDによって特定されます。
NOTE: THIS SECTION CONTAINS EXAMPLES ONLY. IT CANNOT AND DOES NOT SHOW ALL POSSIBLE VARIATIONS AND OPTIONS ON PROTOCOL FLOWS FOR SNA/SDLC, SSP, AND LLC PROTOCOLS.
以下に注意してください。 このセクションは例だけを含みます。 それは、示さないで、またSNA/SDLC、SSP、およびLLCプロトコルのためにプロトコル流れにすべての可能な変化とオプションを示しません。
Wells & Bartky [Page 47] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[47ページ]RFC1795データ・リンク
6.1 Connect Protocols
6.1はプロトコルを接続します。
The two basic startup flows from a pure FSM perspective are shown below. The first flow is a startup involving XIDs and the second is one without XIDs.
純粋なFSM見解からの2回の基本的な始動流れが以下に示されます。 最初の流れはXIDsにかかわる始動です、そして、2番目はXIDsのないものです。
Flow #1 - DLSw Startup With XIDs ====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | < Network > | | | ====== /______\ --------- \__ __/ --------- /______\ Origin Origin DLSw \___/ Target DLSw Target Station partner partner Station
流れ#1--XIDsとのDLSw始動====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | <ネットワーク>。| | | ====== /______\ --------- \__ __/ --------- /______\起源起源DLSw\___/目標DLSw Target駅パートナーパートナー駅
disconnected disconnected
外された状態で、連絡を断ちます。
DLC_RESOLVE_C CANUREACH_ex
-----------> ----------->
DLC_RESOLVE_R ICANREACH_ex
<----------- <-----------
DLC_決心_C CANUREACH_元の連れ合い----------->。-----------_>DLC_決心のR_の元のICANREACH<。----------- <、-、-、-、-、-、-、-、-、-、--
DLC_XID CANUREACH_cs DLC_START_DL
-----------> -----------> ----------->
circuit_start resolve_pending
DLC_XID CANUREACH_Cs DLC_スタート_dl----------->。----------->。-----------未定の>サーキット_スタート決心_
ICANREACH_cs DLC_DL_STARTED
<----------- <-----------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
ICANREACH_Cs DLC_dl_は<を始動しました。----------- <、-、-、-、-、-、-、-、-、-、-- サーキット_は_サーキットの未定のREACH_ACKを設立しました。-----------_が確立した>サーキット
XIDFRAME DLC_XID
-----------> ----------->
XIDFRAME DLC_XID----------->。----------->。
DLC_XID XIDFRAME DLC_XID
<----------- <----------- <-----------
DLC_XID XIDFRAME DLC_XID
-----------> -----------> ----------->
DLC_XID XIDFRAME DLC_XID<。----------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- DLC_XID XIDFRAME DLC_XID----------->。----------->。----------->。
DLC_XIDs XIDFRAMEs DLC_XIDs
<------------> <------------> <------------>
DLC_XIDs XIDFRAMEs DLC_XIDs<。------------><。------------><。------------>。
DLC_CONTACTED CONTACT DLC_CONTACT
-----------> -----------> ----------->
connect_pending contact_pending
DLC_は接触DLC_接触に連絡しました。----------->。----------->。----------->は_未定の未定の接触_を接続します。
Wells & Bartky [Page 48] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[48ページ]RFC1795データ・リンク
DLC_CONTACT CONTACTED DLC_CONTACTED
<----------- <----------- <-----------
connected connected
DLC_接触の連絡されたDLC_は<に連絡しました。----------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- 接続されていた状態で、接続されます。
DLC_INFOs IFRAMEs DLC_INFOs
<------------> <------------> <------------>
DLC_インフォメーションIFRAMEs DLC_インフォメーション<。------------><。------------><。------------>。
Mapping LAN events to the DLC events and actions on Flow #1 produces the following flows shown below:
DLC出来事へのLAN出来事とFlow#1への動作を写像すると、以下に示された以下の流れは発生します:
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | < Network > | | | ====== /______\ --------- \__ __/ --------- /______\ Origin Origin DLSw \___/ Target DLSw Target Station partner partner Station
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | <ネットワーク>。| | | ====== /______\ --------- \__ __/ --------- /______\起源起源DLSw\___/目標DLSw Target駅パートナーパートナー駅
disconnected disconnected
外された状態で、連絡を断ちます。
TEST_cmd DLC_RESOLVE_C CANUREACH_ex TEST_cmd
-----------> -----------> -----------> ---------->
TEST_rsp DLC_RESOLVE_R ICANREACH_ex TEST_rsp
<--------- <----------- <----------- <-----------
null XID DLC_XID CANUREACH_cs DLC_START_DL
-----------> -----------> -----------> ----------->
circuit_start resolve_pending
_テスト_cmd DLCの_の決心_CのCANUREACHの_の元のテストcmd----------->。----------->。----------->。----------_>の_の決心_R ICANREACHの_の元のテスト_rsp DLCテストrsp<。--------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- ヌルXID DLC_XID CANUREACH_Cs DLC_START_DL----------->。----------->。----------->。-----------未定の>サーキット_スタート決心_
ICANREACH_cs DLC_DL_STARTED
<----------- <-------------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
ICANREACH_Cs DLC_dl_は<を始動しました。----------- <、-、-、-、-、-、-、-、-、-、-、-、-- サーキット_は_サーキットの未定のREACH_ACKを設立しました。-----------_が確立した>サーキット
XIDFRAME DLC_XID null XID
-----------> ---------> -------->
XID DLC_XID XIDFRAME DLC_XID XID
<-------- <----------- <----------- <----------- <--------
XIDs DLC_XIDs XIDFRAMEs DLC_XIDs XIDs
<----------> <----------> <------------> <------------> <--------->
SABME DLC_CONTACTED CONTACT DLC_CONTACT SABME
-----------> -----------> -----------> -----------> -------->
connect_pending contact_pending
XIDFRAME DLC_XIDのヌルXID----------->。--------->。-------->XID DLC_XID XIDFRAME DLC_XID XID<。-------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-- XIDs DLC_XIDs XIDFRAMEs DLC_XIDs XIDs<。----------><。----------><。------------><。------------><。--------->SABME DLC_は接触DLC_接触SABMEに連絡しました。----------->。----------->。----------->。----------->。-------->は_未定の未定の接触_を接続します。
UA DLC_CONTACT CONTACTED DLC_CONTACTED UA
<--------- <----------- <----------- <----------- <--------
connected connected
UaのDLC_接触の連絡されたDLC_はUa<に連絡しました。--------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-- 接続されていた状態で、接続されます。
Wells & Bartky [Page 49] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[49ページ]RFC1795データ・リンク
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs <----------> <-----------> <------------> <------------> <-------->
IFRAMEs DLC_インフォメーションIFRAMEs DLC_インフォメーションIFRAMEs<。----------><。-----------><。------------><。------------><。-------->。
Those implementations that prefer to respond to the SABME immediately could use the same events to do that:
すぐにSABMEに応じるのを好むそれらの実現はそれをするのに同じ出来事を使用するかもしれません:
SABME DLC_CONTACTED CONTACT DLC_CONTACT SABME
-----------> -----------> -----------> -----------> -------->
UA connect_pending contact_pending
<---------
RR
----------->
RNR
<---------
SABME DLC_は接触DLC_接触SABMEに連絡しました。----------->。----------->。----------->。----------->。-------->UAは__未定の接触の未定の<を接続します。--------- RR----------->RNR<。---------
RR DLC_CONTACT CONTACTED DLC_CONTACTED UA
<--------- <----------- <----------- <----------- <--------
connected connected
RR DLC_接触の連絡されたDLC_はUa<に連絡しました。--------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-- 接続されていた状態で、接続されます。
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs <----------> <------------> <------------> <------------> <-------->
IFRAMEs DLC_インフォメーションIFRAMEs DLC_インフォメーションIFRAMEs<。----------><。------------><。------------><。------------><。-------->。
Flow #2 - DLSw Startup Without XIDs (circuit setup)
流れ#2--XIDsのないDLSw始動(サーキットセットアップ)
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | < Network > | | | ====== /______\ --------- \__ __/ --------- /______\ Origin Origin DLSw \___/ Target DLSw Target Station partner partner Station
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | <ネットワーク>。| | | ====== /______\ --------- \__ __/ --------- /______\起源起源DLSw\___/目標DLSw Target駅パートナーパートナー駅
disconnected disconnected
外された状態で、連絡を断ちます。
DLC_CONTACTED CANUREACH_cs DLC_START_DL
-----------> -----------> ----------->
circuit_start resolve_pending
DLC_はCANUREACH_Cs DLC_スタート_dlに連絡しました。----------->。----------->。-----------未定の>サーキット_スタート決心_
ICANREACH_cs DLC_DL_STARTED
<----------- <-----------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
ICANREACH_Cs DLC_dl_は<を始動しました。----------- <、-、-、-、-、-、-、-、-、-、-- サーキット_は_サーキットの未定のREACH_ACKを設立しました。-----------_が確立した>サーキット
CONTACT DLC_CONTACT
-----------> ----------->
connect_pending contact_pending
接触DLC_接触----------->。----------->は_未定の未定の接触_を接続します。
Wells & Bartky [Page 50] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[50ページ]RFC1795データ・リンク
DLC_CONTACT CONTACTED DLC_CONTACTED
<----------- <----------- <-----------
connected connected
DLC_接触の連絡されたDLC_は<に連絡しました。----------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- 接続されていた状態で、接続されます。
DLC_INFOs IFRAMEs DLC_INFOs
<------------> <------------> <------------>
DLC_インフォメーションIFRAMEs DLC_インフォメーション<。------------><。------------><。------------>。
Mapping LAN events to the DLC events and actions on Flow #2 (and adding a NETBIOS_NQ and NETBIOS_NR_ex) produces:
DLC出来事へのLAN出来事とFlow#2への動作(NETBIOS_NQとNETBIOS_NR_元の連れ合いを加えて)を写像するのは生産されます:
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | < Network > | | | ====== /______\ --------- \__ __/ --------- /______\ Origin Origin DLSw \___/ Target DLSw Target Station partner partner Station
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | <ネットワーク>。| | | ====== /______\ --------- \__ __/ --------- /______\起源起源DLSw\___/目標DLSw Target駅パートナーパートナー駅
disconnected disconnected
外された状態で、連絡を断ちます。
NAME_QUERY DLC_DGRM NETBIOS_NQ_ex DLC_DGRM NAME_QUERY -----------> -----------> -----------> -----------> --------->
名前_質問DLC_DGRM NETBIOS_NQ_元の連れ合いDLC_DGRM名前_質問----------->。----------->。----------->。----------->。--------->。
NAME_RECOG DLC_DGRM NETBIOS_NR_ex DLC_DGRM NAME_RECOG <----------- <------------ <----------- <----------- <---------
_名前_RECOG DLCの_のDGRM NETBIOS_NRの_の元のDLC_DGRM名のRECOG<。----------- <、-、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、--
SABME DLC_CONTACTED CANUREACH_cs DLC_START_DL
-----------> -----------> -----------> ----------->
circuit_start resolve_pending
SABME DLC_はCANUREACH_Cs DLC_スタート_dlに連絡しました。----------->。----------->。----------->。-----------未定の>サーキット_スタート決心_
ICANREACH_cs DLC_DL_STARTED
<----------- <-----------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
ICANREACH_Cs DLC_dl_は<を始動しました。----------- <、-、-、-、-、-、-、-、-、-、-- サーキット_は_サーキットの未定のREACH_ACKを設立しました。-----------_が確立した>サーキット
CONTACT DLC_CONTACT SABME
-----------> -----------> --------->
connect_pending contact_pending
接触DLC_接触SABME----------->。----------->。--------->は_未定の未定の接触_を接続します。
UA DLC_CONTACT CONTACTED DLC_CONTACTED UA
<--------- <----------- <----------- <----------- <---------
connected connected
UaのDLC_接触の連絡されたDLC_はUa<に連絡しました。--------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-- 接続されていた状態で、接続されます。
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs <------------> <------------> <------------> <------------> <-------->
IFRAMEs DLC_インフォメーションIFRAMEs DLC_インフォメーションIFRAMEs<。------------><。------------><。------------><。------------><。-------->。
Wells & Bartky [Page 51] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[51ページ]RFC1795データ・リンク
In keeping with a paradigm of 'DLSw is a big 802.2 LAN', all other DLC types (SDLC for now, QLLC, channel, or whatever in the future) would be handled by a 'DLC transformation layer' that would transform the specific protocol's events into the appropriate DLSw DLC events and DLSw DLC actions into the appropriate protocol actions. The XIDs that flow in the SSP XIDFRAME should stay 802.2ish (i.e., ABM bit set) and leave it up to the DLC transformation layer to suit the XID to its particular DLC type.
'DLSwは大きい802.2LANです'のパラダイムで保つ際に、他のすべてのDLCタイプ(当分間のSDLC、QLLC、チャンネル、または未来の何でも)が特定のプロトコルの出来事を適切なプロトコル動きへの適切なDLSw DLC出来事とDLSw DLC動きに変える'DLC変化層'によって扱われるでしょう。 SSP XIDFRAMEを流れるXIDsは、802.2ish(すなわち、ABMビットはセットした)に滞在していて、特定のDLCタイプにXIDを合わせるようにDLC変化層にそれを任せるはずです。
Here is an example of a leased SDLC PU 2.0 device as the origin station. It should use Flow #2 since it is not known if the other side is a LAN, a switched line or a leased line.
ここに、賃貸されたSDLC PU2.0装置に関する例が起源ステーションとしてあります。 それは、反対側がLAN、交換回線または専用線であるなら知られていないので、Flow#2を使用するべきです。
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | < Network > | | | ====== /______\ --------- \__ __/ --------- /______\ Origin Origin DLSw \___/ Target DLSw Target Station partner partner Station
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | <ネットワーク>。| | | ====== /______\ --------- \__ __/ --------- /______\起源起源DLSw\___/目標DLSw Target駅パートナーパートナー駅
disconnected disconnected
外された状態で、連絡を断ちます。
implementer's DLC_RESOLVE_C CANUREACH_ex choice (power -----------> -----------> up, configuration change, DLC_RESOLVE_R ICANREACH_ex never, <----------- <----------- connect timer,etc.)
implementerのDLC_RESOLVEの_のCのCANUREACHの_の元の選択(power -----------> -----------> up, configuration change, DLC_RESOLVE_R ICANREACH_ex never, <----------- <----------- connect timer,etc.)
PU 2.0 is
configured
in DLSw to DLC_XID(null) CANUREACH_cs DLC_START_DL
call in -----------> -----------> ----------->
circuit_start resolve_pending
PU2.0はSTART_DLが回収するDLC_XIDにDLSwで構成された(ヌル)CANUREACH_Cs DLC_です。----------->。----------->。-----------未定の>サーキット_スタート決心_
ICANREACH_cs DLC_DL_STARTED
<----------- <-----------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
ICANREACH_Cs DLC_dl_は<を始動しました。----------- <、-、-、-、-、-、-、-、-、-、-- サーキット_は_サーキットの未定のREACH_ACKを設立しました。-----------_が確立した>サーキット
XIDFRAME DLC_XID
-----------> ----------->
XIDFRAME DLC_XID----------->。----------->。
DLC_XID XIDFRAME DLC_XID
respond with <----------- <----------- <-----------
XID configured
DLC_XID XIDFRAME DLC_XIDは<で応じます。----------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- 構成されたXID
Wells & Bartky [Page 52] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[52ページ]RFC1795データ・リンク
for station or
forward XID to
station and
send response DLC_XID XIDFRAME DLC_XID
-----------> -----------> ----------->
応答DLC_XID XIDFRAME DLC_XIDを配置して、送るステーションか前進のXIDのために----------->。----------->。----------->。
SNRM DLC_CONTACT CONTACT DLC_CONTACTED
<--------- <----------- <----------- <------------
contact_pending connect_pending
SNRM DLC_接触接触DLC_は<に連絡しました。--------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-、-- 未定の接触_は未定の_を接続します。
UA DLC_CONTACTED CONTACTED DLC_CONTACT
----------> -----------> -----------> ----------->
connected connected
Ua DLC_は連絡されたDLC_接触に連絡しました。---------->。----------->。----------->。-----------接続された>は接続しました。
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs <-----------> <------------> <------------> <------------>
IFRAMEs DLC_インフォメーションIFRAMEs DLC_インフォメーション<。-----------><。------------><。------------><。------------>。
Here is an example of a switched SDLC PU 2.0 device as the origin station.
ここに、切り換えられたSDLC PU2.0装置に関する例が起源ステーションとしてあります。
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | < Network > | | | ====== /______\ --------- \__ __/ --------- /______\ Origin Origin DLSw \___/ Target DLSw Target Station partner partner Station
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | <ネットワーク>。| | | ====== /______\ --------- \__ __/ --------- /______\起源起源DLSw\___/目標DLSw Target駅パートナーパートナー駅
disconnected disconnected
外された状態で、連絡を断ちます。
implementer's DLC_RESOLVE_C CANUREACH_ex choice (power -----------> -----------> up, configuration change, DLC_RESOLVE_R ICANREACH_ex never, <----------- <----------- connect timer,etc.)
implementerのDLC_RESOLVEの_のCのCANUREACHの_の元の選択(power -----------> -----------> up, configuration change, DLC_RESOLVE_R ICANREACH_ex never, <----------- <----------- connect timer,etc.)
XID(null) DLC_XID(null) CANUREACH_cs DLC_START_DL
-----------> -----------> -----------> ----------->
circuit_start resolve_pending
(ヌル)のXIDのDLC_XID(ヌル)のCANUREACH_Cs DLC_スタート_dl----------->。----------->。----------->。-----------未定の>サーキット_スタート決心_
ICANREACH_cs DLC_DL_STARTED
<----------- <-----------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
ICANREACH_Cs DLC_dl_は<を始動しました。----------- <、-、-、-、-、-、-、-、-、-、-- サーキット_は_サーキットの未定のREACH_ACKを設立しました。-----------_が確立した>サーキット
Wells & Bartky [Page 53] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[53ページ]RFC1795データ・リンク
XIDFRAME DLC_XID
-----------> ----------->
XID DLC_XID XIDFRAME DLC_XID
<--------- <----------- <----------- <-----------
XID DLC_XID XIDFRAME DLC_XID
---------> -----------> -----------> ----------->
XIDFRAME DLC_XID----------->。----------->XID DLC_XID XIDFRAME DLC_XID<。--------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- XID DLC_XID XIDFRAME DLC_XID--------->。----------->。----------->。----------->。
SNRM DLC_CONTACT CONTACT DLC_CONTACTED
<--------- <----------- <----------- <-----------
contact_pending connect_pending
SNRM DLC_接触接触DLC_は<に連絡しました。--------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- 未定の接触_は未定の_を接続します。
UA DLC_CONTACTED CONTACTED DLC_CONTACT
---------> -----------> -----------> ----------->
connected connected
Ua DLC_は連絡されたDLC_接触に連絡しました。--------->。----------->。----------->。-----------接続された>は接続しました。
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs <----------> <------------> <------------> <------------>
IFRAMEs DLC_インフォメーションIFRAMEs DLC_インフォメーション<。----------><。------------><。------------><。------------>。
Here is an example of a leased SDLC PU 2.0 device as the target station.
ここに、賃貸されたSDLC PU2.0装置に関する例が目標ステーションとしてあります。
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / IP \ __| _|_ |__ | |
====== | | | < Network > | | | ======
/______\ --------- \__ __/ --------- /______\
Origin Origin DLSw \___/ Target DLSw Target
Station partner partner Station
(SDLC)
disconnected disconnected
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | <ネットワーク>。| | | ====== /______\ --------- \__ __/ --------- /______\起源起源DLSw\___DLSw Target駅のパートナーパートナー駅(SDLC)が外した/目標は連絡を断ちました。
DLC_RESOLVE_C CANUREACH_ex
-----------> -----------> reply if virtual MAC/SAP
for SDLC station is
configured, if SDLC
station responds to
DLC_RESOLVE_R ICANREACH_ex TEST/SNRM/DISC, etc.
<----------- <-----------
DLC_XID CANUREACH_cs DLC_START_DL SNRM
-----------> -----------> -----------> --------->
circuit_start resolve_pending
DLC_決心_C CANUREACH_元の連れ合い----------->。----------->回答はSDLCステーションへの仮想のMAC/SAPであるならSDLCステーションが_元のTEST/SNRM/DISCなどをDLC_RESOLVE_R ICANREACHに反応させるなら構成されます。 <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- _DLC_XID CANUREACH_Cs DLC_スタートdl SNRM----------->。----------->。----------->。---------未定の>サーキット_スタート決心_
ICANREACH_cs DLC_DL_STARTED UA
<----------- <----------- <-------
circuit_established circuit_pending
RNR
REACH_ACK --------->
-----------> circuit_established
ICANREACH_Cs DLC_dl_はUA<を始動しました。----------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-- サーキット_は_サーキットの未定のRNR REACH_ACKを設立しました。--------->。-----------_が確立した>サーキット
Wells & Bartky [Page 54] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[54ページ]RFC1795データ・リンク
XIDFRAME DLC_XID
-----------> -----------> respond with
XID configured
for station
or forward
XID to
station and
send
DLC_XID XIDFRAME DLC_XID response
<----------- <----------- <-----------
DLC_CONTACTED CONTACT DLC_CONTACT RR
-----------> -----------> -----------> --------->
connect_pending contact_pending
XIDFRAME DLC_XID----------->。----------->はXIDがステーションか前進のXIDのためにステーションに構成にされているので応じて、DLC_XID XIDFRAME DLC_XID応答<を送ります。----------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- DLC_は接触DLC_接触RRに連絡しました。----------->。----------->。----------->。--------->は_未定の未定の接触_を接続します。
DLC_CONTACT CONTACTED DLC_CONTACTED
<----------- <----------- <-----------
connected connected
DLC_接触の連絡されたDLC_は<に連絡しました。----------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- 接続されていた状態で、接続されます。
DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs
<------------> <------------> <------------> <------->
DLC_インフォメーションIFRAMEs DLC_インフォメーションIFRAMEs<。------------><。------------><。------------><。------->。
Here is an example of a switched SDLC PU 2.0 device as the target station.
ここに、切り換えられたSDLC PU2.0装置に関する例が目標ステーションとしてあります。
====== ___ ======
| | --------- __/ \__ --------- | |
| | __| _|_ |__ / IP \ __| _|_ |__ | |
====== | | | < Network > | | | ======
/______\ --------- \__ __/ --------- /______\
Origin Origin DLSw \___/ Target DLSw Target
Station partner partner Station
(SDLC)
disconnected disconnected
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | <ネットワーク>。| | | ====== /______\ --------- \__ __/ --------- /______\起源起源DLSw\___DLSw Target駅のパートナーパートナー駅(SDLC)が外した/目標は連絡を断ちました。
DLC_RESOLVE_C CANUREACH_ex
-----------> -----------> reply if virtual MAC/SAP
for SDLC station is
configured, if SDLC
station responds to
DLC_RESOLVE_R ICANREACH_ex TEST/XID/SNRM/DISC, etc.
<----------- <-----------
DLC_XID CANUREACH_cs DLC_START_DL XID
-----------> -----------> -----------> --------->
circuit_start resolve_pending
DLC_決心_C CANUREACH_元の連れ合い----------->。----------->回答はSDLCステーションへの仮想のMAC/SAPであるならSDLCステーションが_元のTEST/XID/SNRM/DISCなどをDLC_RESOLVE_R ICANREACHに反応させるなら構成されます。 <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- _DLC_XID CANUREACH_Cs DLC_スタートdl XID----------->。----------->。----------->。---------未定の>サーキット_スタート決心_
ICANREACH_cs DLC_DL_STARTED XID
<----------- <----------- <--------
circuit_established circuit_pending
ICANREACH_Cs DLC_dl_はXID<を始動しました。----------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-- 未定のサーキット_確立したサーキット_
Wells & Bartky [Page 55] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[55ページ]RFC1795データ・リンク
REACH_ACK
-----------> circuit_established
_ACKに達してください。-----------_が確立した>サーキット
XIDFRAME DLC_XID
-----------> -----------> respond
with XID
received
DLC_XID XIDFRAME DLC_XID above
<----------- <----------- <---------
DLC_CONTACTED CONTACT DLC_CONTACT SNRM
-----------> -----------> -----------> --------->
connect_pending contact_pending
XIDFRAME DLC_XID----------->。----------->はXIDの容認された_DLC_XID XIDFRAME DLC XIDと共に<の上で応じます。----------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-- DLC_は接触DLC_接触SNRMに連絡しました。----------->。----------->。----------->。--------->は_未定の未定の接触_を接続します。
DLC_CONTACT CONTACTED DLC_CONTACTED UA
<----------- <----------- <----------- <--------
connected connected
DLC_接触の連絡されたDLC_はUa<に連絡しました。----------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-- 接続されていた状態で、接続されます。
DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs
<------------> <------------> <------------> <-------->
DLC_インフォメーションIFRAMEs DLC_インフォメーションIFRAMEs<。------------><。------------><。------------><。-------->。
Here is an example of an SDLC T2.1 device as the target station. (SDLC T2.1 origin station would look just like the LAN T2.1 origin station)
ここに、SDLC T2.1装置に関する例が目標ステーションとしてあります。 (SDLC T2.1起源ステーションはまさしくLAN T2.1起源ステーションに似ているでしょう)
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | < Network > | | | ====== /______\ --------- \__ __/ --------- /______\ Origin Origin DLSw \___/ Target DLSw Target Station partner partner Station
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | <ネットワーク>。| | | ====== /______\ --------- \__ __/ --------- /______\起源起源DLSw\___/目標DLSw Target駅パートナーパートナー駅
disconnected disconnected
外された状態で、連絡を断ちます。
DLC_RESOLVE_C CANUREACH_ex
-----------> -----------> implementer's choice
(virtual MAC/SAP
configured,
check to see if station
is powered up using
DLC_RESOLVE_R ICANREACH_ex TEST/XID/DISC, etc.)
<----------- <-----------
DLC_XID CANUREACH_cs DLC_START_DL null XID
-----------> -----------> -----------> --------->
circuit_start resolve_pending
DLC_決心_C CANUREACH_元の連れ合い----------->。----------->implementerの選択(仮想のMAC/SAPが構成されて、チェックして、ステーションがDLC_RESOLVE_R ICANREACH_元の連れ合いTEST/XID/DISCなどを使用するのに動かされるかどうか確認してください) <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- DLC_XID CANUREACH_Cs DLC_START_DLヌルXID----------->。----------->。----------->。---------未定の>サーキット_スタート決心_
ICANREACH_cs DLC_DL_STARTED XID
<----------- <----------- <-------
ICANREACH_Cs DLC_dl_はXID<を始動しました。----------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、--
Wells & Bartky [Page 56] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[56ページ]RFC1795データ・リンク
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
XIDFRAME DLC_XID
-----------> -----------> respond with
XID received
DLC_XID XIDFRAME DLC_XID above
<----------- <----------- <----------
DLC_XIDs XIDFRAMEs DLC_XIDs XIDs
<------------> <------------> <------------> <-------->
DLC_CONTACTED CONTACT DLC_CONTACT SNRM
-----------> -----------> -----------> --------->
connect_pending contact_pending
サーキット_は_サーキットの未定のREACH_ACKを設立しました。----------->サーキット_はXIDFRAME DLC_XIDを設立しました。----------->。----------->はXIDの容認された_DLC_XID XIDFRAME DLC XIDと共に<の上で応じます。----------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-- DLC_XIDs XIDFRAMEs DLC_XIDs XIDs<。------------><。------------><。------------><。-------->DLC_は接触DLC_接触SNRMに連絡しました。----------->。----------->。----------->。--------->は_未定の未定の接触_を接続します。
DLC_CONTACT CONTACTED DLC_CONTACTED UA
<----------- <----------- <----------- <-------
connected connected
DLC_接触の連絡されたDLC_はUa<に連絡しました。----------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-- 接続されていた状態で、接続されます。
DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs
<------------> <------------> <------------> <-------->
DLC_インフォメーションIFRAMEs DLC_インフォメーションIFRAMEs<。------------><。------------><。------------><。-------->。
Wells & Bartky [Page 57] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[57ページ]RFC1795データ・リンク
6.2 Link Restart Protocols
6.2 リンク再開プロトコル
The following figure depicts the protocol flows that result from restarting the end-to-end connection. This causes the Data Link Switches to terminate the existing connection and to enter the Circuit Established state awaiting the start of a new connection.
以下の図は、終わりから終わりとの接続を再出発するので、結果として生じるプロトコル流れについて表現します。 これは、Data Link Switchesが既存の接続を終えて、新しい接続の始まりを待つCircuit Established州に入れることを引き起こします。
Data Link Data Link Data Link Data Link
Control Switch Switch Control
--------------------- ---------------------
+-----------+ +-----------+
| Connected | | Connected |
SABME +-----------+ +-----------+
-----------> RESTART_DL
DM -------------------------------------> DISC
<----------- -------->
UA
DL_RESTARTED (Case 1) <--------
<-------------------------------------
+-----------+ +-----------+
|Circuit Est| |Circuit Est|
+-----------+ +-----------+
........... or ...........
SABME
-----------> DL_RESTARTED (Case 2)
UA <-------------------------------------
<----------- +-----------+
|Circuit Est|
CONTACT +-----------+
RNR ------------------------------------>
<----------
データ・リンクデータ・リンクデータ・リンクデータリンク制御スイッチスイッチ制御装置--------------------- --------------------- +-----------+ +-----------+ | 接続されます。| | 接続されます。| SABME+-----------+ +-----------+ ----------->再開_dl DM------------------------------------->ディスク<。----------- -------->Ua dl_は(ケース1)<を再開しました。-------- <------------------------------------- +-----------+ +-----------+ |回路エスト| |回路エスト| +-----------+ +-----------+、…、… SABME----------->dl_は(ケース2)UA<を再開しました。------------------------------------- <、-、-、-、-、-、-、-、-、-、-- +-----------+ |回路エスト| 接触+-----------+ RNR------------------------------------><。----------
Figure 5. DLSw Link Restart Message Protocols
図5。 DLSwリンク再開メッセージプロトコル
Upon receipt of a SABME command from the origin station, the origin DLSw will send a RESTART_DL message to the target DLSw. A DM response is also returned to the origin station and the data link is restarted.
発生源ステーションからのSABMEコマンドを受け取り次第、発生源DLSwはRESTART_DLメッセージを目標DLSwに送るでしょう。 また、DM応答を発生源ステーションに返します、そして、データ・リンクを再開します。
Upon receipt of the RESTART_DL message, the target DLSw will issue a DISC command to the target station. The target station is expected to return a UA response. The target DLSw will then restart its data link and send an DL_RESTARTED message back to the origin DLSw. During this exchange of messages, both Data Link Switches change states from Connected state to Circuit Established state.
RESTART_DLメッセージを受け取り次第、目標DLSwは目標ステーションにDISCコマンドを発行するでしょう。 目標ステーションがUA応答を返すと予想されます。 目標DLSwは次に、データ・リンクを再開して、DL_RESTARTEDメッセージを発生源DLSwに送り返すでしょう。 メッセージのこの交換の間、両方のData Link Switchesは州をConnected状態からCircuit Established状態に変えます。
If the origin station now resends the SABME command, the origin DLSw will send a CONTACT message to the target DLSw. If the SABME command
発生源ステーションが現在SABMEコマンドを再送すると、発生源DLSwはCONTACTメッセージを目標DLSwに送るでしょう。 SABMEが命令するなら
Wells & Bartky [Page 58] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[58ページ]RFC1795データ・リンク
is received prior to the receipt of the DL_RESTARTED message (case 2 in the figure), the CONNECT message is delayed until the DL_RESTARTED message is received. The resulting protocol flows at this point parallel those given above for the connect sequence.
DL_RESTARTEDメッセージが受信されるまで、(図におけるケース2)、CONNECTメッセージが遅れるというDL_RESTARTEDメッセージの領収書の前に受け取ります。 結果として起こるプロトコル流れがここに上に与えられたものに沿う、系列を接続してください。
6.3 Disconnect Protocols
6.3 分離プロトコル
The following figure depicts the protocol flows that result from the end system terminating an existing connection. Not only is the connection terminated, but the circuit between the Data Link Switches is taken down.
以下の図は既存の接続を終えるエンドシステムから生じるプロトコル流れについて表現します。 接続が終えられるだけではなく、Data Link Switchesの間の回路は降ろされます。
Data Link Data Link Data Link Data Link
Control Switch Switch Control
-------------------- --------------------
+-----------+ +-----------+
| Connected | | Connected |
+-----------+ +-----------+
DISC
----------> HALT_DL
UA -------------------------------------> DISC
<---------- --------->
UA
DL_HALTED <--------
<-------------------------------------
+-----------+ +-----------+
|Disconnectd| |Disconnectd|
+-----------+ +-----------+
データ・リンクデータ・リンクデータ・リンクデータリンク制御スイッチスイッチ制御装置-------------------- -------------------- +-----------+ +-----------+ | 接続されます。| | 接続されます。| +-----------+ +-----------+ ディスク---------->停止_dl Ua------------------------------------->ディスク<。---------- --------->Ua dl_は<を止めました。-------- <------------------------------------- +-----------+ +-----------+ |Disconnectd| |Disconnectd| +-----------+ +-----------+
......... or ..........
…、…
+-----------+ +-----------+
| Connected | | Connected |
+-----------+ +-----------+
DISC TCP Connection Failure DISC
<-------- <------------------------------------> --------->
UA UA
--------> <--------
+-----------+ +-----------+
|Disconnectd| |Disconnectd|
+-----------+ +-----------+
+-----------+ +-----------+ | 接続されます。| | 接続されます。| +-----------+ +-----------+ ディスクTCP接続失敗ディスク<。-------- <------------------------------------>。--------->Ua Ua--------><。-------- +-----------+ +-----------+ |Disconnectd| |Disconnectd| +-----------+ +-----------+
Figure 6. DLSw Disconnect Message Protocols
図6。 DLSwはメッセージプロトコルから切断します。
Upon receipt of a DISC command from the origin station, the origin DLSw will reply with a UA response and issue a HALT_DL message to the target DLSw. Upon receipt of the HALT_DL message, the target DLSw will send a DISC command to the target station. The target station
発生源ステーションからのDISCコマンドを受け取り次第、発生源DLSwはUA応答で返答して、HALT_DLメッセージを目標DLSwに発行するでしょう。 HALT_DLメッセージを受け取り次第、目標DLSwはDISCコマンドを目標ステーションに送るでしょう。 目標ステーション
Wells & Bartky [Page 59] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[59ページ]RFC1795データ・リンク
will then respond with a UA response, causing the target DLSw to return a DL_HALTED message to the origin DLSw. During this exchange of messages, both Data Link Switches change states from the Connected state to the Disconnected state.
そして、UA応答で、目標DLSwがDL_HALTEDメッセージを発生源DLSwに返すことを引き起こして、応じるでしょう。 メッセージのこの交換の間、両方のData Link Switchesは州をConnected状態からDisconnected状態に変えます。
If the TCP connection between two Data Link Switches fails, all connections that are currently multiplexed on the failed TCP connection will be taken down. This implies that both Data Link Switches will send DISC commands to all the local systems that are associated with the failed connections. Upon sending the DISC command, the Data Link Switch will enter the DISCONNECTED state for each circuit.
2Data Link Switchesの間のTCP接続が失敗すると、失敗したTCP接続のときに現在多重送信されるすべての接続が降ろされるでしょう。 これは、両方のData Link Switchesが失敗した接続に関連しているすべてのローカルシステムへのコマンドをDISCに送るのを含意します。 DISCコマンドを送ると、Data Link Switchは各回路のためにDISCONNECTED状態に入るでしょう。
7.0 Capabilities Exchange Formats/Protocol
7.0の能力が形式/プロトコルを交換します。
The Data Link Switching Capabilities Exchange is a special DLSw Switch-to-Switch control message that describes the capabilities of the sending data link switch. This control message is sent after the switch-to-switch connection is established and optionally during run time if certain operational parameters have changed and need to be communicated to the partner switch.
Data Link Switching Capabilities ExchangeはDLSw Switchからスイッチへのコントロール送付データタンブラ・スイッチの能力について説明する特別なメッセージです。 スイッチからスイッチとの接続を確立した後にこのコントロールメッセージを送ります、そして、任意に、ランタイムの間、ある操作上のパラメタが変化するか、そして、パートナーとコミュニケートするべき必要性は切り替わります。
The actual contents of the Capabilities Exchange is in the data field following the SSP message header. The Capabilities Exchange itself is formatted as a single General Data Stream (GDS) Variable with multiple type "LT" structured subfields.
SSPメッセージヘッダーに続いて、Capabilities Exchangeの実際のコンテンツがデータ・フィールドにあります。 複数のタイプ"LT"に従ったただ一つのData Stream司令官(GDS)変数が部分体を構造化したので、Capabilities Exchange自身はフォーマットされます。
The SSP Message Header has the following fields set for the Capabilities Exchange:
SSP Message Headerは以下の分野をCapabilities Exchangeに設定させます:
Offset Field Value
------ ----- -----
0x00 Version Number 0x31
0x01 Header Length 0x48 (decimal 72)
0x02 Message Length same as LL in GDS Variable
0x14 Message Type 0x20 (CAP_EXCHANGE)
0x16 Protocol Id 0x42
0x17 Header Number 0x01
0x23 Message Type 0x20 (CAP_EXCHANGE)
0x38 Direction 0x01 for CapEx request
0x02 for CapEx response
分野値を相殺してください。------ ----- ----- 0×00 CapExのためのGDS Variable0x14Message Type0x20(CAP_EXCHANGE)0x16プロトコルId0x42 0×17Header Number0x01 0×23Message Type0x20(CAP_EXCHANGE)0x38Direction0x01のLLがCapEx応答のために0×02を要求するのと同じバージョンNumber0x31 0×01Header Length0x48(10進72)0×02Message Length
Other fields in the SSP header are not referenced and should be set to zero.
SSPヘッダーの他の分野は、参照をつけられないで、ゼロに設定されるべきです。
Wells & Bartky [Page 60] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[60ページ]RFC1795データ・リンク
The DLSw Capabilities Exchange Request has the following overall format:
DLSw Capabilities Exchange Requestには、以下の総合的な形式があります:
+----+----+-----------------+ | LL | ID | Control Vectors | +----+----+-----------------+
+----+----+-----------------+ | LL| ID| コントロールベクトル| +----+----+-----------------+
0-1 Length, in binary, of the DLSw Capabilities
Exchange
Request GDS Variable. The value of LL is
the sum of the length of all fields in the
GDS Variable (i.e., length of LL + length of ID
+ length of Control Vectors).
0-1 DLSw Capabilities Exchange Request GDS Variableのバイナリーの長さ。 LLの値はGDS Variable(すなわち、Control VectorsのID+長さのLL+長さの長さ)のすべての分野の長さです。
2-3 GDS Id: 0x1520
2-3 GDSイド: 0×1520
4-n Control Vectors consisting of type LT structured
subfields (i.e., the DLSw Capabilities Exchange
Structured Subfields)
タイプLTから成る4-n Control Vectorsが部分体を構造化しました。(すなわち、DLSw能力交換は部分体を構造化しました)
Type LT structured subfields consist of a 1-byte length field (the "L"), a 1-byte type field (the "T") and n-bytes of data. The length field includes itself as well as the structured subfield. The structured subfield consists of the type field and data so the length is n + 2. This imposes a length restriction of 253 bytes on all data contained in a structured subfield.
構造化されて、LTをタイプしてください。部分体は1バイトの長さの分野(「L」)(1バイトのタイプ分野(「T」)とn-バイトのデータ)から成ります。 長さの分野は構造化された部分体と同様にそれ自体を含んでいます。 構造化された部分体がタイプ分野とデータから成るので、長さはn+2です。 これは構造化された部分体に含まれたすべてのデータに253バイトの長さの制限を課します。
Wells & Bartky [Page 61] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[61ページ]RFC1795データ・リンク
7.1 Control Vector Id Range
7.1 コントロールベクトルイド範囲
Control Vector identifiers (i.e., Type) in the range of 0x80 through 0xCF are reserved for use by the Data Link Switching standard.
0xCFを通した0×80の範囲のコントロールVector識別子(すなわち、Type)は使用のためにData Link Switching規格によって予約されます。
Control Vector identifiers (i.e., Type) in the range of 0xD0 through 0xFD are used for vendor-specific purposes.
0xD0から0xFDの範囲のコントロールVector識別子(すなわち、Type)はベンダー明確な目標に使用されます。
Currently defined vectors are:
現在定義されたベクトルは以下の通りです。
Vector Description Hex Value
ベクトル記述十六進法価値
Vendor Id Control Vector 0x81 DLSw Version Control Vector 0x82 Initial Pacing Window Control Vector 0x83 Version String Control Vector 0x84 Mac Address Exclusivity Control Vector 0x85 Supported SAP List Control Vector 0x86 TCP Connections Control Vector 0x87 NetBIOS Name Exclusivity Control Vector 0x88 MAC Address List Control Vector 0x89 NetBIOS Name List Control Vector 0x8A Vendor Context Control Vector 0x8B Reserved for future use 0x8C - 0xCF Vendor Specific 0xD0 - 0xFD
未来のベンダーId Control Vector0x81DLSwバージョンControl Vector0x82Initial Pacing Window Control Vector0x83バージョンString Control Vector0x84Mac Address Exclusivity Control Vector0x85Supported SAP List Control Vector0x86TCPコネクションズControl Vector0x87NetBIOS Name Exclusivity Control Vector0x88マックーアドレスList Control Vector0x89NetBIOS Name List Control Vector 0x8A Vendor Context Control Vector 0x8B Reservedは0x8C--0xCF Vendor Specific 0xD0--0xFDを使用します。
7.2 Control Vector Order and Continuity
7.2 コントロールベクトル命令と連続
Since their contents can greatly affect the parsing of the Capabilities Exchange GDS Variable, the required control vectors must occur first and appear in the following order: Vendor Id, DLSw Version Number, Initial Pacing Window, Supported SAP List. The remainder of the Control Vectors can occur in any order.
それらのコンテンツがCapabilities Exchange GDS Variableの構文解析に大いに影響できるので、必要なコントロールベクトルは、最初に、起こって、以下のオーダーに現れなければなりません: ベンダーイド(DLSwバージョン番号、初期のペースの窓)は、SAPがリストであるとサポートしました。 Control Vectorsの残りは順不同に起こることができます。
Control Vectors that can be repeated within the same message (e.g., MAC Address List Control Vector and NetBIOS Name List Control Vector) are not necessarily adjacent. It is advisable, but not required, to have the Exclusivity Control Vector occur prior to either of the above two vectors so that the use of the individual MAC addresses or NetBIOS names will be known prior to parsing them.
同じメッセージ(例えば、マックーアドレスList Control VectorとNetBIOS Name List Control Vector)の中で繰り返すことができるコントロールVectorsは必ず隣接しているというわけではありません。 Exclusivity Control Vectorを上の2つのベクトルのどちらかの前にそれらを分析する前に個々のMACアドレスかNetBIOS名の使用が知られているように起こらせるのに、それは、賢明ですが、必要ではありません。
Both the Vendor Context and Vendor Specific control vectors can be repeated. If there are multiple instances of the Vendor Context control vector, the specified context remains in effect for all Vendor Specific control vectors until the next Vendor Context control vector is encountered in the Capabilities Exchange.
Vendor ContextとVendor Specificコントロールベクトルの両方を繰り返すことができます。 Vendor Contextコントロールベクトルの複数のインスタンスがあれば、次のVendor ContextコントロールベクトルがCapabilities Exchangeで遭遇するまで、指定された文脈はすべてのVendor Specificコントロールベクトルに有効なままで残っています。
Wells & Bartky [Page 62] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[62ページ]RFC1795データ・リンク
7.3 Initial Capabilities Exchange
7.3 初期の能力交換
Capabilities exchange is always the first SSP message sent on a new SSP connection between two DLSw switches. This initial Capabilities Exchange is used to identify the DLSw version that each switch is running and other required information, plus details of any optional extensions that the switches are capable of supporting.
いつも能力交換は2個のDLSwスイッチの間の新しいSSP接続に送られた最初のSSPメッセージです。 この初期のCapabilities Exchangeは、スイッチがサポートすることができる各スイッチが実行しているDLSwバージョン、他の必須情報、およびどんな任意の拡大の詳細も特定するのに使用されます。
If a DLSw receives an initial capabilities message that is incorrectly formatted or contains invalid or unsupported data that prevents correct interoperation with the partner DLSw, it should issue a Capabilities Exchange negative response.
DLSwが不当にフォーマットされる初期の能力メッセージを受け取るか、またはパートナーDLSwと共に正しいinteroperationを防ぐ無効の、または、サポートされないデータを含んでいるなら、それはCapabilities Exchange否定応答を発行するべきです。
If a DLSw receives a negative response to its initial capabilities message, it should take down its TCP connections with the offended partner.
DLSwが初期の能力メッセージに否定応答を受けるなら、それは怒っているパートナーとのTCP接続を降ろすべきです。
Note: Pre v1.0 DLSw implementations do not send or respond to capabilities messages and can be identified by the lack of capabilities exchange as the first message on a new SSP connnection. This document does not attempt to specify how to interoperate with back-level DLSw implementations.
以下に注意してください。 前v1.0 DLSw実装は、発信しないか、能力メッセージに応じて、または新しいSSP connnectionに関する最初のメッセージとして能力交換の不足で特定できます。 このドキュメントは、逆レベルDLSw実装で共同利用する方法を指定するのを試みません。
7.4 Run-Time Capabilities Exchange
7.4 ランタイム能力交換
Capabilities exchange always occurs when the SSP connection is started between two DLSw switches. Capabilities Exchange can also occur at run-time, typically when a configuration change is made.
SSP接続が2個のDLSwスイッチの間で始められるとき、能力交換はいつも起こります。 また、能力Exchangeはランタイムのときに起こることができて、構成であるときに、通常、変更は行われます。
Support for run-time Capabilities Exchange is optional. If a node does not support receiving/using Run-Time Capabilities Exchange and receives one, it should discard it quietly (not send back a negative response). If a node supports receipt of run-time capabilities, it should send a positive or negative response as appropriate. The receiver of a negative response to a run-time capabilities message is not required to take down its TCP connections with the offended partner.
ランタイムCapabilities Exchangeのサポートは任意です。 ノードが受信/使用がRun-時間Capabilities Exchangeであることを支えないで、1を受け取るなら、それは静か(否定応答を返送しない)にそれを捨てるべきです。 ノードがランタイム能力の領収書を支えるなら、それは適宜肯定しているか否定している応答を送るべきです。 ランタイム能力メッセージへの否定応答の受信機は怒っているパートナーとのTCP接続を降ろす必要はありません。
Run-time Capabilities Exchange can consist of one or more of the following control vectors. Note that the control vectors required at start-up are not present in a run-time Capabilities Exchange.
ランタイムCapabilities Exchangeは以下のコントロールベクトルの1つ以上から成ることができます。 上にから始まるところで必要であるコントロールベクトルがランタイムCapabilities Exchangeに存在していないことに注意してください。
Wells & Bartky [Page 63] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[63ページ]RFC1795データ・リンク
1. MAC Address Exclusivity CV,
2. NetBIOS Name Exclusivity CV,
3. MAC Address List CV,
4. NetBIOS Name List CV,
5. Supported SAP List CV,
6. Vendor Context CV,
7. Vendor Specific CVs
1. マックーアドレス排他性CV、2。 NetBIOSは排他性CV、3を命名します。 マックーアドレスリストCV、4。 NetBIOSはリストCV、5を命名します。 体液リストCV、6であるとサポートされます。 ベンダー文脈CV、7。 ベンダーの特定のcvs
A run-time capabilities exchange is a replacement operation. As such, all pertinent MAC addresses and NetBIOS names must be specified in the run-time exchange. In addition, run-time changes in capabilities will not effect existing link station circuits.
ランタイム能力交換は交換操作です。 そういうものとして、ランタイム交換ですべての適切なMACアドレスとNetBIOS名を指定しなければなりません。 さらに、能力におけるランタイム変化は既存のリンクステーション回路に作用しないでしょう。
7.5 Capabilities Exchange Filtering Responsibilities
7.5の能力がフィルタリング責任を交換します。
Recipients of the SAP, MAC, and NetBIOS lists are not required to actually use them to filter traffic, etc., either initially or at run-time.
SAP、MAC、およびNetBIOSリストの受取人は、初めはかランタイムのときにトラフィックなどをフィルターにかけるのに実際にそれらを使用する必要はありません。
7.6 DLSw Capabilities Exchange Structured Subfields
7.6 DLSw能力交換は部分体を構造化しました。
The Capabilities Exchange Subfields are listed in the table below and are described in the following sections:
Capabilities Exchange Subfieldsは以下のテーブルに記載されていて、以下のセクションで説明されます:
Required Allowed @
ID @ Startup Length Repeatable* Runtime Order Content
==== ========= ====== ========== ======= ===== ===============
0x81 Y 0x05 N N 1 Vendor ID
必要な許容@ID@始動長さのRepeatable*ランタイムオーダー内容==== ========= ====== ========== ======= ===== =============== 0×81 Y0x05N N1ベンダーID
0x82 Y 0x04 N N 2 DLSw Version
0×82 Y0x04N N2DLSwバージョン
0x83 Y 0x04 N N 3 Initial pacing
window
0×83 Y0x04N N3初期のペースの窓
0x84 N >=0x02 N N 5+ Version String
0×84 N>=0x02N N5+バージョンストリング
0x85 N 0x03 N Y 5+ MAC Address
Exclusivity
0×85 N0x03N Y5+マックーアドレス排他性
0x86 Y 0x12 N Y 4 Supported SAP
List
0×86 SAPであるとサポートされたY0x12N Y4は記載します。
0x87 N 0x03 N N 5+ TCP Connections
0×87 N0x03N N5+TCPコネクションズ
0x88 N 0x03 N Y 5+ NetBIOS Name
Exclusivity
0×88 N0x03N Y5+NetBIOS名前排他性
Wells & Bartky [Page 64] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[64ページ]RFC1795データ・リンク
0x89 N 0x0E Y Y 5+ MAC Address
List
0×89 N0x0E Y Y5+マックーアドレスリスト
0x8A N <=0x13 Y Y 5+ NetBIOS Name
List
0x8A N<は0×13Y Y5+NetBIOS人名簿と等しいです。
0x8B N 0x05 Y Y 5+ Vendor Context
0x8B N0x05Y Y5+ベンダー文脈
0xD0 N varies Y Y 5+ Vendor Specific
0xD0NはY Y5+ベンダーSpecificを変えます。
*Note: "Repeatable" means a Control Vector is repeatable within a single message.
*以下に注意してください。 "Repeatable"は、Control Vectorがただ一つのメッセージの中で反復可能であることを意味します。
7.6.1 Vendor Id (0x81) Control Vector
7.6.1 ベンダーイド(0×81)コントロールベクトル
The Vendor Id control vector identifies the manufacturer's IEEE assigned Organizationally Unique Identifier (OUI) of the Data Link Switch sending the DLSw Capabilities Exchange. The OUI is sent in non-canonical (Token-Ring) format. This control vector is required and must be the first control vector.
Vendor IdコントロールベクトルはDLSw Capabilities Exchangeを送るData Link SwitchのOrganizationally Unique Identifier(OUI)が割り当てられたメーカーのIEEEを特定します。 正典外(トークンリング)の形式でOUIを送ります。 このコントロールベクトルは、必要であり、最初のコントロールベクトルであるに違いありません。
Offset Length Value Contents
------ ------ ----- --------
0 1 0x05 Length of the Vendor Id structured
subfield
長さの価値内容を相殺してください。------ ------ ----- -------- Vendor Idの0 1 0×05の長さは部分体を構造化しました。
1 1 0x81 key = 0x81 that identifies this as the
Vendor Id structured subfield
これがVendor Idであると認識する1 1 0×81キー=0×81が部分体を構造化しました。
2-4 3 the 3-byte Organizationally Unique
Identifier (OUI) for the vendor
(non-canonical format)
2-4 3 ベンダーのための3バイトのOrganizationally Unique Identifier(OUI)(正典外の形式)
7.6.2 DLSw Version (0x82) Control Vector
7.6.2 DLSwバージョン(0×82)コントロールベクトル
The DLSw Version control vector identifies the particular version of the DLSw standard supported by the sending Data Link Switch. This control vector is required and must follow the Vendor Id Control Vector.
DLSwバージョンコントロールベクトルは発信しているData Link SwitchによってサポートされたDLSw規格の特定のバージョンを特定します。 このコントロールベクトルは、必要であり、Vendor Id Control Vectorに続かなければなりません。
Offset Length Value Contents
------ ------ ----- --------
0 1 0x04 Length of the Version String structured
subfield
長さの価値内容を相殺してください。------ ------ ----- -------- バージョンStringの0 1 0×04の長さは部分体を構造化しました。
1 1 0x82 key = 0x82 that identifies this as the
DLSw Version structured subfield
これがDLSwバージョンであると認識する1 1 0×82キー=0×82が部分体を構造化しました。
Wells & Bartky [Page 65] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[65ページ]RFC1795データ・リンク
2 1 the hexadecimal value representing the
DLSw standard Version number of the
sending Data Link Switch.
0x01 (indicates version 1 - closed pages)
発信しているData Link SwitchのDLSwの標準のバージョン番号を表す16進が評価する2 1。 0×01(バージョン1--ページを閉じるのを示します)
3 1 the hexadecimal value representing the
DLSw standard Release number of the
sending Data Link Switch.
0x00 (indicates release 0)
発信しているData Link SwitchのDLSwの標準のRelease番号を表す16進が評価する3 1。 0×00(リリース0を示します)
7.6.3 Initial Pacing Window (0x83) Control Vector
7.6.3 初期のペースの窓(0×83)のコントロールベクトル
The Initial Pacing Window control vector specifies the initial value of the receive pacing window size for the sending Data Link Switch. This control vector is required and must follow the DLSw Version Control Vector.
Initial Pacing Windowコントロールベクトルが初期の値を指定する、発信しているData Link Switchのためにウィンドウサイズに歩調を合わせながら、受信してください。 このコントロールベクトルは、必要であり、DLSwバージョンControl Vectorに続かなければなりません。
Offset Length Value Contents
------ ------ ----- --------
0 1 0x04 Length of the Initial Pacing Window
structured subfield
長さの価値内容を相殺してください。------ ------ ----- -------- Initial Pacing Windowの0 1 0×04の長さは部分体を構造化しました。
1 1 0x83 key = 0x83 that identifies this
as the Initial Pacing Window
structured subfield
これがInitial Pacing Windowであると認識する1 1 0×83キー=0×83が部分体を構造化しました。
2-3 2 the pacing window size, specified
in byte normal form..
2-3 2 バイトの正常なフォームで指定されたペースウィンドウサイズ。
Note: The pacing window size must be non-zero.
以下に注意してください。 ペースウィンドウサイズは非ゼロであるに違いありません。
7.6.4 Version String (0x84) Control Vector
7.6.4 バージョンストリング(0×84)コントロールベクトル
The Version String control vector identifies the particular version number of the sending Data Link Switch. The format of the actual version string is vendor-defined. This control vector is optional.
バージョンStringコントロールベクトルは発信しているData Link Switchの特定のバージョン番号を特定します。 実際のバージョンストリングの形式はベンダーによって定義されています。 このコントロールベクトルは任意です。
Offset Length Value Contents
------ ------ ----- --------
0 1 0xn Length of the Version String
structured subfield
長さの価値内容を相殺してください。------ ------ ----- -------- バージョンStringの0 1 0xn Lengthは部分体を構造化しました。
1 1 0x84 key = 0x84 that identifies
this as the Version String
structured subfield
これがバージョンStringであると認識する1 1 0×84キー=0×84が部分体を構造化しました。
Wells & Bartky [Page 66] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[66ページ]RFC1795データ・リンク
2-n n-2 the ASCII string that identifies
the software version for the
sending DLSw.
発信しているDLSwのためのソフトウェアバージョンを特定するASCIIが結ぶ2-n n-2。
7.6.5 MAC Address Exclusivity (0x85) Control Vector
7.6.5 マックーアドレス排他性(0×85)コントロールベクトル
The MAC Address Exclusivity control vector identifies how the MAC Address List control vector data is to be interpreted. Specifically, this control vector identifies whether the MAC addresses in the MAC Address List control vectors are the only ones accessible via the sending Data Link Switch.
マックーアドレスExclusivityコントロールベクトルは解釈されるマックーアドレスListコントロールベクトルデータがことである方法を特定します。 明確に、このコントロールベクトルは、マックーアドレスListコントロールベクトルにおけるMACアドレスが発信しているData Link Switchを通してアクセスしやすい唯一の方であるかどうか特定します。
If a MAC Address List control vector is specified and the MAC Address Exclusivity control vector is missing, then the MAC addresses are not assumed to be the only ones accessible via this switch.
マックーアドレスListコントロールベクトルが指定されて、マックーアドレスExclusivityコントロールベクトルがなくなるなら、MACアドレスはこのスイッチを通してアクセスしやすい唯一の方であると思われません。
A node may specify that it supports no local MAC addresses by including in its capabilities the MAC Address List Exclusivity CV (with byte 2 == 0x01), and not including any instances of the MAC Address List CV.
ノードは、能力にマックーアドレスList Exclusivity CV(バイト2=0x01がある)を含んでいて、マックーアドレスList CVのどんなインスタンスも含んでいないことによってどんなローカルのMACアドレスもサポートしないと指定するかもしれません。
Offset Length Value Contents
------ ------ ----- --------
0 1 0x03 Length of the Exclusivity structured
subfield
長さの価値内容を相殺してください。------ ------ ----- -------- Exclusivityの0 1 0×03の長さは部分体を構造化しました。
1 1 0x85 key = 0x85 that identifies this as the
MAC address Exclusivity structured
subfield
これがMACアドレスExclusivityであると認識する1 1 0×85キー=0×85が部分体を構造化しました。
2 1 an indicator of the relationship of the
MAC addresses to the sending Data Link
Switch.
0x00 the MAC addresses specified in
this Capabilities Exchange
can be accessed via this
switch but are not the
exclusive set (i.e., other
entities are accessible in
addition to the ones specified)
0x01 the MAC addresses specified in
this Capabilities Exchange
are the only ones accessible
via this switch.
2 1、発信しているData Link SwitchへのMACアドレスの関係のインディケータ。 0×00 このCapabilities Exchangeで指定されたMACアドレスは、このスイッチを通してアクセスできますが、MACアドレスがこのCapabilities Exchangeで指定した唯一のセット(すなわち、他の実体は指定されたものに加えてアクセスしやすい)0×01がこのスイッチを通してアクセスしやすい唯一の方であるということではありません。
Wells & Bartky [Page 67] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[67ページ]RFC1795データ・リンク
7.6.6 SAP List Support (0x86) Control Vector
7.6.6 体液リストサポート(0×86)コントロールベクトル
The SAP List Support control vector identifies support for Logical Link Control SAPs (DSAPs and SSAPs) by the sending Data Link Switch. This is used by the DLSw that sent the SAP List Support control vector to indicate which SAPs can be used to support SNA and optionally NetBIOS traffic. This may be used by the DLSw that receives the SAP list to filter explorer traffic (TEST, XID, or NetBIOS UI frames) from the DLSw state machine. For SNA, a DLSw should set bits for all SAP values (SSAP or DSAP) that may be used for SNA traffic. For NetBIOS support, the bit for SAP 0xF0 should be set (if not supported then the same bit should be cleared).
SAP List Supportコントロールベクトルは発信しているData Link SwitchでLogical Link Control SAPs(DSAPsとSSAPs)のサポートを特定します。 これはSNAをサポートするのにどのSAPsを使用できるかを示すためにSAP List Supportコントロールベクトルを送ったDLSwによって使用されます、そして、任意に、NetBIOSは取引します。 これはDLSw州のマシンから探検家トラフィック(TEST、XID、またはNetBIOS UIフレーム)をフィルターにかけるためにSAPリストを受け取るDLSwによって使用されるかもしれません。 SNAのために、DLSwはSNAトラフィックに使用されるかもしれないすべてのSAP値(SSAPかDSAP)にビットを設定するはずです。 NetBIOSサポートにおいて、SAP0xF0のためのビットは設定されるべきです(サポートされないなら、同じビットはきれいにされるべきです)。
Each bit in the SAP control vector data field represents a SAP as defined below. This vector is required and must follow the Initial Pacing Window Control Vector.
SAPコントロールベクトルデータ・フィールドの各ビットは以下で定義されるようにSAPを代表します。 このベクトルは、必要であり、Initial Pacing Window Control Vectorに続かなければなりません。
Offset Length Value Contents
------ ------ ----- --------
0 1 0x12 Length of the Supported SAP List structured
subfield
長さの価値内容を相殺してください。------ ------ ----- -------- Supported SAP Listの0 1 0×12の長さは部分体を構造化しました。
1 1 0x86 key = 0x86 that identifies this as the
Supported SAP List structured subfield
これがSupported SAP Listであると認識する1 1 0×86キー=0×86が部分体を構造化しました。
2-17 16 the 16-byte bit vector describing all
even numbered SAPs enabled.
2-17 16 すべてについて説明する16バイトの噛み付いているベクトルは有効にされたSAPsに付番さえしました。
Each Bit within the 16 byte bit vector will
indicate whether an even numbered SAP is
enabled (b'1') or disabled (b'0').
16バイト噛み付いているベクトルの中の各Bitは、同等の番号付のSAPが(b'0')であると可能にされるか(b'1')、または無効にされるかを示すでしょう。
Each Byte within the 16 byte bit vector
will be numbered from 0 - F. (Most
significant byte first).
16バイト噛み付いているベクトルの中の各Byteは0から付番されるでしょう--F.、(最も重要なバイト、1番目)
Byte 0 1 2 3 ... F
XX XX XX XX ... XX
バイト0 1 2 3… F XX XX XX XX… XX
The bits in each byte indicate whether an
even numbered SAP is enabled (b'1') or
disabled (b'0'). (Most significant bit first)
各バイトにおけるビットは、同等の番号付のSAPが(b'0')であると可能にされるか(b'1')、または無効にされるかを示します。 (最上位ビット、1番目)
Bits 7 6 5 4 ... 0
SAP 0 2 4 6 ... E
ビット7 6 5 4… 0 SAP0 2 4 6… E
By combining the byte label with the enabled
bits, all supported SAPs can be determined.
バイトラベルを可能にされたビットに結合することによって、SAPsであるとサポートされたすべてが決定できます。
Wells & Bartky [Page 68] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[68ページ]RFC1795データ・リンク
In the following diagram, 'n' would equal 0
through F depending on which byte was being
interpreted.
'以下が図解するコネ、'どのバイトが解釈されていたかによるFを通した等しい0はそうするでしょう。
Bit ordering is shown below with bit
7 being the most significant bit and bit
0 the least significant bit.
噛み付いている注文は最も重要なビットである7とビット0のビットによる最下位ビットの下に示されます。
7654 3210
bbbb bbbb....
|||| ||||
|||| |||SAP 0xnE enabled or not
|||| |||
|||| ||SAP 0xnC enabled or not
|||| ||
|||| |SAP 0xnA enabled or not
|||| |
|||| SAP 0xn8 enabled or not
||||
|||SAP 0xn6 enabled or not
|||
||SAP 0xn4 enabled or not
||
|SAP 0xn2 enabled or not
|
SAP 0xn0 enabled or not
7654 3210bbbb bbbb… |||| |||| |||| |||有効にされたSAP0xnE|||| ||| |||| ||有効にされたSAP0xnC|||| || |||| |有効にされたSAP0xnA|||| | |||| 有効にされたSAP0xn8|||| |||有効にされたSAP0xn6||| ||有効にされたSAP0xn4|| |有効にされたSAP0xn2| 有効にされたSAP0xn0
Wells & Bartky [Page 69] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[69ページ]RFC1795データ・リンク
An example of using all User Definable SAPs of 0x04 to 0xEC for SNA Data Link Switching and SAP 0xF0 for NetBIOS Data Link Switching would be as follows:
NetBIOS Data Link SwitchingのためのSNA Data Link SwitchingとSAP0xF0に0×04のすべてのUser Definable SAPsを0xECに使用する例は以下の通りでしょう:
Offset SAPs Binary Hex
オフセットは2進の十六進法を徐々に破壊します。
0 4,8,C 0010 1010 0x2A 1 10,14,18,1C 1010 1010 0xAA 2 20,24,28,2C 1010 1010 0xAA 3 30,34,38,3C 1010 1010 0xAA 4 40,44,48,4C 1010 1010 0xAA 5 50,54,58,5C 1010 1010 0xAA 6 60,64,68,6C 1010 1010 0xAA 7 70,74,78,7C 1010 1010 0xAA 8 80,84,88,8C 1010 1010 0xAA 9 90,94,98,9C 1010 1010 0xAA A A0,A4,A8,AC 1010 1010 0xAA B B0,B4,B8,BC 1010 1010 0xAA C C0,C4,C8,CC 1010 1010 0xAA D D0,D4,D8,DC 1010 1010 0xAA E E0,E4,E8,EC 1010 1010 0xAA F F0 1000 0000 0x80
0 4,8,C 0010 1010 0x2A 1 10,14,18,1C 1010 1010 0xAA 2 20,24,28,2C 1010 1010 0xAA 3 30,34,38,3C 1010 1010 0xAA 4 40,44,48,4C 1010 1010 0xAA 5 50,54,58,5C 1010 1010 0xAA 6 60,64,68,6C 1010 1010 0xAA 7 70,74,78,7C 1010 1010 0xAA 8 80,84,88,8C 1010 1010 0xAA 9 90,94,98,9C 1010 1010 0xAA A A0,A4,A8,AC 1010 1010 0xAA B B0,B4,B8,BC 1010 1010 0xAA C C0,C4,C8,CC 1010 1010 0xAA D D0,D4,D8,DC 1010 1010 0xAA E E0,E4,E8,EC 1010 1010 0xAA F F0 1000 0000 0x80
7.6.7 TCP Connections (0x87) Control Vector
7.6.7 TCPコネクションズ(0×87)コントロールベクトル
The TCP Connections control vector indicates the support of an alternate number of TCP Connections for the Data Link Switching traffic. The base implementation of Data Link Switching supports two TCP Connections, one for each direction of data traffic.
TCPコネクションズコントロールベクトルは交互の数のTCPコネクションズのサポートをData Link Switching交通に示します。 Data Link Switchingのベース実現は2TCPコネクションズ、データ通信量の各指示あたり1つを支持します。
This control vector is optional. If it is omitted in a DLSw Capabilities Exchange, then two TCP Connections are assumed. It is further assumed that if a Data Link Switch can support one TCP Connection, it can support two TCP Connections.
このコントロールベクトルは任意です。 それが省略されるなら、DLSw Capabilities Exchange、当時2では、TCPコネクションズは想定されます。 Data Link Switchが1TCP Connectionを支持できるなら、サポートtwo TCPコネクションズを支持できるとさらに思われます。
If TCP Connections CV values agree and the number of connections is one, then the DLSw with the higher IP address must tear down the TCP connections on its local port 2065.
TCPコネクションズCV値が同意して、ポートの数が1であるなら、より高いIPアドレスがあるDLSwは地方のポート2065の上でTCP接続を取りこわさなければなりません。
The format of the TCP Connections Control Vector is shown below:
TCPコネクションズControl Vectorの書式は以下に示されます:
Offset Length Value Contents
------ ------ ----- --------
0 1 0x03 Length of the TCP Connections structured
subfield
長さの価値内容を相殺してください。------ ------ ----- -------- TCPコネクションズの0 1 0×03の長さは部分体を構造化しました。
1 1 0x87 key = 0x87 that identifies this as the
TCP Connections structured subfield
これがTCPコネクションズであると認識する1 1 0×87キー=0×87が部分体を構造化しました。
Wells & Bartky [Page 70] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[70ページ]RFC1795データ・リンク
2 1 an indicator of the support for an
alternate number of TCP Connections by
the sending Data Link Switch.
0x01 the number of TCP Connections
may be brought down to one
after Capabilities Exchange
is completed.
0x02 the number of TCP Connections
will remain at two for
the duration of the DLSw
connection.
2 1、発信しているData Link Switchによる交互の数のTCPコネクションズのサポートのインディケータ。 0×01 Capabilities Exchangeが完成した後にTCPコネクションズの数は1までもたらされるかもしれません。 0×02 TCPコネクションズの数はDLSw接続の持続時間のために2に残るでしょう。
7.6.8 NetBIOS Name Exclusivity (0x88) Control Vector
7.6.8 NetBIOS名前排他性(0×88)コントロールベクトル
The NetBIOS Name Exclusivity control vector identifies how the NetBIOS Name List control vector data is to be interpreted. Specifically, this control vector identifies whether the NetBIOS Names in the NetBIOS Name List control vectors are the only ones accessible via the sending Data Link Switch.
NetBIOS Name Exclusivityコントロールベクトルは解釈されるNetBIOS Name Listコントロールベクトルデータがことである方法を特定します。 明確に、このコントロールベクトルは、NetBIOS Name ListコントロールベクトルにおけるNetBIOS Namesが発信しているData Link Switchを通してアクセスしやすい唯一の方であるかどうか特定します。
If a NetBIOS Name List control vector is specified and the NetBIOS Name Exclusivity control vector is missing, then the NetBIOS Names are not assumed to be the only ones accessible via this switch.
NetBIOS Name Listコントロールベクトルが指定されて、NetBIOS Name Exclusivityコントロールベクトルがなくなるなら、NetBIOS Namesはこのスイッチを通してアクセスしやすい唯一の方であると思われません。
A node may specify that it supports no local NetBIOS names by including in its capabilities the NetBIOS Name List Exclusivity CV (with byte 2 == 0x01), and not including any instances of the NetBIOS Name List CV.
ノードは、能力にNetBIOS Name List Exclusivity CV(バイト2=0x01がある)を含んでいて、NetBIOS Name List CVのどんな例も含んでいないことによってどんなローカルのNetBIOS名もサポートしないと指定するかもしれません。
Offset Length Value Contents
------ ------ ----- --------
0 1 0x03 Length of the Exclusivity structured
subfield
長さの価値内容を相殺してください。------ ------ ----- -------- Exclusivityの0 1 0×03の長さは部分体を構造化しました。
1 1 0x88 key = 0x88 that identifies this as the
NetBIOS Name Exclusivity structured
subfield
これがNetBIOS Name Exclusivityであると認識する1 1 0×88キー=0×88が部分体を構造化しました。
2 1 an indicator of the relationship of the
NetBIOS Names to the sending Data Link
Switch.
0x00 the NetBIOS Names specified in
this Capabilities Exchange
can be accessed via this
switch but are not the
exclusive set (i.e., other
entities are accessible in
addition to the ones specified)
2 1、発信しているData Link SwitchへのNetBIOS Namesの関係のインディケータ。 0×00 このCapabilities Exchangeで指定されたNetBIOS Namesはこのスイッチを通してアクセスできますが、唯一のセットではありません。(すなわち、他の実体は指定されたものに加えてアクセスしやすいです)
Wells & Bartky [Page 71] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[71ページ]RFC1795データ・リンク
0x01 the NetBIOS Names specified in
this Capabilities Exchange
are the only ones accessible
via this switch.
0×01このCapabilities Exchangeで指定されたNetBIOS Namesはこのスイッチを通してアクセスしやすい唯一の方です。
7.6.9 MAC Address List (0x89) Control Vector
7.6.9 マックーアドレスリスト(0×89)コントロールベクトル
The MAC Address List control vector identifies one or more MAC addresses that are accessible through the sending Data Link Switch. This control vector specifies a single MAC address value and MAC address mask value to identify the MAC address or range of MAC addresses. MAC addresses and masks are in non-canonical (Token-Ring) format in this control vector.
マックーアドレスListコントロールベクトルは1つ以上の発信しているData Link Switchを通して理解できるMACアドレスを特定します。 このコントロールベクトルは、MACアドレスのMACアドレスか範囲を特定するためにただ一つのMACアドレス値とMACアドレスマスク価値を指定します。 このコントロールベクトルにおける正典外(象徴リング)の形式にはMACアドレスとマスクがあります。
This control vector is optional and can be repeated if necessary.
このコントロールベクトルは、任意であり、必要なら、繰り返すことができます。
Note 1: If a particular MAC address, <mac-addr>, satisfies the following algorithm, then <mac-addr> is assumed to be accessible via the sending Data Link Switch:
注意1: 特定のMACアドレス(<mac-addr>)が以下のアルゴリズムを満たすなら、<mac-addr>が発信しているData Link Switchを通してアクセスしやすいと思われます:
<mac-addr> & <mac-addr-mask> == <mac-addr-value>
<mac-addr>と<mac-addr-マスク>=<mac-addr-価値の>。
where: <mac-addr-value> is the MAC Address
Value specified in
this control vector
どこ: <mac-addr-価値の>はこのコントロールベクトルで指定されたマックーアドレスValueです。
<mac-addr-mask> is the MAC Address
Mask specified in
this control vector
<mac-addr-マスク>はこのコントロールベクトルで指定されたマックーアドレスMaskです。
Note 2: If an individual MAC Address is desired, then <mac-addr- value> should be the individual MAC address and <mac-addr-mask> should be 0xFFFFFFFFFFFF.
注意2: 個々のマックーアドレスが望まれているなら、<mac-addr-価値の>は個々のMACアドレスであるべきです、そして、<mac-addr-マスク>は0xFFFFFFFFFFFFであるべきです。
Offset Length Value Contents
------ ------ ----- --------
0 1 0x0E Length of the MAC Address List
structured subfield
長さの価値内容を相殺してください。------ ------ ----- -------- マックーアドレスListの0 1 0x0Eの長さは部分体を構造化しました。
1 1 0x89 key = 0x89 that identifies this as the
MAC Address List structured subfield
これがマックーアドレスListであると認識する1 1 0×89キー=0×89が部分体を構造化しました。
2-7 6 the 6-byte MAC Address Value,
<mac-addr-value> in the above formula
2-7 6 6バイトのマックーアドレスValue、上の公式の<mac-addr-価値の>。
8-13 6 the 6-byte MAC Address Mask,
<mac-addr-mask> in the above formula
8-13 6 6バイトのマックーアドレスMask、上の公式の<mac-addr-マスク>。
Wells & Bartky [Page 72] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[72ページ]RFC1795データ・リンク
7.6.10 NetBIOS Name List (0x8A) Control Vector
7.6.10 NetBIOS人名簿、(0x8A)コントロールベクトル
The NetBIOS Name List control vector identifies one or more NetBIOS names that are accessible through the sending Data Link Switch. This control vector specifies a single NetBIOS name in ASCII. However, the NetBIOS name can consist of "don't care" and "wildcard" characters to match on a number of NetBIOS names. If an individual character position in the NetBIOS name in this control vector contains a '?', then the corresponding character position in real NetBIOS name is a "don't care". If a NetBIOS name in this control vector ends in '*', then the remainder of real NetBIOS names is a "don't care". '*' is only considered a wildcard if it appears at the end of a name.
NetBIOS Name Listコントロールベクトルは1つ以上の発信しているData Link Switchを通してアクセスしやすいNetBIOS名を特定します。 このコントロールベクトルはASCIIにおけるただ一つのNetBIOS名を指定します。 しかしながら、缶が成るNetBIOS名は「気にかけられません」。そして、多くのNetBIOS名で合わせる「ワイルドカード」キャラクタ。 このコントロールベクトルにおけるNetBIOS名の個性位置が'?'を含んでいるなら、本当のNetBIOS名の対応する欄はaに「気にかけられない」ということです。 このコントロールベクトルにおけるNetBIOS名が'*'に終わるなら、本当のNetBIOS名の残りはaに「気にかけられない」ということです。 名前の終わりに現れる場合にだけ、'*'はワイルドカードであると考えられます。
All blanks or nulls at the end of NetBIOS names in this control vector are ignored. NetBIOS names which have fewer than 16 bytes and which do not end with '*' are not assumed to have a trailing '*'; the "wildcard" character must be explicit.
このコントロールベクトルにおけるNetBIOS名の終わりのすべての空白かヌルが無視されます。 16バイト未満を持って、'*'で終わらないNetBIOS名が引きずっている'*'を持っていると思われません。 「ワイルドカード」キャラクタは明白であるに違いありません。
NetBIOS group names can exist across several LANs/networks. As such, NetBIOS group names received in a NetBIOS Name List Control Vector can not be treated the same as NetBIOS individual names. The Individual/Group Flag allows Data Link Switches to distinguish between the two.
NetBIOSグループ名はいくつかのLAN/ネットワークの向こう側に存在できます。 そういうものとして、同じようにNetBIOS Name List Control Vectorに受け取られたNetBIOSグループ名はNetBIOS個人名として扱うことができません。 Individual/グループFlagはData Link Switchesに2を見分けさせます。
This control vector is optional and can be repeated if necessary.
このコントロールベクトルは、任意であり、必要なら、繰り返すことができます。
Offset Length Value Contents
------ ------ ----- --------
0 1 0xn Length of the NetBIOS Name List
structured subfield (maximum = 0x13)
長さの価値内容を相殺してください。------ ------ ----- -------- NetBIOS Name Listの0 1 0xn Lengthは部分体を構造化しました。(最大の=0×13)
1 1 0x8A key = 0x8A that identifies this as the
NetBIOS Name List structured subfield
これがNetBIOS Name Listであると認識する1 1 0x8A主要な=0x8Aが部分体を構造化しました。
2 1 Individual/Group Flag
0x00 - Individual NetBIOS Name
0x01 - Group NetBIOS Name
2 1個人/グループ旗0x00--個々のNetBIOS名0x01--グループNetBIOS名
3-n n-3 the NetBIOS name with possible embedded
'?' and terminating '*'.
NetBIOSが可能な埋め込まれた'?'で命名する3-n n-3と'*'を終えること。
7.6.11 Vendor Context (0x8B) Control Vector
7.6.11 業者文脈(0x8B)コントロールベクトル
The Vendor Context control vector identifies the manufacturer's IEEE assigned Organizationally Unique Identifier (OUI) of the Data Link Switch sending the DLSw Capabilities Exchange. The OUI is sent in non-canonical (Token-Ring) format.
Vendor ContextコントロールベクトルはDLSw Capabilities Exchangeを送るData Link SwitchのOrganizationally Unique Identifier(OUI)が割り当てられたメーカーのIEEEを特定します。 正典外(象徴リング)の形式でOUIを送ります。
Wells & Bartky [Page 73] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[73ページ]RFC1795データ・リンク
This control vector is optional and is used to provide the context for any Vendor Specific control vectors that follow in the Capabilities Exchange. If there are multiple instances of the Vendor Context control vector, the specified context remains in effect for all Vendor Specific control vectors until the next Vendor Context control vector is encountered.
このコントロールベクトルは、任意であり、Capabilities Exchangeで続くどんなVendor Specificコントロールベクトルのための文脈も提供するのに使用されます。 Vendor Contextコントロールベクトルの複数の例があれば、次のVendor Contextコントロールベクトルが遭遇するまで、指定された文脈はすべてのVendor Specificコントロールベクトルに有効なままで残っています。
Offset Length Value Contents
------ ------ ----- --------
0 1 0x05 Length of the Vendor Context structured
subfield
長さの価値内容を相殺してください。------ ------ ----- -------- Vendor Contextの0 1 0×05の長さは部分体を構造化しました。
1 1 0x8B key = 0x8B that identifies this as the
Vendor Context structured subfield
これがVendor Contextであると認識する1 1 0x8B主要な=0x8Bが部分体を構造化しました。
2-4 3 the 3-byte Organizationally Unique
Identifier (OUI) for the vendor
(non-canonical format)
2-4 3 業者のための3バイトのOrganizationally Unique Identifier(OUI)(正典外の形式)
7.7 Capabilities Exchange Responses
7.7の能力が応答を交換します。
There are two kinds of DLSw Capabilities Exchange Responses: positive and negative. A positive response is returned to the sending Data Link Switch if there were no errors encountered in the DLSw Capabilities Exchange Request. A negative response is returned if there is at least one error encountered.
2種類のDLSw Capabilities Exchange Responsesがあります: 積極的であって、否定的です。 DLSw Capabilities Exchange Requestで遭遇する誤りが全くなかったなら、積極的な応答を発信しているData Link Switchに返します。 遭遇する少なくとも1つの誤りがあれば、否定応答を返します。
A positive DLSw Capabilities Exchange Response has the following overall format:
積極的なDLSw Capabilities Exchange Responseには、以下の総合的な形式があります:
+----+----+ | LL | ID | +----+----+
+----+----+ | LL| ID| +----+----+
0-1 Length, in binary, of the DLSw Capabilities
Exchange Response GDS Variable. The value of
LL in this case is 0x0004.
0-1 DLSw Capabilities Exchange Response GDS Variableのバイナリーの長さ。 この場合、LLの値は0×0004です。
2-3 GDS Id: 0x1521
2-3 GDSイド: 0×1521
A negative DLSw Capabilities Exchange Response has the following overall format:
否定的DLSw Capabilities Exchange Responseには、以下の総合的な形式があります:
+----+----+--------+--------+ | LL | ID | Offset | Reason | +----+----+--------+--------+
+----+----+--------+--------+ | LL| ID| 相殺されます。| 理由| +----+----+--------+--------+
Wells & Bartky [Page 74] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[74ページ]RFC1795データ・リンク
0-1 Length, in binary, of the DLSw Capabilities Exchange
Response GDS Variable. The value of LL is the sum of
the length of all fields in the GDS Variable (i.e.,
length of LL + length of ID + length of Offsets/Reasons).
0-1 DLSw Capabilities Exchange Response GDS Variableのバイナリーの長さ。 LLの値はGDS Variable(すなわち、Offsets/理由のID+長さのLL+長さの長さ)のすべての分野の長さです。
2-3 GDS Id: 0x1522
2-3 GDSイド: 0×1522
4-5 Offset into the DLSw Capabilities Exchange Request of the
error. Offset should always point to the start of the
GDS Variable or a specific control vector.
4-5 誤りのDLSw Capabilities Exchange Requestに相殺してください。 オフセットはいつもGDS Variableの始まりか特定のコントロールベクトルを示すべきです。
6-7 Reason code that uniquely identifies the error. Specific
values for the reason code are:
6-7 唯一誤りを特定するコードを推論してください。 理由コードのための特定の値は以下の通りです。
0x0001 invalid GDS length for a DLSw Capabilities
Exchange Request. (The value of Offset
is ignored.)
0×0001 DLSw Capabilities Exchange Requestに、無効のGDSの長さ。 (Offsetの値は無視されます。)
0x0002 invalid GDS id for a DLSw Capabilities
Exchange Request. (The value of Offset
is ignored.)
0×0002のDLSw Capabilities Exchange Requestに、無効のGDSイド。 (Offsetの値は無視されます。)
0x0003 Vendor Id control vector is missing. (The
value of Offset is ignored.)
0×0003業者Idコントロールベクトルはなくなっています。 (Offsetの値は無視されます。)
0x0004 DLSw Version control vector is missing. (The
value of Offset is ignored.)
0×0004DLSwバージョンコントロールベクトルはなくなっています。 (Offsetの値は無視されます。)
0x0005 Initial Pacing Window control vector is
missing. (The value of Offset is ignored.)
0×0005の初期のPacing Windowコントロールベクトルはなくなっています。 (Offsetの値は無視されます。)
0x0006 length of control vectors doesn't correlate
to the length of the GDS variable
0×0006 コントロールベクトルの長さはGDS変数の長さに関連しません。
0x0007 invalid control vector id
0×0007の無効の規制ベクトルイド
0x0008 length of control vector invalid
0×0008 コントロールベクトル病人の長さ
0x0009 invalid control vector data value
0×0009 無効のコントロールベクトルデータ価値
0x000A duplicate control vector (for non-repeating
control vectors)
0x000Aはコントロールベクトルをコピーします。(非反復しているコントロールベクトルのための)
0x000B out-of-sequence control vector (for
repeating control vector)
0x000Bは順序が狂ってベクトルを制御します。(繰り返しているコントロールベクトルのための)
0x000C DLSw Supported SAP List control vector is
missing.
0x000C DLSw Supported SAP Listコントロールベクトルはなくなっています。
Wells & Bartky [Page 75] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[75ページ]RFC1795データ・リンク
(The value of Offset is ignored.)
(Offsetの値は無視されます。)
Note: Multiple Offset, Reason pairs can be returned with one pair for each error encountered.
以下に注意してください。 複数のOffset、遭遇する各誤りあたり1組と共にReason組を返すことができます。
8. Pacing/Flow Control
8. ペース/フロー制御
This section describes the required Pacing and Flow Control mechanisms used by a Data Link Switch.
このセクションはメカニズムがData Link Switchで使用した必要なPacingとFlow Controlについて説明します。
While it is beyond the scope of this document to specify a policy for how an implementation maps SSP flow control to the native data link flow control at the edges, the following paragraphs describe a general philosophical overview of how the mechanism is to be applied.
実現がどう縁の固有のデータ・リンクフロー制御にSSPフロー制御を写像するかに方針を指定するためにこのドキュメントの範囲を超えている間、以下のパラグラフはどう適用されているかに関するメカニズムがことである一般的な哲学的な概観について説明します。
There are two types of flows which are covered by the flow control mechanism: connection-oriented and connectionless. In the first, connection-oriented flows, the implementer is to map the native flow control mechanism of the two data links at the boundaries to the SSP flow control mechanism thus presenting an end-to-end flow control mechanism which "pushes back" all the way to the originating station in either direction.
フロー制御メカニズムでカバーされている2つのタイプの流れがあります: 接続指向であってコネクションレスです。 1番目、接続指向の流れでは、implementerは、その結果、終わりから終わりへのフロー制御どちらかの方向に由来しているステーションまでのいっぱいに「後退する」メカニズムを提示しながら、境界で2個のデータ・リンクの固有のフロー制御メカニズムをSSPフロー制御メカニズムに写像することになっています。
However, in the case of connectionless traffic, this is not possible at the data link level because there is no native flow control mechanism for connectionless data links. At first glance it is tempting to allow connectionless traffic to flow the DLSw cloud unthrottled. However, the rationale for subjecting these flows to flow control within the DLSw cloud is to "push" the discarding of frames (should this become necessary) back to the ingress of the DLSw cloud. This "early discarding" of excessive DATAGRAMs should allow the cloud to remain deterministic without wasting network bandwidth.
しかしながら、コネクションレスな交通の場合では、コネクションレスなデータ・リンクへのどんな固有のフロー制御メカニズムもないので、これはデータリンク・レベルで可能ではありません。 一見したところではそれはDLSw雲が非阻止した流れにコネクションレスな交通を許容するのに誘惑しています。 「しかしながら、DLSwの中のフロー制御へのこれらの流れが曇らせるかける原理はフレーム(これが必要になるなら)を捨てることをDLSw雲のイングレスに押して戻す」ことです。 ネットワーク回線容量を浪費しないで、過度のDATAGRAMsをこの「早い捨てること」は決定論的に雲を残らせるべきです。
8.1 Basic Overview
8.1 基本的な概観
Each circuit consists of two data flows, one in each direction. Each data flow has its own independent flow control mechanism. For each data flow there is an entity that originates traffic, referred to as the sender, and a target entity which receives the traffic, referred to as the receiver.
各サーキットは2つのデータフロー、各方向への1から成ります。 各データフローには、それ自身の独立しているフロー制御メカニズムがあります。 各データフローのために、送付者と呼ばれた交通を溯源する実体と受信機と呼ばれた交通を受ける目標実体があります。
A sender may only send data when its receiver has granted explicit permission to send a discrete number of data units. Data units are defined as either a DGRMFRAME or an INFOFRAME.
受信機がデータ単位の離散的な数を送る明白な許可を与えたときだけ、送付者はデータを送るかもしれません。 データ単位はDGRMFRAMEかINFOFRAMEのどちらかと定義されます。
The receiver grants permission to send data units by sending a Flow Control Indicator (FCIND- defined later). The sender must acknowledge all FCINDs by sending a Flow Control Acknowledgment
Flow Control Indicator(後で定義されたFCIND)を送ることによって、受信機は送信データユニットに許可を与えます。 送付者は、Flow Control Acknowledgmentを送ることによって、すべてのFCINDsを承認しなければなりません。
Wells & Bartky [Page 76] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[76ページ]RFC1795データ・リンク
(FCACK- defined later).
(後で定義されたFCACK。)
A sending implementation must maintain these values:
送付実現はこれらの値を維持しなければなりません:
1. GrantedUnits - The number of units (frames) which the sender
currently has permission to send.
1. GrantedUnits--送付者が現在許可を持っているユニット(フレーム)の数は発信します。
2. CurrentWindow - This is a discrete number of units, controlled by
the receiver, which is basis for granting additional units.
2. CurrentWindow--これは受信機によって制御された追加ユニットを与える基礎である離散的な数のユニットです。
3. InitialWindowSize - Global for all circuits on a transport
connection. Learned in capabilities exchange when the transport
connection is established. It specifies an initial value for
CurrentWindow when each circuit is established.
3. InitialWindowSize--輸送接続の上のすべてのサーキットにおいて、グローバルです。 輸送接続が確立されるときの能力交換では、学術的です。 各サーキットが確立されるとき、それは初期の値をCurrentWindowに指定します。
A receiving implementation must maintain these values:
受信実現はこれらの値を維持しなければなりません:
1. CurrentWindow - This is a discrete number of units, controlled by
the receiver, which is basis for granting additional units.
1. CurrentWindow--これは受信機によって制御された追加ユニットを与える基礎である離散的な数のユニットです。
2. InitialWindowSize - Global for all circuits on a transport
connection. Sent in capabilities exchange when the transport
connection is established. It specifies an initial value for
CurrentWindow when each circuit is established.
2. InitialWindowSize--輸送接続の上のすべてのサーキットにおいて、グローバルです。 輸送接続が確立されるとき、能力交換を送りました。 各サーキットが確立されるとき、それは初期の値をCurrentWindowに指定します。
3. FCACKOwed - The sender owes an FCACK. If true, no FCIND may be
sent.
3. FCACKOwed--送付者はFCACKに負っています。 本当であるなら、FCINDを全く送らないかもしれません。
8.2 Frame Format
8.2 フレーム形式
The Flow control Byte is contained at offset 15 in both the Information and Control SSP messages. From a flow control perspective, the flow control information in the two frames are handled identically.
FlowコントロールByteはオフセット15時に情報とControl SSPメッセージの両方に含まれています。 フロー制御から、見解、2個のフレームのフロー制御情報は同様に扱われます。
The following diagram describes the format of the Flow Control Byte (Bit 7 is the most significant and Bit 0 is the Least significant bit of the octet):
以下のダイヤグラムはFlow Control Byteの形式について説明します(ビット7は最も重要です、そして、Bit0は八重奏のLeast重要なビットです):
bit 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+
|FCI|FCA| reserved | FCO |
+---+---+---+---+---+---+---+---+
ビット7 6 5 4 3 2 1 0+---+---+---+---+---+---+---+---+ |FCI|FCA| 予約されます。| FCO| +---+---+---+---+---+---+---+---+
FCI : Flow Control Indicator
FCA : Flow Control Ack
FCO : Flow Control Operator Bits
FCI: フロー制御インディケータFCA: フロー制御Ack FCO: フロー制御オペレータビット
Wells & Bartky [Page 77] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[77ページ]RFC1795データ・リンク
000 - Repeat Window Operator
001 - Increment Window Operator
010 - Decrement Window Operator
011 - Reset Window Operator
100 - Halve Window Operator
101 - Reserved
110 - Reserved
111 - Reserved
000(反復ウィンドウオペレータ001)はウィンドウオペレータ010を増加します--ウィンドウオペレータ011を減少させてください--ウィンドウオペレータ100をリセットしてください--ウィンドウオペレータ101--予約された110--予約された111--予約されるのを半分にしてください。
A frame with the FCI bit set is referred to as a Flow Control Indication (FCIND). An FCIND is used to manage the flow in the opposite direction of the frame which bears it.
FCIビットがセットしたことでのフレームはFlow Control Indication(FCIND)と呼ばれます。 FCINDは、それに堪えるフレームの逆方向の流れを管理するのに使用されます。
A frame with the FCA bit set is referred to as a Flow Control Acknowledgment (FCACK). An FCACK is used to manage the flow in the same direction of the frame which bears it.
FCAビットがセットしたことでのフレームはFlow Control Acknowledgment(FCACK)と呼ばれます。 FCACKは、それに堪えるフレームの同じ方向に流れを管理するのに使用されます。
NOTE: A frame may be both a FCIND and an FCACK.
以下に注意してください。 フレームはFCINDとFCACKの両方であるかもしれません。
A frame bearing an FCIND or FCACK may also contain data for the flow in the direction it is traveling. In such a frame, the FCIND or FCACK are said to be piggy-backed. A non-piggy-backed FCIND is called an Independent Flow Control Indication (IFCIND) and a non- piggy-backed FCACK is called an Independent Flow Control Acknowledgment (IFCACK). IFCIND and IFCACK messages are sent in a Independent Flow Control SSP message (type 0x21).
また、FCINDかFCACKを持っているフレームはそれが旅行している方向に流れのためのデータを含むかもしれません。 そのようなフレームでは、FCINDかFCACKが背負われると言われています。 非便乗しているFCINDは無党派Flow Control Indication(IFCIND)と呼ばれます、そして、非便乗しているFCACKは無党派Flow Control Acknowledgment(IFCACK)と呼ばれます。 無党派Flow Control SSPメッセージでIFCINDとIFCACKメッセージを送ります(0×21をタイプしてください)。
NOTE: A frame may be both an IFCIND and an IFCACK.
以下に注意してください。 フレームはIFCINDとIFCACKの両方であるかもしれません。
It is desirable to carry information in control messages so as to reduce the need to send a flow control only message. The diagram below shows the messages that may carry valid flow control information:
コントロールメッセージの情報を運ぶのは、メッセージだけをフロー制御に送る必要性を減少させるために望ましいです。 以下のダイヤグラムは有効なフロー制御情報を運ぶかもしれないメッセージを示しています:
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | < Network > | | | ====== /______\ --------- \__ __/ --------- /______\ Origin Origin DLSw \___/ Target DLSw Target Station partner partner Station
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | <ネットワーク>。| | | ====== /______\ --------- \__ __/ --------- /______\起源起源DLSw\___/目標DLSw Target駅パートナーパートナー駅
May have valid
FCI/FCA/FCO Data carrying
有効なFCI/FCA/FCO Dataが運んで、そうしたかもしれません。
N N CANUREACH_cs
----------->
Y* N ICANREACH_cs
N N CANUREACH_Cs----------->Y*N ICANREACH_Cs
Wells & Bartky [Page 78] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[78ページ]RFC1795データ・リンク
<-----------
Y N REACH_ACK
----------->
Y Y XIDFRAMEs
<------------>
Y Y DGRMFRAMEs
<------------>
Y N CONTACT
----------->
Y N CONTACTED
<-----------
Y Y INFOFRAMEs
<------------>
Y N RESTART_DL
----------->
Y N DL_RESTARTED
<-----------
Y N CONTACT
----------->
Y N CONTACTED
<-----------
N N HALT_DL
----------->
N N DL_HALTED
<-----------
<。----------- Y Nは_ACKに達します。----------->Y Y XIDFRAMEs<。------------>Y Y DGRMFRAMEs<。------------>Y N接触----------->Y Nは<に連絡しました。----------- Y Y INFOFRAMEs<。------------>Y N再開_dl----------->Y N dl_は<を再開しました。----------- Y N接触----------->Y Nは<に連絡しました。----------- N Nは_dlを止めます。----------->N N dl_は<を止めました。-----------
*Note: ICANREACH_cs cannot carry FCA, as there could not be an outstanding FCI.
*以下に注意してください。 傑出しているFCIがあるはずがなくて、ICANREACH_CsはFCAを運ぶことができません。
8.3 Granting Permission to Send Data
8.3 データを送る許可を与えること。
A receiver grants a sender permission to send units of data by sending FCIND. Each FCIND is further qualified by a flow control operator, which is encoded in the FCO bits of the FCIND header. With one exception (the Reset Window operator) all operators may be either piggy-backed or carried in a IFCIND.
受信機はFCINDを送ることによってユニットのデータを送る送付者許可を与えます。 各FCINDはフロー制御オペレータによってさらに資格があります。(そのオペレータは、FCINDヘッダーのFCOビットでコード化されます)。 ただ1つを例外として(Reset Windowオペレータ)すべてのオペレータが、IFCINDで背負われるか、または運ばれるかもしれません。
The five flow control operators are outlined below:
5人のフロー制御オペレータが以下に概説されています:
8.3.1 Repeat Window Operator
8.3.1 ウィンドウオペレータを繰り返してください。
This operator is processed as follows:
このオペレータは以下の通り処理されます:
(CurrentWindow unchanged)
GrantedUnits += CurrentWindow
(CurrentWindow変わりのない)のGrantedUnits+=CurrentWindow
Wells & Bartky [Page 79] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[79ページ]RFC1795データ・リンク
8.3.2 Increment Window Operator
8.3.2 増分のウィンドウオペレータ
This operator is processed as follows:
このオペレータは以下の通り処理されます:
CurrentWindow++
GrantedUnits += CurrentWindow
CurrentWindow++GrantedUnits+=CurrentWindow
8.3.3 Decrement Window Operator
8.3.3 減少ウィンドウオペレータ
This operator is processed as follows:
このオペレータは以下の通り処理されます:
CurrentWindow--
GrantedUnits += CurrentWindow
CurrentWindow--GrantedUnits+=CurrentWindow
NOTE: This operator may only be sent if CurrentWindow is greater than one.
以下に注意してください。 CurrentWindowが1歳以上である場合にだけこのオペレータを送るかもしれません。
8.3.4 Reset Window Operator
8.3.4 リセットウィンドウオペレータ
This operator is processed as follows:
このオペレータは以下の通り処理されます:
CurrentWindow = 0;
GrantedUnits = 0;
CurrentWindow=0。 GrantedUnits=0。
NOTE: This operator may only flow on an independent pacing indication (may NOT be piggy-backed).
以下に注意してください。 このオペレータは、指示(背負われないかもしれない)に歩調を合わせながら、独立者を流れるだけであるかもしれません。
NOTE: After sending this operator, the only legal subsequent operator is Increment Window.
以下に注意してください。 このオペレータを送った後に、唯一の法的なその後のオペレータがIncrement Windowです。
8.3.5 Halve Window Operator
8.3.5 ウィンドウオペレータを半分にしてください。
This operator shall be processed as follows:
このオペレータは以下の通り処理されるものとします:
IF CurrentWindow > 1 THEN
CurrentWindow = CurrentWindow / 2
ENDIF
GrantedUnits += CurrentWindow
CurrentWindow>1の当時のCurrentWindowがCurrentWindow / 2ENDIF GrantedUnits+=CurrentWindowと等しいなら
Note: The divide by two operation is an unsigned integer divide (round down) or bit shift right operation.
以下に注意してください。 2操作による分水嶺は、符号のない整数分水嶺(概数に切り下げ)かビットシフト右作用です。
8.4 Acknowledging a Flow Control Operator
8.4 フロー制御オペレータを承認すること。
Each sender must acknowledge each FCIND with an FCACK which is piggy-backed on the next frame in the opposite direction in all cases except the Reset Window Operator.
各送付者はReset Window Operator以外のすべてのケースの逆方向の隣のフレームの上に背負われるFCACKと各FCINDを承認しなければなりません。
Wells & Bartky [Page 80] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[80ページ]RFC1795データ・リンク
The receiver may have no more than one unacknowledged FCIND outstanding at any time with one exception: A Reset Window Operator may be sent while another FCIND is pending acknowledgment.
受信機には、いつでも未払いの1不承認のFCINDがただ1つを例外としてあるかもしれません: 別のFCINDが未定の承認である間、Reset Window Operatorを送るかもしれません。
NOTE: The FCI and FCO bits of the FCACK are used independently by the flow in the opposite direction
以下に注意してください。 FCACKのFCIとFCOビットは逆方向の流れによって独自に使用されます。
8.4.1 Acknowledging a Reset Window Operator
8.4.1 リセットウィンドウオペレータを承認すること。
Since this operator revokes all previously granted units, the sender must acknowledge this FCIND using an IFCACK (Independent Flow Control Acknowledgment). This is the only case where IFCACK is used.
このオペレータがすべての以前に与えられたユニットを取り消すので、送付者はIFCACK(独立しているFlow Control Acknowledgment)を使用することでこのFCINDを承認しなければなりません。 これはIFCACKが使用されている唯一のそうです。
Should a sender receive a non-reset FCIND followed by a Reset Window FCIND before acknowledging the first, it only acknowledges the Reset Window.
送付者が1番目を承認する前にReset Window FCINDによって続かれた非リセットFCINDを受け取るなら、それはReset Windowを承認するだけです。
NOTE: The FCI and FCO bits on these frames are used independently by the flow in the opposite direction.
以下に注意してください。 これらのフレームのFCIとFCOビットは逆方向の流れによって独自に使用されます。
8.5 Capabilities Exchange Initial Window Size
8.5の能力が初期のウィンドウサイズを交換します。
When two nodes establish a transport connection, they engage in a capabilities exchange (this is a requirement). Refer to the Capabilities Exchange section 7 for further details. The two nodes are required to exchange the following parameter:
2つのノードが輸送接続を確立すると、それらは能力交換に従事します(これは要件です)。 さらに詳しい明細についてはCapabilities Exchange部7を参照してください。 2つのノードが以下のパラメタを交換するのに必要です:
InitialWindowSize - This indicates to the partner what
the sending flow entity initializes
its CurrentWindow value to for each
multiplexed circuit subsequently
established on that transport
connection. This value must be
non-zero.
InitialWindowSize--これは、その輸送接続のときに次に確立されたそれぞれの多重送信されたサーキットのために送付流れ実体がCurrentWindow値を何に初期化するかをパートナーに示します。 この値は非ゼロでなければなりません。
8.6 Circuit Startup
8.6 サーキット始動
Process as follows:
以下の通り処理してください:
CurrentWindow = InitialWindowSize
GrantedUnits = 0
CurrentWindowはInitialWindowSize GrantedUnits=0と等しいです。
NOTE: The InitialWindow Size variable has a scope of one per DLSw transport connection, while CurrentWindow and Granted units are maintained on a per circuit basis. At circuit startup, a sender may not send data units until the receiver grants explicit permission with an FCIND message. This grant may be an independent FCIND message or the FCIND may be piggy-backed on any of the message types
以下に注意してください。 InitialWindow Size変数にはDLSw輸送接続あたり1つの範囲があります、CurrentWindowとGrantedユニットはサーキット基礎あたりのaで維持されますが。 サーキット始動では、受信機がFCINDメッセージがある明白な許可を与えるまで、送付者はデータ単位を送らないかもしれません。 この交付金は独立しているFCINDメッセージであるかもしれませんかFCINDがメッセージタイプのいずれでも背負われるかもしれません。
Wells & Bartky [Page 81] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[81ページ]RFC1795データ・リンク
listed in section 8.2.
セクション8.2では、記載されています。
8.7 Example Receiving Implementations
8.7 例の受信実現
The following two examples illustrate receiving implementations of varying degrees of complexity. These are not meant to be complete implementations but rather serve to illustrate the protocol.
以下の2つの例が、異なった度の複雑さの実現を受けながら、例証します。 完全な実現ですが、これらは、プロトコルを例証するのにむしろ役立つことになっていません。
NOTE: The examples are independent of the buffering model ( buffers may be deterministicly or statistically committed)
以下に注意してください。 例はバッファリングしているモデルから独立しています。(バッファは決定論的か統計的に遂行されるかもしれません)
NOTE: The examples assume a process model where each event processes to completion without being preempted by another event.
以下に注意してください。 例は各出来事が別の出来事によって先取りされないで完成に処理されるプロセス・モデルに就きます。
8.7.1 Fixed Pacing Example
8.7.1 固定ペースの例
Consider the following variables, in addition to InitialWindowSize and CurrentWindow and FCACKOwed:
InitialWindowSize、CurrentWindow、およびFCACKOwedに加えた以下の変数を考えてください:
GrantDelayed - Boolean
GrantedUnits - Outstanding Units
GrantDelayed--ブールGrantedUnits--傑出しているユニット
The following section describes how various events are processed in this example implementation:
以下のセクションは様々な出来事がこの例の実現でどう処理されるかを説明します:
8.7.1.1 Circuit Startup
8.7.1.1 サーキット始動
CurrentWindow = InitialWindowSize
FCACKOwed = FALSE
GrantDelayed = FALSE
GrantedUnits = 0
Repeat Window Operator
偽の偽のCurrentWindow=InitialWindowSize FCACKOwed=GrantDelayed=GrantedUnitsは0反復ウィンドウオペレータと等しいです。
8.7.1.2 Check Buffers Available
8.7.1.2 利用可能なバッファをチェックしてください。
Can my implementation afford to grant CurrentWindow just now?
私の実現にはちょうど今CurrentWindowを与える余裕がありますか?
8.7.1.3 Buffers Become Available
8.7.1.3 バッファは利用可能になります。
IF Check Buffers Available THEN
Send FCIND( Repeat Window)
GrantDelayed = FALSE
ELSE
Wait on buffers to become available (LIFO)
ENDIF
Check Buffers Available THEN Send FCIND(Windowを繰り返す)GrantDelayedが利用可能な(LIFO)ENDIFになるようにバッファの上でFALSE ELSE Waitと等しいなら
Wells & Bartky [Page 82] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[82ページ]RFC1795データ・リンク
8.7.1.4 Repeat Window Operator
8.7.1.4 ウィンドウオペレータを繰り返してください。
IF Check Buffers Available THEN
Send FCIND( Repeat Window)
ELSE
GrantDelayed = TRUE
Wait on buffers to become available (FIFO)
ENDIF
Check Buffers Available THEN Send FCIND(Windowを繰り返す)ELSE GrantDelayedが利用可能な(先入れ先出し法)ENDIFになるようにバッファの上でTRUE Waitと等しいなら
8.7.1.5 Send FCIND( operator)
8.7.1.5 FCINDを送ってください。(オペレータ)
GrantedUnits += CurrentWindow
FCACKOwed = TRUE
Encode and Transmit FCIND piggybacked or as IFCIND
GrantedUnits+=CurrentWindow FCACKOwedは背負われるか、IFCINDとしてのTRUE EncodeとTransmit FCINDと等しいです。
8.7.1.6 A Frame Arrives from Sender
8.7.1.6 フレームは送付者から届きます。
GrantedUnits--;
IF frame is FCACK THEN
IF FCACKOwed THEN
FCACKOwed = FALSE
ELSE
Protocol Violation
ENDIF
ENDIF
IF NOT GrantDelayed THEN
IF GrantedUnits <= CurrentWindow THEN
IF FCACKOwed THEN
Protocol Violation
ELSE
Repeat Window Operator
ENDIF
ENDIF
ENDIF
GrantedUnits--、。 GrantedUnits<がFCACKOwed THENプロトコルViolation ELSE Repeat Window Operator ENDIF ENDIF ENDIFであるならCurrentWindow THENと等しく、GrantDelayed THENでないならフレームがFALSE ELSEプロトコルFCACK THEN IF FCACKOwed THEN FCACKOwed=Violation ENDIF ENDIFであるなら
8.7.2 Adaptive Pacing Example
8.7.2 適応型のペースの例
The following example illustrates a receiving implementation that adjusts the window size and granted units based on buffer availability and transport utilization.
以下の例はウィンドウサイズを調整する受信実現とバッファの有用性と輸送利用に基づく与えられたユニットを例証します。
NOTE: This example ignores other factors which might compel the receiving implementation to adjust the window size (i.e., Outbound queue length, traffic priority, ...)
以下に注意してください。 この例は受信実現がウィンドウサイズを調整するのを強制するかもしれない他の要素を無視します。(すなわち、Outboundは長さ、交通優先権を列に並ばせます…)
Consider the following variables, in addition to InitialWindowSize, CurrentWindow and FCACKOwed:
InitialWindowSize、CurrentWindow、およびFCACKOwedに加えた以下の変数を考えてください:
Wells & Bartky [Page 83] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[83ページ]RFC1795データ・リンク
GrantDelayed - Boolean
GrantedUnits - Outstanding Units
GrantDelayed--ブールGrantedUnits--傑出しているユニット
8.7.2.1 Circuit Startup
8.7.2.1 サーキット始動
CurrentWindow = InitialWindowSize
FCACK = FALSE
GrantDelayed = FALSE
GrantedUnits = 0
Repeat Window Operator
偽の偽のCurrentWindow=InitialWindowSize FCACK=GrantDelayed=GrantedUnitsは0反復ウィンドウオペレータと等しいです。
8.7.2.2 Check Buffers Available ( X)
8.7.2.2 利用可能なバッファをチェックしてください。( X)
Can my implementation afford to grant X units just now?
私の実現にはちょうど今Xユニットを与える余裕がありますか?
8.7.2.3 Buffers Become Available
8.7.2.3 バッファは利用可能になります。
IF Check Buffers Available THEN
CurrentWindow--;
Send FCIND( Decrement Window)
GrantDelayed = FALSE
ELSE
Wait on buffers to become available (LIFO)
ENDIF
チェックが利用可能な当時のCurrentWindowをバッファリングするなら--。 利用可能な(LIFO)ENDIFになるようにFCIND(減少Window)GrantDelayed=FALSE ELSE Waitをバッファに送ってください。
8.7.2.4 Repeat Window Operator
8.7.2.4 ウィンドウオペレータを繰り返してください。
IF Check Buffers Available (CurrentWindow) THEN
Send FCIND( Repeat Window)
ELSE
GrantDelayed = TRUE
Wait on buffers to become available (FIFO)
ENDIF
Check Buffers Available(CurrentWindow)THEN Send FCIND(Windowを繰り返す)ELSE GrantDelayedが利用可能な(先入れ先出し法)ENDIFになるようにバッファの上でTRUE Waitと等しいなら
8.7.2.5 Increment Window Operator
8.7.2.5 増分のウィンドウオペレータ
IF Check Buffers Available ( CurrentWindow + 1) THEN
CurrentWindow++
Send FCIND( Increment Window)
ELSE
Repeat Window Operator
ENDIF
チェックが利用可能な(CurrentWindow+1)をバッファリングするなら、CurrentWindow++はFCIND(増分のウィンドウ)のほかの反復ウィンドウオペレータENDIFを送ります。
8.7.2.6 Send FCIND( operator)
8.7.2.6 FCINDを送ってください。(オペレータ)
FCACKOwed = TRUE
GrantedUnits += CurrentWindow
Encode and Transmit FCIND piggybacked or as IFCIND
FCACKOwedは背負われるか、IFCINDとしてのTRUE GrantedUnits+=CurrentWindow EncodeとTransmit FCINDと等しいです。
Wells & Bartky [Page 84] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[84ページ]RFC1795データ・リンク
8.7.2.7 An FCACK Arrives from Sender
8.7.2.7 FCACKは送付者から到着します。
GrantedUnits--;
IF NOT FCACKOwed THEN
Protocol Violation
ENDIF
FCACKOwed = FALSE;
IF NOT GrantDelayed THEN
IF GrantedUnits < CurrentWindow THEN
Increment Window Operator
ELSE IF GrantedUnits == CurrentWindow THEN
Repeat Window Operator
END
ENDIF
GrantedUnits--、。 そうでなければ、次に、FCACKOwedは違反ENDIF FCACKOwedについて= 虚偽で議定書の中で述べます。 次に、次に、GrantedUnits=CurrentWindowがウィンドウオペレータを繰り返すならGrantedUnits<CurrentWindowがほかにウィンドウオペレータを増加して、GrantDelayedでないなら、ENDIFを終わらせてください。
8.7.2.8 A Non-FCACK Frame Arrives from Sender
8.7.2.8 非FCACKフレームは送付者から届きます。
GrantedUnits--;
IF NOT GrantDelayed THEN
IF FCACKOwed THEN
IF GrantedUnits < CurrentWindow THEN
Protocol Violation
END
ELSE
IF GrantedUnits <= CurrentWindow THEN
Repeat Window Operator
ENDIF
ENDIF
ENDIF
GrantedUnits--、。 次に、GrantedUnits<CurrentWindowが違反について議定書の中で述べるならGrantedUnits<がCurrentWindowと等しいならそしてFCACKOwedがほかに終わって、GrantDelayedでないなら、ウィンドウオペレータENDIF ENDIF ENDIFを繰り返してください。
Wells & Bartky [Page 85] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[85ページ]RFC1795データ・リンク
8.8 Adaptive Pacing Example Flow Diagrams
8.8 適応型の歩き回っている例のフローチャート
8.8.1 Example Flows from the Above Implementation
8.8.1 上の実現からの例の流れ
The following diagram illustrates the use of adaptive pacing (use of Halve Window, and Reset operation are shown in subsequent diagrams).
以下のダイヤグラムは適応型のペース(操作がその後のダイヤグラムで示されるHalve Window、およびResetの使用)の使用を例証します。
-----SENDER----- ----RECEIVER----
Granted Window Window Granted
0 2 circuit established 2 0
2 2 <-------- FCIND(Rpt) 2 2
1 2 FCACK--------------> 2 1
4 3 <-------- FCIND(Inc) 3 4
3 3 FCACK--------------> 3 3
+- FCIND(Rpt) 3 6
2 3 DATA---|-----------> 3 5
1 3 DATA---|-----------> 3 4
4 3 <------+
3 3 FCACK--------------> 3 3
6 3 <-------- FCIND(Rpt) 3 6
5 3 FCACK--------------> 3 5
4 3 DATA---------------> 3 4
3 3 DATA---------------> 3 3
+- FCIND(Rpt) 3 6
2 3 DATA---|-----------> 3 5
1 3 DATA---|-----------> 3 4
0 3 DATA---|-----------> 3 3
3 3 <------+
2 3 FCACK--------------> 3 2
6 4 <-------- FCIND(Inc) 4 6
5 4 FCACK--------------> 4 5
4 4 DATA---------------> 4 4
Waiting on Buffer
+- FCIND(Dec) 3 7
3 4 DATA---|-----------> 3 6
2 4 DATA---|-----------> 3 5
1 4 DATA---|-----------> 3 4
0 4 DATA---|-----------> 3 3
3 3 <------+
2 3 FCACK--------------> 3 2
Waiting on Buffer
+- FCIND(Dec) 2 4
1 3 DATA---|-----------> 2 3
0 3 DATA---|-----------> 2 2
2 2 <------+
1 2 FCACK--------------> 2 1
4 3 <-------- FCIND(Inc) 3 4
3 3 FCACK--------------> 3 3
-----送付者----- ----受信機---- 与えられたWindow Window Granted0 2サーキットは2 0 2 2<を設立しました。-------- FCIND(Rpt)2 2 1 2FCACK-------------->2 1 4 3<。-------- FCIND(Inc)3 4 3 3FCACK-------------->3 3+ FCIND(Rpt)3 6 2 3データ---|----------->3 5 1 3データ---|----------->3 4 4 3<。------+ 3 3FCACK-------------->3 3 6 3<。-------- FCIND(Rpt)3 6 5 3FCACK-------------->3 5 4 3データ--------------->3 4 3 3データ--------------->3 3+ FCIND(Rpt)3 6 2 3データ---|----------->3 5 1 3データ---|----------->3 4 0 3データ---|----------->3 3 3 3<。------+ 2 3FCACK-------------->3 2 6 4<。-------- FCIND(Inc)4 6 5 4FCACK-------------->4 5 4 4データ---------------+FCIND(12月)3 7 3 4のバッファデータで待っている>4 4---|----------->3 6 2 4データ---|----------->3 5 1 4データ---|----------->3 4 0 4データ---|----------->3 3 3 3<。------+ 2 3FCACK--------------+FCIND(12月)2 4 1 3のバッファデータで待っている>3 2---|----------->2 3 0 3データ---|----------->2 2 2 2<。------+ 1 2FCACK-------------->2 1 4 3<。-------- FCIND(Inc)3 4 3 3FCACK-------------->3 3
Wells & Bartky [Page 86] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[86ページ]RFC1795データ・リンク
6 3 <-------- FCIND(Rpt) 3 6
5 3 FCACK--------------> 3 5
4 3 DATA---------------> 3 4
3 3 DATA---------------> 3 3
6 3 <-------- FCIND(Rpt) 3 6
6 3<。-------- FCIND(Rpt)3 6 5 3FCACK-------------->3 5 4 3データ--------------->3 4 3 3データ--------------->3 3 6 3<。-------- FCIND(Rpt)3 6
8.8.2 Example Halve Window Flow
8.8.2 例は窓の流動を半分にします。
The following flow illustrates the use of the Halve Window Operator:
以下の流れはHalve Window Operatorの使用を例証します:
-----SENDER----- ----RECEIVER----
Granted Window Window Granted
0 2 circuit established 2 0
2 2 <-------- FCIND(Rpt) 2 2
1 2 FCACK--------------> 2 1
4 3 <-------- FCIND(Inc) 3 4
3 3 FCACK--------------> 3 3
Resource Shortage
2 3 DATA---------------> 1 2
1 3 DATA---------------> 1 1
0 3 DATA---------------> 1 0
1 1 <-------- FCIND(Hlv) 1 1
0 1 FCACK--------------> 1 0
-----送付者----- ----受信機---- 与えられたWindow Window Granted0 2サーキットは2 0 2 2<を設立しました。-------- FCIND(Rpt)2 2 1 2FCACK-------------->2 1 4 3<。-------- FCIND(Inc)3 4 3 3FCACK-------------->3 3リソース不足2 3データ--------------->1 2 1 3データ--------------->1 1 0 3データ--------------->1 0 1 1<。-------- FCIND(Hlv)1 1 0 1FCACK-------------->1 0
NOTE: The Halve Window Operator could have been sent before the granted units fell to zero. The implementer may make a choice based on the severity of the condition.
以下に注意してください。 与えられたユニットがゼロに落ちる前にHalve Window Operatorを送ったかもしれません。 implementerは状態の厳しさに基づく選択をするかもしれません。
8.8.3 Example Reset Window Flows
8.8.3 例のリセット窓の流れ
The following flow diagram illustrates the ResetWindow operation if the receiver has no FCIND outstanding.
受信機に未払いのどんなFCINDもないなら、以下のフローチャートはResetWindow操作を例証します。
-----SENDER----- ----RECEIVER----
Granted Window Window Granted
0 2 circuit established 2 0
2 2 <-------- FCIND(Rpt) 2 2
1 2 FCACK--------------> 2 1
4 3 <-------- FCIND(Inc) 3 4
3 3 FCACK--------------> 3 3
+- FCIND(Rpt) 3 6
2 3 DATA---|-----------> 3 5
1 3 DATA---|-----------> 3 4
4 3 <------+
3 3 FCACK--------------> 3 3
6 3 <-------- FCIND(Rpt) 3 6
5 3 FCACK--------------> 3 5
Resource shortage!
-----送付者----- ----受信機---- 与えられたWindow Window Granted0 2サーキットは2 0 2 2<を設立しました。-------- FCIND(Rpt)2 2 1 2FCACK-------------->2 1 4 3<。-------- FCIND(Inc)3 4 3 3FCACK-------------->3 3+ FCIND(Rpt)3 6 2 3データ---|----------->3 5 1 3データ---|----------->3 4 4 3<。------+ 3 3FCACK-------------->3 3 6 3<。-------- FCIND(Rpt)3 6 5 3FCACK-------------->3 5リソース不足!
Wells & Bartky [Page 87] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[87ページ]RFC1795データ・リンク
0 0 <-------- FCIND(Rst) 0 5 (note still
committed)
0 0 IFCACK-------------> 0 0
Condition eases
1 1 <-------- FCIND(Inc) 1 1
0 1 FCACK--------------> 1 0
2 2 <-------- FCIND(Inc) 2 2
1 2 FCACK--------------> 3 4
0 0<。-------- FCIND(Rst)0 5(まだ遂行されていた注意)0 0IFCACK------------->0 0状態は1 1<をゆるめます。-------- FCIND(Inc)1 1 0 1FCACK-------------->1 0 2 2<。-------- FCIND(Inc)2 2 1 2FCACK-------------->3 4
The next two flows illustrate the Reset Window operation if the receiver has an outstanding FCIND.
受信機に傑出しているFCINDがあるなら、次の2回の流れがReset Window操作を例証します。
-----SENDER----- ----RECEIVER----
Granted Window Window Granted
0 2 circuit established 2 0
2 2 <-------- FCIND(Rpt) 2 2
1 2 FCACK--------------> 2 1
4 3 <-------- FCIND(Inc) 3 4
3 3 FCACK--------------> 3 3
+- FCIND(Rpt) 3 6
2 3 DATA---|-----------> 3 5
| Resource shortage!
|+-FCIND(Rst) 0 5
1 3 DATA---||----------> 0 4
4 3 <------+|
3 3 FCACK---+----------> 0 3 (Not IFCACK!)
2 3 DATA----|----------> 0 2
0 0 <-------+
0 0 IFCACK-------------> 0 0
Condition eases
1 1 <-------- FCIND(Inc) 1 1
0 1 FCACK--------------> 1 0
2 2 <-------- FCIND(Inc) 2 2
1 2 FCACK--------------> 3 4
-----送付者----- ----受信機---- 与えられたWindow Window Granted0 2サーキットは2 0 2 2<を設立しました。-------- FCIND(Rpt)2 2 1 2FCACK-------------->2 1 4 3<。-------- FCIND(Inc)3 4 3 3FCACK-------------->3 3+ FCIND(Rpt)3 6 2 3データ---|----------->3 5| リソース不足! |+-FCIND(Rst)0 5 1 3データ---||---------->0 4 4 3<。------+| 3 3FCACK---+---------->0 3(IFCACKでない!) 2 3のデータ----|---------->0 2 0 0<。-------+ 0 0IFCACK------------->0 0状態は1 1<をゆるめます。-------- FCIND(Inc)1 1 0 1FCACK-------------->1 0 2 2<。-------- FCIND(Inc)2 2 1 2FCACK-------------->3 4
-----SENDER----- ----RECEIVER----
Granted Window Window Granted
0 2 circuit established 2 0
2 2 <-------- FCIND(Rpt) 2 2
1 2 FCACK--------------> 2 1
4 3 <-------- FCIND(Inc) 3 4
3 3 FCACK--------------> 3 3
+- FCIND(Rpt) 3 6
2 3 DATA---|-----------> 3 5
| Resource shortage!
|+-FCIND(Rst) 0 5
1 3 DATA---||----------> 0 4
4 3 <------+|
-----送付者----- ----受信機---- 与えられたWindow Window Granted0 2サーキットは2 0 2 2<を設立しました。-------- FCIND(Rpt)2 2 1 2FCACK-------------->2 1 4 3<。-------- FCIND(Inc)3 4 3 3FCACK-------------->3 3+ FCIND(Rpt)3 6 2 3データ---|----------->3 5| リソース不足! |+-FCIND(Rst)0 5 1 3データ---||---------->0 4 4 3<。------+|
Wells & Bartky [Page 88] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[88ページ]RFC1795データ・リンク
0 0 <-------+
0 0 IFCACK-------------> 0 0
Condition eases
1 1 <-------- FCIND(Inc) 1 1
0 1 FCACK--------------> 1 0
2 2 <-------- FCIND(Inc) 2 2
1 2 FCACK--------------> 3 4
0 0<。-------+ 0 0IFCACK------------->0 0状態は1 1<をゆるめます。-------- FCIND(Inc)1 1 0 1FCACK-------------->1 0 2 2<。-------- FCIND(Inc)2 2 1 2FCACK-------------->3 4
8.9 Other Considerations
8.9 他の問題
8.9.1 Protocol Violations
8.9.1 プロトコル違反
The following events are considered protocol violations:
以下の出来事はプロトコル違反であると考えられます:
1. Sender exceeds granted units or does not acknowledge FCIND on
first frame after its receipt (the receiver can not discern the
difference between the two).
1. 送付者は、与えられたユニットを超えているか、または領収書の後に最初のフレームの上のFCINDを承認しません(受信機は2の違いについて明察できません)。
2. Receiver does not follow a Reset Window Operator with an Increment
Window Operator.
2. 受信機はIncrement Window Operatorと共にReset Window Operatorに続きません。
3. Receiver has two unacknowledged FCINDs ( other than Reset Window)
outstanding.
3. 受信機には、未払いの2不承認のFCINDs(Reset Windowを除いた)があります。
4. Receiver sends Decrement Window Operator with a window size of one.
4. 受信機は1のウィンドウサイズがあるDecrement Window Operatorを送ります。
5. Receiver attempts to increment the window size beyond 0xFFFF.
5. 受信機は、0xFFFFを超えてウィンドウサイズを増加するのを試みます。
Actions taken in response to protocol violations are left to the implementation of the node which discovers the violation. If an implementation chooses to take down the circuit on which the violation occurred, HALT_DL is the appropriate action.
プロトコル違反に対応して取られた行動は違反を発見するノードの実現に残されます。 実現が、違反が起こったサーキットを降ろすのを選ぶなら、HALT_DLは適切な行動です。
Acknowledgments
承認
Original RFC 1434 Authors:
オリジナルのRFC1434作者:
Roy C. Dixon, IBM
David M. Kushi, IBM
ロイ・C.ディクソン、IBMデヴィッドM.Kushi、IBM
Chair of APPN Implementers Workshop Data Link Switching Related Interest Group:
APPN Implementersワークショップデータ・リンクの切り換えの議長は営利団体を関係づけました:
Louise Herndon Wells, Internetworking Technology Institute
ルイーズ・ハーンドンウェルズ、インターネットワーキング技術研究所
Wells & Bartky [Page 89] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[89ページ]RFC1795データ・リンク
Working Group Chairs (and significant contributors to this document):
作業部会Chairs(そして、このドキュメントへの重要な寄稿者):
Connect/Disconnect (State Machines): Steve Klein, IBM
Capabilities Exchange: Wayne Clark, Cisco Systems
Flow Control (Adaptive Pacing): Shannon Nix, Metaplex
Priority/Class of Service: Gene Cox, IBM
(州のマシン)を接続するか、または外してください: スティーブクライン、IBMの能力交換: ウェイン・クラーク、シスコシステムズフロー制御(適応型のペース): シャノンNix、サービスのMetaplexの優先権/クラス: 遺伝子コックス、IBM
Other significant contributors:
他の重要な貢献者:
Peter Gayek, IBM
Paul Brittain, Data Connection Limited
ピーターGayek、IBMポールBrittain、接続が制限したデータ
References
参照
1) ISO 8802-2/IEEE Std 802.2 International Standard, Information
Processing Systems, Local Area Networks, Part 2: Logical Link
Control, December 31, 1989.
1) ISO8802-2/IEEE Std802.2国際規格、情報処理システム、ローカル・エリア・ネットワーク、第2部: 1989年12月31日の論理的なリンク制御。
2) IBM LAN Technical Reference IEEE 802.2 and NETBIOS Application
Program Interfaces SC30-3587-00, December 1993.
2) IBMのLANの技術的な参照IEEE802.2とNETBIOS適用業務プログラム・インタフェースSC30-3587-00、1993年12月。
3) ISO/IEC DIS 10038 DAM 2, MAC Bridging, Source Routing Supplement,
December 1991.
3) ISO/IECは1991年12月に10038ダム2、MACの橋を架けるソースルート設定補足をけなします。
4) ISO 8802-2/IEEE Std 802.1D International Standard, Information
Processing Systems, Local Area Networks, Part 2: MAC layer
Bridging.
4) ISO8802-2/IEEE Std 802.1D国際規格、情報処理システム、ローカル・エリア・ネットワーク、第2部: MACはBridgingを層にします。
Wells & Bartky [Page 90] RFC 1795 Data Link Switching April 1995
1995年4月に切り替わるウェルズとBartky[90ページ]RFC1795データ・リンク
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Chair's Address
議長のアドレス
Louise Wells Internetwork Technology Institute 2021 Stratford Dr. Milpitas, CA 95035
ミルピタス、ルイーズウェルズインターネットワーク技術研究所2021ストラットフォード博士カリフォルニア 95035
EMail: lhwells@cup.portal.com
メール: lhwells@cup.portal.com
Editor's Address
エディタのアドレス
Alan K. Bartky Manager of Technology Sync Research Inc. 7 Studebaker Irvine, CA 91728-2013
株式会社7スチュードベーカー・アーバイン、技術同時性Researchカリフォルニア91728-2013のアランK.Bartkyマネージャ
Phone: 1-714-588-2070 EMail: alan@sync.com
以下に電話をしてください。 1-714-588-2070 メールしてください: alan@sync.com
Note: Any questions or comments relative to the contents of this RFC should be sent to the following Internet address: aiw-dlsw@networking.raleigh.ibm.com.
以下に注意してください。 このRFCのコンテンツに比例したどんな質問やコメントも以下のインターネット・アドレスに送るべきです: aiw-dlsw@networking.raleigh.ibm.com 。
This address will be used to coordinate the handling of responses.
このアドレスは、応答の取り扱いを調整するのに使用されるでしょう。
NOTE 1: This is a widely subscribed mailing list and messages sent to
this address will be sent to all members of the DLSw mailing
list. For specific questions relating to subscribing to the
AIW and any of it's working groups send email to:
appn@vnet.ibm.com
注意1: これは広く申し込まれたメーリングリストです、そして、このアドレスに送られたメッセージをDLSwメーリングリストのすべてのメンバーに送るでしょう。 AIWに加入して、それのどれかに関連するのが、ワーキンググループであるという具体的な質問には、メールを以下に送ってください。 appn@vnet.ibm.com
Information regarding all of the AIW working groups and the
work they are producing can be obtained by copying, via
anonymous ftp, the file aiwinfo.psbin or aiwinfo.txt from the
Internet host networking.raleigh.ibm.com, located in
directory aiw.
コピーすることによって、AIWワーキンググループのすべてに関する情報とそれらが作り出している仕事を得ることができます、ディレクトリaiwに位置するインターネット・ホストnetworking.raleigh.ibm.comからのファイルのアノニマスFTP、aiwinfo.psbinまたはaiwinfo.txtを通して。
NOTE 2: These mailing lists and addresses are subject to change.
注意2: メーリングリストとアドレスを条件としているこれらが変化します。
Wells & Bartky [Page 91]
ウェルズとBartky[91ページ]
一覧
スポンサーリンク
