RFC2106 日本語訳
2106 Data Link Switching Remote Access Protocol. S. Chiang, J. Lee, H.Yasuda. February 1997. (Format: TXT=40819 bytes) (Obsoleted by RFC2114) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Chiang
Request for Comments: 2106 J. Lee
Category: Informational Cisco Systems, Inc.
H. Yasuda
Mitsubishi Electric Corp.
February 1997
コメントを求めるワーキンググループS.チャン要求をネットワークでつないでください: 2106年のJ.リーカテゴリ: 情報のシスコシステムズInc.H.安田三菱電気社の1997年2月
Data Link Switching Remote Access Protocol
データ・リンクの切り換えのリモートアクセス・プロトコル
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 memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/ NetBIOS traffic over TCP sessions. Any questions or comments should be sent to drap@cisco.com.
このメモはTCPセッションの間、SNA/NetBIOSトラフィックを輸送するのにワークステーションとルータの間で使用されるData Link Switching Remote Accessプロトコルについて説明します。 どんな質問やコメントも drap@cisco.com に送るべきです。
1. Introduction
1. 序論
Since the Data Link Switching Protocol, RFC 1795, was published, some software vendors have begun implementing DLSw on workstations. The implementation of DLSw on a large number of workstations raises several important issues that must be addressed. Scalability is the major concern. For example, the number of TCP sessions to the DLSw router increases in direct proportion to the number of workstations added. Another concern is efficiency. Since DLSw is a switch-to- switch protocol, it is not efficient when implemented on workstations.
Data Link Switchingプロトコル(RFC1795)が発表されて以来、いくつかのソフトウェアベンダーがワークステーションの上でDLSwを実装し始めました。 多くのワークステーションの上のDLSwの実装は扱わなければならないいくつかの切迫した課題を提起します。 スケーラビリティは主要な関心事です。 例えば、DLSwルータへのTCPセッションの数は加えられたワークステーションの数に直接比例して増加します。 別の関心は効率です。 DLSwがスイッチからスイッチへのプロトコルであるので、ワークステーションの上で実装される場合、それは効率的ではありません。
DRAP addresses the above issues. It introduces a hierarchical structure to resolve the scalability problems. All workstations are clients to the router (server) rather than peers to the router. This creates a client/server model. It also provides a more efficient protocol between the workstation (client) and the router (server).
DRAPは上記の問題を扱います。 それは、スケーラビリティ問題を解決するために階層構造を導入します。すべてのワークステーションがルータへの同輩よりむしろルータ(サーバ)へのクライアントです。 これはクライアント/サーバモデルを創造します。 また、それはワークステーション(クライアント)とルータ(サーバ)の間により効率的なプロトコルを提供します。
Chiang, et. al. Informational [Page 1] RFC 2106 DLSRAP February 1997
etチャン、アル。 [1ページ]情報のRFC2106DLSRAP1997年2月
2. Overview
2. 概要
2.1. DRAP Client/Server Model
2.1. DRAPクライアント/サーバモデル
+-----------+ +-----------+ +---------+
| Mainframe | | IP Router +- ppp -+ DLSw |
+--+--------+ +-----+-----+ | Work |
| | | Station |
| | +---------+
+--+--+ +-------------+ |
| FEP +- TR -+ DLSw Router +-- IP Backbone
+-----+ +-------------+ |
|
|
+-----------+ +---------+
| IP Router +- ppp -+ DLSw |
+-----+-----+ | Work |
| Station |
+---------+
+-----------+ +-----------+ +---------+ | メインフレーム| | IP Router+ ppp-+DLSw| +--+--------+ +-----+-----+ | 仕事| | | | 駅| | | +---------+ +--+--+ +-------------+ | | FEP+ TR-+DLSwルータ+--IPバックボーン+-----+ +-------------+ | | | +-----------+ +---------+ | IP Router+ ppp-+DLSw| +-----+-----+ | 仕事| | 駅| +---------+
| DLSw Session |
+-------------------------------+
Figure 2-1. Running DLSw on a large number of workstations creates a
scalability problem.
| DLSwセッション| +-------------------------------+ 図2-1。 多くのワークステーションの上の実行しているDLSwはスケーラビリティ問題を生じさせます。
Figure 2-1 shows a typical DLSw implementation on a workstation. The workstations are connected to the central site DLSw router over the IP network. As the network grows, scalability will become an issue as the number of TCP sessions increases due to the growing number of workstations.
図2-1はワークステーションで典型的なDLSw実装を示しています。 ワークステーションはIPネットワークの上で中央のサイトDLSwルータに接続されます。 ネットワークが成長するとき、TCPセッションの数がワークステーションの増加している数のため増加するのに応じて、スケーラビリティは問題になるでしょう。
Chiang, et. al. Informational [Page 2] RFC 2106 DLSRAP February 1997
etチャン、アル。 [2ページ]情報のRFC2106DLSRAP1997年2月
+-----------+ +-------+
+-----------+ | DLSw/DRAP | | DRAP |
| Mainframe | | Router +- ppp -+ Client|
+--+--------+ +-----+-----+ +-------+
| |
| |
+--+--+ +-------------+ |
| FEP +- TR -+ DLSw Router +-- IP Backbone
+-----+ +-------------+ |
|
|
+-----------+ +-------+
| DLSw/DRAP | | DRAP |
| Router +- ppp -+ Client|
+-----+-----+ +-------+
+-----------+ +-------+ +-----------+ | DLSw/DRAP| | DRAP| | メインフレーム| | ルータ、+ppp-+クライアント| +--+--------+ +-----+-----+ +-------+ | | | | +--+--+ +-------------+ | | FEP+ TR-+DLSwルータ+--IPバックボーン+-----+ +-------------+ | | | +-----------+ +-------+ | DLSw/DRAP| | DRAP| | ルータ、+ppp-+クライアント| +-----+-----+ +-------+
| DLSw Session | | DRAP Session |
+--------------+ +--------------+
Figure 2-2. DLSw Remote Access Protocol solves the scalability problem.
| DLSwセッション| | DRAPセッション| +--------------+ +--------------+ 図2-2。 DLSw Remote Accessプロトコルはスケーラビリティ問題を解決します。
In a large network, DRAP addresses the scalability problem by significantly reducing the number of peers that connect to the central site router. The workstations (DRAP client) and the router (DRAP server) behave in a Client/Server relationship. Workstations are attached to a DRAP server. A DRAP server has a single peer connection to the central site router.
大きいネットワークでは、DRAPは、中央のサイトルータに接続する同輩の数をかなり減少させることによって、そのスケーラビリティ問題を訴えます。 ワークステーション(DRAPクライアント)とルータ(DRAPサーバ)はClient/サーバ関係で振る舞います。 ワークステーションはDRAPサーバに取り付けられます。DRAPサーバには、中央のサイトルータには単独の同輩接続があります。
2.2. Dynamic Address Resolution
2.2. ダイナミックなアドレス解決
In a DLSw network, each workstation needs a MAC address to communicate with a FEP attached to a LAN. When DLSw is implemented on a workstation, it does not always have a MAC address defined. For example, when a workstation connects to a router through a modem via PPP, it only consists of an IP address. In this case, the user must define a virtual MAC address. This is administratively intensive since each workstation must have an unique MAC address.
DLSwネットワークでは、各ワークステーションは、LANに取り付けられたFEPとコミュニケートするためにMACアドレスを必要とします。 DLSwがワークステーションの上で実装されるとき、それには、定義されたMACアドレスがいつもあるというわけではありません。 ワークステーションがPPPを通してモデムを通してルータに接続するときだけ、例えば、それはIPアドレスから成ります。 この場合、ユーザは仮想のMACアドレスを定義しなければなりません。 各ワークステーションにはユニークなMACアドレスがなければならないので、これは行政上徹底的です。
DRAP uses the Dynamic Address Resolution protocol to solve this problem. The Dynamic Address Resolution protocol permits the server to dynamically assign a MAC address to a client without complex configuration.
DRAPは、この問題を解決するのにDynamic Address Resolutionプロトコルを使用します。 Dynamic Address Resolutionプロトコルは、サーバが複雑な構成なしでMACアドレスをクライアントにダイナミックに割り当てることを許可します。
For a client to initiate a session to a server, the workstation sends a direct request to the server. The request contains the destination MAC address and the destination SAP. The workstation can either specify its own MAC address, or request the server to assign one to it. The server's IP address must be pre-configured on the workstation. If IP addresses are configured for multiple servers at a
クライアントがサーバにセッションを開始するように、ワークステーションはダイレクト要求をサーバに送ります。要求は送付先MACアドレスと目的地SAPを含みます。 ワークステーションは、それ自身のMACアドレスを指定するか、または1つをそれに割り当てるようサーバに要求できます。 ワークステーションの上でサーバのIPアドレスをあらかじめ設定しなければなりません。 IPアドレスがaの複数のサーバのために構成されるなら
Chiang, et. al. Informational [Page 3] RFC 2106 DLSRAP February 1997
etチャン、アル。 [3ページ]情報のRFC2106DLSRAP1997年2月
workstation, the request can be sent to these servers and the first one to respond will be used.
ワークステーション、要求をこれらのサーバに送ることができます、そして、応じる最初のものを使用するでしょう。
For a server to initiate a session to a client, the server sends a directed request to the workstation. The workstation must pre- register its MAC address at the server. This can be done either by configuration on the server or registration at the server (both MAC addresses and IP addresses will be registered).
サーバがクライアントにセッションを開始するように、サーバは指示された要求をワークステーションに送ります。 ワークステーションはサーバでMACアドレスをあらかじめ登録しなければなりません。サーバでの構成かサーバにおける登録でこれができます(MACアドレスとIPアドレスの両方が登録されるでしょう)。
2.3. TCP Connection
2.3. TCP接続
The transport used between the client and the server is TCP. Before a TCP session is established between the client and the server, no message can be sent. The default parameters associated with the TCP connections between the client and the server are as follows:
クライアントとサーバの間で使用される輸送はTCPです。 クライアントとサーバの間でTCPセッションを確立する前に、メッセージを全く送ることができません。 クライアントとサーバとのTCP関係に関連しているデフォルトパラメタは以下の通りです:
Socket Family AF_INET (Internet protocols)
Socket Type SOCK_STREAM (stream socket)
Port Number 1973
ソケットFamily AF_INET(インターネットプロトコル)ソケットType SOCK_STREAM(ストリームソケット)はNumber1973を移植します。
There is only one TCP connection between the client and the server. It is used for both read and write operations.
クライアントとサーバとの1つのTCP関係しかありません。それは読まれた両方に使用されます、そして、操作を書いてください。
3. DRAP Format
3. DRAP形式
3.1. General Frame Format
3.1. 一般フレーム形式
The General format of the DRAP frame is as follows:
DRAPフレームの一般形式は以下の通りです:
+-------------+-----------+-----------+
| DRAP Header | DRAP Data | User Data |
+-------------+-----------+-----------+
Figure 3-1. DRAP Frame Format
+-------------+-----------+-----------+ | DRAPヘッダー| DRAPデータ| 利用者データ| +-------------+-----------+-----------+ 図3-1。 DRAPフレーム形式
The DRAP protocol is contained in the DRAP header, which is common to all frames passed between the DRAP client and the server. This header is 4 bytes long. The next section will explain the details.
DRAPプロトコルはDRAPヘッダーに含まれています。(ヘッダーはDRAPクライアントとサーバの間を通り過ぎられたすべてのフレームに共通です)。このヘッダーは4バイト長です。 次のセクションは詳細について説明するでしょう。
The next part is the DRAP Data. The structure and the size are based on the type of messages carried in the DRAP frame. The DRAP data is used to process the frame, but it is optional.
次の部分はDRAP Dataです。 構造とサイズはDRAPフレームで伝えられるメッセージのタイプに基づいています。 DRAPデータはフレームを処理するのに使用されますが、それは任意です。
The third part of the frame is the user data, which is sent by the local system to the remote system. The size of this block is variable and is included in the frame only when there is data to be sent to the remote system.
フレームの3番目の一部が利用者データです。(その利用者データはローカルシステムによってリモートシステムに送られます)。 このブロックのサイズは、可変であり、リモートシステムに送られるデータがあるときだけ、フレームに含まれています。
Chiang, et. al. Informational [Page 4] RFC 2106 DLSRAP February 1997
etチャン、アル。 [4ページ]情報のRFC2106DLSRAP1997年2月
3.2. Header Format
3.2. ヘッダー形式
The DRAP header is used to identify the message type and the length of the frame. This is a general purpose header used for each frame that is passed between the DRAP server and the client. More information is needed for frames like CAN_U_REACH and I_CAN_REACH, therefore, it is passed to the peer as DRAP data. The structure of the DRAP data depends on the type of frames, and will be discussed in detail in later sections.
DRAPヘッダーは、メッセージタイプとフレームの長さを特定するのに使用されます。 これはDRAPサーバとクライアントの間を通り過ぎられる各フレームに使用される汎用のヘッダーです。 詳しい情報が_CAN U_REACHと_I_CAN REACHのようなフレームに必要です、したがって、それはDRAPデータとして同輩に渡されます。 DRAPデータの構造について、フレームのタイプに頼っていて、後のセクションで詳細に議論するでしょう。
The DRAP Header is given below:
DRAP Headerを以下に与えます:
+-------------------------------------------+
| DRAP Packet Header (Each row is one byte) |
+===========================================+
0 | Protocol ID / Version Number |
+-------------------------------------------+
1 | Message Type |
+-------------------------------------------+
2 | Packet Length |
+ - - - - - - - - - - - - - - - - - - - - - +
3 | |
+-------------------------------------------+
Figure 3-2. DRAP Header Format
+-------------------------------------------+ | DRAP Packet Header(各行は1バイトです)| +===========================================+ 0 | プロトコルID/バージョン番号| +-------------------------------------------+ 1 | メッセージタイプ| +-------------------------------------------+ 2 | パケット長| + - - - - - - - - - - - - - - - - - - - - - + 3 | | +-------------------------------------------+ 図3-2。 DRAPヘッダー形式
o The Protocol ID uses the first 4 bits of this field and is set to
"1000".
o Protocol IDは、この分野の最初の4ビットを使用して、「1000」に設定されます。
o The Version Number uses the next 4 bits in this field and is set
to "0001".
o バージョンNumberはこの分野で次の4ビットを使用して、「1インチ」に用意ができています。
o The message type is the DRAP message type.
o メッセージタイプはDRAPメッセージタイプです。
o The Total Packet length is the length of the packet including the
DRAP header, DRAP data and User Data. The minimum size of the
packet is 4, which is the length of the header.
o Total Packetの長さはDRAPヘッダー、DRAPデータ、およびUser Dataを含むパケットの長さです。 パケットの最小規模は4です。(その4はヘッダーの長さです)。
3.3. DRAP Messages
3.3. DRAPメッセージ
Most of the Drap frames are based on the existing DLSw frames and have the same names. The information in the corresponding DRAP and DLSw frames may differ; but the functionalities are the same. Thus the DLSw State Machine is used to handle these DRAP frames. Some new DRAP frames were created to handle special DRAP functions. For example, the new DRAP frames, I_CANNOT_REACH and START_DL_FAILED provide negative acknowledgment. The DLSw frames not needed for DRAP, are dropped.
Drapフレームの大部分は、既存のDLSwフレームに基づいていて、同じ名前を持っています。 対応するDRAPとDLSwフレームの情報は異なるかもしれません。 しかし、機能性は同じです。 したがって、DLSw州Machineは、これらのDRAPフレームを扱うのに使用されます。 いくつかの新しいDRAPフレームが、特別なDRAP機能を扱うために作成されました。 例えば、新しいDRAPフレーム、I_は_DL_FAILEDが否定応答を供給するREACHとSTART_がそうしません。 DRAPに必要でないDLSwフレーム、下げられます。
Chiang, et. al. Informational [Page 5] RFC 2106 DLSRAP February 1997
etチャン、アル。 [5ページ]情報のRFC2106DLSRAP1997年2月
The following table lists and describes all available DRAP messages:
以下のテーブルは、すべての利用可能なDRAPメッセージをリストアップして、説明します:
DRAP Frame Name Code Function --------------- ---- -------- CAN_U_REACH 0x01 Find if the station given is reachable I_CAN_REACH 0x02 Positive response to CAN_U_REACH I_CANNOT_REACH 0x03 Negative response to CAN_U_REACH START_DL 0x04 Setup session for given addresses DL_STARTED 0x05 Session Started START_DL_FAILED 0x06 Session Start failed XID_FRAME 0x07 XID Frame CONTACT_STN 0x08 Contact destination to establish SABME STN_CONTACTED 0x09 Station contacted - SABME mode set DATA_FRAME 0x0A Connectionless Data Frame for a link INFO_FRAME 0x0B Connection oriented I-Frame HALT_DL 0x0C Halt Data Link session HALT_DL_NOACK 0x0D Halt Data Link session without ack DL_HALTED 0x0E Session Halted FCM_FRAME 0x0F Data Link Session Flow Control Message DGRM_FRAME 0x11 Connectionless Datagram Frame for a circuit CAP_XCHANGE 0x12 Capabilities Exchange Message CLOSE_PEER_REQUEST 0x13 Disconnect Peer Connection Request CLOSE_PEER_RESPONSE 0x14 Disconnect Peer Connection Response PEER_TEST_REQ 0x1D Peer keepalive test request PEER_TEST_RSP 0x1E Peer keepalive response
DRAPフレーム名コード機能--------------- ---- -------- _与えられているステーションが届いているIであるなら、_CAN_U REACH I_へのCAN_REACH0x02Positive応答はそうしません。CAN_U_REACH0×01Find、_当然のことが、DL_STARTED0x05Session Started START_がDL_FAILED0x06Session Startであると扱うので、CAN_U_REACH START_DL0x04SetupセッションへのREACH0x03Negative応答はCONTACTED0x09駅が連絡したSABME STN_を証明するためにXID_FRAME0x07XID Frame CONTACT_STN0x08Contactの目的地に失敗しました--、SABMEモードはINFO_FRAME 0x0B Connectionが適応させたリンクにDATA_FRAME 0x0A Connectionless Data Frameを設定しました; 回路CAP_XCHANGE0x12Capabilities Exchange Message CLOSE_PEER_REQUEST0x13Disconnect Peer Connection Request CLOSE_PEER_RESPONSE0x14Disconnect Peer Connection Response PEER_TEST_REQ 0x1D Peer keepaliveテスト要求PEER_TEST_RSP 0x1E Peer keepalive応答のためのack DL_HALTED 0x0E Session Halted FCM_FRAME 0x0F Data Link Session Flow Control Message DGRM_FRAME0x11ConnectionlessデータグラムFrameのないI-フレームHALT_DL 0x0C Halt Data LinkセッションHALT_DL_ノアクの0x0D Halt Data Linkセッション
Table 3-1. DRAP Frames
3-1をテーブルの上に置いてください。 DRAPフレーム
3.4. DRAP Data formats
3.4. DRAP Data形式
The DRAP data is used to carry information required for each DRAP frame. This information is used by the Server or the Client and it does not contain any user data. The DRAP data frame types are listed in the following sections. Please note that the sender should set the reserved fields to zero and the receiver should ignore these fields.
DRAPデータは、それぞれのDRAPフレームに必要である情報を運ぶのに使用されます。 この情報はServerかClientによって使用されます、そして、それは少しの利用者データも含んでいません。 DRAPデータフレームタイプは以下のセクションで記載されています。 送付者は予約された分野をゼロに設定するべきです、そして、受信機はこれらの分野を無視するはずです。
3.4.1. CAN_U_REACH, I_CAN_REACH, and I_CANNOT_REACH Frames
3.4.1. _缶_UのIの_範囲、缶_範囲、およびI_が達しない、_フレームに達してください。
These frame types are used to locate resources in a network. A CAN_U_REACH frame is sent to the server to determine if the resource is reachable. The server responds with an I_CAN_REACH frame if it can reach the workstation identified in the CAN_U_REACH frame, or with an I_CANNOT_REACH if the station is not reachable. The server should not send the CAN_U_REACH frame to the clients. When a server receives an explorer whose destination is a known client, the server should respond to it directly.
これらのフレームタイプは、ネットワークでリソースの場所を見つけるのに使用されます。 リソースが届くかどうか決定するためにCAN_U_REACHフレームをサーバに送ります。 CAN_U_REACHフレームで特定されたワークステーションに達することができるか、または_がIと共に反応しないなら、サーバはI_CAN_REACHフレームで反応します。_REACHはステーションであるなら届いていません。 サーバはCAN_U_REACHフレームをクライアントに送るべきではありません。 サーバが目的地が知られているクライアントである探検家を受けるとき、サーバは直接それに反応するべきです。
Chiang, et. al. Informational [Page 6] RFC 2106 DLSRAP February 1997
etチャン、アル。 [6ページ]情報のRFC2106DLSRAP1997年2月
+---------------+-----------------------+
| Field Name | Information |
+---------------+-----------------------+
| Message Type | 0x01, 0x02, or 0x03 |
+---------------+-----------------------+
| Packet Length | 0x0C |
+---------------+-----------------------+
Figure 3-3. CAN_U_REACH, I_CAN_REACH, and I_CANNOT_REACH Header
+---------------+-----------------------+ | フィールド名| 情報| +---------------+-----------------------+ | メッセージタイプ| 0×01、0×02、または0×03| +---------------+-----------------------+ | パケット長| 0x0C| +---------------+-----------------------+ 図3-3。 _缶_UのIの_範囲、缶_範囲、およびI_がそうしない、_範囲ヘッダー
+-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | Target MAC Address |
+ - - - - - - - - - - - - - - - - - +
1 | |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+ - - - - - - - - - - - - - - - - - +
4 | |
+ - - - - - - - - - - - - - - - - - +
5 | |
+-----------------------------------+
6 | Source SAP |
+-----------------------------------+
7 | Reserved |
+-----------------------------------+
Figure 3-4. CAN_U_REACH, I_CAN_REACH, and I_CANNOT_REACH Data
+-----------------------------------+ | 分野Name(各行は1バイトです)| +===================================+ 0 | 目標マックーアドレス| + - - - - - - - - - - - - - - - - - + 1 | | + - - - - - - - - - - - - - - - - - + 2 | | + - - - - - - - - - - - - - - - - - + 3 | | + - - - - - - - - - - - - - - - - - + 4 | | + - - - - - - - - - - - - - - - - - + 5 | | +-----------------------------------+ 6 | ソースSAP| +-----------------------------------+ 7 | 予約されます。| +-----------------------------------+ 図3-4。 _缶_UのIの_範囲、缶_範囲、およびI_が達しない、_データに達してください。
The MAC Address field carries the MAC address of the target workstation that is being searched. This is a six-byte MAC Address field. The same MAC Address is returned in the I_CAN_REACH and the I_CANNOT_REACH frames.
マックーアドレス分野は捜されている目標ワークステーションのMACアドレスを運びます。 これは6バイトのマックーアドレス分野です。 _I_CAN REACHで同じマックーアドレスを返します、そして、I_は_REACHフレームは返しません。
Byte 6 is the source SAP. The destination SAP is set to zero when an explorer frame is sent to the network.
バイト6はソースSAPです。 探検家フレームをネットワークに送るとき、目的地SAPをゼロに設定します。
If the sender did not receive a positive acknowledgment within a recommended threshold value of 60 seconds, the destination is considered not reachable.
送付者が60秒のお勧めの閾値の中で肯定応答を受けなかったなら、目的地は届かないと考えられます。
3.4.2. START_DL, DL_STARTED, and START_DL_FAILED Frames
3.4.2. _dlを始めてください、dl_は始まって、_dlの_の失敗したフレームを始動します。
These frame types are used by DRAP to establish a link station (circuit). The START_DL frame is sent directly to the server that responds to the CAN_U_REACH frame. When the server receives this frame, it establishes a link station with the source and destination
これらのフレームタイプは、リンクステーション(回路)を証明するのにDRAPによって使用されます。 直接CAN_U_REACHフレームに反応するサーバにSTART_DLフレームを送ります。 サーバがこのフレームを受けるとき、それはソースと目的地でリンクステーションを確立します。
Chiang, et. al. Informational [Page 7] RFC 2106 DLSRAP February 1997
etチャン、アル。 [7ページ]情報のRFC2106DLSRAP1997年2月
addresses and saps provided in the START_DL frame. If the circuit establishment is successful, a DL_STARTED frame is sent back as a response. A failure will result in a START_DL_FAILED response. The server can also send START_DL frames to clients, to establish circuits.
アドレスと体液はSTART_DLフレームに供給されました。 回路設立がうまくいくなら、DL_STARTEDフレームは応答として返送されます。 失敗はSTART_DL_FAILED応答をもたらすでしょう。 また、サーバは、回路を証明するためにSTART_DLにクライアントへのフレームを送ることができます。
+---------------+-----------------------+
| Field Name | Information |
+---------------+-----------------------+
| Message Type | 0x04, 0x05, or 0x06 |
+---------------+-----------------------+
| Packet Length | 0x18 |
+---------------+-----------------------+
Figure 3-5. START_DL, DL_STARTED, and START_DL_FAILED Header
+---------------+-----------------------+ | フィールド名| 情報| +---------------+-----------------------+ | メッセージタイプ| 0×04、0×05、または0×06| +---------------+-----------------------+ | パケット長| 0×18| +---------------+-----------------------+ 図3-5。 _dlを始めてください、dl_は始まって、_dlの_の失敗したヘッダーを始動します。
Chiang, et. al. Informational [Page 8] RFC 2106 DLSRAP February 1997
etチャン、アル。 [8ページ]情報のRFC2106DLSRAP1997年2月
+-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | Host MAC Address |
+ - - - - - - - - - - - - - - - - - +
1 | |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+ - - - - - - - - - - - - - - - - - +
4 | |
+ - - - - - - - - - - - - - - - - - +
5 | |
+-----------------------------------+
6 | Host SAP |
+-----------------------------------+
7 | Client SAP |
+-----------------------------------+
8 | Origin Session ID |
+-----------------------------------+
9 | |
+ - - - - - - - - - - - - - - - - - +
10| |
+ - - - - - - - - - - - - - - - - - +
11| |
+-----------------------------------+
12| Target Session ID |
+ - - - - - - - - - - - - - - - - - +
13| |
+ - - - - - - - - - - - - - - - - - +
14| |
+ - - - - - - - - - - - - - - - - - +
15| |
+-----------------------------------+
16| Largest Frame Size |
+-----------------------------------+
17| Initial Window size |
+-----------------------------------+
18| Reserved |
+ - - - - - - - - - - - - - - - - - +
19| |
+-----------------------------------+
Figure 3-6. START_DL, DL_STARTED, and START_DL_FAILED Data
+-----------------------------------+ | 分野Name(各行は1バイトです)| +===================================+ 0 | ホストマックーアドレス| + - - - - - - - - - - - - - - - - - + 1 | | + - - - - - - - - - - - - - - - - - + 2 | | + - - - - - - - - - - - - - - - - - + 3 | | + - - - - - - - - - - - - - - - - - + 4 | | + - - - - - - - - - - - - - - - - - + 5 | | +-----------------------------------+ 6 | ホストSAP| +-----------------------------------+ 7 | クライアントSAP| +-----------------------------------+ 8 | 発生源セッションID| +-----------------------------------+ 9 | | + - - - - - - - - - - - - - - - - - + 10| | + - - - - - - - - - - - - - - - - - + 11| | +-----------------------------------+ 12| Session IDを狙ってください。| + - - - - - - - - - - - - - - - - - + 13| | + - - - - - - - - - - - - - - - - - + 14| | + - - - - - - - - - - - - - - - - - + 15| | +-----------------------------------+ 16| 最も大きいフレーム・サイズ| +-----------------------------------+ 17| 初期のWindowサイズ| +-----------------------------------+ 18| 予約されます。| + - - - - - - - - - - - - - - - - - + 19| | +-----------------------------------+ 図3-6。 _dlを始めてください、dl_は始まって、_dlの_の失敗したデータを始めます。
The Host MAC address is the address of the target station if the session is initiated from the client, or it is the address of the originating station if the session is initiated from the server.
セッションがクライアントから開始されるなら、Host MACアドレスは目標ステーションのアドレスであるかセッションがサーバから開始されるなら、それが起因するステーションのアドレスです。
Chiang, et. al. Informational [Page 9] RFC 2106 DLSRAP February 1997
etチャン、アル。 [9ページ]情報のRFC2106DLSRAP1997年2月
The next two fields are the Host and Client SAPs. Each is one byte long. The Host SAP is the SAP used by the station with the Host MAC address. The Client SAP is the SAP used by the client.
次の2つの分野が、HostとClient SAPsです。 それぞれが長さ1バイトです。 Host SAPはHost MACアドレスでステーションによって使用されたSAPです。 Client SAPはクライアントによって使用されたSAPです。
The Origin Session ID, is the ID of the originating station that initiates the circuit. The originating station uses this ID to identify the newly created circuit. Before the START_DL frame is sent to the target station, the originating station sets up a control block for the circuit. This link station information is set because DRAP does not use a three-way handshake for link station establishment. In the DL_STARTED and the START_DL_FAILED messages, the Origin Session ID is returned as received in the START_DL frame. The Target Session ID is set by the target station and returned in the DL_STARTED message.
Origin Session IDは回路を開始する起因するステーションのIDです。 起因するステーションは、新たに作成された回路を特定するのにこのIDを使用します。 START_DLフレームを目標ステーションに送る前に、起因するステーションは回路のための制御ブロックをセットアップします。 DRAPがリンクステーション設立に3方向ハンドシェイクを使用しないので、このリンクステーション情報は設定されます。 DL_STARTEDとSTART_DL_FAILEDメッセージでは、START_DLフレームに受け取るようにOrigin Session IDを返します。 Target Session IDを目標ステーションが設定して、DL_STARTEDメッセージで返します。
The Target Session ID is not valid for the START_DL and the START_DL_FAILED frame, and should be treated as Reserved fields. In the DL_STARTED frame, it is the session ID that is used to set up this circuit by the target station.
Target Session IDは、START_DLとSTART_DL_FAILEDフレームには有効でなく、Reserved分野として扱われるべきです。 DL_STARTEDフレームでは、それは目標ステーションのそばでこの回路をセットアップするのに使用されるセッションIDです。
The Largest Frame Size field is used to indicate the maximum frame size that can be used by the client. It is valid only when it is set by the server. The Largest Frame Size field must be set to zero when a frame is sent by the client. Both START_DL and DL_STARTED use the Largest Frame Size field and only its rightmost 6 bits are used. The format is defined in the IEEE 802.1D Standard, Annex C, Largest Frame Bits (LF). Bit 3 to bit 5 are base bits. Bit 0 to bit 2 are extended bits. The Largest Frame Size field is not used in the START_DL_FAILED frame and must be set to zero.
Largest Frame Size分野は、クライアントが使用できる最大のフレーム・サイズを示すのに使用されます。 サーバによって設定されるときだけ、それは有効です。フレームがクライアントによって送られるとき、Largest Frame Size分野をゼロに設定しなければなりません。 START_DLとDL_STARTEDの両方がLargest Frame Size分野を使用します、そして、一番右の6ビットだけが使用されています。 書式はIEEE 802.1D Standard、Annex C、Largest Frame Bits(LF)で定義されます。 ビット3からビット5はベースビットです。 ビット0からビット2は拡張ビットです。 Largest Frame Size分野をSTART_DL_FAILEDフレームで使用されないで、ゼロに設定しなければなりません。
bit 7 6 5 4 3 2 1 0
r r b b b e e e
Figure 3-7. Largest Frame Size
ビット7 6 5 4 3 2 1 0r r b b b e e e図3-7。 最も大きいフレーム・サイズ
Please note that if the client is a PU 2.1 node, the client should use the maximum I-frame size negotiated in the XID3 exchange.
クライアントがPU2.1ノードであるなら、クライアントはXID3交換で交渉された最大のI-フレーム・サイズを使用するべきです。
The Initial window size in the START_DL frame gives the receive window size on the originating side, and the target DRAP station returns its receive window size in the DL_STARTED frame. The field is reserved in the START_DL_FAILED frame. The usage of the window size is the same as the one used in DLSw. Please refer to RFC 1795 for details.
START_DLフレームのInitialウィンドウサイズは起因する側のレシーブ・ウィンドウ・サイズを与えます、そして、目標DRAPステーションはDL_STARTEDフレームでレシーブ・ウィンドウ・サイズを返します。 分野はSTART_DL_FAILEDフレームで予約されます。 ウィンドウサイズの用法はDLSwで使用されるものと同じです。 詳細についてRFC1795を参照してください。
The last two bits are reserved for future use. They must be set to zero by the sender and ignored by the receiver.
最後の2ビットは今後の使用のために予約されます。 それらを送付者によってゼロに設定されて、受信機で無視しなければなりません。
Chiang, et. al. Informational [Page 10] RFC 2106 DLSRAP February 1997
etチャン、アル。 [10ページ]情報のRFC2106DLSRAP1997年2月
If the sender of the START_DL frame did not receive a START_DL_FAILED frame within a recommended threshold value of 60 seconds, the connection is considered unsuccessful.
START_DLフレームの送付者が60秒のお勧めの閾値の中にSTART_DL_FAILEDフレームを受け取らなかったなら、接続は失敗していると考えられます。
3.4.3. HALT_DL, HALT_DL_NOACK, and DL_HALTED Frames
3.4.3. _dlを止めてください、そして、_dl_ノアク、およびdlの_の停止しているフレームを止めてください。
These frame types are used by DRAP to disconnect a link station. A HALT_DL frame is sent directly to the remote workstation to indicate that the sender wishes to disconnect. When the receiver receives this frame, it tears down the session that is associated with the Original Session ID and the Target Session ID provided in the HALT_DL frame. The receiver should respond with the DL_HALTED frame. The DL_HALTED frame should use the same Session ID values as the received HALT_DL message without swapping them. The HALT_DL_NOACK frame is used when the response is not required.
これらのフレームタイプは、リンクがステーションであると切断するのにDRAPによって使用されます。 送付者が切断したがっているのを示すためにHALT_DLフレームを直接遠隔ワークステーションに送ります。 受信機がこのフレームを受けるとき、それはHALT_DLフレームに提供するOriginal Session IDとTarget Session IDに関連しているセッションを取りこわします。 受信機はDL_HALTEDフレームで応じるはずです。 それらを交換しないで、DL_HALTEDフレームは受信されたHALT_DLメッセージと同じSession ID値を使用するはずです。 応答は必要でないときに、HALT_DL_ノアクフレームが使用されています。
+---------------+-----------------------+
| Field Name | Information |
+---------------+-----------------------+
| Message Type | 0x0C, 0x0D, or 0x0E |
+---------------+-----------------------+
| Packet Length | 0x10 |
+---------------+-----------------------+
Figure 3-8. HALT_DL, HALT_DL_NOACK, and DL_HALTED Header
+---------------+-----------------------+ | フィールド名| 情報| +---------------+-----------------------+ | メッセージタイプ| 0x0C、0x0D、または0x0E| +---------------+-----------------------+ | パケット長| 0×10| +---------------+-----------------------+ 図3-8。 _dlを止めてください、そして、_dl_ノアク、およびdlの_の停止しているヘッダーを止めてください。
Chiang, et. al. Informational [Page 11] RFC 2106 DLSRAP February 1997
etチャン、アル。 [11ページ]情報のRFC2106DLSRAP1997年2月
+-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | Sender Session ID |
+ - - - - - - - - - - - - - - - - - +
1 | |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+-----------------------------------+
4 | Receiver Session ID |
+ - - - - - - - - - - - - - - - - - +
5 | |
+ - - - - - - - - - - - - - - - - - +
6 | |
+ - - - - - - - - - - - - - - - - - +
7 | |
+-----------------------------------+
8 | Reserved |
+ - - - - - - - - - - - - - - - - - +
9 | |
+ - - - - - - - - - - - - - - - - - +
10| |
+ - - - - - - - - - - - - - - - - - +
11| |
+-----------------------------------+
Figure 3-9. START_DL, DL_STARTED, and START_DL_FAILED Data
+-----------------------------------+ | 分野Name(各行は1バイトです)| +===================================+ 0 | 送付者Session ID| + - - - - - - - - - - - - - - - - - + 1 | | + - - - - - - - - - - - - - - - - - + 2 | | + - - - - - - - - - - - - - - - - - + 3 | | +-----------------------------------+ 4 | 受信機セッションID| + - - - - - - - - - - - - - - - - - + 5 | | + - - - - - - - - - - - - - - - - - + 6 | | + - - - - - - - - - - - - - - - - - + 7 | | +-----------------------------------+ 8 | 予約されます。| + - - - - - - - - - - - - - - - - - + 9 | | + - - - - - - - - - - - - - - - - - + 10| | + - - - - - - - - - - - - - - - - - + 11| | +-----------------------------------+ 図3-9。 _dlを始めてください、dl_は始まって、_dlの_の失敗したデータを始めます。
3.4.4. XID_FRAME, CONTACT_STN, STN_CONTACTED, INFO_FRAME, FCM_FRAME,
and DGRM_FRAME
3.4.4. XID_フレーム、STN、連絡されたSTN_、インフォメーション_フレーム、FCM_フレーム、およびDGRM_が縁どる接触_
These frame types are used to carry the end-to-end data or establish a circuit. The Destination Session ID is the Session ID created in the START_DL frame or the DL_STARTED frame by the receiver. The usage of the flow control flag is the same as the one used in DLSw. Please refer to RFC 1795 for details.
これらのフレームタイプは、終わりから終わりへのデータを運ぶか、または回路を証明するのに使用されます。 Destination Session IDはSTART_DLフレームかDL_STARTEDフレームで受信機によって作成されたSession IDです。フロー制御旗の使用法はDLSwで使用されるものと同じです。 詳細についてRFC1795を参照してください。
+---------------+----------------------------+
| Field Name | Information |
+---------------+----------------------------+
| Message Type | Based on Message type |
+---------------+----------------------------+
| Packet Length | 0x0C + length of user data |
+---------------+----------------------------+
Figure 3-10. Generic DRAP Header
+---------------+----------------------------+ | フィールド名| 情報| +---------------+----------------------------+ | メッセージタイプ| Messageタイプに基づいています。| +---------------+----------------------------+ | パケット長| 利用者データの0x0C+長さ| +---------------+----------------------------+ 図3-10。 ジェネリックDRAPヘッダー
Chiang, et. al. Informational [Page 12] RFC 2106 DLSRAP February 1997
etチャン、アル。 [12ページ]情報のRFC2106DLSRAP1997年2月
+-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | Destination Session ID |
+ - - - - - - - - - - - - - - - - - +
1 | |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+-----------------------------------+
4 | Flow Control Flags |
+-----------------------------------+
5 | Reserved |
+ - - - - - - - - - - - - - - - - - +
6 | |
+ - - - - - - - - - - - - - - - - - +
7 | |
+-----------------------------------+
Figure 3-11. Generic DRAP Data Format
+-----------------------------------+ | 分野Name(各行は1バイトです)| +===================================+ 0 | 目的地セッションID| + - - - - - - - - - - - - - - - - - + 1 | | + - - - - - - - - - - - - - - - - - + 2 | | + - - - - - - - - - - - - - - - - - + 3 | | +-----------------------------------+ 4 | フロー制御旗| +-----------------------------------+ 5 | 予約されます。| + - - - - - - - - - - - - - - - - - + 6 | | + - - - - - - - - - - - - - - - - - + 7 | | +-----------------------------------+ 図3-11。 ジェネリックDRAPデータの形式
3.4.5. DATA_FRAME
3.4.5. データ_フレーム
This frame type is used to send connectionless SNA and NetBIOS Datagram (UI) frames that do not have a link station associated with the source and destination MAC/SAP pair. The difference between DGRM_FRAME and DATA_FRAME is that DGRM_FRAME is used to send UI frames received for stations that have a link station opened, whereas DATA_FRAME is used for frames with no link station established.
このフレームタイプは、ソースと目的地MAC/SAP組に関連しているリンクステーションを持っていないコネクションレスなSNAとNetBIOSデータグラム(UI)フレームを送るのに使用されます。 DGRM_FRAMEとDATA_FRAMEの違いはDGRM_FRAMEがリンクステーションをオープンさせるステーションに受け取られたフレームをUIに送るのに使用されますが、DATA_FRAMEがフレームに確立されないリンクステーションに全く使用されるということです。
+---------------+-----------------------------+
| Field Name | Information |
+---------------+-----------------------------+
| Message Type | 0x0A |
+---------------+-----------------------------+
| Packet Length | 0x10 + Length of user data |
+---------------+-----------------------------+
Figure 3-12. DATA_FRAME Header
+---------------+-----------------------------+ | フィールド名| 情報| +---------------+-----------------------------+ | メッセージタイプ| 0x0A| +---------------+-----------------------------+ | パケット長| 0×10 + 利用者データの長さ| +---------------+-----------------------------+ 図3-12。 データ_フレームヘッダー
Chiang, et. al. Informational [Page 13] RFC 2106 DLSRAP February 1997
etチャン、アル。 [13ページ]情報のRFC2106DLSRAP1997年2月
+-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | Host MAC Address |
+ - - - - - - - - - - - - - - - - - +
1 | |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+ - - - - - - - - - - - - - - - - - +
4 | |
+ - - - - - - - - - - - - - - - - - +
5 | |
+-----------------------------------+
6 | Host SAP |
+-----------------------------------+
7 | Client SAP |
+-----------------------------------+
8 | Broadcast Type |
+-----------------------------------+
9 | Reserved |
+ - - - - - - - - - - - - - - - - - +
10| |
+ - - - - - - - - - - - - - - - - - +
11| |
+-----------------------------------+
Figure 3-13. DATA_FRAME Data Format
+-----------------------------------+ | 分野Name(各行は1バイトです)| +===================================+ 0 | ホストマックーアドレス| + - - - - - - - - - - - - - - - - - + 1 | | + - - - - - - - - - - - - - - - - - + 2 | | + - - - - - - - - - - - - - - - - - + 3 | | + - - - - - - - - - - - - - - - - - + 4 | | + - - - - - - - - - - - - - - - - - + 5 | | +-----------------------------------+ 6 | ホストSAP| +-----------------------------------+ 7 | クライアントSAP| +-----------------------------------+ 8 | 放送タイプ| +-----------------------------------+ 9 | 予約されます。| + - - - - - - - - - - - - - - - - - + 10| | + - - - - - - - - - - - - - - - - - + 11| | +-----------------------------------+ 図3-13。 データ_フレームデータの形式
The definition of the first 8 bytes is the same as the START_DL frame. The Broadcast Type field indicates the type of broadcast frames in use; Single Route Broadcast, All Route Broadcast, or Directed. The target side will use the same broadcast type. In the case of Directed frame, if the RIF information is known, the target peer can send a directed frame. If not, a Single Route Broadcast frame is sent.
最初の8バイトの定義はSTART_DLフレームと同じです。 Broadcast Type分野は放送フレームのタイプを使用中に示します。 ただ一つのルートが放送されたか、すべてのルートが放送されたか、またはあてられました。 目標側は同じ放送タイプを使用するでしょう。 Directedフレームの場合では、RIF情報が知られているなら、目標同輩は指示されたフレームを送ることができます。 そうでなければ、Single Route Broadcastフレームを送ります。
3.4.6. CAP_XCHANGE Frame
3.4.6. 上限_XCHANGEフレーム
In DRAP, the capability exchange frame is used to exchange the client's information, such as its MAC address, with the server. If a DRAP client has its own MAC address defined, it should put it in the MAC address field. Otherwise, that field must be set to zero.
DRAPでは、能力交換フレームはクライアントの情報を交換するのに使用されます、MACアドレスなどのように、サーバで。DRAPクライアントがアドレスが定義したそれ自身のMACを持っているなら、それはMACアドレス・フィールドにそれを置くべきです。 さもなければ、その分野をゼロに設定しなければなりません。
When the DRAP server receives the CAP_XCHANGE frame, it should cache the MAC address if it is non zero. The DRAP server also verifies that the MAC address is unique. The server should return a CAP_XCHANGE response frame with the MAC address supplied by the client if the MAC
DRAPサーバがCAP_XCHANGEフレームを受けるとき、それは非ゼロであるならMACアドレスをキャッシュするべきです。 また、DRAPサーバは、MACアドレスがユニークであることを確かめます。 MACアドレスがクライアントによって供給されている状態で、サーバはMACであるならCAP_XCHANGEレスポンス・フレームを返すべきです。
Chiang, et. al. Informational [Page 14] RFC 2106 DLSRAP February 1997
etチャン、アル。 [14ページ]情報のRFC2106DLSRAP1997年2月
address is accepted. If a client does not have its own MAC address, the server should assign a MAC address to the client and put that address in the CAP_XCHANGE command frame.
アドレスを受け入れます。 クライアントがそれ自身のMAC住所を知っていないなら、サーバは、MACアドレスをクライアントに割り当てて、CAP_XCHANGEコマンド・フレームにそのアドレスを入れるべきです。
A client should record the new MAC address assigned by the server and return a response with the assigned MAC address. If the client cannot accept the assigned MAC address, another CAP_XCHANGE command with the MAC address field set to zero should be sent to the server. The server should allocate a new MAC address for this client.
クライアントは、サーバによって割り当てられた新しいMACアドレスを記録して、割り当てられたMACアドレスによる応答を返すべきです。 クライアントが割り当てられたMACアドレスを受け入れることができないなら、ゼロに設定されたMACアドレス・フィールドがある別のCAP_XCHANGEコマンドをサーバに送るべきです。サーバは、このクライアントのために新しいMACアドレスを割り当てるべきです。
During the capability exchange, both the client and the server can send command frames. The process stops when either side sends a CAP_XCHANGE response frame. When the response frame is sent, the MAC address in the CAP_XCHANGE frame should be the same as the one in the previous received command. The sender of the CAP_XCHANGE response agrees to use the MAC address defined in the previous command.
能力交換の間、クライアントとサーバの両方がコマンド・フレームを送ることができます。 どちらの側もCAP_XCHANGEレスポンス・フレームを送るとき、プロセスは止まります。 レスポンス・フレームを送るとき、CAP_XCHANGEフレームのMACアドレスは前の容認されたコマンドでものと同じであるべきです。 CAP_XCHANGE応答の送付者は、前のコマンドで定義されたMACアドレスを使用するのに同意します。
The number of CAP_XCHANGE frames that need to be exchanged is determined by the client and the server independently. When the number of exchange frames has exceeded the pre-defined number set by either the server or the client, the session should be brought down.
交換される必要があるCAP_XCHANGEフレームの数はクライアントとサーバによって独自に測定されます。 交換フレームの数がサーバかクライアントのどちらかによって設定された事前に定義された数を超えていたとき、セッションは降ろされるべきです。
The flag is used to show the capability of the sender. The following list shows the valid flags:
旗は、送付者の能力を示しているのに使用されます。 以下のリストは有効な旗を示しています:
0x01 NetBIOS support. If a client sets this bit on, the server will
pass all NetBIOS explorers to this client. If this bit is not
set, only SNA traffic will be sent to this client.
0×01NetBIOSサポート。 クライアントがかみつかれたこれを設定すると、サーバはすべてのNetBIOS探検家をこのクライアントに渡すでしょう。 このビットを設定しないと、SNAトラフィックだけをこのクライアントに送るでしょう。
0x02 TCP Listen Mode support. If a client supports TCP listen mode,
the server will keep the client's MAC and IP addresses even
after the TCP session is down. The cached information will be
used for server to connect out. If a client does not support
TCP listen mode, the cache will be deleted as soon as the TCP
session is down.
0×02 TCP Listen Modeサポート。 クライアントサポートであるなら、TCPはモードを聴いて、TCPセッションが下がった後にさえサーバはクライアントのMACとIPアドレスを保管するでしょう。 キャッシュされた情報は、サーバが外に接続するのに使用されるでしょう。 クライアントがそうしないなら、サポートTCPはモードを聴いて、TCPセッションが下がっているとすぐに、キャッシュは削除されるでしょう。
0x04 Command/Response. If this bit is set, it is a command,
otherwise, it is a response.
0×04 コマンド/応答。 このビットが設定されるなら、コマンドである、さもなければ、それは応答です。
The values 0x01 and 0x02 are used only by the client. When a server sends the command/response to a client, the server does not return these values.
値0×01と0x02は単にクライアントによって使用されます。 サーバがコマンド/応答をクライアントに送るとき、サーバはこれらの値を返しません。
Starting with the Reserved field, implementors can optionally implement the Capability Exchange Control Vector. Each Capability Exchange Control Vector consists of three fields: Length (1 byte), Type (1 byte), and Data (Length - 2 bytes). Two types of Control Vectors are defined: SAP_LIST and VENDOR_CODE (described below). To
Reserved野原から始まって、作成者は任意にCapability Exchange Control Vectorを実装することができます。 各Capability Exchange Control Vectorは3つの分野から成ります: 長さ(1バイト)、Type(1バイト)、およびData(長さ--2バイト)。 Control Vectorsの2つのタイプが定義されます: SAP_LISTとVENDOR_CODE(以下で、説明されます)。 to
Chiang, et. al. Informational [Page 15] RFC 2106 DLSRAP February 1997
etチャン、アル。 [15ページ]情報のRFC2106DLSRAP1997年2月
ensure compatibility, implementors should ignore the unknown Control Vectors instead of treating them as errors.
互換性を確実にしてください、そして、作成者は誤りとして彼らを扱うことの代わりに未知のControl Vectorsを無視するべきです。
0x01 SAP_LIST. Length: 2+n bytes, where n ranges from 1 to 16.
This control vector lists the SAPs that the client can support.
The maximum number of SAPs a client can define is 16. Therefore,
the length of this Control Vector ranges from 3 to 18. If the
SAP_LIST is not specified in the capability exchange, the server
assumes that the client can support all the SAP values. For
example, if a client can only support SAP 4 and 8, then the
following Control Vectors should be sent: "0x04, 0x01, 0x04,
0x08". The first byte indicates the length of 4. The second byte
indicates the control vector type of SAP_LIST. The last two bytes
indicate the supported SAP values; 0x04 and 0x08. This Control
Vector is used only by the client. If the server accepts this
Control Vector, it must return the same Control Vector to the
client.
0×01 _リスト長さを徐々に破壊してください: nが1〜16まで及ぶところの2+nバイト。 このコントロールベクトルはクライアントがサポートすることができるSAPsを記載します。 クライアントが定義できるSAPsの最大数は16です。 したがって、このControl Vectorの長さは3〜18まで及びます。 SAP_LISTが能力交換で指定されないなら、サーバは、クライアントがすべてのSAP値をサポートすることができると仮定します。 例えば、クライアントがSAP4と8をサポートすることができるだけであるなら、以下のControl Vectorsを送るべきです: 「0×04、0×01、0×04、0×08。」 最初のバイトは4の長さを示します。 2番目のバイトはSAP_LISTのコントロールベクトル型を示します。最後の2バイトはサポートしているSAP値を示します。 0×04と0×08。 このControl Vectorは単にクライアントによって使用されます。 サーバがこのControl Vectorを受け入れるなら、それは同じControl Vectorをクライアントに返さなければなりません。
0x02 VENDOR_CODE. Length: 6 bytes.
Each vendor is assigned a vendor code that identifies the vendor.
This Control Vector does not require a response.
0×02 ベンダー_コード。 長さ: 6バイト。 ベンダーを特定するベンダーコードは各ベンダーに配属されます。 このControl Vectorは応答を必要としません。
After the receiver responds to a Control Vector, if the capability exchange is not done, the sender does not have to send the same Control Vector again.
能力交換が完了していないなら受信機がControl Vectorに応じた後に、送付者は再び同じControl Vectorを送る必要はありません。
+---------------+-----------------------+
| Field Name | Information |
+---------------+-----------------------+
| Message Type | 0x12 |
+---------------+-----------------------+
| Packet Length | 0x1C |
+---------------+-----------------------+
Figure 3-14. CAP_XCHANGE Header
+---------------+-----------------------+ | フィールド名| 情報| +---------------+-----------------------+ | メッセージタイプ| 0×12| +---------------+-----------------------+ | パケット長| 0x1C| +---------------+-----------------------+ 図3-14。 上限_XCHANGEヘッダー
Chiang, et. al. Informational [Page 16] RFC 2106 DLSRAP February 1997
etチャン、アル。 [16ページ]情報のRFC2106DLSRAP1997年2月
+-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | MAC Address |
+ - - - - - - - - - - - - - - - - - +
1 | |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+ - - - - - - - - - - - - - - - - - +
4 | |
+ - - - - - - - - - - - - - - - - - +
5 | |
+-----------------------------------+
6 | Flag |
+-----------------------------------+
7 | Reserved |
+-----------------------------------+
Figure 3-15. CAP_XCHANGE Data Format
+-----------------------------------+ | 分野Name(各行は1バイトです)| +===================================+ 0 | マックーアドレス| + - - - - - - - - - - - - - - - - - + 1 | | + - - - - - - - - - - - - - - - - - + 2 | | + - - - - - - - - - - - - - - - - - + 3 | | + - - - - - - - - - - - - - - - - - + 4 | | + - - - - - - - - - - - - - - - - - + 5 | | +-----------------------------------+ 6 | 旗| +-----------------------------------+ 7 | 予約されます。| +-----------------------------------+ 図3-15。 上限_XCHANGEデータの形式
3.4.7. CLOSE_PEER_REQ Frames
3.4.7. _同輩_REQフレームを閉じてください。
This frame is used for peer connection management and contains a reason code field. The following list describes the valid reason codes:
このフレームは、同輩接続管理に使用されて、理由コード分野を含んでいます。 以下のリストは正当な理由コードについて説明します:
0x01 System shutdown. This indicates shutdown in progress.
0×01 システム・シャットダウン。 これは進行中の閉鎖を示します。
0x02 Suspend. This code is used when there is no traffic between the
server and the client, and the server or the client wishes to
suspend the TCP session. When the TCP session is suspended, all
circuits should remain intact. The TCP session should be re-
established when new user data needs to be sent. When the TCP
session is re-established, there is no need to send the
CAP_XCHANGE frame again.
0×02 中断します。 サーバと、クライアントと、サーバの間にトラフィックが全くないとき、このコードが使用されているか、またはクライアントはTCPセッションを中断させたがっています。 TCPセッションが吊しているとき、すべての回路が元の状態のままになるはずです。 新しい利用者データが、送られる必要があるとき、TCPセッションは再確立しているべきです。 TCPセッションが復職するとき、再びCAP_XCHANGEフレームを送る必要は全くありません。
0x03 No MAC address available. This code is sent by the server when
there is no MAC address is available from the MAC address pool.
0×03 利用可能なMACアドレスがありません。 このコードはMACが全くないとき、サーバで送って、アドレスがMACアドレスプールから利用可能であるということです。
+---------------+-----------------------+
| Field Name | Information |
+---------------+-----------------------+
| Message Type | 0x13 |
+---------------+-----------------------+
| Packet Length | 0x08 |
+---------------+-----------------------+
Figure 3-16. CLOSE_PEER_REQ Header
+---------------+-----------------------+ | フィールド名| 情報| +---------------+-----------------------+ | メッセージタイプ| 0×13| +---------------+-----------------------+ | パケット長| 0×08| +---------------+-----------------------+ 図3-16。 _同輩_REQヘッダーを閉じてください。
Chiang, et. al. Informational [Page 17] RFC 2106 DLSRAP February 1997
etチャン、アル。 [17ページ]情報のRFC2106DLSRAP1997年2月
+-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | Reason Code |
+-----------------------------------+
1 | Reserved |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+-----------------------------------+
Figure 3-17. CLOSE_PEER_REQ Data Format
+-----------------------------------+ | 分野Name(各行は1バイトです)| +===================================+ 0 | 理由コード| +-----------------------------------+ 1 | 予約されます。| + - - - - - - - - - - - - - - - - - + 2 | | + - - - - - - - - - - - - - - - - - + 3 | | +-----------------------------------+ 図3-17。 _同輩_REQデータの形式を閉じてください。
3.4.8. CLOSE_PEER_RSP, PEER_TEST_REQ, and PEER_TEST_RSP Frames
3.4.8. 同輩_は_REQをテストします、そして、_同輩_RSPを閉じてください、そして、同輩_は_RSPフレームをテストします。
These three frames are used for peer connection management. There is no data associated with them.
これらの3個のフレームが同輩接続管理に使用されます。 それらに関連しているどんなデータもありません。
o CLOSE_PEER_RSP
CLOSE_PEER_RSP is the response for CLOSE_PEER_REQ.
o CLOSE_PEER_RSP CLOSE_PEER_RSPはCLOSE_PEER_REQのための応答です。
o PEER_TEST_REQ and PEER_TEST_RSP
PEER_TEST_REQ and PEER_TEST_RSP are used for peer level keepalive.
Implementing PEER_TEST_REQ is optional, but PEER_TEST_RSP must be
implemented to respond to the PEER_TEST_REQ frame. When a
PEER_TEST_REQ frame is sent to the remote station, the sender
expects to receive the PEER_TEST_RSP frame in a predefined time
interval (the recommended value is 60 seconds). If the
PEER_TEST_RSP frame is not received in the predefined time
interval, the sender can send the PEER_TEST_REQ frame again. If a
predefined number of PEER_TEST_REQ frames is sent to the remote
station, but no PEER_TEST_RSP frame is received (the recommended
number is 3), the sender should close the TCP session with this
remote station and terminate all associated circuits.
o PEER_TEST_REQ、PEER_TEST_RSP PEER_TEST_REQ、およびPEER_TEST_RSPは同輩レベルkeepaliveに使用されます。 PEER_TEST_がREQであると実装するのは任意ですが、PEER_TEST_REQフレームに応じるためにPEER_TEST_RSPを実装しなければなりません。 PEER_TEST_REQフレームを遠隔局に送るとき、送付者は、事前に定義された時間間隔のPEER_TEST_RSPフレームを受け取ると予想します(推奨値は60秒です)。 PEER_TEST_RSPフレームが事前に定義された時間間隔に受け取られないなら、送付者は再びPEER_TEST_REQフレームを送ることができます。 事前に定義された数のPEER_TEST_REQフレームを遠隔局に送りますが、どんなPEER_TEST_RSPフレームも受け取られていないなら(お勧めの数は3です)、送付者は、この遠隔局とのTCPセッションを終えて、すべての関連回路を終えるべきです。
+---------------+-----------------------+
| Field Name | Information |
+---------------+-----------------------+
| Message Type | 0x14, 0x1D, or 0x1E |
+---------------+-----------------------+
| Packet Length | 0x04 |
+---------------+-----------------------+
Figure 3-18. CLOSE_PEER_RSP, PEER_TEST_REQ, and PEER_TEST_RSP DRAP
+---------------+-----------------------+ | フィールド名| 情報| +---------------+-----------------------+ | メッセージタイプ| 0×14、0x1D、または0x1E| +---------------+-----------------------+ | パケット長| 0×04| +---------------+-----------------------+ 図3-18。 _同輩_RSP、_同輩_テストREQ、および_同輩_テストRSP DRAPを閉じてください。
Chiang, et. al. Informational [Page 18] RFC 2106 DLSRAP February 1997
etチャン、アル。 [18ページ]情報のRFC2106DLSRAP1997年2月
4. References
4. 参照
[1] Wells, L., Chair, and A. Bartky, Editor, "DLSw: Switch-to-Switch
Protocol", RFC 1795, October 1993.
[1] ウェルズとL.、議長とA.Bartky、エディタ、「DLSw:」 「スイッチからスイッチへのプロトコル」、RFC1795、1993年10月。
[2] IEEE 802.1D Standard.
[2] IEEE 802.1D規格。
Authors' Addresses
作者のアドレス
Steve T. Chiang InterWorks Business Unit Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134
スティーブ・T.チャンはビジネス部シスコシステムズInc.170タスマンにDriveサンノゼ、カリフォルニア 95134を織り込みます。
Phone: (408) 526-5189 EMail: schiang@cisco.com
以下に電話をしてください。 (408) 526-5189 メールしてください: schiang@cisco.com
Joseph S. Lee InterWorks Business Unit Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134
ジョゼフ・S.リーはビジネス部シスコシステムズInc.170タスマンにDriveサンノゼ、カリフォルニア 95134を織り込みます。
Phone: (408) 526-5232 EMail: jolee@cisco.com
以下に電話をしてください。 (408) 526-5232 メールしてください: jolee@cisco.com
Hideaki Yasuda System Product Center Network Products Department Network Software Products Section B Mitsubishi Electric Corp. Information Systems Engineering Center 325, Kamimachiya Kamakura Kanagawa 247, Japan
Hideaki安田のシステム製品センターネットワーク製品部のネットワークソフト製品部分B三菱電気社の情報システム工学センター325、Kamimachiya神奈川鎌倉247、日本
Phone: +81-467-47-2120 EMail: yasuda@eme068.cow.melco.co.jp
以下に電話をしてください。 +81-467-47-2120 メールしてください: yasuda@eme068.cow.melco.co.jp
Chiang, et. al. Informational [Page 19]
etチャン、アル。 情報[19ページ]
一覧
スポンサーリンク
