RFC 2844 (rfc2844) - Page 2 of 14
OSPF over ATM and Proxy-PAR
Alternative Format: Original Text Document
RFC 2844 OSPF over ATM and Proxy-PAR May 2000
1.1 Introduction to Proxy-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.
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].
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 [2].
Przygienda, et al. Experimental