RFC 2843 (rfc2843) - Page 2 of 13
Proxy-PAR
Alternative Format: Original Text Document
RFC 2843 Proxy-PAR May 2000
The intention of this document is to provide general information
about Proxy-PAR. For the detailed protocol description we refer the
reader to [3].
Proxy-PAR is a protocol that allows various ATM-attached devices (ATM
and non-ATM devices) to interact with PAR-capable switches to
exchange information about non-ATM services without executing PAR
themselves. The client side is much simpler in terms of
implementation complexity and memory requirements than a complete PAR
instance. This should allow an easy implementation on existing IP
devices such as IP routers. Additionally, clients can use Proxy-PAR
to register various non-ATM services and the protocols they support.
The protocol has deliberately been omitted from ILMI [4] because of
the complexity of PAR information passed in the protocol and the fact
that it is intended for the integration of non-ATM protocols and
services only. A device executing Proxy-PAR does not necessarily need
to execute ILMI or UNI signalling, although this will normally be the
case.
The protocol does not specify how a client should make use of the
obtained information to establish connectivity. For example, OSPF
routers finding themselves through Proxy-PAR could establish a full
mesh of P2P VCs by means of RFC 2225 [5], or use RFC 1793 [6] to
interact with each other. LANE [7] or MARS [8] could be used for the
same purpose. It is expected that the guidelines defining how a
certain protocol can make use of Proxy-PAR should be produced by the
appropriate working group or standardization body responsible for the
particular protocol. An additional RFC [9] describing how to run OSPF
together with Proxy-PAR is published together with this document.
The protocol has the ability to provide ATM address resolution for
IP-attached devices, but such resolutions can also be achieved by
other protocols under specification in the IETF, e.g. [10]. Again,
the main purpose of the protocol is to allow the automatic detection
of devices over an ATM cloud in a distributed fashion, omitting the
usual pitfalls of server-based solutions. Last but not least, it
should be mentioned here as well that the protocol complements and
coexists with the work done in the IETF on server detection via ILMI
extensions [11,12,13].
2 Proxy-PAR Operation and Interaction with PNNI
The protocol is asymmetric and consists of a discovery and
query/registration part. The discovery is very similar to the
existing PNNI Hello protocol and is used to initiate and maintain
communication between adjacent clients and servers. The registration
and update part execute after a Proxy-PAR adjacency has been
established. The client can register its own services by sending
Droz & Przygienda Informational