RFC2114 日本語訳
2114 Data Link Switching Client Access Protocol. S. Chiang, J. Lee, H.Yasuda. February 1997. (Format: TXT=50872 bytes) (Obsoletes RFC2106) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Chiang
Request for Comments: 2114 J. Lee
Category: Informational Cisco Systems, Inc.
Obsoletes: 2106 H. Yasuda
Mitsubishi Electric Corp.
February 1997
コメントを求めるワーキンググループS.チャン要求をネットワークでつないでください: 2114年のJ.リーカテゴリ: 情報のシスコシステムズInc.は以下を時代遅れにします。 2106時間安田三菱電気社の1997年2月
Data Link Switching Client 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 Client 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 dcap@cisco.com.
このメモはTCPセッションの間、SNA/NetBIOSトラフィックを輸送するのにワークステーションとルータの間で使用されるData Link Switching Client Accessプロトコルについて説明します。 どんな質問やコメントも dcap@cisco.com に送るべきです。
Table of Contents
目次
1. Introduction ............................................ 2
2. Overview ................................................ 2
2.1 DCAP Client/Server Model ............................... 2
2.2 Dynamic Address Resolution ............................. 3
2.3 TCP Connection ......................................... 4
2.4 Multicast and Unicast (UDP) ............................ 4
3. DCAP Format ............................................. 6
3.1 General Frame Format ................................... 6
3.2 Header Format .......................................... 6
3.3 DCAP Messages .......................................... 7
3.4 DCAP Data formats ...................................... 8
3.4.1 CAN_U_REACH, I_CAN_REACH, and I_CANNOT_REACH Frames .. 8
3.4.2 START_DL, DL_STARTED, and START_DL_FAILED Frames ..... 9
3.4.3 HALT_DL, HALT_DL_NOACK, and DL_HALTED Frames ......... 13
3.4.4 XID_FRAME, CONTACT_STN, STN_CONTACTED, INFO_FRAME,
FCM_FRAME, and DGRM_FRAME ............................ 14
3.4.5 DATA_FRAME ........................................... 15
3.4.6 CAP_XCHANGE Frame .................................... 16
3.4.7 CLOSE_PEER_REQ Frames ................................ 19
3.4.8 CLOSE_PEER_RSP, PEER_TEST_REQ, and PEER_TEST_RSP Frames 20
4. Protocol Flow Diagram ................................... 20
5. Acknowledgments ......................................... 22
6. References .............................................. 22
1. 序論… 2 2. 概要… 2 2.1DCAPクライアント/サーバモデル… 2 2.2のダイナミックなアドレス解決… 3 2.3 TCP接続… 4 2.4のマルチキャストとユニキャスト(UDP)… 4 3. DCAP形式… 6 3.1 一般フレーム形式… 6 3.2 ヘッダー形式… 6 3.3 DCAPメッセージ… 7 3.4 DCAP Data形式… 8 3.4 .1 I_CANの缶の_U_範囲、_範囲、およびI_は_範囲フレームがそうしません。 8 3.4 .2 _dlを始めてください、dl_は始まって、_dlの_の失敗したフレームを始動します… 9 3.4 .3 _dlを止めてください、そして、_dl_ノアク、およびdlの_の停止しているフレームを止めてください… 13 3.4 .4のXID_フレーム、接触_STN、連絡されたSTN_インフォメーション_フレーム、FCM_フレーム、およびDGRM_フレーム… 14 3.4 .5データ_フレーム… 15 3.4 .6 XCHANGEが縁どる_にふたをしてください… 16 3.4 .7 _同輩_REQフレームを閉じてください… 19個の3.4の.8の近い_同輩_RSP、同輩_テスト_REQ、および同輩_テスト_RSPフレーム、20、4 フローチャートについて議定書の中で述べてください… 20 5. 承認… 22 6. 参照… 22
Chiang, et. al. Informational [Page 1] RFC 2114 DCAP February 1997
etチャン、アル。 [1ページ]情報のRFC2114DCAP1997年2月
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がスイッチからスイッチへのプロトコルであるので、ワークステーションの上で実装される場合、それは効率的ではありません。
DCAP 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).
DCAPは上記の問題を扱います。 それは、スケーラビリティ問題を解決するために階層構造を導入します。すべてのワークステーションがルータへの同輩よりむしろルータ(サーバ)へのクライアントです。 これはクライアント/サーバモデルを創造します。 また、それはワークステーション(クライアント)とルータ(サーバ)の間により効率的なプロトコルを提供します。
2. Overview
2. 概要
2.1. DCAP Client/Server Model
2.1. DCAPクライアント/サーバモデル
+-----------+ +-----------+ +---------+
| 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 2114 DCAP February 1997
etチャン、アル。 [2ページ]情報のRFC2114DCAP1997年2月
+-----------+ +--------+
| Mainframe | | DCAP |
+--+--------+ +-----+ Client |
| | +--------+
| ppp
| |
+--+--+ +--------+ +------+------+
| FEP +- TR -+ DLSw +-- IP Backbone --+ DLSw Router |
+-----+ | Router | | DCAP Server |
+--------+ +------+------+
|
ppp
| +--------+
+-----+ DCAP |
| Client |
+--------+
+-----------+ +--------+ | メインフレーム| | DCAP| +--+--------+ +-----+ クライアント| | | +--------+ | ppp| | +--+--+ +--------+ +------+------+ | FEP+ TR-+DLSw+--IPバックボーン--+ DLSwルータ| +-----+ | ルータ| | DCAPサーバ| +--------+ +------+------+ | ppp| +--------+ +-----+ DCAP| | クライアント| +--------+
| DLSw Session | | DCAP Session |
+----------------------+ +--------------+
Figure 2-2. DLSw Client Access Protocol solves the scalability
problem.
| DLSwセッション| | DCAPセッション| +----------------------+ +--------------+ 図2-2。 DLSw Client Accessプロトコルはスケーラビリティ問題を解決します。
In a large network, DCAP addresses the scalability problem by significantly reducing the number of peers that connect to the central site router. The workstations (DCAP clients) and the router (DCAP server) behave in a Client/Server relationship. Workstations are attached to a DCAP server. A DCAP server has a single peer connection to the central site router.
大きいネットワークでは、DCAPは、中央のサイトルータに接続する同輩の数をかなり減少させることによって、そのスケーラビリティ問題を訴えます。 ワークステーション(DCAPクライアント)とルータ(DCAPサーバ)はClient/サーバ関係で振る舞います。 ワークステーションはDCAPサーバに取り付けられます。DCAPサーバには、中央のサイトルータには単独の同輩接続があります。
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アドレスがなければならないので、これは行政上徹底的です。
DCAP 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.
DCAPは、この問題を解決するのに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
クライアントがサーバにセッションを開始するように、ワークステーションはダイレクト要求をサーバに送ります。要求は送付先MACアドレスと目的地SAPを含みます。 ワークステーションは、それ自身のMACアドレスを指定するか、または1つを割り当てるサーバを要求できます。
Chiang, et. al. Informational [Page 3] RFC 2114 DCAP February 1997
etチャン、アル。 [3ページ]情報のRFC2114DCAP1997年2月
it. The server's IP address must be pre-configured on the workstation. If IP addresses are configured for multiple servers at a workstation, the request can be sent to these servers and the first one to respond will be used.
それ。 ワークステーションの上でサーバのIPアドレスをあらかじめ設定しなければなりません。 ワークステーションの複数のサーバのためにIPアドレスを構成するなら、これらのサーバに要求を送ることができます、そして、応じる最初のものを使用するでしょう。
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. A TCP session must be established between the client and the server before a frame 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関係しかありません。それは読まれた両方に使用されます、そして、操作を書いてください。
A race condition occurs when both client and server try to establish the TCP session with each other at the same time. The TCP session of the initiator with the lower IP address will be used. The other TCP session will be closed.
クライアントとサーバの両方が同時に互いとのTCPセッションを確立しようとするとき、競合条件は起こります。 低いIPアドレスとの創始者のTCPセッションは使用されるでしょう。 もう片方のTCPセッションは終えられるでしょう。
2.4 Multicast and Unicast (UDP)
2.4 マルチキャストとユニキャスト(UDP)
Multicast and unicast with UDP support are optional. In the reset of this session, when multicast and unicast are referenced, UDP is used. Two multicast addresses are reserved for DCAP. The server should listen for 224.0.1.49 and the client should listen for 224.0.1.50. Not all DCAP frames can be sent via multicast or unicast. The DATA_FRAME can be sent via either multicast or unicast. The CAN_U_REACH frame can be sent via multicast only and the I_CAN_REACH frame can be sent via unicast only. All other DCAP frames can only be sent via TCP sessions.
UDPサポートがあるマルチキャストとユニキャストは任意です。 UDPはこのセッションのリセットが使用されています。(その時、マルチキャストとユニキャストは参照をつけられます)。 2つのマルチキャストアドレスがDCAPのために予約されます。 サーバは224.0に.49とクライアントが聞こうとするべきである.1の聞こうとするべきです。224.0 .1 .50。 マルチキャストかユニキャストですべてのDCAPフレームを送ることができるというわけではありません。 マルチキャストかユニキャストのどちらかでDATA_FRAMEを送ることができます。 マルチキャストだけでCAN_U_REACHフレームを送ることができます、そして、ユニキャストだけでI_CAN_REACHフレームを送ることができます。 TCPセッションで他のすべてのDCAPフレームを送ることができるだけです。
When the multicast and unicast support is implemented, the client does not have to configure the server's IP address. When the client attempts to establish a session to the host, instead of establishing a TCP session with the pre-configured server, the client can multicast the CAN_U_REACH frame to the 224.0.1.49 group address. When the server receives this multicast frame, it will locate the
マルチキャストとユニキャストサポートが実装されるとき、クライアントはサーバのIPアドレスを構成する必要はありません。 クライアントが、セッションをホストに確立するのを試みるとき、あらかじめ設定されたサーバとのTCPセッションを確立することの代わりにクライアントはU_REACHが.1.49グループが扱う224.0に縁どるマルチキャストCAN_を試みることができます。 サーバがこのマルチキャストフレームを受けるとき、それは場所を見つけられるでしょう。
Chiang, et. al. Informational [Page 4] RFC 2114 DCAP February 1997
etチャン、アル。 [4ページ]情報のRFC2114DCAP1997年2月
destination as specified in the frame. If the destination is reachable by this server, it will send back an I_CAN_REACH frame to the sender via unicast. The client can initiate a TCP connection to the server and establish a DCAP session. If the I_CAN_REACH frame is received from multiple servers, the first one who returns the I_CAN_REACH frame will be used.
フレームの指定されるとしての目的地。 目的地がこのサーバで届くと、それはユニキャストでI_CAN_REACHフレームを送付者に返送するでしょう。 クライアントは、TCP接続をサーバに開始して、DCAPセッションを確立できます。 複数のサーバからI_CAN_REACHフレームを受け取ると、I_CAN_REACHフレームを返す最初の人を使用するでしょう。
When the host initiates a session to the client, the client does not have to pre-register its MAC address at the server. When the server attempts to reach an unknown client, it will multicast the CAN_U_REACH frame to the 224.0.10.50 group address. The client whose MAC address matches the destination address in the CAN_U_REACH frame will reply with the I_CAN_REACH frame via unicast. Once the server receives the I_CAN_REACH frame, it can establish a DCAP session with that client.
ホストがクライアントにセッションを開始するとき、クライアントはサーバでMAC住所を仮登録に知っていません。サーバが、未知のクライアントに届くのを試みるとき、それはU_REACHが.10.50グループが扱う224.0に縁どるマルチキャストCAN_を試みるでしょう。 MACがCAN_U_REACHフレームで送付先アドレスをマッチに扱うクライアントはI_CAN_REACHフレームでユニキャストで返答するでしょう。 サーバがいったんI_CAN_REACHフレームを受けると、それはそのクライアントとのDCAPセッションを確立できます。
For NetBIOS traffic, NAME_QUERY and ADD_NAME_QUERY can be encapsulated in the DATA_FRAME and sent out via multicast. NAME_RECOGNIZED and ADD_NAME_RESPONSE can be encapsulated in the DATA_FRAME but sent out via unicast. No other NetBIOS frames can be encapsulated in the DATA_FRAME to be sent out via either multicast or unicast.
NetBIOSトラフィック、NAME_QUERY、およびADD_に関しては、NAME_QUERYをDATA_FRAMEでカプセル化して、マルチキャストで出すことができます。 NAME_RECOGNIZEDとADD_NAME_RESPONSEをDATA_FRAMEでカプセル化しますが、ユニキャストで出すことができます。 マルチキャストかユニキャストのどちらかで出すためにDATA_FRAMEで他のNetBIOSフレームを全くカプセル化することができません。
When a client tries to locate a name or check for duplicate name on the network, it can multicast a NAME_QUERY or ADD_NAME_QUERY frame encapsulated in the DATA_FRAME. When a server receives these frames, NetBIOS NAME_QUERY or ADD_NAME_QUERY frames will be forwarded to LAN. If the NAME_RECOGNIZED or ADD_NAME_RESPONSE frame is received from LAN, they will be encapsulated in the DATA_FRAME and sent to the client via unicast.
クライアントがネットワークで名前の場所を見つけようとするか、または写し名がないかどうかチェックしようとするとき、それはNAME_QUERYかADD_NAME_QUERYフレームがDATA_FRAMEでカプセル化したマルチキャストをチェックできます。 サーバがこれらのフレームを受けるとき、NetBIOS NAME_QUERYかADD_NAME_QUERYフレームをLANに送るでしょう。 LANからNAME_RECOGNIZEDかADD_NAME_RESPONSEフレームを受け取ると、それらをDATA_FRAMEでカプセル化して、ユニキャストでクライアントに送るでしょう。
When a server receives a NetBIOS NAME_QUERY or ADD_NAME_QUERY from LAN, the server will encapsulate it in the DATA_FRAME and send it to all clients via multicast. When a client receives the frame and determines that the name specified in the DATA_FRAME matches its own name, a NAME_RECOGNIZED or ADD_NAME_RESPONSE frame will be encapsulated in the DATA_FRAME and sent back to the server via unicast.
サーバがLANからNetBIOS NAME_QUERYかADD_NAME_QUERYを受けるとき、サーバは、DATA_FRAMEでそれをカプセル化して、マルチキャストですべてのクライアントにそれを送るでしょう。 クライアントが、フレームを受け取って、名前がDATA_FRAMEマッチでそれ自身の名前を指定したと決心していると、NAME_RECOGNIZEDかADD_NAME_RESPONSEフレームはDATA_FRAMEでカプセル化されて、ユニキャストでサーバを送り返されるでしょう。
Chiang, et. al. Informational [Page 5] RFC 2114 DCAP February 1997
etチャン、アル。 [5ページ]情報のRFC2114DCAP1997年2月
3. DCAP Format
3. DCAP形式
3.1. General Frame Format
3.1. 一般フレーム形式
The General format of the DCAP frame is as follows:
DCAPフレームの一般形式は以下の通りです:
+-------------+-----------+-----------+
| DCAP Header | DCAP Data | User Data |
+-------------+-----------+-----------+
Figure 3-1. DCAP Frame Format
+-------------+-----------+-----------+ | DCAPヘッダー| DCAPデータ| 利用者データ| +-------------+-----------+-----------+ 図3-1。 DCAPフレーム形式
The DCAP protocol is contained in the DCAP header, which is common to all frames passed between the DCAP client and the server. This header is 4 bytes long. The next section will explain the details.
DCAPプロトコルはDCAPヘッダーに含まれています。(ヘッダーはDCAPクライアントとサーバの間を通り過ぎられたすべてのフレームに共通です)。このヘッダーは4バイト長です。 次のセクションは詳細について説明するでしょう。
The next part is the DCAP Data. The structure and the size are based on the type of messages carried in the DCAP frame. The DCAP data is used to process the frame, but it is optional.
次の部分はDCAP Dataです。 構造とサイズはDCAPフレームで伝えられるメッセージのタイプに基づいています。 DCAPデータはフレームを処理するのに使用されますが、それは任意です。
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番目の一部が利用者データです。(その利用者データはローカルシステムによってリモートシステムに送られます)。 このブロックのサイズは、可変であり、リモートシステムに送られるデータがあるときだけ、フレームに含まれています。
3.2. Header Format
3.2. ヘッダー形式
The DCAP 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 DCAP 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 DCAP data. The structure of the DCAP data depends on the type of frames, and will be discussed in detail in later sections.
DCAPヘッダーは、メッセージタイプとフレームの長さを特定するのに使用されます。 これはDCAPサーバとクライアントの間を通り過ぎられる各フレームに使用される汎用のヘッダーです。 詳しい情報が_CAN U_REACHと_I_CAN REACHのようなフレームに必要です、したがって、それはDCAPデータとして同輩に渡されます。 DCAPデータの構造について、フレームのタイプに頼っていて、後のセクションで詳細に議論するでしょう。
The DCAP Header is given below:
DCAP Headerを以下に与えます:
+-------------------------------------------+
| DCAP Packet Header (Each row is one byte) |
+===========================================+
0 | Protocol ID / Version Number |
+-------------------------------------------+
1 | Message Type |
+-------------------------------------------+
2 | Packet Length |
+ - - - - - - - - - - - - - - - - - - - - - +
3 | |
+-------------------------------------------+
Figure 3-2. DCAP Header Format
+-------------------------------------------+ | DCAP Packet Header(各行は1バイトです)| +===========================================+ 0 | プロトコルID/バージョン番号| +-------------------------------------------+ 1 | メッセージタイプ| +-------------------------------------------+ 2 | パケット長| + - - - - - - - - - - - - - - - - - - - - - + 3 | | +-------------------------------------------+ 図3-2。 DCAPヘッダー形式
Chiang, et. al. Informational [Page 6] RFC 2114 DCAP February 1997
etチャン、アル。 [6ページ]情報のRFC2114DCAP1997年2月
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 DCAP message type.
o メッセージタイプはDCAPメッセージタイプです。
o The Total Packet length is the length of the packet including the
DCAP header, DCAP data and User Data. The minimum size of the
packet is 4, which is the length of the header.
o Total Packetの長さはDCAPヘッダー、DCAPデータ、およびUser Dataを含むパケットの長さです。 パケットの最小規模は4です。(その4はヘッダーの長さです)。
3.3. DCAP Messages
3.3. DCAPメッセージ
Most of the DCAP frames are based on the existing DLSw frames and corresponding frames have similar names. The information in the corresponding DCAP and DLSw frames may differ; but the functionalities are the same. Thus the DLSw State Machine is used to handle these DCAP frames. Some new DCAP frames were created to handle special DCAP functions. For example, the new DCAP frames, I_CANNOT_REACH and START_DL_FAILED provide negative acknowledgment. The DLSw frames not needed for DCAP, are dropped.
DCAPフレームの大部分は既存のDLSwフレームに基づいています、そして、対応するフレームには、同様の名前があります。 対応するDCAPとDLSwフレームの情報は異なるかもしれません。 しかし、機能性は同じです。 したがって、DLSw州Machineは、これらのDCAPフレームを扱うのに使用されます。 いくつかの新しいDCAPフレームが、特別なDCAP機能を扱うために作成されました。 例えば、新しいDCAPフレーム、I_は_DL_FAILEDが否定応答を供給するREACHとSTART_がそうしません。 DCAPに必要でないDLSwフレーム、下げられます。
The following table lists and describes all available DCAP messages:
以下のテーブルは、すべての利用可能なDCAPメッセージをリストアップして、説明します:
DCAP 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
DCAPフレーム名コード機能--------------- ---- -------- CAN_U_REACH0×01Find、__CAN_U REACH I_へのCAN_REACH0x02Positive応答が与えられているステーションが届いているIであるなら失敗しない、_当然のことが、DL_STARTED0x05Session Started START_がDL_FAILED0x06Session Startであると扱うので、CAN_U_REACH START_DL0x04SetupセッションへのREACH0x03Negative応答はSABME STN_CONTACTEDを証明するためにXID_FRAME0x07XID Frame CONTACT_STN0x08Contactの目的地に失敗しました; 連絡された0×09駅--リンクINFO_FRAME 0x0B ConnectionのためのSABMEモードセットDATA_FRAME 0x0A Connectionless Data Frameは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セッションを回路に適応させました。
Chiang, et. al. Informational [Page 7] RFC 2114 DCAP February 1997
etチャン、アル。 [7ページ]情報のRFC2114DCAP1997年2月
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
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応答
Table 3-1. DCAP Frames
3-1をテーブルの上に置いてください。 DCAPフレーム
3.4. DCAP Data formats
3.4. DCAP Data形式
The DCAP data is used to carry information required for each DCAP frame. This information is used by the Server or the Client and it does not contain any user data. The DCAP 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.
DCAPデータは、それぞれのDCAPフレームに必要である情報を運ぶのに使用されます。 この情報はServerかClientによって使用されます、そして、それは少しの利用者データも含んでいません。 DCAPデータフレームタイプは以下のセクションで記載されています。 送付者は予約された分野をゼロに設定するべきです、そして、受信機はこれらの分野を無視するはずです。
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. When a server receives a CAN_U_REACH frame, it should send out an LLC explorer frame to locate the destination specified in the CAN_U_REACH frame. If the destination is reachable, the server responds to the client with an I_CAN_REACH frame. If the server does not receive a positive acknowledgment within a recommended threshold value of 5 seconds, the server should send an LLC explorer to locate the destination again. If the server does not receive any response after sending out 5 explorers (recommended retry value), the destination is considered not reachable and an I_CANNOT_REACH frame is sent back to the client. The client should decide if retry CAN_U_REACH is necessary after the I_CANNOT_REACH frame is received from the server.
これらのフレームタイプは、ネットワークでリソースの場所を見つけるのに使用されます。 リソースが届くかどうか決定するためにCAN_U_REACHフレームをサーバに送ります。 サーバがCAN_U_REACHフレームを受けるとき、それは、CAN_U_REACHフレームで指定された目的地の場所を見つけるようにLLC探検家フレームを出すべきです。 目的地が届くなら、サーバはI_CAN_REACHフレームでクライアントに反応します。 サーバが5秒のお勧めの閾値の中で肯定応答を受けないなら、LLC探検家は、再び目的地の場所を見つけにサーバで行くはずです。 5人の探検家(お勧めの再試行値)を派遣した後にサーバが少しの応答も受けないなら、目的地は届かないと考えられます、そして、I_は考えられません。REACHが縁どる_はクライアントに送り返されます。 クライアントは、I_は必要でなかった後に再試行CAN_U_REACHが必要であるならREACHが縁どる_がサーバから受け取られると決めるべきです。
When a server is in the process of searching a destination and receives another I_CAN_REACH with the same destination, the server should not send out another LLC explorer for that destination.
サーバが目的地を捜すことの途中にあって、_同じ目的地がある別のI_CAN REACHを受けるとき、サーバは別のLLC探検家をその目的地に派遣するべきではありません。
The server should not send the CAN_U_REACH frame to the clients in a TCP session. When a server receives an LLC explorer whose destination is a known client, the server should respond to it directly.
サーバはTCPセッションのときにCAN_U_REACHフレームをクライアントに送るべきではありません。 サーバが目的地が知られているクライアントであるLLC探検家を受けるとき、サーバは直接それに反応するべきです。
Chiang, et. al. Informational [Page 8] RFC 2114 DCAP February 1997
etチャン、アル。 [8ページ]情報のRFC2114DCAP1997年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をゼロに設定します。
3.4.2. START_DL, DL_STARTED, and START_DL_FAILED Frames
3.4.2. _dlを始めてください、dl_は始まって、_dlの_の失敗したフレームを始動します。
These frame types are used by DCAP 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 using the source and destination 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. If the attempt fails within a recommended value, 5 seconds, the server should retry again. If the server fails to establish a
これらのフレームタイプは、リンクステーション(回路)を証明するのにDCAPによって使用されます。 直接CAN_U_REACHフレームに反応するサーバにSTART_DLフレームを送ります。 サーバがこのフレームを受けるとき、それは、START_DLフレームに提供されたソース、送付先アドレス、および体液を使用することでリンクステーションを確立します。 回路設立がうまくいくなら、DL_STARTEDフレームは応答として返送されます。 試みが推奨値の中で失敗するなら、5秒、サーバは再び再試行するべきです。 サーバがaを設立しないなら
Chiang, et. al. Informational [Page 9] RFC 2114 DCAP February 1997
etチャン、アル。 [9ページ]情報のRFC2114DCAP1997年2月
circuit for a recommended retry value, 5 times, a START_DL_FAILED frame should be sent back to the client. If the client receives a START_DL_FAILED frame from the server, it is up to the client to decide if a START_DL frame needs to be sent to the server again.
お勧めの再試行値、5回、START_DL_FAILEDフレームがクライアントに返送されるべきであるaのための回路。 クライアントがサーバからSTART_DL_FAILEDフレームを受け取るなら、START_DLフレームが、再びサーバに送られる必要であるかどうか決めるのは、クライアント次第です。
The server can also send START_DL frames to clients to establish circuits.
また、サーバは、回路を証明するために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 10] RFC 2114 DCAP February 1997
etチャン、アル。 [10ページ]情報のRFC2114DCAP1997年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 11] RFC 2114 DCAP February 1997
etチャン、アル。 [11ページ]情報のRFC2114DCAP1997年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 DCAP does not use a three-way handshake for link station establishment. In the DL_STARTED and the START_DL_FAILED frames, 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 frame.
Origin Session IDは回路を開始する起因するステーションのIDです。 起因するステーションは、新たに作成された回路を特定するのにこのIDを使用します。 START_DLフレームを目標ステーションに送る前に、起因するステーションは回路のための制御ブロックをセットアップします。 DCAPがリンクステーション設立に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 specifies the receive window size on the originating side, and the target DCAP 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ウィンドウサイズは起因する側のレシーブ・ウィンドウ・サイズを指定します、そして、目標DCAPステーションは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 12] RFC 2114 DCAP February 1997
etチャン、アル。 [12ページ]情報のRFC2114DCAP1997年2月
3.4.3. HALT_DL, HALT_DL_NOACK, and DL_HALTED Frames
3.4.3. _dlを止めてください、そして、_dl_ノアク、およびdlの_の停止しているフレームを止めてください。
These frame types are used by DCAP to disconnect a link station. A HALT_DL frame is sent directly to the remote workstation to indicate that the sender wishes to disconnect a session. 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 frame without swapping them. The HALT_DL_NOACK frame is used when the response is not required. The TCP session between the client and server should remain up after the HALT_DL/DL_HALTED/ HALT_DL_NOACK exchange.
これらのフレームタイプは、リンクがステーションであると切断するのにDCAPによって使用されます。 送付者がセッションから切断したがっているのを示すためにHALT_DLフレームを直接遠隔ワークステーションに送ります。 受信機がこのフレームを受けるとき、それはHALT_DLフレームに提供するOriginal Session IDとTarget Session IDに関連しているセッションを取りこわします。 受信機はDL_HALTEDフレームで応じるはずです。 容認されたHALT_DLがスワッピングなしでそれらを縁どるとき、DL_HALTEDフレームはSession IDが評価する同じくらいを使用するはずです。 応答は必要でないときに、HALT_DL_ノアクフレームが使用されています。 クライアントとサーバとのTCPセッションはHALT_DL/DL_HALTED/ 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 13] RFC 2114 DCAP February 1997
etチャン、アル。 [13ページ]情報のRFC2114DCAP1997年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 DCAP Header
+---------------+----------------------------+ | フィールド名| 情報| +---------------+----------------------------+ | メッセージタイプ| Messageタイプに基づいています。| +---------------+----------------------------+ | パケット長| 利用者データの0x0C+長さ| +---------------+----------------------------+ 図3-10。 ジェネリックDCAPヘッダー
Chiang, et. al. Informational [Page 14] RFC 2114 DCAP February 1997
etチャン、アル。 [14ページ]情報のRFC2114DCAP1997年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 DCAP Data Format
+-----------------------------------+ | 分野Name(各行は1バイトです)| +===================================+ 0 | 目的地セッションID| + - - - - - - - - - - - - - - - - - + 1 | | + - - - - - - - - - - - - - - - - - + 2 | | + - - - - - - - - - - - - - - - - - + 3 | | +-----------------------------------+ 4 | フロー制御旗| +-----------------------------------+ 5 | 予約されます。| + - - - - - - - - - - - - - - - - - + 6 | | + - - - - - - - - - - - - - - - - - + 7 | | +-----------------------------------+ 図3-11。 ジェネリックDCAPデータの形式
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 15] RFC 2114 DCAP February 1997
etチャン、アル。 [15ページ]情報のRFC2114DCAP1997年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 DCAP, the capability exchange frame is used to exchange the capability information between a client and a server. CAP_XCHANGE frames are exchanged between a client and a server as soon as the TCP session is established. The capability exchange must be completed before the other frame types can be sent. Once the capability exchange is done, CAP_XCHANGE frame should not be used again.
DCAPでは、クライアントとサーバの間で能力情報を交換するのに能力交換フレームを使用します。TCPセッションが確立されるとすぐに、クライアントとサーバの間でCAP_XCHANGEフレームを交換します。 他のフレームタイプを送ることができる前に能力交換を終了しなければなりません。 能力交換がいったん完了していると、再びXCHANGEが縁どるCAP_を使用するべきではありません。
Chiang, et. al. Informational [Page 16] RFC 2114 DCAP February 1997
etチャン、アル。 [16ページ]情報のRFC2114DCAP1997年2月
CAP_XCHANGE frame contains the clients MAC address, if a client has one. If it does not, then the MAC address field must be set to zero. When the DCAP server receives the CAP_XCHANGE frame, it should cache the MAC address if it is non zero. The DCAP 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 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.
クライアントに1つがあるなら、XCHANGEが縁どるCAP_はクライアントMACアドレスを含んでいます。 それがそうしないなら、MACアドレス・フィールドをゼロに設定しなければなりません。 DCAPサーバがCAP_XCHANGEフレームを受けるとき、それは非ゼロであるならMACアドレスをキャッシュするべきです。 また、DCAPサーバは、MACアドレスがユニークであることを確かめます。 MACアドレスを受け入れるなら、MACアドレスがクライアントによって供給されている状態で、サーバはCAP_XCHANGEレスポンス・フレームを返すべきです。 クライアントがそれ自身の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は単にクライアントによって使用されます。 サーバがコマンド/応答をクライアントに送るとき、サーバはこれらの値を返しません。
Chiang, et. al. Informational [Page 17] RFC 2114 DCAP February 1997
etチャン、アル。 [17ページ]情報のRFC2114DCAP1997年2月
Starting with the Reserved field, implementers 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 ensure compatibility, implementers should ignore the unknown Control Vectors instead of treating them as errors.
Reserved野原から始まって、implementersは任意にCapability Exchange Control Vectorを実装することができます。 各Capability Exchange Control Vectorは3つの分野から成ります: 長さ(1バイト)、Type(1バイト)、およびData(長さ--2バイト)。 Control Vectorsの2つのタイプが定義されます: SAP_LISTとVENDOR_CODE(以下で、説明されます)。 互換性を確実にするために、implementersは誤りとして彼らを扱うことの代わりに未知の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: 3 bytes.
Each vendor is assigned a vendor code that identifies the
vendor. This Control Vector does not require a response.
0×02 ベンダー_コード。 長さ: 3バイト。 ベンダーを特定するベンダーコードは各ベンダーに配属されます。 この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 18] RFC 2114 DCAP February 1997
etチャン、アル。 [18ページ]情報のRFC2114DCAP1997年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 19] RFC 2114 DCAP February 1997
etチャン、アル。 [19ページ]情報のRFC2114DCAP1997年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 DCAP
+---------------+-----------------------+ | フィールド名| 情報| +---------------+-----------------------+ | メッセージタイプ| 0×14、0x1D、または0x1E| +---------------+-----------------------+ | パケット長| 0×04| +---------------+-----------------------+ 図3-18。 _同輩_RSP、_同輩_テストREQ、および_同輩_テストRSP DCAPを閉じてください。
4. Protocol Flow Diagram
4. プロトコルフローチャート
The following diagram shows a normal session start up/tear down sequence between a client and a server.
以下のダイヤグラムは正常なセッション始動/裂け目をクライアントとサーバの間の系列の下側に示しています。
Chiang, et. al. Informational [Page 20] RFC 2114 DCAP February 1997
etチャン、アル。 [20ページ]情報のRFC2114DCAP1997年2月
+-----------+ +-------+
+-----------+ Token | DLSw/DCAP | | DCAP |
| Mainframe +- Ring ---+ Router +-- ip backbone--+ Client|
+-----------+ +-----------+ +-------+
+-----------+ +-------+ +-----------+ トークン| DLSw/DCAP| | DCAP| | メインフレーム+は鳴ります。---+ ルータ+--ipバックボーン--+ クライアント| +-----------+ +-----------+ +-------+
TCP Session Up
<-------------
CAP_EXCHANGE (cmd)
<-------------
CAP_EXCHANGE (cmd)
------------->
CAP_EXCHANGE (rsp)
------------->
TEST(P) CAN_U_REACH
<-------- <-------------
TEST(F) I_CAN_REACH
--------> ------------->
START_DL
<-------------
DL_STARTED
------------->
XID(P) XID_FRAME
<-------- <-------------
XID(F) XID_FRAME
--------> ------------->
XID(P) XID_FRAME
<-------- <-------------
SABME CONTACT_STN
--------> ------------->
UA STN_CONTACTED
<-------- <-------------
I FRAME INFO_FRAME
<-------- <-------------
I FRAME INFO_FRAME
--------> ------------->
DISC HALT_DL
<-------- <-------------
UA DL_HALTED
--------> ------------->
CLOSE_PEER_REQ
<-------------
CLOSE_PEER_RSP
------------->
TCP session down
<-------------
<へのTCPセッション------------- 上限_交換(cmd)<。------------- 上限_交換(cmd)------------->上限_交換(rsp)------------->TEST(P)缶の_U_範囲<。-------- <、-、-、-、-、-、-、-、-、-、-、-、-- テスト(F)I_缶_範囲-------->。------------->始め_dl<。------------- dl_は始まりました。------------->XID(P) XID_フレーム<。-------- <、-、-、-、-、-、-、-、-、-、-、-、-- XID(F) XID_フレーム-------->。------------->XID(P) XID_フレーム<。-------- <、-、-、-、-、-、-、-、-、-、-、-、-- SABME接触_STN-------->。------------->Ua STN_は<に連絡しました。-------- <、-、-、-、-、-、-、-、-、-、-、-、-- 私はインフォメーション_フレーム<を縁どります。-------- <、-、-、-、-、-、-、-、-、-、-、-、-- 私はインフォメーション_フレームを縁どります。-------->。------------->ディスク停止_dl<。-------- <、-、-、-、-、-、-、-、-、-、-、-、-- Ua dl_は停止しました。-------->。------------->の近い_同輩_REQ<。------------- _同輩_RSPを閉じてください。-------------<の下側への>TCPセッション-------------
Chiang, et. al. Informational [Page 21] RFC 2114 DCAP February 1997
etチャン、アル。 [21ページ]情報のRFC2114DCAP1997年2月
5. Acknowledgments
5. 承認
The authors wish to express thanks to Rodger Erickson of Wall Data, Inc. for his helpful comments and suggestions.
作者はロジャーのおかげで彼の役に立つコメントと提案のためにWall Data Inc.のエリクソンを言い表したがっています。
6. References
6. 参照
[1] AIW DLSw Related Interest Group, RFC 1795,
"DLSw: Switch-to-Switch Protocol", April 1995
[1] AIW DLSwが営利団体、RFC1795を関係づけた、「DLSw:」 「スイッチからスイッチへのプロトコル」、1995年4月
[2] IBM Token Ring Network Architecture Reference
SC30-3374-02, September 1989.
[2] IBMトークンリングネットワークアーキテクチャ参照SC30-3374-02、1989年9月。
[3] IBM LAN Technical Reference IEEE 802.2 and NETBIOS Application
Program Interfaces SC30-3587-00, December 1993.
[3] IBMのLANの技術的な参照IEEE802.2とNETBIOS適用業務プログラム・インタフェースSC30-3587-00、1993年12月。
[4] ISO 8802-2/IEEE Std 802.1D International Standard.
[4] ISO8802-2/IEEE Std 802.1D国際規格。
Authors' Addresses
作者のアドレス
Steve T. Chiang InterWorks Business Unit Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134 Phone: (408) 526-5189 EMail: schiang@cisco.com
スティーブ・T.チャンは、ビジネス部がサンノゼ、カリフォルニア 95134が電話をするシスコシステムズInc.170タスマンDriveであると織り込みます: (408) 526-5189 メールしてください: schiang@cisco.com
Joseph S. Lee InterWorks Business Unit Cisco Systems, Inc. 170 Tasman Drive San Jose, CA 95134 Phone: (408) 526-5232 EMail: jolee@cisco.com
ジョゼフ・S.リーは、ビジネス部がサンノゼ、カリフォルニア 95134が電話をするシスコシステムズInc.170タスマンDriveであると織り込みます: (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 Phone: +81-467-47-2120 EMail: yasuda@eme068.cow.melco.co.jp
Hideaki安田のシステム製品センターネットワーク製品部のネットワークソフト製品部分B三菱電気社の情報システム工学は325、Kamimachiya鎌倉神奈川247を中心に置きます、日本電話: +81-467-47-2120 メールしてください: yasuda@eme068.cow.melco.co.jp
Chiang, et. al. Informational [Page 22]
etチャン、アル。 情報[22ページ]
一覧
スポンサーリンク
