Network Working Group T. Przygienda
Request for Comments: 2844 Siara
Category: Experimental P. Droz
R. Haas
IBM
May 2000
Network Working Group T. Przygienda
Request for Comments: 2844 Siara
Category: Experimental P. Droz
R. Haas
IBM
May 2000
OSPF over ATM and Proxy-PAR
ATM上的OSPF和代理PAR
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This memo specifies, for OSPF implementors and users, mechanisms describing how the protocol operates in ATM networks over PVC and SVC meshes with the presence of Proxy-PAR. These recommendations require no protocol changes and allow simpler, more efficient and cost-effective network designs. It is recommended that OSPF implementations should be able to support logical interfaces, each consisting of one or more virtual circuits and used either as numbered logical point-to-point links (one VC), logical NBMA networks (more than one VC) or Point-to-MultiPoint networks (more than one VC), where a solution simulating broadcast interfaces is not appropriate. PAR can help distribute across the ATM cloud configuration setup and changes of such interfaces when OSPF capable routers are (re-)configured. Proxy-PAR can in turn be used to exchange this information between the ATM cloud and the routers connected to it.
本备忘录为OSPF实施者和用户指定了机制，描述了协议如何在存在代理PAR的PVC和SVC网格上的ATM网络中运行。这些建议不需要更改协议，并允许更简单、更高效和经济高效的网络设计。建议OSPF实现应能够支持逻辑接口，每个接口由一个或多个虚拟电路组成，并用作编号逻辑点对点链路（一个VC）、逻辑NBMA网络（多个VC）或点对多点网络（多个VC），模拟广播接口的解决方案不适用。PAR可以帮助跨ATM云配置设置和当OSPF路由器（重新配置）配置时这种接口的改变。代理PAR可以反过来用于在ATM云和与其连接的路由器之间交换此信息。
1 Introduction
1导言
Proxy-PAR and PAR have been accepted as standards by the ATM Forum in January 1999 [1]. A more complete overview of Proxy-PAR than in the section below is given in [2].
代理PAR和PAR已于1999年1月被ATM论坛接受为标准（1）。[2]中给出了比下文更完整的代理PAR概述。
Proxy-PAR [1] is an extension that allows different ATM attached devices (like routers) to interact with PAR-capable switches and to query information about non-ATM services without executing PAR themselves. The Proxy-PAR client side in the ATM attached device is much simpler in terms of implementation complexity and memory requirements than a complete PAR protocol stack (which includes the full PNNI [3] protocol stack) and should allow easy implementation, e.g. in existing IP routers. In addition, clients can use Proxy-PAR to register the various non-ATM services and protocols they support. Proxy PAR has consciously been omitted as part of ILMI [4] due to the complexity of PAR information passed in the protocol and the fact that it is intended for integration of non-ATM protocols and services only. A device that executes Proxy-PAR does not necessarily need to execute ILMI or UNI signaling, although this normally will be the case.
代理PAR（1）是一种扩展，允许不同的ATM附加设备（如路由器）与PAR有能力的交换机交互，并且在不执行PAR自身的情况下查询关于非ATM服务的信息。ATM附加设备中的代理PAR客户端在实现复杂度和存储器需求方面比完整的PAR协议栈（包括完整的PNNI（3）协议栈）要简单得多，并且应该允许容易实现，例如在现有的IP路由器中。此外，客户端可以使用代理PAR来注册它们支持的各种非ATM服务和协议。由于协议中传递的PAR信息的复杂性和仅用于非ATM协议和服务的集成的事实，代理PAR有意识地被省略为ILMI（4）的一部分。执行代理PAR的设备不一定需要执行ILMI或UNI信令，尽管通常情况下是这样。
The protocol in itself does not specify how the distributed service registration and data delivered to the client is supposed to drive other protocols. Hence OSPF routers, for instance, that find themselves through Proxy-PAR could use this information in a Classical IP and ARP over ATM [5] fashion, forming a full mesh of point-to-point connections to interact with each other to simulate broadcast interfaces. For the same purpose, LANE [6] or MARS [7] could be used. As a byproduct, Proxy-PAR could provide the ATM address resolution for IP-attached devices, but such resolution can be achieved by other protocols under specification at the IETF as well, e.g. [8]. Last but not least, it should be mentioned here that the protocol coexists with and complements the ongoing work in IETF on server detection via ILMI extensions [9,10,11].
协议本身并没有指定分布式服务注册和交付给客户机的数据应该如何驱动其他协议。因此，例如，通过代理PAR发现自己的OSPF路由器可以以经典的IP和ARP over ATM[5]方式使用这些信息，形成点到点连接的完整网格，以相互交互来模拟广播接口。出于同样的目的，可以使用车道[6]或火星[7]。作为副产品，代理PAR可以为IP连接设备提供ATM地址解析，但这种解析也可以通过IETF规范下的其他协议实现，例如[8]。最后但并非最不重要的一点是，这里应该提到的是，该协议与IETF中正在进行的通过ILMI扩展进行服务器检测的工作共存并补充[9,10,11]。
Any information registered through Proxy-PAR is flooded only within a defined scope that is established during registration and is equivalent to the PNNI routing level. As no assumption can be made about the information distributed (e.g. IP addresses bound to NSAPs are not assumed to be aligned with them in any respect such as encapsulation or functional mapping), it cannot be summarized. This makes a careful handling of scopes necessary to preserve the scalability. More details on the usage of scope can be found in [2].
通过代理PAR注册的任何信息仅在注册期间建立的定义范围内被淹没，并且与PNNI路由级别等效。由于无法对分发的信息做出任何假设（例如，绑定到NSAP的IP地址在任何方面（如封装或功能映射）都不会与之对齐），因此无法对其进行总结。这使得仔细处理范围成为保持可伸缩性所必需的。有关作用域用法的更多详细信息，请参见[2]。
OSPF (Open Shortest Path First) is an Interior Gateway Protocol (IGP) and described in [12] from which most of the following paragraphs has been taken almost literally. OSPF distributes routing information between routers belonging to a single Autonomous System. The OSPF protocol is based on link-state or SPF technology. It was developed by the OSPF working group of the Internet Engineering Task Force. It has been designed expressly for the TCP/IP internet environment, including explicit support for IP subnetting, and the tagging of externally-derived routing information. OSPF also utilizes IP multicast when sending/receiving the updates. In addition, much work has been done to produce a protocol that responds quickly to topology changes, yet involves small amounts of routing protocol traffic.
OSPF（开放最短路径优先）是一种内部网关协议（IGP），如[12]所述，以下大部分段落几乎都是从字面上理解的。OSPF在属于单个自治系统的路由器之间分发路由信息。OSPF协议基于链路状态或SPF技术。它是由互联网工程任务组的OSPF工作组开发的。它专为TCP/IP internet环境而设计，包括对IP子网的明确支持，以及对外部派生的路由信息的标记。OSPF在发送/接收更新时还利用IP多播。此外，已经做了大量工作来生成一个能够快速响应拓扑变化的协议，但只涉及少量路由协议流量。
To cope with the needs of NBMA and demand-circuit-capable networks such as Frame Relay or X.25, [13] has been made available. It standardizes extensions to the protocol that allow efficient operation over on-demand circuits.
为了满足NBMA和按需电路功能网络的需求，如帧中继或X.25，[13]已经可用。它标准化了协议的扩展，允许在按需电路上高效运行。
OSPF supports three types of networks today:
OSPF目前支持三种类型的网络：
+ Point-to-point networks: A network that joins a single pair of routers. Point-to-point networks can either be numbered or unnumbered. In the latter case the interfaces do not have IP addresses nor masks. Even when numbered, both sides of the link do not have to agree on the IP subnet.
+ 点对点网络：连接一对路由器的网络。点对点网络可以编号，也可以不编号。在后一种情况下，接口既没有IP地址也没有掩码。即使进行编号，链路的双方也不必在IP子网上达成一致。
+ Broadcast networks: Networks supporting many (more than two) attached routers, together with the capability of addressing a single physical message to all of the attached routers (broadcast). Neighboring routers are discovered dynamically on these networks using the OSPF Hello Protocol. The Hello Protocol itself takes advantage of the broadcast capability. The protocol makes further use of multicast capabilities, if they exist. An Ethernet is an example of a broadcast network.
+ 广播网络：支持多个（两个以上）连接路由器的网络，以及向所有连接路由器寻址单个物理消息的能力（广播）。使用OSPF Hello协议在这些网络上动态发现相邻路由器。Hello协议本身利用了广播功能。该协议进一步利用了多播功能（如果存在的话）。以太网是广播网络的一个示例。
+ Non-broadcast networks: Networks supporting many (more than two) attached routers, but having no broadcast capability. Neighboring routers are maintained on these nets using OSPF's Hello Protocol. However, due to the lack of broadcast capability, some configuration information is necessary for the correct operation of the Hello Protocol. On these networks, OSPF protocol packets that are normally multicast need to be sent to each neighboring router, in turn. An X.25 Public Data Network (PDN) is an example of a non-broadcast network.
+ 非广播网络：支持多个（两个以上）连接路由器但没有广播能力的网络。相邻路由器使用OSPF的Hello协议维护在这些网络上。然而，由于缺乏广播能力，一些配置信息对于Hello协议的正确操作是必要的。在这些网络上，通常为多播的OSPF协议包需要依次发送到每个相邻路由器。X.25公共数据网络（PDN）是非广播网络的一个示例。
OSPF runs in one of two modes over non-broadcast networks. The first mode, called non-broadcast multi-access (NBMA), simulates the operation of OSPF on a broadcast network. The second mode, called Point-to-MultiPoint, treats the non-broadcast network as a collection of point-to-point links. Non-broadcast networks are referred to as NBMA networks or Point-to-MultiPoint networks, depending on OSPF's mode of operation over the network.
OSPF在非广播网络上以两种模式之一运行。第一种模式称为非广播多址（NBMA），模拟广播网络上OSPF的操作。第二种模式称为点对多点，将非广播网络视为点对点链路的集合。非广播网络称为NBMA网络或点对多点网络，具体取决于OSPF在网络上的操作模式。
2 OSPF over ATM
ATM上的2 OSPF
Contrary to broadcast-simulation-based solutions such as LANE [6] or Classical IP and ARP over ATM [5], this document elaborates on how to handle virtual OSPF interfaces over ATM such as NBMA, Point-to-MultiPoint or point-to-point and allow for their auto-configuration in the presence of Proxy-PAR. One advantage is the circumvention of server solutions that often present single points of failure or hold large amounts of configuration information.
与基于广播模拟的解决方案（如LANE[6]或ATM上的经典IP和ARP[5]）相反，本文件阐述了如何在ATM上处理虚拟OSPF接口，如NBMA、点对多点或点对点，并允许在存在代理PAR的情况下自动配置这些接口。一个优点是避开了通常出现单点故障或保存大量配置信息的服务器解决方案。
The other main benefit is the capability of executing OSPF on top of NBMA and Point-to-MultiPoint ATM networks, and still benefit from the automatic discovery of OSPF neighbors. As opposed to broadcast networks, broadcast-simulation-based networks (such as LANE or Classical IP and ARP over ATM), and point-to-point networks, where an OSPF router dynamically discovers its neighbors by sending Hello packets to the All-SPFRouters multicast address, this is not the case on NBMA and Point-to-MultiPoint networks. On NBMA networks, the list of all other attached routers to the same NBMA network has to be manually configured or discovered by some other means: Proxy-PAR allows this configuration to be automated. Also on Point-to-MultiPoint networks, the set of routers that are directly reachable can either be manually configured or dynamically discovered by Proxy-PAR or mechanisms such as Inverse ATMARP. In an ATM network, (see 8.2 in [5]) Inverse ATMARP can be used to discover the IP address of the router at the remote end of a given PVC, whether or not its ATM address is known. But Inverse ATMARP does not return, for instance, whether the remote router is running OSPF, unlike Proxy-PAR.
另一个主要好处是在NBMA和点对多点ATM网络上执行OSPF的能力，并且仍然受益于OSPF邻居的自动发现。与广播网络、基于广播模拟的网络（如ATM上的LANE或经典IP和ARP）以及点对点网络（OSPF路由器通过向所有SPF路由器的多播地址发送Hello数据包来动态发现其邻居）不同，NBMA和点对多点网络上的情况并非如此。在NBMA网络上，必须手动配置或通过其他方式发现连接到同一NBMA网络的所有其他路由器的列表：代理PAR允许自动进行此配置。同样在点对多点网络上，可直接访问的路由器集可以手动配置，也可以通过代理PAR或反向ATMARP等机制动态发现。在ATM网络中，（见[5]中的8.2），反向ATMARP可用于发现给定PVC远端路由器的IP地址，无论其ATM地址是否已知。但反向ATMARP不会返回，例如，远程路由器是否运行OSPF，这与Proxy PAR不同。
Parallel to [14], which describes the recommended operation of OSPF over Frame Relay networks, a similar model is assumed where the underlying ATM network can be used to model single VCs as point-to-point interfaces or collections of VCs as non-broadcast interfaces, whether in NBMA or Point-to-MultiPoint mode. Such a VC or collection of VCs is called a logical interface and specified through its type (either point-to-point, NBMA or Point-to-MultiPoint), VPN ID (the
[14]描述了OSPF在帧中继网络上的推荐操作，与[14]类似，假设了一个类似的模型，其中底层ATM网络可用于将单个VCs建模为点对点接口，或将VCs集合建模为非广播接口，无论是在NBMA模式还是点对多点模式下。这种VC或VC集合称为逻辑接口，并通过其类型（点对点、NBMA或点对多点）、VPN ID（
Virtual Private Network to which the interface belongs), address and mask. Layer 2 specific configurations such as the address resolution method, class and quality of service of circuits used, and others, must also be included. As a logical consequence thereof, a single, physical interface could encompass multiple IP subnets or even multiple VPNs. Contrary to layer 2 and IP addressing information, when running Proxy-PAR, most of the OSPF information needed to operate such a logical interface does not have to be configured into routers statically but can be provided through Proxy-PAR queries. This allows much more dynamic configuration of VC meshes in OSPF environments than, for example, Frame Relay solutions do.
接口所属的虚拟专用网络）、地址和掩码。还必须包括第2层特定配置，如地址解析方法、所用电路的等级和服务质量等。因此，一个单一的物理接口可以包含多个IP子网，甚至多个VPN。与第2层和IP寻址信息相反，当运行代理PAR时，操作此类逻辑接口所需的大多数OSPF信息不必静态配置到路由器中，而是可以通过代理PAR查询提供。这允许在OSPF环境中对VC网格进行比帧中继解决方案更动态的配置。
Proxy-PAR queries can also be issued with a subnet address set to 0.0.0.0, instead of a specific subnet address. This type of query returns information on all OSPF routers available in all subnets within the scope specified in the query. This can be used for instance when the IP addressing information has not been configured.
代理PAR查询也可以使用设置为0.0.0.0的子网地址而不是特定的子网地址发出。这种类型的查询返回查询中指定范围内所有子网中可用的所有OSPF路由器的信息。例如，当尚未配置IP地址信息时，可以使用此选项。
To achieve the goal of simplification of VC mesh reconfiguration, Proxy-PAR allows the router to learn automatically most of the configuration that has to be provided to OSPF. Non-broadcast and point-to-point interface information can be learned across an ATM cloud as described in the ongoing sections. It is up to the implementation to possibly allow for a mixture of Proxy-PAR autoconfiguration and manual configuration of neighbor information. Moreover, manual configuration could, for instance, override or complement information derived from a Proxy-PAR client. In addition, OSPF extensions to handle on-demand circuits [13] can be used to allow the graceful tearing down of VCs not carrying any OSPF traffic over prolonged periods of time. The various interactions are described in sections 2.2.1, 2.2.2 and 2.2.3.
为了实现简化VC网格重新配置的目标，代理PAR允许路由器自动学习必须提供给OSPF的大部分配置。非广播和点对点接口信息可以通过ATM云学习，如后续章节所述。这取决于实现是否允许混合使用代理PAR自动配置和手动配置邻居信息。此外，例如，手动配置可以覆盖或补充从代理PAR客户端派生的信息。此外，处理按需电路的OSPF扩展[13]可用于允许在较长时间内优雅地拆除不承载任何OSPF流量的VCs。第2.2.1、2.2.2和2.2.3节描述了各种相互作用。
Even after autoconfiguration of interfaces has been provided, the problem of VC setups in an ATM network is unsolved because none of the normally used mechanisms such as Classical IP and ARP over ATM [5] or LANE [6] are assumed to be present. Section 2.5 describes the behavior of OSPF routers necessary to allow for router connectivity.
即使在提供了接口的自动配置之后，ATM网络中的VC设置问题仍然没有解决，因为通常使用的机制（如ATM上的经典IP和ARP[5]或通道[6]）都不存在。第2.5节描述了允许路由器连接所需的OSPF路由器的行为。
2.2.1 Autoconfiguration of Non-Broadcast Multiple-Access (NMBA) Interfaces
2.2.1 非广播多址（NMBA）接口的自动配置
Proxy-PAR allows the autoconfiguation of the list of all routers residing on the same IP network in the same VPN by simply querying the Proxy-PAR server. Each router can easily obtain the list of all OSPF routers on the same subnet with their router priorities and corresponding ATM addresses. This is the precondition for OSPF to
Proxy PAR允许通过简单地查询Proxy PAR服务器，自动配置驻留在同一VPN中同一IP网络上的所有路由器的列表。每个路由器都可以轻松获得同一子网上所有OSPF路由器的列表，以及它们的路由器优先级和相应的ATM地址。这是OSPF成功的先决条件
work properly across such logical NBMA interfaces. Note that this member list, when learned through Proxy-PAR queries, can dynamically change with PNNI (in)stability and general ATM network behavior. Relying on an OSPF mechanism to discover a lack of reachability in the overlaying logical IP network could alleviate the risk of thrashing DR elections and excessive information flooding. Once the DR election has been completed and the router has not been elected DR or BDR, an implementation of [13] can ignore the fact that all routers on the specific NBMA subnet are available in its configuration because it only needs to maintain VCs to the DR and BDR. Note that this information can serve other purposes, such as the forwarding of data packets (see section 2.4).
跨此类逻辑NBMA接口正常工作。请注意，当通过代理PAR查询了解此成员列表时，它可以随PNNI（in）稳定性和一般ATM网络行为而动态变化。依靠OSPF机制来发现覆盖逻辑IP网络中缺乏可达性，可以减轻打击DR选举和过度信息泛滥的风险。一旦DR选择完成，且路由器未被选择为DR或BDR，[13]的实现可以忽略以下事实：特定NBMA子网上的所有路由器在其配置中都可用，因为它只需要维护DR和BDR的VCs。请注意，此信息可用于其他目的，如转发数据包（见第2.4节）。
Traditionally, router configuration for a NBMA network provides the list of all neighboring routers to allow for proper protocol operation. For stability purposes, the user may choose to provide a list of neighbors through such static means but also enable the operation of Proxy-PAR protocol to complete the list. It is left up to specific router implementations to determine whether to use the manual configuration in addition to the information provided by Proxy-PAR, to use the manual configuration to filter dynamic information, or whether a concurrent mode of operation is prohibited. In any case it should be obvious that allowing for more flexibility may facilitate operation but provides more possibilities for misconfiguration as well.
传统上，NBMA网络的路由器配置提供所有相邻路由器的列表，以允许正确的协议操作。出于稳定性目的，用户可以选择通过这种静态方式提供邻居列表，但也可以允许代理PAR协议的操作来完成该列表。由特定的路由器实现来决定是否使用手动配置以及代理PAR提供的信息，是否使用手动配置来过滤动态信息，或者是否禁止并发操作模式。在任何情况下，允许更大的灵活性都会促进操作，但也会带来更多的错误配置的可能性。
Point-to-MultiPoint interfaces in ATM networks only make sense if no VCs can be set up dynamically because an SVC-capable ATM network normally presents a NBMA cloud to OSPF. This is for example the case if OSPF executes over a network composed of a partial PVC or SPVC mesh or predetermined SVC meshes. Such a network could be modeled using the Point-to-MultiPoint OSPF interface and the neighbor detection could be provided by Proxy-PAR or other means. In the Proxy-PAR case the router queries for all OSPF routers on the same network in the same VPN but it installs in the interface configuration only routers that are already reachable through existing PVCs. The underlying assumption is that a router knows the remote ATM address of a PVC and can compare it with appropriate Proxy-PAR registrations. If the remote ATM address of the PVC is unknown, it can be discovered by such mechanisms as Inverse ARP [15].
ATM网络中的点对多点接口只有在无法动态设置VCs时才有意义，因为支持SVC的ATM网络通常向OSPF提供NBMA云。例如，如果OSPF在由部分PVC或SPVC网格或预定SVC网格组成的网络上执行，则为这种情况。这种网络可以使用点对多点OSPF接口建模，邻居检测可以通过代理PAR或其他方式提供。在代理PAR情况下，路由器在同一VPN中查询同一网络上的所有OSPF路由器，但它在接口配置中只安装通过现有PVC可以访问的路由器。基本假设是路由器知道PVC的远程ATM地址，并可以将其与适当的代理PAR注册进行比较。如果PVC的远程ATM地址未知，则可通过反向ARP等机制发现该地址[15]。
Proxy-PAR provides a true OSPF neighbor detection mechanism, whereas a mechanism like Inverse ARP only returns addresses of directly reachable routers (which are not necessarily running OSPF), in the Point-to-Multi-Point environment.
Proxy PAR提供了一种真正的OSPF邻居检测机制，而在点对多点环境中，像反向ARP这样的机制只返回直接可到达的路由器（不一定运行OSPF）的地址。
OSPF point-to-point links do not necessarily have an IP address assigned and even if they do, the mask is undefined. As a precondition to successfully register a service with Proxy-PAR, an IP address and a mask are required. Therefore, if a router desires to use Proxy-PAR to advertise the local end of a point-to-point link to the router with which it intends to form an adjacency, an IP address has to be provided as well as a netmask set or a default of 255.255.255.252 (this gives as the default case a subnet with two routers on it) assumed. To allow the discovery of the remote end of the interface, IP address of the remote side has to be provided and a netmask set or a default of 255.255.255.252 assumed. Obviously the discovery can only be successful when both sides of the interface are configured with the same network mask and are within the same IP network. The situation where more than two possible neighbors are discovered through queries and the interface type is set to point-to-point presents a configuration error.
OSPF点到点链路不一定有IP地址分配，即使有，掩码也未定义。作为向代理PAR成功注册服务的先决条件，需要IP地址和掩码。因此，如果路由器希望使用代理PAR来公布其打算与之形成邻接的路由器的点到点链路的本地端，则必须提供IP地址以及网络掩码集，或者假定默认值为255.255.255.252（这是默认情况，假定子网上有两个路由器）。为了允许发现接口的远程端，必须提供远程端的IP地址，并假定网络掩码集或默认值为255.255.255.252。显然，只有当接口的两侧都配置了相同的网络掩码并且位于相同的IP网络中时，发现才能成功。如果通过查询发现两个以上的可能邻居，并且接口类型设置为点对点，则会出现配置错误。
Sending multicast Hello packets on the point-to-point links allows OSPF neighbors to be discovered automatically. On the other hand, using Proxy-PAR instead avoids sending Hello messages to routers that are not necessarily running OSPF.
通过在点到点链路上发送多播Hello数据包，可以自动发现OSPF邻居。另一方面，使用代理PAR可以避免向不一定运行OSPF的路由器发送Hello消息。
For reasons given in [14], the use of unnumbered point-to-point interfaces with Proxy-PAR is not a very attractive alternative because the lack of an IP address prevents efficient registration and retrieval of configuration information. Relying on the numbering method based on MIB entries generates conflicts with the dynamic nature of creation of such entries and is beyond the scope of this work.
出于[14]中给出的原因，使用带有代理PAR的无编号点对点接口不是一个很有吸引力的选择，因为缺少IP地址会妨碍配置信息的有效注册和检索。依赖基于MIB条目的编号方法会与创建此类条目的动态性质产生冲突，超出本工作范围。
To allow other routers to discover an OSPF interface automatically, the IP address, mask, Area ID, interface type and router priority information given must be registered with the Proxy-PAR server at an appropriate scope. A change in any of these parameters has to force a reregistration with Proxy-PAR.
为了允许其他路由器自动发现OSPF接口，必须在适当的范围内向代理PAR服务器注册给定的IP地址、掩码、区域ID、接口类型和路由器优先级信息。任何这些参数的更改都必须强制重新注册代理PAR。
It should be emphasized here that because the registration information can be used by other routers to resolve IP addresses against NSAPs as explained in section 2.4, the entire IP address of the router must be registered. It is not sufficient to indicate the subnet up to the mask length; all address bits must be provided.
这里需要强调的是，由于注册信息可被其他路由器用于根据NSAP解析IP地址，如第2.4节所述，因此必须注册路由器的整个IP地址。仅指示掩码长度以下的子网是不够的；必须提供所有地址位。
For an NBMA interface the appropriate parameters are available and can be registered through Proxy-PAR without further complications.
对于NBMA接口，可使用适当的参数，并可通过代理PAR注册，无需进一步复杂化。
In the case of a Point-to-MultiPoint interface the router registers its information in the same fashion as in the NBMA case, except that the interface type is modified accordingly.
在点对多点接口的情况下，路由器以与NBMA相同的方式注册其信息，只是接口类型被相应地修改。
In the case of point-to-point numbered interfaces the address mask is not specified in the OSPF configuration. If the router has to use Proxy-PAR to advertise its capability, a mask must be defined or a default value of 255.255.255.252 used.
在点对点编号接口的情况下，OSPF配置中不指定地址掩码。如果路由器必须使用代理PAR来公布其功能，则必须定义掩码或使用默认值255.255.255.252。
Owing to the lack of a configured IP address and difficulties generated by this fact as described earlier, registration of unnumbered point-to-point interfaces is not covered in this document.
由于缺少配置的IP地址，并且如前所述，由于这一事实而产生的困难，本文档不包括未编号的点到点接口的注册。
As a byproduct of Proxy-PAR presence, an OSPF implementation could use the information in registrations for the resolution of IP addresses to ATM NSAPs on a subnet without having to use static data or mechanisms such as ATMARP [5]. This again should allow a drastic simplification of the number of mechanisms involved in operating OSPF over ATM to provide an IP overlay.
作为代理PAR存在的副产品，OSPF实现可以使用注册中的信息将IP地址解析为子网上的ATM NSAP，而无需使用静态数据或ATMARP等机制[5]。这也应该允许在ATM上操作OSPF以提供IP覆盖所涉及的机制数量大大简化。
From a system perspective, the OSPF component, the Proxy-PAR client, the IP to NSAP address resolution table, and the ATM circuit manager can be depicted as in Figure 1. Figure 1 shows an example of component interactions triggered by a Proxy-PAR query from the Proxy-PAR client.
从系统的角度来看，OSPF组件、代理PAR客户端、IP到NSAP地址解析表和ATM电路管理器可以如图1所示。图1显示了由Proxy PAR客户端的Proxy PAR查询触发的组件交互示例。
This section describes the OSPF behavior in an ATM network under various assumptions in terms of signaling capabilities and preset connectivity.
本节描述了ATM网络中在信令能力和预设连接方面的各种假设下的OSPF行为。
In environments where only partial PVCs (or SPVCs) meshes are available and modeled as Point-to-MultiPoint interfaces, the routers see reachable routers through autodiscovery provided by Proxy-PAR. This leads to expected OSPF behavior. In cases where a full mesh of PVCs is present, such a network should preferably be modeled as NBMA. Note that in such a case, PVCs failures will translate into not-so-obvious routing failures.
在只有部分PVC（或SPVC）网格可用且建模为点对多点接口的环境中，路由器通过代理PAR提供的自动发现来查看可到达的路由器。这会导致预期的OSPF行为。在存在PVC的完整网格的情况下，此类网络最好建模为NBMA。请注意，在这种情况下，PVCs故障将转化为不太明显的路由故障。
__________ _________
| | | |
| OSPF |<-------------------|Proxy-PAR|<---(Proxy-PAR query)
|__________| notify | client |
^ neighbor changes |_________|
| |
send and | | maintain Proxy-PAR
receive | | entries in table
OSPF msg | |
| |
| |
____V____ ____V_____
| ATM | | |
| circuit |-------------------->|IP to NSAP|
| manager | check | table |
|_________| IP to NSAP bindings |__________|
__________ _________
| | | |
| OSPF |<-------------------|Proxy-PAR|<---(Proxy-PAR query)
|__________| notify | client |
^ neighbor changes |_________|
| |
send and | | maintain Proxy-PAR
receive | | entries in table
OSPF msg | |
| |
| |
____V____ ____V_____
| ATM | | |
| circuit |-------------------->|IP to NSAP|
| manager | check | table |
|_________| IP to NSAP bindings |__________|
Figure 1: System perspective of typical components interactions.
图1：典型组件交互的系统透视图。
+ + +
| +---+ | |
+--+ |---|RTA|---| +-------+ | +--+
|H1|---| +---+ | | ATM | |---|H2|
+--+ | | +---+ | Cloud | +---+ | +--+
|LAN Y |---|RTB|-------------|RTC|---|
+ | +---+ | PPAR | +---+ |
+ +-------+ +
+ + +
| +---+ | |
+--+ |---|RTA|---| +-------+ | +--+
|H1|---| +---+ | | ATM | |---|H2|
+--+ | | +---+ | Cloud | +---+ | +--+
|LAN Y |---|RTB|-------------|RTC|---|
+ | +---+ | PPAR | +---+ |
+ +-------+ +
Figure 2: Simple topology with Router B and Router C operating across NBMA ATM interfaces with Proxy-PAR.
图2：路由器B和路由器C在NBMA ATM接口和代理PAR之间运行的简单拓扑。
In SVC-capable environments the routers can initiate VCs after having discovered the appropriate neighbors, preferably driven by the need to send data such as Hello packets. This can lead to race conditions where both sides can open a VC simultaneously. It is generally desirable to avoid wasting this valuable resource: if the router with lower IP address (i.e., the IP address of the OSPF interface registered with Proxy-PAR) detects that the VC initiated by the other side is bidirectional, it is free to close its own VC and use the detected one. Note that this either requires the OSPF implementation to be aware of the VCs used to send and receive Hello messages, or the component responsible of managing VCs to be aware of the usage of particular VCs.
在支持SVC的环境中，路由器可以在发现适当的邻居后启动VCs，最好是由发送数据（如Hello数据包）的需要驱动。这可能会导致双方同时开设VC的竞赛条件。通常希望避免浪费这一宝贵资源：如果具有较低IP地址（即，向代理PAR注册的OSPF接口的IP地址）的路由器检测到另一方发起的VC是双向的，则它可以自由关闭自己的VC并使用检测到的VC。请注意，这要求OSPF实现了解用于发送和接收Hello消息的VCs，或者要求负责管理VCs的组件了解特定VCs的使用情况。
Observe that this behavior operates correctly in case OSPF over Demand Circuits extensions are used [13] over SVC capable interfaces.
观察在支持SVC的接口上使用OSPF超需电路扩展[13]时，该行为是否正常工作。
Most of the time, it is possible to avoid the setup of redundant VCs by delaying the sending of the first OSPF Hello from the router with the lower IP address by an amout of time greater than the interval between the queries from the Proxy-PAR client to the server. Chances are that the router with the higher IP address opens the VC (or use an already existing VC) and sends the OSPF Hello first if its interval between queries is shorter than the Hello delay of the router with the lower IP address. As this interval can vary depending on particular needs and implementations, the race conditions described above can still be expected to happen, albeit presumably less often.
大多数情况下，通过将从IP地址较低的路由器发送第一个OSPF Hello的时间延迟一段大于从代理PAR客户端到服务器的查询间隔的时间，可以避免冗余VCs的设置。如果查询间隔短于IP地址较低的路由器的Hello延迟，则IP地址较高的路由器可能会打开VC（或使用现有VC）并首先发送OSPF Hello。由于该间隔可以根据特定的需求和实现而变化，因此上述竞争条件仍然可能发生，尽管可能不太频繁。
The existence of VCs used for OSPF exchanges is orthogonal to the number and type of VCs the router chooses to use within the logical interface to forward data to other routers. OSPF implementations are free to use any of these VCs (in case they are aware of their existence) to send packets if their end points are adequate and must accept Hello packets arriving on any of the VCs belonging to the
用于OSPF交换的VCs的存在与路由器在逻辑接口内选择用于将数据转发给其他路由器的VCs的数量和类型正交。OSPF实现可以自由地使用这些VCs中的任何一个（如果它们知道它们的存在）来发送数据包，前提是它们的端点足够，并且必须接受到达属于这些VCs的任何VCs上的Hello数据包
logical interface even if OSPF operating on such an interface is not aware of their existence. An OSPF implementation may ignore connections being initiated by another router that has not been discovered by Proxy-PAR. In any case, the OSPF implementation will ignore a neighbor whose Proxy-PAR registration indicates that it is not adjacent.
逻辑接口，即使在这种接口上运行的OSPF不知道它们的存在。OSPF实现可能会忽略由代理PAR未发现的另一路由器启动的连接。在任何情况下，OSPF实现都将忽略其代理PAR注册指示其不相邻的邻居。
As an example consider the topology in Figure 2 where router RTB and RTC are connected to a common ATM cloud offering Proxy-PAR services. Assuming that RTB's OSPF implementation is aware of SVCs initiated on the interface and that RTC only makes minimal use of Proxy-PAR information, the following sequence could develop, illustrating some of the cases described above:
作为一个例子，考虑图2中的拓扑，其中路由器RTB和RTC连接到提供代理PAR服务的公共ATM云。假设RTB的OSPF实现知道在接口上启动的SVC，并且RTC仅对代理PAR信息进行最小限度的使用，则可能会出现以下顺序，说明上述一些情况：
1. RTC and RTB register with ATM cloud as Proxy-PAR capable and discover each other as adjacent OSPF routers.
1. RTC和RTB在ATM云上注册为代理PAR，并作为相邻的OSPF路由器相互发现。
2. RTB sends a Hello, which forces it to establish a SVC connection to RTC.
2. RTB发送Hello，强制其建立到RTC的SVC连接。
3. RTC sends a Hello to RTB, but disregards the already existing VC and establishes a new VC to RTB to deliver the packet.
3. RTC向RTB发送一个Hello，但忽略已经存在的VC，并向RTB建立一个新的VC来传递数据包。
4. RTB sees a new bidirectional VC and, assuming here that RTC's IP address is higher, closes the VC originated in step 2.
4. RTB看到一个新的双向VC，并在这里假设RTC的IP地址更高，关闭在步骤2中发起的VC。
5. Host H1 sends data to H2 and RTB establishes a new data SVC between itself and RTC.
5. 主机H1向H2发送数据，RTB在其自身和RTC之间建立新的数据SVC。
6. RTB sends a Hello to RTC and decides to do so using the newly establish data SVC. RTC must accept the Hello despite the minimal implementation.
6. RTB向RTC发送Hello，并决定使用新建立的数据SVC执行此操作。RTC必须接受Hello，尽管实现很少。
3 Acknowledgments
3致谢
Comments and contributions from several sources, especially Rob Coltun, Doug Dykeman, John Moy and Alex Zinin are included in this work.
来自多个来源的评论和贡献，特别是Rob Coltun、Doug Dykeman、John Moy和Alex Zinin都包含在这项工作中。
4 Security Considerations
4安全考虑
Several aspects are to be considered in the context of the security of operating OSPF over ATM and/or Proxy-PAR. The security of registered information handed to the ATM cloud must be guaranteed by the underlying PNNI protocol. The registration itself through Proxy-PAR is not secured, and are thus appropriate mechanisms for further study. However, even if the security at the ATM layer is not guaranteed, OSPF security mechanisms can be used to verify that
在ATM和/或代理PAR上操作OSPF的安全性方面需要考虑几个方面。移交给ATM云的注册信息的安全性必须由基础PNNI协议保证。通过代理PAR进行的注册本身并不安全，因此是进一步研究的适当机制。然而，即使ATM层的安全性没有得到保证，OSPF安全机制也可以用来验证这一点
detected neighbors are authorized to interact with the entity discovering them.
检测到的邻居被授权与发现它们的实体进行交互。
5 Bibliography
5参考书目
[1] ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0." ATM Forum af-ra-0104.000, January 1999.
[1] ATM论坛，“PNNI增强路由（PAR）1.0版”，ATM论坛af-ra-0104.000，1999年1月。
[2] Droz, P. and T. Przygienda, "Proxy-PAR", RFC 2843, May 2000.
[2] Droz，P.和T.Przygienda，“代理票面价值”，RFC 28432000年5月。
[3] ATM-Forum, "Private Network-Network Interface Specification Version 1.0." ATM Forum af-pnni-0055.000, March 1996.
[3] ATM论坛，“专用网络接口规范1.0版”，ATM论坛af-pnni-0055.000，1996年3月。
[4] ATM-Forum, "Interim Local Management Interface, (ILMI) Specification 4.0." ATM Forum af-ilmi-0065.000, September 1996.
[4] ATM论坛，“临时本地管理接口（ILMI）规范4.0”，ATM论坛af-ILMI-0065.000，1996年9月。
[5] Laubach, J., "Classical IP and ARP over ATM", RFC 2225, April 1998.
[5] Laubach，J.，“ATM上的经典IP和ARP”，RFC2225，1998年4月。
[6] ATM-Forum, "LAN Emulation over ATM 1.0." ATM Forum af-lane-0021.000, January 1995.
[6] ATM论坛，“ATM 1.0上的局域网仿真”，ATM论坛af-lane-0021.000，1995年1月。
[7] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
[7] Armitage，G.“支持基于UNI 3.0/3.1的ATM网络上的多播”，RFC 2022，1996年11月。
[8] Coltun, R., "The OSPF Opaque LSA Option", RFC 2328, July 1998.
[8] Coltun，R.，“OSPF不透明LSA选项”，RFC 23281998年7月。
[9] Davison, M., "ILMI-Based Server Discovery for ATMARP", RFC 2601, June 1999.
[9] Davidson，M.，“基于ILMI的ATMARP服务器发现”，RFC 2601，1999年6月。
[10] Davison, M., "ILMI-Based Server Discovery for MARS", RFC 2602, June 1999.
[10] Davidson，M.，“基于ILMI的火星服务器发现”，RFC 26021999年6月。
[11] Davison, M., "ILMI-Based Server Discovery for NHRP", RFC 2603, June 1999.
[11] Davidson，M.，“基于ILMI的NHRP服务器发现”，RFC 26031999年6月。
[12] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[12] Moy，J.，“OSPF版本2”，RFC 23281998年4月。
[13] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[13] Moy，J.，“扩展OSPF以支持需求电路”，RFC 1793，1995年4月。
[14] deSouza, O. and M. Rodrigues, "Guidelines for Running OSPF Over Frame Relay Networks", RFC 1586, March 1994.
[14] deSouza，O.和M.Rodrigues，“在帧中继网络上运行OSPF的指南”，RFC1586，1994年3月。
[15] Bradley, A. and C. Brown, "Inverse Address Resolution Protocol", RFC 2390, September 1999.
[15] Bradley，A.和C.Brown，“反向地址解析协议”，RFC 23901999年9月。
Authors' Addresses
作者地址
Tony Przygienda Siara Systems Incorporated 1195 Borregas Avenue Sunnyvale, CA 94089 USA
Tony Przygienda Siara Systems Incorporated 1195 Borregas Avenue Sunnyvale，CA 94089美国
EMail: prz@siara.com
EMail: prz@siara.com
Patrick Droz IBM Research Zurich Research Laboratory Saumerstrasse 4 8803 Ruschlikon Switzerland
Patrick Droz IBM苏黎世研究实验室Saumerstrasse 4 8803 Ruschlikon瑞士
EMail: dro@zurich.ibm.com
EMail: dro@zurich.ibm.com
Robert Haas IBM Research Zurich Research Laboratory Saumerstrasse 4 8803 Ruschlikon Switzerland
罗伯特·哈斯IBM苏黎世研究实验室苏美尔大街48803瑞士鲁什利康
EMail: rha@zurich.ibm.com
EMail: rha@zurich.ibm.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。