OSPF Database Exchange Summary List Optimization
RFC 5243
|
| Document |
Type |
|
RFC - Informational
(May 2008; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5243 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
David Ward
|
|
Send notices to |
|
(None)
|
Network Working Group R. Ogier
Request for Comments: 5243 SRI International
Category: Informational May 2008
OSPF Database Exchange Summary List Optimization
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
This document describes a backward-compatible optimization for the
Database Exchange process in OSPFv2 and OSPFv3. In this
optimization, a router does not list a Link State Advertisement (LSA)
in Database Description packets sent to a neighbor, if the same or a
more recent instance of the LSA was listed in a Database Description
packet already received from the neighbor. This optimization reduces
Database Description overhead by about 50% in large networks. This
optimization does not affect synchronization, since it only omits
unnecessary information from Database Description packets.
1. Introduction
In OSPFv2 [RFC2328] and OSPFv3 [RFC2740], when two neighboring
routers become adjacent, they synchronize their link-state databases
via the Database Exchange process. Each router sends the other
router a set of Database Description (DD) packets that describes the
router's link-state database. This is done by listing each LSA
(i.e., including the header of each LSA) in one of the sent DD
packets. This procedure allows each router to determine whether the
other router has newer LSA instances that should be requested via
Link State Request packets.
The optimization simply observes that it is not necessary for a
router (master or slave) to list an LSA in a DD packet if it knows
the neighbor already has an instance of the LSA that is the same or
more recent (and therefore will not request the LSA). To avoid
listing such LSAs in DD packets, when an LSA is listed in a DD packet
received from the neighbor, and the Database summary list for the
neighbor has an instance of the LSA that is the same as or less
recent than the one received, the LSA is removed from the summary
list.
Ogier Informational [Page 1]
RFC 5243 OSPF Database Summary List Optimization May 2008
The optimization, called the Database Exchange summary list
optimization, does not affect synchronization, since the LSAs that
are omitted from DD packets are unnecessary. The optimization is
fully backward compatible with OSPF. The optimization reduces
Database Description overhead by about 50% in large networks in which
routers are usually already nearly synchronized when they become
adjacent, since it reduces the total number of LSA headers exchanged
by about one-half in such networks. The optimization is especially
beneficial in large networks with limited bandwidth, such as large
mobile ad hoc networks.
2. Specification of Optimization
The Database Exchange summary list optimization is defined by
modifying Section 10.6 "Receiving Database Description Packets" of
RFC 2328 as follows. The second-to-last paragraph of Section 10.6 is
replaced with the following augmented paragraph:
When the router accepts a received Database Description Packet as the
next in sequence, the packet contents are processed as follows. For
each LSA listed, the LSA's LS type is checked for validity. If the
LS type is unknown (e.g., not one of the LS types 1-5 defined by this
specification), or if this is an AS-external-LSA (LS type = 5) and
the neighbor is associated with a stub area, generate the neighbor
event SeqNumberMismatch and stop processing the packet. Otherwise,
the router looks up the LSA in its database to see whether it also
has an instance of the LSA. If it does not, or if the database copy
is less recent, the LSA is put on the Link state request list so that
it can be requested (immediately or at some later time) in Link State
Request Packets. In addition, if the Database summary list contains
an instance of the LSA that is the same as or less recent than the
listed LSA, the LSA is removed from the Database summary list.
The above additional step (which updates the Database summary list)
may be performed either before or after the router looks up the
listed LSA in its database and possibly adds the LSA to the Link
state request list. However, to implement the optimization, the
additional step must be performed for each LSA listed in the received
DD packet (to fully update the Database summary list) before the next
DD packet is sent in response.
Ogier Informational [Page 2]
Show full document text