RFC 2844

OSPF over ATM and Proxy-PAR

📅 published May 2000, from ietf

RFC 2844: OSPF over ATM and Proxy-PAR 🦋

Okay bestie, here's the whole vibe at a glance 💅

  • RFC number: 2844
  • Title: OSPF over ATM and Proxy-PAR
  • Working group: Network Working Group
  • Authors: T. Przygienda (Siara); P. Droz and R. Haas (IBM)
  • Category: Experimental
  • Date: May 2000
  • Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates ✨

Status of This Memo 🌸

Okay so this memo is an Experimental protocol for the Internet community, which means it is NOT an Internet standard of any kind 🙈 The authors are literally asking everyone to talk about it and suggest improvements. And distribution is unlimited, so share it with everyone you know 💜

Copyright (C) The Internet Society (2000). All Rights Reserved. Legal stuff, but it's giving proper paperwork energy 📄

Abstract ✨

So this memo is all about how OSPF implementers and users can run OSPF over ATM networks, using PVC and SVC meshes with Proxy-PAR around. The best part is that none of this needs any protocol changes 😭 It just makes network designs simpler, more efficient, and cheaper. 🫶

It is recommended that OSPF implementations should be able to support logical interfaces. Each one is made of one or more virtual circuits, and it can work as a numbered logical point-to-point link (one VC), a logical NBMA network (more than one VC), or a Point-to-MultiPoint network (more than one VC). This is the move when a solution that pretends to be a broadcast interface isn't the right fit 🦋

PAR can help spread the ATM cloud's configuration setup and any changes to these interfaces around, whenever OSPF-capable routers get (re-)configured. And Proxy-PAR can pass that same info back and forth between the ATM cloud and the routers plugged into it 🧚

1 Introduction 🌈

Proxy-PAR and PAR were accepted as standards by the ATM Forum in January 1999 [1]. There's a fuller overview of Proxy-PAR in [2] than the little section below, so go check that out if you want the whole story 📚

1.1 Introduction to Proxy-PAR 💖

Okay, so Proxy-PAR [1] is an extension that lets different ATM-attached devices (like routers) talk to PAR-capable switches and ask about non-ATM services, all without having to run PAR themselves 👑 The Proxy-PAR client side in the ATM-attached device is way simpler to implement and needs way less memory than a full PAR protocol stack. That full stack includes the whole PNNI [3] protocol stack, which is a lot 💀 Because of that, it should be easy to build, for example into existing IP routers ✨

Clients can also use Proxy-PAR to register the various non-ATM services and protocols they support. Proxy-PAR was intentionally left out of ILMI [4], because the PAR information in the protocol is complicated, and because it's meant for plugging in non-ATM protocols and services only 🙈 A device that runs Proxy-PAR doesn't have to run ILMI or UNI signaling, although it usually will 🫶

The protocol itself doesn't say how the distributed service registration and the data delivered to the client should drive other protocols. So OSPF routers that find each other through Proxy-PAR could use that info in a Classical IP and ARP over ATM [5] style, forming a full mesh of point-to-point connections so they can interact and pretend to have broadcast interfaces 🌸 LANE [6] or MARS [7] could also do that job. As a bonus, Proxy-PAR could handle ATM address resolution for IP-attached devices, but other IETF protocols, like [8], can do that too 🧚

Last but not least, the protocol coexists with and complements the ongoing IETF work on server detection via ILMI extensions [9,10,11] 💜

1.1.1 Proxy-PAR Scopes 🔥

Anything registered through Proxy-PAR only gets flooded within a defined scope. That scope gets set up during registration and matches the PNNI routing level 👑 Nobody can assume anything about the info being distributed. For example, IP addresses bound to NSAPs aren't assumed to line up with them in any way, like encapsulation or functional mapping. So it can't be summarized, which means you have to handle scopes super carefully to keep things scalable 😭 More details on scope usage are in [2] ✨

