Network Working Group T. Przygienda
Request for Comments: 2844 Siara
Category: Experimental P. Droz
OSPF over ATM and Proxy-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 (C) The Internet Society (2000). All Rights Reserved.
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.
Proxy-PAR and PAR have been accepted as standards by the ATM Forum in
January 1999 . A more complete overview of Proxy-PAR than in the
section below is given in .
Przygienda, et al. Experimental [Page 1]RFC 2844 OSPF over ATM and Proxy-PAR May 20001.1 Introduction to Proxy-PAR
Proxy-PAR  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  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  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
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  fashion, forming a full mesh of
point-to-point connections to interact with each other to simulate
broadcast interfaces. For the same purpose, LANE  or MARS 
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. . 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].
1.1.1 Proxy-PAR Scopes
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 .
Przygienda, et al. Experimental [Page 2]RFC 2844 OSPF over ATM and Proxy-PAR May 2000