The Continuing Evolution of OSPF | OSPF Network Design Solutions

Table of Contents

Draft Summary

Opaque LSAs are very interesting in that they have not really been designed like the other OSPF LSAs. They are very forward looking by providing OSPF with a way to allow for future growth. This is also shown in the draft, as it not designed to address the exact operation of Opaque LSAs.

Notes:
The OSPF ARA Option is another Internet Draft for OSPF that has already been written that takes advantage of the proposed Opaque LSA.

An Opaque LSA has the standard LSA header followed by a 32-bit application-specific information field. The Opaque LSA will also use the link-state database (LSDB) as its distribution method for flooding within an OSPF network. This draft refers to this as the Flooding Scope.

There are three unique types of Opaque LSAs. Each has a different Flooding scope:

• Type 9. Link local scope and are not flooded beyond the local network.

• Type 10. Area local scope and are not flooded beyond their associated area.

• Type 11. Flooded throughout the OSPF Autonomous System and all transit areas but are not flooded into stub areas nor to routers not originating them and connected to a stub area.

OSPF Over ATM and Proxy PAR

Date Published: March 98

Author: Przygienda & Droz

Expiration Date: September 1998

File Name: draft-ietf-OSPF-atm-01.txt

Abstract

This draft specifies for OSPF implementers and users mechanisms describing how the protocol operates in ATM networks over PVC and SVC meshes with the presence of Proxy PAR.

These recommendations do not require any protocol changes and enable simpler, more efficient and cost- effective network designs. It is recommended that OSPF implementations should 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) where a solution simulating broadcast interfaces is not appropriate. Proxy PAR can help to distribute configuration changes of such interfaces when OSPF capable routers are reconfigured on the ATM cloud.

Draft Summary

This Internet Draft details how OSPF, if it becomes a standard, will be able to operate effectively over ATM. Some of the more useful information as to why it is needed is detailed in the sections that follow.

Overview of PNNI Augmented Routing (PAR)

Private Network-Network Interface (PNNI) Augmented Routing is an extension to PNNI to allow the flooding of information in non-ATM devices. PAR uses a new PTSE type to carry this non-ATM-related information. The current version of PAR specifies IGs for the flooding of IPv4-related protocol information such as OSPF or BGP.

Notes:
Private Network-Network Interface (PNNI) is an ATM Forum specification that describes an ATM virtual circuit routing protocol, as well as a signaling protocol between ATM switches. It is used to enable ATM switches within a private network to interconnect. It is sometimes referred to as Private Network Node Interface.

Overview of Proxy PAR

Proxy PAR is a protocol that allows for different ATM-attached devices to interact with PAR-capable switches and obtain information about non-ATM services without having to run PAR. The main purpose of the protocol is to enable the automatic detection of devices over an ATM cloud in a distributed fashion, without relying on a broadcast facility.

The protocol does not specify how the distributed service registration and data delivered to the client are supposed to drive other protocols. For example, OSPF routers finding themselves through Proxy PAR could use this information to form a full mesh of point-to-point VCs and communicate using RFC 1483 (Multiprotocol Encapsulation over ATM Adaptation) encapsulation. In terms of the discovery of other devices such as IP routers, Proxy PAR is an alternative to LANE (LAN Emulation over ATM 1.0) or MARS (support for Multicast over UNI 3.0/3.1-based ATM Networks). It is expected that the guidelines defining how a certain protocol can make use of Proxy PAR and PAR should come from the group or standardization body that is responsible for the particular protocol.

Techniques in OSPF-Based Network Deployment

Date Published: March 1998

Author: Berkowitz

Expiration Date: September 1998

File Name: draft-berkowitz-ospfdeploy-00.txt

Notes:
This draft has not yet been formally accepted by the IETF, but it has been submitted to the OSPF Working Group for consideration.

Abstract

OSPF is the preferred interior routing protocol of the Internet. It is a complex protocol intended to deal with complex networks. Although it is a powerful mechanism, it does not handle all situations, and its appropriate use might not be obvious to beginners. Standards track documents deal with protocol design, but deployment of OSPF in many enterprise networks has been limited by a lack of information on the best current practice information for interior routing. Best Current Practices documents have focused on general exterior connectivity. This memorandum is intended to complement the protocol specification by describing the experience-based, vendor-independent techniques of OSPF and complementary technologies in representative networks. Better understanding of the use of OSPF features to help exterior connectivity will help reduce the demand for complex user BGP configuration.

Draft Summary

This working draft is one of the most impressive from a “how to” and “what if” standpoint when dealing with OSPF. It is not designed to change or expand OSPF, but rather, the author intends to provide information on different techniques for deploying OSPF. It has been written on the same premise as this text—theory is fine, but most people are more interested in practical application—an area of OSPF that is sorely lacking in documentation. This book and working draft will certainly go along way to filling this need.

The author cites five major topics within this draft, which are as follows:

• Barriers to Understanding OSPF Deployment

• Area Sizing and Numbering Strategies

• Increasing Backbone Reliability & Backbone of Backbones

• Transition and Network Consolidation

• Transition of Legacy Routing Protocol Domains to OSPF

• Traffic Management

Table of Contents