This document defines an optional extension to OSPF that enables routers to distribute IP to link-layer address resolution information. An OSPF Address Resolution Advertisement (ARA) may include media-specific information, such as a multipoint-to-point connection identifier along with the address resolution information to support media-specific functions. The ARA option can be used to support router-to-router inter-subnet shortcut architectures such as those described in the draft titled, Intra-area IP unicast among routers over legacy ATM.
This draft was written to enable OSPF to begin taking advantage of new characteristics of switching at the second layer of the OSI reference model. This type of switching is more commonly known as switched Layer 2 technologies.
The specific new characteristic this draft is concerned with is the new ability to provide inter-subnet shortcut data switching. This switching bypasses the Layer 3 forwarding intervention, which is where switching has traditionally been performed. For this Layer 2 switching to take place, the ingress device(s) must have the link-layer address of the egress device(s). This can either be accomplished through configuration or by dynamically resolving an IP address to a link-layer address.
This draft introduces a method for IP address to link-layer address resolution between routers and router-to-network inter-subnet shortcuts as previously discussed:
This draft does not define an ARA architecture, instead it is meant to be used with the architecture as described in the draft titled, Intra-area IP unicast among routers over legacy ATM. The ARA option is designed to support the following types of operations:
OSPFv2 Domain of Interpretation (DOI) for ISAKMP
Date Published: October 1997
Expiration Date: May 1998
File Name: draft-ietf-ospf-doi-00.txt
The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the OSPFv2 Domain of Interpretation, which is defined to cover the use of ISAKMP to negotiate Security Associations for the OSPFv2 routing protocol.
This Internet Draft details the requirements necessary for using the cryptographic authentication method and operation to provide data authentication for OSPFv2. This Internet Draft is required because OSPF authentication is only on the routing information between participating routers; it does not protect data! If this draft becomes a standard, there will be a means of protecting the data OSPF carries that is very tightly coupled within OSPF.
OSPF NSSA Option
Date Published: December 1997
Author: Coltun, Fuller, & Murphy
Expiration Date: June 1998
File Name: draft-ietf-ospf-nssa-update-03.txt
This Internet Draft documents an optional type of OSPF area, which is somewhat humorously referred to as a not-so-stubby area (NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion.
The OSPF NSSA Option was originally defined in RFC 1587. All functional differences between this memo and RFC 1597, while expanding capability, are backward compatible in nature. Implementations of this memo and of RFC 1587 are interoperable.
As previously discussed, NSSAs remove some of the topological limitations of regular stub areas by enabling the limited importing of external routes. This draft details some enhancements to NSSAs, with the most important change being an addition to the NSSA data structure and the operation of a OSPF router when configured as an NSSA Router. This data structure change is reflected by adding NSSATranslateState. This parameter enables you to control whether the NSSA Border Router performs translation of Type-7 LSAs into Type-5 LSAs and floods the translated Type-5 LSA. There are three settings possible:
This is not the only change being proposed, but it is the most fundamental. There are several other changes being performed as well, and they are as follows:
OSPF Opaque LSA
Date Published: February 1998
Expiration Date: August 1998
File name: draft-ietf-ospf-opaque-04.txt
This memo defines enhancements to the OSPF protocol to support a new class of LSAs called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field might be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology.