Internet Engineering Task Force                    T. Przygienda/P. Droz
INTERNET DRAFT                                                  Fore/IBM
                                                         30 October 1997                                             Bell Labs/IBM
                                                            5 March 1998

                      OSPF over ATM and Proxy PAR
                      <draft-ietf-ospf-atm-00.txt>
                      <draft-ietf-ospf-atm-01.txt>

Status of This Memo
   This document is an Internet Draft, and can be found as
   draft-ietf-ospf-atm-00.txt
   draft-ietf-ospf-atm-01.txt in any standard internet drafts
   repository.  Internet Drafts are working documents of the Internet
   Engineering Task Force (IETF), its Areas, and its Working Groups.
   Note that other groups may also distribute working documents as
   Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material, or to cite them other than as a
   ``working draft'' or ``work in progress.''
   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.

Abstract
   This draft specifes 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 do not
   require any protocol changes and allow for simpler, more efficient
   and cost- effective 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 as numbered
   logical point-to-point links (one VC) or logical NBMA networks (more
   than one VC) where a solution simulating broadcast interfaces is not
   appropriate.  Proxy  PAR can help to distribute configuration changes of
   such interfaces when OSPF capable routers are reconfigured on the ATM
   cloud.

1. Introduction

1.1. Introduction to Proxy PAR

   Proxy PAR [CPS96, PD97]

   PNNI Augmented Routing (PAR) [For98] is an extension allowing for different ATM
   attached devices to interact with PAR capable switches and obtain PNNI [AF96b]
   routing to allow information about non-ATM services without executing PAR [Ca96] which
   is to be distributed
   in an extension ATM network as part of the PNNI [AF96b] themselves. topology.  The client side is much
   simpler in terms of implementation complexity content and memory requirements
   than a complete
   format of the information is specified by PAR stack but is transparent to
   PNNI routing.  A PAR-capable device, one that implements PNNI and should allow for easy implementation in
   e.g.  existing IP routers.  Additionally, clients can use Proxy the
   PAR extension, is able to register different create PAR PTSEs that describe the non-ATM
   services and protocols they support.
   Proxy PAR has consciously not been included as part of ILMI due located on or behind that device.  Because this information
   is flooded by PNNI routing, PAR-capable devices are also able to
   examine the complexity of PAR information passed PTSEs in the protocol and the
   fact topology database that it is intended for integration of non-ATM protocols and were originated
   by other nodes to obtain information on desired services only.  A device executing Proxy reachable
   through the ATM network.  An important example of how PAR does not necessarily
   need to execute ILMI or UNI signaling although this normally will can be used
   is provided by overlay routing on ATM backbones.  If the case.  The context routers
   are PAR-capable, they can create PTSEs to advertise the routing
   protocol supported on the given interface (e.g., OSPF, RIP, or reference model is therefore aligned BGP),
   along with their IP address and subnet, and other protocol-specific
   details.  The PAR-capable routers can also automatically learn about
   "compatible" routers (e.g., supporting the one included same routing protocol,
   in [AF96a].

   The protocol the same IP subnet) active in itself does not specify how the distributed service
   registration and data delivered to same ATM network.  In this
   manner the client is supposed to overlay routing network can be
   driving other protocols so OSPF routers finding themselves through
   proxy established automatically
   on an ATM backbone.  The mechanism is dynamic, and does not require
   configuration.  One potential drawback of PAR could use this information in e.g.  RFC1577 [Lau94]
   fashion, forming is that a full mesh device must
   implement PNNI in order to participate.  Therefore an additional set
   of point- to-point connections optional protocols called Proxy PAR has been defined to allow a
   client that is not PAR-capable to interact with each other to simulate broadcast interfaces.  For a server that is
   PAR-capable and thus obtain the
   same purpose LANE [AF95] or MARS [Arm96] could be used.  Contrary
   to such solutions, this RFC elaborates on how to handle virtual
   OSPF interfaces over ATM such PAR capabilities.  The server acts as NBMA, point-to-multipoint or
   point-to-point and allow
   a proxy for their auto-configuration the client in presence of
   Proxy PAR. One advantage is the circumvention of server solutions
   that often present single points of failure or hold large amounts operation of
   configuration information. PAR. The other main benefit client is able to
   register its own services, and query the possibility server to execute OSPF obtain information
   on top compatible services available in the ATM network.  A key feature
   of partially meshed VC topologies.

   As a by-product, PAR and Proxy PAR could provide is the ATM address resolution
   for IP attached devices but such resolution ability to provide VPN support in a
   simple yet very effective manner.  All PAR information is tagged
   with a VPN ID and can therefore be filtered on that basis.  This can
   be achieved by other
   protocols under specification used for example, in IETF as well, e.g.  [CH97a, CH97b].
   Last but not least, it should a service provider network.  Each customer
   can be mentioned here that the protocol
   coexists provided with and complements the ongoing work in IETF on server
   detection via ILMI extensions [Dav97] and opaque LSAs [CH97a, CH97b].

