Network Working Group M. Laubach
Request for Comments: 2225 Com21, Inc.
Category: Standards Track J. Halpern
Obsoletes: 1626, 1577 Newbridge Networks, Inc.
April 1998
Network Working Group M. Laubach
Request for Comments: 2225 Com21, Inc.
Category: Standards Track J. Halpern
Obsoletes: 1626, 1577 Newbridge Networks, Inc.
April 1998
Classical IP and ARP over ATM
ATM上的经典IP和ARP
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Table of Contents
目录
1. ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. ACKNOWLEDGMENT . . . . . . . . . . . . . . . . . . . . . . . 2
3. CONVENTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 3
5. IP SUBNETWORK CONFIGURATION . . . . . . . . . . . . . . . . . 6
5.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2 LIS Configuration Requirements . . . . . . . . . . . . . . 7
5.3 LIS Router Additional Configuration . . . . . . . . . . . . 8
6. IP PACKET FORMAT . . . . . . . . . . . . . . . . . . . . . . 8
7. DEFAULT VALUE FOR IP MTU OVER ATM AAL5 . . . . . . . . . . . 9
7.1 Permanent Virtual Circuits . . . . . . . . . . . . . . . . 9
7.2 Switched Virtual Circuits . . . . . . . . . . . . . . . . . 9
7.3 Path MTU Discovery Required . . . . . . . . . . . . . . . . 11
8. LIS ADDRESS RESOLUTION SERVICES . . . . . . . . . . . . . . . 11
8.1 ATM-based ARP and InARP Equivalent Services . . . . . . . . 11
8.2 Permanent Virtual Connections . . . . . . . . . . . . . . . 12
8.3 Switched Virtual Connections . . . . . . . . . . . . . . . 12
8.4 ATMARP Single Server Operational Requirements . . . . . . . 13
8.5 ATMARP Client Operational Requirements . . . . . . . . . . 14
8.5.1 Client ATMARP Table Aging . . . . . . . . . . . . . . . . 16
8.5.2 Non-Normal VC Operations . . . . . . . . . . . . . . . . 17
8.5.3 Use of ATM ARP in Mobile-IP Scenarios . . . . . . . . . . 17
8.6 Address Resolution Server Selection . . . . . . . . . . . . 17
8.6.1 PVCs to ATMARP Servers . . . . . . . . . . . . . . . . . 18
8.7 ATMARP Packet Formats . . . . . . . . . . . . . . . . . . . 18
1. ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. ACKNOWLEDGMENT . . . . . . . . . . . . . . . . . . . . . . . 2
3. CONVENTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 3
5. IP SUBNETWORK CONFIGURATION . . . . . . . . . . . . . . . . . 6
5.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2 LIS Configuration Requirements . . . . . . . . . . . . . . 7
5.3 LIS Router Additional Configuration . . . . . . . . . . . . 8
6. IP PACKET FORMAT . . . . . . . . . . . . . . . . . . . . . . 8
7. DEFAULT VALUE FOR IP MTU OVER ATM AAL5 . . . . . . . . . . . 9
7.1 Permanent Virtual Circuits . . . . . . . . . . . . . . . . 9
7.2 Switched Virtual Circuits . . . . . . . . . . . . . . . . . 9
7.3 Path MTU Discovery Required . . . . . . . . . . . . . . . . 11
8. LIS ADDRESS RESOLUTION SERVICES . . . . . . . . . . . . . . . 11
8.1 ATM-based ARP and InARP Equivalent Services . . . . . . . . 11
8.2 Permanent Virtual Connections . . . . . . . . . . . . . . . 12
8.3 Switched Virtual Connections . . . . . . . . . . . . . . . 12
8.4 ATMARP Single Server Operational Requirements . . . . . . . 13
8.5 ATMARP Client Operational Requirements . . . . . . . . . . 14
8.5.1 Client ATMARP Table Aging . . . . . . . . . . . . . . . . 16
8.5.2 Non-Normal VC Operations . . . . . . . . . . . . . . . . 17
8.5.3 Use of ATM ARP in Mobile-IP Scenarios . . . . . . . . . . 17
8.6 Address Resolution Server Selection . . . . . . . . . . . . 17
8.6.1 PVCs to ATMARP Servers . . . . . . . . . . . . . . . . . 18
8.7 ATMARP Packet Formats . . . . . . . . . . . . . . . . . . . 18
8.7.1 ATMARP/InATMARP Request and Reply Packet Formats . . . . 18
8.7.2 Receiving Unknown ATMARP packets . . . . . . . . . . . . 20
8.7.3 TL, ATM Number, and ATM Subaddress Encoding . . . . . . . 20
8.7.4 ATMARP_NAK Packet Format . . . . . . . . . . . . . . . . 21
8.7.5 Variable Length Requirements for ATMARP Packets . . . . . 21
8.8 ATMARP/InATMARP Packet Encapsulation . . . . . . . . . . . 22
9. IP BROADCAST ADDRESS . . . . . . . . . . . . . . . . . . . . 23
10. IP MULTICAST ADDRESS . . . . . . . . . . . . . . . . . . . . 23
11. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . 23
12. MIB SPECIFICATION . . . . . . . . . . . . . . . . . . . . . 24
13. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . . 24
14. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . 24
15. AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . 26
APPENDIX A - Update Information . . . . . . . . . . . . . . . . 27
FULL COPYRIGHT STATEMENT . . . . . . . . . . . . . . . . . . . . 28
8.7.1 ATMARP/InATMARP Request and Reply Packet Formats . . . . 18
8.7.2 Receiving Unknown ATMARP packets . . . . . . . . . . . . 20
8.7.3 TL, ATM Number, and ATM Subaddress Encoding . . . . . . . 20
8.7.4 ATMARP_NAK Packet Format . . . . . . . . . . . . . . . . 21
8.7.5 Variable Length Requirements for ATMARP Packets . . . . . 21
8.8 ATMARP/InATMARP Packet Encapsulation . . . . . . . . . . . 22
9. IP BROADCAST ADDRESS . . . . . . . . . . . . . . . . . . . . 23
10. IP MULTICAST ADDRESS . . . . . . . . . . . . . . . . . . . . 23
11. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . 23
12. MIB SPECIFICATION . . . . . . . . . . . . . . . . . . . . . 24
13. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . . 24
14. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . 24
15. AUTHORS' ADDRESSES . . . . . . . . . . . . . . . . . . . . . 26
APPENDIX A - Update Information . . . . . . . . . . . . . . . . 27
FULL COPYRIGHT STATEMENT . . . . . . . . . . . . . . . . . . . . 28
This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described in Section 5. This memo does not preclude the subsequent development of ATM technology into areas other than a LIS; specifically, as single ATM networks grow to replace many Ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and local LAN segments connecting IP end-stations ("members") and routers operating in the "classical" LAN-based paradigm. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper.
本备忘录定义了经典IP和ARP在异步传输模式（ATM）网络环境中的初始应用，配置为逻辑IP子网（LIS），如第5节所述。本备忘录不排除ATM技术在LIS以外的领域的后续发展；具体地说，随着单个ATM网络逐渐取代许多以太网本地LAN网段，并且随着这些网络的全球连接，IP和ARP的应用将得到不同的对待。本备忘录仅考虑将ATM应用作为连接IP终端站（“成员”）和路由器的“电线”和本地LAN段的直接替代物，这些路由器以“经典”LAN为基础模式运行。MAC层桥接和LAN仿真提出的问题超出了本文的范围。
This memo introduces general ATM technology and nomenclature. Readers are encouraged to review the ATM Forum and ITU-TS (formerly CCITT) references for more detailed information about ATM implementation agreements and standards.
本备忘录介绍了通用ATM技术和术语。鼓励读者阅读ATM论坛和ITU-TS（前CCITT）参考资料，以了解有关ATM实施协议和标准的更多详细信息。
The authors would like to thank the efforts of the IP over ATM Working Group of the IETF. Without their substantial, and sometimes contentious support, of the Classical IP over ATM model, this updated memo would not have been possible. Section 7, on Default MTU, has been incorporated directly from Ran Atkinson's RFC 1626, with his permission. Thanks to Andy Malis for an early review and comments for rolc and ion related issues.
作者要感谢IETF的IP over ATM工作组的努力。如果没有他们对经典的IP over ATM模型的实质性支持，有时甚至是有争议的支持，这个更新的备忘录就不可能实现。第7节，关于默认MTU，经Ran Atkinson许可，已直接并入Ran Atkinson的RFC 1626。感谢Andy Malis对rolc和ion相关问题的早期审查和评论。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [20].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[20]中所述进行解释。
The goal of this specification is to allow compatible and interoperable implementations for transmitting IP datagrams and ATM Address Resolution Protocol (ATMARP) requests and replies over ATM Adaptation Layer 5 (AAL5)[2,6].
本规范的目标是允许通过ATM适配层5（AAL5）[2,6]传输IP数据报和ATM地址解析协议（ATMARP）请求和回复的兼容和互操作实现。
This memo specifies the stable foundation baseline operational model which will always be available in IP and ARP over ATM implementations. Subsequent memos will build upon and refine this model. However, in the absence or failure of those extensions, operations will default to the specifications contained in this memo. Consequently, this memo will not reference these other extensions.
该备忘录规定了ATM实现中IP和ARP将始终可用的稳定基础基线操作模型。随后的备忘录将建立并完善这一模式。但是，如果没有这些扩展或扩展失败，操作将默认为本备忘录中包含的规范。因此，本备忘录不会引用这些其他扩展。
This memo defines only the operation of IP and address resolution over ATM, and is not meant to describe the operation of ATM networks. Any reference to virtual connections, permanent virtual connections, or switched virtual connections applies only to virtual channel connections used to support IP and address resolution over ATM, and thus are assumed to be using AAL5. This memo places no restrictions or requirements on virtual connections used for other purposes.
本备忘录仅定义了ATM上IP和地址解析的操作，而不是描述ATM网络的操作。对虚拟连接、永久虚拟连接或交换虚拟连接的任何引用仅适用于用于支持ATM上的IP和地址解析的虚拟通道连接，因此假定使用AAL5。本备忘录对用于其他目的的虚拟连接没有任何限制或要求。
Initial deployment of ATM provides a LAN segment replacement for:
ATM的初始部署为以下各项提供了LAN段替换：
1) Local area networks (e.g., Ethernets, Token Rings and FDDI).
1) 局域网（如以太网、令牌环和FDDI）。
2) Local-area backbones between existing (non-ATM) LANs.
2) 现有（非ATM）LAN之间的局域网主干。
3) Dedicated circuits or frame relay PVCs between IP routers.
3) IP路由器之间的专用电路或帧中继PVC。
NOTE: In 1), local IP routers with one or more ATM interfaces will be able to connect islands of ATM networks. In 3), public or private ATM Wide Area networks will be used to connect IP routers, which in turn may or may not connect to local ATM networks. ATM WANs and LANs may be interconnected.
注：在1）中，具有一个或多个ATM接口的本地IP路由器将能够连接ATM网络的孤岛。在第三种情况下，公共或专用ATM广域网将用于连接IP路由器，而IP路由器又可能连接到本地ATM网络，也可能不连接到本地ATM网络。ATM WAN和LAN可以互连。
Private ATM networks (local or wide area) will use the private ATM address structure specified in the ATM Forum UNI 3.1 specification [9] or as in the ATM Forum UNI 4.0 specification [19]. This structure is modeled after the format of an OSI Network Service Access Point Address (NSAPA). A private ATM address uniquely identifies an ATM endpoint.
专用ATM网络（局域网或广域网）将使用ATM论坛UNI 3.1规范[9]或ATM论坛UNI 4.0规范[19]中规定的专用ATM地址结构。这种结构是按照OSI网络服务接入点地址（NSPA）的格式建模的。专用ATM地址唯一标识ATM端点。
Public networks will use either the address structure specified in ITU-TS recommendation E.164 or the private network ATM address structure. An E.164 address uniquely identifies an interface to a public network.
公共网络将使用ITU-TS建议E.164中规定的地址结构或专用网络ATM地址结构。E.164地址唯一标识到公共网络的接口。
The characteristics and features of ATM networks are different than those found in LANs:
ATM网络的特征和特点与局域网不同：
o ATM provides a Virtual Connection (VC) switched environment. VC setup may be done on either a Permanent Virtual Connection (PVC) or dynamic Switched Virtual Connection (SVC) basis. SVC call management signalling is performed via implementations of the UNI 3.1 protocol [7,9].
o ATM提供了一个虚拟连接（VC）交换环境。VC设置可以在永久虚拟连接（PVC）或动态交换虚拟连接（SVC）的基础上进行。SVC呼叫管理信令通过UNI 3.1协议的实现来执行[7,9]。
o Data to be passed by a VC is segmented into 53 octet quantities called cells (5 octets of ATM header and 48 octets of data).
o VC将要传递的数据分为53个八位字节，称为信元（5个八位字节的ATM报头和48个八位字节的数据）。
o The function of mapping user Protocol Data Units (PDUs) into the information field of the ATM cell and vice versa is performed in the ATM Adaptation Layer (AAL). When a VC is created a specific AAL type is associated with the VC. There are four different AAL types, which are referred to individually as "AAL1", "AAL2", "AAL3/4", and "AAL5". (NOTE: this memo concerns itself with the mapping of IP and ATMARP over AAL5 only. The other AAL types are mentioned for introductory purposes only.) The AAL type is known by the VC end points via the call setup mechanism and is not carried in the ATM cell header. For PVCs the AAL type is administratively configured at the end points when the Connection (circuit) is set up. For SVCs, the AAL type is communicated along the VC path via UNI 3.1 as part of call setup establishment and the end points use the signaled information for configuration. ATM switches generally do not care about the AAL type of VCs. The AAL5 format specifies a packet format with a maximum size of (64K - 1) octets of user data. Cells for an AAL5 PDU are transmitted first to last, the last cell indicating the end of the PDU. ATM standards guarantee that on a given VC, cell ordering is preserved end-to-end. NOTE: AAL5 provides a non-assured data transfer service - it is up to higher-level protocols to provide retransmission.
o 在ATM适配层（AAL）中执行将用户协议数据单元（PDU）映射到ATM信元的信息字段以及将用户协议数据单元映射到ATM信元的信息字段的功能。创建VC时，特定AAL类型与VC关联。有四种不同的AAL类型，分别称为“AAL1”、“AAL2”、“AAL3/4”和“AAL5”。（注：本备忘录仅涉及IP和ATMARP在AAL5上的映射。提及其他AAL类型仅用于介绍目的。）VC端点通过呼叫设置机制知道AAL类型，且不在ATM信元报头中携带。对于PVC，AAL类型在连接（电路）设置时在端点进行管理配置。对于SVC，作为呼叫建立的一部分，AAL类型通过UNI 3.1沿VC路径进行通信，端点使用信号信息进行配置。ATM交换机通常不关心AAL类型的VCs。AAL5格式指定用户数据最大大小为（64K-1）个八位字节的数据包格式。AAL5 PDU的小区从前到后传输，最后一个小区表示PDU的结束。ATM标准保证在给定的VC上，信元顺序保持端到端。注：AAL5提供了一种不可靠的数据传输服务——由更高级别的协议提供重传。
o ATM Forum signaling defines point-to-point and point-to-point Connection setup [9, 19.] Multipoint-to-multipoint not yet specified by ITU-TS or ATM Forum.
o ATM论坛信令定义了ITU-TS或ATM论坛尚未指定的点对点和点对点连接设置[9,19.]多点对多点。
An ATM Forum ATM address is either encoded as an NSAP form ATM EndSystem Address (AESA) or is an E.164 Public-UNI address [9, 19]. In some cases, both an AESA and an E.164 Public UNI address are needed by an ATMARP client to reach another host or router.
ATM论坛ATM地址编码为NSAP形式的ATM终端系统地址（AESA）或E.164公共UNI地址[9,19]。在某些情况下，ATMARP客户端需要AESA和E.164公共UNI地址才能到达另一台主机或路由器。
Since the use of AESAs and E.164 public UNI addresses by ATMARP are analogous to the use of Ethernet addresses, the notion of "hardware address" is extended to encompass ATM addresses in the context of ATMARP, even though ATM addresses need not have hardware significance. ATM Forum NSAP format addresses (AESA) use the same basic format as U.S. GOSIP OSI NSAPAs [11]. NOTE: ATM Forum addresses should not be construed as being U.S. GOSIP NSAPAs. They are not, the administration is different, which fields get filled out are different, etc. However, in this document, these will be referred to as NSAPAs.
由于ATMARP使用AESA和E.164公共UNI地址类似于使用以太网地址，“硬件地址”的概念被扩展到ATMARP上下文中的ATM地址，即使ATM地址不需要具有硬件意义。ATM论坛NSAP格式地址（AESA）使用与美国GOSIP OSI NSAPA相同的基本格式[11]。注：ATM论坛地址不应解释为美国GOSIP NSAPA。它们不是，管理不同，填写的字段不同，等等。但是，在本文件中，这些字段将被称为NSAPA。
This memo describes the initial deployment of ATM within "classical" IP networks as a direct replacement for local area networks (Ethernets) and for IP links which interconnect routers, either within or between administrative domains. The "classical" model here refers to the treatment of the ATM host adapter as a networking interface to the IP protocol stack operating in a LAN-based paradigm.
本备忘录描述了ATM在“经典”IP网络中的初始部署，作为局域网（以太网）和互连路由器的IP链路的直接替代，无论是在管理域内还是在管理域之间。这里的“经典”模型指的是将ATM主机适配器作为IP协议栈的网络接口，在基于LAN的模式下运行。
Characteristics of the classical model are:
经典模型的特点是：
o The same maximum transmission unit (MTU) size is the default for all VCs in a LIS. However, on a VC-by-VC point-to-point basis, the MTU size may be negotiated during connection setup using Path MTU Discovery to better suit the needs of the cooperating pair of IP members or the attributes of the communications path. (Refer to Section 7.3)
o LIS中所有VCs的默认最大传输单元（MTU）大小相同。然而，在逐个VC点对点的基础上，可以在连接建立期间使用路径MTU发现来协商MTU大小，以更好地适应协作的IP成员对的需要或通信路径的属性。（参考第7.3节）
o Default LLC/SNAP encapsulation of IP packets.
o IP数据包的默认LLC/SNAP封装。
o End-to-end IP routing architecture stays the same.
o 端到端IP路由体系结构保持不变。
o IP addresses are resolved to ATM addresses by use of an ATMARP service within the LIS - ATMARPs stay within the LIS. From a client's perspective, the ATMARP architecture stays faithful to the basic ARP model presented in [3].
o IP地址通过使用LIS中的ATMARP服务解析为ATM地址-ATMARP保留在LIS中。从客户的角度来看，ATMARP体系结构忠实于[3]中介绍的基本ARP模型。
o One IP subnet is used for many hosts and routers. Each VC directly connects two IP members within the same LIS.
o 一个IP子网用于许多主机和路由器。每个VC直接连接同一LIS中的两个IP成员。
Future memos will describe the operation of IP over ATM when ATM networks become globally deployed and interconnected.
未来的备忘录将描述当ATM网络在全球部署和互连时，IP over ATM的操作。
The deployment of ATM into the Internet community is just beginning and will take many years to complete. During the early part of this period, we expect deployment to follow traditional IP subnet boundaries for the following reasons:
ATM在互联网社区的部署才刚刚开始，需要很多年才能完成。在此期间的早期，我们预计部署将遵循传统的IP子网边界，原因如下：
o Administrators and managers of IP subnetworks will tend to initially follow the same models as they currently have deployed. The mindset of the community will change slowly over time as ATM increases its coverage and builds its credibility.
o IP子网的管理员和管理者最初将倾向于遵循他们目前部署的相同模型。随着ATM覆盖范围的扩大和信誉的建立，社区的心态将慢慢改变。
o Policy administration practices rely on the security, access, routing, and filtering capability of IP Internet gateways: i.e., firewalls. ATM will not be allowed to "back-door" around these mechanisms until ATM provides better management capability than the existing services and practices.
o 策略管理实践依赖于IP Internet网关（即防火墙）的安全性、访问、路由和过滤能力。在ATM提供比现有服务和实践更好的管理能力之前，ATM将不被允许在这些机制周围“后门”。
o Standards for global IP over ATM will take some time to complete and deploy.
o ATM全球IP标准的完成和部署将需要一些时间。
This memo details the treatment of the classical model of IP and ATMARP over ATM. This memo does not preclude the subsequent treatment of ATM networks within the IP framework as ATM becomes globally deployed and interconnected; this will be the subject of future documents. This memo does not address issues related to transparent data link layer interoperability.
本备忘录详细介绍了ATM上IP和ATMARP的经典模型的处理方法。本备忘录不排除在IP框架内对ATM网络进行后续处理，因为ATM已在全球范围内部署和互连；这将是今后文件的主题。本备忘录不涉及与透明数据链路层互操作性相关的问题。
In the LIS scenario, each separate administrative entity configures its hosts and routers within a LIS. Each LIS operates and communicates independently of other LISs on the same ATM network.
在LIS场景中，每个独立的管理实体在LIS中配置其主机和路由器。每个LIS独立于同一ATM网络上的其他LIS进行操作和通信。
In the classical model, hosts communicate directly via ATM to other hosts within the same LIS using the ATMARP service as the mechanism for resolving target IP addresses to target ATM endpoint addresses. The ATMARP service has LIS scope only and serves all hosts in the LIS. Communication to hosts located outside of the local LIS is provided via an IP router. This router is an ATM endpoint attached to the ATM network that is configured as a member of one or more LISs. This configuration MAY result in a number of disjoint LISs operating over the same ATM network. Using this model hosts of differing IP subnets MUST communicate via an intermediate IP router even though it may be possible to open a direct VC between the two IP members over the ATM network.
在经典模型中，主机通过ATM直接与同一LIS内的其他主机通信，使用ATMARP服务作为将目标IP地址解析为目标ATM端点地址的机制。ATMARP服务仅具有LIS作用域，并为LIS中的所有主机提供服务。通过IP路由器与位于本地LIS之外的主机进行通信。该路由器是连接到配置为一个或多个LIS成员的ATM网络的ATM端点。这种配置可能导致许多不相交的LIS在同一ATM网络上运行。使用此模型，不同IP子网的主机必须通过中间IP路由器进行通信，即使可能通过ATM网络在两个IP成员之间打开直接VC。
By default, the ATMARP service and the classical LIS routing model MUST be available to any IP member client in the LIS.
默认情况下，ATMARP服务和经典LIS路由模型必须可用于LIS中的任何IP成员客户端。
The requirements for IP members (hosts, routers) operating in an ATM LIS configuration are:
在ATM LIS配置中运行的IP成员（主机、路由器）的要求如下：
o All members of the LIS have the same IP network/subnet number and address mask [8].
o LIS的所有成员具有相同的IP网络/子网编号和地址掩码[8]。
o All members within a LIS are directly connected to the ATM network.
o LIS中的所有成员都直接连接到ATM网络。
o All members of a LIS MUST have a mechanism for resolving IP addresses to ATM addresses via ATMARP (based on [3]) and vice versa via InATMARP (based on [12]) when using SVCs. Refer to Section 8 "LIS ADDRESS RESOLUTION SERVICES" in this memo.
o 当使用SVC时，LIS的所有成员必须有一种机制，通过ATMARP（基于[3]）将IP地址解析为ATM地址，反之亦然，通过InATMARP（基于[12]）。请参阅本备忘录第8节“LIS地址解析服务”。
o All members of a LIS MUST have a mechanism for resolving VCs to IP addresses via InATMARP (based on [12]) when using PVCs. Refer to Section 8 "LIS ADDRESS RESOLUTION SERVICES" in this memo.
o 当使用PVC时，LIS的所有成员必须有一种机制，用于通过InATMARP（基于[12]）将VCs解析为IP地址。请参阅本备忘录第8节“LIS地址解析服务”。
o All members within a LIS MUST be able to communicate via ATM with all other members in the same LIS; i.e., the Virtual Connection topology underlying the intercommunication among the members is fully meshed.
o LIS中的所有成员必须能够通过ATM与同一LIS中的所有其他成员通信；i、 例如，成员之间相互通信的基础虚拟连接拓扑是完全网状的。
The following list identifies the set of ATM specific parameters that MUST be implemented in each IP station connected to the ATM network:
以下列表确定了必须在连接到ATM网络的每个IP站中实施的一组ATM特定参数：
o ATM Hardware Address (atm$ha). The ATM address of the individual IP station.
o ATM硬件地址（ATM$ha）。单个IP站的ATM地址。
o ATMARP Request Address list (atm$arp-req-list): atm$arp-req-list is a list containing one or more ATM addresses of individual ATMARP servers located within the LIS. In an SVC environment, ATMARP servers are used to resolve target IP addresses to target ATM address via an ATMARP request and reply protocol. ATMARP servers MUST have authoritative responsibility for resolving ATMARP requests of all IP members using SVCs located within the LIS.
o ATMARP请求地址列表（atm$arp req list）：atm$arp req list是包含位于LIS内的单个ATMARP服务器的一个或多个atm地址的列表。在SVC环境中，ATMARP服务器用于通过ATMARP请求和应答协议将目标IP地址解析为目标ATM地址。ATMARP服务器必须具有使用位于LIS内的SVC解决所有IP成员的ATMARP请求的权威责任。
A LIS MUST have a single ATMARP service entry configured and available to all members of the LIS who use SVCs.
LIS必须配置一个ATMARP服务条目，并可供使用SVC的所有LIS成员使用。
In the case where there is only a single ATMARP server within the LIS, then all ATMARP clients MUST be configured identically to have only one non-null entry in atm$arp-req-list configured with the same address of the single ATMARP service.
如果LIS中只有一台ATMARP服务器，则所有ATMARP客户机必须配置相同，以便在atm$arp req列表中只有一个非空条目，该条目与单个ATMARP服务的地址相同。
If the IP member is operating with PVCs only, then atm$arp-req-list MUST be configured with all null entries and the client MUST not make queries to either address resolution service.
如果IP成员仅使用PVCs操作，则必须使用所有空条目配置atm$arp req list，并且客户端不得对任一地址解析服务进行查询。
Within the restrictions mentioned above and in Section 8, local administration MUST decide which server address(es) are appropriate for atm$arp-req-list.
在上述和第8节中提到的限制范围内，本地管理部门必须决定哪个服务器地址适合atm$arp req列表。
By default, atm$arp-req-list MUST be configured using the MIB [18].
默认情况下，必须使用MIB配置atm$arp req列表[18]。
Manual configuration of the addresses and address lists presented in this section is implementation dependent and beyond the scope of this document; i.e., this memo does not require any specific configuration method. This memo does require that these addresses MUST be configured completely on the client, as appropriate for the LIS, prior to use by any service or operation detailed in this memo.
本节所述地址和地址列表的手动配置取决于实施情况，超出了本文件的范围；i、 例如，本备忘录不需要任何特定的配置方法。本备忘录确实要求，在本备忘录中详细说明的任何服务或操作使用这些地址之前，必须在客户机上完全配置这些地址（如适用于LIS）。
It is RECOMMENDED that routers providing LIS functionality over the ATM network also support the ability to interconnect multiple LISs. Routers that wish to provide interconnection of differing LISs MUST be able to support multiple sets of these parameters (one set for each connected LIS) and be able to associate each set of parameters to a specific IP network/ subnet number. In addition, it is RECOMMENDED that a router be able to provide this multiple LIS support with a single physical ATM interface that may have one or more individual ATM endpoint addresses. NOTE: this does not necessarily mean different End System Identifiers (ESIs) when NSAPAs are used. The last octet of an NSAPA is the NSAPA Selector (SEL) field which can be used to differentiate up to 256 different LISs for the same ESI. (Refer to Section 5.1.3.1, "Private Networks" in [9].)
建议通过ATM网络提供LIS功能的路由器也支持互连多个LIS的能力。希望提供不同LIS互连的路由器必须能够支持多组这些参数（每个连接的LIS一组），并且能够将每组参数与特定IP网络/子网号关联。此外，建议路由器能够通过单个物理ATM接口提供这种多LIS支持，该接口可能具有一个或多个单独的ATM端点地址。注：使用NSAPA时，这并不一定意味着不同的终端系统标识符（ESI）。NSAPA的最后一个八位字节是NSAPA选择器（SEL）字段，可用于区分同一ESI的多达256个不同LIS。（参考[9]中的第5.1.3.1节“专用网络”）
Implementations MUST support IEEE 802.2 LLC/SNAP encapsulation as described in [2]. LLC/SNAP encapsulation is the default packet format for IP datagrams.
实现必须支持[2]中所述的IEEE 802.2 LLC/SNAP封装。LLC/SNAP封装是IP数据报的默认数据包格式。
This memo recognizes that other encapsulation methods may be used however, in the absence of other knowledge or agreement, LLC/SNAP encapsulation is the default.
本备忘录承认可以使用其他封装方法，但是，在缺乏其他知识或协议的情况下，默认为LLC/SNAP封装。
This memo recognizes that end-to-end signaling within ATM may allow negotiation of encapsulation method on a per-VC basis.
本备忘录承认ATM内的端到端信令可能允许在每个VC的基础上协商封装方法。
Protocols in wide use throughout the Internet, such as the Network File System (NFS), currently use large frame sizes (e.g., 8 KB). Empirical evidence with various applications over the Transmission Control Protocol (TCP) indicates that larger Maximum Transmission Unit (MTU) sizes for the Internet Protocol (IP) tend to give better performance. Fragmentation of IP datagrams is known to be highly undesirable [16]. It is desirable to reduce fragmentation in the network and thereby enhance performance by having the IP Maximum Transmission Unit (MTU) for AAL5 be reasonably large. NFS defaults to an 8192 byte frame size. Allowing for RPC/XDR, UDP, IP, and LLC headers, NFS would prefer a default MTU of at least 8300 octets. Routers can sometimes perform better with larger packet sizes because most of the performance costs in routers relate to "packets handled" rather than "bytes transferred". So, there are a number of good reasons to have a reasonably large default MTU value for IP over ATM AAL5.
在整个互联网上广泛使用的协议，如网络文件系统（NFS），目前使用的是较大的帧大小（例如8KB）。传输控制协议（TCP）上各种应用的经验证据表明，互联网协议（IP）的最大传输单元（MTU）越大，性能越好。众所周知，IP数据报的碎片化是非常不可取的[16]。希望通过使AAL5的IP最大传输单元（MTU）合理地大来减少网络中的分段，从而提高性能。NFS默认为8192字节的帧大小。考虑到RPC/XDR、UDP、IP和LLC头，NFS希望默认MTU至少为8300个八位字节。路由器有时在较大数据包的情况下性能更好，因为路由器中的大部分性能成本与“处理的数据包”而不是“传输的字节”有关。因此，有很多很好的理由可以为IP over ATM AAL5设置一个相当大的默认MTU值。
RFC 1209 specifies the IP MTU over SMDS to be 9180 octets, which is larger than 8300 octets but still in the same range [1]. There is no good reason for the default MTU of IP over ATM AAL5 to be different from IP over SMDS, given that they will be the same magnitude. Having the two be the same size will be helpful in interoperability and will also help reduce incidence of IP fragmentation.
RFC 1209指定SMD上的IP MTU为9180个八位字节，大于8300个八位字节，但仍在相同范围内[1]。鉴于IP over ATM AAL5的默认MTU与IP over SMD的MTU的大小相同，因此没有充分的理由使它们不同。让两者大小相同将有助于互操作性，也将有助于降低IP碎片的发生率。
Therefore, the default IP MTU for use with ATM AAL5 shall be 9180 octets. All implementations compliant and conformant with this specification shall support at least the default IP MTU value for use over ATM AAL5.
因此，与ATM AAL5一起使用的默认IP MTU应为9180八位字节。符合本规范的所有实施应至少支持通过ATM AAL5使用的默认IP MTU值。
Implementations which only support Permanent Virtual Circuits (PVCs) will (by definition) not implement any ATM signalling protocol. Such implementations shall use the default IP MTU value of 9180 octets unless both parties have agreed in advance to use some other IP MTU value via some mechanism not specified here.
仅支持永久虚拟电路（PVC）的实现（根据定义）不会实现任何ATM信令协议。此类实现应使用默认IP MTU值9180八位字节，除非双方事先同意通过此处未指定的机制使用其他IP MTU值。
Implementations that support Switched Virtual Circuits (SVCs) MUST attempt to negotiate the AAL CPCS-SDU size using the ATM signalling protocol. The industry standard ATM signalling protocol uses two different parts of the Information Element named "AAL Parameters" to exchange information on the MTU over the ATM circuit being setup [9]. The Forward Maximum CPCS-SDU Size field contains the value over the path from the calling party to the called party. The Backwards
支持交换虚拟电路（SVC）的实现必须尝试使用ATM信令协议协商AAL CPCS-SDU大小。行业标准ATM信令协议使用名为“AAL参数”的信息元素的两个不同部分，通过正在设置的ATM电路交换MTU上的信息[9]。转发最大CPCS-SDU大小字段包含从主叫方到被叫方的路径上的值。倒退
Maximum CPCS-SDU Size Identifier field contains the value over the path from the called party to the calling party. The ATM Forum specifies the valid values of this identifier as 1 to 65535 inclusive. Note that the ATM Forum's User-to-Network-Interface (UNI) signalling permits the MTU in one direction to be different from the MTU in the opposite direction, so the Forward Maximum CPCS-SDU Size Identifier might have a different value from the Backwards Maximum CPCS-SDU Size Identifier on the same connection.
最大CPCS-SDU大小标识符字段包含从被叫方到主叫方的路径上的值。ATM论坛将此标识符的有效值指定为1到65535（包括1到65535）。注意，ATM论坛的用户到网络接口（UNI）信令允许一个方向上的MTU与另一个方向上的MTU不同，因此前向最大CPCS-SDU大小标识符可能与同一连接上的后向最大CPCS-SDU大小标识符具有不同的值。
If the calling party wishes to use the default MTU it shall still include the "AAL Parameters" information element with the default values for the Maximum CPCS-SDU Size as part of the SETUP message of the ATM signalling protocol [9]. If the calling party desires to use a different value than the default, it shall include the "AAL Parameters" information element with the desired value for the Maximum CPCS-SDU Size as part of the SETUP message of the ATM Signalling Protocol. The called party will respond using the same information elements and identifiers in its CONNECT message response [9].
如果呼叫方希望使用默认MTU，它仍应包括“AAL参数”信息元素以及最大CPCS-SDU大小的默认值，作为ATM信令协议设置消息的一部分[9]。如果呼叫方希望使用不同于默认值的值，则应将“AAL参数”信息元素以及最大CPCS-SDU大小的所需值作为ATM信令协议设置消息的一部分。被叫方将在其连接消息响应中使用相同的信息元素和标识符进行响应[9]。
If the called party receives a SETUP message containing the "Maximum CPCS-SDU Size" in the AAL Parameters information element, it shall handle the Forward and Backward Maximum CPCS-SDU Size Identifier as follows:
如果被叫方收到AAL参数信息元素中包含“最大CPCS-SDU大小”的设置消息，则被叫方应按如下方式处理前向和后向最大CPCS-SDU大小标识符：
a) If it is able to accept the ATM MTU values proposed by the SETUP message, it shall include an AAL Parameters information element in its response. The Forward and Backwards Maximum CPCS-SDU Size fields shall be present and their values shall be equal to the corresponding values in the SETUP message.
a) 如果能够接受设置消息提出的ATM MTU值，则其响应中应包括AAL参数信息元素。应存在向前和向后最大CPCS-SDU大小字段，其值应等于设置消息中的相应值。
b) If it wishes a smaller ATM MTU size than that proposed, then it shall set the values of the Maximum CPCS-SDU Size in the AAL Parameters information elements equal to the desired value in the CONNECT message responding to the original SETUP message.
b) 如果希望ATM MTU的大小小于建议的大小，则应将AAL参数信息元素中的最大CPCS-SDU大小的值设置为等于响应原始设置消息的连接消息中的所需值。
c) If the calling endpoint receives a CONNECT message that does not contain the AAL Parameters Information Element, but the corresponding SETUP message did contain the AAL Parameters Information element (including the forward and backward CPCS-SDU Size fields), it shall clear the call with cause "AAL Parameters cannot be supported".
c) 如果调用端点接收到不包含AAL参数信息元素的CONNECT消息，但相应的设置消息确实包含AAL参数信息元素（包括前向和后向CPCS-SDU大小字段），则应清除调用，原因是“无法支持AAL参数”。
d) If either endpoint receives a STATUS message with cause "Information Element Non-existent or Not Implemented" or cause "Access Information Discarded", and with a diagnostic field
d) 如果任一端点接收到一条状态消息，其原因为“信息元素不存在或未实现”，或原因为“访问信息已丢弃”，且带有诊断字段
indicating the AAL Parameters Information Element identifier, it shall clear the call with cause "AAL Parameters cannot be supported."
指示AAL参数信息元素标识符时，应清除原因为“无法支持AAL参数”的调用
e) If either endpoint receives CPCS-SDUs in excess of the negotiated MTU size, it may use IP fragmentation or may clear the call with cause "AAL Parameters cannot be supported". In this case, an error has occurred either due to a fault in an end system or in the ATM network. The error should be noted by ATM network management for human examination and intervention.
e) 如果任一端点接收到的CPCS SDU超过协商的MTU大小，则可能会使用IP碎片或清除调用，原因是“无法支持AAL参数”。在这种情况下，由于终端系统或ATM网络中的故障而发生错误。ATM网络管理人员应注意错误，以便进行人工检查和干预。
If the called endpoint incorrectly includes the Forward and Backward Maximum CPCS-SDU Size fields in the CONNECT messages (e.g., because the original SETUP message did not include these fields) or it sets these fields to an invalid value, then the calling party shall clear the call with cause "Invalid Information Element Contents".
如果被调用的端点在连接消息中错误地包含前向和后向最大CPCS-SDU大小字段（例如，因为原始设置消息不包含这些字段），或者将这些字段设置为无效值，则调用方应清除调用，并导致“无效信息元素内容”。
The Path MTU Discovery mechanism is Internet Standard RFC 1191 [17] and is an important mechanism for reducing IP fragmentation in the Internet. This mechanism is particularly important because new subnet ATM uses a default MTU sizes significantly different from older subnet technologies such as Ethernet and FDDI.
路径MTU发现机制是互联网标准RFC 1191[17]，是减少互联网中IP碎片的重要机制。这种机制特别重要，因为新的子网ATM使用的默认MTU大小与旧的子网技术（如以太网和FDDI）明显不同。
In order to ensure good performance throughout the Internet and also to permit IP to take full advantage of the potentially larger IP datagram sizes supported by ATM, all router implementations that comply or conform with this specification must also implement the IP Path MTU Discovery mechanism as defined in RFC 1191 and clarified by RFC 1435 [14]. Host implementations should implement the IP Path MTU Discovery mechanism as defined in RFC 1191.
为了确保整个互联网的良好性能，并允许IP充分利用ATM支持的潜在更大的IP数据报大小，所有符合或符合本规范的路由器实现还必须实现RFC 1191中定义并由RFC 1435澄清的IP路径MTU发现机制[14]. 主机实现应实现RFC 1191中定义的IP路径MTU发现机制。
Address resolution within an ATM LIS SHALL make use of the ATM Address Resolution Protocol (ATMARP) (based on [3]) and the Inverse ATM Address Resolution Protocol (InATMARP) (based on [12]) and as defined in this memo. ATMARP is the same protocol as the ARP protocol presented in [3] with extensions needed to support address resolution in a unicast server ATM environment. InATMARP is the same protocol as the original InARP protocol presented in [12] but applied to ATM networks. All IP stations MUST support these protocols as updated and extended in this memo. Use of these protocols differs depending on whether PVCs or SVCs are used.
ATM LIS中的地址解析应使用ATM地址解析协议（ATMARP）（基于[3]）和反向ATM地址解析协议（InATMARP）（基于[12]），如本备忘录所定义。ATMARP协议与[3]中介绍的ARP协议相同，具有支持单播服务器ATM环境中地址解析所需的扩展。InATMARP与[12]中介绍的原始INAP协议相同，但适用于ATM网络。所有IP站必须支持本备忘录中更新和扩展的这些协议。这些协议的使用取决于使用的是PVC还是SVC。
An IP station MUST have a mechanism (e.g., manual configuration) for determining what PVCs it has, and in particular which PVCs are being used with LLC/SNAP encapsulation. The details of the mechanism are beyond the scope of this memo.
IP站必须有一个机制（例如，手动配置）来确定它有哪些PVC，特别是哪些PVC正与LLC/SNAP封装一起使用。该机制的细节超出了本备忘录的范围。
All IP members supporting PVCs are required to use the Inverse ATM Address Resolution Protocol (InATMARP) (refer to [12]) on those VCs using LLC/SNAP encapsulation. In a strict PVC environment, the receiver SHALL infer the relevant VC from the VC on which the InATMARP_Request or response InATMARP_Reply was received. When the ATM source and/or target address is unknown, the corresponding ATM address length in the InATMARP packet MUST be set to zero (0) indicating a null length, and no storage be allocated in the InATMARP packet, otherwise the appropriate address field should be filled in and the corresponding length set appropriately. InATMARP packet format details are presented later in this memo.
所有支持PVC的IP成员都需要在使用LLC/SNAP封装的VCs上使用反向ATM地址解析协议（InATMARP）（参考[12]）。在严格的PVC环境中，接收方应根据收到InATMARP_请求或响应InATMARP_回复的VC推断相关VC。当ATM源地址和/或目标地址未知时，InATMARP数据包中相应的ATM地址长度必须设置为零（0），表示长度为空，并且不在InATMARP数据包中分配存储，否则应填写适当的地址字段并适当设置相应的长度。InATMARP数据包格式的详细信息将在本备忘录后面介绍。
Directly from [12]: "When the requesting station receives the In[ATM]ARP_Reply, it may complete the [ATM]ARP table entry and use the provided address information. NOTE: as with [ATM]ARP, information learned via In[ATM]ARP may be aged or invalidated under certain circumstances." IP stations supporting PVCs MUST re-validate ATMARP table entries as part of the table aging process. See the Section 8.5.1 "Client ATMARP Table Aging".
直接从[12]：“当请求站收到In[ATM]ARP_回复时，它可以完成[ATM]ARP表条目并使用提供的地址信息。注意：与[ATM]ARP一样，通过In[ATM]ARP获取的信息在某些情况下可能会老化或失效。”作为表老化过程的一部分，支持PVC的IP站必须重新验证ATMARP表条目。参见第8.5.1节“客户ATMARP表老化”。
If a client has more than one IP address within the LIS and if using PVCs, when an InATMARP_Request is received an InATMARP_Reply MUST be generated for each such address.
如果客户机在LIS中有多个IP地址，并且如果使用PVCs，则在收到InATMARP_请求时，必须为每个此类地址生成InATMARP_回复。
SVCs require support from address resolution services for resolving target IP addresses to target ATM endpoint addresses. All members in the LIS MUST use the same service. This service MUST have authoritative responsibility for resolving the ATMARP requests of all IP members within the LIS.
SVC需要地址解析服务的支持，以将目标IP地址解析为目标ATM端点地址。LIS中的所有成员必须使用相同的服务。该服务必须具有解决LIS内所有IP成员的ATMARP请求的权威责任。
ATMARP servers do not actively establish connections. They depend on the clients in the LIS to initiate connections for the ATMARP registration procedure and for transmitting ATMARP requests. An individual client connects to the ATMARP server using a point-to-point LLC/SNAP VC. The client sends normal ATMARP request packets to the server. The ATMARP server examines each ATMARP_Request packet for
ATMARP服务器不主动建立连接。它们依赖于LIS中的客户机来启动ATMARP注册过程和传输ATMARP请求的连接。单个客户端使用点对点LLC/SNAP VC连接到ATMARP服务器。客户端向服务器发送正常的ATMARP请求数据包。ATMARP服务器检查每个ATMARP_请求数据包的
the source protocol and source hardware address information of the sending client and uses this information to build its ATMARP table cache. This information is used to generate replies to any ATMARP requests it receives.
发送客户端的源协议和源硬件地址信息，并使用此信息构建其ATMARP表缓存。此信息用于生成对收到的任何ATMARP请求的答复。
InATMARP_Request packets MUST specify valid address information for ATM source number, ATM target number, and source protocol address; i.e., these fields MUST be non-null in InATMARP_Request packets.
InATMARP_请求数据包必须指定ATM源编号、ATM目标编号和源协议地址的有效地址信息；i、 例如，在InATMARP_请求数据包中，这些字段必须为非空。
This memo defines the address resolution service in the LIS and constrains it to consist of a single ATMARP server. Client-server interaction is defined by using a single server approach as a reference model.
此备忘录定义了LIS中的地址解析服务，并将其限制为由单个ATMARP服务器组成。客户机-服务器交互是通过使用单服务器方法作为参考模型来定义的。
This memo recognizes the future development of standards and implementations of multiple-ATMARP-server models that will extend the operations as defined in this memo to provide a highly reliable address resolution service.
本备忘录确认了多个ATMARP服务器模型的标准和实现的未来发展，这些模型将扩展本备忘录中定义的操作，以提供高度可靠的地址解析服务。
A single ATMARP server accepts ATM calls/connections from other ATM end points. After receiving any ATMARP_Request, the server will examine the source and target address information in the packet and make note of the VC on which the ATMARP_Request arrived. It will use this information as necessary to build and update its ATMARP table entries.
单个ATMARP服务器接受来自其他ATM端点的ATM呼叫/连接。在收到任何ATMARP_请求后，服务器将检查数据包中的源地址和目标地址信息，并记录ATMARP_请求到达的VC。它将根据需要使用此信息来构建和更新其ATMARP表条目。
For each ATMARP_Request, then:
对于每个ATMARP_请求，则：
1. If the source IP protocol address is the same as the target IP protocol address and a table entry exists for that IP address and if the source ATM hardware address does not match the table entry ATM address and there is an open VC associated with that table entry that is not the same as the VC associated with the ATMARP_Request, the server MUST return the table entry information in the ATMARP_Reply, and MUST raise a "duplicate IP address detected" condition to the server's management. The table entry is not updated.
1. 如果源IP协议地址与目标IP协议地址相同，并且该IP地址存在一个表项，并且如果源ATM硬件地址与表项ATM地址不匹配，并且与该表项关联的开放VC与与与ATMARP_请求关联的VC不相同，服务器必须在ATMARP_回复中返回表条目信息，并且必须向服务器管理层提出“检测到重复IP地址”条件。表条目未更新。
2. Otherwise, if the source IP protocol address is the same as the target IP protocol address, and either there is no table entry for that IP address, or a table entry exists for that IP address and there is no open VC associated with that table entry, or if the VC associated with that entry is the same as the VC for the ATMARP_Request, the server MUST either create a new entry or update the old entry as appropriate and return that table entry information in the ATMARP Reply.
2. 否则，如果源IP协议地址与目标IP协议地址相同，并且该IP地址没有表项，或者该IP地址存在表项，并且没有与该表项关联的开放VC，或者如果与该项关联的VC与ATMARP_请求的VC相同，服务器必须根据需要创建新条目或更新旧条目，并在ATMARP回复中返回该表条目信息。
3. Otherwise, when the source IP protocol address does not match the target IP protocol address, the ATMARP server will generate the corresponding ATMARP_Reply if it has an entry for the target information in its ATMARP table. Otherwise, it will generate a negative ATMARP reply (ATMARP_NAK).
3. 否则，当源IP协议地址与目标IP协议地址不匹配时，如果ATMARP服务器的ATMARP表中有目标信息条目，则ATMARP服务器将生成相应的ATMARP_回复。否则，它将生成一个否定的ATMARP回复（ATMARP_NAK）。
4. Additionally, when the source IP protocol address does not match the target IP protocol address and when the server receives an ATMARP_Request over a VC, where the source IP and ATM address do not have a corresponding table entry, the ATMARP server MUST create a new table entry for the source information. Explanation: this allows old RFC 1577 clients to register with this ATMARP service by just issuing requests to it.
4. 此外，当源IP协议地址与目标IP协议地址不匹配，并且当服务器通过VC接收到ATMARP_请求时，如果源IP和ATM地址没有相应的表条目，则ATMARP服务器必须为源信息创建新的表条目。说明：这允许旧的RFC1577客户端通过向ATMARP服务发出请求来注册。
5. Additionally, when the source IP protocol address does not match the target IP protocol address and where the source IP and ATM addresses match the association already in the ATMARP table and the ATM address matches that associated with the VC, the server MUST update the table timeout on the source ATMARP table entry but only if it has been more than 10 minutes since the last update. Explanation: if the client is sending ATMARP requests to the server over the same VC that it used to register its ATMARP entry, the server should examine the ATMARP request and note that the client is still "alive" by updating the timeout on the client's ATMARP table entry.
5. 此外，当源IP协议地址与目标IP协议地址不匹配，且源IP和ATM地址与ATMARP表中已有的关联匹配，且ATM地址与VC关联的关联匹配时，服务器必须更新源ATMARP表项上的表超时，但前提是自上次更新以来已超过10分钟。说明：如果客户机通过用于注册其ATMARP条目的同一VC向服务器发送ATMARP请求，则服务器应检查ATMARP请求，并通过更新客户机ATMARP表条目上的超时来注意客户机仍处于“活动”状态。
6. Additionally, when the source IP protocol address does not match the target IP protocol address and where the source IP and ATM addresses do not match the association already in the ATMARP table, the server MUST NOT update the ATMARP table entry.
6. 此外，当源IP协议地址与目标IP协议地址不匹配，并且源IP和ATM地址与ATMARP表中已有的关联不匹配时，服务器不得更新ATMARP表条目。
An ATMARP server MUST have knowledge of any open VCs it has and their association with an ATMARP table entry, and in particular, which VCs support LLC/SNAP encapsulation. In normal operation, active ATMARP clients will revalidate their entries prior to the server aging process taking effect.
ATMARP服务器必须了解其拥有的任何开放VCs及其与ATMARP表项的关联，特别是哪些VCs支持LLC/SNAP封装。在正常操作中，活动ATMARP客户端将在服务器老化过程生效之前重新验证其条目。
Server ATMARP table entries are valid for 20 minutes. If an entry ages beyond 20 minutes without being updated (refreshed) by the client, that entry is deleted from the table regardless of the state of any VCs that may be associated with that entry.
服务器ATMARP表条目有效期为20分钟。如果某个条目的使用时间超过20分钟而未被客户端更新（刷新），则无论与该条目相关联的任何VCs的状态如何，该条目都将从表中删除。
The ATMARP client is responsible for contacting the ATMARP service to both initially register and subsequently refresh its own ATMARP information.
ATMARP客户端负责联系ATMARP服务，以便最初注册并随后刷新其自身的ATMARP信息。
The client is also responsible for using the ATMARP service to gain and revalidate ATMARP information about other IP members in the LIS (server selection overview is discussed in Section 8.6). As noted in Section 5.2, ATMARP clients MUST be configured with the ATM address of the appropriate server prior to client ATMARP operation.
客户还负责使用ATMARP服务获取和重新验证有关LIS中其他IP成员的ATMARP信息（服务器选择概述在第8.6节中讨论）。如第5.2节所述，在客户端ATMARP操作之前，必须为ATMARP客户端配置相应服务器的ATM地址。
IP clients MUST register their ATM endpoint address with their ATMARP server using the ATM address structure appropriate for their ATM network connection: i.e., LISs implemented over ATM LANs following ATM Forum UNI 3.1 should register using Structure 1; LISs implemented over an E.164 "public" ATM network should register using Structure 2. A LIS implemented over a combination of ATM LANs and public ATM networks may need to register using Structure 3. Implementations based on this memo MUST support all three ATM address structures. See Section 8.7.1 for more details regarding the ATMARP Request packet format.
IP客户端必须使用适合其ATM网络连接的ATM地址结构向其ATMARP服务器注册其ATM端点地址：即，在ATM论坛UNI 3.1之后通过ATM LAN实现的LISs应使用结构1注册；通过E.164“公共”ATM网络实现的LISs应使用结构2进行注册。通过ATM LAN和公共ATM网络的组合实现的LIS可能需要使用结构3进行注册。基于此备忘录的实现必须支持所有三种ATM地址结构。有关ATMARP请求数据包格式的更多详细信息，请参见第8.7.1节。
To handle the case when a client has more than one IP address within a LIS, when using an ATMARP server, the client MUST register each such address.
要处理客户机在LIS中具有多个IP地址的情况，在使用ATMARP服务器时，客户机必须注册每个此类地址。
For initial registration and subsequent refreshing of its own information with the ATMARP service, clients MUST:
对于在ATMARP服务中首次注册和随后刷新自己的信息，客户必须：
1. Establish an LLC/SNAP VC connection to a server in the ATMARP service for the purposes of transmitting and receiving ATMARP packets.
1. 建立与ATMARP服务中服务器的LLC/SNAP VC连接，以发送和接收ATMARP数据包。
NOTE: in the case of refreshing its own information with the ATMARP service, a client MAY reuse an existing established connection to the ATMARP service provided that the connection was previously used either to initially register its information with the ATMARP service or to refresh its information with the ATMARP service.
注意：在使用ATMARP服务刷新其自身信息的情况下，客户机可以重用与ATMARP服务的现有已建立连接，前提是该连接以前用于最初向ATMARP服务注册其信息或向ATMARP服务刷新其信息。
2. After establishing a successful connection to the ATMARP service, the client MUST transmit an ATMARP_Request packet, requesting a target ATM address for its own IP address as the target IP protocol address. The client checks the ATMARP_Reply and if the source hardware and protocol addresses match the respective target hardware and protocol addresses, the client is registered with the ATMARP service. If the addresses do not match, the client MAY take action, raise alarms, etc.; however, these actions are beyond the scope of this memo. In the case of a client having more than one IP address in the list, this step MUST be repeated for each IP address.
2. 成功建立到ATMARP服务的连接后，客户端必须发送一个ATMARP_请求数据包，为其自身的IP地址请求一个目标ATM地址作为目标IP协议地址。客户端检查ATMARP_回复，如果源硬件和协议地址与相应的目标硬件和协议地址匹配，则客户端将向ATMARP服务注册。如果地址不匹配，客户可以采取行动、发出警报等。；然而，这些行动超出了本备忘录的范围。如果客户机列表中有多个IP地址，则必须对每个IP地址重复此步骤。
3. Clients MUST respond to ATMARP_Request and InATMARP_Request packets received on any VC appropriately. (Refer to Section 7, "Protocol Operation" in RFC 1293 [12].)
3. 客户端必须适当地响应任何VC上接收到的ATMARP_请求和InATMARP_请求数据包。（参考RFC 1293[12]中的第7节“协议操作”）
NOTE: for reasons of robustness, clients MUST respond to ATMARP_Requests.
注意：出于稳健性的原因，客户端必须响应ATMARP_请求。
4. Generate and transmit address resolution request packets to the address resolution service. Respond to address resolution reply packets appropriately to build/refresh its own client ATMARP table entries.
4. 生成地址解析请求包并将其发送到地址解析服务。适当地响应地址解析应答包，以构建/刷新其自己的客户端ATMARP表条目。
5. Generate and transmit InATMARP_Request packets as needed and process InATMARP_Reply packets appropriately. InATMARP_Reply packets should be used to build/refresh its own client ATMARP table entries. (Refer to Section 7, "Protocol Operation" in [12].) If a client has more than one IP address within the LIS when an InATMARP_Request is received an InATMARP_Reply MUST be generated for each such address.
5. 根据需要生成和发送InATMARP_请求数据包，并适当处理InATMARP_回复数据包。应使用InATMARP_回复数据包构建/刷新其自己的客户端ATMARP表条目。（参考[12]中的第7节“协议操作”）如果当收到InATMARP_请求时，客户机在LIS中有多个IP地址，则必须为每个地址生成InATMARP_回复。
The client MUST refresh its ATMARP information with the server at least once every 15 minutes. This is done by repeating steps 1 and 2.
客户端必须至少每15分钟向服务器刷新一次其ATMARP信息。这可以通过重复步骤1和2来完成。
An ATMARP client MUST have knowledge of any open VCs it has (permanent or switched), their association with an ATMARP table entry, and in particular, which VCs support LLC/SNAP encapsulation.
ATMARP客户必须了解其拥有的任何开放式VCs（永久或交换）、它们与ATMARP表项的关联，特别是哪些VCs支持LLC/SNAP封装。
Client ATMARP table entries are valid for a maximum time of 15 minutes.
客户端ATMARP表项的有效时间最长为15分钟。
When an ATMARP table entry ages, an ATMARP client MUST invalidate the table entry. If there is no open VC server associated with the invalidated entry, that entry is deleted. In the case of an invalidated entry and an open VC, the client MUST revalidate the entry prior to transmitting any non address resolution traffic on that VC; this requirement applies to both PVCs and SVCs. NOTE: the client is permitted to revalidate an ATMARP table entry before it ages, thus restarting the aging time when the table entry is successfully revalidated. The client MAY continue to use the open VC, as long as the table entry has not aged, while revalidation is in progress.
当ATMARP表条目过期时，ATMARP客户端必须使该表条目无效。如果没有与无效条目关联的打开的VC服务器，则该条目将被删除。在无效条目和开放VC的情况下，客户必须在该VC上传输任何非地址解析流量之前重新验证条目；该要求适用于PVC和SVC。注意：允许客户端在ATMARP表项老化之前重新验证该表项，从而在成功重新验证该表项时重新启动老化时间。在重新验证过程中，只要表项没有老化，客户端可以继续使用OpenVC。
In the case of an open PVC, the client revalidates the entry by transmitting an InATMARP_Request and updating the entry on receipt of an InATMARP_Reply.
在开放PVC的情况下，客户端通过发送InATMARP_请求并在收到InATMARP_回复时更新条目来重新验证条目。
In the case of an open SVC, the client revalidates the entry by querying the address resolution service. If a valid reply is received (e.g., ATMARP_Reply), the entry is updated. If the address resolution service cannot resolve the entry (i.e., "host not found"), the SVC should be closed and the associated table entry removed. If the address resolution service is not available (i.e., "server failure") and if the SVC is LLC/SNAP encapsulated, the client MUST attempt to revalidate the entry by transmitting an InATMARP_Request on that VC and updating the entry on receipt of an InATMARP_Reply. If the InATMARP_Request attempt fails to return an InATMARP_Reply, the SVC should be closed and the associated table entry removed.
对于打开的SVC，客户端通过查询地址解析服务重新验证条目。如果收到有效回复（如ATMARP_回复），则更新条目。如果地址解析服务无法解析条目（即“找不到主机”），则应关闭SVC并删除关联的表条目。如果地址解析服务不可用（即“服务器故障”），并且SVC是LLC/SNAP封装的，则客户端必须尝试通过在该VC上发送InATMARP_请求并在收到InATMARP_回复时更新条目来重新验证条目。如果InATMARP_请求尝试未能返回InATMARP_回复，则应关闭SVC并删除关联的表项。
If a VC with an associated invalidated ATMARP table entry is closed, that table entry is removed.
如果关闭了具有关联的无效ATMARP表项的VC，则该表项将被删除。
The specific details on client procedures for detecting non-normal VC connection establishment or closures, or failed communications on an established VC are beyond the scope of this memo. It is REQUIRED however, that the client MUST remove the associated ATMARP entry for a VC that fails to operate properly, as defined by the client, when the client closes that VC, when it releases its resources for a VC, or prior to any attempt to reopen that VC. This behavior specifically REQUIRES that the client MUST refresh its ATMARP table information prior to any attempt to re-establish communication to an IP member after a non-normal communications problem has previously occurred on a VC to that IP member.
有关检测非正常VC连接建立或关闭，或已建立VC上通信失败的客户端程序的具体细节超出本备忘录的范围。但是，当客户关闭某个VC、释放其资源用于某个VC或在尝试重新打开该VC之前，客户必须删除该VC的相关ATMARP条目，该VC无法正常运行（如客户所定义）。此行为特别要求，在VC与某个IP成员之前发生非正常通信问题后，在尝试与该IP成员重新建立通信之前，客户端必须刷新其ATMARP表信息。
When an ATM LIS is used as the home network in a mobile-IP scenario, it is RECOMMENDED that the home agent NOT maintain long term connections with the ATMARP service. The absence of this VC will permit a mobile node's registration, upon its return to the home network, to immediately preempt the home agent's previous gratuitous registration.
当ATM LIS用作移动IP场景中的家庭网络时，建议家庭代理不要与ATMARP服务保持长期连接。没有此VC将允许移动节点的注册在其返回到家庭网络时立即抢占家庭代理先前的免费注册。
If the client supports PVCs only, the ATMARP server list is empty and the client MUST not generate any address resolution requests other than the InATMARP requests on a PVC needed to validate that PVC.
如果客户端仅支持PVCs，则ATMARP服务器列表为空，并且客户端不得在PVC上生成除验证该PVC所需的InATMARP请求以外的任何地址解析请求。
If the client supports SVCs, then the client MUST have a non-NULL atm$arp-req-list pointing to the ATMARP server(s) which provides ATMARP service for the LIS.
如果客户端支持SVC，则客户端必须有一个非空的atm$arp req列表，指向为LIS提供ATMARP服务的ATMARP服务器。
The client MUST register with a server from atm$arp-req-list.
客户端必须从atm$arp req列表向服务器注册。
The client SHALL attempt to communicate with any of the servers until a successful registration is accomplished. The order in which client selects servers to attempt registration, is a local matter, as are the number of retries and timeouts for such attempts.
客户端应尝试与任何服务器通信，直到成功注册。客户机选择服务器尝试注册的顺序是本地问题，重试次数和超时次数也是本地问题。
In a mixed PVC and SVC LIS environment, an ATMARP client MAY have a PVC to an ATMARP server. In this case, this PVC is used for ATMARP requests and responses as if it were an established SVC. NOTE: if this PVC is to be used for IP traffic, then the ATMARP server MUST be prepared to accept and respond appropriately to InATMARP traffic.
在混合PVC和SVC LIS环境中，ATMARP客户机可能具有连接到ATMARP服务器的PVC。在本例中，此PVC用于ATMARP请求和响应，就像它是一个已建立的SVC一样。注意：如果此PVC用于IP流量，则ATMARP服务器必须准备好接受并适当响应InATMARP流量。
Internet addresses are assigned independently of ATM addresses. Each host implementation MUST know its own IP and ATM address(es) and MUST respond to address resolution requests appropriately. IP members MUST also use ATMARP and InATMARP to resolve IP addresses to ATM addresses when needed.
Internet地址的分配独立于ATM地址。每个主机实现必须知道自己的IP和ATM地址，并且必须适当地响应地址解析请求。IP成员还必须在需要时使用ATMARP和InATMARP将IP地址解析为ATM地址。
NOTE: the ATMARP packet format presented in this memo is general in nature in that the ATM number and ATM subaddress fields SHOULD map directly to the corresponding UNI 3.1 fields used for ATM call/connection setup signalling messages. The IP over ATM Working Group expects ATM Forum NSAPA numbers (Structure 1) to predominate over E.164 numbers (Structure 2) as ATM endpoint identifiers within ATM LANs. The ATM Forum's VC Routing specification is not complete at this time and therefore its impact on the operational use of ATM Address Structure 3 is undefined. The ATM Forum will be defining this relationship in the future. It is for this reason that IP members need to support all three ATM address structures.
注：本备忘录中提供的ATMARP数据包格式本质上是通用的，因为ATM号码和ATM子地址字段应直接映射到用于ATM呼叫/连接设置信令消息的相应UNI 3.1字段。IP over ATM工作组期望ATM论坛NSAPA号码（结构1）作为ATM LAN内的ATM端点标识符，将超过E.164号码（结构2）。ATM论坛的VC路由规范目前还不完整，因此其对ATM地址结构3的操作使用的影响尚未定义。ATM论坛将在未来定义这种关系。正是由于这个原因，IP成员需要支持所有三种ATM地址结构。
The ATMARP and InATMARP request and reply protocols use the same hardware type (ar$hrd), protocol type (ar$pro), and operation code (ar$op) data formats as the ARP and InARP protocols [3,12]. The location of these three fields within the ATMARP packet are in the same byte position as those in ARP and InARP packets. A unique hardware type value has been assigned for ATMARP. In addition, ATMARP makes use of an additional operation code for ARP_NAK. The remainder of the ATMARP/InATMARP packet format is different than the ARP/InARP packet format.
ATMARP和InATMARP请求和应答协议使用与ARP和InARP协议相同的硬件类型（ar$hrd）、协议类型（ar$pro）和操作代码（ar$op）数据格式[3,12]。这三个字段在ATMARP数据包中的位置与ARP和INAP数据包中的位置相同。已为ATMARP分配了唯一的硬件类型值。此外，ATMARP还为ARP_NAK使用了一个额外的操作代码。ATMARP/InATMARP数据包格式的其余部分与ARP/InARP数据包格式不同。
The ATMARP and InATMARP protocols have several fields that have the following format and values:
ATMARP和InATMARP协议有几个字段，其格式和值如下：
Data: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type ar$shtl 8 bits Type & length (TL) of source ATM number (q) ar$sstl 8 bits Type & length (TL) of source ATM subaddress (r) ar$op 16 bits Operation code (request, reply, or NAK) ar$spln 8 bits Length of source protocol address (s) ar$thtl 8 bits Type & length (TL) of target ATM number (x) ar$tstl 8 bits Type & length (TL) of target ATM subaddress (y) ar$tpln 8 bits Length of target protocol address (z) ar$sha qoctets of source ATM number ar$ssa roctets of source ATM subaddress ar$spa soctets of source protocol address ar$tha xoctets of target ATM number ar$tsa yoctets of target ATM subaddress ar$tpa zoctets of target protocol address
数据：ar$hrd 16位硬件类型ar$pro 16位协议类型ar$shtl 8位源ATM号类型和长度（TL）ar$sstl 8位源ATM子地址类型和长度（TL）ar$op 16位操作码（请求、应答或NAK）ar$spln 8位源协议地址长度（s）ar$thtl 8位目标ATM号类型和长度（TL）（x） ar$tstl目标ATM子地址的8位类型和长度（TL）（y）ar$tpln目标协议地址的8位长度（z）ar$sha源ATM数量的qoctets ar$ssa源ATM子地址的ROCTTETS ar$spa源协议地址的soctets ar$tha目标ATM数量的xoctets ar$tsa目标ATM子地址的yoctets ar$tpa目标协议地址的zoctets
Where: ar$hrd - assigned to ATM Forum address family and is 19 decimal (0x0013) [4].
其中：ar$hrd-分配给ATM论坛地址系列，十进制为19（0x0013）[4]。
ar$pro - see Assigned Numbers for protocol type number for the protocol using ATMARP. (IP is 0x0800).
ar$pro-有关使用ATMARP的协议的协议类型编号，请参阅分配编号。（IP为0x0800）。
ar$shtl - Type and length of source ATM number. See Section 8.7.4 for TL encoding details.
ar$shtl—源ATM号码的类型和长度。TL编码详情见第8.7.4节。
ar$sstl - Type and length of source ATM subaddress. See Section 8.7.4 for TL encoding details.
ar$sstl—源ATM子地址的类型和长度。TL编码详情见第8.7.4节。
ar$op - The operation type value (decimal):
ar$op—操作类型值（十进制）：
ATMARP_Request = ARP_REQUEST = 1
ATMARP_Reply = ARP_REPLY = 2
InATMARP_Request = InARP_REQUEST = 8
InATMARP_Reply = InARP_REPLY = 9
ATMARP_NAK = ARP_NAK = 10
ATMARP_Request = ARP_REQUEST = 1
ATMARP_Reply = ARP_REPLY = 2
InATMARP_Request = InARP_REQUEST = 8
InATMARP_Reply = InARP_REPLY = 9
ATMARP_NAK = ARP_NAK = 10
ar$spln - length in octets of the source protocol address. Value range is 0 or 4 (decimal). For IPv4 ar$spln is 4.
ar$spln—源协议地址的八位字节长度。值范围为0或4（十进制）。对于IPv4，ar$spln为4。
ar$thtl - Type and length of target ATM number. See Section 8.7.4 for TL encoding details.
ar$thtl—目标ATM号码的类型和长度。TL编码详情见第8.7.4节。
ar$tstl - Type and length of target ATM subaddress. See Section 8.7.4 for TL encoding details.
ar$tstl—目标ATM子地址的类型和长度。TL编码详情见第8.7.4节。
ar$tpln - length in octets of the target protocol address. Value range is 0 or 4 (decimal). For IPv4 ar$tpln is 4.
ar$tpln—目标协议地址的八位字节长度。值范围为0或4（十进制）。对于IPv4 ar，$tpln是4。
ar$sha - source ATM number (E.164 or ATM Forum NSAPA)
ar$sha-源ATM号码（E.164或ATM论坛NSAPA）
ar$ssa - source ATM subaddress (ATM Forum NSAPA)
ar$ssa-源ATM子地址（ATM论坛NSAPA）
ar$spa - source protocol address
ar$spa-源协议地址
ar$tha - target ATM number (E.164 or ATM Forum NSAPA)
ar$tha-目标ATM号码（E.164或ATM论坛NSPA）
ar$tsa - target ATM subaddress (ATM Forum NSAPA)
ar$tsa-目标ATM子地址（ATM论坛NSAPA）
ar$tpa - target protocol address
ar$tpa-目标协议地址
If an ATMARP client receives an ATMARP message with an operation code (ar$op) for which it is not coded to support, it MUST gracefully discard the message and continue normal operation. An ATMARP client is NOT REQUIRED to return any message to the sender of the unsupported message.
如果ATMARP客户端接收到带有操作代码（ar$op）的ATMARP消息，而该操作代码（ar$op）未被编码为支持该操作，则它必须优雅地丢弃该消息并继续正常操作。不需要ATMARP客户端将任何消息返回给不受支持消息的发件人。
The encoding of the 8-bit TL (type and length) fields in ATMARP and In_ATMARP packets is as follows:
ATMARP和in_ATMARP数据包中8位TL（类型和长度）字段的编码如下：
MSB 8 7 6 5 4 3 2 1 LSB
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | 1/0 | Octet length of address |
+-----+-----+-----+-----+-----+-----+-----+-----+
MSB 8 7 6 5 4 3 2 1 LSB
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | 1/0 | Octet length of address |
+-----+-----+-----+-----+-----+-----+-----+-----+
Where: bit.8 (reserved) = 0 (for future use)
式中：位8（保留）=0（供将来使用）
bit.7 (type) = 0 ATM Forum NSAPA format = 1 E.164 format
位7（类型）=0 ATM论坛NSAPA格式=1 E.164格式
bit.6-1 (length) = 6 bit unsigned octet length of address (MSB = bit.6, LSB = bit.1) Value range is from 0 to 20 (decimal).
位.6-1（长度）=地址的6位无符号八位字节长度（MSB=位.6，LSB=位.1）值范围为0到20（十进制）。
ATM addresses, as defined by the ATM Forum UNI 3.1 signaling specification [9], include a "Calling Party Number Information Element" and a "Calling Party Subaddress Information Element". These Information Elements (IEs) SHOULD map to ATMARP/InATMARP source ATM number and source ATM subaddress respectively. Furthermore, ATM Forum defines a "Called Party Number Information Element" and a "Called Party Subaddress Information Element". These IEs map to ATMARP/InATMARP target ATM number and target ATM subaddress, respectively.
ATM地址由ATM论坛UNI 3.1信令规范[9]定义，包括“主叫方号码信息元素”和“主叫方子地址信息元素”。这些信息元素应分别映射到ATMARP/InATMARP源ATM号和源ATM子地址。此外，ATM论坛定义了“被叫方号码信息元素”和“被叫方子地址信息元素”。这些IEs分别映射到ATMARP/InATMARP目标ATM号和目标ATM子地址。
The ATM Forum defines three structures for the combined use of number and subaddress [9]:
ATM论坛为数字和子地址的组合使用定义了三种结构[9]：
ATM Number ATM Subaddress
-------------- --------------
Structure 1 ATM Forum NSAPA null
Structure 2 E.164 null
Structure 3 E.164 ATM Forum NSAPA
ATM Number ATM Subaddress
-------------- --------------
Structure 1 ATM Forum NSAPA null
Structure 2 E.164 null
Structure 3 E.164 ATM Forum NSAPA
ATMARP and InATMARP requests and replies for ATM address structures 1 and 2 MUST indicate a null or unknown ATM subaddress by setting the appropriate subaddress length to zero; i.e., ar$sstl.length = 0 or ar$tstl.length = 0, the corresponding type field (ar$sstl.type or ar$tstl.type) MUST be ignored and the physical space for the ATM subaddress buffer MUST not be allocated in the ATMARP packet. For example, if ar$sstl.length=0, the storage for the source ATM subaddress is not allocated and the first byte of the source protocol address ar$spa follows immediately after the last byte of the source hardware address ar$sha in the packet.
ATM地址结构1和2的ATMARP和InATMARP请求和回复必须通过将适当的子地址长度设置为零来指示空或未知的ATM子地址；i、 例如，ar$sstl.length=0或ar$tstl.length=0时，必须忽略相应的类型字段（ar$sstl.type或ar$tstl.type），并且不得在ATMARP数据包中分配ATM子地址缓冲区的物理空间。例如，如果ar$sstl.length=0，则不分配源ATM子地址的存储，并且源协议地址ar$spa的第一个字节紧跟在数据包中源硬件地址ar$sha的最后一个字节之后。
Null or unknown ATM addresses MUST be indicated by setting the appropriate address length to zero; i.e., ar$shtl.length and ar$thtl.length is zero and the corresponding type field (ar$sstl.type or ar$tstl.type) MUST be ignored and the physical space for the ATM address or ATM subaddress buffer MUST not be allocated in the ATMARP packet.
空或未知ATM地址必须通过将适当的地址长度设置为零来表示；i、 例如，ar$shtl.length和ar$thtl.length为零，必须忽略相应的类型字段（ar$sstl.type或ar$tstl.type），并且不得在ATMARP数据包中分配ATM地址或ATM子地址缓冲区的物理空间。
The ATMARP_NAK packet format is the same as the received ATMARP_Request packet format with the operation code set to ARP_NAK, i.e., the ATMARP_Request packet data is exactly copied (e.g., using bcopy) for transmission with the ATMARP_Request operation code changed to ARP_NAK value.
ATMARP_NAK数据包格式与接收到的ATMARP_请求数据包格式相同，操作代码设置为ARP_NAK，即ATMARP_请求数据包数据被精确复制（例如，使用bcopy）以进行传输，ATMARP_请求操作代码更改为ARP_NAK值。
ATMARP and InATMARP packets are variable in length.
ATMARP和InATMARP数据包的长度是可变的。
A null or unknown source or target protocol address is indicated by the corresponding length set to zero: e.g., when ar$spln or ar$tpln is zero the physical space for the corresponding address structure MUST not be allocated in the packet.
空或未知源或目标协议地址由设置为零的相应长度表示：例如，当ar$spln或ar$tpln为零时，不得在数据包中分配相应地址结构的物理空间。
For backward compatibility with previous implementations, a null IPv4 protocol address may be received with length = 4 and an allocated address in storage set to the value 0.0.0.0. Receiving stations MUST be liberal in accepting this format of a null IPv4 address. However, on transmitting an ATMARP or InATMARP packet, a null IPv4 address MUST only be indicated by the length set to zero and MUST have no storage allocated.
为了与以前的实现向后兼容，可以接收长度为4的空IPv4协议地址，并将存储中的分配地址设置为值0.0.0.0。接收站必须自由地接受这种空IPv4地址格式。但是，在传输ATMARP或InATMARP数据包时，空IPv4地址必须仅由设置为零的长度指示，并且不得分配任何存储。
ATMARP and InATMARP packets are to be encoded in AAL5 PDUs using LLC/SNAP encapsulation. The format of the AAL5 CPCS-SDU payload field for ATMARP/InATMARP PDUs is:
ATMARP和InATMARP数据包将使用LLC/SNAP封装在AAL5 PDU中进行编码。ATMARP/InATMARP PDU的AAL5 CPCS-SDU有效载荷字段的格式为：
Payload Format for ATMARP/InATMARP PDUs:
+------------------------------+
| LLC 0xAA-AA-03 |
+------------------------------+
| OUI 0x00-00-00 |
+------------------------------+
| EtherType 0x08-06 |
+------------------------------+
| |
| ATMARP/InATMARP Packet |
| |
+------------------------------+
Payload Format for ATMARP/InATMARP PDUs:
+------------------------------+
| LLC 0xAA-AA-03 |
+------------------------------+
| OUI 0x00-00-00 |
+------------------------------+
| EtherType 0x08-06 |
+------------------------------+
| |
| ATMARP/InATMARP Packet |
| |
+------------------------------+
The LLC value of 0xAA-AA-03 (3 octets) indicates the presence of a SNAP header.
LLC值0xAA-AA-03（3个八位字节）表示存在快照标头。
The OUI value of 0x00-00-00 (3 octets) indicates that the following two-bytes is an EtherType.
0x00-00-00（3个八位字节）的OUI值表示以下两个字节是以太类型。
The EtherType value of 0x08-06 (2 octets) indicates ARP [4].
EtherType值0x08-06（2个八位字节）表示ARP[4]。
The total size of the LLC/SNAP header is fixed at 8-octets. This aligns the start of the ATMARP packet on a 64-bit boundary relative to the start of the AAL5 CPCS-SDU.
LLC/SNAP标头的总大小固定为8个八位字节。这将使64位边界上的ATMARP数据包的起点与AAL5 CPCS-SDU的起点对齐。
The LLC/SNAP encapsulation for ATMARP/InATMARP presented here is consistent with the treatment of multiprotocol encapsulation of IP over ATM AAL5 as specified in [2] and in the format of ATMARP over IEEE 802 networks as specified in [5].
此处给出的ATMARP/InATMARP的LLC/SNAP封装与[2]中规定的ATM AAL5上IP的多协议封装处理以及[5]中规定的IEEE 802网络上的ATMARP格式一致。
Traditionally, address resolution requests are broadcast to all directly connected IP members within a LIS. It is conceivable in the future that larger scaled ATM networks may handle ATMARP requests to destinations outside the originating LIS, perhaps even globally; issues raised by ATMARPing outside the LIS or by a global ATMARP mechanism are beyond the scope of this memo.
传统上，地址解析请求会广播给LIS中所有直接连接的IP成员。可以想象，在未来，更大规模的ATM网络可能会处理到原始LIS之外的目的地的ATMARP请求，甚至是全球范围内的请求；由LIS之外的ATMARP或全球ATMARP机制提出的问题超出本备忘录的范围。
ATM does not support broadcast addressing, therefore there are no mappings available from IP broadcast addresses to ATM broadcast services. Note: this lack of mapping does not restrict members from transmitting or receiving IP datagrams specifying any of the four standard IP broadcast address forms as described in [8]. Members, upon receiving an IP broadcast or IP subnet broadcast for their LIS, MUST process the packet as if addressed to that station.
ATM不支持广播寻址，因此没有从IP广播地址到ATM广播服务的映射。注：这种映射的缺乏并不限制成员发送或接收指定[8]中所述四种标准IP广播地址形式中任何一种的IP数据报。成员在收到其LIS的IP广播或IP子网广播后，必须处理数据包，如同将数据包发往该站点一样。
This memo recognizes the future development of standards and implementations that will extend the operations as defined in this memo to provide an IP broadcast capability for use by the classical client.
本备忘录确认了标准和实施的未来发展，这些标准和实施将扩展本备忘录中定义的操作，以提供IP广播功能，供经典客户端使用。
ATM does not directly support IP multicast address services, therefore there are no mappings available from IP multicast addresses to ATM multicast services. Current IP multicast implementations (i.e., MBONE and IP tunneling, see [10]) will continue to operate over ATM based logical IP subnets if operated in the WAN configuration.
ATM不直接支持IP多播地址服务，因此没有从IP多播地址到ATM多播服务的映射。如果在WAN配置中运行，当前的IP多播实现（即MBONE和IP隧道，请参见[10]）将继续在基于ATM的逻辑IP子网上运行。
This memo recognizes the future development of ATM multicast service addressing by the ATM Forum. When available and widely implemented, the roll-over from the current IP multicast architecture to this new ATM architecture will be straightforward.
本备忘录确认了ATM论坛对ATM多播服务寻址的未来发展。当可用并广泛实施时，从当前的IP多播体系结构过渡到这种新的ATM体系结构将非常简单。
This memo recognizes the future development of standards and implementations that will extend the operations as defined in this memo to provide an IP multicast capability for use by the classical client.
本备忘录确认了标准和实现的未来发展，这些标准和实现将扩展本备忘录中定义的操作，以提供供经典客户端使用的IP多播功能。
Not all of the security issues relating to IP over ATM are clearly understood at this time, due to the fluid state of ATM specifications, newness of the technology, and other factors.
由于ATM规范的流动性、技术的新颖性和其他因素，目前并非所有与IP over ATM相关的安全问题都被清楚地理解。
It is believed that ATM and IP facilities for authenticated call management, authenticated end-to-end communications, and data encryption will be needed in globally connected ATM networks. Such future security facilities and their use by IP networks are beyond the scope of this memo.
人们相信，在全球连接的ATM网络中，将需要用于认证呼叫管理、认证端到端通信和数据加密的ATM和IP设施。此类未来安全设施及其在IP网络中的使用超出了本备忘录的范围。
There are known security issues relating to host impersonation via the address resolution protocols used in the Internet [13]. No special security mechanisms have been added to the address resolution mechanism defined here for use with networks using IP over ATM.
通过互联网中使用的地址解析协议，存在与主机模拟相关的已知安全问题[13]。此处定义的地址解析机制未添加任何特殊的安全机制，用于使用ATM上IP的网络。
Clients built to this specification MUST implement and provide a Management Information Base (MIB) as defined in "Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2" [18].
按照本规范构建的客户机必须实现并提供“使用SMIv2的ATM上经典IP和ARP托管对象定义”中定义的管理信息库（MIB）[18]。
o Automatic configuration of client ATM addresses via DHCP [15] or via ATM UNI 3.1 Interim Local Management Interface (ILMI) services would be a useful extended service addition to this document and should be addressed in a separate memo.
o 通过DHCP[15]或通过ATM UNI 3.1临时本地管理接口（ILMI）服务自动配置客户端ATM地址将是本文件中有用的扩展服务，应在单独的备忘录中说明。
o ATMARP packets are not authenticated. This is a potentially serious flaw in the overall system by allowing a mechanism by which corrupt information may be introduced into the server system.
o ATMARP数据包未经过身份验证。这是整个系统中的一个潜在严重缺陷，允许将损坏的信息引入服务器系统。
[1] Piscitello, D., and J. Lawrence, "The Transmission of IP Datagrams over the SMDS Service", STD 52, RFC 1209, March 1991.
[1] Piscitello，D.和J.Lawrence，“通过SMDS服务传输IP数据报”，STD 52，RFC 1209，1991年3月。
[2] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[2] Heinanen，J.，“ATM适配层5上的多协议封装”，RFC 1483，1993年7月。
[3] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[3] Plummer，D.，“以太网地址解析协议-或-将网络协议地址转换为48位以太网地址以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, July 1992.
[4] Reynolds，J.和J.Postel，“分配的数字”，STD 2，RFC 1700，1992年7月。
[5] Postel, J., and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042, February 1988.
[5] Postel，J.和J.Reynolds，“通过IEEE 802网络传输IP数据报的标准”，STD 43，RFC 1042，1988年2月。
[6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII, Geneva, 19-29 January 1993.
[6] CCITT，“建议I.363草案”，CCITT第十八研究组，日内瓦，1993年1月19日至29日。
[7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September - 2 October 1992.
[7] CCITT，“Q.93B文本草案”，CCITT研究小组席，9月23日-1992年10月2日。
[8] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[8] Braden，R.，“互联网主机的要求——通信层”，STD 3，RFC 1122，1989年10月。
[9] ATM Forum, "ATM User-Network Interface (UNI) Specification Version 3.1.", ISBN 0-13-393828-X, Prentice-Hall, Inc., Upper Saddle River, NJ, 07458, September, 1994.
[9] ATM论坛，“ATM用户网络接口（UNI）规范3.1版”，ISBN 0-13-393828-X，Prentice Hall，Inc.，新泽西州上鞍河，07458，1994年9月。
[10] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[10] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[11] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI NSAP Allocation in the Internet", RFC 1237, July 1991.
[11] Colella，R.，Gardner，E.，和R.Callon，“互联网上OSI NSAP分配指南”，RFC 1237，1991年7月。
[12] Bradely, T., and C. Brown, "Inverse Address Resolution Protocol", RFC 1293, January 1992.
[12] Bradely，T.和C.Brown，“反向地址解析协议”，RFC 1293，1992年1月。
[13] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48, 1989.
[13] “TCP/IP协议套件中的安全问题”，《ACM计算机通信评论》，第19卷，第2期，第32-48页，1989年。
[14] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[14] Knowles，S.，“从Path MTU发现的经验中得出的IESG建议”，RFC 1435，1993年3月。
[15] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, March 1997.
[15] Droms，R.，“动态主机配置协议”，RFC 1541，1997年3月。
[16] Kent C., and J. Mogul, "Fragmentation Considered Harmful", Proceedings of the ACM SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology, August 1987.
[16] Kent C.和J.Mogul，“碎片被认为是有害的”，ACM SIGCOMM'87计算机通信技术前沿研讨会论文集，1987年8月。
[17] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[17] Mogul，J.和S.Deering，“MTU发现路径”，RFC 119119119990年11月。
[18] Green, M., Luciani, J., White, K., and T. Kuo, "Definitions of Managed Objects for Classical IP and ARP over ATM Using SMIv2", RFC 2320, April 1998.
[18] Green，M.，Luciani，J.，White，K.，和T.Kuo，“使用SMIv2的ATM上传统IP和ARP的托管对象定义”，RFC 2320，1998年4月。
[19] ATM Forum, "ATM User-Network Interface (UNI) Specification Version 4.0", ATM Forum specfication af-sig-0061.000, ftp://ftp.atmforum.com/, July, 1996.
[19] ATM论坛，“ATM用户网络接口（UNI）规范版本4.0”，ATM论坛规范af-sig-0061.000，ftp://ftp.atmforum.com/，一九九六年七月。
[20] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[20] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Mark Laubach Com21, Inc. 750 Tasman Drive Milpitas, CA 95035
Mark Laubach Com21，Inc.加利福尼亚州米尔皮塔斯塔斯曼大道750号，邮编95035
Phone: 408.953.9175 FAX: 408.953.9299 EMail: laubach@com21.com
电话：408.953.9175传真：408.953.9299电子邮件：laubach@com21.com
Joel Halpern Newbridge Networks, Inc. 593 Herndon Parkway Herndon, VA 22070-5241
Joel Halpern Newbridge Networks，Inc.弗吉尼亚州赫恩登公园路593号，邮编22070-5241
Phone: 703.736.5954 FAX: 703.736.5959 EMail: jhalpern@Newbridge.com
电话：703.736.5954传真：703.736.5959电子邮件：jhalpern@Newbridge.com
APPENDIX A - Update Information
附录A-更新信息
This memo represents an update to RFC 1577 and RFC 1626. The following changes are included in this memo:
本备忘录是对RFC 1577和RFC 1626的更新。本备忘录包括以下变更：
o Pointer to Classical MIB I-D for setting of variables
o 指向用于设置变量的经典MIB I-D的指针
o Single ATMARP server address to ATMARP server list, configurable via the MIB.
o 单个ATMARP服务器地址到ATMARP服务器列表，可通过MIB配置。
o RFC 1626 text replaces MTU section
o RFC1626文本替换MTU部分
o Client registration procedure from In_ATMARP to first ATMARP_Request
o 从In_ATMARP到首次ATMARP请求的客户注册程序
o Clarification of variable length ATMARP packet format
o 可变长度ATMARP数据包格式的澄清
o Clarification of ARP_NAK packet format
o ARP_NAK数据包格式的澄清
o Clarification of InATMARP packet format for null IPv4 addresses
o 对空IPv4地址的InATMARP数据包格式的澄清
o Clarification on ATMARP registration and use of InATMARP_Reply for clients having more than one IP address in a LIS
o 关于ATMARP注册和对LIS中有多个IP地址的客户使用InATMARP_回复的澄清
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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 implmentation may be prepared, copied, published andand 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."
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。”