RFC 2843 (rfc2843) - Page 3 of 13

Proxy-PAR

RFC 2843                       Proxy-PAR                        May 2000


   registration messages to the server. The client obtains information
   it is interested in by sending query messages to the server. When the
   client needs to change its set of registered protocols, it has to
   re-register with the server. The client can withdraw all registered
   services by registering a null set of services. It is important to
   note that the server side does not push new information to the
   client, neither does the server keep any state describing which
   information the client received. It is the responsibility of the
   client to update and refresh its information and to discover new
   clients or update its stored information about other clients by
   issuing queries and registrations at appropriate time intervals. This
   simplifies the protocol, but assumes that the client will not store
   and request large amounts of data. The main responsibility of the
   server is to flood the registered information through the PNNI cloud
   such that potential clients can discover each other. The Proxy-PAR
   server side also provides filtering functions to support VPNs and IP
   subnetting. It is assumed that services advertised by Proxy-PAR will
   be advertised by a relatively small number of clients and be fairly
   stable, so that polling and refreshing intervals can be relatively
   long.

   The Proxy-PAR extensions rely on appropriate flooding of information
   by the PNNI protocol. When the client side registers or re-registers
   a new service through Proxy-PAR, it associates an abstract membership
   scope with the service. The server side maps this membership scope
   into a PNNI routing level that restricts the flooding. This allows
   changes of the PNNI routing level without reconfiguration of the
   client. In addition, the server can set up the mapping table such
   that a client can flood information only to a certain level. Nodes
   within the PNNI network take into account the associated scope of the
   information when it is flooded.  It is thus possible to exploit the
   PNNI routing hierarchy by announcing different protocols on different
   levels of the hierarchy, e.g. OSPF could be run inside certain peer
   groups, whereas BGP could be run between the set of peer -groups
   running OSPF. Such an alignment or mapping of non-ATM protocols to
   the PNNI hierarchy can drastically enhance the scalability and
   flexibility of Proxy-PAR service. Figure 1 helps visualize such a
   scenario. For this topology the following registrations are issued:













Droz & Przygienda            Informational