RFC 2843

Document Type RFC - Informational (May 2000; No errata)
Authors Tony Przygienda  , Patrick Droz 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2843 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           P. Droz
Request for Comments: 2843                                          IBM
Category: Informational                                   T. Przygienda
                                                               May 2000


Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.


   Proxy-PAR is a minimal version of PAR (PNNI Augmented Routing) that
   gives ATM-attached devices the ability to interact with PNNI devices
   without the necessity to fully support PAR. Proxy-PAR is designed as
   a client/server interaction, of which the client side is much simpler
   than the server side to allow fast implementation and deployment.

   The purpose of Proxy-PAR is to allow non-ATM devices to use the
   flooding mechanisms provided by PNNI for registration and automatic
   discovery of services offered by ATM attached devices.  The first
   version of PAR primarily addresses protocols available in IPv4. But
   it also contains a generic interface to access the flooding of PNNI.
   In addition, Proxy-PAR-capable servers provide filtering based on VPN
   IDs [1], IP protocols and address prefixes. This enables, for
   instance, routers in a certain VPN running OSPF to find OSPF
   neighbors on the same subnet. The protocol is built using a
   registration/query approach where devices can register their services
   and query for services and protocols registered by other clients.

1 Introduction

   In June of 1996, the ATM Forum accepted the "Proxy-PAR contribution
   as minimal subset of PAR" as a work item of the Routing and
   Addressing (RA) working group, which was previously called the PNNI
   working group [2].  The PAR [3] specification provides a detailed
   description of the protocol including state machines and packet

Droz & Przygienda            Informational                      [Page 1]
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

   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 RFC2225 [5], or use RFC1793 [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
Show full document text