RFC2353 日本語訳
2353 APPN/HPR in IP Networks APPN Implementers' Workshop Closed PagesDocument. G. Dudley. May 1998. (Format: TXT=116972 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Dudley Request for Comments: 2353 IBM Category: Informational May 1998
コメントを求めるワーキンググループG.ダドリー要求をネットワークでつないでください: 2353年のIBMカテゴリ: 情報の1998年5月
APPN/HPR in IP Networks
APPN Implementers' Workshop Closed Pages Document
IPネットワークAPPN Implementersのワークショップの閉じているページドキュメントのAPPN/HPR
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Table of Contents
目次
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
2.0 IP as a Data Link Control (DLC) for HPR . . . . . . . . . 3
2.1 Use of UDP and IP . . . . . . . . . . . . . . . . . . . . 4
2.2 Node Structure . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Logical Link Control (LLC) Used for IP . . . . . . . . . . 8
2.3.1 LDLC Liveness . . . . . . . . . . . . . . . . . . . . 8
2.3.1.1 Option to Reduce Liveness Traffic . . . . . . . . 9
2.4 IP Port Activation . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Maximum BTU Sizes for HPR/IP . . . . . . . . . . . . . 12
2.5 IP Transmission Groups (TGs) . . . . . . . . . . . . . . . 12
2.5.1 Regular TGs . . . . . . . . . . . . . . . . . . . . . 12
2.5.1.1 Limited Resources and Auto-Activation . . . . . . 19
2.5.2 IP Connection Networks . . . . . . . . . . . . . . . . 19
2.5.2.1 Establishing IP Connection Networks . . . . . . . 20
2.5.2.2 IP Connection Network Parameters . . . . . . . . . 22
2.5.2.3 Sharing of TGs . . . . . . . . . . . . . . . . . . 24
2.5.2.4 Minimizing RSCV Length . . . . . . . . . . . . . . 25
2.5.3 XID Changes . . . . . . . . . . . . . . . . . . . . . 26
2.5.4 Unsuccessful IP Link Activation . . . . . . . . . . . 30
2.6 IP Throughput Characteristics . . . . . . . . . . . . . . 34
2.6.1 IP Prioritization . . . . . . . . . . . . . . . . . . 34
2.6.2 APPN Transmission Priority and COS . . . . . . . . . . 36
2.6.3 Default TG Characteristics . . . . . . . . . . . . . . 36
2.6.4 SNA-Defined COS Tables . . . . . . . . . . . . . . . . 38
2.6.5 Route Setup over HPR/IP links . . . . . . . . . . . . 39
2.6.6 Access Link Queueing . . . . . . . . . . . . . . . . . 39
2.7 Port Link Activation Limits . . . . . . . . . . . . . . . 40
UDPのHPR. . . . . . . . . 3 2.1使用のためのデータリンク制御(DLC)としての1.0序論. . . . . . . . . . . . . . . . . . . . . . . 2 1.1要件.32.0IPとIP. . . . . . . . . . . . . . . . . . . . 4 2.2ノード構造. . . . . . . . . . . . . . . . . . . . . . 5 2.3論理的なリンク制御(LLC)はIP. . . . . . . . . . 8 2.3.1LDLCに活性トラフィック. . . . . . . . 9 2を減少させる活性.82.3.1.1オプションを使用しました; 起動. . . . . . . . . . . . . . . . . . . . 10 2.4.1最大のBTUがHPR/IP. . . . . . . . . . . . . 12 2.5IPトランスミッションのために大きさで分ける4IPポートは(TGs). . . . . . . . . . . . . . . 12 2.5.1通常のTGs. . . . . . . . . . . . . . . . . . . . . 12 2.5.1.1の限りある資源と自動活性化. . . . . . 19 2.5.2のIP接続ネットワーク. . . . . . . . . . . . . . . . 19 2.5.2.1設立IP接続ネットワーク. . . . . . . 20 2.5.2.2のIP接続回路パラメータ. . . . . . . . . 22 2.5.2を分類します。.3 TGs. . . . . . . . . . . . . . . . . . 24 2.5.2.4最小にするRSCV長さ. . . . . . . . . . . . . . 25 2.5の.3XIDの共有は.262.5.4の失敗のIPリンク起動. . . . . . . . . . . 30 2.6IPスループットの特性. . . . . . . . . . . . . . 34 2.6の.1IP優先順位づけ. . . . . . . . . . . . . . . . . . 34 2.6を変えます; 2 HPR/IPの上のAPPN Transmission PriorityとCOS. . . . . . . . . . 36 2.6.3Default TG Characteristics. . . . . . . . . . . . . . 36 2.6.4SNAで定義されたCOS Tables. . . . . . . . . . . . . . . . 38 2.6.5Route Setupは.392.6.6Access Link Queueing. . . . . . . . . . . . . . . . . 39 2.7Port Link Activation Limits. . . . . . . . . . . . . . . 40をリンクします。
Dudley Informational [Page 1] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[1ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
2.8 Network Management . . . . . . . . . . . . . . . . . . . . 40
2.9 IPv4-to-IPv6 Migration . . . . . . . . . . . . . . . . . . 41
3.0 References . . . . . . . . . . . . . . . . . . . . . . . . 42
4.0 Security Considerations . . . . . . . . . . . . . . . . . 43
5.0 Author's Address . . . . . . . . . . . . . . . . . . . . . 44
6.0 Appendix - Packet Format . . . . . . . . . . . . . . . . . 45
6.1 HPR Use of IP Formats . . . . . . . . . . . . . . . . . . 45
6.1.1 IP Format for LLC Commands and Responses . . . . . . . 45
6.1.2 IP Format for NLPs in UI Frames . . . . . . . . . . . 46
7.0 Full Copyright Statement . . . . . . . . . . . . . . . . . 48
2.8 ネットワークマネージメント. . . . . . . . . . . . . . . . . . . . 40 2.9IPv4からIPv6への移行. . . . . . . . . . . . . . . . . . 41 3.0参照. . . . . . . . . . . . . . . . . . . . . . . . 42 4.0セキュリティ問題. . . . . . . . . . . . . . . . . 43 5.0作者のアドレス…; 44 6.0付録--LLCコマンドのためのIP形式. . . . . . . . . . . . . . . . . . 45 6.1.1IP形式とUIフレーム. . . . . . . . . . . 46 7.0の完全な著作権宣言文. . . . . . . . . . . . . . . . . 48のNLPsのための応答. . . . . . . 45 6.1.2IP形式のパケット・フォーマット. . . . . . . . . . . . . . . . . 45 6.1HPR使用
1.0 Introduction
1.0 序論
The APPN Implementers' Workshop (AIW) is an industry-wide consortium of networking vendors that develops Advanced Peer-to-Peer Networking(R) (APPN(R)) standards and other standards related to Systems Network Architecture (SNA), and facilitates high quality, fully interoperable APPN and SNA internetworking products. The AIW approved Closed Pages (CP) status for the architecture in this document on December 2, 1997, and, as a result, the architecture was added to the AIW architecture of record. A CP-level document is sufficiently detailed that implementing products will be able to interoperate; it contains a clear and complete specification of all necessary changes to the architecture of record. However, the AIW has procedures by which the architecture may be modified, and the AIW is open to suggestions from the internet community.
APPN ImplementersのWorkshop(AIW)はじっと見るAdvanced Peer Networking(R)を開発するネットワークベンダーの産業全体の共同体です。(APPN(R))規格と他の規格は、システム・ネットワーク・アーキテクチャ(SNA)に関連して、高品質の、そして、完全に共同利用できるAPPNとSNAインターネットワーキング製品を容易にします。 AIWは本書では1997年12月2日にアーキテクチャのためにClosedページ(CP)状態を承認しました、そして、その結果、アーキテクチャは記録のAIWアーキテクチャに追加されました。 製品を実装して、共同利用できるCP-レベルドキュメントについて十分詳述します。 それは記録のアーキテクチャへのすべての必要な改革の明確で完全な仕様を含んでいます。 しかしながら、AIWには、アーキテクチャが変更されるかもしれない手順があります、そして、AIWはインターネット共同体からのあらゆる提案に耳を傾けます。
The architecture for APPN nodes is specified in "Systems Network Architecture Advanced Peer-to-Peer Networking Architecture Reference" [1]. A set of APPN enhancements for High Performance Routing (HPR) is specified in "Systems Network Architecture Advanced Peer-to-Peer Networking High Performance Routing Architecture Reference, Version 3.0" [2]. The formats associated with these architectures are specified in "Systems Network Architecture Formats" [3]. This memo assumes the reader is familiar with these specifications.
APPNノードのためのアーキテクチャは「システム・ネットワーク体系の高度なピアツーピアネットワークアーキテクチャ参照」[1]で指定されます。 Highパフォーマンスルート設定(HPR)のための1セットのAPPN増進は「システム・ネットワーク・アーキテクチャがピアツーピアネットワーク高性能ルート設定アーキテクチャ参照を進めました、バージョン3インチ[2]」で指定されます。 これらのアーキテクチャに関連している形式は「システム・ネットワーク体系形式」[3]で指定されます。 このメモは、読者がこれらの仕様に詳しいと仮定します。
This memo defines a method with which HPR nodes can use IP networks for communication, and the enhancements to APPN required by this method. This memo also describes an option set that allows the use of the APPN connection network model to allow HPR nodes to use IP networks for communication without having to predefine link connections.
このメモはHPRノードがコミュニケーションにIPネットワークを使用できるメソッドを定義します、そして、APPNへの増進がこのメソッドが必要です。 また、このメモはHPRノードがコミュニケーションにAPPN接続ネットワークモデルの使用でリンク結合を事前に定義する必要はなくてIPネットワークを使用できるオプションセットについて説明します。
(R) 'Advanced Peer-to-Peer Networking' and 'APPN' are trademarks of the IBM Corporation.
(R) 'Peerから同輩への高度なNetworking'と'APPN'はIBM社の商標です。
Dudley Informational [Page 2] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[2ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
1.1 Requirements
1.1 要件
The following are the requirements for the architecture specified in this memo:
↓これはこのメモで指定されたアーキテクチャのための要件です:
1. Facilitate APPN product interoperation in IP networks by
documenting agreements such as the choice of the logical link
control (LLC).
1. IPネットワークで論理的なリンク制御(LLC)の選択などの協定を記録することによって、APPN製品interoperationを容易にしてください。
2. Reduce system definition (e.g., by extending the connection
network model to IP networks) -- Connection network support is an
optional function.
2. システム定義(例えば、接続ネットワークモデルをIPネットワークに広げるのによる)を抑えてください--接続ネットワークサポートは任意の機能です。
3. Use class of service (COS) to retain existing path selection and
transmission priority services in IP networks; extend
transmission priority function to include IP networks.
3. サービス(COS)のクラスを使用して、IPネットワークで既存の経路選択とトランスミッション優先サービスを保有してください。 トランスミッション優先権機能を広げて、IPネットワークを含んでください。
4. Allow customers the flexibility to design their networks for low
cost and high performance.
4. 顧客に柔軟性を許容して、低価格と高性能のために彼らのネットワークを設計してください。
5. Use HPR functions to improve both availability and scalability
over existing integration techniques such as Data Link Switching
(DLSw) which is specified in RFC 1795 [4] and RFC 2166 [5].
5. HPR機能を使用して、RFC1795[4]とRFC2166[5]で指定されるData Link Switching(DLSw)などの既存の統合のテクニックの上で有用性とスケーラビリティの両方を改良してください。
2.0 IP as a Data Link Control (DLC) for HPR
2.0 HPRのためのデータリンク制御(DLC)としてのIP
This memo specifies the use of IP and UDP as a new DLC that can be supported by APPN nodes with the three HPR option sets: HPR (option set 1400), Rapid Transport Protocol (RTP) (option set 1401), and Control Flows over RTP (option set 1402). Logical Data Link Control (LDLC) Support (option set 2006) is also a prerequisite.
このメモは3つのHPRオプションセットと共にAPPNノードでサポートすることができる新しいDLCとしてIPとUDPの使用を指定します: HPR(オプションは1400を設定した)、Rapid Transportプロトコル(RTP)(オプションは1401を設定した)、およびRTPの上のControl Flows(オプションは1402を設定しました)。 また、論理的なData Link Control(LDLC)サポート(オプションは2006を設定した)は前提条件です。
RTP is a connection-oriented, full-duplex protocol designed to transport data in high-speed networks. HPR uses RTP connections to transport SNA session traffic. RTP provides reliability (i.e., error recovery via selective retransmission), in-order delivery (i.e., a first-in-first-out [FIFO] service provided by resequencing data that arrives out of order), and adaptive rate-based (ARB) flow/congestion control. Because RTP provides these functions on an end-to-end basis, it eliminates the need for these functions on the link level along the path of the connection. The result is improved overall performance for HPR. For a more complete description of RTP, see Appendix F of [2].
RTPは高速ネットワークでデータを輸送するように設計された接続指向の全二重プロトコルです。 HPRは、SNAセッショントラフィックを輸送するのにRTP接続を使用します。 RTPは信頼性(すなわち、選択している「再-トランスミッション」を通したエラー回復)、オーダーにおける配送(すなわち、故障していた状態で到着するデータを再配列することによって提供されたファーストインファーストアウト[先入れ先出し法]サービス)、および適応型のレートベースの(ARB)流れ/輻輳制御を提供します。 RTPが終わりから終わりへのベースでこれらの機能を提供するので、それは接続の経路に沿ったリンク・レベルでのこれらの機能の必要性を排除します。 結果はHPRのための向上した総合的な性能です。 RTPの、より完全な記述に関しては、[2]のAppendix Fを見てください。
This new DLC (referred to as the native IP DLC) allows customers to take advantage of APPN/HPR functions such as class of service (COS) and ARB flow/congestion control in the IP environment. HPR links established over the native IP DLC are referred to as HPR/IP links.
この新しいDLC(ネイティブのIP DLCと呼ばれる)は顧客にサービス(COS)のクラスなどのAPPN/HPR関数とIP環境におけるARB流れ/輻輳制御を利用させます。 ネイティブのIP DLCの上に設立されたHPRリンクはHPR/IPリンクと呼ばれます。
Dudley Informational [Page 3] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[3ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
The following sections describe in detail the considerations and enhancements associated with the native IP DLC.
以下のセクションは詳細にネイティブのIP DLCに関連している問題と増進について説明します。
2.1 Use of UDP and IP
2.1 UDPとIPの使用
The native IP DLC will use the User Datagram Protocol (UDP) defined in RFC 768 [6] and the Internet Protocol (IP) version 4 defined in RFC 791 [7].
ネイティブのIP DLCはRFC768[6]で定義されたユーザー・データグラム・プロトコル(UDP)とRFC791[7]で定義されたインターネットプロトコル(IP)バージョン4を使用するでしょう。
Typically, access to UDP is provided by a sockets API. UDP provides an unreliable connectionless delivery service using IP to transport messages between nodes. UDP has the ability to distinguish among multiple destinations within a given node, and allows port-number- based prioritization in the IP network. UDP provides detection of corrupted packets, a function required by HPR. Higher-layer protocols such as HPR are responsible for handling problems of message loss, duplication, delay, out-of-order delivery, and loss of connectivity. UDP is adequate because HPR uses RTP to provide end- to-end error recovery and in-order delivery; in addition, LDLC detects loss of connectivity. The Transmission Control Protocol (TCP) was not chosen for the native IP DLC because the additional services provided by TCP such as error recovery are not needed. Furthermore, the termination of TCP connections would require additional node resources (control blocks, buffers, timers, and retransmit queues) and would, thereby, reduce the scalability of the design.
通常、ソケットAPIはUDPへのアクセスを提供します。 UDPは、ノードの間のメッセージを輸送するのにIPを使用することで頼り無いコネクションレスなデリバリ・サービスを提供します。 UDPは与えられたノードの中に複数の目的地の中で区別する能力を持って、IPネットワークでポート番号によるベースの優先順位づけを許容します。 機能は、HPRでUDPが崩壊したパケットの検出を提供するのを必要としました。 HPRなどの上位層プロトコルは接続性のメッセージの損失の取り扱い問題、複製、遅れ、不適切な配送、および損失に原因となります。 HPRが終わりまでの終わりのエラー回復とオーダーにおける配送を提供するのにRTPを使用するので、UDPは適切です。 さらに、LDLCは接続性の損失を検出します。 エラー回復などのTCPによって提供された追加サービスは必要でないので、通信制御プロトコル(TCP)はネイティブのIP DLCに選ばれませんでした。 その上、TCP接続の終了は、追加ノードリソース(制御ブロック、バッファ、タイマ、および再送キュー)を必要として、その結果、デザインのスケーラビリティを減少させるでしょう。
The UDP header has four two-byte fields. The UDP Destination Port is a 16-bit field that contains the UDP protocol port number used to demultiplex datagrams at the destination. The UDP Source Port is a 16-bit field that contains the UDP protocol port number that specifies the port to which replies should be sent when other information is not available. A zero setting indicates that no source port number information is being provided. When used with the native IP DLC, this field is not used to convey a port number for replies; moreover, the zero setting is not used. IANA has registered port numbers 12000 through 12004 for use in these two fields by the native IP DLC; use of these port numbers allows prioritization in the IP network. For more details of the use of these fields, see 2.6.1, "IP Prioritization" on page 28.
UDPヘッダーには、4つの2バイトの分野があります。 UDP Destination Portは目的地に「反-マルチプレックス」データグラムに使用されるUDPプロトコルポートナンバーを保管している16ビットの分野です。 UDP Source Portは他の情報が利用可能でないときに回答が送られるべきであるポートを指定するUDPプロトコルポートナンバーを含む16ビットの分野です。 ソースポート数の情報が全く提供されていない設定が示すゼロ。 ネイティブのIP DLCと共に使用される場合、この分野は回答のためにポートナンバーを伝えるのに使用されません。 そのうえ、セットは使用されていません。 IANAはこれらの2つの分野での使用のためにネイティブのIP DLCで12000〜12004にポートナンバーを示しました。 これらのポートナンバーの使用はIPネットワークで優先順位づけを許容します。 これらの分野の使用のその他の詳細に関しては、見てください、2.6、.1、28ページの「IP優先順位づけ」
The UDP Checksum is a 16-bit optional field that provides coverage of the UDP header and the user data; it also provides coverage of a pseudo-header that contains the source and destination IP addresses. The UDP checksum is used to guarantee that the data has arrived intact at the intended receiver. When the UDP checksum is set to
UDP ChecksumはUDPヘッダーと利用者データの適用範囲を提供する16ビットの任意の分野です。 また、それはIPが演説するソースと目的地を含む疑似ヘッダーの適用範囲を提供します。 UDPチェックサムは、データが所定の受信者で完全な状態で到着したのを保証するのに使用されます。いつ、UDPチェックサムがあるかはセットしました。
Dudley Informational [Page 4] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[4ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
zero, it indicates that the checksum was not calculated and should not be checked by the receiver. Use of the checksum is recommended for use with the native IP DLC.
ゼロ、それはチェックサムが計算されないで、受信機によってチェックされるべきでないのを示します。チェックサムの使用はネイティブのIP DLCとの使用のために推薦されます。
IP provides an unreliable, connectionless delivery mechanism. The IP protocol defines the basic unit of data transfer through the IP network, and performs the routing function (i.e., choosing the path over which data will be sent). In addition, IP characterizes how "hosts" and "gateways" should process packets, the circumstances under which error messages are generated, and the conditions under which packets are discarded. An IP version 4 header contains an 8- bit Type of Service field that specifies how the datagram should be handled. As defined in RFC 1349 [8], the type-of-service byte contains two defined fields. The 3-bit precedence field allows senders to indicate the priority of each datagram. The 4-bit type of service field indicates how the network should make tradeoffs between throughput, delay, reliability, and cost. The 8-bit Protocol field specifies which higher-level protocol created the datagram. When used with the native IP DLC, this field is set to 17 which indicates the higher-layer protocol is UDP.
IPは頼り無くて、コネクションレスな排紙機構を提供します。 IPプロトコルは、IPネットワークを通してデータ転送の原単位を定義して、経路選択機能を実行します(すなわち、どのデータに関して経路を選ぶかを送るでしょう)。 さらに、IPは「ホスト」と「ゲートウェイ」がどうパケットを処理するべきであるか、そして、エラーメッセージが発生している事情、およびパケットが捨てられる状態を特徴付けます。 IPバージョン4ヘッダーはデータグラムがどう扱われるべきであるかを指定するService分野のTypeを8ビット含んでいます。 RFC1349[8]で定義されるように、サービスのタイプバイトは2つの定義された分野を含んでいます。 3ビットの先行分野で、送付者はそれぞれのデータグラムの優先権を示すことができます。 4ビットのタイプのサービス分野はネットワークがスループットと、遅れと、信頼性と、費用の間でどう見返りを作るべきであるかを示します。 8ビットのプロトコル分野は、どの上位レベル・プロトコルがデータグラムを作成したかを指定します。 ネイティブのIP DLCと共に使用されると、この分野は17への上位層プロトコルがUDPであることを示すセットです。
2.2 Node Structure
2.2 ノード構造
Figure 1 on page 6 shows a possible node functional decomposition for transport of HPR traffic across an IP network. There will be variations in different platforms based on platform characteristics.
6ページの図1はIPネットワークの向こう側にHPRトラフィックの輸送のための可能なノード機能的な分解を示しています。 変化がプラットホームの特性に基づく異なったプラットホームにあるでしょう。
The native IP DLC includes a DLC manager, one LDLC component for each link, and a link demultiplexor. Because UDP is a connectionless delivery service, there is no need for HPR to activate and deactivate lower-level connections.
ネイティブのIP DLCはDLCマネージャ、各リンクあたり1つのLDLCの部品、およびリンク「反-マルチプレクサー」を含んでいます。 UDPがコネクションレスなデリバリ・サービスであるので、HPRが低レベル接続を動かして、非活性化する必要は全くありません。
The DLC manager activates and deactivates a link demultiplexor for each port and an instance of LDLC for each link established in an IP network. Multiple links (e.g., one defined link and one dynamic link for connection network traffic) may be established between a pair of IP addresses. Each link is identified by the source and destination IP addresses in the IP header and the source and destination service access point (SAP) addresses in the IEEE 802.2 LLC header (see 6.0, "Appendix - Packet Format" on page 37); the link demultiplexor passes incoming packets to the correct instance of LDLC based on these identifiers. Moreover, the IP address pair associated with an active link and used in the IP header may not change.
DLCマネージャは、各ポートとLDLCのインスタンスのためにIPネットワークに設立された各リンクに、リンク「反-マルチプレクサー」を動かして、非活性化します。 複数のリンク(例えば、1つはリンクと1個のダイナミックなリンクを接続ネットワークトラフィックと定義した)が1組のIPアドレスの間に設立されるかもしれません。 各リンクはIPがIEEE802.2LLCヘッダーでIPヘッダー、ソース、および目的地サービスアクセスポイント(SAP)アドレスで演説するソースと目的地によって特定されます(37ページで6.0、「付録--パケット・フォーマット」を見てください)。 リンク「反-マルチプレクサー」はこれらの識別子に基づくLDLCの正しいインスタンスに入って来るパケットを通過します。 そのうえ、アクティブなリンクに関連づけられて、IPヘッダーで使用されるIPアドレス組は変化しないかもしれません。
LDLC also provides other functions (for example, reliable delivery of Exchange Identification [XID] commands). Error recovery for HPR RTP packets is provided by the protocols between the RTP endpoints.
また、LDLCは他の機能を提供します(例えば、Exchange Identification[XID]の信頼できる配信は命令します)。 RTP終点の間のプロトコルはHPR RTPパケットのためのエラー回復を提供します。
Dudley Informational [Page 5] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[5ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
The network control layer (NCL) uses the automatic network routing (ANR) information in the HPR network header to either pass incoming packets to RTP or an outgoing link.
ネットワーク制御(NCL)層は、RTPか出発しているリンクに入って来るパケットを通過するのにHPRネットワークヘッダーで自動ネットワークルーティング(ANR)情報を使用します。
All components are shown as single entities, but the number of logical instances of each is as follows:
すべてのコンポーネントが単一体として示されますが、それぞれの論理的なインスタンスの数は以下の通りです:
o DLC manager -- 1 per node
o DLCマネージャ--1ノードあたり1
o LDLC -- 1 per link
o LDLC--1リンクあたり1
o Link demultiplexor -- 1 per port
o リンク「反-マルチプレクサー」--1ポートあたり1
o NCL -- 1 per node (or 1 per port for efficiency)
o NCL--1ノードあたり1(または、効率のためのポートあたり1)
o RTP -- 1 per RTP connection
o RTP--RTP接続あたり1
o UDP -- 1 per port
o UDP--1ポートあたり1
o IP -- 1 per port
o IP--1ポートあたり1
Products are free to implement other structures. Products implementing other structures will need to make the appropriate modifications to the algorithms and protocol boundaries shown in this document.
製品は無料で非重要構造を実装することができます。 非重要構造を実装する製品は、アルゴリズムとプロトコル限界への適切な変更を本書では示させる必要があるでしょう。
Dudley Informational [Page 6] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[6ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
--------------------------------------------------------------------
--------------------------------------------------------------------
-*
*-------------* *-------* |
|Configuration| | Path | |
| Services | |Control| |
*-------------* *-------* |
A A A |
| | | |
| | V |
| | *-----* | APPN/HPR
| | | RTP | |
| | *-----* |
| | A |
| | | |
| | V |
| | *-----* |
| | | NCL | |
| | *-----* |
| *------------* A -*
| | |
V V V -*
*---------* *---------* |
| DLC |--->| LDLC | |
| manager | | | |
*---------* *---------* |
| A | | IP DLC
*-----------* | *----* |
V | | |
*---------* | |
| LINK | | |
| DEMUX | | |
*---------* | |
A *-* -*
| |
| V
*---------*
| UDP |
*---------*
A
|
V
*---------*
| IP |
*---------*
-* *-------------* *-------* | |構成| | 経路| | | サービス| |コントロール| | *-------------* *-------* | A A| | | | | | | V| | | *-----* | APPN/HPR| | | RTP| | | | *-----* | | | A| | | | | | | V| | | *-----* | | | | NCL| | | | *-----* | | *------------* -*| | | V V V-**---------* *---------* | | DLC|、-、--、>| LDLC| | | マネージャ| | | | *---------* *---------* | | A| | IP DLC*-----------* | *----* | V| | | *---------* | | | リンク| | | | DEMUX| | | *---------* | | **-*| | | V*---------* | UDP| *---------* A| V*---------* | IP| *---------*
--------------------------------------------------------------------
Figure 1. HPR/IP Node Structure
-------------------------------------------------------------------- 図1。 HPR/IPノード構造
Dudley Informational [Page 7] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[7ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
2.3 Logical Link Control (LLC) Used for IP
2.3 IPに使用される論理的なリンク制御(LLC)
Logical Data Link Control (LDLC) is used by the native IP DLC. LDLC is defined in [2]. LDLC uses a subset of the services defined by IEEE 802.2 LLC type 2 (LLC2). LDLC uses only the TEST, XID, DISC, DM, and UI frames.
論理的なData Link Control(LDLC)はネイティブのIP DLCによって使用されます。 LDLCは[2]で定義されます。 LDLCはIEEE802.2LLCタイプ2(LLC2)によって定義されたサービスの部分集合を使用します。 LDLCはTEST、XID、DISC、DM、およびUIフレームだけを使用します。
LDLC was defined to be used in conjunction with HPR (with the HPR Control Flows over RTP option set 1402) over reliable links that do not require link-level error recovery. Most frame loss in IP networks (and the underlying frame networks) is due to congestion, not problems with the facilities. When LDLC is used on a link, no link-level error recovery is available; as a result, only RTP traffic is supported by the native IP DLC. Using LDLC eliminates the need for LLC2 and its associated cost (adapter storage, longer path length, etc.).
LDLCは、リンク・レベルエラー回復を必要としない信頼できるリンクの上にHPRに関連して使用される(RTPオプションの上のHPR Control Flowsと共に、1402を設定する)ために定義されました。 IPネットワーク(そして、基本的なフレームネットワーク)のほとんどのフレームの損失が施設に関する問題ではなく、混雑のためです。 LDLCがリンクの上に使用されるとき、どんなリンク・レベルエラー回復も利用可能ではありません。 その結果、RTPトラフィックだけがネイティブのIP DLCによってサポートされます。 LDLCを使用すると、LLC2の必要性とその関連費用(アダプターストレージ、より長い経路の長さなど)は排除されます。
2.3.1 LDLC Liveness
2.3.1 LDLC活性
LDLC liveness (using the LDLC TEST command and response) is required when the underlying subnetwork does not provide notification of connection outage. Because UDP is connectionless, it does not provide outage notification; as a result, LDLC liveness is required for HPR/IP links.
基本的なサブネットワークが接続供給停止の通知を提供しないとき、LDLC活性(LDLC TESTコマンドを使用して、応答)が必要です。 UDPがコネクションレスであるので、供給停止通知を提供しません。 その結果、LDLC活性がHPR/IPリンクに必要です。
Liveness should be sent periodically on active links except as described in the following subsection when the option to reduce liveness traffic is implemented. The default liveness timer period is 10 seconds. When the defaults for the liveness timer and retry timer (15 seconds) are used, the period between liveness tests is smaller than the time required to detect failure (retry count multiplied by retry timer period) and may be smaller than the time for liveness to complete successfully (on the order of round-trip delay). When liveness is implemented as specified in the LDLC finite-state machine (see [2]) this is not a problem because the liveness protocol works as follows: The liveness timer is for a single link. The timer is started when the link is first activated and each time a liveness test completes successfully. When the timer expires, a liveness test is performed. When the link is operational, the period between liveness tests is on the order of the liveness timer period plus the round-trip delay.
活性トラフィックを減少させるオプションが実装されるとき、以下の小区分で説明されるのを除いて、定期的にアクティブなリンクに活性を送るべきです。 デフォルト活性タイマの期間は10秒です。 活性タイマと再試行タイマ(15秒)のためのデフォルトが使用されているとき、活性テストの間の期間は、時間が失敗を検出するのが必要であるというよりも(再試行タイマの期間で掛けられたカウントを再試行してください)小さく、活性が首尾よさに(往復の遅れの注文に関して)完成するように、時間より小さいかもしれません。 活性がいつとして実装されるかはLDLC有限状態機械で指定しました。([2]) 活性プロトコルが以下の通り働いているのでこれが問題でないことを確実にしてください: 単一のリンクには活性タイマがあります。 リンクが動かされた1番目と活性テストが首尾よく完成する各回であるときに、タイマは始動されます。 タイマが期限が切れるとき、活性テストは実行されます。 リンクが操作上であるときに、活性タイマの期間と往復の遅れの注文には活性テストの間の期間があります。
For each implementation, it is necessary to check if the liveness protocol will work in a satisfactory manner with the default settings for the liveness and retry timers. If, for example, the liveness timer is restarted immediately upon expiration, then a different default for the liveness timer should be used.
各実装に、活性がないかどうか活性プロトコルが満足のできるように既定の設定に働くかどうかチェックして、タイマを再試行するのが必要です。 例えば、活性タイマがすぐ満了のときに再開されるなら、活性タイマのための異なったデフォルトは使用されるべきです。
Dudley Informational [Page 8] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[8ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
2.3.1.1 Option to Reduce Liveness Traffic
2.3.1.1 活性トラフィックを減少させるオプション
In some environments, it is advantageous to reduce the amount of liveness traffic when the link is otherwise idle. (For example, this could allow underlying facilities to be temporarily deactivated when not needed.) As an option, implementations may choose not to send liveness when the link is idle (i.e., when data was neither sent nor received over the link while the liveness timer was running). (If the implementation is not aware of whether data has been received, liveness testing may be stopped while data is not being sent.) However, the RTP connections also have a liveness mechanism which will generate traffic. Some implementations of RTP will allow setting a large value for the ALIVE timer, thus reducing the amount of RTP liveness traffic.
いくつかの環境で、そうでなければ、リンクが使用されていないときに、活性トラフィックの量を減少させるのは有利です。 (例えば、これで、必要でないと、基本的な施設は一時非活性化するかもしれません。) オプションとして、実装は、リンクが使用されていないときに(すなわち、活性タイマが動いていた間、データは、いつリンクの上に送られないで、また受け取られませんでしたか)、活性を送らないのを選ぶかもしれません。 (実装がデータが受け取られたかどうかを意識していないなら、データが送られない間、活性テストは止められるかもしれません。) しかしながら、RTP接続には、また、トラフィックを生成する活性メカニズムがあります。 RTPのいくつかの実装でALIVEタイマに大きい値を設定するでしょう、その結果、RTP活性トラフィックの量を減少させます。
If LDLC liveness is turned off while the link is idle, one side of the link may detect a link failure much earlier than the other. This can cause the following problems:
リンクが使用されていない間、LDLC活性がオフにされるなら、リンクの半面はもう片方よりはるかに早くリンクの故障を検出するかもしれません。 これは以下の問題を引き起こす場合があります:
o If a node that is aware of a link failure attempts to reactivate
the link, the partner node (unaware of the link failure) may
reject the activation as an unsupported parallel link between the
two ports.
o リンクの故障を意識しているノードが、リンクを現役に戻すのを試みるなら、パートナーノード(リンクの故障に気づかない)は2つのポートの間のサポートされない平行なリンクとして起動を拒絶するかもしれません。
o If a node that is unaware of an earlier link failure sends data
(including new session activations) on the link, it may be
discarded by a node that detected the earlier failure and
deactivated the link. As a result, session activations would
fail.
o それがノードであるなら失敗がリンクに関するデータ(新しいセッション起動を含んでいる)を送る以前のリンクに気づきません、それは以前の失敗を検出して、リンクを非活性化したノードによって捨てられるかもしれません。 その結果、セッション起動は失敗するでしょう。
The mechanisms described below can be used to remedy these problems. These mechanisms are needed only in a node not sending liveness when the link is idle; thus, they would not be required of a node not implementing this option that just happened to be adjacent to a node implementing the option.
これらの問題を改善するのに以下で説明されたメカニズムは使用できます。これらのメカニズムがリンクが使用されていないときに活性を送らないノードだけで必要です。 したがって、ただたまたまオプションを実装するノードに隣接していたこのオプションを実装しないノードはそれらに要求されないでしょう。
o (Mandatory unless the node supports multiple active defined links
between a pair of HPR/IP ports and supports multiple active
dynamic links between a pair of HPR/IP ports.) Anytime a node
rejects the activation of an HPR/IP link as an unsupported
parallel link between a pair of HPR/IP ports (sense data
X'10160045' or X'10160046'), it should perform liveness on any
active link between the two ports that is using a different SAP
pair. Thus, if the activation was not for a parallel link but
rather was a reactivation because one of these active links had
failed, the failed link will be detected. (If the SAP pair for
the link being activated matches the SAP pair for an active link,
a liveness test would succeed because the adjacent node would
o (義務的なノードが1組のHPR/IPポートの間の複数のアクティブな定義されたリンクを支えて、倍数は支えない場合アクティブな動力が1組のHPR/IPポートの間でリンクされるのを。) いつでも、ノードは1組のHPR/IPポート(センス・データX'10160045'かX'10160046')の間のサポートされない平行なリンクとしてHPR/IPリンクの起動を拒絶して、それは2つのポートの間の異なったSAP組を使用しているどんなアクティブなリンクにも活性を実行するべきです。 したがって、起動が平行なリンクにはありませんでしたが、これらのアクティブなリンクの1つが失敗したのでむしろ再起動であったなら、失敗したリンクは検出されるでしょう。 (隣接しているノードは成功するでしょう、したがって、動くリンクへのSAP組がアクティブなリンクへのSAP組に合っているなら、活性テストが成功するでしょう。
Dudley Informational [Page 9] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[9ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
respond for the link being activated.) A simple way to implement
this function is for LDLC, upon receiving an activation XID, to
run liveness on all active links with a matching IP address pair
and a different SAP pair.
動くリンクに応じてください。) この機能を実装する簡単な方法は起動を受けるときのLDLC、合っているIPアドレス組とのすべてのアクティブなリンクの上の走行活性へのXID、および異なったSAPが対にされるからです。
o (Mandatory) Anytime a node receives an activation XID with an IP
address pair and a SAP pair that match those of an active link,
it should deactivate the active link and allow it to be
reestablished. A timer is required to prevent stray XIDs from
deactivating an active link.
o (義務的)です。 いつでも、ノードがアクティブなリンクのものに合っているIPアドレス組とSAP組と共に起動XIDを受けて、それは、アクティブなリンクを非活性化して、復職するのを許容するべきです。 タイマが、迷っているXIDsがアクティブなリンクを非活性化するのを防ぐのに必要です。
o (Recommended) A node should attempt to reactivate an HPR/IP link
before acting on an LDLC-detected failure. This mechanism is
helpful in preventing session activation failures in scenarios
where the other side detected a link failure earlier, but the
network has recovered.
o (お勧め)です。 ノードは、LDLCによって検出された失敗に影響する前にHPR/IPリンクを現役に戻すのを試みるはずです。 このメカニズムは反対側が、より早くリンクの故障を検出しましたが、ネットワークが回復したシナリオでのセッション起動失敗を防ぐ際に役立っています。
2.4 IP Port Activation
2.4 IPポート起動
The node operator (NO) creates a native IP DLC by issuing DEFINE_DLC(RQ) (containing customer-configured parameters) and START_DLC(RQ) commands to the node operator facility (NOF). NOF, in turn, passes DEFINE_DLC(RQ) and START_DLC(RQ) signals to configuration services (CS), and CS creates the DLC manager. Then, the node operator can define a port by issuing DEFINE_PORT(RQ) (also containing customer-configured parameters) to NOF with NOF passing the associated signal to CS.
ノードオペレータ(いいえ)は、_DLC(RQ)(顧客によって構成されたパラメタを含んでいる)とSTART_DLC(RQ)コマンドをDEFINEに発行することによって、ノードオペレータ機能(NOF)にネイティブのIP DLCを作成します。 NOFは順番に、DEFINE_DLC(RQ)を渡します、そして、START_DLC(RQ)は構成サービス(CS)に合図します、そして、CSはDLCマネージャを創造します。 そして、ノードオペレータは、DEFINE_PORT(RQ)(また、顧客によって構成されたパラメタを含んでいる)をNOFが関連信号をCSに渡しているNOFに発行することによって、ポートを定義できます。
A node with adapters attached to multiple IP subnetworks may represent the multiple adapters as a single HPR/IP port. However, in that case, the node associates a single IP address with that port. RFC 1122 [9] requires that a node with multiple adapters be able to use the same source IP address on outgoing UDP packets regardless of the adapter used for transmission.
アダプターが複数のIPサブネットワークに取り付けられているノードは単一のHPR/IPポートとして複数のアダプターを表すかもしれません。 しかしながら、その場合、ノードはただ一つのIPアドレスをそのポートに関連づけます。 RFC1122[9]は、複数のアダプターがあるノードがトランスミッションに使用されるアダプターにかかわらず出発しているUDPパケットに関する同じソースIPアドレスを使用できるのを必要とします。
Dudley Informational [Page 10] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[10ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
*----------------------------------------------*
| NOF CS DLC |
*----------------------------------------------*
. DEFINE_DLC(RQ) .
1 o----------------->o
. DEFINE_DLC(RSP) |
2 o<-----------------*
. START_DLC(RQ) . create
3 o----------------->o------------------->o
. START_DLC(RSP) | .
4 o<-----------------* .
. DEFINE_PORT(RQ) . .
5 o----------------->o .
. DEFINE_PORT(RSP) | .
6 o<-----------------* .
*----------------------------------------------* | NOF Cs DLC| *----------------------------------------------* . DEFINE_DLC(RQ). 1o----------------->o . _DLC(RSP)を定義してください。| 2 o<。-----------------* . START_DLC(RQ)3○を作成してください。----------------->o------------------->o . _DLC(RSP)を始動してください。| . 4 o<。-----------------* . . DEFINE_PORT(RQ). . 5o----------------->o . . _ポート(RSP)を定義してください。| . 6 o<。-----------------* .
Figure 2. IP Port Activation
図2。 IPポート起動
The following parameters are received in DEFINE_PORT(RQ):
DEFINE_PORT(RQ)に以下のパラメタを受け取ります:
o Port name
o ポート名
o DLC name
o DLC名
o Port type (if IP connection networks are supported, set to shared
access transport facility [SATF]; otherwise, set to switched)
o ポートタイプ(IP接続ネットワークがサポートされるなら、共用アクセス輸送施設[SATF]にセットしてください; そうでなければ、切り換えられることへのセット)
o Link station role (set to negotiable)
o リンクステーションの役割(交渉可能へのセット)
o Maximum receive BTU size (default is 1461 [1492 less an allowance
for the IP, UDP, and LLC headers])
o 最大はBTUサイズを受けます。(デフォルトは1461[IP、UDP、およびLLCヘッダーのためのそれほど1小遣いあたり1492]です)
o Maximum send BTU size (default is 1461 [1492 less an allowance
for the IP, UDP, and LLC headers])
o 最大はBTUサイズを送ります。(デフォルトは1461[IP、UDP、およびLLCヘッダーのためのそれほど1小遣いあたり1492]です)
o Link activation limits (total, inbound, and outbound)
o リンク起動限界(総、本国行き、および外国行き)です。
o IPv4 supported (set to yes)
o サポートされたIPv4(はいへのセット)
o The local IPv4 address (required if IPv4 is supported)
o ローカルのIPv4アドレス(IPv4がサポートされるなら、必要です)
o IPv6 supported (set to no; may be set to yes in the future; see
2.9, "IPv4-to-IPv6 Migration" on page 35)
o サポートされたIPv6(いいえ; 将来、はいに設定されるかもしれません; 2.9を見る35ページの「IPv4からIPv6への移行」へのセット)
o The local IPv6 address (required if IPv6 is supported)
o ローカルのIPv6アドレス(IPv6がサポートされるなら、必要です)
o Retry count for LDLC (default is 3)
o LDLCのためにカウントを再試行してください。(デフォルトは3です)
Dudley Informational [Page 11] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[11ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
o Retry timer period for LDLC (default is 15 seconds; a smaller
value such as 10 seconds can be used for a campus network)
o LDLCのためにタイマの期間を再試行してください。(デフォルトは15秒です; キャンパスネットワークに10秒などの、より小さい値を使用できます)
o LDLC liveness timer period (default is 10 seconds; see 2.3.1,
"LDLC Liveness" on page 7)
o LDLC活性タイマの期間(デフォルトは10秒です; 2.3に.1、7ページの「LDLC活性」を見てください)
o IP precedence (the setting of the 3-bit field within the Type of
Service byte of the IP header for the LLC commands such as XID
and for each of the APPN transmission priorities; the defaults
are given in 2.6.1, "IP Prioritization" on page 28.)
o IP先行(APPNトランスミッションプライオリティ; XIDなどとそれぞれのデフォルトのためのコマンドが与えられているLLCのためのIPヘッダーのServiceバイトのTypeの中の3ビットの分野の設定、2.6、.1、28ページの)「IP優先順位づけ」
2.4.1 Maximum BTU Sizes for HPR/IP
2.4.1 HPR/IPに、最大のBTUサイズ
When IP datagrams are larger than the underlying physical links support, IP performs fragmentation. When HPR/IP links are established, the default maximum basic transmission unit (BTU) sizes are 1461 bytes, which corresponds to the typical IP maximum transmission unit (MTU) size of 1492 bytes supported by routers on token-ring networks. 1461 is 1492 less 20 bytes for the IP header, 8 bytes for the UDP header, and 3 bytes for the IEEE 802.2 LLC header. The IP header is larger than 20 bytes when optional fields are included; smaller maximum BTU sizes should be configured if optional IP header fields are used in the IP network. For IPv6, the default is reduced to 1441 bytes to allow for the typical IPv6 header size of 40 bytes. Smaller maximum BTU sizes (but not less than 768) should be used to avoid fragmentation when necessary. Larger BTU sizes should be used to improve performance when the customer's IP network supports a sufficiently large IP MTU size. The maximum receive and send BTU sizes are passed to CS in DEFINE_PORT(RQ). These maximum BTU sizes can be overridden in DEFINE_CN_TG(RQ) or DEFINE_LS(RQ).
IPデータグラムがいつ基本的さより物理的に大きいかがサポートをリンクして、IPは断片化を実行します。 HPR/IPリンクが設立されるとき、デフォルト最大の基本伝送単位(BTU)サイズは、1492バイトのサイズがトークンリングネットワークのルータでサポートした1461バイトから典型的なIPマキシマム・トランスミッション・ユニット(MTU)です。(バイトは対応します)。 1461は、より少ない20バイトIPヘッダー、UDPヘッダーのための8バイト、およびIEEE802.2LLCヘッダーのための3バイトのための1492です。 任意の分野が含まれているとき、IPヘッダーは20バイトより大きいです。 任意のIPヘッダーフィールドがIPネットワークに使用されるなら、より小さい最大のBTUサイズは構成されるべきです。 IPv6に関しては、デフォルトは、40バイトの典型的なIPv6ヘッダーサイズを考慮するために1441バイトまで減少します。 より小さい最大のBTUサイズ(しかし、少なくとも768)は、必要であるときに、断片化を避けるのに使用されるべきです。 顧客のIPネットワークが十分大きいIP MTUサイズをサポートするとき、より大きいBTUサイズは、性能を向上させるのに使用されるべきです。 最大は、受信して、DEFINE_PORT(RQ)のCSをサイズが通過されるBTUに送ります。 最大のBTUがくつがえされたコネがDEFINE_CN_TG(RQ)かDEFINE_LSであったかもしれない(RQ)なら大きさで分けるこれら。
The Flags field in the IP header should be set to allow fragmentation. Some products will not be able to control the setting of the bit allowing fragmentation; in that case, fragmentation will most likely be allowed. Although fragmentation is slow and prevents prioritization based on UDP port numbers, it does allow connectivity across paths with small MTU sizes.
IPヘッダーのFlags分野が断片化を許すように設定されるべきです。 いくつかの製品は断片化を許すビットの設定を制御できないでしょう。 その場合、断片化はたぶん許されるでしょう。 断片化は、遅く、UDPポートナンバーに基づく優先順位づけを防ぎますが、それは経路の向こう側に小さいMTUサイズで接続性を許容します。
2.5 IP Transmission Groups (TGs)
2.5 IPトランスミッショングループ(TGs)
2.5.1 Regular TGs
2.5.1 通常のTGs
Regular HPR TGs may be established in IP networks using the native IP DLC architecture. Each of these TGs is composed of one or more HPR/IP links. Configuration services (CS) identifies the TG with the destination control point (CP) name and TG number; the destination CP
通常のHPR TGsは、固有のIP DLCアーキテクチャを使用することでIPネットワークに設立されるかもしれません。 それぞれのこれらのTGsは1個以上のHPR/IPリンクで構成されます。 構成サービス(CS)は目的地制御点(CP)名とTG番号とTGを同一視します。 目的地CP
Dudley Informational [Page 12] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[12ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
name may be configured or learned via XID, and the TG number, which may be configured, is negotiated via XID. For auto-activatable links, the destination CP name and TG number must be configured.
名前は、XIDを通して構成されるか、または学習されるかもしれません、そして、TG番号(構成されるかもしれない)はXIDを通して交渉されます。 自動活性化可能なリンクに関しては、目的地CP名とTG番号を構成しなければなりません。
When multiple links (dynamic or defined) are established between a pair of IP ports (each associated with a single IP address), an incoming packet can be mapped to its associated link using the IP address pair and the service access point (SAP) address pair. If a node receives an activation XID for a defined link with an IP address pair and a SAP pair that are the same as for an active defined link, that node can assume that the link has failed and that the partner node is reactivating the link. In such a case as an optimization, the node receiving the XID can take down the active link and allow the link to be reestablished in the IP network. Because UDP packets can arrive out of order, implementation of this optimization requires the use of a timer to prevent a stray XID from deactivating an active link.
複数のリンク(ダイナミックであるか定義された)が1組のIPポート(それぞれただ一つのIPアドレスに関連している)の間に設立されるとき、IPアドレス組とサービスアクセスポイント(SAP)アドレス組を使用することで入って来るパケットを関連リンクに写像できます。 ノードが起動を受けるならIPアドレス組との定義されたリンクとSAPがそれを対にするのでXIDがアクティブな定義されたリンクのように同じである、そのノードはリンクが失敗して、パートナーノードがリンクを現役に戻していると仮定できます。 このような場合には最適化として、XIDを受けるノードは、アクティブなリンクを降ろして、リンクがIPネットワークで復職するのを許容できます。 UDPパケットが故障していた状態で到着できるので、この最適化の実装は迷っているXIDがアクティブなリンクを非活性化するのを防ぐためにタイマの使用を必要とします。
Support for multiple defined links between a pair of HPR/IP ports is optional. There is currently no value in defining multiple HPR/IP links between a pair of ports. In the future if HPR/IP support for the Resource ReSerVation Protocol (RSVP) [10] is defined, it may be advantageous to define such parallel links to segregate traffic by COS on RSVP "sessions." Using RSVP, HPR would be able to reserve bandwidth in IP networks. An HPR logical link would be mapped to an RSVP "session" that would likely be identified by either a specific application-provided UDP port number or a dynamically-assigned UDP port number.
1組のHPR/IPポートの間の複数の定義されたリンクのサポートは任意です。 現在、1組のポートの間の複数のHPR/IPリンクを定義するのにおいて値が全くありません。 将来、Resource ReSerVationプロトコル(RSVP)[10]のHPR/IPサポートが定義されるなら、RSVP「セッション」のときにCOSでトラフィックを隔離するためにそのような平行なリンクを定義するのは有利であるかもしれません。 RSVPを使用して、HPRはIPネットワークの帯域幅を控えることができるでしょう。 HPRの論理的なリンクは特定のアプリケーションで提供されたUDPポートナンバーかダイナミックに割り当てられたUDPポートナンバーのどちらかによっておそらく特定されるRSVP「セッション」まで写像されるでしょう。
When multiple defined HPR/IP links between ports are not supported, an incoming activation for a defined HPR/IP link may be rejected with sense data X'10160045' if an active defined HPR/IP link already exists between the ports. If the SAP pair in the activation XID matches the SAP pair for the existing link, the optimization described above may be used instead.
ポートの間の複数の定義されたHPR/IPリンクが支えられないとき、活動的な定義されたHPR/IPリンクがポートの間に既に存在しているなら、定義されたHPR/IPリンクのための入って来る起動は'10160045'というセンス・データXで拒絶されるかもしれません。 起動XIDにおけるSAP組が既存のリンクへのSAP組に合っているなら、上で説明された最適化は代わりに使用されるかもしれません。
If parallel defined HPR/IP links between ports are not supported, an incoming activation XID is mapped to the defined link station (if it exists) associated with the port on the adjacent node using the source IP address in the incoming activation XID. This source IP address should be the same as the destination IP address associated with the matching defined link station. (They may not be the same if the adjacent node has multiple IP addresses, and the configuration was not coordinated correctly.)
ポートの間の平行な定義されたHPR/IPリンクが支えられないなら、入って来る起動XIDは隣接しているノードの上の入って来る起動XIDにおけるソースIPアドレスを使用するポートに関連している定義されたリンクステーション(存在しているなら)に写像されます。 このソースIPアドレスはマッチングに関連している送付先IPアドレスがリンクステーションを定義したのと同じであるべきです。 (隣接しているノードに複数のIPアドレスがあるなら、それらは同じでないかもしれなく、また構成は正しく調整されませんでした。)
If parallel HPR/IP links between ports are supported, multiple defined link stations may be associated with the port on the adjacent node. In that case, predefined TG numbers (see "Partitioning the TG
ポートの間の平行なHPR/IPリンクが支えられるなら、複数の定義されたリンクステーションが隣接しているノードの上のポートに関連しているかもしれません。 その場合、事前に定義されたTGが付番する、(「TGを仕切ります」を見てください。
Dudley Informational [Page 13] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[13ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
Number Space" in Chapter 9 Configuration Services of [1]) may be used to map the XID to a specific link station. However, because the same TG characteristics may be used for all HPR/IP links between a given pair of ports, all the link stations associated with the port in the adjacent node should be equivalent; as a result, TG number negotiation using negotiable TG numbers may be used.
第9章 [1])のConfiguration Servicesの「数のSpace」は、特定のリンクステーションにXIDを写像するのに使用されるかもしれません。 しかしながら、同じTGの特性がすべてのHPR/IPリンクに使用されるかもしれないので、ポートの与えられた組、中にポートがある状態で関連づけられたすべてのリンクステーションの間では、隣接しているノードは同等であるべきです。 その結果、交渉可能なTG番号を使用するTG数の交渉は使用されるかもしれません。
In the future, if multiple HPR/IP links with different characteristics are defined between a pair of ports using RSVP, defined link stations will need sufficient configured information to be matched with incoming XIDs. (Correct matching of an incoming XID to a defined link station allows CS to provide the correct TG characteristics to topology and routing services (TRS).) At that time CS will do the mapping based on both the IP address of the adjacent node and a predefined TG number.
将来、異なった特性との複数のHPR/IPリンクが1組のポートの間でRSVPを使用することで定義されると、定義されたリンクステーションは、十分な構成された情報が入って来るXIDsに合わせられる必要があるでしょう。 (定義されたリンクステーションへの入って来るXIDの正しいマッチングで、CSはトポロジーとルーティングサービス(TRS)に正しいTGの特性を提供できます。) その時、CSは隣接しているノードのIPアドレスと事前に定義されたTG番号の両方に基づくマッピングをするでしょう。
The node initiating link activation knows which link it is activating. Some parameters sent in prenegotiation XID are defined in the regular link station configuration and not allowed to change in following negotiation-proceeding XIDs. To allow for forward migration to RSVP, when a regular TG is activated in an IP network, the node receiving the first XID (i.e., the node not initiating link activation) must also understand which defined link station is being activated before sending a prenegotiation XID in order to correctly set parameters that cannot change. For this reason, the node initiating link activation will indicate the TG number in prenegotiation XIDs by including a TG Descriptor (X'46') control vector containing a TG Identifier (X'80') subfield. Furthermore, the node receiving the first XID will force the node activating the link to send the first prenegotiation XID by responding to null XIDs with null XIDs. To prevent potential deadlocks, the node receiving the first XID has a limit (the LDLC retry count can be used) on the number of null XIDs it will send. Once this limit is reached, that node will send an XID with an XID Negotiation Error (X'22') control vector in response to a null XID; sense data X'0809003A' is included in the control vector to indicate unexpected null XID. If the node that received the first XID receives a prenegotiation XID without the TG Identifier subfield, it will send an XID with an XID Negotiation Error control vector to reject the link connection; sense data X'088C4680' is included in the control vector to indicate the subfield was missing.
起動が知っているリンクを開始するそれがそれのリンクを動かしているノード。 いくつかのパラメタが、prenegotiation XIDが通常のリンクステーション構成で定義されて、交渉を続かせるXIDsに続く際に変化できないのを送りました。 また、通常のTGがIPネットワークで動くとき、RSVPにおいて前進の移行を考慮するために、最初のXID(すなわち、リンク起動を開始しないノード)を受けるノードは、正しく変化できないパラメタを設定するためにprenegotiation XIDを送る前にどれがリンクステーションを定義したかが動かされる予定であるのを理解しなければなりません。 'この理由で、リンク起動を開始するノードがprenegotiation XIDsでTG Descriptorを含んでいることによってTG番号を示す、(X46年、'、)、TG Identifierを含むベクトルを制御してください、(X80年、'、)、部分体。 その上、最初のXIDを受けるノードによって、リンクを動かすノードはヌルXIDsとヌルXIDsに応じることによって、やむを得ず最初のprenegotiation XIDを送るでしょう。 潜在的行き詰まりを防ぐために、最初のXIDを受けるノードはそれが送るヌルXIDsの数に限界(LDLC再試行カウントを使用できる)を持っています。 'この限界にいったん達していると、そのノードがXID Negotiation ErrorとXIDを送る、(X22年、'、)、ヌルXIDに対応してベクトルを制御してください。 'センス・データX'0809003A'は、予期していなかったヌルXIDを示すためにコントロールベクトルに含まれています。 最初のXIDを受けたノードがTG Identifier部分体なしでprenegotiation XIDを受けると、リンク結合を拒絶するためにXID Negotiation Errorコントロールベクトルと共にXIDを送るでしょう。 'センス・データX'088C4680'は、部分体がなくなったのを示すためにコントロールベクトルに含まれています。
For a regular TG, the TG parameters are provided by the node operator based on customer configuration in DEFINE_PORT(RQ) and DEFINE_LS(RQ). The following parameters are supplied in DEFINE_LS(RQ) for HPR/IP links:
通常のTGにおいて、TGパラメタはDEFINE_PORT(RQ)とDEFINE_LS(RQ)で顧客構成に基づくノードオペレータによって提供されます。 DEFINE_LS(RQ)でHPR/IPリンクに以下のパラメタを提供します:
Dudley Informational [Page 14] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[14ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
o The destination IP host name (this parameter can usually be
mapped to the destination IP address): If the link is not
activated at node initialization, the IP host name should be
mapped to an IP address, and the IP address should be stored with
the link station definition. This is required to allow an
incoming link activation to be matched with the link station
definition. If the adjacent node activates the link with a
different IP address (e.g., it could have multiple ports), it
will not be possible to match the link activation with the link
station definition, and the default parameters specified in the
local port definition will be used.
o 目的地IPホスト名(通常、送付先IPアドレスにこのパラメタを写像できます): リンクがノード初期化で動かないなら、IPホスト名はIPアドレスに写像されるべきです、そして、IPアドレスはリンクステーション定義で保存されるべきです。 これが、入って来るリンク起動がリンクステーション定義に合われているのを許容するのに必要です。 隣接しているノードが異なったIPアドレスとのリンクを動かすと(例えば、それは複数のポートを持っているかもしれません)、リンクステーション定義にリンク起動に合っているのが可能でなく、地方のポート定義で指定されたデフォルトパラメタは使用されるでしょう。
o The destination IP version (set to version 4, support for version
6 may be required in the future; this parameter is only required
if the address and version cannot be determined using the
destination IP host name.)
o 目的地IPバージョン(バージョン4へのセット、バージョン6のサポートが将来、必要であるかもしれません; アドレスとバージョンが目的地IPホスト名を使用することで決定できない場合にだけ、このパラメタが必要です。)
o The destination IP address (in the format specified by the
destination IP version; this parameter is only required if the
address cannot be determined using the destination IP host name.)
o 送付先IPアドレス(目的地IPバージョンで指定された形式で; アドレスが目的地IPホスト名を使用することで決定できない場合にだけ、このパラメタが必要です。)
o Source service access point address (SSAP) used for XID, TEST,
DISC, and DM (default is X'04'; other values may be specified
when multiple links between a pair of IP addresses are defined)
o XID、TEST、DISC、およびDMに使用されるソースサービスアクセスポイントアドレス(SSAP)(デフォルトはX'04'です; 1組のIPアドレスの間の複数のリンクが定義されると、他の値は指定されているかもしれません)
o Destination service access point address (DSAP) used for XID,
TEST, DISC, and DM (default is X'04')
o XID、TEST、DISC、およびDMに使用される送付先サービスアクセスポイントアドレス(DSAP)(デフォルトはX'04'です)
o Source service access point address (SSAP) used for HPR network
layer packets (NLPs) (default is X'C8'; other values may be
specified when multiple links between a pair of IP addresses are
defined.)
o HPRネットワーク層パケット(NLPs)に使用されるソースサービスアクセスポイントアドレス(SSAP)デフォルトはX'C8です。'、('; 1組のIPアドレスの間の複数のリンクが定義されると他の値が指定されているかもしれない、)
o Maximum receive BTU size (default is 1461; this parameter is used
to override the setting in DEFINE_PORT.)
o 最大はBTUサイズを受けます。(デフォルトは1461です; このパラメタはDEFINE_PORTで設定をくつがえすのに使用されます。)
o Maximum send BTU size (default is 1461; this parameter is used to
override the setting in DEFINE_PORT.)
o 最大はBTUサイズを送ります。(デフォルトは1461です; このパラメタはDEFINE_PORTで設定をくつがえすのに使用されます。)
o IP precedence (the setting of the 3-bit field within the Type of
Service byte of the IP header for LLC commands such as XID and
for each of the APPN transmission priorities; the defaults are
given in 2.6.1, "IP Prioritization" on page 28; this parameter is
used to override the settings in DEFINE_PORT)
o IP先行(LLCのためのAPPNトランスミッションプライオリティ; XIDなどとそれぞれのデフォルトのためのコマンドが与えられているIPヘッダーのServiceバイトのTypeの中の3ビットの分野の設定、2.6、.1、28ページ ; このパラメタの「IP優先順位づけ」がDEFINE_PORTで設定をくつがえすのに使用される、)
o Shareable with connection network traffic (default is yes for
non-RSVP links)
o 接続ネットワークトラフィックがあるShareable(デフォルトは非RSVPリンクへのはいです)
Dudley Informational [Page 15] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[15ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
o Retry count for LDLC (default is 3; this parameter is used to
override the setting in DEFINE_PORT)
o LDLCのためにカウントを再試行してください。(デフォルトは3です; このパラメタはDEFINE_PORTで設定をくつがえすのに使用されます)
o Retry timer period for LDLC (default is 15 seconds; a smaller
value such as 10 seconds can be used for a campus link; this
parameter is used to override the setting in DEFINE_PORT)
o LDLCのためにタイマの期間を再試行してください。(デフォルトは15秒です; キャンパスリンクに10秒などの、より小さい値を使用できます; このパラメタはDEFINE_PORTで設定をくつがえすのに使用されます)
o LDLC liveness timer period (default is 10 seconds; this parameter
is to override the setting in DEFINE_PORT; see 2.3.1, "LDLC ness"
on page 7)
o LDLC活性タイマの期間(デフォルトは10秒です; このパラメタはDEFINE_PORTで設定をくつがえすことです; 見てください、2.3、.1、7ページの)「LDLC岬」
o Auto-activation supported (default is no; may be set to yes when
the local node has switched access to the IP network)
o サポートされた自動活性化(デフォルトはノーです; ローカルのノードがIPネットワークへのアクセスを切り換えたとき、はいに設定されるかもしれません)
o Limited resource (default is to set in concert with auto-
activation supported)
o 株式会社リソース(デフォルトはサポートされた自動起動と協力してセットすることです)
o Limited resource liveness timer (default is 45 sec.)
o 株式会社リソース活性タイマ(デフォルトは45秒です)
o Port name
o ポート名
o Adjacent CP name (optional)
o 隣接しているCP名(任意)です。
o Local CP-CP sessions supported
o セッションがサポートした地方のCP-CP
o Defined TG number (optional)
o 定義されたTG番号(任意)です。
o TG characteristics
o TGの特性
The following figures show the activation and deactivation of regular TGs.
以下の数字は通常のTGsの起動と非活性化を示しています。
Dudley Informational [Page 16] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[16ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
*------------------------------------------------------------------* |CS DLC LDLC DMUX UDP| *------------------------------------------------------------------* . . . . .CONNECT_OUT(RQ) . create . . o--------------->o-------------->o . . . | new LDLC . . . o----------------------------->o . CONNECT_OUT(+RSP)| . . . o<---------------* . . . | XID . XID(CMD) . XID *------------------------------->o----------------------------->o----->
*------------------------------------------------------------------* |Cs DLC LDLC DMUX UDP| *------------------------------------------------------------------* . . . . .CONNECT_OUT(RQ). . oを作成してください。--------------->o-------------->o . . . | 新しいLDLC o…----------------------------->o . (+ RSP)を_外に接続してください。| . . . o<、-、-、-、-、-、-、-、-、-、-、-、-、-、--* . . . | XID XID(CMD)XID*------------------------------->o----------------------------->o----->。
Figure 3. Regular TG Activation (outgoing)
図3。 定期的なTG起動(送信する)です。
In Figure 3 upon receiving START_LS(RQ) from NOF, CS starts the link activation process by sending CONNECT_OUT(RQ) to the DLC manager. The DLC manager creates an instance of LDLC for the link, informs the link demultiplexor, and sends CONNECT_OUT(+RSP) to CS. Then, CS starts the activation XID exchange.
NOFからSTART_LS(RQ)を受けるときの図3では、DLCマネージャにCONNECT_を出すことによって(RQ)、CSはリンク活性化過程を始めます。 DLCマネージャは、CSにLDLCのインスタンスをリンクに作成して、リンク「反-マルチプレクサー」に知らせて、CONNECT_を出します(+ RSP)。 そして、CSは起動XID交換を始めます。
*------------------------------------------------------------------* |CS DLC LDLC DMUX UDP| *------------------------------------------------------------------* . . . . . CONNECT_IN(RQ) . XID(CMD) . XID . XID o<---------------o<-----------------------------o<--------------o<----- | CONNECT_IN(RSP). create . . *--------------->o-------------->o . . . | new LDLC . . . o----------------------------->o . . | XID(CMD) . . . . *-------------->o . . . XID | . . o<-------------------------------* . . | XID . XID(RSP) . XID *------------------------------->o----------------------------->o----->
*------------------------------------------------------------------* |Cs DLC LDLC DMUX UDP| *------------------------------------------------------------------* . . . . . CONNECT_IN(RQ)XID(CMD)XID XID o<。---------------o<、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--o<、-、-、-、-、-、-、-、-、-、-、-、-、--o<、-、-、-、--、| CONNECT_IN(RSP)作成する、*--------------->o-------------->o . . . | 新しいLDLC o…----------------------------->o . . | XID(CMD)… *-------------->o . . . XID| . . o<-------------------------------* . . | XID XID(RSP)XID*------------------------------->o----------------------------->o----->。
Figure 4. Regular TG Activation (incoming)
図4。 定期的なTG起動(入来)
In Figure 4, when an XID is received for a new link, it is passed to the DLC manager. The DLC manager sends CONNECT_IN(RQ) to notify CS of the incoming link activation, and CS sends CONNECT_IN(+RSP) accepting the link activation. The DLC manager then creates a new instance of LDLC, informs the link demultiplexor, and forwards the XID to to CS via LDLC. CS then responds by sending an XID to the adjacent node.
新しいリンクにXIDを受け取るとき、図4では、DLCマネージャにそれを渡します。 DLCマネージャは入って来るリンク起動についてCSに通知するためにCONNECT_を送ります、そして、(RQ)CSはCONNECT_IN(+ RSP)にリンク起動を受け入れさせます。 DLCマネージャは、次に、LDLCの新しいインスタンスを作成して、リンクを知らせます。LDLCを通してXIDをCSにdemultiplexorして、送ります。 そして、CSは、隣接しているノードにXIDを送ることによって、応じます。
Dudley Informational [Page 17] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[17ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
The two following figures show normal TG deactivation (outgoing and incoming).
2つの次の数字が(送受信)で正常なTG非活性化を示しています。
*------------------------------------------------------------------* |CS DLC LDLC DMUX UDP| *------------------------------------------------------------------* . . . . . . DEACT . DISC . DISC o------------------------------->o----------------------------->o-----> . DEACT . DM . DM . DM o<-------------------------------o<-------------o<--------------o<----- | DISCONNECT(RQ) . destroy . . . *--------------->o-------------->o . . DISCONNECT(RSP) | . . o<---------------* . .
*------------------------------------------------------------------* |Cs DLC LDLC DMUX UDP| *------------------------------------------------------------------* . . . . . . DEACT DISC DISC o------------------------------->o----------------------------->o----->DEACT DM DM DM o<。-------------------------------o<、-、-、-、-、-、-、-、-、-、-、-、--o<、-、-、-、-、-、-、-、-、-、-、-、-、--o<、-、-、-、--、| DISCONNECT(RQ)…*を破壊してください。--------------->o-------------->o . . (RSP)から切断してください。| . . o<、-、-、-、-、-、-、-、-、-、-、-、-、-、--* . .
Figure 5. Regular TG Deactivation (outgoing)
図5。 通常のTG非活性化(送信する)です。
In Figure 5 upon receiving STOP_LS(RQ) from NOF, CS sends DEACT to notify the partner node that the HPR link is being deactivated. When the response is received, CS sends DISCONNECT(RQ) to the DLC manager, and the DLC manager deactivates the instance of LDLC. Upon receiving DISCONNECT(RSP), CS sends STOP_LS(RSP) to NOF.
NOFからSTOP_LS(RQ)を受けるときの図5では、CSは、HPRリンクが非活性化されているようにパートナーノードに通知するためにDEACTを送ります。 応答が受け取られているとき、CSはDISCONNECT(RQ)をDLCマネージャに送ります、そして、DLCマネージャはLDLCのインスタンスを非活性化します。 DISCONNECT(RSP)を受けると、CSはSTOP_LS(RSP)をNOFに送ります。
*------------------------------------------------------------------* |CS DLC LDLC DMUX UDP| *------------------------------------------------------------------* . . . . . . DEACT . DISC . DISC . DISC o<-------------------------------o<-------------o<--------------o<----- | . | DM . DM | . *----------------------------->o-----> | DISCONNECT(RQ) . destroy . . . *--------------->o-------------->o . . .DISCONNECT(RSP) | . . o<---------------* . .
*------------------------------------------------------------------* |Cs DLC LDLC DMUX UDP| *------------------------------------------------------------------* . . . . . . DEACT DISC DISC DISC o<。-------------------------------o<、-、-、-、-、-、-、-、-、-、-、-、--o<、-、-、-、-、-、-、-、-、-、-、-、-、--o<、-、-、-、--、| . | DM DM| . *----------------------------->o----->| DISCONNECT(RQ)…*を破壊してください。--------------->o-------------->o . . .DISCONNECT(RSP)| . . o<、-、-、-、-、-、-、-、-、-、-、-、-、-、--* . .
Figure 6. Regular TG Deactivation (incoming)
図6。 通常のTG非活性化(入来)
In Figure 6, when an adjacent node deactivates a TG, the local node receives a DISC. CS sends STOP_LS(IND) to NOF. Because IP is connectionless, the DLC manager is not aware that the link has been deactivated. For that reason, CS also needs to send DISCONNECT(RQ) to the DLC manager; the DLC manager deactivates the instance of LDLC.
隣接しているノードがTGを非活性化するとき、図6では、ローカルのノードはDISCを受けます。 CSはSTOP_LS(IND)をNOFに送ります。 IPがコネクションレスであるので、DLCマネージャはリンクが非活性化されたのを意識していません。 その理由で、また、CSは、DISCONNECT(RQ)をDLCマネージャに送る必要があります。 DLCマネージャはLDLCのインスタンスを非活性化します。
Dudley Informational [Page 18] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[18ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
2.5.1.1 Limited Resources and Auto-Activation
2.5.1.1 限りある資源と自動活性化
To reduce tariff charges, the APPN architecture supports the definition of switched links as limited resources. A limited- resource link is deactivated when there are no sessions traversing the link. Intermediate HPR nodes are not aware of sessions between logical units (referred to as LU-LU sessions) carried in crossing RTP connections; in HPR nodes, limited-resource TGs are deactivated when no traffic is detected for some period of time. Furthermore, APPN links may be defined as auto-activatable. Auto-activatable links are activated when a new session has been routed across the link.
関税充電を下げるために、APPNアーキテクチャは限りある資源として切り換えられたリンクの定義をサポートします。 リンクを横断するセッションが全くないとき、限られたリソースリンクは非活性化されます。 中間的HPRノードはRTP接続を横断する際に運ばれた論理装置(LU-LUセッションに言及される)の間のセッションを意識していません。 トラフィックが全くいつかの期間の間検出されないとき、HPRノードでは、限られたリソースTGsは非活性化されます。 その上、APPNリンクは自動活性化可能であると定義されるかもしれません。 新しいセッションがリンクの向こう側に発送されたとき、自動活性化可能なリンクは活性です。
An HPR node may have access to an IP network via a switched access link. In such environments, it may be advisable for customers to define regular HPR/IP links as limited resources and as being auto- activatable.
HPRノードは切り換えられたアクセスリンクを通してIPネットワークに近づく手段を持っているかもしれません。 そのような環境で、顧客が通常のHPR/IPリンクを限りある資源で自動活性化可能であると定義するのは、賢明であるかもしれません。
2.5.2 IP Connection Networks
2.5.2 IP接続ネットワーク
Connection network support for IP networks (option set 2010), is described in this section.
IPの接続ネットワークサポートは、(オプションセット2010)をネットワークでつないで、このセクションで説明されます。
APPN architecture defines single link TGs across the point-to-point lines connecting APPN nodes. The natural extension of this model would be to define a TG between each pair of nodes connected to a shared access transport facility (SATF) such as a LAN or IP network. However, the high cost of the system definition of such a mesh of TGs is prohibitive for a network of more than a few nodes. For that reason, the APPN connection network model was devised to reduce the system definition required to establish TGs between APPN nodes.
APPNアーキテクチャは、APPNノードを接続しながら、二地点間系列の向こう側に独身のリンクTGsを定義します。 このモデルの自然な拡大はLANかIPネットワークなどの共用アクセス輸送施設(SATF)に接続されたそれぞれの組のノードの間のTGを定義するだろうことです。 しかしながら、かなり多くのノードのネットワークに、TGsのそのようなメッシュのシステム定義の高い費用はひどく高いです。 その理由で、APPN接続ネットワークモデルは、APPNノードの間のTGsを設立するのに必要であるシステム定義を抑えるために工夫されました。
Other TGs may be defined through the SATF which are not part of the connection network. Such TGs (referred to as regular TGs in this document) are required for sessions between control points (referred to as CP-CP sessions) but may also be used for LU-LU sessions.
他のTGsは接続ネットワークの一部でないSATFを通して定義されるかもしれません。 そのようなTGs(本書では通常のTGsと呼ばれる)は制御点の間のセッションに必要ですが(CP-CPセッションに言及されます)、また、LU-LUセッションに使用されるかもしれません。
In the connection network model, a virtual routing node (VRN) is defined to represent the SATF. Each node attached to the SATF defines a single TG to the VRN rather than TGs to all other attached nodes.
接続ネットワークモデルでは、仮想のルーティングノード(VRN)は、SATFを表すために定義されます。 SATFに添付された各ノードは他のすべての添付のノードへのTGsよりむしろVRNと独身のTGを定義します。
Topology and routing services (TRS) specifies that a session is to be routed between two nodes across a connection network by including the connection network TGs between each of those nodes and the VRN in the Route Selection control vector (RSCV). When a network node has a TG to a VRN, the network topology information associated with that TG includes DLC signaling information required to establish connectivity to that node across the SATF. For an end node, the DLC signaling
トポロジーと接続ネットワークの向こう側にそれぞれのそれらのノードの間の接続ネットワークTGsとRoute SelectionのVRNを含んでいることによって(TRS)が指定する2つのノードの間に発送されるためにセッションがあるサービスを発送すると、ベクトル(RSCV)は制御されます。 ネットワーク・ノードがVRNにTGを持っているとき、そのTGに関連しているネットワーク形態情報はSATFの向こう側に接続性を確立するのに必要であるDLCシグナリング情報をそのノードに含んでいます。 エンドノード、DLCシグナリングのために
Dudley Informational [Page 19] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[19ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
information is returned as part of the normal directory services (DS) process. TRS includes the DLC signaling information for TGs across connection networks in RSCVs.
正常なディレクトリサービス(DS)プロセスの一部として情報を返します。 TRSはRSCVsの接続ネットワークの向こう側にTGsのためのDLCシグナリング情報を含んでいます。
CS creates a dynamic link station when the next hop in the RSCV of an ACTIVATE_ROUTE signal received from session services (SS) is a connection network TG or when an adjacent node initiates link activation upon receiving such an ACTIVATE_ROUTE signal. Dynamic link stations are normally treated as limited resources, which means they are deactivated when no sessions are using them. CP-CP sessions are not supported on connections using dynamic link stations because CP-CP sessions normally need to be kept up continuously.
セッション・サービス(SS)から受信されたACTIVATE_ROUTE信号のRSCVの次のホップが接続ネットワークTGであるか隣接しているノードがそのようなACTIVATE_ROUTE信号を受信するときのリンク起動を開始するとき、CSはダイナミックなリンクステーションを創設します。 通常、ダイナミックなリンクステーションは限りある資源として扱われます(どんなセッションもそれらを使用していないとき、それらが非活性化されることを意味します)。 CP-CPセッションは、接続のときにCP-CPセッションが、通常絶え間なく維持される必要があるのでダイナミックなリンクステーションを使用することでサポートされません。
Establishment of a link across a connection network normally requires the use of CP-CP sessions to determine the destination IP address. Because CP-CP sessions must flow across regular TGs, the definition of a connection network does not eliminate the need to define regular TGs as well.
通常、接続ネットワークの向こう側のリンクの設立は、送付先IPアドレスを決定するためにCP-CPセッションの使用を必要とします。 CP-CPセッションが通常のTGsの向こう側に流れなければならないので、接続ネットワークの定義はまた、通常のTGsを定義する必要性を排除しません。
Normally, one connection network is defined on a LAN (i.e., one VRN is defined.) For an environment with several interconnected campus IP networks, a single wide-area connection network can be defined; in addition, separate connection networks can be defined between the nodes connected to each campus IP network.
通常、1つの接続ネットワークがLANで定義されます(すなわち、1VRNが定義されます。)。 いくつかのインタコネクトされたキャンパスIPネットワークがある環境において、ただ一つの広い領域接続ネットワークを定義できます。 さらに、それぞれのキャンパスIPネットワークに接続されたノードの間で別々の接続ネットワークを定義できます。
2.5.2.1 Establishing IP Connection Networks
2.5.2.1 IP接続ネットワークを設立すること。
Once the port is defined, a connection network can be defined on the port. In order to support multiple TGs from a port to a VRN, the connection network is defined by the following process:
ポートがいったん定義されると、ポートの上で接続ネットワークを定義できます。 ポートからVRNまで複数のTGsをサポートするために、接続ネットワークは以下のプロセスによって定義されます:
1. A connection network and its associated VRN are defined on the
port. This is accomplished by the node operator issuing a
DEFINE_CONNECTION_NETWORK(RQ) command to NOF and NOF passing a
DEFINE_CN(RQ) signal to CS.
1. 接続ネットワークとその関連VRNはポートの上で定義されます。 これはDEFINE_CONNECTION_NETWORK(RQ)コマンドをNOFに発行するノードオペレータによって達成されます、そして、DEFINE_CN(RQ)を渡すNOFがCSに合図します。
2. Each TG from the port to the VRN is defined by the node operator
issuing DEFINE_CONNECTION_NETWORK_TG(RQ) to NOF and NOF passing
DEFINE_CN_TG(RQ) to CS.
2. 各ポートからVRNまでのTGはDEFINE_CN_TG(RQ)をCSに通過するNOFとNOFにDEFINE_CONNECTION_NETWORK_TG(RQ)を発行するノードオペレータによって定義されます。
Prior to implementation of Resource ReSerVation Protocol (RSVP) support, only one connection network TG between a port and a VRN is required. In that case, product support for the DEFINE_CN_TG(RQ) signal is not required because a single set of port configuration parameters for each connection network is sufficient. If a NOF implementation does not support DEFINE_CN_TG(RQ), the parameters listed in the following section for DEFINE_CN_TG(RQ), are provided by DEFINE_CN(RQ) instead. Furthermore, the Connection Network TG
Resource ReSerVationプロトコル(RSVP)サポートの実装の前に、ポートとVRNとの1接続ネットワークTGだけが必要です。 その場合、各接続ネットワークのための1セットのポート設定パラメータが十分であるので、DEFINE_CN_TG(RQ)信号の製品サポートは必要ではありません。 _NOF実装が、DEFINE_がCNであるとサポートしないなら、TG(RQ)(DEFINE_CN_TG(RQ)のために以下のセクションでリストアップされたパラメタ)は代わりにDEFINE_CN(RQ)によって提供されます。 その上、接続はTGをネットワークでつなぎます。
Dudley Informational [Page 20] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[20ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
Numbers (X'81') subfield in the TG Descriptor (X'46') control vector on an activation XID is only required to support multiple connection network TGs to a VRN, and its use is optional.
'番号、(X81年、'、)、TG Descriptorの部分体、(X46年、'、)、起動XIDのコントロールベクトルが複数の接続ネットワークがTGsであるとVRNにサポートするのに必要であるだけであり、使用は任意です。
*-----------------------------------------------------*
| NO NOF CS |
*-----------------------------------------------------*
DEFINE_CONNECTION_NETWORK(RQ) DEFINE_CN(RQ) .
o------------------------>o----------------->o
DEFINE_CONNECTION_NETWORK(RSP) DEFINE_CN(RSP) |
o<------------------------o<-----------------*
DEFINE_CONNECTION_NETWORK_TG(RQ) DEFINE_CN_TG(RQ) .
o------------------------>o----------------->o
DEFINE_CONNECTION_NETWORK_TG(RSP) DEFINE_CN_TG(RSP)|
o<------------------------o<-----------------*
*-----------------------------------------------------* | NOF Csがありません。| *-----------------------------------------------------* DEFINE_CONNECTION_NETWORK(RQ)DEFINE_CN(RQ) o------------------------>o----------------->o 定義、_接続_ネットワーク(RSP)は_CN(RSP)を定義します。| o<、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--o<、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--* DEFINE_CONNECTION_NETWORK_TG(RQ)DEFINE_CN_TG(RQ) o------------------------>o----------------->o 定義、_接続_ネットワーク_TG(RSP)は_CN_TG(RSP)を定義します。| o<、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--o<、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--*
Figure 7. IP Connection Network Definition
図7。 IP接続ネットワーク定義
An incoming dynamic link activation may be rejected with sense data X'10160046' if there is an existing dynamic link between the two ports over the same connection network (i.e., with the same VRN CP name). If a node receives an activation XID for a dynamic link with an IP address pair, a SAP pair, and a VRN CP name that are the same as for an active dynamic link, that node can assume that the link has failed and that the partner node is reactivating the link. In such a case as an optimization, the node receiving the XID can take down the active link and allow the link to be reestablished in the IP network. Because UDP packets can arrive out of order, implementation of this optimization requires the use of a timer to prevent a stray XID from deactivating an active link.
同じ接続ネットワーク(すなわち、同じVRN CP名がある)の上に2つのポートの間には、既存のダイナミックなリンクがあれば、入って来るダイナミックなリンク起動は'10160046'というセンス・データXで拒絶されるかもしれません。 ノードが起動を受けるなら、IPアドレス組、SAP組、およびVRN CP名とのダイナミックなリンクへの同じであるXIDはアクティブな動力のようにリンクして、そのノードは、リンクが失敗して、パートナーノードがリンクを現役に戻していると仮定できます。 このような場合には最適化として、XIDを受けるノードは、アクティブなリンクを降ろして、リンクがIPネットワークで復職するのを許容できます。 UDPパケットが故障していた状態で到着できるので、この最適化の実装は迷っているXIDがアクティブなリンクを非活性化するのを防ぐためにタイマの使用を必要とします。
Once all the connection networks are defined, the node operator issues START_PORT(RQ), NOF passes the associated signal to CS, and CS passes ACTIVATE_PORT(RQ) to the DLC manager. Upon receiving the ACTIVATE_PORT(RSP) signal from the DLC manager, CS sends a TG_UPDATE signal to TRS for each defined connection network TG. Each signal notifies TRS that a TG to the VRN has been activated and includes TG vectors describing the TG. If the port fails or is deactivated, CS sends TG_UPDATE indicating the connection network TGs are no longer operational. Information about TGs between a network node and the VRN is maintained in the network topology database. Information about TGs between an end node and the VRN is maintained only in the local topology database. If TRS has no node entry in its topology database for the VRN, TRS dynamically creates such an entry. A VRN node entry will become part of the network topology database only if
かつてのすべての接続ネットワークが定義されます、そして、ノードオペレータはSTART_PORT(RQ)を発行します、そして、NOFは関連信号をCSに渡します、そして、CSはACTIVATE_PORT(RQ)をDLCマネージャに渡します。 DLCマネージャからACTIVATE_PORT(RSP)信号を受信すると、CSはそれぞれの定義された接続ネットワークTGのためにTG_UPDATE信号をTRSに送ります。 各信号は、VRNへのTGが動いたことをTRSに通知して、TGについて説明するTGベクトルを含んでいます。 ポートが失敗するか、または非活性化されるなら、CSはTG_UPDATEに接続ネットワークTGsがもう操作上でないことを示させます。 ネットワーク・ノードとVRNの間のTGsの情報はネットワーク形態データベースで保守されます。 エンドノードとVRNの間のTGsの情報はローカルのトポロジーデータベースだけで保守されます。 TRSにVRNのためのトポロジーデータベースにおけるノードエントリーが全くないなら、TRSはダイナミックにそのようなエントリーを作成します。 VRNノードエントリーはネットワーク形態データベースの一部だけになるでしょう。
Dudley Informational [Page 21] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[21ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
a network node has defined a TG to the VRN; however, TRS is capable of selecting a direct path between two end nodes across a connection network without a VRN node entry.
ネットワーク・ノードはTGをVRNと定義しました。 しかしながら、TRSは接続ネットワークの向こう側にVRNノードエントリーなしで2つのエンドノードの間の直接路を選択できます。
*--------------------------------------------------------------------*
| CS TRS DLC DMUX |
*--------------------------------------------------------------------*
. ACTIVATE_PORT(RQ) . create
o--------------------------------------->o----------------->o
. ACTIVATE_PORT(RSP) | .
o<---------------------------------------* .
| TG_UPDATE . . .
*------------------->o . .
. . . .
*--------------------------------------------------------------------* | Cs TRS DLC DMUX| *--------------------------------------------------------------------* . ACTIVATE_PORT(RQ)oを作成してください。--------------------------------------->o----------------->o . _ポート(RSP)を動かしてください。| . o<---------------------------------------* . | TG_アップデート…*------------------->o . . . . . .
Figure 8. IP Connection Network Establishment
エイト環。 IP接続ネットワークの形成
The TG vectors for IP connection network TGs include the following information:
IP接続ネットワークTGsのためのTGベクトルは以下の情報を含んでいます:
o TG number
o TG番号
o VRN CP name
o VRN CP名
o TG characteristics used during route selection
o ルート選択の間に使用されるTGの特性
- Effective capacity
- Cost per connect time
- Cost per byte transmitted
- Security
- Propagation delay
- User defined parameters
- 有効能力--1バイトあたりの費用が伝わったという接続時間単位でセキュリティ--伝播遅延--ユーザの定義されたパラメタかかってください。
o Signaling information
o シグナリング情報
- IP version (indicates the format of the IP header including
the IP address)
- IPバージョン(IPアドレスを含むIPヘッダーの書式を示します)
- IP address
- IPアドレス
- Link service access point address (LSAP) used for XID, TEST,
DISC, and DM
- XID、TEST、DISC、およびDMに使用されるリンクサービスアクセスポイントアドレス(LSAP)
2.5.2.2 IP Connection Network Parameters
2.5.2.2 IP接続回路パラメータ
For a connection network TG, the parameters are determined by CS using several inputs. Parameters that are particular to the local port, connection network, or TG are system defined and received in
接続ネットワークTGにおいて、パラメタは、CSによっていくつかの入力を使用することで決定されます。 地方のポート、接続ネットワーク、またはTGに特定のパラメタは定義されて、受け止められたシステムです。
Dudley Informational [Page 22] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[22ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
DEFINE_PORT(RQ), DEFINE_CN(RQ), or DEFINE_CN_TG(RQ). Signaling information for the destination node including its IP address is received in the ACTIVATE_ROUTE request from SS.
_ポート(RQ)を定義するか、_CN(RQ)を定義するか、または_CN_TG(RQ)を定義してください。 ROUTEがSSから要求するACTIVATE_にIPアドレスを含む目的地ノードのためのシグナリング情報を受け取ります。
The following configuration parameters are received in DEFINE_CN(RQ):
DEFINE_CN(RQ)に以下の設定パラメータを受け取ります:
o Connection network name (CP name of the VRN)
o 接続ネットワーク名(CP名(VRN))
o Limited resource liveness timer (default is 45 sec.)
o 株式会社リソース活性タイマ(デフォルトは45秒です)
o IP precedence (the setting of the 3-bit field within the Type of
Service byte of the IP header for LLC commands such as XID and
for each of the APPN transmission priorities; the defaults are
given in 2.6.1, "IP Prioritization" on page 28; this parameter is
used to override the settings in DEFINE_PORT)
o IP先行(LLCのためのAPPNトランスミッションプライオリティ; XIDなどとそれぞれのデフォルトのためのコマンドが与えられているIPヘッダーのServiceバイトのTypeの中の3ビットの分野の設定、2.6、.1、28ページ ; このパラメタの「IP優先順位づけ」がDEFINE_PORTで設定をくつがえすのに使用される、)
The following configuration parameters are received in DEFINE_CN_TG(RQ):
DEFINE_CN_TG(RQ)に以下の設定パラメータを受け取ります:
o Port name
o ポート名
o Connection network name (CP name of the VRN)
o 接続ネットワーク名(CP名(VRN))
o Connection network TG number (set to a value between 1 and 239)
o 接続ネットワークTG番号(1と239の間の値へのセット)
o TG characteristics (see 2.6.3, "Default TG Characteristics" on
page 30)
o TGの特性(2.6に、.3、30ページの「デフォルトTGの特性」を見ます)
o Link service access point address (LSAP) used for XID, TEST,
DISC, and DM (default is X'04')
o XID、TEST、DISC、およびDMに使用されるリンクサービスアクセスポイントアドレス(LSAP)(デフォルトはX'04'です)
o Link service access point address (LSAP) used for HPR network
layer packets (default is X'C8')
o HPRネットワーク層パケットに使用されるリンクサービスアクセスポイントアドレス(LSAP)'、(デフォルトがX'C8である、'、)
o Limited resource (default is yes)
o 株式会社リソース(デフォルトははいです)
o Retry count for LDLC (default is 3; this parameter is used to
override the setting in DEFINE_PORT)
o LDLCのためにカウントを再試行してください。(デフォルトは3です; このパラメタはDEFINE_PORTで設定をくつがえすのに使用されます)
o Retry timer period for LDLC (default is 15 sec.; a smaller value
such as 10 seconds can be used for a campus connection network;
this parameter is used to override the setting in DEFINE_PORT)
o LDLCのためにタイマの期間を再試行してください。(デフォルトは15秒です; キャンパス接続ネットワークに10秒などの、より小さい値を使用できます; このパラメタはDEFINE_PORTで設定をくつがえすのに使用されます)
o LDLC liveness timer period (default is 10 seconds; this parameter
is used to override the setting in DEFINE_PORT; see 2.3.1, "LDLC
Liveness" on page 7)
o LDLC活性タイマの期間(デフォルトは10秒です; このパラメタはDEFINE_PORTで設定をくつがえすのに使用されます; 見てください、2.3、.1、7ページの)「LDLC活性」
Dudley Informational [Page 23] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[23ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
o Shareable with other HPR traffic (default is yes for non-RSVP
links)
o 他のHPRトラフィックがあるShareable(デフォルトは非RSVPリンクへのはいです)
o Maximum receive BTU size (default is 1461; this parameter is used
to override the value in DEFINE_PORT(RQ).)
o 最大はBTUサイズを受けます。(デフォルトは1461です; このパラメタはDEFINE_PORT(RQ)で値をくつがえすのに使用されます。)
o Maximum send BTU size (default is 1461; this parameter is used to
override the value in DEFINE_PORT(RQ).)
o 最大はBTUサイズを送ります。(デフォルトは1461です; このパラメタはDEFINE_PORT(RQ)で値をくつがえすのに使用されます。)
The following parameters are received in ACTIVATE_ROUTE for connection network TGs:
接続ネットワークTGsのためにACTIVATE_ROUTEに以下のパラメタを受け取ります:
o The TG pair
o TG組
o The destination IP version (if this version is not supported by
the local node, the ACTIVATE_ROUTE_RSP reports the activation
failure with sense data X'086B46A5'.)
o 目的地IPバージョン'(このバージョンがローカルのノードによってサポートされないなら、ACTIVATE_ROUTE_RSPは'086B46A5'というセンス・データXで起動失敗を報告します。)
o The destination IP address (in the format specified by the
destination IP version)
o 送付先IPアドレス(目的地IPバージョンによって指定された形式の)
o Destination service access point address (DSAP) used for XID,
TEST, DISC, and DM
o XID、TEST、DISC、およびDMに使用される送付先サービスアクセスポイントアドレス(DSAP)
2.5.2.3 Sharing of TGs
2.5.2.3 TGsの共有
Connection network traffic is multiplexed onto a regular defined IP TG (usually used for CP-CP session traffic) in order to reduce the control block storage. No XIDs flow to establish a new TG on the IP network, and no new LLC is created. When a regular TG is shared, incoming traffic is demultiplexed using the normal means. If the regular TG is deactivated, a path switch is required for the HPR connection network traffic sharing the TG.
制御ブロックストレージを抑えるために通常の定義されたIP TG(通常、CP-CPセッショントラフィックに使用される)に接続ネットワークトラフィックを多重送信します。 どんなXIDsもIPネットワークで新しいTGを証明するために流れません、そして、どんな新しいLLCも作成されません。 通常のTGが共有されるとき、入って来るトラフィックは、正常な手段を使用することで反多重送信されます。 通常のTGが非活性化されるなら、経路スイッチがTGを共有するHPR接続ネットワークトラフィックに必要です。
Multiplexing is possible if the following conditions hold:
以下の条件が成立するなら、マルチプレクシングは可能です:
1. Both the regular TG and the connection network TG to the VRN are
defined as shareable between HPR traffic streams.
1. 通常のTGと接続ネットワークTGのVRNへの両方がHPRトラフィックストリームの間の共有可能と定義されます。
2. The destination IP address is the same.
2. 送付先IPアドレスは同じです。
3. The regular TG is established first. (Because links established
for connection network traffic do not support CP-CP sessions,
there is little value in allowing a regular TG to share such a
link.)
3. 通常のTGは最初に、設立されます。 (接続ネットワークトラフィックに設立されたリンクがCP-CPにセッションをサポートしないので、通常のTGがそのようなリンクを共有するのを許容するのにおいて値がほとんどありません。)
The destination node is notified via XID when a TG can be shared between HPR data streams. At either end, upon receiving
HPRデータ・ストリームの間でTGを共有できるとき、目的地ノードはXIDを通して通知されます。どちらかでは、受信のときに終わってください。
Dudley Informational [Page 24] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[24ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
ACTIVATE_ROUTE requesting a shared TG for connection network traffic, CS checks its TGs for one meeting the required specifications before initiating a new link. First, CS looks for a link established for the TG pair; if there is no such link, CS determines if there is a regular TG that can be shared and, if multiple such TGs exist, which TG to choose. As a result, RTP connections routed over the same TG pair may actually use different links, and RTP connections routed over different TG pairs may use the same link.
ACTIVATE_ROUTEが接続ネットワークトラフィックに共有されたTGを要求して、CSは新しいリンクを開始する前に個人的には必要な仕様を満たすTGsをチェックします。 まず最初に、CSはTG組のために設立されたリンクを探します。 どれかそのようなリンクがなければ、CSは共有できる通常のTGがあるかどうかと、どのTGをそのような倍数TGsが存在しているなら選んだらよいかを決定します。 その結果、同じTG組の上に発送されたRTP接続は実際に異なったリンクを使用するかもしれません、そして、異なったTG組の上に発送されたRTP接続は同じリンクを使用するかもしれません。
2.5.2.4 Minimizing RSCV Length
2.5.2.4 RSCVの長さを最小にすること。
The maximum length of a Route Selection (X'2B') control vector (RSCV) is 255 bytes. Use of connection networks significantly increases the size of the RSCV contents required to describe a "hop" across an SATF. First, because two connection network TGs are used to specify an SATF hop, two TG Descriptor (X'46') control vectors are required. Furthermore, inclusion of DLC signaling information within the TG Descriptor control vectors increases the length of these control vectors. As a result, the total number of hops that can be specified in RSCVs traversing connection networks is reduced.
'Route Selection(X'2B')コントロールベクトル(RSCV)の最大の長さは255バイトです。 接続ネットワークの使用はコンテンツがSATFの向こう側に「ホップ」について説明するのを必要としたRSCVのサイズをかなり増加させます。 '2接続ネットワークTGsがSATFホップを指定するのに使用されるので最初に、2TG Descriptor、(X46年、'、)、コントロールベクトルが必要です。 その上、TG Descriptorコントロールベクトルの中で情報に合図するDLCの包含はこれらのコントロールベクトルの長さを増加させます。 その結果、接続ネットワークを横断するRSCVsで指定できるホップの総数は減少します。
To avoid unnecessarily limiting the number of hops, a primary goal in designing the formats for IP signaling information is to minimize their size. Additional techniques are also used to reduce the effect of the RSCV length limitation.
不必要にホップの数を制限するのを避けるために、IPシグナリング情報のために形式を設計することにおける第一の目標はそれらのサイズを最小にすることです。 また、追加テクニックは、RSCV長さの制限の効果を減少させるのに使用されます。
For an IP connection network, DLC signaling information is required only for the second TG (i.e., from the VRN to the destination node); the signaling information for the first TG is locally defined at the origin node. For this reason, the topology database does not include DLC signaling information for the entry describing a connection network TG from a network node to a VRN. The DLC signaling information is included in the allied entry for the TG in the opposite direction. This mechanism cannot be used for a connection network TG between a VRN and an end node. However, a node implementing IP connection networks does not include IP signaling information for the first connection network TG when constructing an RSCV.
IP接続ネットワークにおいて、DLCシグナリング情報が第2TG(すなわち、VRNから目的地ノードまでの)にだけ必要です。 最初のTGのためのシグナリング情報は起源ノードで局所的に定義されます。 この理由で、トポロジーデータベースはネットワーク・ノードからVRNまでの接続ネットワークTGについて説明するエントリーのためのDLCシグナリング情報を含んでいません。 DLCシグナリング情報はTGのための同盟したエントリーで逆方向に含められています。 VRNとエンドノードとの接続ネットワークTGにこのメカニズムを使用できません。 しかしながら、IP接続ネットワークを実行するノードはRSCVを組み立てるとき最初の接続ネットワークTGのために情報に合図するIPを含んでいません。
In an environment where APPN network nodes are used to route between legacy LANs and wide-area IP networks, it is recommended that customers not define connection network TGs between these network nodes and VRNs representing legacy LANs. Typically, defined links are required between end nodes on the legacy LANs and such network nodes which also act as network node servers for the end nodes. These defined links can be used for user traffic as well as control traffic. This technique will reduce the number of connection network hops in RSCVs between end nodes on different legacy LANs.
APPNネットワーク・ノードが遺産LANと広い領域IPの間でネットワークを発送するのに使用される環境で、顧客が遺産LANを表しながらこれらのネットワーク・ノードとVRNsの間で接続ネットワークTGsを定義しないのは、お勧めです。 定義されたリンクが遺産LANとエンドノードのためにノードサーバをネットワークでつなぐようなまた、行動するネットワーク・ノードの上でエンドノードの間で通常、必要です。 コントロール交通と同様にユーザ交通にこれらの定義されたリンクを使用できます。 このテクニックは異なった遺産LANでエンドノードの間のRSCVsの接続ネットワークホップの数を減少させるでしょう。
Dudley Informational [Page 25] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[25ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
Lastly, for environments where RSCVs are still not able to include enough hops, extended border nodes (EBNs) can be used to partition the network. In this case, the EBNs will also provide piecewise subnet route calculation and RSCV swapping. Thus, the entire route does not need to be described in a single RSCV with its length limitation.
最後に、RSCVsがまだ十分なホップを含むことができない環境において、ネットワークを仕切るのに、敷衍された境界ノード(EBNs)を使用できます。 また、この場合、EBNsは断片サブネットルート計算とRSCVスワッピングを提供するでしょう。 したがって、独身のRSCVで長さの制限で全体のルートは説明される必要はありません。
2.5.3 XID Changes
2.5.3 XID変化
Packets transmitted over IP networks are lost or arrive out of order more often than packets transmitted over other "link" technologies. As a result, the following problem with the XID3 negotiation protocol was exposed:
IPネットワークの上に伝えられたパケットは、無くなるか、または他の「リンク」技術の上に伝えられたパケットよりしばしば故障していた状態で到着します。 その結果、XID3交渉プロトコルに関する以下の問題は露出されました:
--------------------------------------------------------------------
--------------------------------------------------------------------
*---------------------------------*
|Node A Node B|
*---------------------------------*
o
o
o
XID3 (np, NEG)
o<-------------------------o
|XID3 (np, SEC)
*------------------------->o
XID3 (np, PRI)|
lost<-----------*
*---------------------------------* |ノードはノードBです。| *---------------------------------* o o o XID3(Np、NEG)o<。-------------------------o |XID3(Np、SEC)*------------------------->o XID3(Np、PRI)| 無くなっている<。-----------*
time out
XID3 (np, SEC)
o------------------------->o
SETMODE |
o<-------------------------*
fail because never
received XID3 (np, PRI)
タイムアウトXID3(Np、SEC)o------------------------->o SETMODE| o<、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--* 決して受け取らないので失敗してください、XID3(Np、PRI)
Notation: np - negotiation proceeding
NEG - negotiable link station role
SEC - secondary link station role
PRI - primary link station role
記法: Np--NEGを続かせる交渉--交渉可能なリンクのステーション役割のSEC--二次リンクステーションの役割のPRI--第一のリンクステーションの役割
--------------------------------------------------------------------
Figure 9. XID3 Protocol Problem
-------------------------------------------------------------------- 図9。 XID3プロトコル問題
In the above sequence, the XID3(np, PRI), which is a link-level response to the received XID3(np, SEC), is lost. Node A times out and resends the XID3(np, SEC) as a link-level command. When Node B
上の系列では、XID3(Np、PRI)は無くなっています。(XID3は容認されたXID3(Np、SEC)へのリンク・レベル応答です)。 そして、ノードA回のアウト、リンク・レベルコマンドとしてXID3(Np、SEC)を再送します。 ノードBです。
Dudley Informational [Page 26] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[26ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
receives this command, it thinks that the XID3(np, PRI) was successfully received by Node A and that the activation XID exchange is complete. As a result, Node B sends SETMODE (SNRM, SABME, or XID_DONE_RQ, depending upon the link type). When Node A receives SETMODE, it fails the link activation because it has not received an XID3(np, PRI) from Node B confirming that Node B does indeed agree to be the primary. Moreover, there are similar problems with incomplete TG number negotiation.
受信、このコマンド、それはXID3(Np、PRI)がNode Aによって首尾よく受け取られて、起動XID交換が完全であると思います。 その結果、Node BはSETMODEを送ります(SNRM、SABME、またはXID_DONE_RQ、リンク型に頼ります)。 Node AがSETMODEを受けるとき、本当に、Node Bが、予備選挙であるのに同意すると確認しながらNode BからXID3(Np、PRI)を受けていないので、それはリンク起動に失敗します。 そのうえ、不完全なTG数の交渉に関する同様の問題があります。
To solve the problems with incomplete role and TG number negotiation, two new indicators are defined in XID3. The problems are solved only if both link stations support these new indicators:
不完全な役割とTG数の交渉に関する問題を解決するために、2つの新しいインディケータがXID3で定義されます。 両方のリンクステーションがこれらの新しいインディケータを支持する場合にだけ、問題は解決されています:
o Negotiation Complete Supported indicator (byte 12 bit 0) -- this
1-bit field indicates whether the Negotiation Complete indicator
is supported. This field is meaningful when the XID exchange
state is negotiation proceeding; otherwise, it is reserved. A
value of 0 means the Negotiation Complete indicator is not
supported; a value of 1 means the indicator is supported.
o 交渉Complete Supportedインディケータ(12ビット0のバイト)--この1ビットの分野は、Negotiation Completeインディケータが支持されるかどうかを示します。 XID交換状態が交渉進行であるときに、この分野は重要です。 さもなければ、それは予約されています。 0の値は、Negotiation Completeインディケータが支持されないことを意味します。 1の値は、インディケータが支持されることを意味します。
o Negotiation Complete indicator (byte 12 bit 1) -- this 1-bit
field is meaningful only when the XID exchange state is
negotiation proceeding, the XID3 is sent by the secondary link
station, and the Negotiation Complete Supported indicator is set
to 1; otherwise, this field is reserved. This field is set to 1
by a secondary link station that supports enhanced XID
negotiation when it considers the activation XID negotiation to
be complete for both link station role and TG number (i.e., it is
ready to receive a SETMODE command from the primary link
station.)
o 交渉Completeインディケータ(12ビット1のバイト)--XID交換状態が交渉進行であるときにだけ、この1ビットの分野は重要です、そして、XID3は二次リンクステーションによって送られます、そして、Negotiation Complete Supportedインディケータは1に設定されます。 さもなければ、この分野は予約されています。 それが、リンクステーションの役割とTG番号の両方に、起動XID交渉が完全であると考えると、この分野は高められたXID交渉を支持する二次リンクステーションによって1に設定されます。(すなわち、それは第一のリンクステーションからSETMODEコマンドを受け取る準備ができています。)
When a primary link station that supports enhanced XID negotiation receives an XID3(np) with both the Negotiation Complete Supported indicator and the Negotiation Complete indicator set to 1, the primary link station will know that it can safely send SETMODE if it also considers the XID negotiation to be complete. The new indicators are used as shown in the following sequence when both the primary and secondary link stations support enhanced XID negotiation.
高められたXID交渉を支持する第一のリンクステーションがNegotiation Complete Supportedインディケータと1に設定されたNegotiation Completeインディケータの両方でXID3(Np)を受けるとき、第一のリンクステーションは、また、XID交渉が完全であると考えるなら安全にSETMODEを送ることができるのを知るでしょう。 第一の、そして、二次のリンクステーションサポートがXID交渉を機能アップしたとき、新しいインディケータは以下の系列で示されるように使用されています。
Dudley Informational [Page 27] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[27ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
--------------------------------------------------------------------
--------------------------------------------------------------------
*----------------------------------*
|Node A Node B |
*----------------------------------*
o
o
o
XID3 (np, NEG, S, ^C)
1 o<--------------------------o
|XID3 (np, SEC, S, ^C)
2 *-------------------------->o
XID3 (np, PRI, S, ^C)|
3 lost <-----------*
*----------------------------------* |ノードはノードBです。| *----------------------------------* o o o XID3(Np、NEG、S、^C)1o<。--------------------------o |XID3(Np、SEC、S、^C)2*-------------------------->o XID3(Np、PRI、S、^C)| 3 無くなっている<。-----------*
time out
XID3 (np, SEC, S, ^C)
4 o-------------------------->o
XID3 (np, PRI, S, ^C)|
5 o<--------------------------*
|XID3 (np, SEC, S, C)
6 *-------------------------->o
SETMODE |
7 o<--------------------------*
タイムアウトXID3(Np、SEC、S、^C)4o-------------------------->o XID3(Np、PRI、S、^C)| 5 o<。--------------------------* |XID3(Np、SEC、S、C)6*-------------------------->o SETMODE| 7 o<。--------------------------*
^S indicates that byte 12 bit 0 is set to 0.
S indicates that byte 12 bit 0 is set to 1.
^C indicates that byte 12 bit 1 is set to 0.
C indicates that byte 12 bit 1 is set to 1.
^Sは、12ビット0のバイトが0に設定されるのを示します。 Sは、12ビット0のバイトが1に設定されるのを示します。 ^Cは、12ビット1のバイトが0に設定されるのを示します。 Cは、12ビット1のバイトが1に設定されるのを示します。
-------------------------------------------------------------------- Figure 10. Enhanced XID Negotiation
-------------------------------------------------------------------- 図10。 高められたXID交渉
When Node B receives the XID in flow 4, it realizes that the Node A does not consider XID negotiation to be complete; as a result, it resends its current XID information in flow 5. When Node A receives this XID, it responds in flow 6 with an XID that indicates XID negotiation is complete. At this point, Node B, acting as the primary link station, sends SETMODE, and the link is activated successfully.
Node Bが流れ4でXIDを受けるとき、完全になるようにNode Aが、XIDが交渉であると考えないとわかります。 その結果、それは流れ5における現在のXID情報を再送します。 Node AがこのXIDを受けるとき、それはXID交渉が完全であることを示すXIDと共に流れ6で応じます。 ここに、第一のリンクステーションとして機能して、Node BはSETMODEを送ります、そして、リンクは首尾よく動きます。
Migration cases with only one link station supporting enhanced XID negotiation are shown in the two following sequences. In the next sequence, only Node A (acting as the secondary link station) supports the new function.
1つのリンクステーションだけが高められたXID交渉を支持している移動ケースは2つの次の系列で見せられます。 次の系列では、Node Aだけ(二次リンクステーションとして、機能します)が新しい機能をサポートします。
Dudley Informational [Page 28] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[28ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
--------------------------------------------------------------------
--------------------------------------------------------------------
*---------------------------------*
|Node A Node B|
*---------------------------------*
o
o
o
XID3 (np, NEG, ^S)
1 o<--------------------------o
|XID3 (np, SEC, S, ^C)
2 *-------------------------->o
XID3 (np, PRI, ^S)|
3 lost <-----------*
*---------------------------------* |ノードはノードBです。| *---------------------------------* o o o XID3(Np、NEG、^S)1o<。--------------------------o |XID3(Np、SEC、S、^C)2*-------------------------->o XID3(Np、PRI、^S)| 3 無くなっている<。-----------*
time out
XID3 (np, SEC, S, ^C)
4 o-------------------------->o
SETMODE |
5 o<--------------------------*
fail
タイムアウトXID3(Np、SEC、S、^C)4o-------------------------->o SETMODE| 5 o<。--------------------------* 失敗してください。
--------------------------------------------------------------------
Figure 11. First Migration Case
-------------------------------------------------------------------- 図11。 最初の移動ケース
The XID negotiation fails because Node B does not understand the new indicators and responds to flow 4 with SETMODE.
Node Bが新しいインディケータを理解しないで、SETMODEと共に流れ4に応じるので、XID交渉は失敗します。
In the next sequence, Node B supports the new indicators but Node A does not.
次の系列では、Node Bは新しいインディケータを支持しますが、Node Aは支持するというわけではありません。
Dudley Informational [Page 29] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[29ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
--------------------------------------------------------------------
--------------------------------------------------------------------
*---------------------------------*
|Node A Node B|
*---------------------------------*
o
o
o
XID3 (np, NEG, S, ^C)
1 o<--------------------------o
|XID3 (np, SEC, ^S)
2 *-------------------------->o
XID3 (np, PRI, S, ^C)|
3 lost <-----------*
*---------------------------------* |ノードはノードBです。| *---------------------------------* o o o XID3(Np、NEG、S、^C)1o<。--------------------------o |XID3(Np、SEC、^S)2*-------------------------->o XID3(Np、PRI、S、^C)| 3 無くなっている<。-----------*
time out
XID3 (np, SEC, ^S)
4 o-------------------------->o
SETMODE |
5 o<--------------------------*
fail
タイムアウトXID3(Np、SEC、^S)4o-------------------------->o SETMODE| 5 o<。--------------------------* 失敗してください。
------------------------------------------------------------------------
Figure 12. Second Migration Case
------------------------------------------------------------------------ 図12。 第2移動ケース
The XID negotiation fails because Nobe A does not understand the new indicators and thus cannot indicate that it thinks XID negotiation is not complete in flow 4. Node B understands that the secondary link station (node A) does not support the new indicators and respond with SETMODE in flow 5.
Nobe Aが、新しいインディケータを理解しないで、その結果、XID交渉が流れ4で完全でないと思うのを示すことができないので、XID交渉は失敗します。 ノードBは、二次リンクステーション(ノードA)が新しいインディケータを支持して、SETMODEと共に流れ5で応じないのを理解しています。
Products that support HPR/IP links are required to support enhanced XID negotiation. Moreover, it is recommended that products implementing this solution for HPR/IP links also support it for other link types.
サポートHPR/IPリンクが支えていなければならない製品はXID交渉を機能アップしました。 そのうえ、また、HPR/IPリンクのこのソリューションを実現する製品が他のリンク型のためにそれを支持するのは、お勧めです。
2.5.4 Unsuccessful IP Link Activation
2.5.4 失敗のIPリンク起動
Link activation may fail for several different reasons. When link activation over a connection network or of an auto-activatable link is attempted upon receiving ACTIVATE_ROUTE from SS, activation failure is reported with ACTIVATE_ROUTE_RSP containing sense data explaining the cause of failure. Likewise, when activation fails for other regular defined links, the failure is reported with START_LS(RSP) containing sense data.
リンク起動はいくつかの異なった理由で失敗するかもしれません。 SSからACTIVATE_ROUTEを受けるとき接続ネットワークか自動活性化可能なリンクのリンク起動が試みられるとき、ACTIVATE_ROUTE_RSPが失敗の原因がわかるセンス・データを含んでいて、起動失敗は報告されます。 同様に、起動が他の通常の定義されたリンクに失敗すると、START_LS(RSP)がセンス・データを含んでいて、失敗は報告されます。
Dudley Informational [Page 30] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[30ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
As is normal for session activation failures, the sense data is also sent to the node that initiated the session. At the APPN-to-HPR boundary, a -RSP(BIND) or an UNBIND with an Extended Sense Data control vector is generated and returned to the primary logical unit (PLU).
また、セッション起動失敗のための標準のように、セッションを開始したノードにセンス・データを送ります。 APPNからHPRへの境界では、-RSP(BIND)かExtended Sense DataコントロールベクトルがあるUNBINDを第一の論理装置(PLU)に発生して、返します。
At an intermediate HPR node, link activation failure can be reported with sense data X'08010000' or X'80020000'. At a node with route- selection responsibility, such failure can be reported with sense data X'80140001'.
中間的HPRノードでは、センス・データX'08010000'かX'80020000'でリンク起動の故障を報告できます。 ルート選択責任があるノードでは、'80140001'というセンス・データXでそのような失敗を報告できます。
The following table contains the sense data for the various causes of link activation failure:
以下のテーブルはリンク起動の故障の様々な原因のためのセンス・データを含んでいます:
Dudley Informational [Page 31] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[31ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
+----------------------------------------------------------------------+ | Table 1 (Page 1 of 2). Native IP DLC Link Activation Failure Sense | | Data | +--------------------------------------------------------+-------------+ | ERROR DESCRIPTION | SENSE DATA | +--------------------------------------------------------+-------------+ | The link specified in the RSCV is not available. | X'08010000' | +--------------------------------------------------------+-------------+ | The limit for null XID responses by a called node was | X'0809003A' | | reached. | | +--------------------------------------------------------+-------------+ | A BIND was received over a subarea link, but the next | X'08400002' | | hop is over a port that supports only HPR links. The | | | receiver does not support this configuration. | | +--------------------------------------------------------+-------------+ | The contents of the DLC Signaling Type (X'91') | X'086B4691' | | subfield of the TG Descriptor (X'46') control vector | | | contained in the RSCV were invalid. | | +--------------------------------------------------------+-------------+ | The contents of the IP Address and Link Service Access | X'086B46A5' | | Point Address (X'A5') subfield of the TG Descriptor | | | (X'46') control vector contained in the RSCV were | | | invalid. | | +--------------------------------------------------------+-------------+ | No DLC Signaling Type (X'91') subfield was found in | X'086D4691' | | the TG Descriptor (X'46') control vector contained in | | | the RSCV. | | +--------------------------------------------------------+-------------+ | No IP Address and Link Service Access Point Address | X'086D46A5' | | (X'A5') subfield was found in the TG Descriptor | | | (X'46') control vector contained in the RSCV. | | +--------------------------------------------------------+-------------+ | Multiple sets of DLC signaling information were found | X'08770019' | | in the TG Descriptor (X'46') control vector contained | | | in the RSCV. IP supports only one set of DLC | | | signaling information. | | +--------------------------------------------------------+-------------+ | Link Definition Error: A link is defined as not | X'08770026' | | supporting HPR, but the port only supports HPR links. | | +--------------------------------------------------------+-------------+ | A called node found no TG Identifier (X'80') subfield | X'088C4680' | | within a TG Descriptor (X'46') control vector in a | | | prenegotiation XID for a defined link in an IP | | | network. | | +--------------------------------------------------------+-------------+
+----------------------------------------------------------------------+ | テーブル1 (1/2ページ。) ネイティブのIP DLCリンク起動失敗感覚| | データ| +--------------------------------------------------------+-------------+ | エラー記述| センス・データ| +--------------------------------------------------------+-------------+ | RSCVで指定されたリンクは利用可能ではありません。 | X'08010000'| +--------------------------------------------------------+-------------+ | 呼ばれたノードによるヌルXID応答のための限界はそうでした。| 'X'0809003A'| | 達せられる。 | | +--------------------------------------------------------+-------------+ | しかし、「副-領域」のリンク、次の上にBINDを受け取りました。| X'08400002'| | HPRリンクだけを支えるポートの上にホップがあります。 The| | | 受信機はこの構成をサポートしません。 | | +--------------------------------------------------------+-------------+ | 'DLC Signaling Typeのコンテンツ、(X91年、'、)| 'X'086B4691'| | 'TG Descriptorの部分体、(X46年、'、)、コントロールベクトル| | | RSCVに含まれているのは、病人でした。 | | +--------------------------------------------------------+-------------+ | IP AddressとLink Service Accessのコンテンツ| 'X'086B46A5'| | 'Addressを指してください、(X'A5、'、)、TG Descriptorの部分体| | | '、(X46年、'、) RSCVに含まれたコントロールベクトルはそうでした。| | | 無効。 | | +--------------------------------------------------------+-------------+ | 'ノーDLC Signaling Type、(X91年、'、)、部分体は見つけられました。| 'X'086D4691'| | 'TG Descriptor、(X46年、'、)、中に含まれたベクトルを制御してください。| | | RSCV。 | | +--------------------------------------------------------+-------------+ | IPアドレスとリンクサービスアクセスポイントアドレスがありません。| 'X'086D46A5'| | '、(X'A5、'、) 部分体はTG Descriptorで見つけられました。| | | '、(X46年、'、) RSCVに含まれたベクトルを制御してください。 | | +--------------------------------------------------------+-------------+ | 複数のセットのDLCシグナリング情報は見つけられました。| X'08770019'| | '、TG Descriptor、(X46年、'、)、コントロールベクトルは含みました。| | | RSCVで。 IPはDLCの1セットだけを支えます。| | | 情報に合図します。 | | +--------------------------------------------------------+-------------+ | 定義誤りをリンクしてください: リンクは定義されます。| X'08770026'| | しかし、HPR、ポートにサポートだけをサポートして、HPRはリンクします。 | | +--------------------------------------------------------+-------------+ | '呼ばれたノードがTG Identifierを全く見つけなかった、(X80年、'、)、部分体| 'X'088C4680'| | '、TG Descriptor、(X46年、'、)、aでベクトルを制御してください。| | | IPにおける定義されたリンクへのprenegotiation XID| | | ネットワークでつなぎます。 | | +--------------------------------------------------------+-------------+
Dudley Informational [Page 32] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[32ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
+----------------------------------------------------------------------+ | Table 1 (Page 2 of 2). Native IP DLC Link Activation Failure Sense | | Data | +--------------------------------------------------------+-------------+ | The XID3 received from the adjacent node does not | X'10160031' | | contain an HPR Capabilities (X'61') control vector. | | | The IP port supports only HPR links. | | +--------------------------------------------------------+-------------+ | The RTP Supported indicator is set to 0 in the HPR | X'10160032' | | Capabilities (X'61') control vector of the XID3 | | | received from the adjacent node. The IP port supports | | | only links to nodes that support RTP. | | +--------------------------------------------------------+-------------+ | The Control Flows over RTP Supported indicator is set | X'10160033' | | to 0 in the HPR Capabilities (X'61') control vector of | | | the XID3 received from the adjacent node. The IP port | | | supports only links to nodes that support control | | | flows over RTP. | | +--------------------------------------------------------+-------------+ | The LDLC Supported indicator is set to 0 in the HPR | X'10160034' | | Capabilities (X'61') control vector of the XID3 | | | received from the adjacent node. The IP port supports | | | only links to nodes that support LDLC. | | +--------------------------------------------------------+-------------+ | The HPR Capabilities (X'61') control vector received | X'10160044' | | in XID3 does not include an IEEE 802.2 LLC (X'80') HPR | | | Capabilities subfield. The subfield is required on an | | | IP link. | | +--------------------------------------------------------+-------------+ | Multiple defined links between a pair of switched | X'10160045' | | ports is not supported by the local node. A link | | | activation request was received for a defined link, | | | but there is an active defined link between the paired | | | switched ports. | | +--------------------------------------------------------+-------------+ | Multiple dynamic links across a connection network | X'10160046' | | between a pair of switched ports is not supported by | | | the local node. A link activation request was | | | received for a dynamic link, but there is an active | | | dynamic link between the paired switched ports across | | | the same connection network. | | +--------------------------------------------------------+-------------+ | Link failure | X'80020000' | +--------------------------------------------------------+-------------+ | Route selection services has determined that no path | X'80140001' | | to the destination node exists for the specified COS. | | +--------------------------------------------------------+-------------+
+----------------------------------------------------------------------+ | テーブル1 (2/2ページ。) ネイティブのIP DLCリンク起動失敗感覚| | データ| +--------------------------------------------------------+-------------+ | 隣接しているノードから受け取られたXID3はそうしません。| X'10160031'| | 'HPR Capabilitiesを含んでください、(X61年、'、)、コントロールベクトル。 | | | IPポートはHPRリンクだけを支えます。 | | +--------------------------------------------------------+-------------+ | RTP SupportedインディケータはHPRの0に設定されます。| X'10160032'| | '能力、(X61年、'、)、XID3のベクトルを制御してください。| | | 隣接しているノードから、受け取られています。 ポートがサポートするIP| | | RTPを支えるノードへのリンクだけ。 | | +--------------------------------------------------------+-------------+ | RTP Supportedインディケータの上のControl Flowsは用意ができています。| X'10160033'| | '0つのコネへのHPR Capabilities、(X61年、'、)、ベクトルを制御します。| | | XID3は隣接しているノードから受信しました。 IPポート| | | ノードへの唯一のリンクがそのサポートコントロールであるとサポートします。| | | RTPの上の流れ。 | | +--------------------------------------------------------+-------------+ | LDLC SupportedインディケータはHPRの0に設定されます。| X'10160034'| | '能力、(X61年、'、)、XID3のベクトルを制御してください。| | | 隣接しているノードから、受け取られています。 ポートがサポートするIP| | | LDLCを支えるノードへのリンクだけ。 | | +--------------------------------------------------------+-------------+ | 'HPR Capabilities、(X61年、'、)、コントロールベクトルは受けました。| X'10160044'| | 'XID3がするコネがIEEE802.2LLCを含んでいない、(X80年、'、)、HPR| | | 能力部分体。 部分体が必要です。| | | IPリンク。 | | +--------------------------------------------------------+-------------+ | 切り換えられることの1組の間の複数の定義されたリンク| X'10160045'| | ポートはローカルのノードによって支えられません。 リンク| | | 起動要求を定義されたリンクに受け取りました。| | | しかし、対にすることの間には、アクティブな定義されたリンクがあります。| | | ポートを切り換えました。 | | +--------------------------------------------------------+-------------+ | 接続ネットワークの向こう側の複数のダイナミックなリンク| X'10160046'| | ポートが支えられない切り換えられることの1組の間で| | | ローカルのノード。 リンク起動要求はそうでした。| | | ダイナミックなリンクに受信しますが、能動態があります。| | | 直径の対にされた切り換えられたポートの間のダイナミックなリンク| | | 同じ接続ネットワーク。 | | +--------------------------------------------------------+-------------+ | リンクの故障| X'80020000'| +--------------------------------------------------------+-------------+ | ルート選択サービスが、いいえを決定した、経路| X'80140001'| | 目的地に、ノードは指定されたCOSのために存在します。 | | +--------------------------------------------------------+-------------+
Dudley Informational [Page 33] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[33ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
2.6 IP Throughput Characteristics
2.6 IPスループットの特性
2.6.1 IP Prioritization
2.6.1 IP優先順位づけ
Typically, IP routers process packets on a first-come-first-served basis; i.e., no packets are given transmission priority. However, some IP routers prioritize packets based on IP precedence (the 3-bit field within the Type of Service byte of the IP header) or UDP port numbers. (With the current plans for IP security, the UDP port numbers are encrypted; as a result, IP routers would not be able to prioritize encrypted traffic based on the UDP port numbers.) HPR will be able to exploit routers that provide priority function.
通常、IPルータは先着順にパケットを処理します。 すなわち、パケットは全くトランスミッション優先しません。 しかしながら、いくつかのIPルータがIP先行(IPヘッダーのServiceバイトのTypeの中の3ビットの分野)かUDPポートナンバーに基づくパケットを最優先させます。 (IPセキュリティのための現在のプランで、UDPポートナンバーは暗号化されています; その結果、IPルータはUDPポートナンバーに基づく暗号化されたトラフィックを最優先させることができないでしょう。) HPRは優先権機能を提供するルータを利用できるでしょう。
The 5 UDP port numbers, 12000-12004 (decimal), have been assigned by the Internet Assigned Number Authority (IANA). Four of these port numbers are used for ANR-routed network layer packets (NLPs) and correspond to the APPN transmission priorities (network, 12001; high, 12002; medium, 12003; and low, 12004), and one port number (12000) is used for a set of LLC commands (i.e., XID, TEST, DISC, and DM) and function-routed NLPs (i.e., XID_DONE_RQ and XID_DONE_RSP). These port numbers are used for "listening" and are also used in the destination port number field of the UDP header of transmitted packets. The source port number field of the UDP header can be set either to one of these port numbers or to an ephemeral port number.
5つのUDPポートナンバー(12000-12004(小数))がISOCの機関の一つで(IANA)によって割り当てられました。 これらの4つのポートナンバーが、ANRによって発送されたネットワーク層パケット(NLPs)に使用されて、APPNトランスミッションプライオリティ(ネットワーク、12001; 高値、12002; 媒体、12003、および安値、12004)に対応しています、そして、1つのポートナンバー(12000)がLLCコマンド(すなわち、XID、TEST、DISC、およびDM)と機能で発送されたNLPs(すなわち、XID_DONE_RQとXID_DONE_RSP)の1セットに使用されます。 これらのポートナンバーは、「聴取」に使用されて、また、伝えられたパケットのUDPヘッダーの仕向港ナンバーフィールドに使用されます。 これらのポートナンバーの1つ、または、エフェメラルポート番号にUDPヘッダーのソースポートナンバーフィールドを設定できます。
The IP precedence for each transmission priority and for the set of LLC commands (including function-routed NLPs) are configurable. The implicit assumption is that the precedence value is associated with priority queueing and not with bandwidth allocation; however, bandwidth allocation policies can be administered by matching on the precedence field. The default mapping to IP precedence is shown in the following table:
それぞれのトランスミッション優先権とLLCコマンドのセットのためのIP先行(機能で発送されたNLPsを含んでいる)は構成可能です。 暗黙の仮定は先行値が帯域幅配分ではなく、優先権待ち行列に関連しているということです。 しかしながら、先行フィールドで合っていることによって、帯域幅配分方針を管理できます。 先行をIPに写像するデフォルトは以下のテーブルに示されます:
Dudley Informational [Page 34] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[34ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
+---------------------------------------------+ | Table 2. Default IP Precedence Settings | +----------------------+----------------------+ | PRIORITY | PRECEDENCE | +----------------------+----------------------+ | LLC commands and | 110 | | function-routed NLPs | | +----------------------+----------------------+ | Network | 110 | +----------------------+----------------------+ | High | 100 | +----------------------+----------------------+ | Medium | 010 | +----------------------+----------------------+ | Low | 001 | +----------------------+----------------------+
+---------------------------------------------+ | 2を見送ってください。 デフォルトIP先行設定| +----------------------+----------------------+ | 優先権| 先行| +----------------------+----------------------+ | そしてLLCが命令する。| 110 | | 機能で発送されたNLPs| | +----------------------+----------------------+ | ネットワーク| 110 | +----------------------+----------------------+ | 高値| 100 | +----------------------+----------------------+ | 媒体| 010 | +----------------------+----------------------+ | 安値| 001 | +----------------------+----------------------+
As an example, with this default mapping, telnet, interactive ftp, and business-use web traffic could be mapped to a precedence value of 011, and batch ftp could be mapped to a value of 000.
例として、このデフォルトマッピングで、telnet、インタラクティブftp、および業務用ウェブ・トラフィックを011の先行値に写像できました、そして、バッチftpを000の値に写像できました。
These settings were devised based on the AIW's understanding of the intended use of IP precedence. The use of IP precedence will be modified appropriately if the IETF standardizes its use differently. The other fields in the IP TOS byte are not used and should be set to 0.
これらの設定はAIWのIP先行の意図している使用の理解に基づいて工夫されました。 IETFが使用を異なって標準化すると、IP先行の使用は適切に変更されるでしょう。 IP TOSバイトにおける他の分野は、使用されていなくて、0に設定されるべきです。
For outgoing ANR-routed NLPs, the destination (and optionally the source) UDP port numbers and IP precedence are set based on the transmission priority specified in the HPR network header.
そして、出発しているANRによって発送されたNLPs、目的地、(任意に、ソース) UDPポートナンバーとIP先行はHPRネットワークヘッダーで指定されたトランスミッション優先権に基づいて設定されます。
It is expected that the native IP DLC architecture described in this document will be used primarily for private campus or wide-area intranets where the customer will be able to configure the routers to honor the transmission priority associated with the UDP port numbers or IP precedence. The architecture can be used to route HPR traffic in the Internet; however, in that environment, routers do not currently provide the priority function, and customers may find the performance unacceptable.
本書では説明された固有のIP DLCアーキテクチャが主として顧客がUDPポートナンバーかIP先行に関連しているトランスミッション優先権を光栄に思うためにルータを構成できる個人的なキャンパスか広い領域イントラネットに使用されると予想されます。 インターネットでHPRトラフィックを発送するのにアーキテクチャを使用できます。 しかしながら、その環境に、ルータは現在優先権機能を前提としません、そして、顧客は性能が容認できないのがわかるかもしれません。
In the future, a form of bandwidth reservation may be possible in IP networks using the Resource ReSerVation Protocol (RSVP), or the differentiated services currently being studied by the Integrated Services working group of the IETF. Bandwidth could be reserved for an HPR/IP link thus insulating the HPR traffic from congestion associated with the traffic of other protocols.
将来、IETFのIntegrated Servicesワーキンググループによって研究されながら、帯域幅の予約のフォームはIPネットワークで現在Resource ReSerVationプロトコル(RSVP)、または差別化されたサービスを利用することで可能であるかもしれません。 その結果他のプロトコルのトラフィックに関連している混雑からHPRトラフィックを隔離するHPR/IPリンクに帯域幅を控えることができました。
Dudley Informational [Page 35] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[35ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
2.6.2 APPN Transmission Priority and COS
2.6.2 APPNトランスミッションの優先権とCOS
APPN transmission priority and class of service (COS) allow APPN TGs to be highly utilized with batch traffic without impacting the performance of response-time sensitive interactive traffic. Furthermore, scheduling algorithms guarantee that lower-priority traffic is not completely blocked. The result is predictable performance.
サービス(COS)のAPPNトランスミッション優先権とクラスは、APPN TGsがバッチトラフィックと共に応答時間の敏感な対話的な通信の性能に影響を与えないで非常に利用されるのを許容します。 その上、スケジューリングアルゴリズムは、低優先度トラフィックが完全に妨げられるというわけではないのを保証します。 結果は予測できる性能です。
When a session is initiated across an APPN network, the session's mode is mapped into a COS and transmission priority. For each COS, APPN has a COS table that is used in the route selection process to select the most appropriate TGs (based on their TG characteristics) for the session to traverse. The TG characteristics and COS tables are defined such that APPN topology and routing services (TRS) will select the appropriate TG for the traffic of each COS.
セッションがAPPNネットワークの向こう側に開始されるとき、セッションのモードはCOSとトランスミッション優先に写像されます。 各COSに関しては、APPNはセッションのための最も適切なTGs(彼らのTGの特性に基づいている)が横断するのを選択するルート選択プロセスで使用されるCOSテーブルを持っています。 TGの特性とCOSテーブルは、APPNトポロジーとルーティングサービス(TRS)がそれぞれのCOSのトラフィックのために適切なTGを選択するように、定義されます。
2.6.3 Default TG Characteristics
2.6.3 デフォルトTGの特性
In Chapter 7 (TRS) of [1], there is a set of SNA-defined TG default profiles. When a TG (connection network or regular) is defined as being of a particular technology (e.g., ethernet or X.25) without specification of the TG's characteristics, parameters from the technology's default profile are used in the TG's topology entry. The customer is free to override these values via configuration. Some technologies have multiple profiles (e.g., ISDN has both a profile for switched and nonswitched.) Two default profiles are required for IP TGs. This many are needed because there are both campus and wide-area IP networks. As a result for each HPR/IP TG, a customer should specify, at minimum, campus or wide area. HPR/IP TGs traversing the Internet should be specified as wide-area links. If no specification is made, a campus network is assumed.
第7章の(TRS)の[1]に、1セットのSNAで定義されたTGデフォルトプロフィールがあります。 TG(接続ネットワークの、または、通常の)がTGの特性の仕様なしで特定の技術(例えば、イーサネットかX.25)の存在と定義されるとき、技術のデフォルトプロフィールからのパラメタはTGのトポロジーエントリーで使用されます。 顧客は構成で自由にこれらの値をくつがえすことができます。 いくつかの技術には複数のプロフィールがある、(切り換えられて、「非-切り換え」られて、例えば、ISDNにaが輪郭を描く両方がある、)。 2個のデフォルトプロフィールがIP TGsに必要です。 両方のキャンパスと広い領域IPネットワークがあるので、この多くが必要です。 その結果、各HPR/IP TGとして、顧客は最小限、キャンパスまたは広い領域で指定するべきです。 広い領域がリンクされるとき、インターネットを横断するHPR/IP TGsは指定されるべきです。 仕様が全く作られないなら、キャンパスネットワークは想定されます。
The 2 IP profiles are as follows:
2個のIPプロフィールは以下の通りです:
+----------------------------------------------------------------------+ | Table 3. IP Default TG Characteristics | +-------------------+---------+----------+---------+---------+---------+ | | Cost | Cost per | Security| Propa- | Effec- | | | per | byte | | gation | tive | | | connect | | | delay | capacity| | | time | | | | | +-------------------+---------+----------+---------+---------+---------+ | Campus | 0 | 0 | X'01' | X'71' | X'75' | +-------------------+---------+----------+---------+---------+---------+ | Wide area | 0 | 0 | X'20' | X'91' | X'43' | +-------------------+---------+----------+---------+---------+---------+
+----------------------------------------------------------------------+ | 3を見送ってください。 IPデフォルトTGの特性| +-------------------+---------+----------+---------+---------+---------+ | | 費用| 費用| セキュリティ| Propa| Effec| | | per| バイト| | gation| tive| | | 接続してください。| | | 遅れ| 容量| | | 時間| | | | | +-------------------+---------+----------+---------+---------+---------+ | キャンパス| 0 | 0 | X'01'| 'X71年'| 'X75年'| +-------------------+---------+----------+---------+---------+---------+ | 広い領域| 0 | 0 | 'X20年'| 'X91年'| 'X43年'| +-------------------+---------+----------+---------+---------+---------+
Dudley Informational [Page 36] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[36ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
Typically, a TG is either considered to be "free" if it is owned or leased or "costly" if it is a switched carrier facility. Free TGs have 0 for both cost parameters, and costly TGs have 128 for both parameters. For campus IP networks, the default for both cost parameters is 0.
通常、TGが「それが切り換えられたキャリヤー施設であるなら所有されているか、賃貸されているか、または高価であるなら、自由である」と考えられます。 自由なTGsは両方のための0にパラメタをかからせます、そして、高価なTGsには、両方のパラメタのための128があります。 キャンパスIPネットワークにおいて、両方の費用パラメタのためのデフォルトは0です。
It is less clear what the defaults should be for wide area. Because a router normally has leased access to an IP network, the defaults for both costs are also 0. This assumes the IP network is not tariffed. However, if the IP network is tariffed, then the customer should set the cost per byte to 0 or 128 depending on whether the tariff contains a component based on quantity of data transmitted, and the customer should set the cost per connect time to 0 or 128 based on whether there is a tariff component based on connect time. Furthermore, for switched access to the IP network, the customer settings for both costs should also reflect the tariff associated with the switched access link.
デフォルトが広い領域への何であるべきであるかがそれほど明確ではありません。 ルータが通常IPネットワークへのアクセスを賃貸したので、また、両方のコストのためのデフォルトは0です。 これは、IPネットワークがtariffedされないと仮定します。 しかしながら、IPネットワークがtariffedされるなら、顧客は関税が送られたデータの量に基づくコンポーネントを含んでいるかどうかによる0か128に1バイトあたりの費用を設定するべきです、そして、関税コンポーネントがあるかどうかに基づいて顧客は接続時間に基づいて1接続時間あたりの費用を0か128に設定するべきです。 その上、また、IPネットワークへの切り換えられたアクセスのために、両方のコストのための顧客設定は切り換えられたアクセスリンクに関連している関税を反映するはずです。
Only architected values (see "Security" in [1]) may be used for a TG's security parameter. The default security value is X'01' (lowest) for campus and X'20' (public switched network; secure in the sense that there is no predetermined route the traffic will take) for wide-area IP networks. The network administrator may override the default value but should, in that case, ensure that an appropriate level of security exists.
値をarchitectedしただけである、([1])の「セキュリティ」がTGのセキュリティパラメタに使用されるかもしれないのを確実にしてください。 'デフォルトセキュリティ価値は広い領域における'キャンパスとX20年の(最も低い)'(公衆交換回線網; ある意味で、トラフィックが取らない予定されたルートを全く固定する)のIPがネットワークでつなぐX'01です。 ネットワーク管理者は、デフォルト値をくつがえすかもしれませんが、その場合適正水準のセキュリティが存在するのを保証するべきです。
For wide area, the value X'91' (packet switched) is the default for propagation delay; this is consistent with other wide-area facilities and indicates that IP packets will experience both terrestrial propagation delay and queueing delay in intermediate routers. This value is suitable for both the Internet and wide-area intranets; however, the customer could use different values to favor intranets over the Internet during route selection. The value X'99' (long) may be appropriate for some international links across the Internet. For campus, the default is X'71' (terrestrial); this setting essentially equates the queueing delay in IP networks with terrestrial propagation delay.
X91年を評価してください。'広い領域に'(切り換えられたパケット)は伝播遅延のためのデフォルトです。 これは、他の広い領域施設と一致していて、IPパケットが地球の伝播遅延と中間的ルータの待ち行列遅れの両方を経験するのを示します。 この値は両方のインターネットと広い領域イントラネットに適しています。 しかしながら、顧客は、ルート選択の間、インターネットよりイントラネットを好むのに異価を使用できました。 いくつかの国際的な関係に、値X'99'(長い)はインターネットの向こう側に適切であるかもしれません。 'キャンパスに関して、デフォルトはX71年(地球の)です'。 この設定は本質的にはIPネットワークの待ち行列遅れを地球の伝播遅延と同一視します。
For wide area, X'43' (56 kbs) is shown as the default effective capacity; this is at the low-end of typical speeds for wide-area IP links. For campus, X'75' (4 Mbs) is the default; this is at the low-end of typical speeds for campus IP links. However, customers should set the effective capacity for both campus and wide area IP links based on the actual physical speed of the access link to the IP network; for regular links, if both the source and destination access speeds are known, customers should set the effective capacity based on the minimum of these two link speeds. If there are multiple access links, the capacity setting should be based on the physical
'広い領域、X43年'(56kbs)はデフォルト有効能力として示されます。 広い領域のIPリンクへの典型的な速度のローエンドにはこれがあります。 'キャンパス、X75年'(4Mbs)はデフォルトです。 キャンパスIPリンクへの典型的な速度のローエンドにはこれがあります。 しかしながら、顧客はキャンパスとIPネットワークへのアクセスリンクの実際の物理的な速度に基づく広い領域のIPリンクの両方に有効能力を設定するべきです。 通常のリンクに、ソースと目的地アクセススピードの両方が知られているなら、顧客はこれらの2つのリンク速度の最小限に基づく有効能力を設定するべきです。 複数のアクセスリンクがあれば、容量設定は物理的に基づくべきです。
Dudley Informational [Page 37] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[37ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
speed of the access link that is expected to be used for the link.
リンクに使用されると予想されるアクセスリンクの速度。
For the encoding technique for effective capacity in the topology database, see "Effective Capacity" in Chapter 7, Topology and Routing Services of [1]. The table in that section can be extended as follows for higher speeds:
トポロジーデータベースの有効能力のためのコード化のテクニックに関しては、[1]の第7章、Topology、およびルート設定Servicesの「有効能力」を見てください。 より高い速度のために以下の通りそのセクションのテーブルを広げることができます:
+----------------------------------------------------------------------+ | Table 4. Calculated Effective Capacity Representations | +-----------------------------------+----------------------------------+ | Link Speed (Approx.) | Effective Capacity | +-----------------------------------+----------------------------------+ | 25M | X'8A' | +-----------------------------------+----------------------------------+ | 45M | X'91' | +-----------------------------------+----------------------------------+ | 100M | X'9A' | +-----------------------------------+----------------------------------+ | 155M | X'A0' | +-----------------------------------+----------------------------------+ | 467M | X'AC' | +-----------------------------------+----------------------------------+ | 622M | X'B0' | +-----------------------------------+----------------------------------+ | 1G | X'B5' | +-----------------------------------+----------------------------------+ | 1.9G | X'BC' | +-----------------------------------+----------------------------------+
+----------------------------------------------------------------------+ | 4を見送ってください。 計算された有効能力表現| +-----------------------------------+----------------------------------+ | リンク速度(Approx.) | 有効能力| +-----------------------------------+----------------------------------+ | 25M| 'X'8A'| +-----------------------------------+----------------------------------+ | 45M| 'X91年'| +-----------------------------------+----------------------------------+ | 100M| 'X'9A'| +-----------------------------------+----------------------------------+ | 155M| X'A0'| +-----------------------------------+----------------------------------+ | 467M| X'AC'| +-----------------------------------+----------------------------------+ | 622M| X'B0'| +-----------------------------------+----------------------------------+ | 1G| X'B5'| +-----------------------------------+----------------------------------+ | 1.9 G| X'BC'| +-----------------------------------+----------------------------------+
2.6.4 SNA-Defined COS Tables
2.6.4 SNAで定義されたCOSテーブル
SNA-defined batch and interactive COS tables are provided in [1]. These tables are enhanced in [2] (see section 18.7.2) for the following reasons:
SNAで定義されたバッチと対話的なCOSテーブルを[1]に提供します。 これらのテーブルは以下の理由で[2]で機能アップされます(セクション18.7.2を見ます):
o To ensure that the tables assign reasonable weights to ATM TGs
relative to each other and other technologies based on cost,
speed, and delay
o テーブルが費用、速度、および遅れに基づく互いと他の技術に比例して妥当な重りをATM TGsに割り当てるのを確実にするために
o To facilitate use of other new higher-speed facilities - This
goal is met by providing several speed groupings above 10 Mbps.
To keep the tables from growing beyond 12 rows, low-speed
groupings are merged.
o 他の新しいより高い速度施設の使用を容易にしてください--この目標は、いくつかの速度組分けを10Mbpsの上に供給することによって、達成されます。 テーブルが12の行を超えて成長するのを妨げるために、低速組分けは合併されています。
Products implementing the native IP DLC should use the new COS tables. Although the effective capacity values in the old tables are sufficient for typical IP speeds, the new tables are valuable because higher-speed links can be used for IP networks.
ネイティブのIP DLCを実装する製品は新しいCOSテーブルを使用するはずです。 古いテーブルの有効能力値は典型的なIP速度に十分ですが、新しいテーブルは、IPネットワークにより高い速度リンクを使用できるので、貴重です。
Dudley Informational [Page 38] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[38ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
2.6.5 Route Setup over HPR/IP links
2.6.5 HPR/IPリンクの上のルートSetup
The Resequence ("REFIFO") indicator is set in Route Setup request and
reply when the RTP path uses a multi-link TG because packets may not
be received in the order sent. The Resequence indicator is also set
when the RTP path includes an HPR/IP link as packets sent over an IP
network may arrive out of order.
Resequence("REFIFO")インディケータはルートセットアップ要求に設定されました、そして、パケットがオーダーに受け取られないかもしれないのでRTP経路がマルチリンクTGを使用するとき、回答は発信しました。 また、IPネットワークの上に送られたパケットが故障していた状態で到着するときRTP経路がHPR/IPリンクを含んでいるとき、Resequenceインディケータは設定されます。
Adaptive rate-based congestion control (ARB) is an HPR Rapid Transport Protocol (RTP) function that controls the data transmission rate over RTP connections. ARB also provides fairness between the RTP traffic streams sharing a link. For ARB to perform these functions in the IP environment, it is necessary to coordinate the ARB parameters with the IP TG characteristics. This is done for IP links in a similar manner to that done for other link types.
適応型のレートベースの輻輳制御(ARB)はRTP接続の上でデータ伝送レートを制御するHPR Rapid Transportプロトコル(RTP)機能です。 また、ARBはリンクを共有するRTPトラフィックストリームの間に公正を提供します。 ARBがIP環境におけるこれらの機能を実行するように、IP TGの特性でARBパラメタを調整するのが必要です。 同じように他のリンク型のために行われたそれへのIPリンクにこれをします。
2.6.6 Access Link Queueing
2.6.6 アクセスリンク待ち行列
Typically, nodes implementing the native IP DLC have an access link to a network of IP routers. These IP routers may be providing prioritization based on UDP port numbers or IP precedence. A node implementing the native IP DLC can be either an IP host or an IP router; in both cases, such nodes should also honor the priorities associated with either the UDP port numbers or the IP precedence when transmitting HPR data over the access link to the IP network.
通常、アクセスはネイティブのIP DLCを実装するノードによってIPルータのネットワークにリンクされます。 これらのIPルータはUDPポートナンバーかIP先行に基づく優先順位づけを提供しているかもしれません。 ネイティブのIP DLCを実装するノードは、IPホストかIPルータのどちらかであるかもしれません。 どちらの場合も、また、IPネットワークへのアクセスリンクの上にHPRデータを送るとき、そのようなノードはUDPポートナンバーかIP先行のどちらかに関連しているプライオリティを光栄に思うはずです。
--------------------------------------------------------------------
--------------------------------------------------------------------
*--------* access link *--------* *--------*
| HPR |-------------| IP |-----| IP |
| node | | Router | | Router |
*--------* *--------* *--------*
| |
| |
| |
*--------* *--------* access link *--------*
| IP |-----| IP |-------------| HPR |
| Router | | Router | | node |
*--------* *--------* *--------*
*--------* アクセスリンク*--------* *--------* | HPR|-------------| IP|-----| IP| | ノード| | ルータ| | ルータ| *--------* *--------* *--------* | | | | | | *--------* *--------* アクセスリンク*--------* | IP|-----| IP|-------------| HPR| | ルータ| | ルータ| | ノード| *--------* *--------* *--------*
--------------------------------------------------------------------
Figure 13. Access Links
-------------------------------------------------------------------- 図13。 アクセスリンク
Otherwise, the priority function in the router network will be negated with the result being HPR interactive traffic delayed by either HPR batch traffic or the traffic of other higher-layer protocols at the access link queues.
さもなければ、ルータネットワークにおける優先権機能はアクセスリンク待ち行列のときに他の上位層プロトコルのHPRバッチトラフィックかトラフィックのどちらかで遅れたHPRの対話的な通信である結果で否定されるでしょう。
Dudley Informational [Page 39] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[39ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
2.7 Port Link Activation Limits
2.7 ポートリンク起動限界
Three parameters are provided by NOF to CS on DEFINE_PORT(RQ) to define the link activation limits for a port: total limit, inbound limit, and outbound limit. The total limit is the desired maximum number of active link stations allowed on the port for both regular TGs and connection network TGs. The inbound limit is the desired number of link stations reserved for connections initiated by adjacent nodes; the purpose of this field is to insure that a minimum number of link stations may be activated by adjacent nodes. The outbound limit is the desired number of link stations reserved for connections initiated by the local node. The sum of the inbound and outbound limits must be less than or equal to the total limit. If the sum is less than the total limit, the difference is the number of link stations that can be activated on a demand basis as either inbound or outbound. These limits should be based on the actual adapter capability and the node's resources (e.g., control blocks).
3つのパラメタがポートのためのリンク起動限界を定義するためにNOFによってDEFINE_PORT(RQ)の上のCSに提供されます: 限界、本国行きの限界、および外国行きの限界を合計してください。 総限界は通常のTGsと接続ネットワークTGsの両方のためのポートの上に許容された必要な最大数の活動的なリンクステーションです。 本国行きの限界は隣接しているノードによって開始された接続のために予約されたリンクステーションの必要な数です。 この分野の目的は最小の数のリンクステーションが隣接しているノードによって動かされるかもしれないのを保障することです。 外国行きの限界はローカルのノードを開始された接続のために予約されたリンクステーションの必要な数です。 本国行きの、そして、外国行きの限界の合計は総より限界以下であるに違いありません。 合計が総限界以下であるなら、違いは本国行きか外国行きとして要求ベースで動かすことができるリンクステーションの数です。 これらの限界は実際のアダプター能力とノードのリソース(例えば、制御ブロック)に基づくべきです。
A connection network TG will be reported to topology as quiescing when its port's total limit threshold is reached; likewise, an inactive auto-activatable regular TG is reported as nonoperational. When the number of active link stations drops far enough below the threshold (e.g., so that at least 20 percent of the original link activation limit has been recovered), connection network TGs are reported as not quiescing, and auto-activatable TGs are reported as operational.
接続ネットワークTGはポートの総限界敷居に達しているときquiescingするとしてトポロジーに報告されるでしょう。 同様に、不活発な自動活性化可能な通常のTGはnonoperationalとして報告されます。 活動的なリンクステーションの数が敷居より下であるまで十分遠くに低下するとき(例えば、元のリンク起動限界の少なくとも20パーセントが回復されたように)、接続ネットワークTGsはquiescingしないとして報告されます、そして、自動活性化可能なTGsは操作上として報告されます。
2.8 Network Management
2.8 ネットワークマネージメント
APPN and HPR management information is defined by the APPN MIB (RFC 2155 [11]) and the HPR MIB (RFC 2238 [13]). In addition, the SNANAU working group of the IETF plans to define an HPR-IP-MIB that will provide HPR/IP-specific management information. In particular, this MIB will provide a mapping of APPN traffic types to IP Type of Service Precedence values, as well as a count of UDP packets sent for each traffic type.
APPNとHPR経営情報がAPPN MIBによって定義される、(RFC2155[11])とHPR MIB、(RFC2238[13])。 さらに、IETFのSNANAUワーキンググループは、IP HPR/特有の経営情報を提供するHPR IP MIBを定義するのを計画しています。 特に、このMIBはAPPNトラフィックタイプに関するマッピングをService Precedence値のIP Typeに供給するでしょう、それぞれのトラフィックタイプのために送られたUDPパケットのカウントと同様に。
There are also rules that must be specified concerning the values an HPR/IP implementation returns for objects in the APPN MIB:
HPR/IP実装がオブジェクトのために返す値に関して指定しなければならない規則もAPPN MIBにあります:
o Several objects in the APPN MIB have the syntax IANAifType. The
value 126, defined as "IP (for APPN HPR in IP networks)" should
be returned by the following three objects when they identify an
HPR/IP link:
o APPN MIBの数個のオブジェクトには、構文IANAifTypeがあります。 値126HPR/IPリンクを特定すると以下の3個のオブジェクトで「IP(IPネットワークにおけるAPPN HPRのための)」を返すべきであると定義されて、
- appnPortDlcType
- appnLsDlcType
- appnLsStatusDlcType
- appnPortDlcType--appnLsDlcType--appnLsStatusDlcType
Dudley Informational [Page 40] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[40ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
o Link-level addresses are reported in the following objects:
o リンク・レベルアドレスは以下のオブジェクトで報告されます:
- appnPortDlcLocalAddr
- appnLsLocalAddr
- appnLsRemoteAddr
- appnLsStatusLocalAddr
- appnLsStatusRemoteAddr
- appnPortDlcLocalAddr--appnLsLocalAddr--appnLsRemoteAddr--appnLsStatusLocalAddr--appnLsStatusRemoteAddr
All of these objects should return ASCII character strings that
represent IP addresses in the usual dotted-decimal format. (At
this point it's not clear what the "usual...format" will be for
IPv6 addresses, but whatever it turns out to be, that is what
these objects will return when an HPR/IP link traverses an IP
network.)
これらのオブジェクトのすべてが普通のドット付き10進法形式でIPアドレスを表すASCII文字列を返すべきです。 (ここに、「普通の…形式」がIPv6アドレスのためになるか何が明確でないか、しかし、何を判明しても、HPR/IPリンクがIPネットワークを横断するとき、それはこれらのオブジェクトが返すものです。)
o The following two objects return Object Identifiers that tie
table entries in the APPN MIB to entries in lower-layer MIBs:
o 以下の2個のオブジェクトが下層MIBsでAPPN MIBのテーブル項目をエントリーにつなぐObject Identifiersを返します:
- appnPortSpecific
- appnLsSpecific
- appnPortSpecific--appnLsSpecific
Both of these objects should return the same value: a RowPointer
to the ifEntry in the agent's ifTable for the physical interface
associated with the local IP address for the port. If the agent
implements the IP-MIB (RFC 2011 [12]), this association between
the IP address and the physical interface will be represented in
the ipNetToMediaTable.
これらのオブジェクトの両方が同じ値を返すべきです: 物理インターフェースへのエージェントのifTableのifEntryへのRowPointerはポートへのローカルアイピーアドレスと交際しました。 エージェントはIP-MIBを実装します。(RFC2011[12])、この協会はipNetToMediaTableでIPアドレスと物理インターフェースの間で代表されるでしょう。
2.9 IPv4-to-IPv6 Migration
2.9 IPv4からIPv6への移行
The native IP DLC is architected to use IP version 4 (IPv4). However, support for IP version 6 (IPv6) may be required in the future.
ネイティブのIP DLCは、IPバージョン4(IPv4)を使用するためにarchitectedされます。 しかしながら、IPバージョン6(IPv6)のサポートが将来、必要であるかもしれません。
IP routers and hosts can interoperate only if both ends use the same version of the IP protocol. However, most IPv6 implementations (routers and hosts) will actually have dual IPv4/IPv6 stacks. IPv4 and IPv6 traffic can share transmission facilities provided that the router/host at each end has a dual stack. IPv4 and IPv6 traffic will coexist on the same infrastructure in most areas. The version number in the IP header is used to map incoming packets to either the IPv4 or IPv6 stack. A dual-stack host which wishes to talk to an IPv4 host will use IPv4.
両端がIPプロトコルの同じバージョンを使用する場合にだけ、IPルータとホストは共同利用できます。 しかしながら、ほとんどのIPv6実装(ルータとホスト)には、実際に、二元的なIPv4/IPv6スタックがあるでしょう。 各端のルータ/ホストにデュアルスタックがあれば、IPv4とIPv6トラフィックは通信施設を共有できます。 IPv4とIPv6トラフィックはほとんどの領域の同じインフラストラクチャに共存するでしょう。 IPヘッダーのバージョン番号は、IPv4かIPv6スタックに入って来るパケットを写像するのに使用されます。 IPv4ホストと話すというそれの願望がIPv4を使用するデュアルスタックホスト。
Hosts which have an IPv4 address can use it as an IPv6 address using a special IPv6 address prefix (i.e., it is an embedded IPv4 address). This mapping was provided mainly for "legacy" application compatibility purposes as such applications don't have the socket
IPv4アドレスを持っているホストは、IPv6アドレスとして特別なIPv6アドレス接頭語を使用することでそれを使用できます(すなわち、それは埋め込まれたIPv4アドレスです)。 そのようなアプリケーションにソケットがないとき、主に「レガシー」アプリケーション互換性目的にこのマッピングを提供しました。
Dudley Informational [Page 41] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[41ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
structures needed to store full IPv6 addresses. Two IPv6 hosts may communicate using IPv6 with embedded-IPv4 addresses.
構造は、完全なIPv6アドレスを保存する必要がありました。 2人のIPv6ホストが、埋め込まれたIPv4アドレスがあるIPv6を使用することで交信するかもしれません。
Both IPv4 and IPv6 addresses can be stored by the domain name service (DNS). When an application queries DNS, it asks for IPv4 addresses, IPv6 addresses, or both. So, it's the application that decides which stack to use based on which addresses it asks for.
ドメイン名サービス(DNS)でIPv4とIPv6アドレスの両方を保存できます。 アプリケーションがDNSについて質問するとき、それはIPv4アドレス、IPv6アドレス、または両方を求めます。 それで、それはそれが求めるどのアドレスに基づいてどのスタックを使用したらよいかを決めるアプリケーションです。
Migration for HPR/IP ports will work as follows:
HPR/IPポートへの移行は以下の通り働くでしょう:
An HPR/IP port is configured to support IPv4, IPv6, or both. If IPv4 is supported, a local IPv4 address is defined; if IPv6 is supported, a local IPv6 address (which can be an embedded IPv4 address) is defined. If both IPv4 and IPv6 are supported, both a local IPv4 address and a local IPv6 address are defined.
HPR/IPポートは、IPv4、IPv6、または両方をサポートするために構成されます。 IPv4がサポートされるなら、ローカルのIPv4アドレスは定義されます。 IPv6がサポートされるなら、ローカルのIPv6アドレス(埋め込まれたIPv4アドレスであるかもしれない)は定義されます。 IPv4とIPv6の両方がサポートされるなら、ローカルのIPv4アドレスとローカルのIPv6アドレスの両方が定義されます。
Defined links will work as follows: If the local node supports IPv4 only, a destination IPv4 address may be defined, or an IP host name may be defined in which case DNS will be queried for an IPv4 address. If the local node supports IPv6 only, a destination IPv6 address may be defined, or an IP host name may be defined in which case DNS will be queried for an IPv6 address. If both IPv4 and IPv6 are supported, a destination IPv4 address may be defined, a destination IPv6 address may be defined, or an IP host name may be defined in which case DNS will be queried for both IPv4 and IPv6 addresses; if provided by DNS, an IPv6 address can be used, and an IPv4 address can be used otherwise.
定義されたリンクは以下の通り働くでしょう: ローカルのノードがIPv4だけを支えるなら、送付先IPv4アドレスが定義されるかもしれませんか、またはどのケースDNSがIPv4アドレスのために質問されるかにIPホスト名は定義されるかもしれません。 ローカルのノードがIPv6だけを支えるなら、送付先IPv6アドレスが定義されるかもしれませんか、またはどのケースDNSがIPv6アドレスのために質問されるかにIPホスト名は定義されるかもしれません。 IPv4とIPv6の両方がサポートされるなら、送付先IPv4アドレスが定義されるかもしれませんか、送付先IPv6アドレスが定義されるかもしれませんか、またはどのケースDNSがIPv4とIPv6アドレスの両方のために質問されるかにIPホスト名は定義されるかもしれません。 DNSによって提供されるなら、IPv6アドレスを使用できます。別の方法で、IPv4アドレスを使用できます。
Separate IPv4 and IPv6 connection networks can be defined. If the local node supports IPv4, it can define a connection network TG to the IPv4 VRN. If the local node supports IPv6, it can define a TG to the IPv6 VRN. If both are supported, TGs can be defined to both VRNs. Therefore, the signaling information received in RSCVs will be compatible with the local node's capabilities unless a configuration error has occurred.
別々のIPv4とIPv6接続ネットワークを定義できます。 ローカルのノードがIPv4を支えるなら、それは接続ネットワークTGをIPv4 VRNと定義できます。 ローカルのノードがIPv6を支えるなら、それはTGをIPv6 VRNと定義できます。 両方がサポートされるなら、両方のVRNsとTGsを定義できます。 したがって、構成誤りが発生していないと、RSCVsに受け取られたシグナリング情報はローカルのノードの能力と互換性があるでしょう。
3.0 References
3.0の参照箇所
[1] IBM, Systems Network Architecture Advanced Peer-to-Peer Networking Architecture Reference, SC30-3442-04. Viewable at URL: http://www.raleigh.ibm.com/cgi-bin/bookmgr/BOOKS/D50L0000/CCONTENTS
[1]IBM、アーキテクチャ参照、SC30-3442-04をネットワークでつなぐシステム・ネットワーク体系の高度なピアツーピア。 URLで見える: http://www.raleigh.ibm.com/cgi-bin/bookmgr/BOOKS/D50L0000/CCONTENTS
[2] IBM, Systems Network Architecture Advanced Peer-to-Peer Networking High Performance Routing Architecture Reference, Version 3.0, SV40-1018-02. Viewable at URL: http://www.raleigh.ibm.com/cgi- bin/bookmgr/BOOKS/D50H6001/CCONTENTS
[2]IBM、高度なシステム・ネットワーク体系のピアツーピアネットワーク高性能ルート設定アーキテクチャ参照、バージョン3.0、SV40-1018-02。 URLで見える: http://www.raleigh.ibm.com/cgi- 容器/bookmgr/本/D50H6001/CCONTENTS
Dudley Informational [Page 42] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[42ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
[3] IBM, Systems Network Architecture Formats, GA27-3136-16. Viewable at URL: http://www.raleigh.ibm.com/cgi- bin/bookmgr/BOOKS/D50A5003/CCONTENTS
[3]IBM、システム・ネットワーク体系形式、GA27-3136-16。 URLで見える: http://www.raleigh.ibm.com/cgi- 容器/bookmgr/本/D50A5003/CCONTENTS
[4] Wells, L. and A. Bartky, "Data Link Switching: Switch-to-Switch Protocol, AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1.0", RFC 1795, April 1995.
[4] ウェルズ、L.、およびA.Bartky、「データは切り換えをリンクします」。 スイッチからスイッチへのプロトコル、AIW DLSwリグ: DLSwはページ、DLSw標準のバージョン1インチ、RFC1795、1995年4月を閉じました。
[5] Bryant, D. and P. Brittain, "APPN Implementers' Workshop Closed Pages Document DLSw v2.0 Enhancements", RFC 2166, June 1997.
[5] ブライアントとD.とP.Brittain、「APPN ImplementersのWorkshop ClosedページDocument DLSw v2.0 Enhancements」、RFC2166 1997年6月。
[6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[6] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[7] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[7] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[8] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[8]Almquist、P.、「インターネットプロトコル群のサービスのタイプ」、RFC1349、1992年7月。
[9] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[9] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[10] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[10] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[11] Clouston, B., and B. Moore, "Definitions of Managed Objects for APPN using SMIv2", RFC 2155, June 1997.
[11] Clouston、B.とB.ムーア、「1997年6月にSMIv2"、RFC2155を使用するAPPNのための管理オブジェクトの定義。」
[12] McCloghrie, K., "SNMPv2 Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996.
[12]McCloghrie、K.、「1996年11月にSMIv2"、RFC2011を使用するインターネットプロトコルのためのSNMPv2管理情報ベース。」
[13] Clouston, B., and B. Moore, "Definitions of Managed Objects for HPR using SMIv2", RFC 2238, November 1997.
[13] Clouston、B.とB.ムーア、「1997年11月にSMIv2"、RFC2238を使用するHPRのための管理オブジェクトの定義。」
4.0 Security Considerations
4.0 セキュリティ問題
For HPR, the IP network appears to be a link. For that reason, the SNA session-level security functions (user authentication, LU authentication, session encryption, etc.) are still available for use. In addition, as HPR traffic flows as UDP datagrams through the IP network, IPsec can be used to provide network-layer security inside the IP network.
HPRに関しては、IPネットワークはリンクであるように見えます。 その理由で、SNAセッションレベルセキュリティ機能(ユーザー認証、LU認証、セッション暗号化など)はまだ使用に利用可能です。 さらに、HPRトラフィックがUDPデータグラムとしてIPネットワークを通して流れるとき、ネットワーク層セキュリティをIPネットワークに提供するのにIPsecを使用できます。
There are firewall considerations when supporting HPR traffic using the native IP DLC. First, the firewall filters can be set to allow the HPR traffic to pass. Traffic can be restricted based on the source and destination IP addresses and the destination port number;
HPRがトラフィックであるとネイティブのIP DLCを使用することでサポートするとき、ファイアウォール問題があります。 まず最初に、ファイアウォールフィルタにHPRトラフィックを終わらせるように設定できます。 トラフィックはソース、送付先IPアドレス、および目的地ポートナンバーに基づいて制限される場合があります。
Dudley Informational [Page 43] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[43ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
the source port number is not relevant. That is, the firewall should accept traffic with the IP addresses of the HPR/IP nodes and with destination port numbers in the range 12000 to 12004. Second, the possibility exists for an attack using forged UDP datagrams; such attacks could cause the RTP connection to fail or even introduce false data on a session. In environments where such attacks are expected, the use of network-layer security is recommended.
ソースポート番号は関連していません。 HPR/IPノードのIPアドレスと目的地ポートナンバーが範囲にある状態で、すなわち、ファイアウォールは12000〜12004にトラフィックを受け入れるはずです。 2番目に、可能性は攻撃のために偽造UDPデータグラムを使用することで存在しています。 そのような攻撃は、RTP接続が失敗するか、またはセッションに関する誤ったデータを紹介するのさえ引き起こす場合がありました。 そのような攻撃が予想される環境で、ネットワーク層セキュリティの使用はお勧めです。
5.0 Author's Address
5.0 作者のアドレス
Gary Dudley C3BA/501 IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709, USA
ゲーリーダドリーC3BA/501IBM社のP.O. Box12195リサーチトライアングル公園、NC 27709、米国
Phone: +1 919-254-4358 Fax: +1 919-254-6243 EMail: dudleyg@us.ibm.com
以下に電話をしてください。 +1 919-254-4358Fax: +1 919-254-6243 メールしてください: dudleyg@us.ibm.com
Dudley Informational [Page 44] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[44ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
6.0 Appendix - Packet Format
6.0付録--パケット・フォーマット
6.1 HPR Use of IP Formats
6.1 IP形式のHPR使用
+----------------------------------------------------------------------+ | 6.1.1 IP Format for LLC Commands and Responses | | | | The formats described here are used for the | | following LLC commands and responses: XID | | command and response, TEST command and response, | | DISC command, and DM response. | +----------------------------------------------------------------------+
+----------------------------------------------------------------------+ | 6.1.1 LLCコマンドと応答のためのIP形式| | | | ここで説明された形式は使用されています。| | 次のLLCコマンドと応答: XID| | コマンド、応答、TESTコマンド、および応答| | DISCコマンド、およびDM応答。 | +----------------------------------------------------------------------+
+----------------------------------------------------------------------+
| IP Format for LLC Commands and Responses |
+-------+-----+--------------------------------------------------------+
| Byte | Bit | Content |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| 0-p | | IP header (see note 1) |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+1- | | UDP header (see note 2) |
| p+8 | | |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+9- | | IEEE 802.2 LLC header (see note 3) |
_____________________
| p+11 | | |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+9 | | DSAP: same as for the base APPN (i.e., X'04' or an |
| | | installation-defined value) |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+10 | | SSAP: same as for the base APPN (i.e., X'04' or an |
| | | installation-defined value) |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+11 | | Control: set as appropriate |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+12-n| | Remainder of PDU: XID3 or TEST information field, or |
| | | null for DISC command and DM response |
+-------+-----+--------------------------------------------------------+
+----------------------------------------------------------------------+ | LLCコマンドと応答のためのIP形式| +-------+-----+--------------------------------------------------------+ | バイト| ビット| 内容| +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | 0-p| | IPヘッダー(注意1を見ます)| +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | p+1、-| | UDPヘッダー(注意2を見ます)| | p+8| | | +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | p+9、-| | IEEE802.2LLCヘッダー(注意3を見ます)| _____________________ | p+11| | | +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | p+9| | DSAP: または、ベースAPPNのような同じこと、(すなわち、X'04'、| | | | インストールで定義された値、)| +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | p+10| | SSAP: または、ベースAPPNのような同じこと、(すなわち、X'04'、| | | | インストールで定義された値、)| +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | p+11| | コントロール: 適宜、セットします。| +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | p+12-n| | PDUの残り: またはXID3かTEST情報フィールド。| | | | DISCコマンドとDM応答のためのヌル| +-------+-----+--------------------------------------------------------+
Dudley Informational [Page 45] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[45ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
+-------+-----+--------------------------------------------------------+ | | | Note 1: Rules for encoding the IP header can be found | | | | in RFC 791. | +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | | | Note 2: Rules for encoding the UDP header can be | | | | found in RFC 768. | +-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+ | | | 注意1: IPヘッダーをコード化するための規則を見つけることができます。| | | | RFC791で。 | +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | | | 注意2: UDPヘッダーをコード化するための規則はそうであることができます。| | | | RFC768では、設立します。 | +-------+-----+--------------------------------------------------------+
+----------------------------------------------------------------------+ | IP Format for LLC Commands and Responses | +-------+-----+--------------------------------------------------------+ | Byte | Bit | Content | +-------+-----+--------------------------------------------------------+
+----------------------------------------------------------------------+ | LLCコマンドと応答のためのIP形式| +-------+-----+--------------------------------------------------------+ | バイト| ビット| 内容| +-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+ | | | Note 3: Rules for encoding the IEEE 802.2 LLC header | | | | can be found in ISO/IEC 8802-2:1994 (ANSI/IEEE Std | | | | 802.2, 1994 Edition), Information technology - | | | | Telecommunications and information exchange between | | | | systems - Local and metropolitan area networks - | | | | Specific requirements - Part 2: Logical Link Control. | +-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+ | | | 注意3: IEEE802.2LLCヘッダーをコード化するための規則| | | | ISO/IEC8802-2:1994(ANSI/IEEE Std| | | | 802.2、1994Edition)、情報技術で見つけることができる、-| | | | テレコミュニケーションと間の情報交換| | | | 地方とシステム--メトロポリタンエリアネットワーク、-| | | | 決められた一定の要求--第2部: 論理的なリンク制御。 | +-------+-----+--------------------------------------------------------+
+----------------------------------------------------------------------+
| 6.1.2 IP Format for NLPs in UI Frames |
| |
| This format is used for either LDLC specific |
| messages or HPR session and control traffic. |
+----------------------------------------------------------------------+
+----------------------------------------------------------------------+
| IP Format for NLPs in UI Frames |
+-------+-----+--------------------------------------------------------+
| Byte | Bit | Content |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| 0-p | | IP header (see note 1) |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+1- | | UDP header (see note 2) |
| p+8 | | |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| p+9- | | IEEE 802.2 LLC header |
_____________________
| p+11 | | |
+-------+-----+--------------------------------------------------------+
+----------------------------------------------------------------------+ | 6.1.2 UIフレームのNLPsのためのIP形式| | | | この形式はLDLCに特定の状態で使用されています。| | メッセージかHPRセッションとコントロールトラフィック。 | +----------------------------------------------------------------------+ +----------------------------------------------------------------------+ | UIフレームのNLPsのためのIP形式| +-------+-----+--------------------------------------------------------+ | バイト| ビット| 内容| +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | 0-p| | IPヘッダー(注意1を見ます)| +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | p+1、-| | UDPヘッダー(注意2を見ます)| | p+8| | | +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | p+9、-| | IEEE802.2LLCヘッダー| _____________________ | p+11| | | +-------+-----+--------------------------------------------------------+
Dudley Informational [Page 46] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[46ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
+-------+-----+--------------------------------------------------------+ | p+9 | | DSAP: the destination SAP obtained from the IEEE | | | | 802.2 LLC (X'80') subfield in the HPR Capabilities | | | | (X'61') control vector in the received XID3 (see note | | | | 3) | +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | p+10 | | SSAP: the source SAP obtained from the IEEE 802.2 LLC | | | | (X'80') subfield in the HPR Capabilities (X'61') | | | | control vector in the sent XID3 (see note 4) | +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | p+11 | | Control: | +-------+-----+-------+------------------------------------------------+ | | | X'03' | UI with P/F bit off | +-------+-----+-------+------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | p+12-n| | Remainder of PDU: NLP | +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | | | Note 1: Rules for encoding the IP header can be found | | | | in RFC 791. | +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | | | Note 2: Rules for encoding the UDP header can be | | | | found in RFC 768. | +-------+-----+--------------------------------------------------------+ +----------------------------------------------------------------------+ | IP Format for NLPs in UI Frames | +-------+-----+--------------------------------------------------------+ | Byte | Bit | Content | +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | | | Note 3: The User-Defined Address bit is considered | | | | part of the DSAP. The Individual/Group bit in the | | | | DSAP field is set to 0 by the sender and ignored by | | | | the receiver. | +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | | | Note 4: The User-Defined Address bit is considered | | | | part of the SSAP. The Command/Response bit in the | | | | SSAP field is set to 0 by the sender and ignored by | | | | the receiver. | +-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+ | p+9| | DSAP: IEEEから得られた目的地SAP| | | | '802.2LLC、(X80年、'、)、HPR Capabilitiesの部分体| | | | '、(X61年、'、) 容認されたXID3(注意| | | | 3を見る)のコントロールベクトル| +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | p+10| | SSAP: IEEE802.2LLCから得られたソースSAP| | | | '、(X80年、'、) 'HPR Capabilitiesの部分体、(X61年、'、)| | | | 送られたXID3(注意4を見る)のコントロールベクトル| +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | p+11| | コントロール: | +-------+-----+-------+------------------------------------------------+ | | | X'03'| P/Fが食いちぎられているUI| +-------+-----+-------+------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | p+12-n| | PDUの残り: NLP| +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | | | 注意1: IPヘッダーをコード化するための規則を見つけることができます。| | | | RFC791で。 | +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | | | 注意2: UDPヘッダーをコード化するための規則はそうであることができます。| | | | RFC768では、設立します。 | +-------+-----+--------------------------------------------------------+ +----------------------------------------------------------------------+ | UIフレームのNLPsのためのIP形式| +-------+-----+--------------------------------------------------------+ | バイト| ビット| 内容| +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | | | 注意3: Userによって定義されたAddressビットは考えられます。| | | | DSAPの一部。 Individual/グループは噛み付きました。| | | | DSAP分野は、送付者によって0に設定されて、無視されます。| | | | 受信機。| +-------+-----+--------------------------------------------------------+ +-------+-----+--------------------------------------------------------+ | | | 注意4: Userによって定義されたAddressビットは考えられます。| | | | SSAPの一部。 Command/応答は噛み付きました。| | | | SSAP分野は、送付者によって0に設定されて、無視されます。| | | | 受信機。| +-------+-----+--------------------------------------------------------+
Dudley Informational [Page 47] RFC 2353 APPN/HPR in IP Networks May 1998
IPにおけるダドリー情報[47ページ]のRFC2353APPN/HPRは1998年5月をネットワークでつなぎます。
7.0 Full Copyright Statement
7.0 完全な著作権宣言文
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(1997)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Dudley Informational [Page 48]
ダドリーInformationalです。[48ページ]
一覧
スポンサーリンク
