RFC 2843 (rfc2843) - Page 2 of 13

Proxy-PAR

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