Guidelines for Running OSPF Over Frame Relay Networks
How to configure OSPF over frame relay so that a full mesh of virtual circuits is not needed.
deSouza, O. and M. Rodrigues, "Guidelines for Running OSPF Over Frame Relay Networks", RFC 1586, DOI 10.17487/RFC1586, March 1994, <https://www.rfc-editor.org/info/rfc1586>.
@misc{rfc1586,
series = {Request for Comments},
number = 1586,
howpublished = {RFC 1586},
publisher = {RFC Editor},
doi = {10.17487/RFC1586},
url = {https://www.rfc-editor.org/info/rfc1586},
author = {O. deSouza and M. Rodrigues},
title = {{Guidelines for Running OSPF Over Frame Relay Networks}},
pagetotal = 6,
year = 1994,
month = mar,
} RFC text
Contents
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
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
support logical interfaces (networks) as well as physical interfaces.
Each logical network can be either point-to-point, that is, a single
VC, or NBMA, that is, a collection of VCs. It is not necessary to
define new interface types for logical networks, since the operation
of the protocol over logical point-to-point networks and logical NBMA
networks remains the same as for the corresponding physical networks.
For instance, logical point-to-point links could be numbered or
unnumbered. It is only necessary for implementations to provide the
hooks that give users the ability to 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 provide some economy in OSPF protocol processing
and overhead and is the recommended mode of operation for small
homogeneous networks. Other than the Designated Router (DR) and the
backup Designated Router (BDR), each router maintains only two
adjacencies, one each with the DR and BDR, regardless of the size of
the NBMA network. When FR VCs are configured as point-to-point
links, a router would have many more adjacencies to maintain,
resulting in increased protocol overhead. If all VCs were to have
comparable performance characteristics as well, there may not be
compelling reasons to assign a different link metric to each VC.
3. Implementing OSPF over FR
We recommend that OSPF router implementations be built so that
administrators can configure network layer interfaces that consist of
one or more FR VCs within a single physical interface. Each logical
network interface could then be configured as the appropriate type of
OSPF interface, that is, point-to-point for a single VC, or NBMA for
a collection of VCs. This capability would allow a router to belong
to one or more distinct IP subnets on a single physical FR interface.
Thus, it is necessary that the router be able to support multiple IP
addresses on a single physical FR interface. As with physical NBMA
networks, logical NBMA networks must be full-mesh connected. While
logical point-to-point links can be either numbered or unnumbered, we
show that it is easier to implement routers to 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 as follows:
STEP 1: Configure the physical interface specifying relevant
parameters such as the 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, assign the physical interface an
ifIndex, and increment the ifNumber by one.
STEP 2: Configure the data-link layer over the interface,
specifying frame relay as the encapsulation method.
Parameters such as the DLCI encoding type and length,
maximum frame size, management interface (Annex D, LMI),
and address resolution procedure (manual, 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 have 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
such as area ID, link metric, protocol timers and
intervals, DR priority, and list of neighbors (for the DR).
OSPF interfaces consisting 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.
However, since an unnumbered point-to-point link does not have an IP
address, the ifIndex from the interface MIB is used instead [5].
This is straightforward for a physical point-to-point network, since
the ifIndex is assigned when the interface is configured. Logical
interfaces over FR however, do not have distinct and unique values
for ifIndex. To allow OSPF to instance unnumbered logical point-to-
point links, it is necessary to assign each such link a unique
ifIndex in STEP 3 above. This could lead to some confusion in the
interfaces table since a new ifTable entry would have to be created
for each logical point-to-point link. This type of departure from the
standard practice of creating interface table entries only for
physical interfaces could be viewed as an unnecessary complication.
Alternatively, it is possible to build a private MIB that contains
data structures to instance unnumbered logical links. However, making
recommendations for the structure and use of such a private MIB is
beyond the scope of this work. Even if unnumbered point-to-point
logical links were implemented in this manner, it would still be
necessary to allow a FR interface to be configured with multiple IP
addresses when a router is connected to multiple NBMA subnets through
a single physical interface. Hence, while it is possible to define
unnumbered logical point-to-point links in OSPF, we find this
alternative less attractive than using numbered logical point-to-
point links.
4. Using OSPF over FR
The ability to configure distinct logical interfaces over FR gives
users a great deal of flexibility in designing FR networks for use
with OSPF. Because routers can be partially interconnected over FR,
it is possible to design networks more cost-effectively than before.
The issues to consider are the price/cost structure for VCs (fixed,
distance-sensitive, banded) and ports, performance guarantees
provided, traffic distribution (local, long-haul), and protocol
efficiency. We have mentioned that the NBMA model provides some
economy in OSPF protocol processing and overhead and is recommended
for small homogeneous networks. In general, users should configure
their networks to contain several small "NBMA clusters," which are in
turn 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 depends on the factors mentioned above. If it is
necessary to architect a more "flat" network, the ability to assign
different link metrics to different (groups of) VCs allows for
greater efficiency in using FR resources since VCs with better
performance characteristics (throughput, delay) could be assigned
lower link metrics.
5. Conclusion
We have specified guidelines for OSPF implementors and users to bring
about improvements in how the protocol runs over frame relay
networks. These recommendations do not require any protocol changes
and 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
Security issues are not discussed in this memo.
7. Authors' Addresses
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
ISO Plain Language
On this page
§1Why Frame Relay Was Hard for OSPF
A frame relay network provides virtual circuits, VCs, to interconnect attached devices. Each VC is uniquely identified at each frame relay interface by a Data Link Connection Identifier, a DLCI, and RFC 1294 specifies the encapsulation of multiprotocol traffic over frame relay. The devices on a frame relay network may either be fully interconnected with a mesh of VCs, or partially interconnected.
OSPF characterises frame relay networks as non-broadcast multiple access, NBMA, because they can support more than two attached routers but do not have a broadcast capability. Under that model, the physical frame relay interface on a router corresponds to a single OSPF interface through which the router is connected to one or more neighbours on the frame relay network, and all the neighbouring routers must also be directly connected to each other over the frame relay network. It follows that OSPF implementations using the NBMA model for frame relay do not work when the routers are partially interconnected.
The memo then identifies two separate problems with that. First, the number of VCs required for full-mesh connectivity increases quadratically with the number of routers. Public frame relay services typically offer performance guarantees for each VC provisioned by the service, which means real physical resources in the frame relay network are devoted to each VC, and for this the customer eventually pays. The expense of full-mesh connectivity therefore grows quadratically with the number of interconnected routers, and the memo says plainly that OSPF implementations are needed that allow partial connectivity over frame relay.
Second, using a single link metric, per type of service, for the frame relay 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 frame relay network resources, it should be possible to assign different link metrics to different VCs.
These limitations become more severe as the network size increases, and they render frame relay technology less cost effective than it could be for large networks. The solutions the memo proposes do not increase complexity by much and do not require any changes to the OSPF protocol.
Frame relay gives you a set of private lines between routers, billed one by one. OSPF assumed that on such a network every router could see every other router, so it wanted a private line to each of them. That is fine for three routers and expensive for thirty.
| Aspect | What frame relay is | What the NBMA model needs |
|---|---|---|
| Connectivity | Virtual circuits, each identified by a DLCI at each interface | Every attached router directly connected to every other one |
| Broadcast | None, though it can carry more than two attached routers | A broadcast capability, or a way to avoid needing one |
| Cost | Each provisioned VC gets performance guarantees and is charged for | Connectivity whose cost grows with the square of the number of routers |
| Metrics | Each VC can have its own performance characteristics | One link metric for the whole interface |
§2The Recommendations in Brief
The first recommendation is to expand the general view of an OSPF interface to account for its functional type, point-to-point, broadcast or 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 frame relay, however, logical connections between routers can serve different functions, so one VC on a frame relay interface can be viewed distinctly from other VCs on the same physical interface.
The solution therefore requires that OSPF be able to support logical interfaces, that is, logical networks, as well as physical interfaces. Each logical network can be either point-to-point, a single VC, or NBMA, a collection of VCs. It is not necessary to define new interface types for logical networks, since the operation of the protocol over logical point-to-point networks and logical NBMA networks remains the same as for the corresponding physical networks. Logical point-to-point links, for instance, could be numbered or unnumbered. It is only necessary for implementations to provide the hooks that give users the ability to configure an individual VC as a logical point-to-point network, or a collection of VCs as a logical NBMA network.
The memo is careful to record the other side of the trade-off. The NBMA model does provide some economy in OSPF protocol processing and overhead, and it is the recommended mode of operation for small homogeneous networks. Other than the designated router and the backup designated router, each router maintains only two adjacencies, one each with the DR and the BDR, regardless of the size of the NBMA network. When frame relay VCs are configured as point-to-point links, a router would have many more adjacencies to maintain, resulting in increased protocol overhead. If all the VCs had comparable performance characteristics as well, there might not be compelling reasons to assign a different link metric to each VC.
The change is to think of the interface type as a property of each virtual circuit rather than of the physical card. One circuit can be a plain point-to-point link to one neighbour, and several circuits can be grouped into a shared network. The price is more adjacencies to maintain.
§3.1Configuring Numbered Logical Interfaces
The memo describes how an administrator would configure numbered logical interfaces over frame relay, in four steps.
In the first step the physical interface is configured, specifying the relevant parameters such as the slot, connector and port numbers, the physical frame format, the encoding and the clock mode. In its internal interface MIB the router should create a new ifEntry in the ifTable, assign the physical interface an ifIndex, and increment the ifNumber by one.
In the second step the data link layer over the interface is configured, specifying frame relay as the encapsulation method, and parameters such as the DLCI encoding type and length, the maximum frame size, the management interface, Annex D LMI, and the address resolution procedure, manual or inverse ARP. If a management interface is not supported, frame relay VCs must be configured manually.
In the third step the IP network layer is configured for the interface, by specifying the number of logical interfaces and the IP address and subnet mask for each numbered logical interface, and the VCs, by DLCI, associated with each logical network interface where there is more than one. If an address resolution protocol such as inverse ARP is being used, it should suffice to specify a list of IP addresses for the frame relay interface and have inverse ARP create the DLCI and IP address binding.
In the fourth step OSPF is configured to run over each logical interface as appropriate, specifying the necessary interface parameters such as the area ID, the link metric, the protocol timers and intervals, the designated router priority, and the list of neighbours for the designated router. OSPF interfaces consisting 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 the router should create additional entries in the ospfIfTable, each with the appropriate ospfIfType, nbma or pointTopoint.
The configuration follows the stack from the bottom up. Set up the physical port, then frame relay on it, then the IP addresses of the logical links inside it, and finally tell OSPF which of those links to run on and what they should cost.
| Step | What to configure |
|---|---|
| 1. Physical interface | Slot, connector and port numbers, physical frame format, encoding and clock mode; a new ifEntry in the ifTable, an ifIndex, and ifNumber incremented by one. |
| 2. Data link layer | Frame relay encapsulation, the DLCI encoding type and length, maximum frame size, the Annex D management interface, and the address resolution procedure, manual or inverse ARP. |
| 3. IP network layer | The number of logical interfaces, and the IP address and subnet mask for each, with the DLCIs of each group where there is more than one. |
| 4. OSPF | Area ID, link metric, protocol timers and intervals, designated router priority and the neighbour list, with new ospfIfTable entries typed nbma or pointTopoint. |
§3.2Numbered or Unnumbered Logical Interfaces
OSPF uses the IP address to instance each numbered interface. Since an unnumbered point-to-point link has no IP address, the ifIndex from the interface MIB is used instead. That is straightforward for a physical point-to-point network, because the ifIndex is assigned when the interface is configured. Logical interfaces over frame relay, however, do not have distinct and unique values for ifIndex.
To allow OSPF to instance unnumbered logical point-to-point links, it would be necessary to assign each such link a unique ifIndex in the third configuration step. The memo notes that this could lead to some confusion in the interfaces table, since a new ifTable entry would have to be created for each logical point-to-point link, and that this departure from the standard practice of creating interface table entries only for physical interfaces could be viewed as an unnecessary complication.
Alternatively, it is possible to build a private MIB that contains data structures to instance unnumbered logical links, but making recommendations for the structure and use of such a private MIB is beyond the scope of this work. Even if unnumbered logical point-to-point links were implemented in this manner, it would still be necessary to allow a frame relay interface to be configured with multiple IP addresses when a router is connected to multiple NBMA subnets through a single physical interface. So, while it is possible to define unnumbered logical point-to-point links in OSPF, the memo finds this alternative less attractive than using numbered logical point-to-point links.
A logical link could be left without an IP address, but then it needs a separate entry in the router's interface table, and the memo judges that messier than simply giving each one an address.
§4Designing the Network
The ability to configure distinct logical interfaces over frame relay gives users a great deal of flexibility in designing frame relay networks for use with OSPF. Because routers can be partially interconnected over frame relay, it is possible to design networks more cost-effectively than before.
The memo lists the issues to consider: the price and cost structure for VCs, which may be fixed, distance-sensitive or banded, and for ports; the performance guarantees provided; traffic distribution, local or long-haul; and protocol efficiency. It repeats that the NBMA model provides some economy in OSPF protocol processing and overhead and is recommended for small homogeneous networks.
In general, users should configure their networks to contain several small NBMA clusters, which are in turn 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 just listed. If it is necessary to architect a more flat network, the ability to assign different link metrics to different groups of VCs allows for greater efficiency in using frame relay resources, since VCs with better performance characteristics, in throughput and delay, could be assigned lower link metrics.
The advice for a network designer is to build clusters: a handful of routers wired together in a mesh, and the clusters joined by long-haul links. That keeps the mesh small while the distance between sites is carried by a circuit that is cheap to provision.
§5Conclusion and Security
The memo concludes that it has specified guidelines for OSPF implementors and users to bring about improvements in how the protocol runs over frame relay networks, that these recommendations do not require any protocol changes, and that they allow for simpler, more efficient and cost-effective network designs. The recommendation is 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 for one VC, or as logical NBMA networks for more than one VC, and that the current NBMA model for frame relay should continue to be used for small homogeneous networks consisting of a few routers.
The Security Considerations section is one sentence: security issues are not discussed in this memo. The acknowledgements record that the memo is the result of work done in the OSPF Working Group of the IETF, and that comments and contributions from several sources are included, naming Fred Baker of ACC, John Moy of Proteon and Bala Rajagopalan of AT&T Bell Laboratories.
Nothing in the protocol has to change; the routers just have to be able to see inside the interface and be told which circuits to use. The memo says nothing about security.