1.1.1. Proxy PAR scopes

   Any Proxy PAR registration is carried only within a defined scope unique VPN ID that is set during registration part of all Proxy PAR
   registrations and is equivalent to queries.  Usage of the PNNI routing
   level.  Since no assumptions except scope values correct VPN ID can easily
   be made about enforced at the information distributed (e.g.  IP addresses bound to NSAPs
   are not assumed to Proxy PAR server.  In this way the services of a
   given customer will be aligned with them available only to clients in any respect such as
   encapsulation or functional mapping), registration information cannot
   be summarized.  This makes a careful handling that customer's
   network.

1.1.1. Overview of scopes necessary to
   preserve the scalability.

1.2. Introduction to OSPF

   OSPF (Open Shortest Path First) PNNI Augmented Routing (PAR)

   PNNI Augmented Routing (PAR) is an Interior Gateway Protocol (IGP)
   and described in [Moy94, Moy97] from which most of extension to PNNI to allow the following
   paragraphs has been taken almost literally.  OSPF distributes routing
   flooding of information between routers belonging to about non-ATM devices.  PAR uses a single Autonomous System. new PTSE
   type to carry this non-ATM-related information.  The OSPF current version
   of PAR specifies IGs for the flooding of IPv4-related protocol is based on link-state
   information such as OSPF or SPF technology.  It was
   developed by BGP. In addition PAR also allows the OSPF working group use
   of the Internet Engineering
   Task Force.  It has been designed expressly for the TCP/IP internet
   environment, including explicit support for IP subnetting, and System Capabilities IG, which can be used to carry proprietary
   or experimental information.

   PAR supports extensive filtering possibilities, which allow the tagging
   implementation of externally-derived virtual private networks (VPN). As PAR is a
   PNNI extension, it can reuse existing PNNI routing information.  OSPF also
   utilizes IP multicast when sending/receiving the updates. level scopes.
   In addition, much work has been done to produce PAR provides filtering in terms of a VPN ID, IP
   address, including a subnet mask, as well as protocol that responds
   quickly flags.  The
   correct filtering according to topology changes, yet involves small amounts these parameters is part of routing
   protocol traffic.

   To cope with the needs a PAR
   implementation.

1.1.2. Overview of NBMA and Proxy PAR

   Proxy PAR is a protocol that allows for different ATM attached
   devices to interact with PAR-capable switches and obtain 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 and should allow easy
   implementation in, for example, existing IP routers.  Clients can use
   Proxy PAR to register different non-ATM services and protocols they
   support.  This protocol has deliberately not been included as part of
   ILMI [AF96a] owing 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 executing Proxy PAR does not
   necessarily need to execute ILMI or UNI signaling, although this will
   normally be the case.
   The protocol does not specify how the distributed service
   registration and data delivered to the client are supposed to drive
   other protocols.  For example, OSPF routers finding themselves
   through Proxy PAR could use this information to form a full mesh of
   P2P VCs and communicate using RFC1483 [Hei93] encapsulation.  In
   terms of the discovery of other devices such as IP routers, Proxy PAR
   is an alternative to LANE [AF95] or MARS [Arm96].  It is expected
   that the guidelines defining how a certain protocol can make use of
   Proxy PAR and PAR should come from the group or standardization body
   that is responsible for the particular protocol.

   PAR and Proxy PAR have the ability to provide ATM address resolution
   for IP attached devices, but such resolution can also be achieved by
   other protocols under specification in IETF e.g.  [CH97a, CH97b].
   However, the main purpose of the protocol is to allow the automatic
   detection of devices over an ATM cloud in a distributed fashion, not
   relying on a broadcast facility.  Finally, it should be mentioned
   that the protocol complements and coexists with server detection via
   ILMI extensions.

