RFC2166 日本語訳
2166 APPN Implementer's Workshop Closed Pages Document DLSw v2.0Enhancements. D. Bryant, P. Brittain. June 1997. (Format: TXT=75527 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Bryant
Request for Comments: 2166 3Com Corp
Category: Informational P. Brittain
Data Connection Ltd.
June 1997
コメントを求めるワーキンググループD.ブライアント要求をネットワークでつないでください: 2166年の3Com Corpカテゴリ: 情報のP.Brittainデータ接続株式会社1997年6月
APPN Implementer's Workshop
Closed Pages Document
APPN Implementerのワークショップの閉じているページドキュメント
DLSw v2.0 Enhancements
DLSw v2.0 Enhancements
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 document specifies
このドキュメントは指定します。
- a set of extensions to RFC 1795 designed to improve the scalability
of DLSw
- clarifications to RFC 1795 in the light of the implementation
experience to-date.
- DLSwのスケーラビリティを改良するように設計されたRFC1795への1セットの拡大--これまでの実装経験の光におけるRFC1795への明確化。
It is assumed that the reader is familiar with DLSw and RFC 1795. No effort has been made to explain these existing protocols or associated terminology.
読者がDLSwとRFC1795に詳しいと思われます。 取り組みは全くこれらの既存のプロトコルか関連用語について説明させられていません。
This document was developed in the DLSw Related Interest Group (RIG) of the APPN Implementers Workshop (AIW). If you would like to participate in future DLSw discussions, please subscribe to the DLSw RIG mailing lists by sending a mail to majordomo@raleigh.ibm.com specifying 'subscribe aiw-dlsw' as the body of the message.
このドキュメントはAPPN Implementers Workshop(AIW)のDLSwの関連Interest Group(RIG)で開発されました。 今後のDLSw議論に参加したいなら、メッセージ欄として'aiw-dlswを申し込んでください'を指定する majordomo@raleigh.ibm.com にメールを送ることによって、DLSw RIGメーリングリストに加入してください。
Table of Contents
目次
1. INTRODUCTION ................................................ 3
2. HALT REASON CODES............................................ 3
3. SCOPE OF SCALABILITY ENHANCEMENTS............................ 4
4. OVERVIEW OF SCALABILITY ENHANCEMENTS......................... 6
5. MULTICAST GROUPS AND ADDRESSING.............................. 7
5.1 USING MULTICAST GROUPS...................................... 8
5.2 DLSW MULTICAST ADDRESSES.................................... 8
6. DLSW MESSAGE TRANSPORTS...................................... 8
6.1 TCP/IP CONNECTIONS ON DEMAND................................ 9
6.1.1 TCP CONNECTIONS ON DEMAND RACE CONDITIONS................ 9
1. 序論… 3 2. 理由コードを止めてください… 3 3. スケーラビリティ増進の範囲… 4 4. スケーラビリティ増進の概要… 6 5. マルチキャストはANDアドレシングを分類します… 7 5.1 マルチキャストを使用するのは分類されます… 8 5.2 DLSWマルチキャストアドレス… 8 6. DLSWメッセージ転送… 8 6.1 オンデマンドのTCP/IP接続… 9 6.1 .1 TCPのコネクションズのオンデマンドの競合条件… 9
Bryant & Brittain Informational [Page 1] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[1ページ]のRFC2166APPN Implementerのワークショップ1997年6月
6.2 SINGLE SESSION TCP/IP CONNECTIONS........................... 9
6.2.1 EXPEDITED SINGLE SESSION TCP/IP CONNECTIONS.............. 10
6.2.1.1 TCP PORT NUMBERS...................................... 10
6.2.1.2 TCP CONNECTION SETUP.................................. 10
6.2.1.3 SINGLE SESSION SETUP RACE CONDITIONS.................. 10
6.2.1.4 TCP CONNECTIONS WITH NON-MULTICAST CAPABLE DLSW PEERS. 11
6.3 UDP DATAGRAMS............................................... 12
6.3.1 VENDOR SPECIFIC FUNCTIONS OVER UDP....................... 12
6.3.2 UNICAST UDP DATAGRAMS.................................... 12
6.3.3 MULTICAST UDP DATAGRAMS.................................. 13
6.4 UNICAST UDP DATAGRAMS IN LIEU OF IP MULTICAST............... 13
6.5 TCP TRANSPORT............................................... 14
7. MIGRATION SUPPORT............................................ 14
7.1 CAPABILITIES EXCHANGE....................................... 14
7.2 CONNECTING TO NON-MULTICAST CAPABLE NODES................... 15
7.3 COMMUNICATING WITH MULTICAST CAPABLE NODES.................. 15
8. SNA SUPPORT.................................................. 16
8.1 ADDRESS RESOLUTION.......................................... 16
8.2 EXPLORER FRAMES............................................. 16
8.3 CIRCUIT SETUP............................................... 17
8.4 EXAMPLE SNA SSP MESSAGE SEQUENCE............................ 17
8.5 UDP RELIABILITY............................................. 19
8.5.1 RETRIES.................................................. 19
9. NETBIOS...................................................... 20
9.1 ADDRESS RESOLUTION.......................................... 21
9.2 EXPLORER FRAMES............................................. 21
9.3 CIRCUIT SETUP............................................... 21
9.4 EXAMPLE NETBIOS SSP MESSAGE SEQUENCE........................ 22
9.5 MULTICAST RELIABILITY AND RETRIES........................... 24
10. SEQUENCING.................................................. 24
11. FRAME FORMATS............................................... 25
11.1 MULTICAST CAPABILITIES CONTROL VECTOR...................... 25
11.1.1 DLSW CAPABILITIES NEGATIVE RESPONSE..................... 26
11.2 UDP PACKETS................................................ 26
11.3 VENDOR SPECIFIC UDP PACKETS................................ 27
12. COMPLIANCE STATEMENT........................................ 28
13. SECURITY CONSIDERATIONS..................................... 29
14. ACKNOWLEDGEMENTS............................................ 29
15. AUTHORS' ADDRESSES.......................................... 30
16. APPENDIX - CLARIFICATIONS TO RFC 1795....................... 31
6.2 セッションTCP/IP接続を選抜してください… 9 6.2 .1は単独のセッションTCP/IP接続を速めました… 10 6.2 .1 .1 TCPは数を移植します… 10 6.2 .1 .2 TCP接続設定… 10 6.2 .1 .3 ただ一つのセッションセットアップ競合条件… 10 6.2 .1 .4 非マルチキャストのできるDLSWがあるTCPコネクションズはじっと見ます。 11 6.3 UDPデータグラム… 12 6.3 .1 UDPの上のベンダー具体的な機能… 12 6.3 .2 ユニキャストUDPデータグラム… 12 6.3 .3 マルチキャストUDPデータグラム… 13 6.4 IPマルチキャストの代わりにユニキャストUDPデータグラム… 13 6.5 TCP輸送… 14 7. 移行サポート… 7.1の能力が交換する14… 14 7.2 非マルチキャストのできるノードに接続します… 15 7.3 マルチキャストのできるノードとコミュニケートします… 15 8. SNAサポート… 16 8.1 解決を扱ってください… 16 8.2 探検家フレーム… 16 8.3 回路セットアップ… 17 8.4 例のSNA SSPメッセージ系列… 17 8.5 UDPの信頼性… 19 8.5 .1 再試行します… 19 9. NETBIOS… 20 9.1 解決を扱ってください… 21 9.2 探検家フレーム… 21 9.3 回路セットアップ… 21 9.4 例のNETBIOS SSPメッセージ系列… 22 9.5マルチキャスト信頼性のANDは再試行されます… 24 10. 配列します。 24 11. 形式を縁どってください… 25 11.1 マルチキャスト能力はベクトルを制御します… 25 11.1.1 DLSW能力否定応答… 26 11.2 UDPパケット… 26 11.3 ベンダーの特定のUDPパケット… 27 12. 承諾声明… 28 13. セキュリティ問題… 29 14. 承認… 29 15. 作者のアドレス… 30 16. 付録--、RFC1795への明確化… 31
Bryant & Brittain Informational [Page 2] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[2ページ]のRFC2166APPN Implementerのワークショップ1997年6月
1. Introduction
1. 序論
This document defines v2.0 of Data Link Switching (DLSw) in the form of a set of enhancements to RFC 1795. These enhancements are designed to be fully backward compatible with existing RFC 1795 implementations. As a compatible set of enhancements to RFC 1795, this document does not replace or supersede RFC 1795.
このドキュメントは1セットの増進の形でData Link Switching(DLSw)のv2.0をRFC1795と定義します。 これらの増進は、既存のRFC1795実装と互換性があった状態で完全に後方であるために設計されています。 RFC1795へのコンパチブル増進として、このドキュメントは、RFC1795に取って代わりもしませんし、取って代わりもしません。
The bulk of these enhancements address scalability issues in DLSw v1.0. Reason codes have also been added to the HALT_DL and HALT_DL_NOACK SSP messages in order to improve the diagnostic information available.
アドレススケーラビリティがDLSw v1.0で発行するこれらの増進の大半。 また、利用可能な診断情報を改良するためにHALT_DLとHALT_DL_NOACK SSPメッセージに理由コードを追加してあります。
Finally, the appendix to this document lists a number of clarifications to RFC 1795 where the implementation experience to- date has shown that the original RFC was ambiguous or unclear. These clarifications should be read alongside RFC 1795 to obtain a full specification of the base v1.0 DLSw standard.
最終的に、このドキュメントへの付録が多くの明確化をRFC1795に記載する、実装がなるどこ、-、日付は、オリジナルのRFCがあいまいであるか、または不明瞭であったのを示したか。 これらの明確化は、RFC1795と並んでベースv1.0 DLSw規格の完全な仕様を得るために読まれるべきです。
2. HALT Reason codes
2. HALT Reasonコード
RFC 1795 provides no mechanism for a DLSw to communicate to its peer the reason for dropping a circuit. DLSw v2.0 adds reason code fields to the HALT_DL and HALT_DL_NOACK SSP messages to carry this information.
DLSwが回路を下げる理由を同輩に伝えるように、RFC1795はメカニズムを全く提供しません。 DLSw v2.0はHALT_DLとこの情報を運ぶHALT_DL_NOACK SSPメッセージに理由コード分野を追加します。
The reason code is carried as 6 bytes of data after the existing SSP header. The format of these bytes is as shown below.
理由コードは既存のSSPヘッダーの後に6バイトのデータとして運ばれます。 以下で示されるとしてこれらのバイトの形式があります。
Byte Description 0-1 Generic HALT reason code in byte normal format
バイト記述0-1Generic HALTはバイトの正常な形式でコードを推論します。
2-5 Vendor-specific detailed reason code
2-5 ベンダー特有の詳細な理由コード
The generic HALT reason code takes one of the following decimal values (which are chosen to match the disconnect reason codes specified in the DLSw MIB).
ジェネリックHALT理由コードは以下のデシマル値の1つを取ります(どれが分離理由コードを合わせるために選ばれているかはDLSw MIBで指定しました)。
1 - Unknown error 2 - Received DISC from end-station 3 - Detected DLC error with end-station 4 - Circuit-level protocol error (e.g., pacing) 5 - Operator-initiated (mgt station or local console)
1--2--端3番射台からの容認されたDISC--端4番射台(回路レベルプロトコル誤り(例えば、ペース)5)がある検出されたDLC誤りがオペレータと同じくらい開始した未知の誤り(mgtステーションか地方のコンソール)
The vendor-specific detailed reason code may take any value.
ベンダー特有の詳細な理由コードはどんな値も取るかもしれません。
Bryant & Brittain Informational [Page 3] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[3ページ]のRFC2166APPN Implementerのワークショップ1997年6月
All V2.0 DLSws must include this information on all HALT_DL and HALT_DL_NOACK messages sent to v2.0 DLSw peers. For backwards compatibility with RFC 1795, DLSw V2.0 implementations must also accept a HALT_DL or HALT_DL_NOACK message received from a DLSw peer that does not carry this information (i.e. RFC 1795 format for these SSP messages).
すべてのV2.0 DLSwsがDL_ノアクメッセージがv2.0 DLSw同輩に送ったすべてのHALT_DLとHALT_のこの情報を含まなければなりません。 また、RFC1795との遅れている互換性のために、DLSw V2.0実装はこの情報(すなわち、これらのSSPメッセージのためのRFC1795形式)を運ばないDLSw同輩から受け取られたHALT_DLかHALT_DL_ノアクメッセージを受け入れなければなりません。
3. Scope of Scalability Enhancements
3. スケーラビリティ増進の範囲
The DLSw Scalability group of the AIW identified a number of scalability issues associated with existing DLSw protocols as defined in RFC 1795:
AIWのDLSw ScalabilityグループはRFC1795で定義されるように既存のDLSwプロトコルに関連している多くのスケーラビリティ問題を特定しました:
- Administration
- 政権
RFC 1795 implies the need to define the transport address of all
DLSw peers at each DLSw. In highly meshed situations (such as
those often found in NetBIOS networks), the resultant
administrative burden is undesirable.
RFC1795は各DLSwのすべてのDLSw同輩の輸送アドレスを定義する必要性を含意します。 非常にかみ合っている状況(NetBIOSネットワークでしばしば見つけられたものなどの)で、結果の管理負担は望ましくありません。
- Address Resolution
- アドレス解決
RFC 1795 defines point to point TCP (or other reliable transport
protocol) connections between DLSw peers. When attempting to
discover the location of an unknown resource, a DLSw sends an
address resolution packet to each DLSw peer over these connections.
In highly meshed configurations, this can result in a very large
number of packets in the transport network. Although each packet
is sent individually to each DLSw peer, they are each identical in
nature. Thus the transport network is burdened with excessive
numbers of identical packets. Since the transport network is most
commonly a wide area network, where bandwidth is considered a
precious resource, this packet duplication is undesirable.
RFC1795は、DLSw同輩の間のTCP(または、他の信頼できるトランスポート・プロトコル)接続を指すためにポイントを定義します。 未知のリソースの位置を発見するのを試みるとき、DLSwはこれらの接続の上でアドレス解決パケットをそれぞれのDLSw同輩に送ります。 非常にかみ合っている構成では、これは転送ネットワークで非常に多くのパケットをもたらすことができます。 個別にそれぞれのDLSw同輩に各パケットを送りますが、それらはそれぞれ現実に同じです。 したがって、転送ネットワークは過度の数の同じパケットで負担されます。 転送ネットワークが最も一般的に帯域幅が貴重なリソースであると考えられるところの広域ネットワークであるので、このパケット重複は望ましくありません。
- Broadcast Packets
- 放送パケット
In addition to the address resolution packets described above, RFC
1795 also propagates NetBIOS broadcast packets into the transport
network. The UI frames of NetBIOS are sent as LAN broadcast
packets. RFC 1795 propagates these packets over the point to point
transport connections to each DLSw peer. In the same manner as
above, this creates a large number of identical packets in the
transport network, and hence is undesirable. Since NetBIOS UI
frames can be sent by applications, it is difficult to predict or
control the rate and quantity of such traffic. This compounds the
undesirability of the existing RFC 1795 propagation method for
these packets.
また、上で説明されたアドレス解決パケットに加えて、RFC1795はNetBIOS放送パケットを転送ネットワークに伝播します。 LAN放送パケットとしてNetBIOSのUIフレームを送ります。 RFC1795は、それぞれのDLSw同輩に輸送の接続を向けるためにポイントの上でこれらのパケットを伝播します。 同じ方法で、これは、同じくらい上では、転送ネットワークで多くの同じパケットを作成して、したがって、望ましくありません。 アプリケーションでNetBIOS UIフレームを送ることができるので、そのようなトラフィックのレートと量を予測するか、または制御するのが難しいです。 これはこれらのパケットのために既存のRFC1795伝播メソッドの不適性を合成します。
Bryant & Brittain Informational [Page 4] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[4ページ]のRFC2166APPN Implementerのワークショップ1997年6月
- TCP (transport connection) Overhead
- TCP(輸送接続)オーバーヘッド
As defined in RFC 1795, each DLSw maintains a transport connection
to its DLSw peers. Each transport connection guarantees in order
packet delivery. This is accomplished using acknowledgment and
sequencing algorithms which require both CPU and memory at the DLSw
endpoints in direct proportion to the number transport connections.
The DLSw Scalability group has identified two scenarios where the
number of transport connections can become significant resulting in
excessive overhead and corresponding equipment costs (memory and
CPU). The first scenario is found in highly meshed DLSw
configurations where the number of transport connections
approximates n2 (where n is the number of DLSw peers). This is
typically found in DLSw networks supporting NetBIOS. The second
scenario is found in networks where many remote locations
communicate to few central sites. In this case, the central sites
must support n transport connections (where n is the number of
remote sites). In both scenarios the resultant transport
connection overhead is considered undesirable depending upon the
value of n.
RFC1795で定義されるように、各DLSwはDLSw同輩に輸送接続を維持します。 接続がオーダーパケット配信で保証する各輸送。 これは数の輸送の接続に直接比例してDLSw終点でCPUとメモリの両方を必要とする承認と配列アルゴリズムを使用するのに優れています。 DLSw Scalabilityグループは輸送の接続の数が過度のオーバーヘッドと対応する設備コスト(メモリとCPU)をもたらしながら重要になることができる2つのシナリオを特定しました。 輸送の接続の数がn2(nがDLSw同輩の数であるところ)に近似するところで最初のシナリオは非常にかみ合っているDLSw構成で見つけられます。 これはNetBIOSをサポートするDLSwネットワークで通常見つけられます。 2番目のシナリオは多くの離れた場所がわずかな主要なサイトに交信するネットワークで見つけられます。 この場合、主要なサイトは、nが輸送の接続(nがリモートサイトの数であるところ)であるとサポートしなければなりません。 両方のシナリオでは、nの値によって、結果の輸送接続オーバーヘッドは望ましくないと考えられます。
- LLC2 overhead
- LLC2オーバーヘッド
RFC 1795 specifies that each DLSw provides local termination for
the LLC2 (SDLC or other SNA reliable data link protocol) sessions
traversing the SSP. Because these reliable data links provide
guaranteed in order packet delivery, the memory and CPU overhead of
maintaining these connections can also become significant. This
is particularly undesirable in the second scenario described above,
because the number of reliable connections maintained at the
central site is the aggregate of the connections maintained at each
remote site.
RFC1795は、各DLSwがLLC2(SDLCか他のSNA確実な資料リンク・プロトコル)セッションのためにSSPを横断しながら地方の終了を提供すると指定します。 これらの確実な資料リンクがオーダーパケット配信で保証を与えるので、また、これらの接続を維持するメモリとCPUオーバーヘッドは重要になることができます。 これは上で説明された2番目のシナリオで特に望ましくありません、主要なサイトで維持された頼もしい接続の数が各リモートサイトで維持された接続の集合であるので。
It is not the intent of this document to address all the undesirable scalability issues associated with RFC 1795. This paper identifies protocol enhancements to RFC 1795 using the inherent multicast capabilities of the underlying transport network to improve the scalability of RFC 1795. It is believed that the enhancements defined, herein, address many of the issues identified above, such as administration, address resolution, broadcast packets, and, to a lesser extent, transport overhead. This paper does not address LLC2 overhead. Subsequent efforts by the AIW and/or DLSw Scalability group may address the unresolved scalability issues.
すべての望ましくないスケーラビリティがRFC1795に関連している問題であると扱うのは、このドキュメントの意図ではありません。 この論文は、基本的な転送ネットワークがRFC1795のスケーラビリティを改良する固有のマルチキャスト能力を使用することでRFC1795にプロトコル増進を特定します。 増進がここに問題の多くが上で特定したアドレスを定義したと信じられています、管理や、アドレス解決や、放送パケットや、ある程度輸送オーバーヘッドなどのように。 この紙は、LLC2がオーバーヘッドであると扱いません。 AIW、そして/または、DLSw Scalabilityグループによるその後の取り組みは、未定のスケーラビリティが問題であると扱うかもしれません。
Bryant & Brittain Informational [Page 5] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[5ページ]のRFC2166APPN Implementerのワークショップ1997年6月
While it is the intent of this paper to accommodate all transport protocols as best as is possible, it is recognized that the multicast capabilities of many protocols is not yet well defined, understood, or implemented. Since TCP is the most prevalent DLSw transport protocol in use today, the DLSw Scalability group has chosen to focus its definition around IP based multicast services. This document only addresses the implementation detail of IP based multicast services.
それはよく可能であるように多くのプロトコルのマルチキャスト能力がそうでないと特に認められませんが、定義するか、理解しているか、または実装されて、この紙がすべてのトランスポート・プロトコルに対応する意図ですが。 今日TCPが使用中の最も一般的なDLSwトランスポート・プロトコルであるので、DLSw Scalabilityグループは、IPのベースのマルチキャストサービスの周りで定義の焦点を合わせるのを選びました。 このドキュメントはIPの細部が基礎づけた実装にマルチキャストサービスを扱うだけです。
This proposal does not consider the impacts of IPv6 as this was considered too far from widespread use at the time of writing.
これが普及使用からあまりにはるかにこれを書いている時点で考えられたとき、この提案はIPv6の影響を考えません。
4. Overview of Scalability Enhancements
4. スケーラビリティ増進の概要
This paper describes the use of multicast services within the transport network to improve the scalability of DLSw based networking. There are only a few main components of this proposal:
この論文は、DLSwのベースのネットワークのスケーラビリティを改良するために転送ネットワークの中でマルチキャストサービスの使用について説明します。 この提案のほんのいくつかの主な成分があります:
- Single session TCP connections
- 単独のセッションTCP接続
RFC 1795 defines a negotiation protocol for DLSw peers to choose
either two unidirectional or one bi-directional TCP connection.
DLSws implementing the enhancements described in this document must
support and use(whenever required and possible)a single bi-
directional TCP connection between DLSw peers. That is to say that
the single tunnel negotiation support of RFC 1795 is a prerequisite
function to this set of enhancements. Use of two unidirectional TCP
connections is only allowed (and required)for migration purposes
when communicating with DLSw peers that do not implement these
enhancements.
DLSw同輩が2単方向か1つの双方向のTCP接続のどちらかを選ぶように、RFC1795は交渉プロトコルを定義します。 本書では説明された増進を実装するDLSwsはDLSw同輩の間の単独の両性愛者の方向のTCP接続をサポートして、使用しなければなりません(必要であって、可能であるときはいつも)。 すなわち、RFC1795のただ一つのトンネル交渉サポートはこのセットの増進への必須の機能です。 これらの増進を実装しないDLSw同輩とコミュニケートするときだけ、2つの単方向のTCP接続の使用は移行目的のために許されています(そして、必要です)。
This document also specifies a faster method for bringing up a
single TCP connection between two DLSw peers than the negotiation
used in RFC 1795. This faster method, detailed in section 6.2.1,
must be used where both peers are known to support DLSw v2.0.
また、このドキュメントは2人のDLSw同輩の間に単独のTCP接続を育てるためのRFC1795で使用される交渉より速いメソッドを指定します。 両方の同輩がDLSw v2.0をサポートするのが知られているところでこのより速いセクション6.2.1で詳細なメソッドを使用しなければなりません。
- TCP connections on demand
- オンデマンドのTCP接続
Two DLSw peers using these enhancements will only establish a TCP
connection when necessary. SSP connections to DLSw peers which do
not implement these enhancements are assumed to be established by
the means defined in RFC 1795. DLSws implementing v2.0 utilize UDP
based transport services to send address resolution packets
(CANUREACH_ex, NETBIOS_NQ_ex, etc.). If a positive response is
received, then a TCP connection is only established to the
associated DLSw peer if one does not already exist.
Correspondingly, TCP connections are brought down when there are no
circuits to a DLSw peer for an implementation defined period of
time.
必要であるときにだけ、これらの増進を使用している2人のDLSw同輩がTCP接続を確立するでしょう。 これらの増進がRFC1795で定義された手段で設立されると思われる道具ではなく、そうするDLSw同輩とのSSP接続。 v2.0を実装するDLSwsは、アドレス解決パケット(CANUREACH_元の連れ合い、NETBIOS_NQ_元の連れ合いなど)を送るのにUDPのベースの輸送サービスを利用します。 積極的な応答が受け取られていて、1つが既に存在していない場合にだけ、TCP接続は関連DLSw同輩に確立されます。 DLSw同輩への回路が全く実装の定義された期間の間ないとき、TCP接続は対応する、落ち込みます。
Bryant & Brittain Informational [Page 6] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[6ページ]のRFC2166APPN Implementerのワークショップ1997年6月
- Address resolution through UDP
- UDPを通したアドレス解決
The main thrust of this paper is to utilize non-reliable transport
and the inherent efficiencies of multicast protocols whenever
possible and applicable to reduce network overhead. Accordingly,
the address resolution protocols of SNA and NetBIOS are sent over
the non-reliable transport of IP, namely UDP. In addition, IP
multicast/unicast services are used whenever address resolution
packets must be sent to multiple destinations. This avoids the need
to maintain TCP SSP connections between two DLSw peers when no
circuits are active. CANUREACH_ex and ICANREACH_ex packets can be
sent to all the appropriate DLSw peers without the need for pre-
configured peers or pre-established TCP/IP connections. In
addition, most multicast services (including TCP's MOSPF, DVMRP,
MIP, etc.) replicate and propagate messages only as necessary to
deliver to all multicast members. This avoids duplication and
excessive bandwidth consumption in the transport network.
この紙の主な突きはネットワークオーバーヘッドを下げるのにおいて可能であって、適切であるときはいつも、非信頼できる輸送とマルチキャストプロトコルの固有の効率を利用することです。 それに従って、すなわち、IP、UDPの非信頼できる輸送の上にSNAとNetBIOSのアドレス解決プロトコルを送ります。 さらに、アドレス解決パケットを複数の目的地に送らなければならないときはいつも、IPマルチキャスト/ユニキャストサービスは使用されています。 これはどんな回路もアクティブでないときに2人のDLSw同輩の間のTCP SSP接続を維持する必要性を避けます。 あらかじめ構成された同輩かプレ確立したTCP/IP接続の必要性なしでCANUREACH_元の連れ合いとICANREACHの_の元のパケットをすべての適切なDLSw同輩に送ることができます。 さらに、ほとんどのマルチキャストサービス(TCPのMOSPF、DVMRP、MIPなどを含んでいる)が、すべてのマルチキャストメンバーに配送するために必要に応じてメッセージだけを模写して、伝播します。 これは転送ネットワークで複製と過度の帯域幅消費を避けます。
To further optimize the use of WAN resources, address resolution
responses are sent in a directed fashion (i.e., unicast) via UDP
transport whenever possible. This avoids the need to setup or
maintain TCP connections when they are not required. It also
avoids the bandwidth costs associated with broadcasting.
さらにWANリソースの使用を最適化するために、可能であるときはいつも、指示されたファッション(すなわち、ユニキャスト)でUDP輸送でアドレス解決応答を送ります。 これは彼らが必要でないときにTCP接続をセットアップするか、または維持する必要性を避けます。 また、それは放送に関連している帯域幅コストを避けます。
Note: It is also permitted to send some address resolution traffic
over existing TCP connections. The conditions under which this is
permitted are detailed in section 7.
以下に注意してください。 また、それが存在する上の何らかのアドレス解決トラフィックにTCP接続を送ることが許可されています。 これが受入れられる状態はセクション7で詳細です。
- NetBIOS broadcasts over UDP
- UDPの上のNetBIOS放送
In the same manner as above, NetBIOS broadcast packets are sent via
UDP (unicast and multicast) whenever possible and appropriate. This
avoids the need to establish TCP connections between DLSw peers
when there are no circuits required. In addition, bandwidth in
the transport network is conserved by utilizing the efficiencies
inherent to multicast service implementation. Details covering
identification of these packets and proper propagation methods are
described in section 10.
同じ方法で、可能であって、適切であるときはいつも、同じくらい上に、UDP(ユニキャストとマルチキャスト)を通してNetBIOS放送パケットを送ります。 これは必要である回路が全くないときDLSw同輩の間のTCP接続を確立する必要性を避けます。 さらに、転送ネットワークの帯域幅は、マルチキャストサービス実装に固有の効率を利用することによって、保存されます。 これらのパケットの識別をカバーする詳細と適切な伝播メソッドはセクション10で説明されます。
5. Multicast Groups and Addressing
5. マルチキャストグループとアドレシング
IP multicast services provides an unreliable datagram oriented delivery service to multiple parties. Communication is accomplished by sending and/or listening to specific 'multicast' addresses. When a given node sends a packet to a specific address (defined to be within the multicast address range), the IP network (unreliably) delivers the packet to every node listening on that address.
IPマルチキャストサービスは複数のパーティーへの頼り無いデータグラム指向のデリバリ・サービスを提供します。 コミュニケーションは、特定の'マルチキャスト'アドレスを送る、そして/または、聞くことによって、達成されます。 与えられたノードが特定のアドレス(マルチキャストアドレスの範囲の中にあるように、定義される)にパケットを送るとき、IPネットワークはそのアドレスで聴くあらゆるノードにパケットを(当てにならずに)提供します。
Bryant & Brittain Informational [Page 7] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[7ページ]のRFC2166APPN Implementerのワークショップ1997年6月
Thus, DLSws can make use of this service by simply sending and receiving (i.e., listening for) packets on the appropriate multicast addresses. With careful planning and implementation, networks can be effectively partitioned and network overhead controlled by sending and listening on different addresses groups. It is not the intent of this paper to define or describe the techniques by which this can be accomplished. It is expected that the networking industry (vendors and end users alike) will determine the most appropriate ways to make use of the functions provided by use of DLSw multicast transport services.
すなわち、その結果、DLSwsが単に発信して、受信することによってこのサービスを利用できる、(聞こうとする、)、適切なマルチキャストアドレスのパケット。 綿密な計画と実装で、事実上、ネットワークを仕切ることができます、そして、異なったアドレスで発信して、聴くことによって制御されたネットワークオーバーヘッドは分類されます。 これを達成できるテクニックについて定義するか、または説明するのが、この紙の意図ではありません。 ネットワーク産業(ベンダーもエンドユーザも)がDLSwマルチキャスト輸送サービスの使用で提供された機能を利用する最も適切な方法を決定すると予想されます。
5.1 Using Multicast Groups
5.1 マルチキャストグループを使用すること。
The multicast addressing as described above can be effectively used to limit the amount of broadcast/multicast traffic in the network. It is not the intent of this document to describe how individual DLSw/SSP implementations would assign or choose group addresses. The specifics of how this is done and exposed to the end user is an issue for the specific implementor. In order to provide for multivendor interoperability and simplicity of configuration, however, this paper defines a single IP multicast address, 224.0.10.000, to be used as a default DLSw multicast address. If a given implementation chooses to provide a default multicast address, it is recommended this address be used. In addition, this address should be used for both transmitting and receiving of multicast SSP messages. Implementation of a default multicast address is not, however, required.
事実上、放送/マルチキャストトラフィックについてネットワークが量を制限するのに上で説明されるマルチキャストアドレシングは使用できます。 個々のDLSw/SSP実装がグループアドレスを割り当てるか、またはどう選ぶだろうかを説明するのは、このドキュメントの意図ではありません。 どうエンドユーザにこれをして、暴露するかに関する詳細は特定の作成者のための問題です。 この論文はしかしながら、構成の「マルチ-ベンダー」相互運用性と簡単さに備えるためにただ一つのIPマルチキャストアドレスを定義します、224.0。.10 .000 デフォルトDLSwマルチキャストアドレスとして使用されるために。 与えられた実装が、デフォルトマルチキャストアドレスを提供するのを選ぶなら、このアドレスはそれに推薦されます。使用されます。 さらに、マルチキャストSSPメッセージが伝わって、受信されながら、このアドレスは両方に使用されるべきです。 しかしながら、デフォルトマルチキャストアドレスの実装は必要ではありません。
5.2 DLSw Multicast Addresses
5.2 DLSwマルチキャストアドレス
For the purpose of long term interoperability, the AIW has secured a block of IP multicast addresses to be used with DLSw. These addresses are listed below:
長期相互運用性の目的のために、AIWは、1ブロックのIPマルチキャストアドレスがDLSwと共に使用されていると機密保護しました。 これらのアドレスは以下に記載されています:
Address Range Purpose
--------------------------------------------------------------------
224.0.10.000 Default multicast address
224.0.10.001-191 User defined DLSw multicast groups
224.0.10.192-255 Reserved for future use by the DLSw RIG in DLSw
enhancements
アドレス範囲目的-------------------------------------------------------------------- 224.0.10.000 デフォルトマルチキャストアドレス224.0.10.001-191UserはDLSw RIGによる今後の使用のためにDLSw増進でDLSwマルチキャストグループ224.0.10.192-255Reservedを定義しました。
6. DLSw Message Transports
6. DLSwメッセージ転送
With the introduction of DLSw Multicast Protocols, SSP messages are now sent over two distinct transport mechanisms: TCP/IP connections and UDP services. Furthermore, the UDP datagrams can be sent to two different kinds of IP addresses: unique IP addresses (generally associated with a specific DLSw), and multicast IP addresses (generally associated with a group of DLSw peers).
DLSw Multicastプロトコルの導入で、現在、2台以上の異なった移送機構をSSPメッセージに送ります: TCP/IP接続とUDPサービス。 その上、2つの異種のIPアドレスにUDPデータグラムを送ることができます: 固有のIPアドレス(一般に特定のDLSwに関連している)、およびマルチキャストIPアドレス(一般にDLSw同輩のグループに関連している)。
Bryant & Brittain Informational [Page 8] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[8ページ]のRFC2166APPN Implementerのワークショップ1997年6月
6.1 TCP/IP Connections on Demand
6.1 オンデマンドのTCP/IP接続
As is the case in RFC 1795, TCP/IP connections are established between DLSw peers. Unlike RFC 1795, however, TCP/IP connections are only established to carry reliable circuit data (i.e., LLC2 based circuits). Accordingly, a TCP/IP connection is only established to a given DLSw peer when the first circuit to that DLSw is required (i.e., the origin DLSw must send a CANUREACH_CS to a target DLSw peer and there is no existing TCP connection between the two). In addition, the TCP/IP connection is brought down an implementation defined amount of time after the last active (not pending) circuit has terminated. In this way, the overhead associated with maintaining TCP connections is minimized.
RFC1795のケースのように、TCP/IP接続はDLSw同輩の間で確立されます。 しかしながら、RFC1795と異なって、TCP/IP接続は、信頼できる回路データを運ぶために確立されるだけです(すなわち、LLC2は回路を基礎づけました)。 そのDLSwへの最初の回路が必要であるときにだけ(すなわち、発生源DLSwはCANUREACH_CSを目標DLSw同輩に送らなければなりません、そして、2つの間には、どんな既存のTCP接続もありません)、それに従って、TCP/IP接続は与えられたDLSw同輩に確立されます。 さらに、最後のアクティブな(未定でない)回路が終わった後にTCP/IP接続は実装の定義された時間の下でもたらされています。 このように、TCP接続を維持すると関連しているオーバーヘッドは最小にされます。
With the advent of TCP connections on demand, the activation and deactivation of TCP connections becomes a normal occurrence as opposed to the exception event it constitutes in RFC 1795. For this reason, it is recommended that implementations carefully consider the value of SNMP traps for this condition.
TCP接続のオンデマンドのTCP接続の到来、起動、および非活性化で、それがRFC1795で構成する例外イベントと対照的に通常の発生になります。 この理由で、実装がこの状態のために慎重にSNMP罠の値を考えるのは、お勧めです。
6.1.1 TCP Connections on Demand Race Conditions
6.1.1 TCPのコネクションズのオンデマンドの競合条件
Non-circuit based SSP packetsn (e.g.,CANUREACH_ex, etc.) may still be sent/received over TCP connections after all circuits have been terminated. Taking this into account implementations should still gracefully terminate these TCP connections once the connection is no longer supporting circuits. This may require an implementation to retransmit request frames over UDP when no response to a TCP based unicast request is received and the TCP connection is brought down. This is not required in the case of multicast requests as these are received over the multicast transport mechanism.
すべての回路を終えた後に、まだ、非回路のベースのSSP packetsn(例えば、CANUREACH_元の連れ合いなど)をTCP接続の上に送るか、または受け取っているかもしれません。 アカウント実装にこれを連れていくと、接続がもういったん回路を支えないと、これらのTCP接続はまだ優雅に終えられているべきです。 これは、TCPのベースのユニキャスト要求へのどんな応答も受け取られていないで、TCP接続が落ち込むとき、UDPの上に要求フレームを再送するために実装を必要とするかもしれません。 これはマルチキャスト移送機構の上にこれらを受け取るようなマルチキャスト要求の場合で必要ではありません。
6.2 Single Session TCP/IP Connections
6.2 ただ一つのセッションTCP/IP接続
RFC 1795 defines the use of two unidirectional TCP/IP sessions between any pair of DLSw peers using read port number 2065 and write port number 2067. Additionally, RFC 1795 allows for implementations to optionally use only one bi-directional TCP/IP session. Using one TCP/IP session between DLSw peers is believed to significantly improve the performance and scalability of DLSw protocols. Performance is improved because TCP/IP acknowledgments are much more likely to be piggy-backed on real data when TCP/IP sessions are used bi-directionally. Scalability is improved because fewer TCP control blocks, state machines, and associated message buffers are required. For these reasons, the DLSw enhancements defined in this paper REQUIRE the use of single session TCP/IP sessions.
RFC1795はNo.2065を移植して、ポートNo.2067を書くDLSw同輩使用の組が、読むいずれも間の2つの単方向のTCP/IPセッションの使用を定義します。 さらに、RFC1795は、実装が任意に1つの双方向のTCP/IPセッションだけを使用するのを許容します。 DLSw同輩の間の使用1TCP/IPセッションがDLSwプロトコルの性能とスケーラビリティをかなり向上させると信じられています。 TCP/IPセッションが2方向に使用されるとき、TCP/IP承認が本当のデータではるかに背負われそうであるので、パフォーマンスは向上されています。 より少ないTCP制御ブロック、州のマシン、および関連メッセージ・バッファが必要であるので、スケーラビリティは改良されています。 これらの理由で、DLSw増進はこの紙のREQUIREでただ一つのセッションTCP/IPセッションの使用を定義しました。
Bryant & Brittain Informational [Page 9] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[9ページ]のRFC2166APPN Implementerのワークショップ1997年6月
Accordingly, DLSws implementing these enhancements must carry the TCP Connections Control Vector in their Capabilities Exchange. In addition, the TCP Connections Control Vector must indicate support for 1 connection.
それに従って、これらの増進を実装するDLSwsはそれらのCapabilities ExchangeでTCPコネクションズControl Vectorを運ばなければなりません。 さらに、TCPコネクションズControl Vectorは1つの接続のサポートを示さなければなりません。
6.2.1 Expedited Single Session TCP/IP Connections
6.2.1 速められたただ一つのセッションTCP/IP接続
In RFC 1795, single session TCP/IP connections are accomplished by first establishing two uni-directional TCP connections, exchanging capabilities, and then bringing down one of the connections. In order to avoid the unnecessary flows and time delays associated with this process, a new single session bi-directional TCP/IP connection establishment algorithm is defined.
RFC1795では、ただ一つのセッションTCP/IP接続は2つのuni方向のTCP接続を確立しながら、最初にによって達成されます、能力を交換して、次に、接続のひとりを降ろして。 不要な流れとこのプロセスに関連している時間遅れを避けるために、新しいただ一つのセッション双方向のTCP/IP接続設立アルゴリズムは定義されます。
6.2.1.1 TCP Port Numbers
6.2.1.1 TCPポートナンバー
DLSws implementing these enhancements will use a TCP destination port of 2067 (as opposed to RFC 1795 which uses 2065) for single session TCP connections. The source port will be a random port number using the established TCP norms which exclude the possibility of either 2065 or 2067.
これらの増進を実装するDLSwsは単独のセッションTCP接続に2067年(2065を使用するRFC1795と対照的に)のTCP仕向港を使用するでしょう。 ソースポートは2065か2067年の可能性を除く確立したTCP標準を使用する無作為のポートナンバーになるでしょう。
6.2.1.2 TCP Connection Setup
6.2.1.2 TCP接続設定
DLSw peers implementing these enhancements will establish a single session TCP connection whenever the associated peer is known to support this capability. To do this, the initiating DLSw simply sends a TCP setup request to destination port 2067. The receiving DLSw responds accordingly and the TCP three way handshake ensues. Once this handshake has completed, each DLSw is notified and the DLSw capabilities exchange ensues. As in RFC 1795, no flows may take place until the capabilities exchange completes.
関連同輩がこの能力を支持するのが知られているときはいつも、これらの増進を実行するDLSw同輩が単独のセッションTCP接続を確立するでしょう。 これをするために、開始しているDLSwは単にTCPセットアップ要求を仕向港2067に送ります。 DLSwがそれに従って、反応させる受信と握手が続くTCP three方法。 一度、この握手は続いたことがあります。完成していて、各DLSwは通知されます、そして、DLSw能力交換は続きます。 RFC1795のように、流れは全く交換が完成する能力まで起こらないかもしれません。
6.2.1.3 Single Session Setup Race Conditions
6.2.1.3 ただ一つのセッションセットアップ競合条件
The new expedited single session setup procedure described above opens up the possibility of a race condition that occurs when two DLSw peers attempt to setup single session TCP connections to each other at the same time. To avoid the establishment of two TCP connections, the following rules are applied when establishing expedited single session TCP connections:
上で説明された新しい速められたただ一つのセッションセットアップ手順は2人のDLSw同輩が、同時に単独のセッションTCP接続を互いにセットアップするのを試みるとき起こる競合条件の可能性を開けます。 速められた単独のセッションTCP接続を確立するとき、2つのTCP接続の設立を避けるために、以下の規則は適用されています:
1.If an inbound TCP connect indication is received on port 2067 while
an outbound TCP connect request (on port 2067) to the same DLSw (IP
address) is in process or outstanding, the DLSw with the higher IP
address will close or reject the connection from the DLSw with the
lower IP address.
1. 本国行きのTCPが受けられた指示を接続するなら外国行きのTCPが接続している間、ポートの上では、2067が、(IPアドレス)が過程にあるか、または傑出しているよう同じDLSwに要求して(ポート2067の上で)、より高いIPアドレスがあるDLSwは低いIPアドレスでDLSwから接続を終えるか、または拒絶するでしょう。
Bryant & Brittain Informational [Page 10] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[10ページ]のRFC2166APPN Implementerのワークショップ1997年6月
2.To further expedite the process, the DLSw with the lower IP address
may choose (implementation option) to close its connection request
to the DLSw with the higher address when this condition is
detected.
3.If the DLSw with the lower IP address has already sent its
capabilities exchange request on its connection to the DLSw with
the higher IP address, it must resend its capabilities exchange
request over the remaining TCP connection from its DLSw peer (with
the higher IP address).
4.The DLSw with the higher IP address must ignore any capabilities
exchange request received over the TCP connection to be terminated
(the one from the DLSw with the lower IP address).
2. さらに過程を速めるために、低いIPアドレスがあるDLSwは、この状態が検出されるとき、より高いアドレスで接続要求をDLSwに終えるのを選ぶかもしれません(実現オプション)。 3. 低いIPアドレスがあるDLSwが既に発信したなら、能力は接続のときに、より高いIPアドレスで要求をDLSwと交換して、それは交換が残っているTCP接続の上でDLSw同輩(より高いIPアドレスがある)から要求する能力を再送しなければなりません。 4. より高いIPアドレスがあるDLSwは交換要求が終えられるためにTCP接続の上で受けたどんな能力(低いIPアドレスがあるDLSwからのもの)も無視しなければなりません。
6.2.1.4 TCP Connections with Non-Multicast Capable DLSw peers
6.2.1.4 Non-マルチキャストCapable DLSw同輩がいるTCPコネクションズ
During periods of migration, it is possible that TCP connections between multicast capable and non-multicast capable DLSw peers will occur. It is also possible that multicast capable DLSws may attempt to establish TCP connections with partners of unknown capabilities (e.g., statically defined peers). To handle these conditions the following additional rules apply to expedited single session TCP connection setup:
移動の期間、マルチキャストのできて非マルチキャストの有能なDLSw同輩の間のTCP接続が起こるのは、可能です。 また、そのマルチキャストのできるDLSwsが、未知の能力(例えば、静的に定義された同輩)のパートナーとのTCP接続を確立するのを試みるのも、可能です。 これらの状態を扱うために、以下の付則は速められたただ一つのセッションTCP接続設定に適用されます:
1.If the capability of a DLSw peer is not known, an implementation
may choose to send the initial TCP connect request to either port
2067 (expedited single session setup) or port 2065 (standard RFC
1795 TCP setup).
2.If a multicast capable DLSw receives an inbound TCP connect request
on port 2065 while processing an outbound request on 2067 to the
same DLSw, the sending DLSw will terminate its 2067 request and
respond as defined in RFC 1795 with an outbound 2065 request
(standard RFC 1795 TCP setup).
3.If a multicast capable DLSw receives an indication that the DLSw
peer is not multicast capable (the port 2067 setup request times
out or a port not recognized rejection is received), it will send
another connection request using port 2065 and the standard RFC
1795 session setup protocol.
1. DLSw同輩の能力が知られていないなら、実現は、2067(ただ一つのセッションセットアップを速める)を移植するか、または2065(標準のRFC1795TCPセットアップ)を移植するという要求をTCPが接続する初期に送るのを選ぶかもしれません。 2. マルチキャストできるDLSwが本国行きのTCPを受けるなら、同じDLSwへの2067に外国行きの要求を処理して、発信しているDLSwが2065年の外国行きの要求(標準のRFC1795TCPセットアップ)でRFC1795で定義されるように2067年の要求を終えて、応じる間、ポート2065に要求を接続してください。 3. aマルチキャストのできるDLSwがDLSw同輩がマルチキャストできないという(ポート2067が外で要求時間をセットアップするか、または認識された拒絶ではなく、ポートが受け取られています)指示を受けると、それは、ポート2065と標準のRFC1795セッションセットアッププロトコルを使用することで別の接続要求を送るでしょう。
Bryant & Brittain Informational [Page 11] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[11ページ]のRFC2166APPN Implementerのワークショップ1997年6月
6.3 UDP Datagrams
6.3 UDPデータグラム
As mentioned above, UDP datagrams can be sent two different ways: unicast (e.g., sent to a single unique IP address) or multicast (i.e., sent to an IP multicast address). Throughout this document, the term UDP datagram will be used to refer to SSP messages sent over UDP, while unicast and multicast SSP messages will refer to the specific type/method of UDP packet transport. In either case, standard UDP services are used to transport these packets. In order to properly parse the inbound UDP packets and deliver them to the SSP state machines, all DLSw UDP packets will use the destination port of 2067.
以上のように、UDPデータグラムを2つの異なった方法送ることができます: ユニキャスト(例えば、ただ一つの固有のIPアドレスに発信する)かマルチキャスト(すなわち、IPマルチキャストアドレスに発信します)。 このドキュメント中では、用語UDPデータグラムはUDPの上に送られたSSPメッセージを示すのに使用されるでしょう、ユニキャストとマルチキャストSSPメッセージはUDPパケット輸送の特定のタイプ/方法を示すでしょうが。 どちらの場合ではも、標準のUDPサービスは、これらのパケットを輸送するのに利用されます。 適切に本国行きのUDPパケットを分析して、SSP州のマシンにそれらを渡すために、すべてのDLSw UDPパケットが2067年の仕向港を使用するでしょう。
In addition, the checksum function of UDP remains optional for DLSw SSP messages. It is believed that the inherent CRC capabilities of all data link transports will adequately protect SSP packets during transmission. And the incremental exposure to intermediate nodal data corruption is negligible. For further information on UDP packet formats see the 擢rame Formats� section.
さらに、UDPのチェックサム機能はDLSw SSPメッセージに任意のままで残っています。 すべてのデータ・リンク輸送の固有のCRC能力がトランスミッションの間適切にSSPパケットを保護すると信じられています。 そして、中間的こぶのようなデータの汚染への増加の露出は取るにたらないです。 UDPパケット・フォーマットの詳細に関しては、擢rame Formatsを見てください--セクション。
6.3.1 Vendor Specific Functions over UDP
6.3.1 UDPの上の業者具体的な機能
In order to accommodate vendor specific capabilities over UDP transport, a new SSP packet format has been defined. This new packet format is required because message traffic of this type is not necessarily preceded by a capabilities exchange. Accordingly, DLSw's wishing to invoke a vendor specific function may send out this new SSP packet format over UDP.
UDP輸送の上に業者の特定の能力を収容するために、新しいSSPパケット・フォーマットは定義されました。 能力交換でこのタイプのメッセージ交通に必ず先行されるというわけではないので、この新しいパケット・フォーマットが必要です。 それに従って、業者具体的な機能を呼び出すDLSwの願望はこの新しいSSPパケット・フォーマットをUDPの上に出すかもしれません。
Because this packet can be sent over TCP connections and non- multicast capable nodes may not be able to recognize it, implementations may only send this packet over TCP to DLSw peers known to understand this packet format (i.e., multicast capable). To avoid this situation in the future, DLSws implementing these enhancements must ignore SSP packets with an unrecognized DLSw version number in the range of x'31' to x'3F'. Further information and the precise format for this new packet type is described below in the 擢rame Formats� section.
非マルチキャストのできるノードがTCP接続の上にこのパケットを送ることができて、それを認識できないかもしれないので、実現はこのパケット・フォーマット(すなわち、できるマルチキャスト)を理解しているのが知られているDLSw同輩へのTCPの上にこのパケットを送るだけであるかもしれません。 '将来この状況を避けるために、認識されていないDLSwバージョン番号がx31年'x'3のF'の範囲にある状態で、これらの増進を実行するDLSwsはSSPパケットを無視しなければなりません。 詳細とこの新しいパケットタイプのための正確な形式は擢rame Formatsで以下で説明されます--セクション。
6.3.2 Unicast UDP Datagrams
6.3.2 ユニキャストUDPデータグラム
Generically speaking, a unicast UDP datagram is utilized whenever an SSP message (not requiring reliable transport) must be sent to a unique set (not all) of DLSw peers. This avoids the overhead of having to establish and maintain TCP connections when they are not required for reliable data transport.
一般的に話すなら、SSPメッセージ(信頼できる輸送を必要としない)をユニークなセット(すべてでない)のDLSw同輩に送らなければならないときはいつも、ユニキャストUDPデータグラムは利用されています。 これは彼らが確実な資料輸送に必要でないときに、TCP接続を確立して、維持しなければならないオーバーヘッドを避けます。
Bryant & Brittain Informational [Page 12] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[12ページ]のRFC2166APPN Implementerのワークショップ1997年6月
A typical example of when unicast UDP might be used would be an ICANREACH_ex response from a peer DLSw (with which no TCP connection currently exists). In this case, the sending DLSw knows the IP address of the intended receiver and can simply send the response via unicast UDP. In addition, there are a number of NetBIOS cases where unicast UDP is used to handle UI frames directed to a specific DLSw (e.g., NetBIOS STATUS_RESPONSE). Further detail is provided in the NetBIOS section of this document.
ユニキャストUDPが使用されるかもしれない時に関する典型的な例は同輩DLSw(どんなTCP接続も現在存在しない)からのICANREACHの_の元の応答でしょう。 この場合、発信しているDLSwは所定の受信者のIPアドレスを知って、ユニキャストUDPを通して単に応答を送ることができます。 さらに、多くのNetBIOSケースがユニキャストUDPが特定のDLSw(例えば、NetBIOS STATUS_RESPONSE)に向けられたUIフレームを扱うのに使用されるところにあります。 このドキュメントのNetBIOS部に詳細を提供します。
6.3.3 Multicast UDP Datagrams
6.3.3 マルチキャストUDPデータグラム
In a broad sense, multicast UDP datagrams are used whenever a given SSP message must be sent to multiple DLSw peers. In the case of SNA, this is primarily the CANUREACH_ex packets. In the case of NetBIOS, multicast datagrams are used to send broadcast UI frames such as NetBIOS user datagrams and broadcast datagrams.
広い意味で、与えられたSSPメッセージを複数のDLSw同輩に送らなければならないときはいつも、マルチキャストUDPデータグラムは使用されています。 SNAの場合では、これは主としてCANUREACHの_の元のパケットです。 NetBIOSの場合では、マルチキャストデータグラムは、NetBIOSユーザデータグラムやブロードキャスト・データグラムなどの放送UIフレームを送るのに使用されます。
Note, however, it is sometimes possible to avoid broadcasting certain NetBIOS frames that would otherwise be broadcast in the LAN environment. This is typically accomplished using name caching techniques not described in this paper. In cases of this type when a single destination DLSw can be determined, unicast transport can be used to send the 'broadcast' NetBIOS frame to a single destination. A more detailed listing of NetBIOS SSP packets and transport methods can be found in the NetBIOS section of this document.
しかしながら、そうでなければLAN環境で放送されるあるNetBIOSフレームを放送するのを避けるのが時々可能であることに注意してください。 これは、この紙で説明されなかった名前キャッシュのテクニックを使用することで通常達成されます。 単一の目的地であることのこのタイプの場合では、DLSwは決定できて、'放送'NetBIOSフレームを単一の目的地に送るのにユニキャスト輸送は使用できます。 このドキュメントのNetBIOS部でNetBIOS SSPパケットと輸送方法の、より詳細なリストを見つけることができます。
6.4 Unicast UDP Datagrams in Lieu of IP Multicast
6.4 IPマルチキャストの代わりにユニキャストUDPデータグラム
Because the use of IP multicast services is actually a function of IP itself and not DLSw proper, it is possible for implementations to simply make use of the UDP transport mechanisms described in this paper without making direct use of the IP multicast function. While this is not considered to be as efficient as using multicast transport mechanisms, this practice is not explicitly prohibited.
IPマルチキャストサービスの使用が実際にDLSw本土ではなく、IP自身の機能であるので、実現が単にこの紙でIPマルチキャスト機能をダイレクトに利用しないで説明されたUDP移送機構を利用するのは、可能です。 これがマルチキャスト移送機構を使用するのと同じくらい効率的であると考えられませんが、この習慣は明らかに禁止されていません。
Implementations which choose to make use of UDP transport in this manner must first know the IP address of all the potential target DLSw peers and send individual unicast packets to each. How this information is obtained and/or maintained is outside the scope of this paper.
UDP輸送を利用するのを選ぶ実現は、この様に最初に、すべての仮想ターゲットDLSw同輩のIPアドレスを知って、個々のユニキャストパケットをそれぞれに送らなければなりません。 この紙の範囲の外にこの情報が得る、そして/または、どう保守されるかがあります。
As a matter of compliance, implementers need not send SSP packets outbound over UDP as there are some conditions where this may not be necessary or desirable. It is, however, required that implementers provide an option to receive SSP packets over UDP.
承諾の問題として、いくつかの状態がこれが必要であるか、または望ましくないかもしれないところにあるとき、implementersはUDPの上の外国行きのパケットをSSPに送る必要はありません。 しかしながら、implementersがSSPパケットをUDPの上に受けるためにオプションを提供するのが必要です。
Bryant & Brittain Informational [Page 13] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[13ページ]のRFC2166APPN Implementerのワークショップ1997年6月
6.5 TCP Transport
6.5 TCP輸送
Despite the addition of UDP based packet transport, TCP remains the fundamental form of communications between DLSw peers. In particular, TCP is still used to carry all LLC2 based circuit data.
UDPのベースのパケット輸送の添加にもかかわらず、TCPはDLSw同輩のコミュニケーションの基本形のままで残っています。 特に、TCPは、すべてのLLC2のベースのサーキットデータを運ぶのにまだ使用されています。
Throughout this document wherever UDP unicast (not multicast) is discussed, the reader should be aware that TCP may be used instead. Moreover, it is strongly recommended that TCP be used in preference to UDP whenever a TCP connection to the destination already exists. Implementations, however, should be prepared to receive SSP packets from either transport (TCP or UDP).
このドキュメント中では、どこでUDPユニキャスト(マルチキャストでない)について議論しても、読者はTCPが代わりに使用されるかもしれないのを意識しているべきです。 そのうえ、TCPがUDPに優先して目的地とのTCP接続が既に存在しているときはいつも、使用されることが強く勧められます。 しかしながら、実現は輸送(TCPかUDP)からSSPパケットを受けるように準備されるべきです。
7. Migration Support
7. 移動サポート
It is anticipated that some networks will experience a transition stage where both RFC 1795 (referred to as 'non-multicast' DLSws) and It will be important for these two DLSw node types to interoperate and thus the following accommodations for non-multicast DLSws are required:
いくつかのネットワークがこれらの2人のDLSwノード種別が共同利用するようにRFC1795('非マルチキャスト'DLSwsと呼ばれます)とItの両方が重要になる転換期を経験すると予期されて、その結果、非マルチキャストDLSwsのための以下の宿泊設備が必要です:
7.1 Capabilities Exchange
7.1 能力交換
In order to guarantee both backward and forward capability, DLSws which implement these multicast enhancements will carry a 溺ulticast Capabilities� Control Vector in their capabilities exchange (see RFC 1795 for an explanation of capabilities exchange protocols). Presence of the Multicast Capabilities control vector indicates support for the protocols defined in this document on a per DLSw peer basis. Conversely, lack of the Multicast Capabilities control vector indicates no support for these extensions on a per DLSw peer basis.
後ろ向きものと同様に前向きな能力を保証するために、これらのマルチキャスト増進を実行するDLSwsはulticast Capabilities?彼らの能力におけるControl Vectorが交換する溺を運ぶでしょう(能力に関する説明のためのRFC1795がプロトコルを交換するのを見てください)。 Multicast Capabilitiesコントロールベクトルの存在は本書ではDLSw同輩基礎あたりのaで定義されたプロトコルのサポートを示します。 逆に、Multicast Capabilitiesコントロールベクトルの不足はDLSw同輩基礎あたりのaでこれらの拡大のサポートを全く示しません。
Additionally, nodes implementing these enhancement will carry a modified DLSw Version control vector (x'82') indicating support for version 2 release 0.
'さらに、これらの増進を実行するノードが変更されたDLSwバージョンコントロールベクトルを運ぶために望んでいる、(x82年、'、)、バージョン2リリース0のサポートを示すこと。
Lastly, presence of these control vectors mandates a TCP Connections Control Vector indicating support for 1 TCP connection in the same Capabilities exchange.
最後に、これらのコントロールベクトルの存在は同じCapabilities交換における1つのTCP接続のサポートを示すTCPコネクションズControl Vectorを強制します。
If a multicast capable DLSw receives a Capabilities Exchange CV that includes the Multicast Capabilites CV but does not meet the above criteria, it must reject the capabilities exchange by sending a negative response as described in section 11.1.1.
マルチキャストできるDLSwがMulticast Capabilites CVを含んでいますが、上の評価基準を満たさないCapabilities Exchange CVを受けるなら、それは、セクション11.1.1で説明されるように否定応答を送ることによって、能力交換を拒絶しなければなりません。
Bryant & Brittain Informational [Page 14] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[14ページ]のRFC2166APPN Implementerのワークショップ1997年6月
7.2 Connecting to Non-Multicast Capable Nodes
7.2 非マルチキャストのできるノードに接続すること。
It is assumed that TCP connections to DLSw peers which do not support multicast services are established by some means outside the scope of this paper (i.e., non-multicast partner addresses are configured by the customer). TCP connections must be established and maintained to down level nodes in the exact same manner as RFC 1795 requires, establishes, and maintains them. And because non-multicast DLSw peers will not indicate support for multicast services in their capabilities exchange, a multicast capable DLSw will know all its non-multicast peers.
サポートマルチキャストサービスではなく、そうするDLSw同輩とのTCP接続がどうでもこの紙の範囲の外で確立される(すなわち、非マルチキャストパートナーアドレスは顧客によって構成される)と思われます。 RFC1795がそれらを必要であり、設立して、維持するとき、TCPは全く同じ方法によるノードを平らにしますダウンするように接続を確立されて、主張しなければならない。 そして、非マルチキャストDLSw同輩がそれらの能力交換におけるマルチキャストサービスのサポートを示さないので、マルチキャストできるDLSwはすべての非マルチキャスト同輩を知るでしょう。
7.3 Communicating with Multicast Capable Nodes
7.3 マルチキャストのできるノードとコミュニケートすること。
Because non-multicast nodes will not receive SSP frames via UDP (unicast or multicast) transmission, SSP messages to these DLSw peers must be sent over TCP connections. Therefore, nodes which implement the multicast protocol enhancements must keep track of which DLSw peers do not support multicast extensions (as indicated in the capabilities exchange). When a given packet is sent out via multicast services, it must also be sent over multicast UDP(to reach other multicast capable DLSw peers) and over the TCP connection to each non-multicast node. And although the multicast service requires periodic retransmissions (for reliability reasons), this is not the case with TCP connections to non-multicast nodes. Therefore, multicast capable DLSws should not resend SSP packets over TCP transport connection but rather, rely upon TCP to recover any lost packets. Furthermore, communications with non-multicast nodes should be in exact compliance with RFC 1795 protocols.
非マルチキャストノードがUDP(ユニキャストかマルチキャスト)トランスミッションでSSPフレームを受けないので、これらのDLSw同輩へのSSPメッセージをTCP接続の上に送らなければなりません。 したがって、DLSw同輩がマルチキャストプロトコル増進が動向をおさえなければならないそれのどの道具をするノードはマルチキャスト拡大(能力交換にみられるように)を支えません。 また、マルチキャストサービスで与えられたパケットを出すとき、マルチキャストUDP(他のマルチキャストの有能なDLSw同輩に届く)の上と、そして、それぞれの非マルチキャストノードとのTCP接続の上にそれを送らなければなりません。 そして、マルチキャストサービスは周期的な「再-トランスミッション」(信頼性の理由による)を必要としますが、これは非マルチキャストノードとのTCP接続があるそうではありません。 したがって、マルチキャストのできるDLSwsはTCP輸送接続の上でSSPにパケットを再送するはずがありませんが、むしろ、TCPを当てにして、あらゆる無くなっているパケットを回復してください。 その上、非マルチキャストノードとのコミュニケーションはRFC1795プロトコルへの正確な承諾中であるべきです。
When sending a unicast UDP message, it is important to know that the destination DLSw supports multicast services. This knowledge can be obtained from previous TCP connections/capabilities exchanges or inferred from a previously received UDP message, but how this information is obtained is outside the scope of this paper. In the latter case, if the DLSw is non-multicast, then there would be a TCP connection to it and it would be known to be non-multicast. If it is multicast capable and a TCP connection is in existence, then its level is known (via the prior capabilities exchange). If its capabilities are not known and there is not an existing TCP connection, then it can be implied to be multicast capable by virtue of a cached entry but no active TCP connection (e.g., TCP peer on demand support). This inference, however, could be erroneous in cases where the TCP connection (to a non-multicast DLSw) has failed for some reason. But normal UDP based unicast verification mechanisms will detect no active path to the destination and circuit setup will proceed correctly (i.e., succeed or fail in accordance with true connectivity).
ユニキャストUDPメッセージを送るとき、目的地DLSwがマルチキャストサービスを支持するのを知るのは重要です。 この知識を前のTCP接続/能力交換から得るか、または以前に受信されたUDPメッセージから推論できますが、この紙の範囲の外にどうこの情報を得るかがあります。 後者の場合には、DLSwが非マルチキャストであるなら、それとのTCP接続があるでしょう、そして、非マルチキャストであることが知られているでしょう。 それがマルチキャストできて、TCP接続が現存しているなら、レベルは知られています(先の能力交換で)。 能力が知られていなくて、また既存のTCP接続がなければ、キャッシュされたエントリーにもかかわらず、活発なTCP接続によるではなくできるマルチキャストになるようにそれを含意できます(例えば、TCPは要求サポートのときにじっと見ます)。 しかしながら、この推論はTCP接続(非マルチキャストDLSwへの)がある理由で失敗した場合で誤っているかもしれません。 しかし、正常なUDPベースのユニキャスト検証メカニズムはどんなアクティブな経路も目的地に検出しないでしょう、そして、サーキットセットアップは正しく進むでしょう(すなわち、成功するか、または本当の接続性に応じて、失敗してください)。
Bryant & Brittain Informational [Page 15] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[15ページ]のRFC2166APPN Implementerのワークショップ1997年6月
8. SNA Support
8. SNAサポート
Note: This paper does not attempt to address the unique issues presented by SNA/HPR and its non-ERP data links
以下に注意してください。 この紙は、SNA/HPRによって提示されたユニークな問題とその非ERPデータ・リンクを記述するのを試みません。
In SNA protocols the generalized packet sequence of interest is a test frame exchange followed by an XID exchange. In all cases, DLSw uses the CANUREACH_ex and ICANREACH_ex SSP packets to complete address resolution and circuit establishment. The following table describes how these packets are transported via UDP between two multicast capable DLSw peers.
SNAプロトコルでは、興味がある一般化されたパケット系列はXID交換がいうことになったテストフレーム交換です。 すべての場合では、DLSwは、アドレス解決とサーキット設立を終了するのにCANUREACH_元の連れ合いとICANREACHの_の元のSSPパケットを使用します。 以下のテーブルはこれらのパケットが2人のマルチキャストの有能なDLSw同輩の間のUDPを通してどう輸送されるかを説明します。
Transport
Message Event Action Mechanism Retry
--------------------------------------------------------------------
TEST SEND CANUREACH_ex Multicast/Unicast Yes
TEST RESPONSE SEND ICANREACH_ex Unicast No
輸送メッセージイベント動作メカニズム再試行-------------------------------------------------------------------- テストは元のマルチキャスト/ユニキャストはいテスト応答が送るCANUREACH_にICANREACHの_の元のユニキャストノーを送ります。
The following paragraphs provide more detail on how UDP transport and multicast protocol enhancements are used to establish SNA data links.
以下のパラグラフはUDP輸送とマルチキャストプロトコル増進がSNAデータ・リンクを証明するのにどう使用されるかに関するその他の詳細を提供します。
8.1 Address Resolution
8.1 アドレス解決
When a DLSw receives an incoming test frame from an attached data link, the assumption is that this is an exploratory frame in preparation for an XID exchange and link activation. The DLSw must determine a correlation between the destination LSAP (mac and sap pairing) and some other DLSw in the transport network. This paper generically refers to this process as 殿ddress resolution�.
DLSwが付属データ・リンクから入って来るテストフレームを受けるとき、仮定はこれがXID交換とリンク起動に備えた踏査のフレームであるということです。 DLSwは転送ネットワークで目的地LSAP(macと体液組み合わせ)とある他のDLSwの間の相関関係を決定しなければなりません。 この論文は一般的に殿ddress解決とこの過程を呼びますか?
8.2 Explorer frames
8.2 エクスプローラーフレーム
Address resolution messages may be sent over a TCP connection to a multicast capable DLSw peer if such a connection already exists in order that they take advantage of the guaranteed delivery of TCP. This is particularly recommended for ICANREACH_ex frames.
そのような接続がTCPの保証された配送を利用するために既に存在しているなら、マルチキャストの有能なDLSw同輩とのTCP接続の上にアドレス解決メッセージを送るかもしれません。 これは特にICANREACHの_の元のフレームに推薦されます。
Bryant & Brittain Informational [Page 16] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[16ページ]のRFC2166APPN Implementerのワークショップ1997年6月
8.3 Circuit Setup
8.3 サーキットセットアップ
Circuit setup is accomplished in the same manner as described in RFC 1795. More specifically, CANUREACH_cs, ICANREACH_cs, REACH_ACK, XIDFRAME, etc. are all sent over the TCP connection to the appropriate DLSw. This, of course, assumes the existence of a TCP connection between the DLSw peers. If the sending DLSw (sending a CANUREACH_cs ) detects no active TCP connection to the DLSw peer, then a TCP connection setup is initiated and the packet sent. All other circuit setup (and takedown) related sequences are now passed over the TCP connection.
サーキットセットアップはRFC1795で説明されるのと同じ方法で実行されます。 より明確に、CANUREACH_Cs、ICANREACH_Cs、REACH_ACK、XIDFRAMEなどを適切なDLSwとのTCP接続の上にすべて送ります。 これはもちろんDLSw同輩の間のTCP接続の存在を仮定します。 送付DLSw(CANUREACH_Csを送る)がどんな活発なTCP接続もDLSw同輩に検出しないなら、TCP接続設定は着手されました、そして、パケットは発信しました。 すべての他のサーキットセットアップ(そして、分解)関連配列が今、TCP接続の上に渡されます。
8.4 Example SNA SSP Message Sequence
8.4 例のSNA SSPメッセージ系列
The following diagram provides an example sequence of flows associated with an SNA LLC circuit setup. All flows and states described below correspond precisely with those defined in RFC 1795. The only exception is the addition of a TCP connection setup and DLSw capabilities exchange that occurs when the origin DLSw must send a CANUREACH_CS and no TCP connection yet exists to the target DLSw peer.
以下のダイヤグラムはSNA LLCサーキットセットアップに関連している流れの例の系列を提供します。 すべてが流れます、そして、以下で説明された州はまさにRFC1795で定義されるそれらに対応しています。 唯一の例外がTCP接続設定の添加です、そして、起源DLSwがまだCANUREACH_CSにもかかわらず、どんなTCPにも接続を送ってはいけないとき起こるDLSw能力交換は目標DLSw同輩に存在しています。
Bryant & Brittain Informational [Page 17] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[17ページ]のRFC2166APPN Implementerのワークショップ1997年6月
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | < Network > | | | ====== /______\ --------- \__ __/ --------- /______\ Origin Origin DLSw \___/ Target DLSw Target Station partner partner Station
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | <ネットワーク>。| | | ====== /______\ --------- \__ __/ --------- /______\起源起源DLSw\___/目標DLSw Target駅パートナーパートナー駅
disconnected disconnected
外された状態で、連絡を断ちます。
TEST_cmd DLC_RESOLVE_C CANUREACH_ex TEST_cmd
-----------> -----------> -----------> ---------->
TEST_rsp DLC_RESOLVE_R ICANREACH_ex TEST_rsp
<--------- <----------- <----------- <----------
null XID DLC_XID
-----------> ----------->
circuit_start
_テスト_cmd DLCの_の決心_CのCANUREACHの_の元のテストcmd----------->。----------->。----------->。----------_>の_の決心_R ICANREACHの_の元のテスト_rsp DLCテストrsp<。--------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-- ヌルXID DLC_XID----------->。----------->サーキット_始め
TCP Connection Setup
<------------->
Capabilities Exch.
<------------->
TCP接続設定<。------------->能力Exch。 <、-、-、-、-、-、-、-、-、-、-、-、-->。
CANUREACH_cs DLC_START_DL
-----------> ----------->
resolve_pending
ICANREACH_cs DLC_DL_STARTED
<----------- <-------------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
CANUREACH_Cs DLC_スタート_dl----------->。----------->決心_未定のICANREACH_Cs DLC_DL_STARTED<。----------- <、-、-、-、-、-、-、-、-、-、-、-、-- サーキット_は_サーキットの未定のREACH_ACKを設立しました。-----------_が確立した>サーキット
XIDFRAME DLC_XID null XID
-----------> ---------> -------->
XID DLC_XID XIDFRAME DLC_XID XID
<-------- <----------- <----------- <----------- <--------
XIDs DLC_XIDs XIDFRAMEs DLC_XIDs XIDs
<----------> <----------> <------------> <------------> <--------->
SABME DLC_CONTACTED CONTACT DLC_CONTACT SABME
-----------> -----------> -----------> -----------> -------->
connect_pending contact_pending
XIDFRAME DLC_XIDのヌルXID----------->。--------->。-------->XID DLC_XID XIDFRAME DLC_XID XID<。-------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-- XIDs DLC_XIDs XIDFRAMEs DLC_XIDs XIDs<。----------><。----------><。------------><。------------><。--------->SABME DLC_は接触DLC_接触SABMEに連絡しました。----------->。----------->。----------->。----------->。-------->は_未定の未定の接触_を接続します。
UA DLC_CONTACT CONTACTED DLC_CONTACTED UA
<--------- <----------- <----------- <----------- <--------
connected connected
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs
<----------> <-----------> <------------> <------------> <-------->
UaのDLC_接触の連絡されたDLC_はUa<に連絡しました。--------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-- 接続接続_INFOs IFRAMEs IFRAMEs DLC_INFOs IFRAMEs DLC<。----------><。-----------><。------------><。------------><。-------->。
Bryant & Brittain Informational [Page 18] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[18ページ]のRFC2166APPN Implementerのワークショップ1997年6月
8.5 UDP Reliability
8.5 UDPの信頼性
It is important to note, that UDP (unicast and multicast)transport services do not provide a reliable means of delivery. Existing RFC 1795 protocols guarantee the delivery (or failure notification) of CANUREACH_ex and ICANREACH_ex messages. UDP will not provide the same level of reliability. It is, therefore, possible that these messages may be lost in the network and (CANUREACH_ex) retries will be necessary.
それはUDP(ユニキャストとマルチキャスト)輸送サービスが配送の信頼できる手段を提供しないというメモに重要です。 既存のRFC1795プロトコルはCANUREACH_元の連れ合いとICANREACHの_の元のメッセージの配送(または、失敗通知)を保証します。 UDPは同じレベルの信頼性を提供しないでしょう。 したがって、これらのメッセージがネットワークで失われているのが、可能であり、(CANUREACH_元の連れ合い)再試行は必要になるでしょう。
8.5.1 Retries
8.5.1 再試行
Test Frames are generally initiated by end stations every few seconds. Many existing RFC 1795 DLSw implementations take advantage of the reliable SSP TCP connections and filter out end station Test frame retries when a CANUREACH_ex is outstanding. Given the unreliable nature of UDP transport for these messages, however, this filtering technique may not be advisable. Neither RFC 1795 nor this paper address this issue specifically. It is simply noted that the UDP transport mechanism is unreliable and implementations should take this into account when determining a scheme for Test frame filtering and explorer retries. Accordingly, the 迭etry� section in the table above only serves as an indicator of situations where retries may be desirable and/or necessary, but does not imply any requirement to implement retries. Also note, that retry logic only applies to non- response type packets. It is not appropriate to retry response type SSP packets (i.e., ICANREACH_ex) as there is no way of knowing if the original response was ever received (and whether retry is necessary). So in the case of SNA, CANUREACH_ex messages may need retry logic and ICANREACH_ex messages do not.
一般に、テストFramesはあらゆる数秒単位で端のステーションによって開始されます。 多くの既存のRFC1795DLSw実現は、頼もしいSSP TCP接続を利用して、CANUREACH_元の連れ合いが傑出しているとき、終わりのステーションTestフレーム再試行を無視します。 しかしながら、これらのメッセージのためのUDP輸送の頼り無い本質を考えて、このフィルター技術は賢明でないかもしれません。 RFC1795もこの論文も明確にこの問題を記述しません。 UDP移送機構が頼り無く、Testフレームフィルタリングと探検家再試行の計画を決定するとき実現がこれを考慮に入れるべきであることに単に注意されます。 それに従って、上のテーブルだけの迭etry?部は、再試行が望ましい、そして/または、必要であるかもしれない状況のインディケータとして機能しますが、再試行を実行するというどんな要件も含意しません。 再試行論理が非応答のタイプパケットに適用されるだけであるというメモも。 オリジナルの応答が今までに受けられたかどうかを(再試行が必要であるか否かに関係なく)知る方法が全くないとき、応答タイプSSPパケット(すなわち、ICANREACH_元の連れ合い)を再試行するのは適切ではありません。 それで、SNAの場合では、CANUREACHの_の元のメッセージは元のメッセージが必要としない再試行論理とICANREACH_を必要とするかもしれません。
Bryant & Brittain Informational [Page 19] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[19ページ]のRFC2166APPN Implementerのワークショップ1997年6月
9. NetBIOS
9. NetBIOS
With the introduction of DLSw Multicast transport, all multicast NetBIOS UI frames are carried outside the TCP connections between DLSw peers (i.e., via UDP datagrams). The following table defines the various NetBIOS UI frames and how they are transported via UDP between multicast capable DLSw peers:
DLSw Multicast輸送の導入で、すべてのマルチキャストNetBIOS UIフレームがDLSw同輩(すなわち、UDPデータグラムを通した)の間のTCP接続の外で運ばれます。 以下のテーブルはマルチキャストの有能なDLSw同輩の間で様々なNetBIOS UIフレームとそれらがUDPを通してどう輸送されるかを定義します:
Transport
Message Event Action Mechanism Retry
---------------------------------------------------------------------------
ADD_GROUP_NAME_QUERY SEND DATAFRAME Multicast Yes
ADD_NAME_QUERY SEND NETBIOS_ANQ Multicast Yes
ADD_NAME_RESPONSE SEND NETBIOS_ANR Unicast1 No
NAME_IN_CONFLICT SEND DATAFRAME Multicast No
STATUS_QUERY SEND DATAFRAME Unicast/Multicast(2) Yes
STATUS_RESPONSE SEND DATAFRAME Multicast(5) No
TERMINATE_TRACE (x'07') SEND DATAFRAME Multicast No
TERMINATE_TRACE (X'13') SEND DATAFRAME Multicast No
DATAGRAM SEND DATAFRAME(3) Unicast/Multicast(2) No
DATAGRAM_BROADCAST SEND DATAFRAME Multicast No
NAME_QUERY SEND NETBIOS_NQ_ex Unicast/Multicast(2) Yes
NAME_RECOGNIZED SEND NETBIOS_NR_ex Unicast(4) No
輸送メッセージイベント動作メカニズム再試行--------------------------------------------------------------------------- __名前_質問がDATAFRAMEマルチキャストはいを送るグループが、_名前_質問が_名前_応答が送る_ANQマルチキャストはいが_闘争における名前がない_がどんな状態_質問も_応答が(5)ノー、が終えるDATAFRAMEマルチキャストを送るDATAFRAMEユニキャスト/マルチキャスト(2)はい状態を送らないDATAFRAMEマルチキャストを送るNETBIOS_ANR Unicast1を言い足すNETBIOSに_跡を送ると言い足すと言い足してください; '(x'07')がいいえが終えるDATAFRAMEマルチキャストに_跡を送る、(X13年、'、)、どんな名前_質問もユニキャスト/マルチキャスト(2)はい名の_からの_が_元のユニキャスト(4)ノーをNETBIOS_NRに送ると認めたNETBIOS_NQを送らないDATAFRAMEマルチキャストをどんなデータグラムもどんなデータグラム_放送も送らないDATAFRAME(3)ユニキャスト/マルチキャスト(2)を送らないDATAFRAMEマルチキャストに送ってください。
Note 1: Upon receipt of an ADD_NAME_RESPONSE frame, a NETBIOS_ANR SSP message is returned via unicast UDP to the originator of the NETBIOS_ANQ message.
注意1: ADD_NAME_RESPONSEフレームを受け取り次第、NETBIOS_ANQメッセージの創始者へのユニキャストUDPを通してNETBIOS_ANR SSPメッセージを返します。
Note 2: These frames may be sent either Unicast or Multicast UDP. If the implementation has sufficient cached information to resolve the NetBIOS datagram destination to a single DLSw peer, then the SSP message can and should be sent via unicast. If the cache does not contain such information then the resultant SSP message must be sent via multicast UDP.
注意2: UnicastかMulticast UDPのどちらかをこれらのフレームに送るかもしれません。 実現に独身のDLSw同輩にNetBIOSデータグラムの目的地を決議できるくらいのキャッシュされた情報があるなら、SSPメッセージを送ることができて、ユニキャストで送るべきです。 キャッシュがそのような情報を含んでいないなら、マルチキャストUDPを通して結果のSSPメッセージを送らなければなりません。
Note 3: Note that this frame is sent as either a DATAFRAME or DGRMFRAME according to the rules as specified in RFC 1795.
注意3: RFC1795の指定されるとしての規則に従ってこのフレームがDATAFRAMEかDGRMFRAMEのどちらかとして送られることに注意してください。
Note 4: Upon receipt of a NAME_RECOGNIZED frame, a NETBIOS_NR_ex SSP message is returned via unicast UDP to the originator of the NETBIOS_NQ_ex frame. Notice that although the NAME_RECOGNIZED frame is sent as an All Routes Explorer (source routing LANs only) frame, the resultant NETBIOS_NR_ex is sent as a unicast UDP directed response to the DLSw originating the NETBIOS_NQ_ex. This is because there is no value in
注意4: NAME_RECOGNIZEDフレームを受け取り次第、NETBIOS_NQの_の元のフレームの創始者へのユニキャストUDPを通してNETBIOS_NRの_の元のSSPメッセージを返します。 NAME_RECOGNIZEDフレームを送りましたが、All Routesエクスプローラー(ソースルーティングLAN専用)フレーム、_元の連れ合いがユニキャストとして送られる結果のNETBIOS_NRとして、UDPがNETBIOS_NQ_を溯源するDLSwへの応答を指示したのに注意してください、例えば。 これは中に値が全くないからです
Bryant & Brittain Informational [Page 20] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[20ページ]のRFC2166APPN Implementerのワークショップ1997年6月
sending NETBIOS_NR_ex as a multicast packet in the transport network. The use of ARE transmission in the LAN environment is to accomplish some form of load sharing in the source routed LAN environment. Since no analogous capability exists in the (TCP) transport network, it is not necessary to emulate this function there. It is important to note, however, that when converting a received NETBIOS_NR_ex to a NAME_RECOGNIZED frame, the DLSw sends the NAME_RECOGNIZED frame onto the LAN as an ARE (source routing LANs only) frame. This preserves the source route load sharing in the LAN environments on either side of the DLSw transport network.
マルチキャストパケットとして転送ネットワークでNETBIOS_NR_元の連れ合いを送ります。 使用、中のLAN環境が実行することになっているソースの何らかのフォームの負荷分割法が発送したトランスミッションはLAN環境ですか? どんな類似の能力も(TCP)転送ネットワークで存在していないので、そこでこの機能を見習うのは必要ではありません。 それ、しかしながら、容認されたNETBIOS_NR_元の連れ合いをNAME_RECOGNIZEDフレームに変換するとき、DLSwがNAME_RECOGNIZEDフレームをLANに送ることに注意するために重要である、(ソースルーティングLAN専用)はフレームですか? これはDLSw転送ネットワークのどちらかの側面のLAN環境における送信元経路負荷分割法を保存します。
Note 5: Although RFC 1795 does not attempt to optimize STATUS_RESPONSE processing, it is possible to send a STATUS_RESPONSE as a unicast UDP response. To do this, DLSws receiving an incoming SSP DATAFRAME containing a STATUS_QUERY must remember the originating DLSw's address and STATUS_QUERY correlator. Then upon receipt of the corresponding STATUS_RESPONSE, the DLSw responds via unicast UDP to the originating DLSw(using the remembered originating DLSw address). Note, however, that in order to determine whether a frame is a STATUS_QUERY, all multicast capable DLSw implementations will need to parse the contents of frames that would normally be sent as DATAFRAME SSP messages.
注意5: RFC1795は、STATUS_RESPONSE処理を最適化するのを試みませんが、ユニキャストUDP応答としてSTATUS_RESPONSEを送るのは可能です。 これをするために、STATUS_QUERYを含む入って来るSSP DATAFRAMEを受けるDLSwsは起因しているDLSwのアドレスとSTATUS_QUERY相関器を覚えていなければなりません。 そして対応するSTATUS_RESPONSEを受け取り次第、DLSwは起因しているDLSwへのユニキャストUDPを通して応じます(覚えていられた起因しているDLSwアドレスを使用して)。 しかしながら、すべてのマルチキャストのできるDLSw実装が、フレームがSTATUS_QUERYであるかどうか決定するのに通常、DATAFRAME SSPメッセージとして送られるフレームのコンテンツを分析する必要に注意してください。
All other multicast frames are sent into the transport network using the appropriate multicast group address.
適切なマルチキャストグループアドレスを使用することで他のすべてのマルチキャストフレームを転送ネットワークに送ります。
9.1 Address Resolution
9.1 アドレス解決
Typical NetBIOS circuit setup using multicast services is essentially the same as specified in RFC 1795. The only significant difference is that NETBIOS_NQ_ex messages are sent via UDP to the appropriate unicast/multicast IP address and the NETBIOS_NR_ex is sent via unicast UDP to the DLSw originating the NETBIOS_NQ_ex.
マルチキャストサービスを利用する典型的なNetBIOS回路セットアップはRFC1795で指定されるのと本質的には同じです。 唯一の著しい違いが適切なユニキャスト/マルチキャストIPアドレスへのUDPを通してNETBIOS_NQの_の元のメッセージを送って、NETBIOS_NQ_を溯源するDLSwへのユニキャストUDPを通してNETBIOS_NR_元の連れ合いを送るということである、例えば。
9.2 Explorer Frames
9.2 エクスプローラーフレーム
Address resolution messages may be sent over a TCP connection to a multicast capable partner if such a connection already exists in order that they take advantage of the guaranteed delivery of TCP. This is particularly recommended for NETBIOS_NR_ex frames.
そのような接続がTCPの保証された配送を利用するために既に存在しているなら、マルチキャストの有能なパートナーとのTCP接続の上にアドレス解決メッセージを送るかもしれません。 これは特にNETBIOS_NRの_の元のフレームに推薦されます。
9.3 Circuit Setup
9.3 回路セットアップ
Following successful address resolution, a NetBIOS end station typically sends a SABME frame to initiate a formal LLC2 connection. Receipt of this message results in normal circuit setup as described in RFC 1795 (and the SNA case described above). That is to say that
うまくいっているアドレス解決に続いて、NetBIOS端のステーションは、礼儀正しいLLC2接続を開始するためにSABMEフレームを通常送ります。 このメッセージの領収書はRFC1795(そして、上で説明されたSNAケース)で説明されるように通常の回路セットアップをもたらします。 すなわち、それ
Bryant & Brittain Informational [Page 21] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[21ページ]のRFC2166APPN Implementerのワークショップ1997年6月
the CANUREACH_cs messages etc. are sent on a TCP connection to the appropriate DLSw peer. If no such TCP connection exists, one is brought up.
CANUREACH_Csメッセージなどを適切なDLSw同輩とのTCP接続に送ります。 何かそのようなTCP接続が存在していないなら、1つは持って来られます。
9.4 Example NetBIOS SSP Message Sequence
9.4 例のNetBIOS SSPメッセージ系列
The following diagram provides an example sequence of flows associated with a NetBIOS circuit setup. All flows and states described below correspond precisely with those defined in RFC 1795. The only exception is the addition of a TCP connection setup and DLSw capabilities exchange that occurs when the origin DLSw must send a CANUREACH_cs and no TCP connection yet exists to the target DLSw peer.
以下のダイヤグラムはNetBIOS回路セットアップに関連している流れの例の系列を提供します。 すべてが流れます、そして、以下で説明された州はまさにRFC1795で定義されるそれらに対応しています。 唯一の例外がTCP接続設定の追加です、そして、CANUREACH_Csを送りますが、発生源DLSwがまだどんなTCP接続も送ってはいけないとき起こるDLSw能力交換が目標DLSw同輩に存在しています。
Bryant & Brittain Informational [Page 22] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[22ページ]のRFC2166APPN Implementerのワークショップ1997年6月
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | < Network > | | | ====== /______\ --------- \__ __/ --------- /______\ Origin Origin DLSw \___/ Target DLSw Target Station partner partner Station
====== ___ ====== | | --------- __/ \__ --------- | | | | __| _|_ |__ / IP \ __| _|_ |__ | | ====== | | | <ネットワーク>。| | | ====== /______\ --------- \__ __/ --------- /______\発生源発生源DLSw\___/目標DLSw Target駅パートナーパートナー駅
disconnected disconnected
切断された状態で、切断されます。
NAME_QUERY DLC_DGRM NETBIOS_NQ_ex DLC_DGRM NAME_QUERY -----------> -----------> -----------> -----------> --------->
名前_質問DLC_DGRM NETBIOS_NQ_元の連れ合いDLC_DGRM名前_質問----------->。----------->。----------->。----------->。--------->。
NAME_RECOG DLC_DGRM NETBIOS_NR_ex DLC_DGRM NAME_RECOG <----------- <------------ <----------- <----------- <---------
_名前_RECOG DLCの_のDGRM NETBIOS_NRの_の元のDLC_DGRM名のRECOG<。----------- <、-、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、--
SABME DLC_CONTACTED
-----------> ----------->
circuit_start
連絡されたSABME DLC_----------->。----------->回路_始め
TCP Connection Setup
<------------->
Capabilities Exch.
<------------->
TCP接続設定<。------------->能力Exch。 <、-、-、-、-、-、-、-、-、-、-、-、-->。
CANUREACH_cs DLC_START_DL
-----------> ----------->
resolve_pending
CANUREACH_Cs DLC_スタート_dl----------->。-----------未定の>決心_
ICANREACH_cs DLC_DL_STARTED
<----------- <-----------
circuit_established circuit_pending
REACH_ACK
-----------> circuit_established
ICANREACH_Cs DLC_dl_は<を始動しました。----------- <、-、-、-、-、-、-、-、-、-、-- 回路_は_回路の未定のREACH_ACKを設立しました。-----------_が確立した>回路
CONTACT DLC_CONTACT SABME
-----------> -----------> --------->
connect_pending contact_pending
接触DLC_接触SABME----------->。----------->。--------->は_未定の未定の接触_を接続します。
UA DLC_CONTACT CONTACTED DLC_CONTACTED UA
<--------- <----------- <----------- <----------- <---------
connected connected
UaのDLC_接触の連絡されたDLC_はUa<に連絡しました。--------- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-、-、-- <、-、-、-、-、-、-、-、-- 接続されていた状態で、接続されます。
IFRAMEs DLC_INFOs IFRAMEs DLC_INFOs IFRAMEs <------------> <------------> <------------> <------------> <-------->
IFRAMEs DLC_インフォメーションIFRAMEs DLC_インフォメーションIFRAMEs<。------------><。------------><。------------><。------------><。-------->。
Bryant & Brittain Informational [Page 23] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[23ページ]のRFC2166APPN Implementerのワークショップ1997年6月
9.5 Multicast Reliability and Retries
9.5 マルチキャストの信頼性と再試行
In the case of NetBIOS, many more packets are being sent via UDP than in the SNA case. Therefore, the exposure to the unreliability of these services is greater than that of SNA. For address resolution frames, such as NAME_QUERY, etc., successful message delivery is an issue. In addition, the retry interval for these types of frames is considerably shorter than SNA with the defaults being: retry interval = 0.5 seconds and retry count = 6. Once again, neither RFC 1795 nor this paper attempt to address the issue of LAN frame filtering optimizations. This issue is outside the scope of this paper. But it is important for implementers to recognize the inherent unreliable nature of UDP transport services for frames of this type and to implement retry schemes that are appropriate to successful operation. Again, it is only appropriate to consider retry of non-response type packets. Specific NetBIOS messages where successful message delivery is considered important (and retries possibly necessary) are indicated in the table above with an 添es� in the 迭etry� column.
NetBIOSの場合では、SNAケースよりUDPを通してずっと多くのパケットを送ります。 したがって、これらのサービスの非信頼性への暴露はSNAのものよりすばらしいです。 NAME_QUERYなどのアドレス解決フレームなどのために、うまくいっているメッセージ配送は問題です。 さらに、これらのタイプのフレームへの再試行間隔はデフォルトがあるSNAよりかなり短いです: 再試行間隔は0.5秒と再試行カウント=6と等しいです。 もう一度、RFC1795もこの紙も、LANフレームフィルタリング最適化の問題を扱うのを試みません。 この紙の範囲の外にこの問題はあります。 しかし、implementersがこのタイプのフレームのためのUDP輸送サービスの固有の頼り無い本質を認識して、うまくいっている操作に適切な再試行体系を実装するのは重要です。 一方、単に非応答タイプパケットの再試行を考えるのは適切です。 うまくいっているメッセージ配送が重要であると考えられる(そして、ことによると必要な状態で、再試行します)特定のNetBIOSメッセージは添esによる上のテーブル、迭etryで示されます--コラム。
10. Sequencing
10. 配列
It is important to note that UDP transport services do not provide guaranteed packet sequencing like TCP does for RFC 1795. In a steady state network, in order packet delivery can be generally assumed. But in the presence of network outages and topology changes, packets may take alternate routes to the destination and arrive out of sequence with respect to their original transmission order. For SNA address resolution this should not be a problem given that there is no inherent significance to the order of packets being transmitted via UDP.
TCPがRFC1795のためにするようにUDP輸送サービスが保証されたパケット順序制御を提供しないことに注意するのは重要です。 一般に、定常状態ネットワーク、オーダーでは、パケット配信を想定できます。 しかし、ネットワーク供給停止とトポロジー変化があるとき、パケットは、目的地に代替経路を持って行って、彼らのオリジナルのトランスミッション命令に関して順序が狂って到着するかもしれません。 SNAアドレス解決のために、UDPを通して伝えられるパケットの注文へのどんな固有の意味もなければ、これは問題であるべきではありません。
In the case of NetBIOS, in order delivery is not guaranteed in the normal case (e.g., LANs). This is because LAN broadcasting mechanisms suffer the same problems of packet sequencing as do WAN multicast mechanisms. But one might argue the greater likelihood of topology related changes in the WAN environment and thus a greater level of concern. The vast majority of NetBIOS UI frames (being handled via UDP and Multicast) have correlator values and do not rely upon packet sequencing.
NetBIOSに関するケース、オーダーでは、配送は正常な場合(例えば、LAN)で保証されません。 これはLAN放送メカニズムがWANマルチキャストメカニズムのようにパケット順序制御の同じ問題を受けるからです。しかし、人はWAN環境とその結果、より大きいレベルの関心におけるトポロジー関連変化のより大きな見込みについて論争するかもしれません。 かなりの大多数のNetBIOS UIフレーム(UDPを通して扱われて、Multicast)は、相関器値を持って、パケット順序制御を当てにされません。
Bryant & Brittain Informational [Page 24] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[24ページ]のRFC2166APPN Implementerのワークショップ1997年6月
The only NetBIOS frames of special note would be: DATAGRAM, DATAGRAM_BROADCAST, and STATUS_RESPONSE. In the case of DATAGRAM and DATAGRAM_BROADCAST it is generally assumed that datagrams do not provide any guarantee of in order packet delivery. Thus applications utilizing this NetBIOS service are assumed to have no dependency on in order packet delivery. STATUS_RESPONSE can actually be sent as a sequence of STATUS_RESPONSE messages. In cases where this occurs, the STATUS_RESPONSE will be exposed to potential out of sequence delivery.
特別な注意の唯一のNetBIOSフレームは以下の通りでしょう。 データグラム、データグラム_放送、および状態_応答。 一般に、データグラムとデータグラム_BROADCASTの場合では、データグラムがコネのどんな保証にもオーダーパケット配信を提供しないと思われます。 したがって、このNetBIOSサービスを利用するアプリケーションがオーダーパケット配信でオンに依存を全く持っていないと思われます。 実際にSTATUS_RESPONSEメッセージの系列としてSTATUS_RESPONSEを送ることができます。 これが起こる場合では、STATUS_RESPONSEは系列配送から可能性にさらされるでしょう。
11. Frame Formats
11. フレーム形式
11.1 Multicast Capabilities Control Vector
11.1 マルチキャスト能力はベクトルを制御します。
This control vector is carried in the Capabilities Exchange Request. When present, it must be accompanied by a TCP Connections Control Vector indicating support for 1 TCP/IP connection and a DLSw version CV indicating support for version 2 release 0. Like all control vectors in this SSP message, it is an LT structure. LT structures consist of a 1 byte length field followed by a 1 byte type field. The length field includes itself as well as the type and data fields.
このコントロールベクトルはCapabilities Exchange Requestで運ばれます。 存在しているとき、1つのTCP/IP接続とCVがバージョン2のためにリリースが0であるとサポートするのを示すDLSwバージョンのサポートを示すTCPコネクションズControl Vectorはそれに伴わなければなりません。 すべてがこのSSPメッセージのベクトルを制御するように、それはLT構造です。 LT構造は1バイトのタイプ分野があとに続いた1バイトの長さの分野から成ります。 長さの分野はタイプとデータ・フィールドと同様にそれ自体を含んでいます。
Byte Bit Description 0 0-7 Length, in binary, of the Multicast Capabilities control vector (inclusive of this byte, always 3)
Multicast CapabilitiesコントロールベクトルのバイナリーのバイトBit記述0 0-7Length(このバイト、いつも3で包括的)です。
1 0-7 Type: x'8C'
1 0-7 タイプしてください: x'8C'
2 0-7 Multicast Version Number:
A binary numerical representation of the level of
multicast services provided. The protocols as identified
in this document constitute version one. Accordingly,
x'01' is encoded in this field. Any subsequent version
must provide the services of all previous versions.
2 0-7 マルチキャストバージョン番号: マルチキャストサービスのレベルの2進の数字の表現は提供されました。 本書では特定されるプロトコルはバージョン1を構成します。 それに従って、x'01'はこの分野でコード化されます。 どんなその後のバージョンもすべての旧バージョンのサービスを提供しなければなりません。
The intended use of this CV for Multicast support is to detect when the multicast CANUREACH_ex flows will suffice between partners. If this CV is present in a CAPEX from a partner, that partner is also multicast capable and therefore does not need to receive CANUREACH_ex messages over the TCP link that exists between them (and there must be one or else the CAPEX would not have flowed) because it will receive the multicast copies.
このCVのMulticastサポートの意図している使用はマルチキャストのCANUREACHの_の元の流れがいつパートナーの間で十分であるかを検出することです。 このCVがCAPEXにパートナーから存在しているなら、そのパートナーは、また、マルチキャストできて、したがって、マルチキャストコピーを受けるのでそれら(1つがないに違いないでしょうか、CAPEXは流れていない)の間に存在するTCPリンクの上にCANUREACHの_の元のメッセージを受け取る必要はありません。
A DLSw includes this control vector on a peer-wise basis. That is to say, that a DLSw implementation may support multicast services but choose not to indicate this in its capabilities exchange to all partners. Therefore, a DLSw may include this capabilities CV with some DLSw peers and not with others. Not including this vector can
DLSwは同輩的なベースでこのコントロールベクトルを含んでいます。 すなわち、DLSw実装が、マルチキャストサービスをサポートしますが、能力でこれを示さないのを選ぶかもしれないのがパートナーをすべてと交換します。 したがって、DLSwは他のものではなく、何人かのDLSw同輩がいるこの能力CVを含むかもしれません。 このベクトルを含んでいないのはそうすることができます。
Bryant & Brittain Informational [Page 25] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[25ページ]のRFC2166APPN Implementerのワークショップ1997年6月
be used to force TCP connections with other multicast capable nodes and degrade to normal RFC 1795 operations. This capability is allowed to provide greater network design flexibility.
使用されて、他のマルチキャストのできるノードでTCP接続を強制して、1795の操作を正常なRFCまで下がらせてください。 この能力は、より大きいネットワークデザインの柔軟性を提供できます。
When sending this capabilities exchange control vector, the following rules apply:
この能力為替管理ベクトルを送るとき、以下の規則は適用されます:
Required Allowed @
ID @ Startup Length Repeatable* Runtime Order Content
==== ========= ====== ========== ======= ===== ===============
0x8C Y 0x03 N N 5+ Multicast
Capabilities
必要な許容@ID@始動長さのRepeatable*ランタイムオーダー内容==== ========= ====== ========== ======= ===== =============== 0x8C Y0x03N N5+マルチキャスト能力
*Note: "Repeatable" means a Control Vector is repeatable within a single message.
*以下に注意してください。 "Repeatable"は、Control Vectorがただ一つのメッセージの中で反復可能であることを意味します。
11.1.1 DLSw Capabilities Negative Response
11.1.1 DLSw能力否定応答
DLSws that implement these enhancements must provide support for both multicast version 1 and single TCP connections. This means that the capabilities exchange request must contain a DLSw Version ID control vector (x'82') indicating support for version 2 release 0, a Multicast Capabilities control vector, and the TCP Connections control vector indicating support for 1 TCP connection within a given capabilities exchange. If a multicast capable DLSw receives a capabilities exchange with a Multicast Capabilities, but either a missing or inappropriate TCP Connections CV (i.e., connections not equal to one)or DLSw Version control vector, then the inbound capabilities exchange should be rejected with a DLSw capabilities exchange negative response (see RFC 1795) using the following new reason code:
これらの増進を実装するDLSwsはマルチキャストバージョン1と単独のTCP接続の両方のサポートを提供しなければなりません。 '能力交換が要求するこの手段がDLSwバージョンIDコントロールベクトルを含まなければならない、(x82年、'、)、与えられた能力交換の中に1つのTCP接続のサポートを示すバージョン2リリース0、Multicast Capabilitiesコントロールベクトル、およびTCPコネクションズコントロールベクトルのサポートを示します。 マルチキャストできるDLSwがMulticast Capabilitiesとの能力交換、しかし、なくなったか不適当なTCPコネクションズCV(すなわち、1つと等しくない接続)かDLSwバージョンコントロールベクトルのどちらかを受けるなら、DLSw能力交換否定的な応答(RFC1795を見る)が以下の新しい理由コードを使用している状態で、本国行きの能力交換は拒絶されるべきです:
x'000D'Inconsistent DLSw Version, Multicast Capabilities, and TCP Connections CV received on the inbound Capabilities exchange
'コネクションズCVが本国行きのCapabilities交換のときに受けたx'000D'矛盾したDLSwバージョン、Multicast Capabilities、およびTCP'
11.2 UDP Packets
11.2 UDPパケット
SSP frame formats are defined in RFC 1795. Multicast protocol enhancements do not change these formats in any way. The multicast protocol enhancements, however, do introduce the notion of SSP packet transport via UDP. In this case, standard UDP services and headers are used to transport SSP packets.
SSPフレーム形式はRFC1795で定義されます。 マルチキャストプロトコル増進は何らかの方法でこれらの形式を変えません。 しかしながら、マルチキャストプロトコル増進はUDPを通してSSPパケット輸送の概念を紹介します。 この場合、標準のUDPサービスとヘッダーは、SSPパケットを輸送するのに利用されます。
Bryant & Brittain Informational [Page 26] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[26ページ]のRFC2166APPN Implementerのワークショップ1997年6月
The following section describes the proper UDP header for DLSw SSP packets.
以下のセクションはDLSw SSPパケットのために適切なUDPヘッダーについて説明します。
Byte Description
0-1 Source Port address
In DLSw multicast protocols, this particular field is not
relevant. It may be set to any value.
バイト記述0-1Source PortはマルチキャストプロトコルをIn DLSwに扱って、この特定の分野は関連していません。 それはどんな値にも設定されるかもしれません。
2-3 Destination Port address
Always set to 2067
2-3 目的地PortアドレスAlwaysは2067にセットしました。
4-5 Length
4-5 長さ
6-7 Checksum
The standard UDP checksum value. Use of the UDP checksum
function is optional.
6-7 標準のUDPチェックサムが評価するチェックサム。 UDPチェックサム機能の使用は任意です。
11.3 Vendor Specific UDP Packets
11.3 ベンダーの特定のUDPパケット
In order to accommodate the addition of vendor specific functions over UDP transport, a new SSP packet header has been defined. As described above, it is possible to receive these packets over both UDP and TCP (when a TCP connection already exists).
UDP輸送の上にベンダー具体的な機能の追加を収容するために、新しいSSPパケットのヘッダーは定義されました。 上で説明されるように、UDPとTCPの両方の上にこれらのパケットを受けるのは可能です(TCP接続が既に存在していると)。
It is important to note that the first 4 bytes of this packet match the format of existing RFC 1795 SSP packets. This is done so that implementations in the future can expect that the DLSw 天ersion Number� is found in byte one and that the following bytes describe the packet header and message length.
このパケットの最初の4バイトが既存のRFC1795SSPパケットの形式に合っていることに注意するのは重要です。 実装が、将来DLSw天ersion Number?がバイト1で見つけられて、以下のバイトがパケットのヘッダーとメッセージ長について説明すると予想できるように、これをします。
Furthermore, to assist DLSws in detecting 'out-of-sync' conditions whereby packet or parsing errors lead to improper length interpretations in the TCP datastream, valid DLSw version numbers will be restricted to the range of x'31' through x'3F' inclusive.
'その上、パケットか構文解析誤りがTCP datastreamの不適当な長さの解釈につながる'同期していない'状態を検出するのにDLSwsを助けるために、有効なDLSwバージョン番号はx31年'x'3のF'の範囲に包括的に制限されるでしょう。
DLSw multicast Vendor Specific frame format differs from existing RFC 1795 packets in the following ways:
DLSwマルチキャストVendor Specificフレーム形式は以下の方法で既存のRFC1795パケットと異なっています:
1) The 天ersion Number� field is set to x'32' (ASCII '2') and now represents a packet type more than a DLSw version number. More precisely, it is permitted and expected that DLSw may send packets of both types (x'31' and x'32').
1) '天ersion Number?分野は、'(ASCII'2')をx32年に設定することであり、現在、DLSwバージョン番号よりもう少しパケットタイプの代理をします。 'DLSwが両方のタイプ(x31年と'x32年')のパケットを送るかもしれないと、より正確に、許可されていて、予想されます。
2) The message length field is followed by a new 3 byte field that contains the specific vendor's IEEE Organizationally Unique Identifier (OUI).
2) 特定のベンダーのIEEE Organizationally Unique Identifier(OUI)を含む3バイトの新しい分野はメッセージ長野原のあとに続いています。
Bryant & Brittain Informational [Page 27] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[27ページ]のRFC2166APPN Implementerのワークショップ1997年6月
3) All fields following the new OUI field are arbitrary and defined by implementers.
3) 新しいOUI野原に続くすべての分野が、任意であり、implementersによって定義されます。
The following section defines this new packet format:
以下のセクションはこの新しいパケット・フォーマットを定義します:
Byte Description 0 DLSw packet type, Always set to x'32'
'バイト記述0DLSwパケットタイプ、x32年に用意ができているAlways'
1 Header Length
Always 7 or higher
1 ヘッダーLength Alwaysより多くの7
2-3 Message Length
Number of bytes within the data field following the
header.
2-3 ヘッダーに続くデータ・フィールドの中のバイトのメッセージLength Number。
4-6 Vendor specific OUI
The IEEE Organizationally Unique Identifier (OUI)
associated with the vendor specific function in
question.
4-6 ベンダー具体的な機能がはっきりしていなく、ベンダーの特定のOUI IEEE Organizationally Unique Identifier(OUI)は交際しました。
7-n Defined by the OUI owner
OUI所有者による7-n Defined
12. Compliance Statement
12. 承諾声明
All DLSw v2.0 implementations must support
DLSw v2.0実装がサポートしなければならないすべて
- Halt reason codes
- the Multicast Capabilities control vector in the DLSw
capabilities exchanges messages.
- 理由コードを止めてください--DLSw能力におけるMulticast Capabilitiesコントロールベクトルはメッセージを交換します。
The presence of the Multicast Capabilities control vector in a capabilities exchange message implies that the DLSw that issued the message supports all the scalability enhancements defined in this document. These are:
能力交換メッセージにおける、Multicast Capabilitiesコントロールベクトルの存在は、メッセージを発行したDLSwが、すべてのスケーラビリティが本書では定義された増進であるとサポートするのを含意します。 これらは以下の通りです。
- use of multicast IP (if it is available in the underlying network) - use of 2067 as the destination port for UDP and TCP connections - single tunnel bring-up of TCP connections to DLSw peers - peer-on-demand - quiet ignore of all unrecognized vendor-specific UDP/TCP packets.
- IP(それが基本的なネットワークで利用可能であるなら)--仕向港としての2067のUDPとTCP接続の使用--単一のトンネルが持って来る静かが無視するすべての認識されていないベンダー特有のUDP/TCPパケットの同輩要求次第のDLSw同輩とのTCP接続のマルチキャストの使用。
Bryant & Brittain Informational [Page 28] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[28ページ]のRFC2166APPN Implementerのワークショップ1997年6月
13. Security Considerations
13. セキュリティ問題
This document addresses only scalability problems in RFC 1795. No attempt is made to define any additional security mechanisms. Note that, as in RFC 1795, a given implementation may still choose to refuse TCP connections from DLSw peers that have not been configured by the user. The mechanism by which the user configures this behavior is not specified in this document.
このドキュメントはRFC1795のそのスケーラビリティ問題だけを訴えます。 どんな追加担保メカニズムも定義するのを試みを全くしません。与えられた実装が、RFC1795のようにユーザによって構成されていないDLSw同輩からTCP接続を拒否するのをまだ選んでいるかもしれないことに注意してください。 ユーザがこの振舞いを構成するメカニズムは本書では指定されません。
14. Acknowledgements
14. 承認
This specification was developed in the DLSw Related Interest Group (RIG) of the APPN Implementers Workshop. This RIG is chaired by Louise Herndon- Wells (lhwells@cup.portal.com) and edited by Paul Brittain (pjb@datcon.co.uk).
この仕様はAPPN Implementers WorkshopのDLSwの関連Interest Group(RIG)で開発されました。 このRIGはルイーズ・ハーンドン・ウェルズ( lhwells@cup.portal.com )によってまとめられて、ポールBrittain( pjb@datcon.co.uk )によって編集されます。
Much of the work on the scalability enhancements for v2.0 was developed by Dave Bryant (3COM).
v2.0のためのスケーラビリティ増進に対する仕事の多くがデーヴブライアント(3COM)によって発生されました。
Other significant contributors to this document include:
このドキュメントへの他の重要な寄稿者は:
Frank Bordonaro (Cisco) Jon Houghton (IBM) Steve Klein (IBM) Ravi Periasamy (Cisco) Mike Redden (Proteon) Doug Wolff (3COM)
フランクBordonaro(シスコ)ジョンホートン(IBM)スティーブクライン(IBM)ラービーPeriasamy(シスコ)マイクは(Proteon)ダグ・ヴォルフを赤くします。(3COM)
Many thanks also to all those who participated in the DLSw RIG sessions and mail exploder discussions.
また、DLSw RIGセッションとメール発破器議論に参加したすべての人をありがとうございます。
If you would like to participate in future DLSw discussions, please subscribe to the DLSw RIG mailing lists by sending a mail to majordomo@raleigh.ibm.com specifying 'subscribe aiw-dlsw' as the body of the message.
今後のDLSw議論に参加したいなら、メッセージ欄として'aiw-dlswを申し込んでください'を指定する majordomo@raleigh.ibm.com にメールを送ることによって、DLSw RIGメーリングリストに加入してください。
If you would like further information on the activities of the AIW, please refer to the AIW web site at http://www.raleigh.ibm.com/app/aiwhome.htm.
AIWの活動に関する詳細が欲しいなら、 http://www.raleigh.ibm.com/app/aiwhome.htm のAIWウェブサイトを参照してください。
Bryant & Brittain Informational [Page 29] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[29ページ]のRFC2166APPN Implementerのワークショップ1997年6月
15. Authors' Addresses
15. 作者のアドレス
The editor of this document is:
このドキュメントのエディタは以下の通りです。
Paul Brittain
Data Connection Ltd
Windsor House
Pepper Street
Chester
CH1 1DF
UK
ポール・Brittainデータ接続Ltdウインザー家のコショウ通りチェスターCH1 1DFイギリス
tel: +44 1244 313440
email: pjb@datcon.co.uk
tel: +44 1244 313440はメールされます: pjb@datcon.co.uk
Much of the work on this document was created by:
このドキュメントへの作業の多くが以下によって作成されました。
David Bryant
3Com Corporation
5400 Bayfront Plaza MS 2418
Santa Clara, CA 95052
デヴィッドブライアント3Com社5400のBayfront広場MS2418サンタクララ、カリフォルニア 95052
tel: (408) 764-5272
email: David_Bryant@3mail.3com.com
tel: (408) 764-5272 メールしてください: David_Bryant@3mail.3com.com
Bryant & Brittain Informational [Page 30] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[30ページ]のRFC2166APPN Implementerのワークショップ1997年6月
16. Appendix - Clarifications to RFC 1795
16. 付録--RFC1795への明確化
This appendix attempts to clarify the areas of RFC 1795 that have proven to be ambiguous or hard to understand in the implementation experience to- date. These clarifications should be read in conjunction with RFC 1795 as this document does not reproduce the complete text of that RFC.
この付録が、あいまいであるか、または実装経験で理解しにくいと判明したRFC1795の領域をはっきりさせるのを試みる、-、デートしてください。 このドキュメントがそのRFCの全文を再生させないとき、これらの明確化はRFC1795に関連して読まれるべきです。
The clarifications are ordered by the section number in RFC 1795 to which they apply. Where one point applies to more than one place in RFC 1795, it is listed below by the first relevant section.
明確化はそれらが適用するRFC1795でセクション番号によって命令されます。 1ポイントがRFC1795の1つ以上の場所に適用されるところでは、それは以下に最初の関連セクションによって記載されています。
If any implementers encounter further difficulties in understanding RFC 1795 or these clarifications, they are encouraged to query the DLSw mail exploder (see section 1.1) for assistance.
どれかimplementersがさらにRFC1795を理解することにおける苦労かこれらの明確化に遭遇するなら、支援のためにDLSwメール発破器について質問するよう(セクション1.1を見ます)奨励されます。
3. Send Port
3. ポートを送ってください。
It is not permitted for a DLSw implementation to check that the send port used by a partner is 2067. All implementations must accept connections from partners that do not use this port.
発信してください。それがDLSw実装がそれをチェックすることが許可されていない、パートナーによって使用されたポートは2067です。 すべての実装がこのポートを使用しないパートナーから接続を受け入れなければなりません。
3 TCP Tunnel bringup
3 TCP Tunnel bringup
The paragraph below the figure should read as follows:
図より下であるのにおけるパラグラフは以下の通り読むべきです:
Each Data Link Switch will maintain a list of DLSw capable routers
and their status (active/inactive). Before Data Link Switching can
occur between two routers, they must establish two TCP connections
between them. These connections are treated as half duplex data
pipes. A Data Link Switch will listen for incoming connections on
its Read Port (2065), and initiate outgoing connections on its
Write Port (2067). Each Switch is responsible for initiating one
of the two TCP connections. After the TCP connections are
established, SSP messages are exchanged to establish the
capabilities of the two Data Link Switches. Once the exchange is
complete, the DLSw will employ SSP control messages to establish
end-to-end circuits over the transport connection. Within the
transport connection, DLSw SSP messages are exchanged. The
message formats and types for these SSP messages are documented in
the following sections.
各Data Link Switchは、DLSwのリストができるルータとそれらの状態(アクティブであるか不活発な)であることを支持するでしょう。 Data Link Switchingが2つのルータの間に起こることができる前に、それらは彼らの間の2つのTCP接続を確立しなければなりません。 これらの接続は半二重データパイプとして扱われます。 Data Link SwitchはRead Port(2065)で接続要求の聞こうとして、Write Port(2067)で外向的な接続を開始するでしょう。 それぞれのSwitchは2つのTCP接続のひとりを開始するのに責任があります。 TCP接続を確立した後に、2Data Link Switchesの能力を証明するためにSSPメッセージを交換します。 交換がいったん完全になると、DLSwは輸送接続の上で終わりから端への回路を確立するSSPコントロールメッセージを使うでしょう。 輸送接続の中では、DLSw SSPメッセージを交換します。 これらのSSPメッセージのためのメッセージ・フォーマットとタイプは以下のセクションで記録されます。
Bryant & Brittain Informational [Page 31] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[31ページ]のRFC2166APPN Implementerのワークショップ1997年6月
3.2 RII bit in SSP header MAC addresses
3.2 SSPヘッダーMACアドレスで噛み付かれたRII
The RII bit in MAC addresses received from the LAN must be set to zero before forwarding in the source or destination address field in a SSP message header. This requirement aims to avoid ambiguity of circuit IDs. It is also recommended that all implementations ignore this bit in received SSP message headers.
LANから受け取られたMACアドレスのRIIビットは推進の前のソースのゼロかSSPメッセージヘッダーの目的地アドレス・フィールドへのセットであるに違いありません。 この要件は、回路IDのあいまいさを避けることを目指します。 また、実装がこのビットを無視するすべてがSSPメッセージヘッダーを受けたのも、お勧めです。
3.3 Transport IDs
3.3 輸送ID
All implementations must allow for the DLSw peer varying the Transport ID up to and including when the ICR_cs message flows, and at all times reflect the most recent TID received from the partner in any SSP messages sent. The TID cannot vary once the ICR_cs message has flowed.
すべての実装が、ICR_Csメッセージが流れる時を含めてTransport IDを変えるDLSw同輩を考慮して、いつもメッセージが送ったどんなSSPにもパートナーから受け取られた最新のTIDを反映しなければなりません。 ICR_Csメッセージがいったん流れると、TIDは異なることができません。
3.4 LF bits
3.4 LFビット
LF-bits should be propagated from LAN to SSP to LAN (and back) as per a bridge (i.e. they can only be revised downwards at each step if required).
LF-ビットはブリッジに従って(行き帰り)LANからSSPまでLANに伝播されるべきです(必要なら、各ステップで下向きにすなわち、それらを改訂できるだけです)。
3.5 KEEPALIVE messages
3.5 KEEPALIVEメッセージ
The SSP KEEPALIVE message (x1D) uses the short ("infoframe") version
of the SSP header. All DLSw implementation must support receipt and
quiet ignore of this message, but there is not requirement to send
it. There is no response to a KEEPALIVE message.
SSP KEEPALIVEメッセージ(x1D)はSSPヘッダーの短い("infoframe")バージョンを使用します。 サポート領収書と静かが無視するこのメッセージのすべてのDLSw実装必須だけ、それを送るという要件がありません。 KEEPALIVEメッセージへの応答が全くありません。
3.5 MAC header for Netbios SSP frames
3.5 Netbios SSPフレームへのMACヘッダー
The MAC header is included in forwarded SSP Netbios frames in the
format described below:
- addresses are always in non-canonical format
- src/dest addresses are as per the LLC frame
- AC/FC bits may be reset and must be ignored
- SSAP, DSAP and command fields are included
- RII bit in src address is copied from the LLC frame
- the RIF length is not extended to include padding
- all RIFs are padded to 18 bytes so that the data is
in a consistent place.
MACヘッダーは進められたSSP Netbiosフレームに以下で説明された形式で含まれています: - いつも正典外の形式にはアドレスがあります--src/destアドレスがLLCフレームに従ってあります--西暦/FCビットをリセットされるかもしれなくて、無視しなければなりません--SSAP、DSAP、およびコマンド欄は含まれています--srcアドレスで噛み付かれたRIIはLLCフレームからコピーされます--RIFの長さはそっと歩くのを含むように広げられません--すべてのRIFsが18バイトに水増しされるので、データが一貫した場所にあります。
3.5.7 Unrecognized control vectors
3.5.7 認識されていないコントロールベクトル
All implementations should quietly ignore unrecognized control vectors in any SSP messages. In particular, unrecognized SSP frames or unrecognized fields in a CAPEX message should be quietly ignored without dropping the TCP connection.
すべての実装が静かにどんなSSPメッセージの認識されていないコントロールベクトルも無視するべきです。 TCP接続を下げないで、特に、CAPEXメッセージの認識されていないSSPフレームか認識されていない分野が静かに無視されるべきです。
Bryant & Brittain Informational [Page 32] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[32ページ]のRFC2166APPN Implementerのワークショップ1997年6月
5.4 Use of CUR-cs/CUR-ex
5.4 野良犬野良犬Cs/元の連れ合いの使用
The SSAP and DSAP numbers in CUR_ex messages should reflect those actually used in the TEST (or equivalent) frame that caused the CUR_ex message to flow. This would mean that the SAP numbers in a 'typical' CUR_ex frame for SNA traffic switched from a LAN will be a source SAP of x04 and a destination SAP of x00.
CURの_の元のメッセージのSSAPとDSAP番号は実際に流れるCURの_の元のメッセージを引き起こしたTEST(または、同等物)フレームで使用されるものを反映するべきです。 これは、'典型的な'CUR_元のフレームのSNAトラフィックのSAP番号がx04のソースSAPと目的地がx00のSAPであるつもりであったならLANから切り替わったことを意味するでしょう。
The CUR_cs frame should only be sent when the DSAP is known. Specifically, CUR_ex should be used when a NULL XID is received that is targeted at DSAP zero, and CUR_cs when a XID specifying the (non- zero) DSAP is received.
DSAPを知っているときだけ、CUR_Csフレームを送るべきです。 明確に、CUR_元の連れ合いはNULL XIDが受け取られているとき、使用されて、それがDSAPゼロをターゲットにするということであるべきです、そして、(非ゼロ)DSAPを指定するXIDであるときに、CUR_Csは受け取られています。
Note that this does not mean that an implementation can assume that the DSAP on a CUR_ex will always be zero. The ICR_ex must always reflect the SSAP and DSAP values sent on the CUR_ex. This is still true even if an implementation always sends a TEST with DSAP = x00 on its local LAN(s) in response to a CUR_ex to any SAP.
これが、実装が、CUR_元の連れ合いの上のDSAPがいつもゼロになると仮定できることを意味しないことに注意してください。 ICR_元の連れ合いがいつもSSAPを反映しなければならなくて、DSAP値がCUR_を転送した、例えば。 実装がいつも地方のLANのDSAP=x00でどんなSAPへのCUR_元の連れ合いに対応してTESTを送っても、これはまだ本当です。
An example of a situation where the CUR_ex may flow with a non-zero DSAP is when there is an APPN stack local to the DLSw node. The APPN stack may then issue a connection request specifying the DSAP as a non-zero value. This would then be passed on the CUR_ex message.
CUR_元の連れ合いが非ゼロDSAPであふれるかもしれない状況に関する例はDLSwノードへの地方のAPPNスタックがある時です。 そして、APPNスタックは非ゼロ値としてDSAPを指定する接続要求を発行するかもしれません。 そして、これはCURの_の元のメッセージで通過されるでしょう。
7.6.1 Vendor IDs
7.6.1 ベンダーID
The Vendor ID field in a CAPEX may be zero. However, a zero Vendor Context ID is not permitted, which implies that an implementation that uses a zero ID cannot send any vendor-specific CVs (other than those specified by other vendors that do have a non-zero ID)
CAPEXのVendor ID分野はゼロであるかもしれません。 しかしながら、aゼロVendor Context ID(aゼロIDを使用する実現が少しの業者特有のCVsも送ることができないのを含意する)は受入れられません。(非ゼロIDを持っている他の業者によって指定されたものを除いた)
7.6.3 Initial Pacing Window
7.6.3 初期のペースの窓
The initial pacing window may be 1. There is no requirement on an implementation to use any minimum value for the initial pacing window.
初期のペースの窓は1であるかもしれません。 初期のペースの窓にどんな最小値も使用するという実現に関する要件が全くありません。
7.6.7 TCP Tunnel bringup
7.6.7 TCP Tunnel bringup
The third paragraph should read:
第3パラグラフは読むべきです:
If TCP Connections CV values agree and the number of connections
is one, then the DLSw with the higher IP address must tear down
the TCP connections on its local port 2065. This connection is
torn down after a CAPEX response has been both sent and received.
After this point, the remaining TCP connection is used to exchange
data in both directions.
TCPコネクションズCV値が同意して、ポートの数が1であるなら、より高いIPアドレスがあるDLSwは地方のポート2065の上でTCP接続を取りこわさなければなりません。 CAPEX応答を送って、受けた後にこの接続を取りこわします。 このポイント後に、残っているTCP接続は、両方の指示のデータを交換するのに使用されます。
Bryant & Brittain Informational [Page 33] RFC 2166 APPN Implementer's Workshop June 1997
ブライアントとBrittainの情報[33ページ]のRFC2166APPN Implementerのワークショップ1997年6月
7.7 CAPEX negative responses
7.7 CAPEX否定応答
If a DLSw does not support any of the options specified on a CAPEX received from a partner, or if it thinks the CAPEX is malformed, it must send a CAPEX negative response to the partner. The receiver of a CAPEX negative response is then responsible for dropping the connection. It is not permitted to drop the link instead of sending a CAPEX negative response.
DLSwがパートナーから受け取られたCAPEXで指定されたオプションのいずれも支持しないか、またはCAPEXが奇形であると考えるなら、それはCAPEX否定応答をパートナーに送らなければなりません。 CAPEX否定応答の受信機はその時、接続を落とすのに原因となります。 それがCAPEX否定応答を送ることの代わりにリンクを落とすことが許可されていません。
8.2 Flow Control ACKs
8.2 フロー制御ACKs
The first flow-control ack (FCACK) does not have to be returned on the REACH_ACK even if the ICR_cs carried the FCIND bit. However it should be returned on the first SSP frame flowing for that circuit after the REACH_ACK.
ICR_CsがFCINDビットを運んだとしても、REACH_ACKで最初のフロー制御ack(FCACK)を返す必要はありません。 しかしながら、REACH_ACKの後のそのサーキットに流れながら、最初のSSPフレームの上にそれを返すべきです。
Bryant & Brittain Informational [Page 34]
ブライアントとBrittain情報です。[34ページ]
一覧
スポンサーリンク
