RFC 1247
OSPF Version 2
References [BBN] McQuillan, J.M., Richer, I. and Rosen, E.C. ARPANET Routing Algorithm Improvements. BBN Technical Report 3803, April 1978. [DEC] Digital Equipment Corporation. Information processing systems -- Data communications -- Intermediate System to Intermediate System Intra-Domain Routing Protocol. October 1987. [McQuillan] McQuillan, J. et.al. The New Routing Algorithm for the Arpanet. IEEE Transactions on Communications, May 1980. [Perlman] Perlman, Radia. Fault-Tolerant Broadcast of Routing Information. Computer Networks, Dec. 1983. [RFC 791] Postel, Jon. Internet Protocol. September 1981 [RFC 944] ANSI X3S3.3 86-60. Final Text of DIS 8473, Protocol for Providing the Connectionless-mode Network Service. March 1986. [RFC 1060] Reynolds, J. and Postel, J. Assigned Numbers. March 1990. [RFC 1112] Deering, S.E. Host extensions for IP multicasting. May 1988. [RFC 1131] Moy, J. The OSPF Specification. October 1989. [RS-85-153] Leiner, Dr. Barry M., et.al. The DARPA Internet Protocol Suite. DDN Protocol Handbook, April 1985.
A. OSPF data formats This appendix describes the format of OSPF protocol packets and OSPF link state advertisements. 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. It is contained both in OSPF protocol packets and in OSPF link state advertisements. OSPF packet formats are detailed in Section A.3. A description of OSPF link state advertisements 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 network 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. 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 packets sent over virtual links to 576 bytes. However, if necessary, the length of OSPF packets can be up to 65,535 bytes (including the IP header). The other important features of OSPF's IP encapsulation are: o Use of IP multicast. Some OSPF messages are multicast, when sent over multi-access networks. Two distinct IP multicast addresses are used. Packets destined to these multicast addresses should never be forwarded. Such packets 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 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
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 [RFC 1060].
o Routing protocol packets are sent with IP TOS of 0. The OSPF
protocol supports TOS-based routing. Routes to any particular
destination may vary based on TOS. However, all OSPF routing
protocol packets are sent with the DTR bits in the IP header's TOS
field (see [RFC 791]) set to 0.
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 [RFC 791] 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 link state advertisements. 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 LSA types to a neighbor because of its reduced functionality. Lastly, listing capabilities in LSAs allows routers to route traffic around reduced functionality routers, by excluding them from parts of the routing table calculation. Two capabilities are currently defined. For each capability, the effect of the capability's appearance (or lack of appearance) in Hello packets, Database Description packets and link state advertisements is specified below. For example, the external routing capability (below called the E-bit) has meaning only in OSPF Hello Packets. Routers should reset (i.e. clear) the unassigned part of the capability field when sending Hello packets or Database Description packets and when originating link state advertisements. Additional capabilities may be assigned in the future. Routers encountering unrecognized capabilities in received Hello Packets, Database Description packets or link state advertisements should ignore the capability and process the packet/advertisement normally. +-+-+-+-+-+-+-+-+ | | | | | | |E|T| +-+-+-+-+-+-+-+-+ The options field T-bit This describes the router's TOS capability. If the T-bit is reset, then the router supports only a single TOS (TOS 0). Such a router is also said to be incapable of TOS-routing. The absence of the T- bit in a router links advertisement causes the router to be skipped when building a non-zero TOS shortest-path tree (see Section 16.9). In other words, routers incapable of TOS routing will be avoided as much as possible when forwarding data traffic requesting a non-zero TOS. The absence of the T-bit in a summary link advertisement or an AS external link advertisement indicates that the advertisement is
describing a TOS 0 route only (and not routes for non-zero TOS).
E-bit
AS external link advertisements are not flooded into/through OSPF
stub areas (see Section 3.6). The E-bit ensures that all members of
a stub area agree on that area's configuration. The E-bit is
meaningful only in OSPF Hello packets. When the E-bit is reset in
the Hello packet sent out a particular interface, it means that the
router will neither send nor receive AS external link state
advertisements on that interface (in other words, the interface
connects to a stub area). Two routers will not become neighbors
unless they agree on the state of the E-bit.
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 link state advertisements. For example, Link State Update packets implement the flooding of advertisements throughout the OSPF routing domain. Because of this, OSPF protocol packets cannot be parsed unless the format of link state advertisements is also understood. The format of Link state advertisements 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 common 24 byte header. This header contains all the necessary information 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. The format of each of these packet types is described in a succeeding section. 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 protocol packet in bytes. This length includes
the standard OSPF header.
Router ID
The Router ID of the packet's source. In OSPF, the source and
destination of a routing protocol packet are the two ends of an
(potential) adjacency.
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.
Checksum
The standard IP checksum of the entire contents of the packet,
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.
AuType
Identifies the authentication scheme to be used for the packet.
Authentication is discussed in Appendix E of the specification.
Consult Appendix E for a list of the currently defined
authentication types.
Authentication
A 64-bit field for use by the authentication scheme.
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, Hellos 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, hello and dead intervals). 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInt | Options | Rtr Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DeadInt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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.
HelloInt
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.
Deadint
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 advertising router. The Designated Router is identified here
by its IP interface address on the network. Set to 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 advertising router. The Backup Designated Router is
identified here by its IP interface address on the network. Set to
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
DeadInt 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 topological 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 master, the other a 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' sequence numbers. 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 topological 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 0 | Options |0|0|0|0|0|I|M|MS +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DD sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | A | +- Link State Advertisement -+ | Header | +- -+ | | +- -+ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
0 These fields are reserved. They must be 0.
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 descriptions.
M-bit
The More bit. When set to 1, it indicates that more database
descriptions 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 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
topological database's pieces. Each link state advertisement in the
database is described by its link state header. The link state header
is documented in Section A.4.1. It contains all the information
required to uniquely identify both the advertisement and the
advertisement'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 topological 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. The sending of Link State Request packets is the last step in bringing up an adjacency. A router that sends a Link State Request packet has in mind the precise instance of the database pieces it is requesting (defined by LS sequence number, LS checksum, and LS age). It 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 advertisement requested is specified by its LS type, Link State ID, and Advertising Router. This uniquely identifies the advertisement, 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 link state advertisements. Each Link State Update packet carries a collection of link state advertisements one hop further from its origin. Several link state advertisements 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 advertisements are acknowledged in Link State Acknowledgment packets. If retransmission of certain advertisements is necessary, the retransmitted advertisements are always carried by unicast Link State Update packets. For more information on the reliable flooding of link state advertisements, 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # advertisements | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- +-+ | Link state advertisements | +- +-+ | ... | # advertisements The number of link state advertisements included in this update. The body of the Link State Update packet consists of a list of link state advertisements. Each advertisement begins with a common 20 byte
header, the link state advertisement header. This header is described in Section A.4.1. Otherwise, the format of each of the five types of link state advertisements is different. Their formats 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 link state advertisements reliable, flooded advertisements are explicitly acknowledged. This acknowledgment is accomplished through the sending and receiving of Link State Acknowledgment packets. Multiple link state advertisements can be acknowledged in a single packet. Depending on the state of the sending interface and the source of the advertisements being acknowledged, 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 link state advertisement 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | A | +- Link State Advertisement -+ | Header | +- -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
Each acknowledged link state advertisement is described by its link state header. The link state header is documented in Section A.4.1. It contains all the information required to uniquely identify both the advertisement and the advertisement's current instance.
A.4 Link state advertisement formats There are five distinct types of link state advertisements. Each link state advertisement begins with a standard 20-byte link state header. This header is explained in Section A.4.1. Succeeding sections then diagram the separate link state advertisement types. Each link state advertisement describes a piece of the OSPF routing domain. Every router originates a router links advertisement. In addition, whenever the router is elected Designated Router, it originates a network links advertisement. Other types of link state advertisements may also be originated (see Section 12.4). All link state advertisements are then flooded throughout the OSPF routing domain. The flooding algorithm is reliable, ensuring that all routers have the same collection of link state advertisements. (See Section 13 for more information concerning the flooding algorithm). This collection of advertisements is called the link state (or topological) database. From the link state database, each router constructs a shortest path tree with itself as root. This yields a routing table (see Section 11). For the details of the routing table build process, see Section 16.
A.4.1 The Link State Advertisement header All link state advertisements begin with a common 20 byte header. This header contains enough information to uniquely identify the advertisement (LS type, Link State ID, and Advertising Router). Multiple instances of the link state advertisement may exist in the routing domain at the same time. It is then necessary to determine which instance is more recent. This is accomplished by examining the LS age, LS sequence number and LS checksum fields that are also contained in the link state advertisement header. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LS age The time in seconds since the link state advertisement was originated. Options The optional capabilities supported by the described portion of the routing domain. OSPF's optional capabilities are documented in Section A.2. LS type The type of the link state advertisement. Each link state type has a separate advertisement format. The link state types are as follows (see Section 12.1.3 for further explanation):
LS Type Description
___________________________________
1 Router links
2 Network links
3 Summary link (IP network)
4 Summary link (ASBR)
5 AS external link
Link State ID
This field identifies the portion of the internet environment that
is being described by the advertisement. The contents of this field
depend on the advertisement's LS type. For example, in network
links advertisements the Link State ID is set to the IP interface
address of the network's Designated Router (from which the network's
IP address can be derived). The Link State ID is further discussed
in Section 12.1.4.
Advertising Router
The Router ID of the router that originated the link state
advertisement. For example, in network links advertisements this
field is set to the Router ID of the network's Designated Router.
LS sequence number
Detects old or duplicate link state advertisements. Successive
instances of a link state advertisement are given successive LS
sequence numbers. See Section 12.1.6 for more details.
LS checksum
The Fletcher checksum of the complete contents of the link state
advertisement. See Section 12.1.7 for more details.
length
The length in bytes of the link state advertisement. This includes
the 20 byte link state header.
A.4.2 Router links advertisements Router links advertisements are the Type 1 link state advertisements. Each router in an area originates a router links advertisement. The advertisement describes the state and cost of the router's links (or interfaces) to the area. All of the router's links to the area must be described in a single router links advertisement. For details concerning the construction of router links advertisements, see Section 12.4.1. In router links advertisements, the Link State ID field is set to the router's OSPF Router ID. The T-bit is set in the advertisement's Option field if and only if the router is able to calculate a separate set of routes for each IP TOS. Router links advertisements are flooded throughout a single area only. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |E|B| 0 | # links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | # TOS | TOS 0 metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | 0 | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | 0 | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
bit E
When set, the router is an AS boundary router (E is for external)
bit B
When set, the router is an area border router (B is for border)
# links
The number of router links described by this advertisement. This
must be the total collection of router links to the area.
The following fields are used to describe each router link. Each router
link is typed (see the below Type field). The type field indicates the
kind of link being described. It may be a link to a transit network, to
another router or to a stub network. The values of all the other fields
describing a router link depend on the link's type. For example, each
link has an associated 32-bit data field. For links to stub networks
this field specifies the network's IP address mask. For the other link
types the Link Data specifies the router's associated IP interface
address.
Type
A quick description of the router link. One of the following. Note
that host routes are classified as links to stub networks whose
network mask is 0xffffffff.
Type Description
__________________________________________________
1 Point-to-point connection to another router
2 Connection to a transit network
3 Connection to a stub network
4 Virtual link
Link ID
Identifies the object that this router link connects to. Value
depends on the link's type. When connecting to an object that also
originates a link state advertisement (i.e., another router or a
transit network) the Link ID is equal to the other advertisement's
Link State ID. This provides the key for looking up said
advertisement in the link state database. See Section 12.2 for more
details.
Type Link ID
______________________________________
1 Neighboring router's ID
2 IP address of Designated Router
3 IP network/subnet number
4 Neighboring router's ID
Link Data
Contents again depend on the link's Type field. For connections to
stub network, it specifies the network mask. For the other link
types it specifies the router's associated IP interface address.
This latter piece of information is needed during the routing table
build process, when calculating the IP address of the next hop. See
Section 16.1.1 for more details.
#metrics
The number of different TOS metrics given for this link, not
counting the required metric for TOS 0. For example, if no
additional TOS metrics are given, this field should be set to 0.
TOS 0 metric
The cost of using this router link for TOS 0.
For each link, separate metrics may be specified for each Type of
Service (TOS). The metric for TOS 0 must always be included, and was
discussed above. Metrics for non-zero TOS are described below. The
encoding of TOS in OSPF link state advertisements is described in
Section 12.3. Note that the cost for non-zero TOS values that are not
specified defaults to the TOS 0 cost. Metrics must be listed in order
of increasing TOS encoding. For example, the metric for TOS 16 must
always follow the metric for TOS 8 when both are specified.
TOS IP type of service that this metric refers to. The encoding of TOS
in OSPF link state advertisements is described in Section 12.3.
metric
The cost of using this outbound router link, for traffic of the
specified TOS.
A.4.3 Network links advertisements Network links advertisements are the Type 2 link state advertisements. A network links advertisement is originated for each transit network in the area. A transit network is a multi-access network that has more than one attached router. The network links advertisement is originated by the network's Designated Router. The advertisement describes all routers attached to the network, including the Designated Router itself. The advertisement's Link State ID field lists the IP interface address of the Designated Router. The distance from the network to all attached routers is zero, for all types of service. This is why the TOS and metric fields need not be specified in the network links advertisement. For details concerning the construction of network links advertisements, see Section 12.4.2. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attached Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Network Mask The IP address mask for the network. For example, a class A network would have the mask 0xff000000. Attached Router The Router IDs of each of the routers attached to the network. Actually, only those routers that are fully adjacent to the Designated Router are listed. The Designated Router includes itself in this list. The number of routers included can be deduced from the link state advertisement's length field.
A.4.4 Summary link advertisements Summary link advertisements are the Type 3 and 4 link state advertisements. These advertisements are originated by area border routers. A separate summary link advertisement is made for each destination (known to the router) which belongs to the AS, yet is outside the area. For details concerning the construction of summary link advertisements, see Section 12.4.3. Type 3 link state advertisements are used when the destination is an IP network. In this case the advertisement's Link State ID field is an IP network number. When the destination is an AS boundary router, a Type 4 advertisement is used, and the Link State ID field is the AS boundary router's OSPF Router ID. (To see why it is necessary to advertise the location of each ASBR, consult Section 16.4.) Other than the difference in the Link State ID field, the format of Type 3 and 4 link state advertisements is identical. For stub areas, type 3 summary link advertisements can also be used to describe a (per-area) default route. Default summary routes are used in stub areas instead of flooding a complete set of external routes. When describing a default summary route, the advertisement's Link State ID is always set to DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. Separate costs may be advertised for each IP Type of Service. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. Note that the cost for TOS 0 must be included, and is always listed first. If the T-bit is reset in the advertisement's Option field, only a route for TOS 0 is described by the advertisement. Otherwise, routes for the other TOS values are also described; if a cost for a certain TOS is not included, its cost defaults to that specified for TOS 0. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 3 or 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Network Mask
For Type 3 link state advertisements, this indicates the
destination's IP network mask. For example, when advertising the
location of a class A network the value 0xff000000 would be used.
This field is not meaningful and must be zero for Type 4 link state
advertisements.
For each specified type of service, the following fields are defined.
The number of TOS routes included can be calculated from the link state
advertisement's length field. Values for TOS 0 must be specified; they
are listed first. Other values must be listed in order of increasing
TOS encoding. For example, the cost for TOS 16 must always follow the
cost for TOS 8 when both are specified.
TOS The Type of Service that the following cost concerns. The encoding
of TOS in OSPF link state advertisements is described in Section
12.3.
metric
The cost of this route. Expressed in the same units as the
interface costs in the router links advertisements.
A.4.5 AS external link advertisements AS external link advertisements are the Type 5 link state advertisements. These advertisements are originated by AS boundary routers. A separate advertisement is made for each destination (known to the router) which is external to the AS. For details concerning the construction of AS external link advertisements, see Section 12.4.3. AS external link advertisements usually describe a particular external destination. For these advertisements the Link State ID field specifies an IP network number. AS external link advertisements are also used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the Link State ID is always set to DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. Separate costs may be advertised for each IP Type of Service. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. Note that the cost for TOS 0 must be included, and is always listed first. If the T-bit is reset in the advertisement's Option field, only a route for TOS 0 is described by the advertisement. Otherwise, routes for the other TOS values are also described; if a cost for a certain TOS is not included, its cost defaults to that specified for TOS 0. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Route Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
Network Mask
The IP network mask for the advertised destination. For example,
when advertising a class A network the mask 0xff000000 would be
used.
For each specified type of service, the following fields are defined.
The number of TOS routes included can be calculated from the link state
advertisement's length field. Values for TOS 0 must be specified; they
are listed first. Other values must be listed in order of increasing
TOS encoding. For example, the cost for TOS 16 must always follow the
cost for TOS 8 when both are specified.
bit E
The type of external metric. If bit E is set, the metric specified
is a Type 2 external metric. This means the metric is considered
larger than any link state path. If bit E is zero, the specified
metric is a Type 1 external metric. This means that is is
comparable directly (without translation) to the link state metric.
Forwarding address
Data traffic for the advertised destination will be forwarded to
this address. If the Forwarding address is set to 0.0.0.0, data
traffic will be forwarded instead to the advertisement's originator
(i.e., the responsible AS boundary router).
TOS The Type of Service that the following cost concerns. The encoding
of TOS in OSPF link state advertisements is described in Section
12.3.
metric
The cost of this route. Interpretation depends on the external type
indication (bit E above).
External Route Tag
A 32-bit field attached to each external route. This is not used by
the OSPF protocol itself. It may be used to communicate information
between AS boundary routers; the precise nature of such information
is outside the scope of this specification.
B. Architectural Constants Several OSPF protocol parameters have fixed architectural values. These parameters have been referred to in the text by names such as LSRefreshTimer. The same naming convention is used for the configurable protocol parameters. They are defined in appendix C. The name of each architectural constant follows, together with its value and a short description of its function. LSRefreshTime The maximum time between distinct originations of any particular link state advertisement. For each link state advertisement that a router originates, an interval timer should be set to this value. Firing of this timer causes a new instance of the link state advertisement to be originated. The value of LSRefreshTime is set to 30 minutes. MinLSInterval The minimum time between distinct originations of any particular link state advertisement. The value of MinLSInterval is set to 5 seconds. MaxAge The maximum age that a link state advertisement can attain. When an advertisement's age reaches MaxAge, it is reflooded. It is then removed from the database as soon as this flood is acknowledged, i.e., as soon as it has been removed from all neighbor Link state retransmission lists. Advertisements having age MaxAge are not used in the routing table calculation. The value of MaxAge must be greater than LSRefreshTime. The value of MaxAge is set to 1 hour. CheckAge When the age of a link state advertisement (that is contained in the link state database) hits a multiple of CheckAge, the advertisement's checksum is verified. An incorrect checksum at this time indicates a serious error. The value of CheckAge is set to 5 minutes. MaxAgeDiff The maximum time dispersion that can occur, as a link state advertisement is flooded throughout the AS. Most of this time is accounted for by the link state advertisements sitting on router output queues (and therefore not aging) during the flooding process. The value of MaxAgeDiff is set to 15 minutes.
LSInfinity
The link state metric value indicating that the destination is
unreachable. It is defined to be the binary value of all ones. It
depends on the size of the metric field, which is 16 bits in router
links advertisements, and 24 bits in both summary and AS external
links advertisements.
DefaultDestination
The Destination ID that indicates the default route. This route is
used when no other matching routing table entry can be found. The
default destination can only be advertised in AS external link
advertisements and in type 3 summary link advertisements for stub
areas. Its value is the IP address 0.0.0.0.
(next page on part 7)