1.2. Introduction to OSPF
   OSPF (Open Shortest Path First) is an Interior Gateway Protocol (IGP)
   and described in [Moy94, Moy97] from which most of the following
   paragraphs has been taken almost literally.  OSPF distributes routing
   information between routers belonging to a single Autonomous System.
   The OSPF protocol is based on link-state or SPF technology.  It was
   developed by the OSPF working group of the Internet Engineering
   Task Force.  It has been designed expressly for the TCP/IP internet
   environment, including explicit support for IP subnetting, and
   the tagging of externally-derived routing information.  OSPF also
   utilizes IP multicast when sending/receiving the updates.  In
   addition, much work has been done to produce a protocol that responds
   quickly to topology changes, yet involves small amounts of routing
   protocol traffic.

   To cope with the needs of NBMA and demand circuits capable networks
   such as Frame Relay or X.25, [Moy95] has been made available that
   standardizes extensions or X.25, [Moy95] has been made available that
   standardizes extensions to the protocol allowing for efficient
   operation over on-demand circuits.
   OSPF supports three types of networks today:

    -  Point-to-point networks:  A network that joins a single pair
       of routers.  Point- to-point networks can either be numbered
       or unnumbered in the latter case the interfaces do not have IP
       addresses nor masks.  Even when numbered, both sides of the link
       do not have to agree on the IP subnet.

    -  Broadcast networks:  Networks supporting many (more than two)
       attached routers, together with the capability to address
       a single physical message to all of the attached routers
       (broadcast).  Neighboring routers are discovered dynamically
       on these nets using OSPF's Hello Protocol.  The Hello Protocol
       itself takes advantage of the broadcast capability.  The protocol
       makes further use of multicast capabilities, if they exist.  An
       Ethernet is an example of a broadcast network.

    -  Non-broadcast networks:  Networks supporting many (more than
       two) attached routers, but having no broadcast capability.

       Neighboring routers are maintained on these nets using
       OSPF's Hello Protocol.  However, due to the lack of broadcast
       capability, some configuration information is necessary for the
       correct operation of the Hello Protocol.  On these networks, OSPF
       protocol packets that are normally multicast need to be sent to
       each neighboring router, in turn.  An X.25 Public Data Network
       (PDN) is an example of a non-broadcast network.

       OSPF runs in one of two modes over non-broadcast networks.  The
       first mode, called non-broadcast multi-access (NBMA), simulates
       the operation of OSPF on a broadcast network.  The second mode,
       called Point-to-MultiPoint, treats the non-broadcast network as a
       collection of point-to-point links.  Non-broadcast networks are
       referred to as NBMA networks or Point-to-MultiPoint networks,
       depending on OSPF's mode of operation over the network.

2. OSPF over ATM
2.1. Model

   Contrary to broadcast-simulation based solutions such as LANE [AF95]
or RFC1577 [Lau94], this RFC elaborates on how to handle virtual OSPF
interfaces over ATM such as NBMA, point-to-multipoint or point-to-point
and allow for their auto-configuration in presence of Proxy PAR.
One advantage is the circumvention of server solutions that often
present single points of failure or hold large amounts of configuration
information.  The other main benefit is the possibility to execute OSPF
on top of partially meshed VC topologies.
   Parallel to [dR94] that describes the recommended operation of
   OSPF over Frame Relay networks, a similar model is assumed where
   the underlying ATM network can be used to model single VCs as
   point-to-point interfaces or collections of VCs can be accessed as an
   non-broadcast interface in NBMA or point-to-multipoint mode.  Such a
   VC or collection of VCs is called a logical interface and specified
   through its type (either point-to-point, NBMA or point-to-point),
   IP instance (presenting an incarnation of IP with its own address
   spaces), address and mask.  Layer 2 specific configuration such as
   address resolution method, class and quality of service of used
   circuits and other must be also included.  As logical consequence
   thereof, a single, physical interface could encompass multiple IP
   subnets or even multiple, independent IP instances.  In contrary to
   layer 2 and IP addressing information, when running Proxy PAR, most
   of the OPSF information needed to operate such a logical interface
   does not have to be configured into routers statically but can be
   provided through Proxy PAR queries.  This allows for much more
   dynamic configuration of VC meshes in OSPF environments than e.g.  in
   Frame Relay solutions.

