Network Working Group G. Dudley
Request for Comments: 2353 IBM
Category: Informational May 1998
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
IP网络中的APPN/HPR APPN实施者研讨会闭页文档
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.
版权所有（C）互联网协会（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
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
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实施者研讨会（AIW）是一个由网络供应商组成的全行业联盟，负责开发先进的点对点网络（R）（APPN（R））标准和与系统网络体系结构（SNA）相关的其他标准，并促进高质量、完全互操作的APPN和SNA互联产品。1997年12月2日，AIW批准了本文件中架构的闭页（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]中规定。“系统网络体系结构高级对等网络高性能路由体系结构参考，3.0版”[2]中规定了一组用于高性能路由（HPR）的APPN增强功能。“系统网络体系结构格式”[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） “高级对等网络”和“APPN”是IBM公司的商标。
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. 与RFC 1795[4]和RFC 2166[5]中规定的数据链路交换（DLSw）等现有集成技术相比，使用HPR功能可提高可用性和可扩展性。
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作为新的DLC，APPN节点可通过三个HPR选项集支持该DLC：HPR（选项集1400）、快速传输协议（RTP）（选项集1401）和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.
这种新的数据链路连接器（称为本机IP数据链路连接器）允许客户在IP环境中利用APPN/HPR功能，如服务类别（COS）和ARB流量/拥塞控制。通过本机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等高层协议负责处理消息丢失、复制、延迟、无序交付和连接丢失等问题。UDP是足够的，因为HPR使用RTP来提供端到端错误恢复和顺序交付；此外，低密度脂蛋白检测连通性的丧失。未为本机IP DLC选择传输控制协议（TCP），因为不需要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标头有四个双字节字段。UDP目标端口是一个16位字段，其中包含用于在目标处解复用数据报的UDP协议端口号。UDP源端口是一个16位字段，其中包含UDP协议端口号，该端口号指定在其他信息不可用时应向其发送回复的端口。零设置表示未提供源端口号信息。当与本机IP DLC一起使用时，此字段不用于传递回复的端口号；此外，不使用零位设置。IANA已注册端口号12000至12004，以供本机IP DLC在这两个字段中使用；使用这些端口号可以在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
UDP校验和是一个16位可选字段，提供UDP报头和用户数据的覆盖范围；它还提供包含源和目标IP地址的伪报头的覆盖范围。UDP校验和用于确保数据已完整地到达预期接收器。当UDP校验和设置为
zero, it indicates that the checksum was not calculated and should not be checked by the receiver. Use of the checksum is recommended for use with the native IP DLC.
零，表示未计算校验和，接收器不应检查校验和。建议与本机IP DLC一起使用校验和。
IP provides an unreliable, connectionless delivery mechanism. The IP protocol defines the basic unit of data transfer through the IP network, and performs the routing function (i.e., choosing the path over which data will be sent). In addition, IP characterizes how "hosts" and "gateways" should process packets, the circumstances under which error messages are generated, and the conditions under which packets are discarded. An IP version 4 header contains an 8- bit Type of Service field that specifies how the datagram should be handled. As defined in RFC 1349 [8], the type-of-service byte contains two defined fields. The 3-bit precedence field allows senders to indicate the priority of each datagram. The 4-bit type of service field indicates how the network should make tradeoffs between throughput, delay, reliability, and cost. The 8-bit Protocol field specifies which higher-level protocol created the datagram. When used with the native IP DLC, this field is set to 17 which indicates the higher-layer protocol is UDP.
IP提供了一种不可靠、无连接的传递机制。IP协议定义了通过IP网络进行数据传输的基本单元，并执行路由功能（即选择发送数据的路径）。此外，IP描述了“主机”和“网关”应如何处理数据包、生成错误消息的环境以及丢弃数据包的条件。IPVersion4报头包含一个8位类型的服务字段，用于指定应如何处理数据报。如RFC 1349[8]中所定义，服务字节的类型包含两个定义的字段。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数据链路包括一个数据链路管理器、每个链路一个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实例。可以在一对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还提供其他功能（例如，交换标识[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 低密度脂蛋白胆固醇——每链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 |
*---------*
-*
*-------------* *-------* |
|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
--------------------------------------------------------------------
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使用。低密度脂蛋白胆固醇的定义见[2]。LDLC使用IEEE 802.2 LLC类型2（LLC2）定义的服务子集。LDLC仅使用测试、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选项集1402的HPR控制流）结合使用。IP网络（以及底层帧网络）中的大多数帧丢失都是由于拥塞造成的，而不是设备问题。在链路上使用LDLC时，没有链路级错误恢复可用；因此，本机IP DLC只支持RTP通信。使用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测试命令和响应）。因为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的一些实现将允许为活动计时器设置一个较大的值，从而减少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 如果意识到链路故障的节点尝试重新激活链路，则伙伴节点（不知道链路故障）可能会拒绝激活，因为这是两个端口之间不受支持的并行链路。
o If a node that is unaware of an earlier link failure sends data (including new session activations) on the link, it may be discarded by a node that detected the earlier failure and deactivated the link. As a result, session activations would fail.
o 如果不知道早期链路故障的节点在链路上发送数据（包括新会话激活），则检测到早期故障并停用链路的节点可能会丢弃该数据。因此，会话激活将失败。
The mechanisms described below can be used to remedy these problems. These mechanisms are needed only in a node not sending liveness when the link is idle; thus, they would not be required of a node not implementing this option that just happened to be adjacent to a node implementing the option.
下面描述的机制可用于解决这些问题。只有在链路空闲时不发送活跃度的节点中才需要这些机制；因此，不实现此选项的节点恰好与实现该选项的节点相邻，因此不需要它们。
o (Mandatory unless the node supports multiple active defined links between a pair of HPR/IP ports and supports multiple active dynamic links between a pair of HPR/IP ports.) Anytime a node rejects the activation of an HPR/IP link as an unsupported parallel link between a pair of HPR/IP ports (sense data X'10160045' or X'10160046'), it should perform liveness on any active link between the two ports that is using a different SAP pair. Thus, if the activation was not for a parallel link but rather was a reactivation because one of these active links had failed, the failed link will be detected. (If the SAP pair for the link being activated matches the SAP pair for an active link, a liveness test would succeed because the adjacent node would
o （除非节点支持一对HPR/IP端口之间的多个活动定义链路，并支持一对HPR/IP端口之间的多个活动动态链路，否则为必填项。）只要节点拒绝将HPR/IP链路激活为一对HPR/IP端口之间不受支持的并行链路（检测数据X'10160045'或X'10160046'），它应该在使用不同SAP对的两个端口之间的任何活动链路上执行活动性。因此，如果激活不是针对并行链路，而是因为其中一个活动链路发生故障而重新激活，则会检测到故障链路。（如果正在激活的链路的SAP对与活动链路的SAP对匹配，则活跃度测试将成功，因为相邻节点将
respond for the link being activated.) A simple way to implement this function is for LDLC, upon receiving an activation XID, to run liveness on all active links with a matching IP address pair and a different SAP pair.
响应正在激活的链接。）实现此功能的一个简单方法是，LDLC在收到激活XID后，在所有具有匹配IP地址对和不同SAP对的活动链接上运行liveness。
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对匹配活动链路的IP地址对和SAP对的激活XID时，它都应该停用活动链路并允许重新建立它。需要一个定时器来防止杂散的XIDs停用活动链路。
o (Recommended) A node should attempt to reactivate an HPR/IP link before acting on an LDLC-detected failure. This mechanism is helpful in preventing session activation failures in scenarios where the other side detected a link failure earlier, but the network has recovered.
o （建议）节点在对LDLC检测到的故障采取行动之前，应尝试重新激活HPR/IP链路。在另一方先前检测到链路故障，但网络已恢复的情况下，此机制有助于防止会话激活失败。
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）通过向节点操作员设施（NOF）发出DEFINE_DLC（RQ）（包含客户配置的参数）和START_DLC（RQ）命令来创建本机IP DLC。NOF依次将DEFINE_DLC（RQ）和START_DLC（RQ）信号传递给配置服务（CS），CS创建DLC管理器。然后，节点操作员可以通过向NOF发出define_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<-----------------* .
*----------------------------------------------*
| 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_端口（RQ）中接收以下参数：
o Port name
o 端口名
o DLC name
o 数据链路连接器名称
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（设置为是）
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（设置为否；将来可能设置为是；请参阅第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 LDLC的重试计数（默认值为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的重试计时器周期（默认值为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优先级（LLC命令（如XID）和每个APPN传输优先级的IP报头服务字节类型内的3位字段设置；默认值在第28页的2.6.1“IP优先级”中给出。）
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_端口（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
可以使用本机IP DLC体系结构在IP网络中建立常规HPR TG。每个TGs都由一个或多个HPR/IP链路组成。配置服务（CS）用目的地控制点（CP）名称和TG编号标识TG；目的地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.
可通过XID配置或学习名称，可通过XID协商配置的TG编号。对于自动激活链路，必须配置目标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）地址对将传入数据包映射到其关联链路。如果一个节点接收到一个定义的链路的激活XID，该链路的IP地址对和SAP对与活动定义的链路相同，则该节点可以假定该链路已发生故障，并且伙伴节点正在重新激活该链路。在这种情况下，作为优化，接收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链路目前没有任何价值。将来，如果定义了对资源预留协议（RSVP）[10]的HPR/IP支持，则定义此类并行链路以隔离RSVP“会话”上的COS流量可能是有利的。使用RSVP，HPR将能够在IP网络中预留带宽。HPR逻辑链路将映射到RSVP“会话”，该会话可能由特定应用程序提供的UDP端口号或动态分配的UDP端口号标识。
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链路，则可能会使用检测数据X“10160045”拒绝已定义HPR/IP链路的传入激活。如果激活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中的源IP地址，将传入激活XID映射到与相邻节点上的端口关联的已定义链路站（如果存在）。此源IP地址应与与匹配的已定义链路站关联的目标IP地址相同。（如果相邻节点具有多个IP地址，并且配置未正确协调，则它们可能不同。）
If parallel HPR/IP links between ports are supported, multiple defined link stations may be associated with the port on the adjacent node. In that case, predefined TG numbers (see "Partitioning the TG
如果支持端口之间的并行HPR/IP链路，则多个定义的链路站可能与相邻节点上的端口相关联。在这种情况下，预定义的TG编号（参见“TG分区
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.
[1]第9章配置服务中的“数字空间”)可用于将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地址和预定义的TG号进行映射。
The node initiating link activation knows which link it is activating. Some parameters sent in prenegotiation XID are defined in the regular link station configuration and not allowed to change in following negotiation-proceeding XIDs. To allow for forward migration to RSVP, when a regular TG is activated in an IP network, the node receiving the first XID (i.e., the node not initiating link activation) must also understand which defined link station is being activated before sending a prenegotiation XID in order to correctly set parameters that cannot change. For this reason, the node initiating link activation will indicate the TG number in prenegotiation XIDs by including a TG Descriptor (X'46') control vector containing a TG Identifier (X'80') subfield. Furthermore, the node receiving the first XID will force the node activating the link to send the first prenegotiation XID by responding to null XIDs with null XIDs. To prevent potential deadlocks, the node receiving the first XID has a limit (the LDLC retry count can be used) on the number of null XIDs it will send. Once this limit is reached, that node will send an XID with an XID Negotiation Error (X'22') control vector in response to a null XID; sense data X'0809003A' is included in the control vector to indicate unexpected null XID. If the node that received the first XID receives a prenegotiation XID without the TG Identifier subfield, it will send an XID with an XID Negotiation Error control vector to reject the link connection; sense data X'088C4680' is included in the control vector to indicate the subfield was missing.
发起链路激活的节点知道它正在激活哪个链路。在prenegotiation XID中发送的一些参数是在常规链路站配置中定义的，在后续协商过程中不允许更改。为了允许向RSVP的前向迁移，当在IP网络中激活常规TG时，接收第一个XID的节点（即，未启动链路激活的节点）还必须在发送预协商XID之前了解正在激活哪个定义的链路站，以便正确设置无法更改的参数。因此，发起链路激活的节点将通过包括包含TG标识符（X'80'）子字段的TG描述符（X'46'）控制向量来指示预协商XIDs中的TG编号。此外，接收第一XID的节点将通过使用null XID响应null XID来强制激活链路的节点发送第一预协商XID。为了防止潜在的死锁，接收第一个XID的节点对其将发送的空XID的数量有一个限制（可以使用LDLC重试计数）。一旦达到该限制，该节点将发送带有XID协商错误（X'22'）控制向量的XID，以响应空XID；控制向量中包含检测数据X'0809003A'以指示意外的空XID。如果接收到第一XID的节点接收到没有TG标识符子字段的预协商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:
对于常规TG，TG参数由节点操作员根据客户在DEFINE_PORT（RQ）和DEFINE_LS（RQ）中的配置提供。以下参数在HPR/IP链路的定义（RQ）中提供：
o The destination IP host name (this parameter can usually be mapped to the destination IP address): If the link is not activated at node initialization, the IP host name should be mapped to an IP address, and the IP address should be stored with the link station definition. This is required to allow an incoming link activation to be matched with the link station definition. If the adjacent node activates the link with a different IP address (e.g., it could have multiple ports), it will not be possible to match the link activation with the link station definition, and the default parameters specified in the local port definition will be used.
o 目标IP主机名（此参数通常可映射到目标IP地址）：如果在节点初始化时未激活链路，则IP主机名应映射到IP地址，并且IP地址应与链路站定义一起存储。这是允许传入链路激活与链路站定义匹配所必需的。如果相邻节点使用不同的IP地址激活链路（例如，它可能有多个端口），则无法将链路激活与链路站定义相匹配，并且将使用本地端口定义中指定的默认参数。
o The destination IP version (set to version 4, support for version 6 may be required in the future; this parameter is only required if the address and version cannot be determined using the destination IP host name.)
o 目标IP版本（设置为版本4，将来可能需要支持版本6；仅当无法使用目标IP主机名确定地址和版本时，才需要此参数。）
o The destination IP address (in the format specified by the destination IP version; this parameter is only required if the address cannot be determined using the destination IP host name.)
o 目标IP地址（采用目标IP版本指定的格式；仅当无法使用目标IP主机名确定地址时，才需要此参数。）
o Source service access point address (SSAP) used for XID, TEST, DISC, and DM (default is X'04'; other values may be specified when multiple links between a pair of IP addresses are defined)
o 用于XID、TEST、DISC和DM的源服务访问点地址（SSAP）（默认值为X'04'；定义一对IP地址之间的多个链路时，可以指定其他值）
o Destination service access point address (DSAP) used for XID, TEST, DISC, and DM (default is X'04')
o 用于XID、测试、光盘和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优先级（LLC命令（如XID）和每个APPN传输优先级的IP报头服务字节类型内的3位字段设置；默认值在第28页的2.6.1“IP优先级”中给出；此参数用于覆盖DEFINE_PORT中的设置）
o Shareable with connection network traffic (default is yes for non-RSVP links)
o 可与连接网络流量共享（对于非RSVP链路，默认为是）
o Retry count for LDLC (default is 3; this parameter is used to override the setting in DEFINE_PORT)
o LDLC的重试计数（默认值为3；此参数用于覆盖DEFINE_端口中的设置）
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_端口中的设置）
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中的设置；请参阅第7页的2.3.1“LDLC活跃度”）
o Auto-activation supported (default is no; may be set to yes when the local node has switched access to the IP network)
o 支持自动激活（默认为否；当本地节点已切换到IP网络时，可将其设置为是）
o Limited resource (default is to set in concert with auto-activation supported)
o 有限资源（默认设置与支持自动激活一致）
o Limited resource liveness timer (default is 45 sec.)
o 有限资源活动计时器（默认值为45秒。）
o Port name
o 端口名
o Adjacent CP name (optional)
o 相邻CP名称（可选）
o Local CP-CP sessions supported
o 支持本地CP-CP会话
o Defined TG number (optional)
o 定义的TG编号（可选）
o TG characteristics
o 热重特性
The following figures show the activation and deactivation of regular TGs.
下图显示了常规TGs的激活和停用。
*------------------------------------------------------------------*
|CS DLC LDLC DMUX UDP|
*------------------------------------------------------------------*
. . . .
.CONNECT_OUT(RQ) . create . .
o--------------->o-------------->o . .
. | new LDLC . .
. o----------------------------->o .
CONNECT_OUT(+RSP)| . . .
o<---------------* . . .
| XID . XID(CMD) . XID
*------------------------------->o----------------------------->o----->
*------------------------------------------------------------------*
|CS DLC LDLC DMUX UDP|
*------------------------------------------------------------------*
. . . .
.CONNECT_OUT(RQ) . 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.
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.translate error, please retry
*------------------------------------------------------------------*
|CS DLC LDLC DMUX UDP|
*------------------------------------------------------------------*
. . . .
. CONNECT_IN(RQ) . XID(CMD) . XID . XID
o<---------------o<-----------------------------o<--------------o<-----
| CONNECT_IN(RSP). create . .
*--------------->o-------------->o . .
. | new LDLC . .
. o----------------------------->o .
. | XID(CMD) . . .
. *-------------->o . .
. XID | . .
o<-------------------------------* . .
| XID . XID(RSP) . XID
*------------------------------->o----------------------------->o----->
*------------------------------------------------------------------*
|CS DLC LDLC DMUX UDP|
*------------------------------------------------------------------*
. . . .
. CONNECT_IN(RQ) . XID(CMD) . XID . XID
o<---------------o<-----------------------------o<--------------o<-----
| CONNECT_IN(RSP). 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管理器。数据链路管理器发送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).
以下两幅图显示了正常的TG失活（输出和输入）。
*------------------------------------------------------------------*
|CS DLC LDLC DMUX UDP|
*------------------------------------------------------------------*
. . . . .
. DEACT . DISC . DISC
o------------------------------->o----------------------------->o----->
. DEACT . DM . DM . DM
o<-------------------------------o<-------------o<--------------o<-----
| DISCONNECT(RQ) . destroy . . .
*--------------->o-------------->o . .
DISCONNECT(RSP) | . .
o<---------------* . .
*------------------------------------------------------------------*
|CS DLC LDLC DMUX UDP|
*------------------------------------------------------------------*
. . . . .
. DEACT . DISC . DISC
o------------------------------->o----------------------------->o----->
. DEACT . DM . DM . DM
o<-------------------------------o<-------------o<--------------o<-----
| DISCONNECT(RQ) . 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向DLC管理器发送DISCONNECT（RQ），DLC管理器将停用LDLC实例。收到断开连接（RSP）后，CS向NOF发送停止（RSP）。
*------------------------------------------------------------------*
|CS DLC LDLC DMUX UDP|
*------------------------------------------------------------------*
. . . . .
. DEACT . DISC . DISC . DISC
o<-------------------------------o<-------------o<--------------o<-----
| . | DM . DM
| . *----------------------------->o----->
| DISCONNECT(RQ) . destroy . . .
*--------------->o-------------->o . .
.DISCONNECT(RSP) | . .
o<---------------* . .
*------------------------------------------------------------------*
|CS DLC LDLC DMUX UDP|
*------------------------------------------------------------------*
. . . . .
. DEACT . DISC . DISC . DISC
o<-------------------------------o<-------------o<--------------o<-----
| . | DM . DM
| . *----------------------------->o----->
| DISCONNECT(RQ) . 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时，本地节点接收到一个磁盘。CS向NOF发送停止信号（IND）。由于IP是无连接的，因此数据链路管理器不知道链路已停用。因此，CS还需要向DLC管理器发送断开连接（RQ）；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节点中，当在一段时间内未检测到流量时，有限的资源TGs被停用。此外，可以将APPN链路定义为可自动激活的。当新会话已通过链路路由时，将激活自动激活的链路。
An HPR node may have access to an IP network via a switched access link. In such environments, it may be advisable for customers to define regular HPR/IP links as limited resources and as being auto-activatable.
HPR节点可以通过交换接入链路访问IP网络。在这种环境中，建议客户将常规HPR/IP链路定义为有限资源和可自动激活。
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。该模型的自然扩展是在连接到共享访问传输设施（SATF）的每对节点（如LAN或IP网络）之间定义TG。然而，对于节点数超过几个的网络来说，TGs网状结构的系统定义成本很高。因此，设计APPN连接网络模型是为了减少在APPN节点之间建立TGs所需的系统定义。
Other TGs may be defined through the SATF which are not part of the connection network. Such TGs (referred to as regular TGs in this document) are required for sessions between control points (referred to as CP-CP sessions) but may also be used for LU-LU sessions.
其他TG可通过不属于连接网络的SATF定义。控制点之间的会话（称为CP-CP会话）需要此类TG（在本文件中称为常规TG），但也可用于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的每个节点都定义了到VRN的单个TG，而不是到所有其他连接节点的TGs。
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
拓扑和路由服务（TRS）通过将每个节点之间的连接网络TGs和路由选择控制向量（RSCV）中的VRN包括在内，指定在连接网络的两个节点之间路由会话。当网络节点具有到VRN的TG时，与该TG相关联的网络拓扑信息包括跨SATF建立到该节点的连接所需的DLC信令信息。对于终端节点，DLC信令
information is returned as part of the normal directory services (DS) process. TRS includes the DLC signaling information for TGs across connection networks in RSCVs.
信息作为正常目录服务（DS）过程的一部分返回。TRS包括RSCV中连接网络上TGs的DLC信令信息。
CS creates a dynamic link station when the next hop in the RSCV of an ACTIVATE_ROUTE signal received from session services (SS) is a connection network TG or when an adjacent node initiates link activation upon receiving such an ACTIVATE_ROUTE signal. Dynamic link stations are normally treated as limited resources, which means they are deactivated when no sessions are using them. CP-CP sessions are not supported on connections using dynamic link stations because CP-CP sessions normally need to be kept up continuously.
当从会话服务（SS）接收的激活路由信号的RSCV中的下一跳是连接网络TG时，或者当相邻节点在接收到该激活路由信号时发起链路激活时，CS创建动态链路站。动态链路站通常被视为有限资源，这意味着当没有会话使用它们时，它们将被停用。使用动态链路站的连接不支持CP-CP会话，因为CP-CP会话通常需要持续保持。
Establishment of a link across a connection network normally requires the use of CP-CP sessions to determine the destination IP address. Because CP-CP sessions must flow across regular TGs, the definition of a connection network does not eliminate the need to define regular TGs as well.
通过连接网络建立链路通常需要使用CP-CP会话来确定目标IP地址。由于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.
通常，在LAN上定义一个连接网络（即定义一个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。这是通过节点操作员向NOF发出定义连接网络（RQ）命令，NOF向CS传递定义CN（RQ）信号来实现的。
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由节点运营商定义，该运营商向NOF发出定义连接网络TG（RQ），NOF将定义连接网络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
在实施资源预留协议（RSVP）支持之前，端口和VRN之间只需要一个连接网络TG。在这种情况下，不需要对DEFINE_CN_TG（RQ）信号的产品支持，因为每个连接网络的一组端口配置参数就足够了。如果NOF实现不支持DEFINE_CN_TG（RQ），那么DEFINE_CN_TG（RQ）的下一节中列出的参数将由DEFINE_CN（RQ）提供。此外，连接网络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.
激活XID上TG描述符（X'46'）控制向量中的数字（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<-----------------*
*-----------------------------------------------------*
| 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.
如果在同一连接网络上的两个端口之间存在现有的动态链路（即，具有相同的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
一旦定义了所有连接网络，节点操作员将发出START_端口（RQ），NOF将相关信号传递给CS，CS将激活_端口（RQ）传递给DLC管理器。在从DLC管理器接收到ACTIVATE_PORT（RSP）信号后，CS为每个定义的连接网络TG向TRS发送TG_更新信号。每个信号通知TRS到VRN的TG已被激活，并且包括描述TG的TG向量。如果端口出现故障或停用，CS将发送TG_更新，指示连接网络TGs不再工作。网络节点和VRN之间的TGs信息保存在网络拓扑数据库中。关于终端节点和VRN之间TGs的信息仅在本地拓扑数据库中维护。如果TRS在其VRN拓扑数据库中没有节点条目，则TRS会动态创建此类条目。只有在以下情况下，VRN节点条目才会成为网络拓扑数据库的一部分
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.
网络节点已定义到VRN的TG；然而，TRS能够在连接网络上的两个终端节点之间选择直接路径，而无需VRN节点条目。
*--------------------------------------------------------------------*
| CS TRS DLC DMUX |
*--------------------------------------------------------------------*
. ACTIVATE_PORT(RQ) . create
o--------------------------------------->o----------------->o
. ACTIVATE_PORT(RSP) | .
o<---------------------------------------* .
| TG_UPDATE . . .
*------------------->o . .
. . . .
*--------------------------------------------------------------------*
| CS TRS DLC DMUX |
*--------------------------------------------------------------------*
. ACTIVATE_PORT(RQ) . 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连接网络TGs的TG向量包括以下信息：
o TG number
o TG数
o VRN CP name
o VRN CP名称
o TG characteristics used during route selection
o 路线选择期间使用的TG特性
- Effective capacity - Cost per connect time - Cost per byte transmitted - Security - Propagation delay - User defined parameters
- 有效容量-每连接时间成本-每传输字节成本-安全性-传播延迟-用户定义参数
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、测试、光盘和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
对于连接网络TG，参数由CS使用多个输入确定。特定于本地端口、连接网络或TG的参数由系统定义并在中接收
DEFINE_PORT(RQ), DEFINE_CN(RQ), or DEFINE_CN_TG(RQ). Signaling information for the destination node including its IP address is received in the ACTIVATE_ROUTE request from SS.
定义端口（RQ）、定义CN（RQ）或定义TG（RQ）。在来自SS的ACTIVATE_ROUTE请求中接收目的地节点的信令信息，包括其IP地址。
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优先级（LLC命令（如XID）和每个APPN传输优先级的IP报头服务字节类型内的3位字段设置；默认值在第28页的2.6.1“IP优先级”中给出；此参数用于覆盖DEFINE_PORT中的设置）
The following configuration parameters are received in DEFINE_CN_TG(RQ):
在DEFINE_CN_TG（RQ）中接收以下配置参数：
o Port name
o 端口名
o Connection network name (CP name of the VRN)
o 连接网络名称（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 热重特性（见第30页2.6.3“默认热重特性”）
o Link service access point address (LSAP) used for XID, TEST, DISC, and DM (default is X'04')
o 用于XID、测试、光盘和DM的链路服务接入点地址（LSAP）（默认值为X'04'）
o Link service access point address (LSAP) used for HPR network layer packets (default is X'C8')
o 用于HPR网络层数据包的链路服务接入点地址（LSAP）（默认为X'C8'）
o Limited resource (default is yes)
o 有限资源（默认为是）
o Retry count for LDLC (default is 3; this parameter is used to override the setting in DEFINE_PORT)
o LDLC的重试计数（默认值为3；此参数用于覆盖DEFINE_端口中的设置）
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链路，默认为是）
o Maximum receive BTU size (default is 1461; this parameter is used to override the value in DEFINE_PORT(RQ).)
o 最大接收BTU大小（默认值为1461；此参数用于覆盖DEFINE_端口（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_端口（RQ）中的值。）
The following parameters are received in ACTIVATE_ROUTE for connection network TGs:
在连接网络TGs的激活路由中接收到以下参数：
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、测试、光盘和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的XIDs流，也没有创建新的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
当可以在HPR数据流之间共享TG时，通过XID通知目标节点。在任何一端，在收到
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.
激活请求连接网络流量的共享TG的路由，CS在启动新链路之前检查其TGs是否符合要求的规范。首先，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内容的大小。首先，由于使用两个连接网络TG来指定SATF跃点，因此需要两个TG描述符（X'46'）控制向量。此外，在TG描述符控制向量中包含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连接网络，仅第二TG（即，从VRN到目的地节点）需要DLC信令信息；第一TG的信令信息在源节点本地定义。因此，拓扑数据库不包括用于描述从网络节点到VRN的连接网络TG的条目的DLC信令信息。DLC信令信息包含在TG的反向联合条目中。此机制不能用于VRN和终端节点之间的连接网络TG。然而，当构造RSCV时，实现IP连接网络的节点不包括用于第一连接网络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<-----------*
*---------------------------------*
|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)
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
--------------------------------------------------------------------
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
在上述序列中，作为对接收到的XID3（np，SEC）的链路级响应的XID3（np，PRI）丢失。节点A超时并作为链路级命令重新发送XID3（np，秒）。当节点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.
收到此命令后，它认为节点A已成功接收到XID3（np，PRI），并且激活XID交换已完成。结果，节点B发送SETMODE（SNRM、SABME或XID_DONE_RQ，取决于链路类型）。当节点A接收到SETMODE时，由于没有从节点B接收到确认节点B确实同意作为主节点的XID3（np，PRI），链路激活失败。此外，不完全TG数协商也存在类似问题。
To solve the problems with incomplete role and TG number negotiation, two new indicators are defined in XID3. The problems are solved only if both link stations support these new indicators:
为了解决角色不完整和TG号协商的问题，在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）——只有当XID交换状态为协商正在进行，XID3由二级链路站发送，且支持的协商完成指示符设置为1时，此1位字段才有意义；否则，此字段将保留。当辅助链路站认为链路站角色和TG号的激活XID协商均已完成时，该字段由支持增强型XID协商的辅助链路站设置为1（即，它已准备好接收来自主链路站的SETMODE命令）
When a primary link station that supports enhanced XID negotiation receives an XID3(np) with both the Negotiation Complete Supported indicator and the Negotiation Complete indicator set to 1, the primary link station will know that it can safely send SETMODE if it also considers the XID negotiation to be complete. The new indicators are used as shown in the following sequence when both the primary and secondary link stations support enhanced XID negotiation.
当支持增强型XID协商的主链路站接收到一个XID3（np）时，其支持的协商完成指示符和协商完成指示符都设置为1，主链路站将知道，如果它也认为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 <-----------*
*----------------------------------*
|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<--------------------------*
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
--------------------------------------------------------------------
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.
当Node 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协商的迁移情况。在下一个序列中，只有节点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 <-----------*
*---------------------------------*
|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
time out
XID3 (np, SEC, S, ^C)
4 o-------------------------->o
SETMODE |
5 o<--------------------------*
fail
--------------------------------------------------------------------
Figure 11. First Migration Case
--------------------------------------------------------------------
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.
XID协商失败，因为节点B不理解新的指示符，并使用SETMODE响应流4。
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 <-----------*
*---------------------------------*
|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
time out
XID3 (np, SEC, ^S)
4 o-------------------------->o
SETMODE |
5 o<--------------------------*
fail
------------------------------------------------------------------------
Figure 12. Second Migration Case
------------------------------------------------------------------------
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.
XID协商失败，因为Nobe A不了解新的指标，因此无法表示它认为流程4中的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.
支持HPR/IP链路的产品需要支持增强的XID协商。此外，建议为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接收到激活路由时，尝试通过连接网络或自动激活链路激活链路时，激活失败将通过包含解释故障原因的检测数据的激活路由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（绑定）或带有扩展检测数据控制向量的解除绑定，并将其返回到主逻辑单元（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 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. | |
+--------------------------------------------------------+-------------+
+----------------------------------------------------------------------+
| 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路由器以先到先得的方式处理数据包；i、 例如，没有数据包被赋予传输优先级。但是，一些IP路由器根据IP优先级（IP头的服务字节类型中的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（十进制），已由互联网分配号码管理局（IANA）分配。其中四个端口号用于ANR路由网络层数据包（NLP），并对应于APPN传输优先级（网络，12001；高，12002；中，12003；低，12004），一个端口号（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优先级是可配置的。隐式假设是优先级值与优先级排队相关，而与带宽分配无关；但是，带宽分配策略可以通过在优先字段上进行匹配来管理。下表显示了到IP优先级的默认映射：
+---------------------------------------------+
| Table 2. Default IP Precedence Settings |
+----------------------+----------------------+
| PRIORITY | PRECEDENCE |
+----------------------+----------------------+
| LLC commands and | 110 |
| function-routed NLPs | |
+----------------------+----------------------+
| Network | 110 |
+----------------------+----------------------+
| High | 100 |
+----------------------+----------------------+
| Medium | 010 |
+----------------------+----------------------+
| Low | 001 |
+----------------------+----------------------+
+---------------------------------------------+
| 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、interactive ftp和business use web流量可以映射到优先级值011，而batch ftp可以映射到值000。
These settings were devised based on the AIW's understanding of the intended use of IP precedence. The use of IP precedence will be modified appropriately if the IETF standardizes its use differently. The other fields in the IP TOS byte are not used and should be set to 0.
这些设置是根据AIW对IP优先级预期用途的理解而设计的。如果IETF以不同的方式对IP优先级的使用进行标准化，则将适当修改IP优先级的使用。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，根据HPR网络标头中指定的传输优先级设置目标（以及可选的源）UDP端口号和IP优先级。
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优先级相关的传输优先级。该体系结构可用于在Internet上路由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.
在未来，一种形式的带宽预留可能在IP网络中使用资源预留协议（RSVP），或IETF综合服务工作组目前正在研究的区分服务。可以为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 TGs在批处理流量中得到高度利用，而不会影响响应时间敏感的交互流量的性能。此外，调度算法保证低优先级流量不会完全阻塞。结果是可预测的性能。
When a session is initiated across an APPN network, the session's mode is mapped into a COS and transmission priority. For each COS, APPN has a COS table that is used in the route selection process to select the most appropriate TGs (based on their TG characteristics) for the session to traverse. The TG characteristics and COS tables are defined such that APPN topology and routing services (TRS) will select the appropriate TG for the traffic of each COS.
当通过APPN网络启动会话时，会话的模式映射为COS和传输优先级。对于每个COS，APPN都有一个COS表，在路由选择过程中使用该表为会话选择最合适的TG（基于它们的TG特征）。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（连接网络或常规）被定义为特定技术（如以太网或X.25）而未规定TG的特性时，TG的拓扑条目中使用该技术的默认配置文件中的参数。客户可以通过配置自由覆盖这些值。某些技术具有多个配置文件（例如，ISDN同时具有交换和非交换配置文件）。IP TGs需要两个默认配置文件。这是需要的，因为有校园和广域IP网络。因此，对于每个HPR/IP TG，客户应至少指定园区或广域。穿越互联网的HPR/IP TGs应指定为广域链路。如果未制定规范，则假定为校园网。
The 2 IP profiles are as follows:
2个IP配置文件如下所示：
+----------------------------------------------------------------------+
| Table 3. IP Default TG Characteristics |
+-------------------+---------+----------+---------+---------+---------+
| | Cost | Cost per | Security| Propa- | Effec- |
| | per | byte | | gation | tive |
| | connect | | | delay | capacity|
| | time | | | | |
+-------------------+---------+----------+---------+---------+---------+
| Campus | 0 | 0 | X'01' | X'71' | X'75' |
+-------------------+---------+----------+---------+---------+---------+
| Wide area | 0 | 0 | X'20' | X'91' | X'43' |
+-------------------+---------+----------+---------+---------+---------+
+----------------------------------------------------------------------+
| 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如果是自有或租赁的，则被视为“免费”，如果是交换运营商设施，则被视为“昂贵”。免费TGs的两个成本参数均为0，而昂贵TGs的两个参数均为128。对于校园IP网络，两个成本参数的默认值均为0。
It is less clear what the defaults should be for wide area. Because a router normally has leased access to an IP network, the defaults for both costs are also 0. This assumes the IP network is not tariffed. However, if the IP network is tariffed, then the customer should set the cost per byte to 0 or 128 depending on whether the tariff contains a component based on quantity of data transmitted, and the customer should set the cost per connect time to 0 or 128 based on whether there is a tariff component based on connect time. Furthermore, for switched access to the IP network, the customer settings for both costs should also reflect the tariff associated with the switched access link.
广域的默认值应该是什么还不太清楚。因为路由器通常拥有对IP网络的租用访问权，所以这两种成本的默认值也是0。这假定IP网络未加密。但是，如果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数据包将经历地面传播延迟和中间路由器中的排队延迟。此值适用于Internet和广域内部网；但是，在选择路线时，客户可以使用不同的值来支持内部网而不是Internet。值X'99'（长）可能适用于Internet上的某些国际链接。对于校园，默认值为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
对于广域，X'43'（56 kbs）显示为默认有效容量；这是广域IP链路典型速度的低端。对于校园，X'75'（4 Mbs）是默认值；这是校园IP链路典型速度的低端。但是，客户应根据IP网络接入链路的实际物理速度设置校园和广域IP链路的有效容量；对于常规链路，如果源和目标访问速度都已知，则客户应根据这两个链路速度中的最小值设置有效容量。如果存在多个接入链路，则容量设置应基于物理链路
speed of the access link that is expected to be used for the link.
预期用于链路的访问链路的速度。
For the encoding technique for effective capacity in the topology database, see "Effective Capacity" in Chapter 7, Topology and Routing Services of [1]. The table in that section can be extended as follows for higher speeds:
有关拓扑数据库中有效容量的编码技术，请参见[1]第7章拓扑和路由服务中的“有效容量”。对于更高的速度，该部分中的表格可扩展如下：
+----------------------------------------------------------------------+
| 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' |
+-----------------------------------+----------------------------------+
+----------------------------------------------------------------------+
| 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:
[1]中提供了SNA定义的批量和交互式COS表。[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时，在路由设置请求和应答中设置重排序（“refinfo”）指示符，因为可能无法按发送顺序接收数据包。当RTP路径包括HPR/IP链路时，由于通过IP网络发送的数据包可能会无序到达，也会设置重排序指示符。
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）是一种HPR快速传输协议（RTP）功能，用于控制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路由器；在这两种情况下，当通过接入链路向IP网络传输HPR数据时，此类节点还应遵守与UDP端口号或IP优先级相关的优先级。
--------------------------------------------------------------------
--------------------------------------------------------------------
*--------* access link *--------* *--------*
| HPR |-------------| IP |-----| IP |
| node | | Router | | Router |
*--------* *--------* *--------*
| |
| |
| |
*--------* *--------* access link *--------*
| IP |-----| IP |-------------| HPR |
| Router | | Router | | node |
*--------* *--------* *--------*
*--------* access link *--------* *--------*
| HPR |-------------| IP |-----| IP |
| node | | Router | | Router |
*--------* *--------* *--------*
| |
| |
| |
*--------* *--------* access link *--------*
| IP |-----| IP |-------------| HPR |
| Router | | Router | | node |
*--------* *--------* *--------*
--------------------------------------------------------------------
Figure 13. Access Links
--------------------------------------------------------------------
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提供三个参数来定义端口的链路激活限制：总限制、入站限制和出站限制。总限制是常规TGs和连接网络TGs端口上允许的活动链路站的期望最大数量。入站限制是为相邻节点发起的连接保留的链路站的期望数量；该字段的目的是确保相邻节点可以激活最少数量的链路站。出站限制是为本地节点发起的连接保留的所需链路站数。入站和出站限额之和必须小于或等于总限额。如果总和小于总限制，则差值为可按需激活的链路站数，即入站或出站。这些限制应基于实际适配器能力和节点资源（例如，控制块）。
A connection network TG will be reported to topology as quiescing when its port's total limit threshold is reached; likewise, an inactive auto-activatable regular TG is reported as nonoperational. When the number of active link stations drops far enough below the threshold (e.g., so that at least 20 percent of the original link activation limit has been recovered), connection network TGs are reported as not quiescing, and auto-activatable TGs are reported as operational.
当连接网络TG的端口达到总限制阈值时，将向拓扑报告TG处于静止状态；同样，非活动自动激活的常规TG报告为不可操作。当活动链路站的数量远远低于阈值（例如，至少恢复了20%的原始链路激活限制）时，连接网络TGs报告为未停止，自动激活TGs报告为运行。
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-MIB，它将提供HPR/IP特定的管理信息。特别是，此MIB将提供APPN通信量类型到IP服务优先级值类型的映射，以及为每种通信量类型发送的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 APPNMIB中有几个对象的语法为IANAifType。当以下三个对象标识HPR/IP链路时，应返回定义为“IP（用于IP网络中的APPN HPR）”的值126：
- appnPortDlcType - appnLsDlcType - appnLsStatusDlcType
- appnPortDlcType-appnLsDlcType-APPNLStatusDLLCTYPE
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.)
所有这些对象都应返回ASCII字符串，以通常的点十进制格式表示IP地址。（目前还不清楚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 以下两个对象返回将APPN MIB中的表条目与较低层MIB中的条目联系起来的对象标识符：
- appnPortSpecific - appnLsSpecific
- appnPortSpecific-AppNLSSSpecific
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.
这两个对象都应该返回相同的值：一个RowPointer，指向与端口的本地IP地址关联的物理接口的代理ifTable中的ifEntry。如果代理实现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
具有IPv4地址的主机可以使用特殊的IPv6地址前缀（即，它是嵌入式IPv4地址）将其用作IPv6地址。此映射主要用于“遗留”应用程序兼容性目的，因为此类应用程序没有套接字
structures needed to store full IPv6 addresses. Two IPv6 hosts may communicate using IPv6 with embedded-IPv4 addresses.
存储完整IPv6地址所需的结构。两台IPv6主机可以使用具有嵌入式IPv4地址的IPv6进行通信。
Both IPv4 and IPv6 addresses can be stored by the domain name service (DNS). When an application queries DNS, it asks for IPv4 addresses, IPv6 addresses, or both. So, it's the application that decides which stack to use based on which addresses it asks for.
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。如果两者都受支持，则可以为两个VRN定义TGs。因此，除非发生配置错误，否则在RSCVs中接收的信令信息将与本地节点的能力兼容。
[1] IBM, Systems Network Architecture Advanced Peer-to-Peer
Networking Architecture Reference, SC30-3442-04. Viewable at URL:
http://www.raleigh.ibm.com/cgi-bin/bookmgr/BOOKS/D50L0000/CCONTENTS
[1] IBM, 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
[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
[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，“数据链路切换：切换至切换协议，AIW DLSw钻机：DLSw闭页，DLSw标准版本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实施者研讨会闭页文档DLSw v2.0增强”，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 7911981年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] Braden，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，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[11] Clouston, B., and B. Moore, "Definitions of Managed Objects for APPN using SMIv2", RFC 2155, June 1997.
[11] Clouston，B.和B.Moore，“使用SMIv2的APPN托管对象定义”，RFC 2155，1997年6月。
[12] McCloghrie, K., "SNMPv2 Management Information Base for the Internet Protocol using SMIv2", RFC 2011, November 1996.
[12] McCloghrie，K.，“使用SMIv2的互联网协议的SNMPv2管理信息库”，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流量作为UDP数据报在IP网络中流动，因此可以使用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
Gary Dudley C3BA/501 IBM公司美国北卡罗来纳州三角研究公园12195号邮政信箱，邮编：27709
Phone: +1 919-254-4358
Fax: +1 919-254-6243
EMail: dudleyg@us.ibm.com
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. |
+----------------------------------------------------------------------+
+----------------------------------------------------------------------+
| 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 |
+-------+-----+--------------------------------------------------------+
+----------------------------------------------------------------------+
| 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. |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| | | 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 |
+-------+-----+--------------------------------------------------------+
+----------------------------------------------------------------------+
| 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. |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| | | 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 | | |
+-------+-----+--------------------------------------------------------+
+----------------------------------------------------------------------+
| 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. |
+-------+-----+--------------------------------------------------------+
+-------+-----+--------------------------------------------------------+
| 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.
版权所有（C）互联网协会（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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。