RFC 1586

RFC 1586 🎀 (Part 1 of 2)

Guidelines for Running OSPF Over Frame Relay Networks ✨

bestie, the title block is giving Informational 📚 which means it's guidance, not a standard. It was written by O. deSouza and M. Rodrigues from AT&T Bell Laboratories 💼 and it's dated March 1994 🍓. The header doesn't list any obsoletes or updates, so this doc isn't replacing or patching anything 🫶

Status of This Memo

this memo gives info to the Internet community 🌈 it does not specify an Internet standard of any kind, and distribution of it is unlimited ✨

Abstract

this memo is the guide for implementors and users of the Open Shortest Path First (OSPF) routing protocol 🦋 the goal is making OSPF run better over frame relay networks 💅 we show how to configure frame relay interfaces so you don't need the "full-mesh" connectivity that current OSPF implementations require 😭 that means simpler, more economic network designs 💖 and the big plus is none of this needs any protocol changes 🔥 these are just recommendations for how OSPF should be implemented and configured to use frame relay networks efficiently 🧚

Acknowledgements

this work came out of the OSPF Working Group of the IETF 🫶 extra love to Fred Baker of ACC, John Moy of Proteon, and Bala Rajagopalan of AT&T Bell Laboratories, whose comments and contributions are included here 💜

1. Introduction

okay so a frame relay (FR) network gives you virtual circuits (VCs) to connect attached devices 🌸 every VC is uniquely identified at each FR interface by a Data Link Connection Identifier (DLCI) 🎀 RFC 1294 specifies how multiprotocol traffic gets encapsulated over FR [1] ✨ the devices on an FR network may either be fully interconnected with a "mesh" of VCs, or only partially interconnected 🕸️

here's the tea: OSPF calls FR networks non-broadcast multiple access (NBMA) 🙈 because they can support more than two attached routers but don't have a broadcast capability [2] 😭 in the NBMA model, the physical FR interface on a router corresponds to a single OSPF interface, and through it the router connects to one or more neighbors on the FR network 🌈 all of those neighboring routers must also be directly connected to each other over the FR network 💀 so OSPF implementations that use the NBMA model for FR don't work when the routers are only partially interconnected 🥲 and the topology view of a multiple access network has each attached router bi-directionally connected to the network vertex, with a single link metric assigned to the edge directed into the vertex 🧠

it only gets worse as the network grows 📈 first, the number of VCs needed for full-mesh connectivity increases quadratically with the number of routers 😭 public FR services usually offer performance guarantees for every VC they provision 💸 that means real physical resources in the FR network get devoted to each VC, and the customer eventually pays for all of it 💅 so the cost of full-mesh connectivity grows quadratically with the number of interconnected routers, and we need OSPF implementations that allow partial connectivity over FR 🫶 second, using a single link metric (per TOS) for the FR interface doesn't let OSPF weigh some VCs more heavily than others based on each connection's performance characteristics 🙅‍♀️ to use FR network resources efficiently, it should be possible to assign different link metrics to different VCs 🔥

these limits of the current OSPF model for FR get more severe as network size goes up, and they make FR less cost effective than it could be for large networks 🍓 we propose fixes that don't add much complexity and don't require any changes to the OSPF protocol 👑

2. Summary of Recommendations

we're proposing that the general view of an OSPF interface account for its functional type (point-to-point, broadcast, NBMA) instead of its physical type ✨ most of the time a physical network can only serve one function and can only be defined as one type of OSPF interface 🦋 but multiplexed interfaces like FR are different, because logical connections between routers can serve different functions 🌈 so one VC on an FR interface can be viewed distinctly from other VCs on that same physical interface 💖

the solution requires that OSPF be able to support logical interfaces (networks) as well as physical interfaces 🧚 each logical network can be either point-to-point (a single VC) or NBMA (a collection of VCs) 🎀 we don't need new interface types for logical networks, since OSPF over logical point-to-point networks and logical NBMA networks works the same as it does over the corresponding physical networks 💅 for instance, logical point-to-point links could be numbered or unnumbered 🫶 implementations just need the hooks that let users configure an individual VC as a logical point-to-point network, or a collection of VCs as a logical NBMA network ⭐

the NBMA model does save some OSPF protocol processing and overhead, so it's the recommended mode of operation for small homogeneous networks 🍓 apart from the Designated Router (DR) and the backup Designated Router (BDR), each router only maintains two adjacencies, one each with the DR and BDR, no matter how big the NBMA network is 🙌 when FR VCs are configured as point-to-point links, a router would have way more adjacencies to maintain, which means more protocol overhead 😩 and if all the VCs had comparable performance characteristics, there may not be compelling reasons to give each VC a different link metric 🌸

3. Implementing OSPF over FR

we recommend that OSPF router implementations be built so administrators can configure network layer interfaces made of one or more FR VCs inside a single physical interface 🎀 each logical network interface can then be set up as the right type of OSPF interface: point-to-point for a single VC, or NBMA for a collection of VCs 💖 this lets one router belong to one or more distinct IP subnets on a single physical FR interface 🦋 so the router needs to support multiple IP addresses on that one physical FR interface 🧠 just like physical NBMA networks, logical NBMA networks must be full-mesh connected 🕸️ and while logical point-to-point links can be numbered or unnumbered, it's way easier to build routers that handle numbered logical point-to-point links 🙌

3.1. Numbered Logical Interfaces

the router administrator should be able to configure numbered logical interfaces over FR like this 👑

