Network Working Group T. Smith
Request for Comments: 2226 IBM Corporation
Category: Standards Track G. Armitage
Lucent Technologies
October 1997
Network Working Group T. Smith
Request for Comments: 2226 IBM Corporation
Category: Standards Track G. Armitage
Lucent Technologies
October 1997
IP Broadcast over ATM Networks
ATM网络上的IP广播
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 (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
Abstract
摘要
This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. The solution revolves around treating the broadcast problem as a special case of multicast, where every host in the subnet or cluster is a member of the group.
本备忘录描述了IP over ATM工作组开发的IP多播服务如何用于支持IP广播传输。该解决方案将广播问题视为多播的一种特殊情况，其中子网或集群中的每台主机都是组的成员。
An understanding of the services provided by RFC 2022 is assumed.
假设理解RFC 2022提供的服务。
1. Introduction.
1. 介绍
The IETF's first step in solving the problems of running IP over Asynchronous Transfer Mode (ATM) technology is described in RFC 1577 [1]. It provides for unicast communication between hosts and routers within Logical IP Subnets (LISs), and proposes a centralized ATM ARP Server which provides IP to ATM address resolution services to LIS members.
RFC 1577[1]中描述了IETF在解决IP over Asynchronous Transfer Mode（ATM）技术运行问题方面的第一步。它提供了逻辑IP子网（LIS）内主机和路由器之间的单播通信，并提出了一种集中式ATM ARP服务器，该服务器向LIS成员提供IP到ATM地址解析服务。
Two classes of IP service were omitted - multicast and broadcast transmissions. Multicasting allows a single transmit operation to cause a packet to be received by multiple remote destinations.
省略了两类IP服务：多播和广播传输。多播允许单个传输操作导致多个远程目的地接收数据包。
Broadcasting typically allows a single transmit operation to cause a packet to be received by all IP hosts that are members of a particular 'subnet'.
广播通常允许单个传输操作使属于特定“子网”成员的所有IP主机接收数据包。
To address the need for multicast support (represented by transmission to IP addresses in the Class D space), RFC 2022 ("Support for Multicast over UNI 3.0/3.1 based ATM Networks") [2] was created. This memo creates an analog of the RFC 1577 ARP Server - a new entity known as the MARS (Multicast Address Resolution Server). The MARS operates as a centralized registry and distribution mechanism for mappings between IP multicast addresses and groups of ATM unicast addresses. Host behavior is also defined for establishing and managing point to multipoint VCs, based on the information returned by the MARS, when hosts wish to transmit packets to a multicast group.
为了满足多播支持的需求（通过传输到D类空间中的IP地址来表示），创建了RFC 2022（“基于UNI 3.0/3.1的ATM网络上的多播支持”）[2]。此备忘录创建了RFC1577ARP服务器的模拟，这是一个称为MARS（多播地址解析服务器）的新实体。MARS作为IP多播地址和ATM单播地址组之间映射的集中注册和分发机制运行。当主机希望向多播组传输数据包时，还定义了主机行为，用于根据MARS返回的信息建立和管理点对多点VCs。
This memo aims to show how RFC 2022 may be used to emulate IP broadcast within Logical IP Subnets. While the broadcast technique does not align itself well with the underlying point-to-point nature of ATM, clearly, some applications will still wish to use IP broadcasts. Client-server applications where the client searches for a server by sending out a broadcast is one scenario. Routing protocols, most notably RIP, are other examples.
本备忘录旨在说明如何使用RFC 2022在逻辑IP子网内模拟IP广播。虽然广播技术不能很好地与ATM的基本点对点特性保持一致，但显然，一些应用程序仍希望使用IP广播。客户端-服务器应用程序，其中客户端通过发送广播来搜索服务器是一种场景。路由协议，尤其是RIP，是其他的例子。
2. Review of Unicast and Multicast.
2. 单播和多播综述。
Both the unicast and multicast cases take advantage of the point-to-point and point-to-multipoint capabilities defined in the ATM Forum UNI 3.1 document [4]. A unicast IP address has a single ATM level destination. Unicast transmissions occur over point to point Virtual Channels (VCs) between the source and destination. The ARP Server holds mappings between IP destination addresses and their associated ATM destination address. Hosts issue an ARP_REQUEST to the ARP Server when they wish to ascertain a particular mapping. The ARP Server replies with either an ARP_REPLY containing the ATM address of the destination, or an ARP_NAK when the ARP Server is unable to resolve the address. If the request is successful the host establishes a VC to the destination interface. This VC is then used to forward the first (and subsequent) packets to that particular IP destination. RFC 1577 describes in further detail how hosts are administratively grouped in to Logical IP Subnets (LISs), and how the ARP Server establishes the initial mappings for members of the LIS it serves.
单播和多播情况都利用了ATM论坛UNI 3.1文档[4]中定义的点对点和点对多点功能。单播IP地址只有一个ATM级别的目的地。单播传输发生在源和目标之间的点对点虚拟信道（VCs）上。ARP服务器保存IP目标地址与其关联的ATM目标地址之间的映射。当主机希望确定特定映射时，会向ARP服务器发出ARP_请求。ARP服务器回复包含目的地ATM地址的ARP_回复，或者在ARP服务器无法解析地址时回复ARP_NAK。如果请求成功，主机将建立到目标接口的VC。然后使用此VC将第一个（和后续）数据包转发到该特定IP目的地。RFC 1577进一步详细描述了主机如何在管理上分组到逻辑IP子网（LIS），以及ARP服务器如何为其服务的LIS成员建立初始映射。
The basic host behavior for multicasting is similar - the sender must establish and manage a point to multipoint VC whose leaf nodes are the group's actual members. Under UNI 3.1 these VCs can only be established and altered by the source (root) interface.
多播的基本主机行为类似-发送方必须建立并管理一个点对多点VC，其叶节点是组的实际成员。根据UNI 3.1，这些VCs只能通过源（根）接口建立和更改。
The MARS is an evolution of the ARP Server model, and performs two key functions. The first function is the maintenance of a list of ATM addresses corresponding to the members for each group. This list is created by a host registration process which involves two messages - a MARS_JOIN which declares that a host wishes to join the specified group(s), and a MARS_LEAVE which indicates that a host wishes to leave the specified group(s).
MARS是ARP服务器模型的演变，执行两个关键功能。第一个功能是维护与每个组的成员相对应的ATM地址列表。此列表由主机注册过程创建，该过程涉及两条消息-一条MARS_JOIN（声明主机希望加入指定组），另一条MARS_LEAVE（表示主机希望离开指定组）。
MARS_JOIN and MARS_LEAVE messages are also redistributed to all members of the group so that active senders may dynamically adjust their point to multipoint VCs accordingly.
MARS_JOIN和MARS_LEAVE消息也会重新分发给组中的所有成员，以便活动发件人可以相应地动态调整其点对多点VCs。
The other major function is the retrieval of group membership from MARS (analogous to the ARP Server providing unicast address mappings). When faced with the need to transmit an IP packet with a Class D destination address, a host issues a MARS_REQUEST to the MARS. If the group has members the MARS returns a MARS_MULTI (possibly in multiple segments) carrying a set of ATM addresses. The host then establishes an initial point to multipoint VC using these ATM addresses as the leaf nodes. If the MARS had no mapping it would return a MARS_NAK.
另一个主要功能是从MARS检索组成员资格（类似于提供单播地址映射的ARP服务器）。当需要传输具有D类目的地地址的IP数据包时，主机会向MARS发出MARS_请求。如果组中有成员，MARS将返回一个MARS_MULTI（可能在多个段中），其中包含一组ATM地址。然后，主机使用这些ATM地址作为叶节点，建立一个初始点对多点VC。如果火星没有地图，它将返回一个火星号。
(RFC 2022 also discusses how the MARS can arrange for Class D groups to be supported by either multicast servers, or meshes of point to multipoint VCs from host to host. However, from the host's perspective this is transparent, and is not central to this discussion of IP broadcast support.)
（RFC 2022还讨论了MARS如何安排由多播服务器或主机间点对多点VCs网格支持的D类组。然而，从主机的角度来看，这是透明的，不是IP广播支持讨论的核心。）
This memo describes how a host may utilize the registration and group management functions in an existing MARS based IP/ATM network to emulate IP broadcasts.
本备忘录描述了主机如何利用现有基于MARS的IP/ATM网络中的注册和组管理功能来模拟IP广播。
3. Broadcast as a special case of Multicast.
3. 广播作为多播的一种特殊情况。
Many of the problems that occur when implementing a broadcast solution also occur in when implementing a multicast solution. In fact, broadcast may be considered a special case of multicast. That is, broadcast is a multicast group whose members include all members in the LIS.
在实现广播解决方案时出现的许多问题在实现多播解决方案时也会出现。事实上，广播可以被认为是多播的一种特殊情况。也就是说，广播是一个多播组，其成员包括LIS中的所有成员。
There are two broadcast groups which this memo addresses:
本备忘录涉及两个广播组：
1) 255.255.255.255 - "All ones" broadcast
1) 255.255.255.255-“所有人”广播
2) x.z - CIDR-prefix (subnet) directed broadcast
2) x、 z-CIDR前缀（子网）定向广播
Broadcast (1) is sometimes referred to as a limited broadcast to this physical network. Broadcast (2) can be thought of as the the broadcast for subnets or networks in the old paradigm. As described in [6] and [7], the notion of subnets and networks is being replaced with a more efficient utilization of the routing address space known as Classless Inter-Domain Routing. The CIDR-prefix (x) is the combination of IP address and subnet mask that denotes the subnet number. The host portion of the address (z) is all ones. One should note that while these broadcasts have different scopes at the IP or network layer, they have precisely the same scope at the link layer -- namely that all members of the LIS will receive a copy.
Broadcast (1) is sometimes referred to as a limited broadcast to this physical network. Broadcast (2) can be thought of as the the broadcast for subnets or networks in the old paradigm. As described in [6] and [7], the notion of subnets and networks is being replaced with a more efficient utilization of the routing address space known as Classless Inter-Domain Routing. The CIDR-prefix (x) is the combination of IP address and subnet mask that denotes the subnet number. The host portion of the address (z) is all ones. One should note that while these broadcasts have different scopes at the IP or network layer, they have precisely the same scope at the link layer -- namely that all members of the LIS will receive a copy.translate error, please retry
These addresses may be used in two environments:
这些地址可用于两种环境：
o Broadcasting to all members of a given LIS where a priori knowledge of a host's IP address and subnet mask are known (e.g. the CIDR-prefix directed broadcast).
o 向已知主机IP地址和子网掩码先验知识的给定LIS的所有成员广播（例如CIDR前缀定向广播）。
o Broadcasting to all members of a physical network without knowledge of a host's IP address and subnet mask (e.g. the all ones broadcast).
o 向物理网络的所有成员广播，而不知道主机的IP地址和子网掩码（例如，所有成员广播）。
On a broadcast medium like Ethernet, these two environments result in the same physical destination. That is, all stations on that network will receive the broadcast even if they are on different logical subnets, or are non-IP stations. With ATM, this may not be the case. Because ATM is non-broadcast, a registration process must take place. And if there are stations that register to some broadcast groups, but not others, then the different broadcast groups will have different memberships. The notion of broadcast becomes inconsistent.
在像以太网这样的广播媒体上，这两种环境产生相同的物理目的地。也就是说，该网络上的所有站点都将接收广播，即使它们位于不同的逻辑子网上，或者是非IP站点。对于ATM，情况可能并非如此。因为ATM是非广播的，所以必须进行注册过程。如果有电台注册到某些广播组，而不是其他广播组，那么不同的广播组将拥有不同的成员资格。广播的概念变得不一致。
One case that requires the use of the all ones broadcast is that of the diskless boot, or bootp client, where the host boots up, and does not know its own IP address or subnet mask. Clearly, the host does not know which subnet it belongs to. So, to send a broadcast to its bootp server, the diskless workstation must use the group which contains no subnet information, i.e. the 255.255.255.255 broadcast group. Carrying the example a little further, the bootp server, after receiving the broadcast, can not send either a directed frame nor a subnet directed broadcast to respond to the diskless workstation. Instead, the bootp server must also use the 255.255.255.255 group to communicate with the client.
需要使用“全一”广播的一种情况是无盘启动或bootp客户机，其中主机启动，但不知道自己的IP地址或子网掩码。显然，主机不知道它属于哪个子网。因此，要向其bootp服务器发送广播，无盘工作站必须使用不包含子网信息的组，即255.255.255.255广播组。再举一个例子，bootp服务器在接收到广播后，不能发送定向帧或子网定向广播来响应无盘工作站。相反，bootp服务器还必须使用255.255.255.255组与客户端通信。
While the all ones broadcast is required at the IP layer, it also has relevance at the link layer when deciding which broadcast group to register with in MARS. In other words, a bootp client wishing to register for a link layer broadcast, can only register for
虽然在IP层需要“全一”广播，但在决定在MARS中向哪个广播组注册时，它在链路层也具有相关性。换句话说，希望注册链路层广播的bootp客户端只能注册
255.255.255.255 in the MARS address space because the client's subnet is unknown at the time. Given that some applications must use the all ones address in MARS for their broadcast group, and that we wish to minimize the number of broadcast groups used by LIS members, the all ones group in MARS MUST be used by all members of the LIS when registering to receive broadcast transmissions. The VCC used for transmitting any broadcast packet will be based on the members registered in the MARS under the 255.255.255.255 address position. This VCC will be referred to as the "broadcast channel" through the remainder of this memo.
由于客户端的子网当时未知，因此在MARS地址空间中存在255.255.255.255。考虑到一些应用程序必须使用MARS中的all ones地址作为其广播组，并且我们希望尽量减少LIS成员使用的广播组的数量，因此在注册接收广播传输时，LIS的所有成员必须使用MARS中的all ones组。用于传输任何广播数据包的VCC将基于在MARS中255.255.255.255地址位置下注册的成员。在本备忘录的其余部分中，该VCC将被称为“广播频道”。
4. The MARS role in broadcast.
4. 火星在广播中的作用。
Many solutions have been proposed, some of which are listed in Appendix A. This memo addresses a MARS solution which appears to do the best job of solving the broadcast problem.
已经提出了许多解决方案，其中一些在附录A中列出。本备忘录介绍了一个MARS解决方案，它似乎在解决广播问题方面做得最好。
There are a number of characteristics of the MARS architecture that should be kept intact. They include:
火星建筑有许多特点应该保持完整。这些措施包括：
o MARS contains no knowledge of subnet prefixes and subnet masks. Each group address registered with MARS is managed independently.
o MARS不包含子网前缀和子网掩码的知识。向MARS注册的每个组地址都是独立管理的。
o A MARS may only serve one LIS. This insures that the broadcast group 255.255.255.255 is joined by hosts from one LIS, keeping its scope bound to conventional interpretation.
o 火星可能只服务于一个LIS。这确保广播组255.255.255.255由来自一个LIS的主机连接，使其范围受常规解释的约束。
o The Multicast Server (MCS) described in [2] may be used to service the broadcast groups defined in this memo without modification. The MCS will reduce the number of channels used by the network.
o [2]中描述的多播服务器（MCS）可用于为本备忘录中定义的广播组提供服务，无需修改。MCS将减少网络使用的信道数量。
The MARS needs no additional code or special algorithms to handle the resolution of IP broadcast addresses. It is simply a general database that holds {Protocol address, ATM.1, ATM.2, ... ATM.n} mappings, and imposes no constraints on the type and length of the 'Protocol address'. Whether the hosts view it as Class D or 'broadcast' (or even IP) is purely a host side issue.
火星不需要额外的代码或特殊算法来处理IP广播地址的解析。它只是一个普通的数据库，它拥有{protocoladdress，ATM.1，ATM.2，…ATM.n}映射，并且对“protocoladdress”的类型和长度没有任何限制。主机是否将其视为D类或“广播”（甚至IP）纯粹是主机端的问题。
It is likely that end points will want to use the IP broadcast emulation described here in order to support boot time location of the end point's IP address. This leads to the observation that the MARS should NOT expect to see both the IP source and ATM source address fields of the MARS_JOIN filled in. This is reasonable, since only the ATM source address is used when registering the end point as a group member.
端点可能希望使用此处描述的IP广播模拟，以支持端点IP地址的启动时位置。这导致了一个观察结果，即MARS不应该期望看到MARS_连接的IP源和ATM源地址字段都被填充。这是合理的，因为在将端点注册为组成员时只使用ATM源地址。
The MARS architecture is sufficient to insure the integrity of the broadcast group list without any modification.
MARS架构足以确保广播组列表的完整性，无需任何修改。
5. Host Requirements for Broadcast.
5. 广播的主机要求。
The following list of bullets describes additional characteristics of a MARS-compliant host. These characteristics are required to take advantage of the broadcast function.
以下项目符号列表描述了与MARS兼容的主机的其他特性。这些特性是利用广播功能所必需的。
o A host must register as a MARS client.
o 主机必须注册为MARS客户端。
o A host, soon after registration MUST issue a MARS_JOIN to the all ones broadcast address (i.e. 255.255.255.255) with the mar$flags.layer3grp reset.
o 注册后不久，主机必须向所有人广播地址（即255.255.255.255）发出mar$flags.layer3grp重置的MARS_加入。
o When transmitting packets, the host should map all IP layer broadcasts to the VCC (broadcast channel) created and maintained based on the all ones entry in MARS.
o 在传输数据包时，主机应将所有IP层广播映射到基于MARS中的all ONE条目创建和维护的VCC（广播频道）。
o A host MUST monitor the MARS_JOIN/MARS_LEAVE messages for 255.255.255.255 to keep the broadcast channel current.
o 主机必须监视255.255.255.255的MARS_JOIN/MARS_LEAVE消息，以保持广播频道的最新状态。
o A broadcast channel should be torn down after a period of inactivity. The corresponding timeout period MAY be specified with a minimum value of one minute, and a RECOMMENDED default value of 20 minutes.
o 一段时间不活动后，广播频道应被拆除。可以指定相应的超时时间，最小值为1分钟，建议默认值为20分钟。
One should note that while every member participating in the broadcast MUST be a member of the all ones group, not all members will choose to transmit broadcast information. Some members will only elect to receive broadcast information passively. Therefore, in a LIS with n stations, there may be less than n channels terminated at each station for broadcast information. Further reductions may be gained by adding a Multicast Server (MCS) to the broadcast environment which could reduce the number of VCs to two (one incoming, one outgoing), or one for a station that only wishes to listen.
需要注意的是，虽然参与广播的每个成员都必须是“全一”组的成员，但并非所有成员都会选择传输广播信息。有些议员只会选择被动接收广播资料。因此，在具有n个站点的LIS中，在每个站点终止的用于广播信息的信道可能少于n个。可通过向广播环境添加多播服务器（MCS）来获得进一步的减少，该多播服务器（MCS）可将vc的数量减少到两个（一个传入，一个传出），或仅希望收听的电台的vc数量减少到一个。
It is well understood that broadcasting in this environment may tax the resources of the network and of the hosts that use it. Therefore, an implementer MAY choose to provide a mechanism for retracting the host's entry in the broadcast group after it has been established or prior to joining the group. The MARS_LEAVE is used to request withdrawal from the group if the host wishes to disable broadcast reception after it has joined the group. The default behavior SHALL be to join the all ones broadcast group in MARS.
众所周知，在这种环境中进行广播可能会对网络资源和使用网络的主机资源征税。因此，实现者可以选择提供一种机制，用于在广播组中的主机条目已经建立之后或在加入该组之前收回该主机条目。如果主机希望在加入组后禁用广播接收，则MARS_LEAVE用于请求退出组。默认行为是加入火星上的“全一”广播组。
6. Implications of IP broadcast on ATM level resources.
6. IP广播对ATM级资源的影响。
RFC 2022 discusses some of the implications of large multicast groups on the allocation of ATM level resources, both within the network and within end station ATM interfaces.
RFC 2022讨论了大型多播组对网络内和终端站ATM接口内ATM级资源分配的一些影响。
The default mechanism is for IP multicasting to be achieved using meshes of point to multipoint VCs, direct from source host to group members. Under certain circumstances system administrators may, in a manner completely transparent to end hosts, redirect multicast traffic through ATM level Multicast Servers (MCSs). This may be performed on an individual group basis.
默认机制是使用点对多点VCs网格实现IP多播，直接从源主机到组成员。在某些情况下，系统管理员可以以对终端主机完全透明的方式通过ATM级多播服务器（MCS）重定向多播流量。这可以在单个组的基础上执行。
It is sufficient to note here that the IP broadcast 'multicast group' will constitute the largest consumer of VCs within your ATM network when it is active. For this reason it will probably be the first multicast group to have one or more ATM MCSs assigned to support it. However, there is nothing unique about an MCS assigned to support IP broadcast traffic, so this will not be dealt with further in this memo. RFC 2022 contains further discussion on the possible application of multiple MCSs to provide fault-tolerant architectures.
请注意，当IP广播“多播组”处于活动状态时，它将构成ATM网络中VCs的最大消费者。因此，它可能是第一个分配了一个或多个ATM MCS来支持它的多播组。然而，分配给支持IP广播流量的MCS并没有什么独特之处，因此本备忘录将不再进一步讨论。RFC 2022进一步讨论了多个MCS的可能应用，以提供容错体系结构。
7. Further discussion.
7. 进一步讨论。
A point of discussion on the ip-atm forum revolved around "auto configuration" and "diskless boot". This memo describes a broadcast solution that requires the use of the MARS. Therefore, at a minimum, the ATM address of the MARS must be manually configured into a diskless workstation. Suggestions such as universal channel numbers, and universal ATM addresses have been proposed, however, no agreement has been reached.
ip atm论坛上的一个讨论点围绕“自动配置”和“无盘引导”展开。这份备忘录描述了一个需要使用火星的广播解决方案。因此，至少必须手动将MARS的ATM地址配置为无盘工作站。已经提出了诸如通用通道号和通用ATM地址等建议，但尚未达成一致意见。
Another topic for discussion is multiprotocol support. MARS is designed for protocol independence. This memo specifically addresses the IP broadcast case, identifying which addresses are most effective in the IP address space. However, the principles apply to any layer 3 protocol. Further work should be performed to identify suitable addresses for other layer 3 protocols.
另一个讨论主题是多协议支持。MARS是为协议独立而设计的。本备忘录专门针对IP广播情况，确定哪些地址在IP地址空间中最有效。但是，这些原则适用于任何第3层协议。应开展进一步工作，为其他第3层协议确定合适的地址。
Finally, there has been support voiced for a link layer broadcast that would be independent of the layer 3 protocol. Such a solution may provide a simpler set of rules through which broadcast applications may be used. In addition, some solutions also provide for more efficient use of VCCs.
最后，有人支持独立于第3层协议的链路层广播。这样的解决方案可以提供一组更简单的规则，通过这些规则可以使用广播应用程序。此外，一些解决方案还提供了更有效的VCC使用。
Security Considerations
安全考虑
This memo addresses a specific use of the MARS architecture and components to provide the broadcast function. As such, the security implications are no greater or less than the implications of using any of the other multicast groups available in the multicast address range. Should enhancements to security be required, they would need to be added as an extension to the base architecture in RFC 2022.
本备忘录阐述了火星架构和组件的具体用途，以提供广播功能。因此，安全含义不大于或小于使用多播地址范围中可用的任何其他多播组的含义。如果需要增强安全性，则需要在RFC 2022中将其作为基础架构的扩展添加。
Acknowledgments
致谢
The apparent simplicity of this memo owes a lot to the services provided in [2], which itself is the product of much discussion on the IETF's IP-ATM working group mailing list. Grenville Armitage worked on this document while at Bellcore.
本备忘录的明显简洁性在很大程度上归功于[2]中提供的服务，这本身就是IETF IP-ATM工作组邮件列表上大量讨论的结果。格伦维尔·阿米蒂奇在贝尔科勒工作期间负责编写这份文件。
References
工具书类
[1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, December 1993.
[1] Laubach，M.，“ATM上的经典IP和ARP”，RFC 15771993年12月。
[2] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1995.
[2] Armitage，G.“支持基于UNI 3.0/3.1的ATM网络上的多播”，RFC 2022，1995年11月。
[3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[3] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[4] ATM Forum, "ATM User-Network Interface Specification Version 3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993.
[4] ATM论坛，“ATM用户网络接口规范3.0版”，恩格尔伍德悬崖，新泽西州：普伦蒂斯大厅，1993年9月。
[5] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E. and A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755, February 1995.
[5] Perez，M.，Liaw，F.，Grossman，D.，Mankin，A.，Hoffman，E.和A.Malis，“ATM上IP的ATM信令支持”，RFC 17551995年2月。
[6] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[6] Fuller，V.，Li，T.，Yu，J.，和K.Varadhan，“无类域间路由（CIDR）：地址分配和聚合策略”，RFC 1519，1993年9月。
[7] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[7] Baker，F.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997.
[8] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Authors' Addresses
作者地址
Timothy J. Smith Network Routing Systems, International Business Machines Corporation. N21/664 P.O.Box 12195 Research Triangle Park, NC 27709
Timothy J.Smith网络路由系统，国际商业机器公司。北卡罗来纳州三角研究公园N21/664邮政信箱12195 27709
Phone: (919) 254-4723 EMail: tjsmith@vnet.ibm.com
电话：（919）254-4723电子邮件：tjsmith@vnet.ibm.com
Grenville Armitage Bell Labs, Lucent Technologies. 101 Crawfords Corner Rd, Holmdel, NJ, 07733
朗讯科技公司格伦维尔·阿米蒂奇·贝尔实验室。新泽西州霍姆德尔克劳福德角路101号，邮编：07733
EMail: gja@lucent.com
EMail: gja@lucent.com
Throughout the development of this memo, there have been a number of alternatives explored and discarded for one reason or another. This appendix documents these alternatives and the reason that they were not chosen.
在这份备忘录的整个开发过程中，出于这样或那样的原因，已经探索并放弃了许多备选方案。本附录记录了这些备选方案及其未被选择的原因。
A.1 ARP Server Broadcast Solutions.
A.1 ARP服务器广播解决方案。
The ARP Server is a good candidate to support broadcasting. There is an ARP Server for every LIS. The ARP Server contains the entire LIS membership. These are fundamental ingredients for the broadcast function.
ARP服务器是支持广播的一个很好的候选者。每个LIS都有一个ARP服务器。ARP服务器包含整个LIS成员资格。这些是广播功能的基本要素。
A.1.1 Base Solution without modifications to ARP Server.
A.1.1 基本解决方案，无需修改ARP服务器。
One may choose as an existing starting point to use only what is available in RFC 1577. That is, a host can easily calculate the range of members in its LIS based on its own IP address and subnet mask. The host can then issue an ARP Request for every member of the LIS. With this information, the host can then set up point-to-point connections with all members, or can set up a point-to-multipoint connection to all members. There you have it, the poor man's broadcast.
可以选择仅使用RFC 1577中可用的内容作为现有起点。也就是说，主机可以根据自己的IP地址和子网掩码轻松计算其LIS中的成员范围。然后，主机可以为LIS的每个成员发出ARP请求。有了这些信息，主机可以与所有成员建立点对点连接，也可以与所有成员建立点对多点连接。给你，可怜的人的广播。
While this solution is very straight forward, it suffers from a number of problems.
虽然这个解决方案非常直截了当，但它存在许多问题。
o The load on the ARP Server is very large. If all stations on a LIS choose to implement broadcasting, the initial surge of ARP Requests will be huge. Some sort of slow start sequence would be needed.
o ARP服务器上的负载非常大。如果LIS上的所有电台都选择实施广播，ARP请求的初始激增将是巨大的。需要某种缓慢的启动顺序。
o The amount of resource required makes this a non-scalable solution. The authors believe that broadcasting will require an MCS to reduce the number of channel resources required to support each broadcast 'group'. Using the ARP Server in this manner does not allow an MCS to be transparently introduced. (Basic RFC1577 interfaces also do not implement the extended LLC/SNAP encapsulation required to safely use more than one MCS).
o 所需的资源量使其成为不可扩展的解决方案。作者认为，广播将需要MCS来减少支持每个广播“组”所需的频道资源数量。以这种方式使用ARP服务器不允许透明地引入MCS。（基本RFC1577接口也不实现安全使用多个MCS所需的扩展LLC/SNAP封装）。
o The diskless boot solution can not function in this environment because it may be unable to determine which subnet to which it belongs.
o 无盘启动解决方案无法在此环境中运行，因为它可能无法确定它所属的子网。
A.1.2 Enhanced ARP Server solution.
A.1.2 增强的ARP服务器解决方案。
This solution is similar to the base solution except that it takes some of the (MARS) multicast solution and embeds it in the ARP Server. The first enhancement is to add the MARS_MULTI command to the set of opcodes that the ARP Server supports. This would allow a host to issue a single request, and to get back the list of members in one or more MARS_REPLY packets. Rather than have a registration mechanism, the ARP Server could simply use the list of members that have already been registered. When a request comes in for the subnet broadcast address, the ARP Server would aggregate the list, and send the results to the requester.
此解决方案与基本解决方案类似，只是它采用了一些（MARS）多播解决方案并将其嵌入到ARP服务器中。第一个增强是将MARS_MULTI命令添加到ARP服务器支持的操作码集中。这将允许主机发出单个请求，并在一个或多个MARS_回复数据包中获取成员列表。ARP服务器不需要注册机制，只需使用已经注册的成员列表即可。当收到子网广播地址的请求时，ARP服务器将聚合列表，并将结果发送给请求者。
This suffers from two drawbacks.
这有两个缺点。
1) Scalability with regard to number of VCs is still an issue. One would eventually need to add in some sort of multicast server solution to the ARP Server.
1) VCs数量的可扩展性仍然是一个问题。最终需要向ARP服务器添加某种多播服务器解决方案。
2) The diskless boot scenario is still broken. There is no way for a station to perform a MARS_MULTI without first knowing its IP address and subnet mask.
2) 无盘启动方案仍处于中断状态。在不知道其IP地址和子网掩码的情况下，站点无法执行MARS_MULTI。
The diskless boot problem could be solved by adding to the ARP Server a registration process where anyone could register to the 255.255.255.255 address. These changes would make the ARP Server look more and more like MARS.
通过向ARP服务器添加一个注册过程，任何人都可以注册到255.255.255.255地址，可以解决无盘启动问题。这些变化将使ARP服务器看起来越来越像火星。
A.2 MARS Solutions.
A.2火星解决方案。
If we wish to keep the ARP Server constant as described in RFC 1577, the alternative is to use the Multicast Address Resolution Server (MARS) described in [2].
如果我们希望保持RFC 1577中所述的ARP服务器不变，则另一种方法是使用[2]中所述的多播地址解析服务器（MARS）。
MARS has three nice features for broadcasting.
火星有三个很好的广播功能。
1) It has a generalized registration approach which allows for any address to have a group of entities registered. So, if the subnet address is not known, a host can register for an address that is known (e.g. 255.255.255.255).
1) 它有一种通用的注册方法，允许任何地址注册一组实体。因此，如果子网地址未知，主机可以注册已知地址（例如255.255.255.255）。
2) The command set allows for lists of members to be passed in a single MARS_MULTI packet. This reduces traffic.
2) 该命令集允许在单个MARS_多数据包中传递成员列表。这减少了交通量。
3) MARS contains an architecture for dealing with the scalability issues. That is, Multicast Servers (MCSs) may be used to set up the point-to-multipoint channels
3) MARS包含一个用于处理可伸缩性问题的体系结构。也就是说，多播服务器（MCS）可用于建立点对多点信道
and reduce the number of channels that a host needs to set up to one. Hosts wishing to broadcast will instead send the packet to the MCS who will then forward it to all members of the LIS.
并将主机需要设置的通道数减少到一个。希望广播的主机将向MCS发送数据包，然后MCS将数据包转发给LIS的所有成员。
A.2.1. CIDR-prefix (Subnet) Broadcast solution.
A.2.1. CIDR前缀（子网）广播解决方案。
One of the earliest solutions was to simply state that broadcast support would be implemented by using a single multicast group in the class D address space -- namely, the CIDR-prefix (subnet) broadcast address group. All members of a LIS would be required to register to this address, and use it as required. A host wishing to use either the 255.255.255.255 broadcast, or the network broadcast addresses would internally map the VC to the subnet broadcast VC. The all ones and network broadcast addresses would exist on MARS, but would be unused.
最早的解决方案之一是简单地声明广播支持将通过在D类地址空间中使用单个多播组来实现，即CIDR前缀（子网）广播地址组。LIS的所有成员都必须注册到此地址，并根据需要使用此地址。希望使用255.255.255.255广播或网络广播地址的主机将在内部将VC映射到子网广播VC。“全一”和网络广播地址将存在于火星上，但不会被使用。
The problem with this approach goes back to the diskless workstation problem. Because the workstation may not know which subnet it belongs to, it doesn't know which group to register with.
这种方法的问题可以追溯到无盘工作站问题。因为工作站可能不知道它属于哪个子网，所以它不知道要向哪个组注册。
This solution acknowledges that the diskless boot problem requires a generic address (one that does not contain CIDR-prefix (subnet) information) to register with and to use until subnet knowledge is known. In essence, all stations first register to the 255.255.255.255 group, then as they know their subnet information, they could optionally de-register from the all one's group and register to the CIDR-prefix (subnet) broadcast group.
此解决方案承认，无盘启动问题需要一个通用地址（不包含CIDR前缀（子网）信息的地址）来注册和使用，直到知道子网知识为止。本质上，所有电台首先注册到255.255.255.255组，然后由于它们知道自己的子网信息，它们可以选择从all one组中注销，并注册到CIDR prefix（subnet）广播组。
This solution would appear to solve a couple of problems:
此解决方案似乎解决了几个问题：
1) The bootp client can function if the server remains registered to the all one's group continuously.
1) 如果服务器持续注册到所有人的组，则bootp客户端可以正常工作。
2) There will be less traffic using the all ones group because the preferred transactions will be on the subnet broadcast channel.
2) 由于首选事务将在子网广播频道上，因此使用all ones组的通信量将减少。
Unfortunately the first bullet contains a flaw. The server must continually be registered to two groups -- the all ones group and the subnet broadcast group. If this server has multiple processes that are running different IP applications, it may be difficult for the link layer to know which broadcast VC to use. If it always uses the all ones, then it will be missing members that have removed themselves from the all ones and have registered to the subnet broadcast. If it always uses the subnet broadcast group, the
不幸的是，第一颗子弹包含一个缺陷。服务器必须连续地注册到两个组——all One组和subnet broadcast组。如果此服务器有多个进程运行不同的IP应用程序，链路层可能很难知道要使用哪个广播VC。如果它总是使用all ONE，则缺少的成员将从all ONE中删除自己并注册到子网广播。如果始终使用子网广播组，则
diskless boot scenario gets broken. While making the decision at the link layer may require additional control flows be built into the path, it may also require the rewriting of application software.
无盘启动场景被破坏。虽然在链路层做出决策可能需要在路径中构建额外的控制流，但也可能需要重写应用软件。
In some implementations, a simple constant is used to indicate to the link layer that this packet is to be transmitted to the broadcast "MAC" address. The assumption is that the physical network broadcast and the logical protocol broadcast are one and the same. As pointed out earlier, this is not the case with ATM. Therefore applications would need to specifically identify the subnet broadcast group address to take advantage of the smaller group.
在一些实现中，使用简单常数向链路层指示该分组将被发送到广播“MAC”地址。假设物理网络广播和逻辑协议广播是同一个。如前所述，ATM的情况并非如此。因此，应用程序需要专门标识子网广播组地址，以利用较小的组。
These problems could be solved in a number of ways, but it was thought that they added unnecessarily to the complexity of the broadcast solution.
这些问题可以通过多种方式解决，但有人认为它们不必要地增加了广播解决方案的复杂性。
Appendix B. Should MARS Be Limited to a Single LIS?
附录B.MARS是否应仅限于一个LIS？
RFC 2022 explicitly states that a network administrator MUST ensure that each LIS is served by a separate MARS, creating a one-to-one mapping between cluster and a unicast LIS. But, it also mentions that relaxation of this restriction MAY occur after future research warrants it. This appendix discusses some to the potential implications to broadcast should this restriction be removed.
RFC 2022明确规定，网络管理员必须确保每个LIS由单独的MARS提供服务，从而在集群和单播LIS之间创建一对一映射。但是，它也提到，在未来的研究证明这一限制后，可能会放宽这一限制。本附录讨论了取消此限制后可能对广播产生的影响。
The most obvious change would be that the notion of a cluster would span more than one LIS. Therefore, the broadcast group of 255.255.255.255 would contain members from more than one LIS.
最明显的变化是，集群的概念将跨越多个LIS。因此，255.255.255.255的广播组将包含来自多个LIS的成员。
It also should be emphasized that the one LIS limitation is not a restriction of the MARS architecture. Rather, it is only enforced if an administrator chooses to do so.
还应该强调的是，一个LIS限制不是火星架构的限制。相反，只有当管理员选择这样做时，才会强制执行。
Full Copyright Statement
完整版权声明
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 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。