1.2 Introduction to OSPF 🍓

OSPF (Open Shortest Path First) is an Interior Gateway Protocol (IGP), described in [12]. A lot of the paragraphs that follow were taken almost word for word from that document 📚 OSPF distributes routing information between routers that belong to a single Autonomous System. It's based on link-state or SPF technology and was developed by the OSPF working group of the Internet Engineering Task Force. It was designed expressly for the TCP/IP internet environment, with explicit support for IP subnetting and for tagging externally-derived routing information 🦋 OSPF also uses IP multicast when it sends and receives updates. And a lot of work went into making it respond quickly to topology changes while keeping routing protocol traffic small 💅

To handle NBMA and demand-circuit-capable networks, like Frame Relay or X.25, [13] was made available. It standardizes extensions to the protocol that allow 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 be either numbered or unnumbered. In the unnumbered case, the interfaces have no IP addresses or masks. Even when they're numbered, both sides of the link don't have to agree on the IP subnet 🎀
  • Broadcast networks: Networks that support many (more than two) attached routers, plus the ability to address a single physical message to all of the attached routers (broadcast). Neighboring routers are discovered dynamically on these networks using the OSPF Hello Protocol, and the Hello Protocol itself takes advantage of the broadcast capability. The protocol also uses multicast capabilities, if they exist. An Ethernet is an example of a broadcast network 🌸
  • Non-broadcast networks: Networks that support many (more than two) attached routers, but have no broadcast capability. Neighboring routers are still maintained on these networks using OSPF's Hello Protocol. But because there's no broadcast, some configuration information is needed for the Hello Protocol to work correctly. On these networks, OSPF protocol packets that would normally be multicast need to be sent to each neighboring router, one at a time. 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 which mode OSPF is running in over that network 💖

2 OSPF over ATM ☁️

2.1 Model 🦋

Okay so this is the big difference: unlike broadcast-simulation-based solutions such as LANE [6] or Classical IP and ARP over ATM [5], this document explains how to handle virtual OSPF interfaces over ATM. That includes NBMA, Point-to-MultiPoint, and point-to-point, and it lets them auto-configure when Proxy-PAR is around 👑 One big perk is skipping server solutions, which often are single points of failure or hold tons of configuration info 😭

The other main benefit is being able to run OSPF on top of NBMA and Point-to-MultiPoint ATM networks while still getting automatic discovery of OSPF neighbors. On broadcast networks, broadcast-simulation-based networks (like LANE or Classical IP and ARP over ATM), and point-to-point networks, an OSPF router finds its neighbors on its own by sending Hello packets to the All-SPFRouters multicast address. That's not how it works on NBMA and Point-to-MultiPoint networks 🙈 On NBMA networks, the list of all the other routers attached to the same NBMA network has to be configured by hand or found some other way. Proxy-PAR lets that configuration be automated 🫶 On Point-to-MultiPoint networks, the set of directly reachable routers can be configured manually or discovered dynamically by Proxy-PAR or by mechanisms like Inverse ATMARP. Over an ATM network (see 8.2 in [5]), Inverse ATMARP can find the IP address of the router at the remote end of a given PVC, whether or not its ATM address is known. But Inverse ATMARP doesn't tell you things like whether the remote router is running OSPF, and Proxy-PAR does 🧚

This is parallel to [14], which describes the recommended operation of OSPF over Frame Relay networks. A similar model is assumed here, where the underlying ATM network can model single VCs as point-to-point interfaces, or collections of VCs as non-broadcast interfaces, in either NBMA or Point-to-MultiPoint mode 🌈 Each VC or collection of VCs is called a logical interface, and it's specified by its type (point-to-point, NBMA, or Point-to-MultiPoint), its VPN ID (the Virtual Private Network it belongs to), its address, and its mask. Layer 2 specific configurations, like the address resolution method, the class and quality of service of the circuits used, and others, must also be included 💅 As a logical consequence, a single physical interface could hold multiple IP subnets or even multiple VPNs 🦋