2.2. OSPF Configuration Interaction with Proxy PAR
   To achieve the goal of simplification of VC mesh reconfiguration,
   Proxy PAR allows the router to the protocol allowing for efficient
   operation over on-demand circuits.

   OSPF supports three types learn automatically most of networks today:

    -  Point-to-point networks:  A network the
   configuration that joins a single pair
       of routers.  Point- to-point networks has to be provided to OSPF. Non-broadcast
   and point-to-point interface information can either be numbered
       or unnumbered learned across
   an ATM cloud as described in the latter case ongoing sections.  It is up to
   the interfaces do implementation to possibly allow for a mixture of Proxy PAR
   autoconfiguration and manual configuration of neighbor information.
   Moreover, manual configuration could e.g.  override or complement
   information derived from a proxy PAR client.  Additionally, OSPF
   extensions to handle on-demand circuits [Moy95] can be used to allow
   for graceful tearing down of VCs not have IP
       addresses nor masks. carrying any OSPF traffic over
   prolonged periods of time.  The different interactions are described
   in sections 2.2.1, 2.2.2 and 2.2.3.

   Even when numbered, both sides after autoconfiguration of interfaces has been provided, the link
       do not have to agree on the IP subnet.

    -  Broadcast networks:  Networks supporting many (more than two)
       attached routers, together with
   problem of VC setups in an ATM network is unsolved since none of the capability
   normally used mechanisms such as RFC1577 [Lau94] or LANE [AF95] are
   assumed to address
       a single physical message be present.  Section 2.5 describes the behavior of OSPF
   routers to all allow for router connectivity necessary.

2.2.1. Autoconfiguration of Non-Broadcast Interfaces

   Proxy PAR allows to autoconfigure the attached list of all routers
       (broadcast).  Neighboring residing
   on the same IP network in the same IP instance by simply querying
   the Proxy PAR server.  Each router can easily obtain the list of
   all OSPF routers are discovered dynamically on these nets using OSPF's Hello Protocol.  The Hello Protocol
       itself takes advantage of the broadcast capability.  The protocol
       makes further use of multicast capabilities, if they exist.  An
       Ethernet same subnet with their router priorities
   and ATM address bindings.  This is the precondition for OSPF to
   work properly across such logical NBMA interfaces.  Note that the
   memberlist, when learned through Proxy PAR queries, can dynamically
   change with PNNI (in)stability and general ATM network behavior.  It
   maybe preferable for an example of a broadcast network.

    -  Non-broadcast networks:  Networks supporting many (more implementation to withdraw list membership
   e.g.  much slower than
       two) attached routers, but having no broadcast capability.
       Neighboring routers are maintained detect new members.  Relying on these nets using
       OSPF's Hello Protocol.  However, due OSPF mechanism
   to the discover lack of broadcast
       capability, some configuration reachability in the overlaying logical IP network
   could alleviate the risk of thrashing DR elections and excessive
   information flooding.  Once the DR registration is necessary for completed and the
       correct operation
   router has not been elected DR or BDR, an implementation of [Moy95]
   can ignore the Hello Protocol.  On these networks, OSPF
       protocol packets fact that all routers on the specific NBMA subnet are normally multicast need
   available in its configuration since it only needs to be sent maintain VCs to
       each neighboring router, in turn.  An X.25 Public Data Network
       (PDN) is an example of a non-broadcast network.

       OSPF runs in one of two modes over non-broadcast networks.  The
       first mode, called non-broadcast multi-access (NBMA), simulates
       the operation of OSPF on a broadcast network.  The second mode,
       called Point-to-MultiPoint, treats
   the non-broadcast network as DR and BDR.

   Traditionally, router configuration for a
       collection of point-to-point links.  Non-broadcast networks are
       referred to as NBMA networks or Point-to-MultiPoint networks,
       depending on OSPF's mode network provides
the list of operation over all neighboring routers to allow for proper protocol
operation.  For stability purposes, the network.

2. OSPF over ATM

2.1. Model

   Parallel user may choose to [dR94] that describes provide a
list of neighbors through such static means but additionally enable the recommended
operation of
   OSPF over Frame Relay networks, a similar model Proxy PAR protocol to complete the list.  It is assumed where left to
specific router implementations whether the underlying ATM network can be manual configuration is used
in addition to model single VCs the information provided by Proxy PAR, used as
   point-to-point interfaces filter of
the dynamic information or collections whether a concurrent mode of operation is
prohibited.  In any case it should be obvious that allowing for more
flexibility may facilitate operation but provides more possibilities for
misconfiguration as well.

