Sign in
Version 5.3.0, 2014-04-12
Report a bug

OSPF over ATM and Proxy-PAR
RFC 2844

Document type: RFC - Experimental (May 2000)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 2844 (Experimental)
Responsible AD: (None)
Send notices to: No addresses provided

Network Working Group                                       T. Przygienda
Request for Comments: 2844                                          Siara
Category: Experimental                                            P. Droz
                                                                  R. Haas
                                                                 May 2000

                      OSPF over ATM and Proxy-PAR

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

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


   This memo specifies, for OSPF implementors and users, mechanisms
   describing how the protocol operates in ATM networks over PVC and SVC
   meshes with the presence of Proxy-PAR. These recommendations require
   no protocol changes and allow simpler, more efficient and cost-
   effective network designs. It is recommended that OSPF
   implementations should be able to support logical interfaces, each
   consisting of one or more virtual circuits and used either as
   numbered logical point-to-point links (one VC), logical NBMA networks
   (more than one VC) or Point-to-MultiPoint networks (more than one
   VC), where a solution simulating broadcast interfaces is not
   appropriate. PAR can help distribute across the ATM cloud
   configuration setup and changes of such interfaces when OSPF capable
   routers are (re-)configured.  Proxy-PAR can in turn be used to
   exchange this information between the ATM cloud and the routers
   connected to it.

1 Introduction

   Proxy-PAR and PAR have been accepted as standards by the ATM Forum in
   January 1999 [1]. A more complete overview of Proxy-PAR than in the
   section below is given in [2].

Przygienda, et al.            Experimental                      [Page 1]
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

   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                      [Page 2]
RFC 2844              OSPF over ATM and Proxy-PAR               May 2000

[include full document text]