Guidelines for Running OSPF Over Frame Relay Networks
RFC 1586

Document Type RFC - Informational (March 1994; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1586 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         O. deSouza
Request for Comments: 1586                                  M. Rodrigues
Category: Informational                           AT&T Bell Laboratories
                                                              March 1994

                      Guidelines for Running OSPF
                       Over Frame Relay Networks

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.


   This memo specifies guidelines for implementors and users of the Open
   Shortest Path First (OSPF) routing protocol to bring about
   improvements in how the protocol runs over frame relay networks.  We
   show how to configure frame relay interfaces in a way that obviates
   the "full-mesh" connectivity required by current OSPF
   implementations. This allows for simpler, more economic network
   designs.  These guidelines do not require any protocol changes; they
   only provide recommendations for how OSPF should be implemented and
   configured to use frame relay networks efficiently.


   This memo is the result of work done in the OSPF Working Group of the
   IETF.  Comments and contributions from several sources, especially
   Fred Baker of ACC, John Moy of Proteon, and Bala Rajagopalan of AT&T
   Bell Laboratories are included in this work.

1.  Introduction

   A frame relay (FR) network provides virtual circuits (VCs) to
   interconnect attached devices. Each VC is uniquely identified at each
   FR interface by a Data Link Connection Identifier (DLCI).  RFC 1294
   specifies the encapsulation of multiprotocol traffic over FR [1].
   The devices on a FR network may either be fully interconnected with a
   "mesh" of VCs, or partially interconnected.  OSPF characterizes FR
   networks as non-broadcast multiple access (NBMA) because they can
   support more than two attached routers, but do not have a broadcast
   capability [2].  Under the NBMA model, the physical FR interface on a
   router corresponds to a single OSPF interface through which the
   router is connected to one or more neighbors on the FR network; all
   the neighboring routers must also be directly connected to each other

deSouza & Rodrigues                                             [Page 1]
RFC 1586                 OSPF over Frame Relay                March 1994

   over the FR network.  Hence OSPF implementations that use the NBMA
   model for FR do not work when the routers are partially
   interconnected.  Further, the topological representation 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.

   We see that the NBMA model becomes more restrictive as the number of
   routers connected to the network increases. First, the number of VCs
   required for full-mesh connectivity increases quadratically with the
   number of routers. Public FR services typically offer performance
   guarantees for each VC provisioned by the service. This means that
   real physical resources in the FR network are devoted to each VC, and
   for this the customer eventually pays. The expense for full-mesh
   connectivity thus grows quadratically with the number of
   interconnected routers.  We need to build OSPF implementations that
   allow for partial connectivity over FR.  Second, using a single link
   metric (per TOS) for the FR interface does not allow OSPF to weigh
   some VCs more heavily than others according to the performance
   characteristics of each connection. To make efficient use of the FR
   network resources, it should be possible to assign different link
   metrics to different VCs.

   These limitations of the current OSPF model for FR become more severe
   as the network size increases, and render FR technology less cost
   effective than it could be for large networks. We propose solutions
   to these problems that do not increase complexity by much and do not
   require any changes to the OSPF protocol.

2.  Summary of Recommendations

   We propose expanding the general view of an OSPF interface to account
   for its functional type (point-to-point, broadcast, NBMA) rather than
   its physical type. In most instances, the physical network can only
   serve one function and can only be defined as one type of OSPF
   interface. For multiplexed interfaces such as FR however, logical
   connections between routers can serve different functions. Hence one
   VC on a FR interface can be viewed distintly from other VCs on the
   same physical interface.  The solution requires that OSPF be able to
Show full document text