2.2.2. Autoconfiguration of Point-to-Multipoint Interfaces

   Point-to-Multipoint interfaces in ATM networks only make sense if
   no VCs can be accessed as dynamically set up since an
   non-broadcast interface in SVC-capable ATM network
   normally presents a NBMA cloud to OSPF. This is e.g.  the case if
   the intended use of the network is only to execute OSPF in presence
   of a partial PVC or point-to-multipoint mode. SPVC mesh or pre-determined SVC meshes.  Such
   a
   VC or collection could be modeled using the point-to-multipoint OSPF
   interface and the neighbor detection could be provided by Proxy
   PAR or other means.  In Proxy PAR case the router queries for all
   OSPF routers on the same network in the same IP instance but it
   installs in the interface configuration only routers that are already
   reachable through preset PVCs.  The underlying assumption is that a
   router understands the remote NSAP of VCs is called a logical interface PVC and specified
   through its type (either point-to-point, NBMA or point-to-point),
   IP instance (presenting an incarnation of IP can compare it with its own address
   spaces), address and mask.  Layer 2 specific configuration such as
   address resolution method, class and quality of service
   appropriate Proxy PAR registrations.  If the remote NSAP of the PVC
   is unknown, alternative autodiscovery mechanisms have to be used
   circuits e.g.
   inverse ARP [BB92, LH96].

2.2.3. Autoconfiguration of Numbered Point-to-Point Interfaces

   OSPF point-to-point links do not necessarily have an IP address
   assigned and other must be also included. even when having one, the mask is undefined.  As logical consequence
   thereof, a single, physical interface could encompass multiple IP
   subnets or even multiple, independent IP instances.  In contrary
   precondition to
   layer 2 and IP addressing information, when running successfully register a service with Proxy PAR, most IP
   address and mask is required.  Therefore, if a router desires to use
   Proxy PAR to advertise the local end of a point-to- point link to the OPSF information needed
   router it intends to operate such a logical interface
   does not have form an adjacency with, an IP address has to
   be configured into routers statically but can be provided through Proxy PAR queries.  This allows for much more
   dynamic configuration and a netmask set or a default of VC meshes in OSPF environments than e.g.  in
   Frame Relay solutions.

2.2. OSPF Configuration Interaction 255.255.255.254 (this
   gives as the default case a subnet with Proxy PAR 2 routers on it) assumed.  To achieve
   allow the goal discovery of simplification the remote end of VC mesh reconfiguration,
   Proxy PAR allows the router to learn automatically most interface, IP address
   of the
   configuration that remote side has to be provided to OSPF. Non-broadcast and point-to-point interface information can be learned across
   an ATM cloud as described in the ongoing sections.  It is up to
   the implementation to possibly allow for a mixture of Proxy PAR
   autoconfiguration and manual configuration of neighbor information.
   Moreover, manual configuration could e.g.  override netmask set or complement
   information derived from a proxy PAR client.  Additionally, OSPF
   extensions to handle on-demand circuits [Moy95] default
   of 255.255.255.254 assumed.  Obviously the discovery can only be used to allow
   for graceful tearing down of VCs not carrying any OSPF traffic over
   prolonged periods of time.

   Even after autoconfiguration
   successfull when both sides of interfaces has been provided, the
   problem of VC setups in an ATM interface are configured with the
   same network is unsolved since none of mask and are within the
   normally used mechanisms such as RFC1577 [Lau94] or LANE [AF95] same IP network.  The situation
   where more than two possible neighbors are
   assumed to be present.  Section 2.3 describes discovered through
   queries and the behavior of OSPF
   routers interface type is set to allow for router connectivity necessary.

2.2.1. point-to-point presents a
   configuration error.

2.2.4. Autoconfiguration of non-broadcast Unnumbered Point-to-Point Interfaces
   For reasons given already in [dR94] using unnumbered point-to-point
   interfaces with Proxy PAR allows to autoconfigure is not a very attractive alternative
   since the list lack of all routers residing
   on the same IP network in the same an IP instance by simply querying
   the Proxy PAR server.  Each router can easily obtain the list address prevents efficient registration and
   retrieval of
   all OSPF routers configuration information.  Relying on the same subnet with their router priorities
   and ATM address bindings.  This is numbering
   method based on MIB entries generates conflicts with the precondition for OSPF to
   work properly across dynamic
   nature of creation of such logical NBMA interfaces.  Note that entries and is beyond the
   memberlist, when learned through scope of this
   work.

2.3. Proxy PAR queries, can dynamically
   change Interaction with PNNI (in)stability and general ATM network behavior.  It
   maybe preferable for an implementation to withdraw list membership
   e.g.  much slower than detect new members.  Relying on OSPF mechanism Configuration
   To allow other routers to discover lack of reachability in an OSPF interface automatically,
   the overlaying logical IP network
   could alleviate the risk of thrashing DR elections address, mask, Area ID, interface type and excessive router priority
   information flooding.  Once the DR registration is completed and given must be registered with the
   router has not been elected DR or BDR, Proxy PAR server at an implementation
   appropriate scope.  A change in any of [Moy95]
   can ignore the fact these parameters has to force
   a reregistration with Proxy PAR.

   It should be emphasized here that all routers on the specific NBMA subnet are
   available in its configuration since it only needs to maintain VCs to the DR and BDR.

