tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 1247

 
 
 

OSPF Version 2

Part 6 of 7, p. 135 to 165
Prev RFC Part       Next RFC Part

 


prevText      Top       Page 135 
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.

Top       Page 136 
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

Top       Page 137 
        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.

Top       Page 138 
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

Top       Page 139 
    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.

Top       Page 140 
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.

Top       Page 141 
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

Top       Page 142 
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.

Top       Page 143 
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                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |

Top       Page 144 
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.

Top       Page 145 
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                              |
   +-                                                             -+
   |                                                               |
   +-                                                             -+
   |                                                               |

Top       Page 146 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |




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.

Top       Page 147 
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).

Top       Page 148 
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

Top       Page 149 
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.

Top       Page 150 
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                              |
   +-                                                             -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |

Top       Page 151 
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.

Top       Page 152 
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.

Top       Page 153 
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):

Top       Page 154 
                      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.

Top       Page 155 
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                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top       Page 156 
   |                              ...                              |



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

Top       Page 157 
    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

Top       Page 158 
    specified TOS.

Top       Page 159 
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.

Top       Page 160 
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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top       Page 161 
   |                         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.

Top       Page 162 
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                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              |

Top       Page 163 
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.

Top       Page 164 
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.

Top       Page 165 
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 RFC Part