Here's the thing though: when you run Proxy-PAR, most of the OSPF information needed to operate such a logical interface doesn't have to be statically configured into the routers. It can be provided through Proxy-PAR queries instead. Layer 2 and IP addressing info don't work like that. So this allows way more dynamic configuration of VC meshes in OSPF environments than, say, Frame Relay solutions do 🔥

Proxy-PAR queries can also be issued with a subnet address set to 0.0.0.0, instead of a specific subnet address. This type of query returns information on all OSPF routers available in all subnets within the scope specified in the query. It's super handy when the IP addressing information hasn't been configured yet 🌸

2.2 Configuration of OSPF interfaces with Proxy-PAR

okay so the whole goal here is making VC mesh reconfiguration way less painful 💅 Proxy-PAR lets the router learn most of the config OSPF needs all by itself ✨ Non-broadcast and point-to-point interface info can be learned across an ATM cloud, and we'll get into how in the next bits 🦋 It's up to the implementation whether it mixes Proxy-PAR autoconfig with manual config of neighbor info. Manual config could also override or complement what it gets from a Proxy-PAR client 🎀 Plus, the OSPF extensions for on-demand circuits [13] can be used to gracefully tear down VCs that aren't carrying any OSPF traffic for long stretches of time 🌸 The various interactions are described in sections 2.2.1, 2.2.2 and 2.2.3.

Even after the interfaces are autoconfigured, VC setup in ATM is still a problem 💀 because none of the usual stuff, like Classical IP and ARP over ATM [5] or LANE [6], is assumed to be around. Section 2.5 covers the router behavior needed for connectivity 🫶

2.2.1 Autoconfiguration of Non-Broadcast Multiple-Access (NMBA) Interfaces

Proxy-PAR can autoconfigure the list of every router on the same IP network in the same VPN, just by querying the Proxy-PAR server 🧚 Each router can grab the list of all OSPF routers on its subnet, along with their router priorities and ATM addresses. That's the precondition for OSPF to work properly across these logical NBMA interfaces 👑 Heads up though: when the list is learned through Proxy-PAR queries, it can change dynamically with PNNI (in)stability and general ATM network behavior 😭 Relying on an OSPF mechanism to spot a lack of reachability in the overlaying logical IP network could ease the risk of thrashing DR elections and excessive information flooding 🔥 Once the DR election is done and the router wasn't elected DR or BDR, an implementation of [13] can ignore the fact that all routers on that NBMA subnet are available in its config, since it only needs to maintain VCs to the DR and BDR. This info can also serve other purposes, like forwarding data packets (see section 2.4) ✨

Traditionally, router config for an NBMA network provides the list of all neighboring routers so protocol operation works right 🌈 For stability, the user may choose to provide a list of neighbors through static means and also turn on the Proxy-PAR protocol to complete the list 💜 It's left up to specific router implementations to decide whether to use manual config in addition to Proxy-PAR info, use manual config to filter dynamic info, or whether a concurrent mode is prohibited. Honestly, it's pretty obvious that more flexibility can make things easier to run, but it also gives more chances to misconfigure things 🙈

2.2.2 Autoconfiguration of Point-to-MultiPoint Interfaces

Point-to-MultiPoint interfaces in ATM only make sense if no VCs can be set up dynamically, because an SVC-capable ATM network normally presents an NBMA cloud to OSPF 🦋 For example, this is the case if OSPF runs over a network made of a partial PVC or SPVC mesh, or predetermined SVC meshes. Such a network can be modeled using the Point-to-MultiPoint OSPF interface, and neighbor detection could come from Proxy-PAR or other means 💅 In the Proxy-PAR case, the router queries for all OSPF routers on the same network in the same VPN, but it only installs routers that are already reachable through existing PVCs into the interface config 🎀 The underlying assumption is that a router knows the remote ATM address of a PVC and can compare it with the appropriate Proxy-PAR registrations. If the remote ATM address of the PVC is unknown, it can be discovered by mechanisms such as Inverse ARP [15] 🌸

