[要約] 要約：RFC 2353は、APPN/HPR in IP Networksの実装者向けのワークショップで共有された情報をまとめたものである。 目的：このドキュメントの目的は、APPN/HPRをIPネットワークに実装する際のベストプラクティスや課題についての知識を提供することである。
Network Working Group G. Dudley
Request for Comments: 2353 IBM
Category: Informational May 1998
APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document
APPN / HPR in IP Networks APPN Implementers 'Workshop Closed Pages Document
Status of this 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）The Internet Society（1998）。全著作権所有。
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
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
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）は、高度なピアツーピアネットワーキング（R）（APPN（R））標準およびシステムネットワークアーキテクチャ（SNA）に関連するその他の標準を開発し、促進する業界全体のネットワーキングベンダーのコンソーシアムです。高品質で完全に相互運用可能なAPPNおよびSNAインターネットワーキング製品。 AIWは、1997年12月2日にこのドキュメントのアーキテクチャのクローズドページ（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]で指定されています。高性能ルーティング（HPR）の一連のAPPN拡張機能は、「システムネットワークアーキテクチャの高度なピアツーピアネットワーキング高性能ルーティングアーキテクチャリファレンスバージョン3.0」[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の機能拡張を定義しています。このメモは、APPN接続ネットワークモデルを使用してHPRノードがリンク接続を事前に定義する必要なくIPネットワークを通信に使用できるようにするオプションセットについても説明しています。
(R) 'Advanced Peer-to-Peer Networking' and 'APPN' are trademarks of the IBM Corporation.
（R）「Advanced Peer-to-Peer Networking」および「APPN」は、IBM Corporationの商標です。
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. 論理リンク制御（LLC）の選択などの合意を文書化することにより、IPネットワークでのAPPN製品の相互運用を促進します。
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機能を使用して、RFC 1795 [4]およびRFC 2166 [5]で指定されているデータリンクスイッチング（DLSw）などの既存の統合技術よりも可用性とスケーラビリティの両方を向上させます。
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.
このメモでは、IPおよびUDPの使用を、3つのHPRオプションセット（HPR（オプションセット1400）、Rapid Transport Protocol（RTP）（オプションセット1401）、およびControl Flows overを備えたAPPNノードでサポートできる新しいDLCとして指定していますRTP（オプションセット1402）。論理データリンク制御（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はRTP接続を使用してSNAセッショントラフィックを転送します。 RTPは、信頼性（つまり、選択的な再送信によるエラー回復）、順序どおりの配信（つまり、順不同で到着したデータのシーケンスを変更することで提供される先入れ先出し[FIFO]サービス）、および適応レートベース（ARB ）フロー/輻輳制御。 RTPはこれらの機能をエンドツーエンドで提供するため、接続のパスに沿ったリンクレベルでこれらの機能を使用する必要がなくなります。その結果、HPRの全体的なパフォーマンスが向上します。 RTPの詳細については、[2]の付録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と呼ばれる）を使用すると、IP環境でサービスクラス（COS）やARBフロー/輻輳制御などのAPPN / HPR機能を利用できます。ネイティブIP DLCを介して確立されたHPRリンクは、HPR / IPリンクと呼ばれます。
The following sections describe in detail the considerations and enhancements associated with the native IP DLC.
次のセクションでは、ネイティブIP DLCに関連する考慮事項と拡張機能について詳しく説明します。
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は、RFC 768 [6]で定義されているユーザーデータグラムプロトコル（UDP）とRFC 791 [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.
通常、UDPへのアクセスは、ソケットAPIによって提供されます。 UDPは、IPを使用してノード間でメッセージを転送する、信頼性の低いコネクションレス型配信サービスを提供します。 UDPには、特定のノード内の複数の宛先を区別する機能があり、IPネットワークでポート番号ベースの優先順位付けが可能です。 UDPは、HPRが必要とする機能である破損パケットの検出を提供します。 HPRなどの上位層プロトコルは、メッセージの損失、複製、遅延、順序の乱れた配信、および接続の損失の問題を処理する責任があります。 HPRはRTPを使用してエンドツーエンドのエラー回復と順序どおりの配信を提供するため、UDPで十分です。さらに、LDLCは接続の喪失を検出します。エラー回復など、TCPによって提供される追加のサービスは必要ないため、ネイティブIP DLCには伝送制御プロトコル（TCP）は選択されませんでした。さらに、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宛先ポートは、宛先でデータグラムを逆多重化するために使用されるUDPプロトコルポート番号を含む16ビットのフィールドです。 UDPソースポートは16ビットのフィールドで、UDPプロトコルのポート番号が含まれています。これは、他の情報が利用できない場合に返信を送信するポートを指定します。ゼロ設定は、送信元ポート番号情報が提供されていないことを示します。ネイティブIP DLCで使用する場合、このフィールドは返信用のポート番号の伝達には使用されません。また、ゼロ設定は使用されません。 IANAは、ネイティブIP DLCがこれらの2つのフィールドで使用するポート番号12000から12004を登録しています。これらのポート番号を使用すると、IPネットワークでの優先順位付けが可能になります。これらのフィールドの使用の詳細については、28ページの2.6.1、「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 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.
UDPチェックサムは、UDPヘッダーとユーザーデータをカバーする16ビットのオプションフィールドです。また、送信元と宛先のIPアドレスを含む疑似ヘッダーをカバーします。 UDPチェックサムは、データがそのまま目的の受信者に到着したことを保証するために使用されます。 UDPチェックサムがゼロに設定されている場合は、チェックサムが計算されておらず、受信者がチェックする必要がないことを示しています。チェックサムの使用は、ネイティブ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ヘッダーには、データグラムの処理方法を指定する8ビットのType of Serviceフィールドが含まれています。 RFC 1349 [8]で定義されているように、サービスタイプバイトには2つの定義済みフィールドが含まれています。 3ビットの優先順位フィールドにより、送信者は各データグラムの優先順位を示すことができます。 4ビットのタイプオブサービスフィールドは、ネットワークがスループット、遅延、信頼性、およびコストの間のトレードオフをどのようにすべきかを示します。 8ビットのプロトコルフィールドは、データグラムを作成した上位プロトコルを指定します。ネイティブIP DLCで使用する場合、このフィールドは17に設定され、上位層プロトコルがUDPであることを示します。
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マネージャーは、各ポートのリンクデマルチプレクサーと、IPネットワークで確立された各リンクのLDLCのインスタンスをアクティブ化および非アクティブ化します。複数のリンク（たとえば、1つの定義済みリンクと、接続ネットワークトラフィック用の1つの動的リンク）が、IPアドレスのペア間に確立されます。各リンクは、IPヘッダーのソースおよび宛先IPアドレスと、IEEE 802.2 LLCヘッダーのソースおよび宛先サービスアクセスポイント（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]コマンドの信頼できる配信）。 HPR RTPパケットのエラー回復は、RTPエンドポイント間のプロトコルによって提供されます。
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）は、HPRネットワークヘッダーの自動ネットワークルーティング（ANR）情報を使用して、着信パケットをRTPまたは発信リンクに渡します。
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つ
o LDLC -- 1 per link
o LDLC-リンクごとに1
o Link demultiplexor -- 1 per port
o リンクデマルチプレクサー-ポートごとに1
o NCL -- 1 per node (or 1 per port for efficiency)
o NCL-ノードごとに1つ（または効率化のためにポートごとに1つ）
o RTP -- 1 per RTP connection
o RTP-RTP接続ごとに1
o UDP -- 1 per port
o UDP-ポートごとに1
o IP -- 1 per port
o IP-ポートごとに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.
製品は他の構造を自由に実装できます。他の構造を実装する製品では、このドキュメントに示されているアルゴリズムとプロトコルの境界に適切な変更を加える必要があります。
--------------------------------------------------------------------
-*
*-------------* *-------* |
|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 |
*---------*
--------------------------------------------------------------------
Figure 1. HPR/IP Node Structure
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.
論理データリンク制御（LDLC）は、ネイティブIP DLCによって使用されます。 LDLCは[2]で定義されています。 LDLCは、IEEE 802.2 LLCタイプ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制御フローオプションセット1402）と組み合わせて使用するように定義されました。 IPネットワーク（および基盤となるフレームネットワーク）でのほとんどのフレーム損失は、輻輳が原因であり、ファシリティの問題ではありません。 LDLCがリンクで使用される場合、リンクレベルのエラー回復は利用できません。その結果、RTPトラフィックのみがネイティブIP DLCでサポートされます。 LDLCを使用すると、LLC2とそれに関連するコスト（アダプターストレージ、より長いパス長など）が不要になります。
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はコネクションレスであるため、停止通知を提供しません。その結果、HPR / IPリンクにはLDLC活性が必要です。
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]を参照）で指定されているように実装されている場合、活性プロトコルは次のように機能するため、これは問題ではありません。活性タイマーは単一リンク用です。タイマーは、リンクが最初にアクティブになったとき、および活性テストが正常に完了するたびに開始されます。タイマーが切れると、活性テストが実行されます。リンクが動作している場合、活性テストの間の期間は、活性タイマー期間と往復遅延のオーダーになります。
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.
実装ごとに、活性プロトコルが活性タイマーと再試行タイマーのデフォルト設定で問題なく機能するかどうかを確認する必要があります。たとえば、有効期限が切れた直後に活性タイマーが再起動される場合は、活性タイマーに別のデフォルトを使用する必要があります。
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 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.
o（ノードがHPR / IPポートのペア間の複数のアクティブな定義済みリンクをサポートし、HPR / IPポートのペア間の複数のアクティブな動的リンクをサポートしない限り、必須。）ノードがサポートされていないものとしてHPR / IPリンクのアクティブ化を拒否する場合HPR / IPポートのペア（センスデータX'10160045 'またはX'10160046'）間のパラレルリンクでは、異なるSAPペアを使用している2つのポート間のアクティブリンクで活性を実行する必要があります。したがって、アクティブ化がパラレルリンクではなく、アクティブリンクの1つが失敗したために再アクティブ化された場合、失敗したリンクが検出されます。 （アクティブ化されているリンクのSAPペアがアクティブリンクのSAPペアと一致する場合、隣接ノードがアクティブ化されているリンクに応答するため、活性テストは成功します。）この関数を実装する簡単な方法は、LDLCの受信時にアクティベーションXID。一致するIPアドレスペアと異なる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を受信すると、アクティブリンクを非アクティブ化して再確立できるようにする必要があります。浮遊XIDがアクティブなリンクを非アクティブ化しないようにするには、タイマーが必要です。
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リンクの再アクティブ化を試みる必要があります。このメカニズムは、相手側が以前にリンク障害を検出したが、ネットワークは回復した場合に、セッションのアクティブ化の失敗を防ぐのに役立ちます。
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.
ノード・オペレーター（NO）は、DEFINE_DLC（RQ）（お客様が構成したパラメーターを含む）およびSTART_DLC（RQ）コマンドをノード・オペレーター機能（NOF）に発行することにより、ネイティブIP DLCを作成します。次に、NOFはDEFINE_DLC（RQ）およびSTART_DLC（RQ）信号を構成サービス（CS）に渡し、CSはDLCマネージャーを作成します。次に、ノード・オペレーターは、DEFE_PORT（RQ）（お客様が構成したパラメーターも含む）をNOFに発行して、関連シグナルをCSに渡すことにより、ポートを定義できます。
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アドレスをそのポートに関連付けます。 RFC 1122 [9]では、複数のアダプターを持つノードが、送信に使用されるアダプターに関係なく、発信UDPパケットで同じソースIPアドレスを使用できる必要があります。
*----------------------------------------------*
| 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<-----------------* .
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 [1492-IP、UDP、およびLLCヘッダーの許容値]）
o Maximum send BTU size (default is 1461 [1492 less an allowance for the IP, UDP, and LLC headers])
o 最大送信BTUサイズ（デフォルトは1461 [1492からIP、UDP、およびLLCヘッダーの許容値を差し引いたもの]）
o Link activation limits (total, inbound, and outbound)
o リンクのアクティブ化の制限（合計、受信、送信）
o IPv4 supported (set to yes)
o IPv4をサポート（yesに設定）
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をサポート（noに設定。将来的にはyesに設定される可能性があります。35ページの2.9「IPv4からIPv6への移行」を参照）
o The local IPv6 address (required if IPv6 is supported)
o ローカルIPv6アドレス（IPv6がサポートされている場合は必須）
o Retry count for LDLC (default is 3) 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の再試行カウント（デフォルトは3）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秒。7ページの2.3.1、「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 precedence（XIDなどのLLCコマンドおよび各APPN送信優先順位のIPヘッダーのType of Serviceバイト内の3ビットフィールドの設定。デフォルトは2.6.1、「IP優先順位付け」に示されています。 28ページ）
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）サイズは1461バイトです。これは、トークンリングネットワーク上のルーターがサポートする一般的なIP最大伝送単位（MTU）サイズ1492バイトに対応します。 1461は1492からIPヘッダーの20バイト、UDPヘッダーの8バイト、IEEE 802.2 LLCヘッダーの3バイトを差し引いたものです。オプションのフィールドが含まれている場合、IPヘッダーは20バイトより大きくなります。 IPネットワークでオプションのIPヘッダーフィールドを使用する場合は、より小さい最大BTUサイズを構成する必要があります。 IPv6の場合、デフォルトは1441バイトに削減され、通常のIPv6ヘッダーサイズである40バイトが可能になります。必要に応じて断片化を回避するために、小さい最大BTUサイズ（ただし、768以上）を使用する必要があります。顧客のIPネットワークが十分に大きなIP MTUサイズをサポートしている場合は、パフォーマンスを向上させるために、より大きなBTUサイズを使用する必要があります。最大受信および送信BTUサイズは、DEFINE_PORT（RQ）でCSに渡されます。これらの最大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ヘッダーのフラグフィールドは、フラグメンテーションを許可するように設定する必要があります。一部の製品では、フラグメンテーションを許可するビットの設定を制御できません。その場合、フラグメンテーションはおそらく許可されます。断片化は低速であり、UDPポート番号に基づく優先順位付けを妨げますが、MTUサイズが小さいパス間の接続を可能にします。
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 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.
通常のHPR TGは、ネイティブIP DLCアーキテクチャーを使用してIPネットワークで確立できます。これらの各TGは、1つ以上のHPR / IPリンクで構成されています。構成サービス（CS）は、TGを宛先制御点（CP）名とTG番号で識別します。宛先CP名は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.
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.
HPR / IPポートのペア間の複数の定義済みリンクのサポートはオプションです。現在、ポートのペア間に複数のHPR / IPリンクを定義しても意味がありません。今後、Resource ReSerVation Protocol（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リンクの着信アクティベーションがセンスデータX'10160045 'で拒否されることがあります。アクティベーション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 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.
ポート間のパラレルHPR / IPリンクがサポートされている場合、複数の定義されたリンクステーションが隣接ノードのポートに関連付けられる場合があります。その場合、事前定義されたTG番号（第9章構成サービスの[1]の「TG番号スペースのパーティション化」を参照）を使用して、XIDを特定のリンクステーションにマップできます。ただし、特定のポートのペア間のすべてのHPR / IPリンクに同じTG特性を使用できるため、隣接ノードのポートに関連付けられているすべてのリンクステーションは同等である必要があります。その結果、交渉可能な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.
将来、RSVPを使用してポートのペア間に異なる特性を持つ複数のHPR / IPリンクが定義された場合、定義されたリンクステーションは、着信XIDと照合するために十分な構成情報を必要とします。 （着信XIDと定義されたリンクステーションの正しいマッチングにより、CSはトポロジーおよびルーティングサービス（TRS）に正しいTG特性を提供できます。）その時点で、CSは隣接ノードのIPアドレスと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.
リンクのアクティブ化を開始するノードは、アクティブになっているリンクを認識しています。事前ネゴシエーションXIDで送信される一部のパラメーターは、通常のリンクステーション構成で定義され、次のネゴシエーション処理XIDでは変更できません。 RSVPへの前方移行を可能にするために、IPネットワークで通常のTGがアクティブ化されている場合、最初のXIDを受信するノード（つまり、リンクのアクティブ化を開始していないノード）は、事前交渉XIDを送信する前に、アクティブになっている定義済みのリンクステーションも理解する必要があります。変更できないパラメータを正しく設定するため。このため、リンクのアクティブ化を開始するノードは、TG識別子（X'80 '）サブフィールドを含むTG記述子（X'46'）制御ベクトルを含めることにより、事前交渉XIDでTG番号を示します。さらに、最初のXIDを受信するノードは、リンクをアクティブにするノードに、ヌルXIDを使用してヌルXIDに応答することにより、最初の事前交渉XIDを送信させます。潜在的なデッドロックを防ぐために、最初のXIDを受信するノードには、送信するnull XIDの数に制限があります（LDLC再試行カウントを使用できます）。この制限に達すると、そのノードはヌルXIDに応答してXIDネゴシエーションエラー（X'22 '）制御ベクトルを含むXIDを送信します。センスデータX'0809003A 'は、予期しないヌルXIDを示すために制御ベクトルに含まれています。最初のXIDを受け取ったノードがTG Identifierサブフィールドのない事前交渉XIDを受け取った場合、リンク接続を拒否するためにXID交渉エラー制御ベクトルを持つ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: 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.
通常のTGの場合、TGパラメーターは、DEFINE_PORT（RQ）およびDEFINE_LS（RQ）の顧客構成に基づいてノードオペレーターによって提供されます。 HPR / IPリンクの場合、DEFINE_LS（RQ）で次のパラメーターが提供されます。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 'です。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ネットワーク層パケット（NLP）に使用されるソースサービスアクセスポイントアドレス（SSAP）（デフォルトはX'C8 'です。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 precedence（XIDなどのLLCコマンドのIPヘッダーのType of Serviceバイト内の3ビットフィールドの設定、および各APPN送信優先度。デフォルトは、2.6.1、「IP優先度」に記載されています。 28ページ。このパラメーターは、DEFINE_PORTの設定をオーバーライドするために使用されます）
o Shareable with connection network traffic (default is yes for non-RSVP links)
o 接続ネットワークトラフィックと共有可能（非RSVPリンクのデフォルトはyes）
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 自動アクティブ化をサポート（デフォルトはno、ローカルノードがIPネットワークへのアクセスを切り替えたときにyesに設定される場合があります）
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.
次の図は、通常のTGのアクティブ化と非アクティブ化を示しています。
*------------------------------------------------------------------*
|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----->
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.
図3では、NOFからSTART_LS（RQ）を受信すると、CSはCONNECT_OUT（RQ）をDLCマネージャーに送信することにより、リンクのアクティブ化プロセスを開始します。 DLCマネージャーは、リンクのLDLCのインスタンスを作成し、リンクデマルチプレクサーに通知し、CONNECT_OUT（+ RSP）をCSに送信します。次に、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----->
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.
図4では、新しいリンクのXIDが受信されると、DLCマネージャーに渡されます。 DLCマネージャーはCONNECT_IN（RQ）を送信してCSに着信リンクのアクティブ化を通知し、CSはリンクのアクティブ化を受け入れるCONNECT_IN（+ RSP）を送信します。次に、DLCマネージャーは、LDLCの新しいインスタンスを作成し、リンクデマルチプレクサーに通知し、LDLCを介してXIDをCSに転送します。次に、CSはXIDを隣接ノードに送信して応答します。
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<---------------* . .
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.
図5では、NOFからSTOP_LS（RQ）を受信すると、CSはDEACTを送信して、HPRリンクが非アクティブ化されていることをパートナーノードに通知します。応答を受信すると、CSはDISCONNECT（RQ）をDLCマネージャーに送信し、DLCマネージャーはLDLCのインスタンスを非アクティブ化します。 CSはDISCONNECT（RSP）を受信すると、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<---------------* . .
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.
図6では、隣接ノードがTGを非アクティブ化すると、ローカルノードがDISCを受信します。 CSはSTOP_LS（IND）をNOFに送信します。 IPはコネクションレスであるため、DLCマネージャーはリンクが非アクティブ化されたことを認識しません。そのため、CSは、DISCONNECT（RQ）をDLCマネージャーに送信する必要もあります。 DLCマネージャーは、LDLCのインスタンスを非アクティブ化します。
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ノードでは、限られたリソースのTGは、一定期間トラフィックが検出されないと非アクティブ化されます。さらに、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リンクを限られたリソースとして、また自動アクティブ化可能として定義することをお勧めします。
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ノードを接続するポイントツーポイント回線全体に単一リンクTGを定義します。このモデルの自然な拡張は、LANまたはIPネットワークなどの共有アクセス転送機能（SATF）に接続されたノードの各ペア間にTGを定義することです。ただし、TGのそのようなメッシュのシステム定義の高コストは、数ノードを超えるネットワークでは不可能です。そのため、APPN接続ネットワークモデルは、APPNノード間にTGを確立するために必要なシステム定義を削減するために考案されました。
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.
接続ネットワークの一部ではない他のTGは、SATFを介して定義できます。このようなTG（このドキュメントでは通常のTGと呼ばれます）は、コントロールポイント間のセッション（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に接続された各ノードは、他のすべての接続されたノードに対するTGではなく、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 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.
Topology and Routing Services（TRS）は、ルート選択制御ベクトル（RSCV）の各ノードとVRN間の接続ネットワークTGを含めることにより、セッションが接続ネットワーク上の2つのノード間でルーティングされることを指定します。ネットワークノードにVRNへのTGがある場合、そのTGに関連付けられたネットワークトポロジ情報には、SATFを介してそのノードへの接続を確立するために必要なDLCシグナリング情報が含まれます。エンドノードの場合、DLCシグナリング情報は通常のディレクトリサービス（DS）プロセスの一部として返されます。 TRSには、RSCVの接続ネットワーク全体のTGの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セッションは通常、継続的に継続する必要があるため、ダイナミックリンクステーションを使用する接続ではサポートされません。
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セッションは通常のTG間を流れる必要があるため、接続ネットワークを定義しても、通常のTGを定義する必要がなくなるわけではありません。
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で定義されます（つまり、1つのVRNが定義されます）。相互接続された複数のキャンパスIPネットワークがある環境では、単一の広域接続ネットワークを定義できます。さらに、各キャンパス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への複数のTGをサポートするために、接続ネットワークは次のプロセスによって定義されます。
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に発行し、NOFがDEFINE_CN（RQ）信号を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_CONNECTION_NETWORK_TG（RQ）をNOFに発行し、NOFがDEFINE_CN_TG（RQ）をCSに渡すノードオペレーターによって定義されます。
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 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.
Resource ReSerVation Protocol（RSVP）サポートの実装前は、ポートとVRN間の接続ネットワークTGは1つだけ必要です。その場合、各接続ネットワークのポート構成パラメーターの単一のセットで十分であるため、DEFINE_CN_TG（RQ）信号の製品サポートは必要ありません。 NOF実装がDEFINE_CN_TG（RQ）をサポートしない場合、DEFINE_CN_TG（RQ）の次のセクションにリストされているパラメーターは、代わりにDEFINE_CN（RQ）によって提供されます。さらに、アクティベーションXID上のTG記述子（X'46 '）制御ベクトルの接続ネットワークTG番号（X'81'）サブフィールドは、VRNへの複数の接続ネットワークTGをサポートするためにのみ必要であり、その使用はオプションです。
*-----------------------------------------------------*
| 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<-----------------*
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.
同じ接続ネットワーク上の2つのポート間に既存の動的リンク（つまり、同じVRN CP名を持つ）がある場合、着信動的リンクのアクティブ化はセンスデータX'10160046 'で拒否される可能性があります。ノードが、アクティブダイナミックリンクと同じ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 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.
すべての接続ネットワークが定義されると、ノードオペレーターはSTART_PORT（RQ）を発行し、NOFは関連する信号をCSに渡し、CSはACTIVATE_PORT（RQ）をDLCマネージャーに渡します。 CSは、DLCマネージャーからACTIVATE_PORT（RSP）信号を受信すると、定義された各接続ネットワークTGのTG_UPDATE信号をTRSに送信します。各信号は、VRNへのTGがアクティブ化されたことをTRSに通知し、TGを記述するTGベクトルを含みます。ポートに障害が発生するか、ポートが非アクティブになると、CSはTG_UPDATEを送信して、接続ネットワークTGが動作していないことを示します。ネットワークノードとVRN間のTGに関する情報は、ネットワークトポロジデータベースに保持されます。エンドノードとVRN間のTGに関する情報は、ローカルトポロジデータベースでのみ維持されます。 TRSのトポロジデータベースにVRNのノードエントリがない場合、TRSはそのようなエントリを動的に作成します。 VRNノードエントリは、ネットワークノードがVRNにTGを定義している場合にのみ、ネットワークトポロジデータベースの一部になります。ただし、TRSは、VRNノードエントリがなくても、接続ネットワーク上の2つのエンドノード間の直接パスを選択できます。
*--------------------------------------------------------------------*
| CS TRS DLC DMUX |
*--------------------------------------------------------------------*
. ACTIVATE_PORT(RQ) . create
o--------------------------------------->o----------------->o
. ACTIVATE_PORT(RSP) | .
o<---------------------------------------* .
| TG_UPDATE . . .
*------------------->o . .
. . . .
Figure 8. IP Connection Network Establishment
図8. IP接続ネットワークの確立
The TG vectors for IP connection network TGs include the following information:
IP接続ネットワークTGの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
- 有効容量-接続時間あたりのコスト-送信バイトあたりのコスト-セキュリティ-伝播遅延-ユーザー定義パラメーター
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）
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 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.
接続ネットワークTGの場合、パラメーターはCSによっていくつかの入力を使用して決定されます。ローカル・ポート、接続ネットワーク、またはTGに固有のパラメーターは、システムで定義され、DEFINE_PORT（RQ）、DEFINE_CN（RQ）、またはDEFINE_CN_TG（RQ）で受信されます。 IPアドレスを含む宛先ノードのシグナリング情報は、SSからのACTIVATE_ROUTE要求で受信されます。
The following configuration parameters are received in DEFINE_CN(RQ):
以下の構成パラメーターがDEFINE_CN（RQ）で受け取られます。
o Connection network name (CP name of the VRN)
o 接続ネットワーク名（VRNのCP名）
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 precedence（XIDなどのLLCコマンドのIPヘッダーのType of Serviceバイト内の3ビットフィールドの設定、および各APPN送信優先度。デフォルトは、2.6.1、「IP優先度」に記載されています。 28ページ。このパラメーターは、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 接続ネットワーク名（VRNのCP名）
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特性（30ページの2.6.3、「デフォルト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 限られたリソース（デフォルトはyes）
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の設定をオーバーライドするために使用されます。7ページの2.3.1、「LDLC活性」を参照してください）
o Shareable with other HPR traffic (default is yes for non-RSVP links)
o 他のHPRトラフィックと共有可能（非RSVPリンクのデフォルトはyes）
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:
以下のパラメーターは、接続ネットワークTGの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は、センスデータX'086B46A5 'でアクティブ化の失敗を報告します。）
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）
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セッショントラフィックに使用されます）に多重化されます。 IPネットワーク上に新しいTGを確立するためのXIDフローはなく、新しい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とVRNへの接続ネットワークTGの両方が、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 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.
HPRデータストリーム間でTGを共有できる場合、宛先ノードはXIDを介して通知されます。どちらかの端で、接続ネットワークトラフィックの共有TGを要求するACTIVATE_ROUTEを受信すると、CSは新しいリンクを開始する前に、TGをチェックして、必要な仕様を満たすものがないか確認します。まず、CSはTGペアに対して確立されたリンクを探します。そのようなリンクがない場合、CSは、共有できる通常のTGがあるかどうか、およびそのようなTGが複数存在する場合はどのTGを選択するかを決定します。その結果、同じTGペアを介してルーティングされるRTP接続は実際には異なるリンクを使用し、異なるTGペアを介してルーティングされるRTP接続は同じリンクを使用する場合があります。
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.
ルート選択（X'2B '）制御ベクトル（RSCV）の最大長は255バイトです。接続ネットワークを使用すると、SATF全体の「ホップ」を記述するために必要なRSCVコンテンツのサイズが大幅に増加します。まず、SATFホップを指定するために2つの接続ネットワークTGが使用されるため、2つのTG記述子（X'46 '）制御ベクトルが必要です。さらに、TG Descriptor制御ベクトル内にDLCシグナリング情報を含めると、これらの制御ベクトルの長さが長くなります。その結果、接続ネットワークを通過するRSCVで指定できるホップの総数が減少します。
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シグナリング情報は2番目のTGにのみ必要です（つまり、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を表すVRN間に接続ネットワークTGを定義しないことをお勧めします。通常、レガシーLAN上のエンドノードと、エンドノードのネットワークノードサーバーとしても機能するネットワークノードとの間には、定義されたリンクが必要です。これらの定義されたリンクは、ユーザートラフィックと制御トラフィックに使用できます。この手法は、異なるレガシーLAN上のエンドノード間のRSCVの接続ネットワークホップの数を減らします。
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.
最後に、RSCVに十分なホップを含めることができない環境では、拡張ボーダーノード（EBN）を使用してネットワークを分割できます。この場合、EBNは区分的サブネットルート計算とRSCVスワッピングも提供します。したがって、ルート全体を単一のRSCVで記述する必要はなく、長さの制限があります。
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<-----------*
time out
XID3 (np, SEC)
o------------------------->o
SETMODE |
o<-------------------------*
fail because never
received 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
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 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、SEC）に対するリンクレベルの応答であるXID3（np、PRI）が失われます。ノードAはタイムアウトし、XID3（np、SEC）をリンクレベルのコマンドとして再送信します。ノードBがこのコマンドを受信すると、XID3（np、PRI）がノードAによって正常に受信され、アクティベーションXID交換が完了したと見なされます。その結果、ノードBはSETMODE（リンクタイプに応じて、SNRM、SABME、またはXID_DONE_RQ）を送信します。ノードAがSETMODEを受信すると、ノードBからXID3（np、PRI）を受信していないため、ノードAがリンクアクティベーションに失敗します。さらに、不完全な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 交渉完了サポートインジケーター（バイト12ビット0）-この1ビットのフィールドは、交渉完了インジケーターがサポートされているかどうかを示します。このフィールドは、XID交換状態がネゴシエーション進行中の場合に意味があります。それ以外の場合は予約されています。値0は、交渉完了インジケーターがサポートされていないことを意味します。値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 ネゴシエーション完了インジケーター（バイト12ビット1）-この1ビットフィールドは、XID交換状態がネゴシエーション進行中で、XID3がセカンダリリンクステーションによって送信され、サポートされるネゴシエーション完了インジケーターが1に設定されている場合にのみ意味があります。それ以外の場合、このフィールドは予約されています。このフィールドは、拡張XIDネゴシエーションをサポートするセカンダリリンクステーションによって1に設定されます。これは、アクティベーションXIDネゴシエーションがリンクステーションの役割とTG番号の両方に対して完了したと見なす場合（つまり、プライマリリンクステーションから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ネゴシエーションをサポートするプライマリリンクステーションが、ネゴシエーション完了サポートインジケーターとネゴシエーション完了インジケーターの両方が1に設定されたXID3（np）を受信すると、プライマリリンクステーションは、XIDも考慮する場合、SETMODEを安全に送信できることを認識します。交渉が完了する。新しいインジケーターは、プライマリリンクステーションとセカンダリリンクステーションの両方が拡張XIDネゴシエーションをサポートする場合に、次のシーケンスに示すように使用されます。
--------------------------------------------------------------------
*----------------------------------*
|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 <-----------*
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<--------------------------*
^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
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.
ノードBがフロー4でXIDを受信すると、ノードAはXIDネゴシエーションが完了したと見なさないことに気付きます。その結果、フロー5で現在のXID情報を再送信します。ノードAがこのXIDを受信すると、フロー6でXIDネゴシエーションが完了したことを示すXIDで応答します。この時点で、プライマリリンクステーションとして機能するノード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.
拡張XIDネゴシエーションをサポートするリンクステーションが1つだけの移行ケースを、次の2つのシーケンスで示します。次のシーケンスでは、ノードA（セカンダリリンクステーションとして機能）のみが新しい機能をサポートします。
--------------------------------------------------------------------
*---------------------------------*
|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 <-----------*
time out
XID3 (np, SEC, S, ^C)
4 o-------------------------->o
SETMODE |
5 o<--------------------------*
fail
--------------------------------------------------------------------
Figure 11. First Migration Case
The XID negotiation fails because Node B does not understand the new indicators and responds to flow 4 with SETMODE.
ノードBが新しいインジケーターを理解せず、フロー4にSETMODEで応答するため、XIDネゴシエーションは失敗します。
In the next sequence, Node B supports the new indicators but Node A does not.
次のシーケンスでは、ノードBは新しいインジケーターをサポートしますが、ノードAはサポートしません。
--------------------------------------------------------------------
*---------------------------------*
|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 <-----------*
time out
XID3 (np, SEC, ^S)
4 o-------------------------->o
SETMODE |
5 o<--------------------------*
fail
------------------------------------------------------------------------
Figure 12. Second Migration Case
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は新しいインジケーターを理解せず、フロー4でXIDネゴシエーションが完了していないと判断できないため、XIDネゴシエーションは失敗します。ノードBは、セカンダリリンクステーション（ノードA）が新しいインジケーターをサポートしておらず、フロー5のSETMODE。
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.
拡張XIDネゴシエーションをサポートするには、HPR / IPリンクをサポートする製品が必要です。さらに、HPR / 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）で失敗が報告されます。
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）または拡張センスデータ制御ベクトルを持つ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'で報告される可能性があります。ルート選択責任を持つノードでは、このような障害はセンスデータX'80140001 'で報告されます。
The following table contains the sense data for the various causes of link activation failure:
次の表には、リンクのアクティブ化の失敗のさまざまな原因のセンスデータが含まれています。
+----------------------------------------------------------------------+
| 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. | |
+--------------------------------------------------------+-------------+
+----------------------------------------------------------------------+
| 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. | |
+--------------------------------------------------------+-------------+
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 precedence（IPヘッダーのType of Serviceバイト内の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（10進数）は、Internet Assigned Number Authority（IANA）によって割り当てられています。これらのポート番号のうち4つは、ANRでルーティングされるネットワーク層パケット（NLP）に使用され、APPN送信優先度（ネットワーク、12001、高、12002、中、12003、および低、12004）に対応し、1つのポート番号（12000） LLCコマンドのセット（XID、TEST、DISC、DMなど）と機能ルーティングされたNLP（XID_DONE_RQおよびXID_DONE_RSP）に使用されます。これらのポート番号は「リスニング」に使用され、送信パケットのUDPヘッダーの宛先ポート番号フィールドでも使用されます。 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コマンド（機能ルーティングされたNLPを含む）のIP precedenceは構成可能です。暗黙的な仮定は、優先順位の値が帯域幅の割り当てではなく、優先度のキューイングに関連付けられていることです。ただし、優先順位フィールドを照合することにより、帯域幅割り当てポリシーを管理できます。次の表に、IP precedenceへのデフォルトのマッピングを示します。
+---------------------------------------------+
| Table 2. Default IP Precedence Settings |
+----------------------+----------------------+
| PRIORITY | PRECEDENCE |
+----------------------+----------------------+
| LLC commands and | 110 |
| function-routed NLPs | |
+----------------------+----------------------+
| Network | 110 |
+----------------------+----------------------+
| High | 100 |
+----------------------+----------------------+
| Medium | 010 |
+----------------------+----------------------+
| Low | 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、およびビジネス用のWebトラフィックを優先値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.
これらの設定は、IP precedenceの使用目的に関するAIWの理解に基づいて考案されました。 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でルーティングされるNLPの場合、宛先（およびオプションで送信元）の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 precedenceに関連付けられた送信優先度を尊重するようにルーターを構成できるプライベートキャンパスまたは広域イントラネットで主に使用されることが予想されます。このアーキテクチャは、インターネットで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.
将来的には、Resource ReSerVation Protocol（RSVP）を使用するIPネットワーク、または現在IETFのIntegrated Servicesワーキンググループによって研究されている差別化サービスで、帯域幅予約の形式が可能になる可能性があります。帯域幅をHPR / IPリンク用に予約して、HPRトラフィックを他のプロトコルのトラフィックに関連する輻輳から遮断することができます。
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.
APPN送信優先順位とサービスクラス（COS）により、応答時間に敏感なインタラクティブトラフィックのパフォーマンスに影響を与えることなく、バッチトラフィックでAPPN TGを高度に利用できます。さらに、スケジューリングアルゴリズムは、優先度の低いトラフィックが完全にブロックされないことを保証します。結果は予測可能なパフォーマンスです。
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には、セッションが通過する最も適切なTG（TG特性に基づいて）を選択するためにルート選択プロセスで使用されるCOSテーブルがあります。 TG特性とCOSテーブルは、APPNトポロジとルーティングサービス（TRS）が各COSのトラフィックに適切な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.
[1]の第7章（TRS）には、SNA定義のTGデフォルトプロファイルのセットがあります。 TG（接続ネットワークまたはレギュラー）が、TGの特性を指定せずに特定のテクノロジー（イーサネットやX.25など）のものであると定義されている場合、そのテクノロジーのデフォルトプロファイルのパラメーターがTGのトポロジエントリで使用されます。お客様は、設定を介してこれらの値を自由に上書きできます。一部のテクノロジーには複数のプロファイルがあります（たとえば、ISDNには交換用と非交換用の両方のプロファイルがあります。）IP TGには2つのデフォルトプロファイルが必要です。キャンパスと広域の両方のIPネットワークがあるため、この数が必要です。その結果、HPR / IP TGごとに、顧客は少なくともキャンパスまたは広域を指定する必要があります。インターネットを通過するHPR / IP TGは、広域リンクとして指定する必要があります。指定がない場合は、キャンパスネットワークが想定されます。
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' |
+-------------------+---------+----------+---------+---------+---------+
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は、所有またはリースされている場合は「無料」と見なされ、スイッチドキャリアファシリティの場合は「高額」と見なされます。無料のTGは両方のコストパラメータに対して0を持ち、高価なTGは両方のパラメータに対して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ネットワークが関税を受けていないことを前提としています。ただし、IPネットワークに料金が発生している場合、お客様は、料金に送信データ量に基づくコンポーネントが含まれているかどうかに応じて、バイトあたりのコストを0または128に設定し、接続時間あたりのコストを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.
TGのセキュリティパラメータには、設計された値（[1]の「セキュリティ」を参照）のみを使用できます。デフォルトのセキュリティ値は、キャンパスではX'01 '（最低）、広域IPネットワークではX'20'（パブリックスイッチドネットワーク。トラフィックが通過する事前定義のルートがないという意味で安全）です。ネットワーク管理者はデフォルト値を上書きできますが、その場合、適切なレベルのセキュリティが存在することを確認する必要があります。
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.
広域の場合、値X'91 '（パケット交換）が伝搬遅延のデフォルトです。これは他の広域ファシリティと一貫しており、IPパケットが中間ルーターで地上伝搬遅延とキューイング遅延の両方を経験することを示しています。この値は、インターネットと広域イントラネットの両方に適しています。ただし、顧客は異なる値を使用して、ルートの選択中にインターネットよりもイントラネットを優先することができます。値X'99 '（ロング）は、インターネット上の一部の国際リンクに適している場合があります。キャンパスの場合、デフォルトはX'71 '（地上）です。この設定は基本的に、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 speed of the access link that is expected to be used for the link.
広域の場合、X'43 '（56 kbs）がデフォルトの有効容量として表示されます。これは、広域IPリンクの一般的な速度の下限です。キャンパスでは、X'75 '（4 Mbs）がデフォルトです。これは、キャンパスIPリンクの一般的な速度の下限です。ただし、お客様は、IPネットワークへのアクセスリンクの実際の物理速度に基づいて、キャンパスと広域IPリンクの両方の実効容量を設定する必要があります。通常のリンクの場合、ソースと宛先の両方のアクセス速度がわかっている場合、お客様はこれら2つのリンク速度の最小値に基づいて実効容量を設定する必要があります。複数のアクセスリンクがある場合、容量設定は、リンクに使用されることが予想されるアクセスリンクの物理速度に基づく必要があります。
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章「トポロジとルーティングサービス」の「実効容量」を参照してください。そのセクションの表は、高速化のために次のように拡張できます。
+----------------------------------------------------------------------+
| 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' |
+-----------------------------------+----------------------------------+
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 TGに相互に、および他のテクノロジーに関連して適切な重みを割り当てるようにする
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 他の新しい高速設備の使用を容易にする-この目標は、10 Mbpsを超える複数の速度グループを提供することで満たされます。テーブルが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ネットワークに高速リンクを使用できるため、新しい表は価値があります。
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.
パケットが送信された順序で受信されない可能性があるため、RTPパスがマルチリンクTGを使用すると、Resequence（ "REFIFO"）インジケーターがルートセットアップ要求と応答に設定されます。 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 Protocol（RTP）機能です。 ARBは、リンクを共有するRTPトラフィックストリーム間の公平性も提供します。 ARBがIP環境でこれらの機能を実行するには、ARBパラメータをIP TG特性と調整する必要があります。これは、他のリンクタイプに対して行われるのと同様の方法でIPリンクに対して行われます。
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ルーターのいずれかになります。どちらの場合も、このようなノードは、HPRデータをアクセスリンク経由でIPネットワークに送信するときに、UDPポート番号またはIP precedenceのいずれかに関連付けられた優先順位も尊重する必要があります。
--------------------------------------------------------------------
*--------* access link *--------* *--------*
| HPR |-------------| IP |-----| IP |
| node | | Router | | Router |
*--------* *--------* *--------*
| |
| |
| |
*--------* *--------* access link *--------*
| IP |-----| IP |-------------| HPR |
| Router | | Router | | node |
*--------* *--------* *--------*
--------------------------------------------------------------------
Figure 13. Access Links
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バッチトラフィックまたはアクセスリンクキューの他の上位層プロトコルのトラフィックによって遅延されます。
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).
NOFがDEFINE_PORT（RQ）のCSに提供するパラメーターは、ポートのリンクアクティベーション制限を定義するために提供されます。合計制限、インバウンド制限、アウトバウンド制限です。合計制限は、通常のTGと接続ネットワークTGの両方に対してポートで許可されるアクティブリンクステーションの望ましい最大数です。インバウンド制限は、隣接ノードによって開始された接続用に予約されているリンクステーションの希望数です。このフィールドの目的は、最小数のリンクステーションが隣接ノードによってアクティブ化されることを保証することです。アウトバウンド制限は、ローカルノードによって開始された接続用に予約されているリンクステーションの希望数です。インバウンド制限とアウトバウンド制限の合計は、合計制限以下でなければなりません。合計が制限の合計よりも小さい場合、差は、インバウンドまたはアウトバウンドとしてオンデマンドでアクティブ化できるリンクステーションの数になります。これらの制限は、実際のアダプター機能とノードのリソース（制御ブロックなど）に基づく必要があります。
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は、ポートの合計制限しきい値に達すると、休止状態としてトポロジに報告されます。同様に、非アクティブな自動アクティブ化可能な通常のTGは非動作として報告されます。アクティブなリンクステーションの数がしきい値をはるかに下回ると（たとえば、元のリンクのアクティブ化制限の少なくとも20％が回復したため）、接続ネットワークTGは静止していないと報告され、自動アクティブ化可能なTGは次のように報告されます。運用。
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（RFC 2155 [11]）およびHPR MIB（RFC 2238 [13]）によって定義されます。さらに、IETFのSNANAUワーキンググループは、HPR / IP固有の管理情報を提供するHPR-IP-MIBを定義する予定です。特に、このMIBは、APPNトラフィックタイプのIP Type of Service Precedence値へのマッピング、および各トラフィックタイプに対して送信された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です。 「IP（IPネットワークのAPPN HPRの場合）」として定義されている値126は、次の3つのオブジェクトがHPR / IPリンクを識別するときに返されます。
- appnPortDlcType - appnLsDlcType - appnLsStatusDlcType
- appnPortDlcType-appnLsDlcType-appnLsStatusDlcType
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つのオブジェクトは、APPN MIBのテーブルエントリを下位層MIBのエントリに関連付けるオブジェクト識別子を返します。
- 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.
これらのオブジェクトはどちらも同じ値を返す必要があります。ポートのローカルIPアドレスに関連付けられている物理インターフェースのエージェントのifTableにあるifEntryへのRowPointerです。エージェントがIP-MIB（RFC 2011 [12]）を実装する場合、IPアドレスと物理インターフェース間のこの関連付けは、ipNetToMediaTableで表されます。
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）を使用するように設計されています。ただし、将来的には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 structures needed to store full IPv6 addresses. Two IPv6 hosts may communicate using IPv6 with embedded-IPv4 addresses.
IPv4アドレスを持つホストは、特別なIPv6アドレスプレフィックスを使用してIPv6アドレスとして使用できます（つまり、埋め込まれたIPv4アドレスです）。このようなアプリケーションには完全なIPv6アドレスを格納するために必要なソケット構造がないため、このマッピングは主に「レガシー」アプリケーションの互換性のために提供されました。 2つのIPv6ホストは、IPv6と埋め込みIPv4アドレスを使用して通信できます。
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.
IPv4アドレスとIPv6アドレスの両方をドメインネームサービス（DNS）で保存できます。アプリケーションが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アドレスを定義するか、IPホスト名を定義できます。その場合、DNSはIPv4アドレスを照会されます。ローカルノードがIPv6のみをサポートする場合、宛先IPv6アドレスを定義するか、IPホスト名を定義することができます。その場合、DNSはIPv6アドレスを照会されます。 IPv4とIPv6の両方がサポートされている場合、宛先IPv4アドレスを定義したり、宛先IPv6アドレスを定義したり、IPホスト名を定義したりできます。この場合、IPv4アドレスとIPv6アドレスの両方に対してDNSが照会されます。 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をサポートしている場合は、IPv4 VRNへの接続ネットワークTGを定義できます。ローカルノードがIPv6をサポートしている場合、IPv6 VRNにTGを定義できます。両方がサポートされている場合、TGを両方のVRNに定義できます。したがって、RSCVで受信されたシグナリング情報は、構成エラーが発生していない限り、ローカルノードの機能と互換性があります。
[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
[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
[3] IBM, Systems Network Architecture Formats, GA27-3136-16.
Viewable at URL: http://www.raleigh.ibm.com/cgi-
bin/bookmgr/BOOKS/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] Wells、L。およびA. Bartky、「Data Link Switching：Switch-to-Switch Protocol、AIW DLSw RIG：DLSw Closed Pages、DLSw Standard Version 1.0」、RFC 1795、1995年4月。
[5] Bryant, D. and P. Brittain, "APPN Implementers' Workshop Closed Pages Document DLSw v2.0 Enhancements", RFC 2166, June 1997.
[5] Bryant、D.およびP. Brittain、「APPN Implementers 'Workshop Closed Pages Document DLSw v2.0 Enhancements」、RFC 2166、1997年6月。
[6] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[6] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[7] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[7] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[8] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[8] Almquist、P。、「インターネットプロトコルスイートのサービスタイプ」、RFC 1349、1992年7月。
[9] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[9] ブレーデン、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、1997年9月。
[11] Clouston, B., and B. Moore, "Definitions of Managed Objects for APPN using SMIv2", RFC 2155, June 1997.
[11] Clouston、B。、およびB. Moore、「Definions of Managed Objects for APPN using SMIv2」、RFC 2155、1997年6月。
[12] McCloghrie, K., "SNMPv2 Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996.
[12] McCloghrie、K。、「SNMPv2 Management Information Base for the Internet Protocol using SMIv2」、RFC 2011、1996年11月。
[13] Clouston, B., and B. Moore, "Definitions of Managed Objects for HPR using SMIv2", RFC 2238, November 1997.
[13] Clouston、B。、およびB. Moore、「SMIv2を使用したHPRの管理対象オブジェクトの定義」、RFC 2238、1997年11月。
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トラフィックはIPネットワークを介してUDPデータグラムとして流れるため、IPsecを使用して、IPネットワーク内にネットワーク層のセキュリティを提供できます。
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;
ネイティブIP DLCを使用してHPRトラフィックをサポートする場合、ファイアウォールに関する考慮事項があります。最初に、ファイアウォールフィルターを設定してHPRトラフィックを通過させることができます。トラフィックは、送信元および宛先IPアドレスと宛先ポート番号に基づいて制限できます。
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の範囲の宛先ポート番号を持つトラフィックを受け入れる必要があります。次に、偽造されたUDPデータグラムを使用した攻撃の可能性があります。このような攻撃により、RTP接続が失敗したり、セッションで誤ったデータが導入されたりする可能性があります。このような攻撃が予想される環境では、ネットワーク層セキュリティの使用をお勧めします。
Gary Dudley C3BA/501 IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709, USA
ゲイリーダドリーC3BA / 501 IBM Corporation P.O. Box 12195 Research Triangle Park、NC 27709、USA
Phone: +1 919-254-4358
Fax: +1 919-254-6243
EMail: dudleyg@us.ibm.com
+----------------------------------------------------------------------+
| 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. |
+----------------------------------------------------------------------+
+----------------------------------------------------------------------+
| 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 |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| | | 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 LLC Commands and Responses |
+-------+-----+--------------------------------------------------------+
| Byte | Bit | Content |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| | | 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. |
+-------+-----+--------------------------------------------------------+
+----------------------------------------------------------------------+
| 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 | | |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| 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. |
+-------+-----+--------------------------------------------------------+
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
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.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。