2.2.2. Autoconfiguration of point-to-multipoint interfaces

   Point-to-Multipoint interfaces in ATM networks only make sense if
   no VCs registration information
   can be dynamically set up since an SVC-capable ATM network
   normally presents a NBMA cloud.  This is e.g.  the case if the
   intended use used by other routers to resolve IP addresses against NSAPs as
   explained in section 2.4 already, whole IP address of the network router must
   be registered.  It is only not enough to execute OSPF in presence of a
   partial PVC or SPVC mesh.  Such a collection could just indicate the subnet up to
   the mask length but all address bits must be modeled using
   the point-to-multipoint OSPF provided.

2.3.1. Registration of Non-Broadcast Interfaces

   For an NBMA interface and the neighbor detection
   could appropriate parameters are available and
   can be provided by registered through Proxy PAR or other means. without further complications.

2.3.2. Registration of Point-to-Multipoint Interfaces

   In Proxy PAR case of a point-to-multipoint interface the router queries for all OSPF routers on the same network registers its
   information in the same IP instance but it installs fashion as in the interface configuration
   only routers that are already reachable through preset PVCs.  The
   underlying assumption is NBMA case except that a router understands the remote NSAP of
   a PVC and can compare it with appropriate Proxy PAR registrations.
   If the remote NSAP of the PVC
   interface type is unknown, alternative autodiscovery
   mechanisms have to be used e.g.  inverse ARP [BB92].

2.2.3. Autoconfiguration modified accordingly.

2.3.3. Registration of Point-to-Point Interfaces

   In case of numbered point-to-point numbered interfaces

   OSPF point-to-point links do not necessarily have an IP address
   assigned and even when having one, the mask is undefined.  As a
   precondition to successfully register a service with Proxy PAR, IP address and mask is required.  Therefore, if a not
   specified in the OSPF configuration.  If the router desires has to use Proxy
   PAR to advertise the local end of its capability, a point-to- point link mask must be defined or a default
   value of 255.255.255.254 used.

2.3.4. Registration of Unnumbered Point-to-Point Interfaces

   Due to the
   router it intends to form an adjacency with, an lack of a configured IP address has and difficulties generated
   by this fact as described earlier, registration of unnumbered
   point-to-point interfaces is not covered in this document.

2.4. IP address to NSAP Resolution Using Proxy PAR

   As a byproduct of Proxy PAR presence, an OSPF implementation
could use the information in registrations for the resolution of IP
addresses to
   be provided and ATM NSAPs on a netmask set subnet without having to use static data or a default of 255.255.255.254 (this
   gives
mechanisms such as the default case a subnet with 2 routers on it) assumed.  To ATMARP [LH96].  This again should allow the discovery for drastic
simplification of the remote end number of the interface, mechanisms involved in operation of OSPF
over ATM to provide an IP address overlay.

2.5. Connection Setup Mechanisms

   This sections describes OSPF behavior in an ATM network under
   different assumptions in terms of signaling capabilities and preset
   connectivity.

2.5.1. OSPF in PVC Environments

   In environments where only partial PVCs (or SPVCs) meshes are
   available and modeled as point-to-multipoint interfaces, the remote side has to be routers
   see reachable routers through autodiscovery provided and a netmask set or by Proxy PAR.
   This leads to expected OSPF behavior.  In cases where a default full mesh of 255.255.255.254 assumed.  Obviously the
   PVCs is present, such an interface should preferably be modeled as
   broadcast and Proxy PAR discovery can only should be
   successfull when both sides of superfluous.

2.5.2. OSPF in SVC Environments

   In SVC-capable environments the interface are configured with routers can initiate VCs after having
   discovered the
   same network mask and are within appropriate neighbors, preferably driven by the same IP network.  The situation need
   to send data such as Hello-packets.  Since this can lead to race
   conditions where more than two possible neighbors are discovered through
   queries both sides can open a VC and the interface type it is set desirable to point-to-point presents a
   configuration error.

2.2.4. Autoconfiguration of unnumbered point-to-point interfaces

   For reasons given already in [dR94] using unnumbered point-to-point
   minimize this valuable resource, if the router with lower Router ID
          +           +                             +
          |   +---+   |                             |
   +--+   |---|RTA|---|          +-------+          |   +--+
   |H1|---|   +---+   |          | ATM   |          |---|H2|
   +--+   |           |   +---+  | Cloud |  +---+   |   +--+
          |LAN Y      |---|RTB|-------------|RTC|---|
          +           |   +---+  | PPAR  |  +---+   |
                      +          +-------+          +

 Figure 1:  Simple Topology with Router B and Router C operating across
                   NBMA ATM interfaces with Proxy PAR is not a very attractive alternative
   since the lack of an IP address prevents efficient registration and
   retrieval of configuration information.  Relying on

   detects that the numbering
   method based on MIB entries generates conflicts with VC initiated by the dynamic
   nature of creation of such entries and other side is beyond bidirectional, it
   is free to close its own VC and use the scope of detected one.  Observe that
   this
   work.

2.3. Proxy PAR Interaction with behavior operates correctly in case OSPF Configuration

   To allow other routers to discover an over Demand Circuits
   extensions are used [Moy95] over SVC capable interfaces.

   The existence of VCs used for OSPF interface automatically, exchanges is orthogonal to the IP address, mask, Area ID, interface type
   number and type of VCs the router priority
   information given must be registered with chooses to use within the Proxy PAR server at an
   appropriate scope.  A change in logical
   interface to forward data to other routers.  OSPF implementations are
   free to use any of these parameters has VCs (1) to force
   a reregistration with Proxy PAR.

2.3.1. Registration of non-broadcast interfaces

   For an NBMA interface the appropriate parameters send packets if their endpoints
   are available adequate and
   can be registered through Proxy PAR without further complications.

2.3.2. Registration of point-to-multipoint interfaces

   In case must accept hello packets arriving on any of a point-to-multipoint interface the router registers its
   information in the same fashion as in the NBMA case except that VCs
   belonging to the logical interface even if OSPF operating on such an
   interface type is modified accordingly.

2.3.3. Registration of point-to-point interfaces

   In case of point-to-point numbered interfaces the address mask is not
   specified in the aware of their existence.  An OSPF configuration.  If the implementation
   may not accept or close connections being initiated by another router
   that has to use either not been discovered by Proxy PAR to advertise its capability, a mask must be defined or a default
   value of 255.255.255.254 used.

2.3.4. Registration of unnumbered point-to-point interfaces

   Due to the lack of a configured IP address and difficulties generated
   by this fact as described earlier, whose Proxy PAR
   registration of unnumbered
   point-to-point interfaces is indicating that it is not covered in this document.

2.4. Connection setup mechanisms

   This sections describes OSPF behavior in adjacent.
   As an ATM network under
   different assumptions in terms of signaling capabilities and preset
   connectivity.

2.4.1. OSPF example consider the topology in PVC environments

   In environments figure 2.5.2 where only partial PVCs (or SPVCs) meshes are
   available router
   RTB and modeled as point-to-multipoint interfaces, the routers
   see reachable routers through autodiscovery provided by Proxy PAR.
   This leads RTC are connected to expected OSPF behavior.  In cases where a full mesh of
   PVCs common ATM cloud offering Proxy PAR
   services.  Assuming that RTB's OSPF implementation is present, such an aware of SVCs
   initiated on the interface should preferably be modeled as
   broadcast and RTC only makes minimal use of Proxy
   PAR discovery should be superfluous.

2.4.2. OSPF in SVC environments

   In SVC-capable environments the routers can initiate VCs after having
   discovered information the appropriate neighbors, preferably driven by following sequence could develop illustrating
   some of the need
   to send data such cases described above:

    1. RTC and RTB register with ATM cloud as Hello-packets.  Since this can lead Proxy PAR capable and
       discover each other as adjacent OSPF routers.

___________________________________________
1. in case they are aware of their existence
    2. RTB sends a hello which forces it to race
   conditions where both sides can open establish a SVC connection
       to RTC.

    3. RTC sends a hello to RTB but disregards the already existing VC
       and it is desirable establishes a new VC to
   minimize this valuable resource, if RTB to deliver the router with lower Router ID
   detects packet.

    4. RTB sees a new bi-directional VC and assuming here that RTC's
       OSPF Id is higher, closes the VC initiated by the other side is bidirectional, it
   is free originated in step 2.

    5. Host H1 sends data to close its own VC H2 and use the detected one.  The existence
   of VCs used for OSPF exchanges is orthogonal RTB establishes a new data SVC
       between itself and RTC.

    6. RTB sends a Hello to the number RTC and type
   of VCs the router chooses decides to use within do it using the logical interface to
   forward newly
       establish data to other routers.  OSPF implementations are free to use
   any of these VCs to send packets if their endpoints are adequate and SVC. RTC must accept hello packets arriving on any of the VCs belonging to hello despite the
   logical interface. minimal
       implementation.