Proxy-PAR provides a true OSPF neighbor detection mechanism 👑, whereas something like Inverse ARP only returns addresses of directly reachable routers (which aren't necessarily running OSPF) in the Point-to-Multi-Point environment 🙃

2.2.3 Autoconfiguration of Numbered Point-to-Point Interfaces

OSPF point-to-point links don't necessarily have an IP address assigned, and even if they do, the mask is undefined 🤷 As a precondition to successfully registering a service with Proxy-PAR, you need an IP address and a mask. So if a router wants to use Proxy-PAR to advertise the local end of a point-to-point link to the router it intends to form an adjacency with, an IP address has to be provided, along with a netmask set, or else the default of 255.255.255.252 gets assumed (that gives a subnet with two routers on it by default) 💖 To let the remote end of the interface be discovered, the IP address of the remote side has to be provided, and a netmask set or the default of 255.255.255.252 assumed. Obviously, discovery can only work when both sides are configured with the same network mask and are within the same IP network 🧠 If more than two possible neighbors are discovered through queries and the interface type is set to point-to-point, that's a configuration error 🚨

Sending multicast Hello packets on point-to-point links lets OSPF neighbors be discovered automatically. On the other hand, using Proxy-PAR instead avoids sending Hello messages to routers that aren't necessarily running OSPF 🫶

2.2.4 Autoconfiguration of Unnumbered Point-to-Point Interfaces

For the reasons given in [14], using unnumbered point-to-point interfaces with Proxy-PAR isn't a very attractive alternative 😭 because the lack of an IP address gets in the way of efficient registration and retrieval of config info. Relying on the numbering method based on MIB entries clashes with the dynamic nature of creating those entries, and it's beyond the scope of this work 🙈

2.3 Registration of OSPF interfaces with Proxy-PAR

So other routers can discover an OSPF interface automatically, the IP address, mask, Area ID, interface type and router priority info given must be registered with the Proxy-PAR server at an appropriate scope ✨ Any change to one of these parameters has to force a reregistration with Proxy-PAR 🔄

It's worth emphasizing here that, because the registration info can be used by other routers to resolve IP addresses against NSAPs (as explained in section 2.4), the entire IP address of the router must be registered 🎀 It's not sufficient to indicate the subnet up to the mask length; all address bits must be provided 💅

2.3.1 Registration of Non-Broadcast Multiple-Access Interfaces

For an NBMA interface, the appropriate parameters are available and can be registered through Proxy-PAR without further complications 🌈

2.3.2 Registration of Point-to-Multipoint Interfaces

For a Point-to-MultiPoint interface, the router registers its info the same way as in the NBMA case, except the interface type gets modified accordingly 🦋

2.3.3 Registration of Numbered Point-to-Point Interfaces

For numbered point-to-point interfaces, the address mask isn't specified in the OSPF config. If the router has to use Proxy-PAR to advertise its capability, a mask must be defined, or the default value of 255.255.255.252 used 🧚

2.3.4 Registration of Unnumbered Point-to-Point Interfaces

Because there's no configured IP address, and the difficulties that come with that (as described earlier), registration of unnumbered point-to-point interfaces isn't covered in this document 🙈

2.4 IP address to NSAP Resolution Using Proxy-PAR

As a byproduct of Proxy-PAR being around, an OSPF implementation could use the info in registrations to resolve IP addresses to ATM NSAPs on a subnet, without needing static data or mechanisms like ATMARP [5] 🔥 This should allow a drastic simplification of the number of mechanisms involved in operating OSPF over ATM to provide an IP overlay 👑

From a system perspective, the OSPF component, the Proxy-PAR client, the IP to NSAP address resolution table, and the ATM circuit manager can be depicted as in Figure 1. Figure 1 shows an example of component interactions triggered by a Proxy-PAR query from the Proxy-PAR client 💜

2.5 Connection Setup Mechanisms

This section describes the OSPF behavior in an ATM network under various assumptions in terms of signaling capabilities and preset connectivity 🧚

2.5.1 OSPF in PVC Environments

In environments where only partial PVC (or SPVC) meshes are available and modeled as Point-to-MultiPoint interfaces, the routers see reachable routers through autodiscovery provided by Proxy-PAR. This leads to expected OSPF behavior 🌸 In cases where a full mesh of PVCs is present, such a network should preferably be modeled as NBMA. Note that in such a case, PVC failures will translate into not-so-obvious routing failures 😱

        __________                      _________
       |          |                    |         |
       |   OSPF   |<-------------------|Proxy-PAR|<---(Proxy-PAR query)
       |__________|  notify            | client  |
            ^        neighbor changes  |_________|
            |                               |
   send and |                               | maintain Proxy-PAR
   receive  |                               | entries in table
   OSPF msg |                               |
            |                               |
            |                               |
        ____V____                       ____V_____
       |   ATM   |                     |          |
       | circuit |-------------------->|IP to NSAP|
       | manager | check               |  table   |
       |_________| IP to NSAP bindings |__________|

Figure 1: System perspective of typical components interactions. 📊

2.5.2 OSPF in SVC Environments 🦋

In SVC-capable environments, routers can start VCs after they've discovered their neighbors, usually because they need to send something like Hello packets. This can cause race conditions where both sides open a VC at the same time 😭. It's generally desirable to avoid wasting this valuable resource. If the router with the lower IP address (i.e., the IP address of the OSPF interface registered with Proxy-PAR) detects that the VC initiated by the other side is bidirectional, it's free to close its own VC and use the one it detected. Note that this either requires the OSPF implementation to be aware of the VCs used to send and receive Hello messages, or the component responsible for managing VCs to be aware of how particular VCs are being used 🧚.

Observe that this behavior works correctly when OSPF over Demand Circuits extensions [13] are used over SVC-capable interfaces ✨.

Most of the time, you can avoid setting up redundant VCs by delaying the first OSPF Hello from the router with the lower IP address by an amount of time greater than the interval between queries from the Proxy-PAR client to the server. Chances are the router with the higher IP address opens the VC (or uses an already existing VC) and sends the OSPF Hello first, as long as its interval between queries is shorter than the Hello delay of the router with the lower IP address. Since this interval can vary depending on particular needs and implementations, the race conditions described above can still be expected to happen, albeit presumably less often 🙈.

The VCs used for OSPF exchanges are independent of the number and type of VCs the router chooses to use within the logical interface to forward data to other routers 💅. OSPF implementations are free to use any of these VCs (if they're aware of them) to send packets, as long as their end points are adequate. They must accept Hello packets arriving on any of the VCs belonging to the logical interface, even if OSPF running on that interface isn't aware those VCs exist 🫶. An OSPF implementation may ignore connections initiated by another router that Proxy-PAR hasn't discovered. In any case, the OSPF implementation will ignore a neighbor whose Proxy-PAR registration indicates it is not adjacent 🚫.

As an example, consider the topology in Figure 2, where routers RTB and RTC are connected to a common ATM cloud offering Proxy-PAR services. Assume RTB's OSPF implementation is aware of SVCs initiated on the interface, and RTC only makes minimal use of Proxy-PAR information. The following sequence could develop, illustrating some of the cases described above 👑:

          +           +                             +
          |   +---+   |                             |
   +--+   |---|RTA|---|          +-------+          |   +--+
   |H1|---|   +---+   |          | ATM   |          |---|H2|
   +--+   |           |   +---+  | Cloud |  +---+   |   +--+
          |LAN Y      |---|RTB|-------------|RTC|---|
          +           |   +---+  | PPAR  |  +---+   |
                      +          +-------+          +

     Figure 2: Simple topology with Router B and Router C operating
               across NBMA ATM interfaces with Proxy-PAR.
  1. RTC and RTB register with the ATM cloud as Proxy-PAR capable and discover each other as adjacent OSPF routers 🌸.
  2. RTB sends a Hello, which forces it to establish an SVC connection to RTC 📞.
  3. RTC sends a Hello to RTB, but disregards the already existing VC and establishes a new VC to RTB to deliver the packet 😤.
  4. RTB sees a new bidirectional VC and, assuming here that RTC's IP address is higher, closes the VC it originated in step 2 🧹.
  5. Host H1 sends data to H2, and RTB establishes a new data SVC between itself and RTC 🚀.
  6. RTB sends a Hello to RTC and decides to use the newly established data SVC to do it. RTC must accept the Hello despite its minimal implementation 💖.

3 Acknowledgments ✨

Comments and contributions from several sources, especially Rob Coltun, Doug Dykeman, John Moy and Alex Zinin, are included in this work. Thank you, legends 🫶.

4 Security Considerations 🔐

Okay, this section is serious, bestie, so read it carefully 💀.

Several aspects need to be considered when it comes to the security of running 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. The registration itself through Proxy-PAR is not secured, and appropriate mechanisms for it are a topic for further study. However, even if security at the ATM layer is not guaranteed, OSPF security mechanisms can be used to verify that detected neighbors are authorized to interact with the entity discovering them 🛡️.

5 Bibliography 📚

  • [1] ATM Forum, "PNNI Augmented Routing (PAR) Version 1.0." ATM Forum af-ra-0104.000, January 1999.
  • [2] Droz, P. and T. Przygienda, "Proxy-PAR", RFC 2843, May 2000.
  • [3] ATM-Forum, "Private Network-Network Interface Specification Version 1.0." ATM Forum af-pnni-0055.000, March 1996.
  • [4] ATM-Forum, "Interim Local Management Interface, (ILMI) Specification 4.0." ATM Forum af-ilmi-0065.000, September 1996.
  • [5] Laubach, J., "Classical IP and ARP over ATM", RFC 2225, April 1998.
  • [6] ATM-Forum, "LAN Emulation over ATM 1.0." ATM Forum af-lane-0021.000, January 1995.
  • [7] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1996.
  • [8] Coltun, R., "The OSPF Opaque LSA Option", RFC 2328, July 1998.
  • [9] Davison, M., "ILMI-Based Server Discovery for ATMARP", RFC 2601, June 1999.
  • [10] Davison, M., "ILMI-Based Server Discovery for MARS", RFC 2602, June 1999.
  • [11] Davison, M., "ILMI-Based Server Discovery for NHRP", RFC 2603, June 1999.
  • [12] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
  • [13] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
  • [14] deSouza, O. and M. Rodrigues, "Guidelines for Running OSPF Over Frame Relay Networks", RFC 1586, March 1994.
  • [15] Bradley, A. and C. Brown, "Inverse Address Resolution Protocol", RFC 2390, September 1999.

Authors' Addresses 🧚

Tony Przygienda
Siara Systems Incorporated
1195 Borregas Avenue
Sunnyvale, CA 94089
USA

EMail: prz@siara.com


Patrick Droz
IBM Research
Zurich Research Laboratory
Saumerstrasse 4
8803 Ruschlikon
Switzerland

EMail: dro@zurich.ibm.com


Robert Haas
IBM Research
Zurich Research Laboratory
Saumerstrasse 4
8803 Ruschlikon
Switzerland

EMail: rha@zurich.ibm.com

Here's the legal bit, kept exactly as written so it stays complete 💜.

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

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. Iconic behavior from them, honestly 👑.

📦 where this page comes from