• STEP 1: configure the physical interface with relevant parameters like slot, connector, and port numbers, physical frame format, encoding, and clock mode 🔧 in its internal interface MIB [3], the router should create a new ifEntry in the ifTable, give the physical interface an ifIndex, and increment the ifNumber by one 📝
• STEP 2: configure the data-link layer over the interface, with frame relay as the encapsulation method 🌈 parameters include the DLCI encoding type and length, maximum frame size, management interface (Annex D, LMI), and address resolution procedure (manual or inverse ARP) 💅 if a management interface is not supported, FR VCs must be configured manually 😬
• STEP 3: configure the IP network layer for the interface by specifying the number of logical interfaces and the IP address and subnet mask for each numbered logical interface 🧚 specify the VCs (by DLCI) associated with each logical network interface if there is more than one 🎀 if an address resolution protocol such as Inverse ARP [4] is being used, it should suffice to specify a list of IP addresses for the FR interface and let Inverse ARP create the DLCI-IP address binding ✨
• STEP 4: configure OSPF to run over each logical interface as appropriate, specifying the necessary interface parameters like area ID, link metric, protocol timers and intervals, DR priority, and the list of neighbors (for the DR) 🫶 OSPF interfaces made of one VC can be treated as point-to-point links, while multi-VC OSPF interfaces are treated as NBMA subnets 🦋 in its internal OSPF MIB [5], the router should create additional entries in the ospfIfTable, each with the appropriate ospfIfType (nbma or pointTopoint) 💖

3.2. Unnumbered Point-to-Point Logical Interfaces

OSPF uses the IP address to instance each numbered interface 🧠 but an unnumbered point-to-point link doesn't have an IP address, so OSPF uses the ifIndex from the interface MIB instead [5] 🌸 for a physical point-to-point network this is simple, since the ifIndex gets assigned when the interface is configured 🙌 logical interfaces over FR, however, don't have distinct and unique ifIndex values 😭 so to let OSPF instance unnumbered logical point-to-point links, each one needs a unique ifIndex assigned in STEP 3 above 🔧 that can get confusing in the interfaces table, since a new ifTable entry would have to be created for every logical point-to-point link 🥲 this departure from the standard practice of creating interface table entries only for physical interfaces could honestly be seen as an unnecessary complication 🙄

another option is building a private MIB with data structures to instance unnumbered logical links 💡 but recommending the structure and use of that private MIB is beyond the scope of this work 🙅‍♀️ even if unnumbered point-to-point logical links were done that way, a FR interface would still need to be configurable with multiple IP addresses whenever a router connects to multiple NBMA subnets through a single physical interface 💀 so yes, you can define unnumbered logical point-to-point links in OSPF, but we find that alternative less attractive than numbered logical point-to-point links 👑

(part 2 picks up right here 🫶)

4. Using OSPF over FR ✨

okay bestie, being able to set up distinct logical interfaces over FR is giving major flexibility 💅 You can design FR networks for OSPF in a way that actually fits what you need. Routers can be partially interconnected over FR, so you can build networks more cost-effectively than before 💰 The stuff to think about is the price/cost structure for VCs (fixed, distance-sensitive, banded) and ports, the performance guarantees you get, traffic distribution (local, long-haul), and protocol efficiency 🧠

We already mentioned that the NBMA model gives some economy in OSPF protocol processing and overhead, and that it is recommended for small homogeneous networks 🫶 In general, users should configure their networks to contain several small "NBMA clusters," which are then interconnected by long-haul VCs 🧚 The best choices for the number of routers in each cluster and the size of the long-haul logical point-to-point links depend on the factors mentioned above 🤔

if you need a more "flat" network, you can assign different link metrics to different (groups of) VCs. that's so efficient for FR resources bc VCs with better performance characteristics (throughput, delay) could be assigned lower link metrics 🔥

---

5. Conclusion 👑

okay so we've wrapped up the guidelines for OSPF implementors and users to level up how the protocol runs over frame relay networks 🦋 These recommendations don't require any protocol changes, and they allow for simpler, more efficient, and cost-effective network designs ✨ We recommend that OSPF implementations 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) 💖 The current NBMA model for frame relay should continue to be used for small homogeneous networks consisting of a few routers 🌸

---

6. References 📚

• [1] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 1294, Wellfleet Communications, Inc., BBN Communications, January 1992.
• [2] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994.
• [3] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based Internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Inc., Performance Systems International, March 1991.
• [4] Bradley, T., and C. Brown, "Inverse Address Resolution Protocol", RFC 1293, Wellfleet Communications, Inc., January 1992.
• [5] Baker, F., and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1253, ACC, Computer Science Center, August 1991.

---

Security Considerations 🔒

tea time 🫖 the memo itself says that security issues are not discussed in this memo 💀 so yeah, that's the whole security section, no cap

---

7. Authors' Addresses 🖊️

these are the cuties who wrote it 🫶

Osmund S. deSouza
AT&T Bell Laboratories
Room 1K-606
101 Crawfords Corner Road
Holmdel, NJ 07733

Phone: (908) 949-1393
EMail: osmund.desouza@att.com

Manoel A. Rodrigues
Room 1K-608
AT&T Bell Laboratories
101 Crawfords Corner Road
Holmdel, NJ 07733

Phone: (908) 949-4655
EMail: manoel.rodrigues@att.com

the end!! 🌈💜 thank u for reading the whole thing, you're literally the best 🎀