3. Acknowledgments
   Comments and contributions from several sources, especially Rob
   Coltun
   Coltun, Doug Dykeman and John Moy are included in this work.

4. Security Consideration

   Security
   Several aspects are to be considered when talking about security of
operating OSPF over ATM and/or Proxy PAR. The security of registered
information handed to the ATM cloud must be guaranteed by the underlying
PNNI protocol.  Extensions to PNNI are available and given their
implementation spoofing of registrations and/or denial-of-service issues
can be addressed [PB97].  The registration itself through proxy PAR is
not secured and appropriate mechanisms are for further study.  However,
even if the security at the ATM layer is not discussed in this memo. guaranteed, OSPF security
mechanisms can be used to verify that detected neighbors are authorized
to interact with the entity discovering them.

References
   [AF95]  ATM-Forum.  LAN Emulation over ATM 1.0.  ATM Forum
           af-lane-0021.000, January 1995.

   [AF96a] ATM-Forum.  Interim Local Management Interface (ILMI)
           Specification 4.0.  ATM Forum 95-0417R8, June 1996.

   [AF96b] ATM-Forum.  Private Network-Network Interface Specification
           Version 1.0.  ATM Forum af-pnni-0055.000, March 1996.

   [Arm96] G. Armitage.  Support for Multicast over UNI 3.0/3.1 based
           ATM Networks, RFC 2022.  Internet Engineering Task Force,
           November 1996.

   [BB92]  T. Bradley and C. Brown.  Inverse Address Resolution
           Protocol, RFC 1293.  Internet Engineering Task Force, January
           1992.

   [Ca96]  R. Callon and al.  An Overview of Pnni Augmented Routing.
           ATM Forum 96-0354, April 1996.

   [CH97a] R. Coltun and J. Heinanen.  Opaque LSA in OSPF.  Internet
           Draft, 1997.

   [CH97b] R. Coltun and J. Heinanen.  The OSPF Address Resolution
           Advertisement Option.  Internet Draft, 1997.

   [CPS96] R. Coltun, T. Przygienda, and S. Shew.  MIPAR: Minimal PNNI
           Augmented Routing.  ATM Forum 96-0838, June 1996.

   [Dav97] M. Davison.  Simple ILMI-Based Server Discovery.  Internet
           Draft, 1997.

   [dR94]  O. deSouza and M. Rodrigues.  Guidelines for Running OSPF
           Over Frame Relay Networks, RFC 1586.  Internet Engineering
           Task Force, March 1994.

   [For98] ATM Forum.  PNNI Augmented Routing (PAR) Version 1.0.  ATM
           Forum PNNI-RA-PAR-01.04, 1998.

   [Hei93] J. Heinanen.  Multiprotocol Encapsulation over ATM Adaptation
           Layer 5, RFC 1483.  Internet Engineering Task Force, July
           1993.

   [Lau94] M. Laubach.  Classical IP and ARP over ATM, RFC 1577.
           Internet Engineering Task Force, January 1994.

   [LH96]  M. Laubach and J. Halpern.  Classical IP and ARP over ATM.
           Internet Draft, 1996.

   [Moy94] J. Moy.  OSPFv2, RFC 1583.  Internet Engineering Task Force,
           March 1994.

   [Moy95] J. Moy.  Extending OSPF to Support Demand Circuits, RFC 1793.
           Internet Engineering Task Force, April 1995.

   [Moy97] J. Moy.  OSPFv2, RFC 2178.  Internet Engineering Task Force,
           July 1997.

   [PD97]

   [PB97]  T. Przygienda and P. Droz.  Proxy PAR. C. Bullard.  Baseline Text for PNNI Peer
           Authentication and Cryptographic Data Integrity.  ATM Forum 97-0495,
           97-0705, 97-0882,
           97-0472, July 1997.

Authors' Addresses

Tony Przygienda
FORE Systems
6905 Rockledge Drive
Suite 800
Bethesda, MD 20817
prz@fore.com
Bell Labs, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
prz@dnrc.bell-labs.com

Patrick Droz
IBM Research Division
Saumerstrasse 4
8803 Ruschlikon
Switzerland
dro@zurich.ibm.com