"Management Information Base for OSPFv3", Dan Joyal, Vishwas Manral, 29-Jul-09. ( bytes)

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3). Please send comments to ospf@ietf.org.

"OSPF Link-local Signaling", Alex Zinin, Abhay Roy, Liem Nguyen, Barry Friedman, Derek Yeung, 8-Jun-09. ( bytes)

OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well- defined fixed format. The format is not flexible enough to enable new features which need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This document replaces the experimental specification published in RFC4813 to bring it on the Standards Track.

"Support of address families in OSPFv3", Acee Lindem, Sina Mirtorabi, Abhay Roy, Michael Barnes, Rahul Aggarwal, 11-Jul-09. ( bytes)

This document describes a mechanism for supporting multiple address families in OSPFv3 using multiple instances. It maps an address family (AF) to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs.

"Advertising a Router's Local Addresses in OSPF TE Extensions", Rahul Aggarwal, Kireeti Kompella, 4-May-09. ( bytes)

OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE- enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE- enabled links, and the local address corresponding to the Router ID. In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) traffic engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE. This document describes procedures that enhance OSPF TE to advertise a router's local addresses.

"OSPFv2 HMAC-SHA Cryptographic Authentication", Randall Atkinson, Vishwas Manral, M Fanto, Russ White, Tony Li, Michael Barnes, Manav Bhatia, 27-May-09. ( bytes)

This document describes how the NIST Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328.

"Extensions to OSPF to Support Mobile Ad Hoc Networking", Madhavi Chandra, Abhay Roy, 11-Jul-09. ( bytes)

This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extension, called OSPF-OR, includes a mechanism for link-local signaling, a OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. It also provides a means to reduce unnecessary adjacencies to support larger MANET networks.

"MANET Extension of OSPF using CDS Flooding", Richard Ogier, Phil Spagnolo, 28-Jan-09. ( bytes)

This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information.

"Dynamic Hostname Exchange Mechanism for OSPF", Subbaiah Venkata, Sanjay Harwani, Carlos Pignataro, Danny McPherson, 12-Jul-09. ( bytes)

This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood their hostname-to-Router ID mapping information across an OSPF network to provide a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames just like for routers running IS-IS. This mechanism is applicable to both OSPFv2 and OSPFv3.

"OSPF Transport Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi, 2-May-09. ( bytes)

OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is convenient to envision using the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanism to relegate this ancillary information to a separate OSPF instance and minimize the impact.

"OSPF Multi-Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi, 27-Feb-09. ( bytes)

OSPFv3 includes a mechanism for supporting multiple instances on the same link. OSPFv2 could benefit from such a mechanism in order to support multiple routing domains on the same subnet. The OSPFv2 instance ID is reserved for support of separate OSPFv2 protocol instances. This is different from OSPFv3 where it could be used for other purposes such as putting the same link in multiple areas. OSPFv2 supports this capability using a separate subnet or the OSPF multi-area adjacency capability.

Return to Internet-Draft directory.

Return to IETF home page.