OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type
RFC 6845
Internet Engineering Task Force (IETF) N. Sheth
Request for Comments: 6845 Contrail Systems
Updates: 2328, 5340 L. Wang
Category: Standards Track J. Zhang
ISSN: 2070-1721 Juniper Networks
January 2013
OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type
Abstract
This document describes a mechanism to model a broadcast network as a
hybrid of broadcast and point-to-multipoint networks for purposes of
OSPF operation. Neighbor discovery and maintenance as well as Link
State Advertisement (LSA) database synchronization are performed
using the broadcast model, but the network is represented using the
point-to-multipoint model in the router-LSAs of the routers connected
to it. This allows an accurate representation of the cost of
communication between different routers on the network, while
maintaining the network efficiency of broadcast operation. This
approach is relatively simple and requires minimal changes to OSPF.
This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6845.
Sheth, et al. Standards Track [Page 1]
RFC 6845 OSPF Hybrid Broadcast and P2MP Intf Type January 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 4
4.2. Neighbor Data Structure . . . . . . . . . . . . . . . . . . 4
4.3. Neighbor Discovery and Maintenance . . . . . . . . . . . . 5
4.4. Database Synchronization . . . . . . . . . . . . . . . . . 5
4.5. Generating Network-LSAs . . . . . . . . . . . . . . . . . . 5
4.6. Generating Router and Intra-Area-Prefix-LSAs . . . . . . . 5
4.6.1. Stub Links in OSPFv2 Router-LSA . . . . . . . . . . . . 6
4.6.2. OSPFv3 Intra-Area-Prefix-LSA . . . . . . . . . . . . . 6
4.7. Next-Hop Calculation . . . . . . . . . . . . . . . . . . . 6
4.8. Graceful Restart . . . . . . . . . . . . . . . . . . . . . 6
5. Compatibility Considerations . . . . . . . . . . . . . . . . . 6
6. Scalability and Deployment Considerations . . . . . . . . . . . 7
7. Management Considerations . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Sheth, et al. Standards Track [Page 2]
RFC 6845 OSPF Hybrid Broadcast and P2MP Intf Type January 2013
1. Introduction
OSPF [RFC2328] operation on broadcast interfaces takes advantage of
the broadcast capabilities of the underlying medium for doing
neighbor discovery and maintenance. Further, it uses a Designated
Router (DR) and Backup Designated Router (BDR) to keep the Link State
Advertisement (LSA) databases of the routers on the network
synchronized in an efficient manner. However, it has the limitation
that a router cannot advertise different costs to each of the
neighboring routers on the network in its router-LSA.
Consider a radio network that supports true broadcast, yet the
metrics between different pairs of terminals could be different for
Show full document text