Browse Prior Art Database

Guidelines for Running OSPF Over Frame Relay Networks (RFC1586)

IP.com Disclosure Number: IPCOM000002420D
Original Publication Date: 1994-Mar-01
Included in the Prior Art Database: 2019-Feb-13
Document File: 6 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

O. deSouza: AUTHOR [+1]

Related Documents

10.17487/RFC1586: DOI

Abstract

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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 23% of the total text.

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.

Abstract

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.

Acknowledgements

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 inter...

Processing...
Loading...