Appendix A. OSPF Data Formats
A. OSPF data formats
This appendix describes the format of OSPF protocol packets and OSPF
LSAs. The OSPF protocol runs directly over the IP network layer.
Before any data formats are described, the details of the OSPF
encapsulation are explained.
Next the OSPF Options field is described. This field describes
various capabilities that may or may not be supported by pieces of
the OSPF routing domain. The OSPF Options field is contained in OSPF
Hello packets, Database Description packets and in OSPF LSAs.
OSPF packet formats are detailed in Section A.3. A description of
OSPF LSAs appears in Section A.4.
A.1 Encapsulation of OSPF packets
OSPF runs directly over the Internet Protocol's network layer. OSPF
packets are therefore encapsulated solely by IP and local data-link
headers.
OSPF does not define a way to fragment its protocol packets, and
depends on IP fragmentation when transmitting packets larger than
the network MTU. If necessary, the length of OSPF packets can be up
to 65,535 bytes (including the IP header). The OSPF packet types
that are likely to be large (Database Description Packets, Link
State Request, Link State Update, and Link State Acknowledgment
packets) can usually be split into several separate protocol
packets, without loss of functionality. This is recommended; IP
fragmentation should be avoided whenever possible. Using this
reasoning, an attempt should be made to limit the sizes of OSPF
packets sent over virtual links to 576 bytes unless Path MTU
Discovery is being performed (see [Ref22]).
The other important features of OSPF's IP encapsulation are:
o Use of IP multicast. Some OSPF messages are multicast, when
sent over broadcast networks. Two distinct IP multicast
addresses are used. Packets sent to these multicast addresses
should never be forwarded; they are meant to travel a single hop
only. To ensure that these packets will not travel multiple
hops, their IP TTL must be set to 1.
AllSPFRouters
This multicast address has been assigned the value
224.0.0.5. All routers running OSPF should be prepared to
receive packets sent to this address. Hello packets are
always sent to this destination. Also, certain OSPF
protocol packets are sent to this address during the
flooding procedure.
AllDRouters
This multicast address has been assigned the value
224.0.0.6. Both the Designated Router and Backup Designated
Router must be prepared to receive packets destined to this
address. Certain OSPF protocol packets are sent to this
address during the flooding procedure.
o OSPF is IP protocol number 89. This number has been registered
with the Network Information Center. IP protocol number
assignments are documented in [Ref11].
o All OSPF routing protocol packets are sent using the normal
service TOS value of binary 0000 defined in [Ref12].
o Routing protocol packets are sent with IP precedence set to
Internetwork Control. OSPF protocol packets should be given
precedence over regular IP data traffic, in both sending and
receiving. Setting the IP precedence field in the IP header to
Internetwork Control [Ref5] may help implement this objective.
A.2 The Options field
The OSPF Options field is present in OSPF Hello packets, Database
Description packets and all LSAs. The Options field enables OSPF
routers to support (or not support) optional capabilities, and to
communicate their capability level to other OSPF routers. Through
this mechanism routers of differing capabilities can be mixed within
an OSPF routing domain.
When used in Hello packets, the Options field allows a router to
reject a neighbor because of a capability mismatch. Alternatively,
when capabilities are exchanged in Database Description packets a
router can choose not to forward certain LSAs to a neighbor because
of its reduced functionality. Lastly, listing capabilities in LSAs
allows routers to forward traffic around reduced functionality
routers, by excluding them from parts of the routing table
calculation.
Five bits of the OSPF Options field have been assigned, although
only one (the E-bit) is described completely by this memo. Each bit
is described briefly below. Routers should reset (i.e. clear)
unrecognized bits in the Options field when sending Hello packets or
Database Description packets and when originating LSAs. Conversely,
routers encountering unrecognized Option bits in received Hello
Packets, Database Description packets or LSAs should ignore the
capability and process the packet/LSA normally.
+------------------------------------+
| * | * | DC | EA | N/P | MC | E | * |
+------------------------------------+
The Options field
E-bit
This bit describes the way AS-external-LSAs are flooded, as
described in Sections 3.6, 9.5, 10.8 and 12.1.2 of this memo.
MC-bit
This bit describes whether IP multicast datagrams are forwarded
according to the specifications in [Ref18].
N/P-bit
This bit describes the handling of Type-7 LSAs, as specified in
[Ref19].
EA-bit
This bit describes the router's willingness to receive and
forward External-Attributes-LSAs, as specified in [Ref20].
DC-bit
This bit describes the router's handling of demand circuits, as
specified in [Ref21].
A.3 OSPF Packet Formats
There are five distinct OSPF packet types. All OSPF packet types
begin with a standard 24 byte header. This header is described
first. Each packet type is then described in a succeeding section.
In these sections each packet's division into fields is displayed,
and then the field definitions are enumerated.
All OSPF packet types (other than the OSPF Hello packets) deal with
lists of LSAs. For example, Link State Update packets implement the
flooding of LSAs throughout the OSPF routing domain. Because of
this, OSPF protocol packets cannot be parsed unless the format of
LSAs is also understood. The format of LSAs is described in Section
A.4.
The receive processing of OSPF packets is detailed in Section 8.2.
The sending of OSPF packets is explained in Section 8.1.
A.3.1 The OSPF packet header
Every OSPF packet starts with a standard 24 byte header. This
header contains all the information necessary to determine whether
the packet should be accepted for further processing. This
determination is described in Section 8.2 of the specification.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version #
The OSPF version number. This specification documents version 2
of the protocol.
Type
The OSPF packet types are as follows. See Sections A.3.2 through
A.3.6 for details.
Type Description
________________________________
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
Packet length
The length of the OSPF protocol packet in bytes. This length
includes the standard OSPF header.
Router ID
The Router ID of the packet's source.
Area ID
A 32 bit number identifying the area that this packet belongs
to. All OSPF packets are associated with a single area. Most
travel a single hop only. Packets travelling over a virtual
link are labelled with the backbone Area ID of 0.0.0.0.
Checksum
The standard IP checksum of the entire contents of the packet,
starting with the OSPF packet header but excluding the 64-bit
authentication field. This checksum is calculated as the 16-bit
one's complement of the one's complement sum of all the 16-bit
words in the packet, excepting the authentication field. If the
packet's length is not an integral number of 16-bit words, the
packet is padded with a byte of zero before checksumming. The
checksum is considered to be part of the packet authentication
procedure; for some authentication types the checksum
calculation is omitted.
AuType
Identifies the authentication procedure to be used for the
packet. Authentication is discussed in Appendix D of the
specification. Consult Appendix D for a list of the currently
defined authentication types.
Authentication
A 64-bit field for use by the authentication scheme. See
Appendix D for details.
A.3.2 The Hello packet
Hello packets are OSPF packet type 1. These packets are sent
periodically on all interfaces (including virtual links) in order to
establish and maintain neighbor relationships. In addition, Hello
Packets are multicast on those physical networks having a multicast
or broadcast capability, enabling dynamic discovery of neighboring
routers.
All routers connected to a common network must agree on certain
parameters (Network mask, HelloInterval and RouterDeadInterval).
These parameters are included in Hello packets, so that differences
can inhibit the forming of neighbor relationships. A detailed
explanation of the receive processing for Hello packets is presented
in Section 10.5. The sending of Hello packets is covered in Section
9.5.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 1 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | Options | Rtr Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Network mask
The network mask associated with this interface. For example,
if the interface is to a class B network whose third byte is
used for subnetting, the network mask is 0xffffff00.
Options
The optional capabilities supported by the router, as documented
in Section A.2.
HelloInterval
The number of seconds between this router's Hello packets.
Rtr Pri
This router's Router Priority. Used in (Backup) Designated
Router election. If set to 0, the router will be ineligible to
become (Backup) Designated Router.
RouterDeadInterval
The number of seconds before declaring a silent router down.
Designated Router
The identity of the Designated Router for this network, in the
view of the sending router. The Designated Router is identified
here by its IP interface address on the network. Set to 0.0.0.0
if there is no Designated Router.
Backup Designated Router
The identity of the Backup Designated Router for this network,
in the view of the sending router. The Backup Designated Router
is identified here by its IP interface address on the network.
Set to 0.0.0.0 if there is no Backup Designated Router.
Neighbor
The Router IDs of each router from whom valid Hello packets have
been seen recently on the network. Recently means in the last
RouterDeadInterval seconds.
A.3.3 The Database Description packet
Database Description packets are OSPF packet type 2. These packets
are exchanged when an adjacency is being initialized. They describe
the contents of the link-state database. Multiple packets may be
used to describe the database. For this purpose a poll-response
procedure is used. One of the routers is designated to be the
master, the other the slave. The master sends Database Description
packets (polls) which are acknowledged by Database Description
packets sent by the slave (responses). The responses are linked to
the polls via the packets' DD sequence numbers.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 2 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | Options |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The format of the Database Description packet is very similar to
both the Link State Request and Link State Acknowledgment packets.
The main part of all three is a list of items, each item describing
a piece of the link-state database. The sending of Database
Description Packets is documented in Section 10.8. The reception of
Database Description packets is documented in Section 10.6.
Interface MTU
The size in bytes of the largest IP datagram that can be sent
out the associated interface, without fragmentation. The MTUs
of common Internet link types can be found in Table 7-1 of
[Ref22]. Interface MTU should be set to 0 in Database
Description packets sent over virtual links.
Options
The optional capabilities supported by the router, as documented
in Section A.2.
I-bit
The Init bit. When set to 1, this packet is the first in the
sequence of Database Description Packets.
M-bit
The More bit. When set to 1, it indicates that more Database
Description Packets are to follow.
MS-bit
The Master/Slave bit. When set to 1, it indicates that the
router is the master during the Database Exchange process.
Otherwise, the router is the slave.
DD sequence number
Used to sequence the collection of Database Description Packets.
The initial value (indicated by the Init bit being set) should
be unique. The DD sequence number then increments until the
complete database description has been sent.
The rest of the packet consists of a (possibly partial) list of the
link-state database's pieces. Each LSA in the database is described
by its LSA header. The LSA header is documented in Section A.4.1.
It contains all the information required to uniquely identify both
the LSA and the LSA's current instance.
A.3.4 The Link State Request packet
Link State Request packets are OSPF packet type 3. After exchanging
Database Description packets with a neighboring router, a router may
find that parts of its link-state database are out-of-date. The
Link State Request packet is used to request the pieces of the
neighbor's database that are more up-to-date. Multiple Link State
Request packets may need to be used.
A router that sends a Link State Request packet has in mind the
precise instance of the database pieces it is requesting. Each
instance is defined by its LS sequence number, LS checksum, and LS
age, although these fields are not specified in the Link State
Request Packet itself. The router may receive even more recent
instances in response.
The sending of Link State Request packets is documented in Section
10.9. The reception of Link State Request packets is documented in
Section 10.7.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 3 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Each LSA requested is specified by its LS type, Link State ID, and
Advertising Router. This uniquely identifies the LSA, but not its
instance. Link State Request packets are understood to be requests
for the most recent instance (whatever that might be).
A.3.5 The Link State Update packet
Link State Update packets are OSPF packet type 4. These packets
implement the flooding of LSAs. Each Link State Update packet
carries a collection of LSAs one hop further from their origin.
Several LSAs may be included in a single packet.
Link State Update packets are multicast on those physical networks
that support multicast/broadcast. In order to make the flooding
procedure reliable, flooded LSAs are acknowledged in Link State
Acknowledgment packets. If retransmission of certain LSAs is
necessary, the retransmitted LSAs are always sent directly to the
neighbor. For more information on the reliable flooding of LSAs,
consult Section 13.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 4 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |
# LSAs
The number of LSAs included in this update.
The body of the Link State Update packet consists of a list of LSAs.
Each LSA begins with a common 20 byte header, described in Section
A.4.1. Detailed formats of the different types of LSAs are described
in Section A.4.
A.3.6 The Link State Acknowledgment packet
Link State Acknowledgment Packets are OSPF packet type 5. To make
the flooding of LSAs reliable, flooded LSAs are explicitly
acknowledged. This acknowledgment is accomplished through the
sending and receiving of Link State Acknowledgment packets.
Multiple LSAs can be acknowledged in a single Link State
Acknowledgment packet.
Depending on the state of the sending interface and the sender of
the corresponding Link State Update packet, a Link State
Acknowledgment packet is sent either to the multicast address
AllSPFRouters, to the multicast address AllDRouters, or as a
unicast. The sending of Link State Acknowledgement packets is
documented in Section 13.5. The reception of Link State
Acknowledgement packets is documented in Section 13.7.
The format of this packet is similar to that of the Data Description
packet. The body of both packets is simply a list of LSA headers.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 5 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Each acknowledged LSA is described by its LSA header. The LSA
header is documented in Section A.4.1. It contains all the
information required to uniquely identify both the LSA and the LSA's
current instance.