tech-invite   World Map     

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

RFC 2178

 
 
 

OSPF Version 2

Part 7 of 8, p. 168 to 200
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 168 
A.3.3 The Database Description packet

   Database Description packets are OSPF packet type 2.  These packets
   are exchanged when an adjacency is being initialized.  They describe
   the contents of the link-state database.  Multiple packets may be
   used to describe the database.  For this purpose a poll-response
   procedure is used. One of the routers is designated to be the master,
   the other the slave.  The master sends Database Description packets
   (polls) which are acknowledged by Database Description packets sent
   by the slave (responses).  The responses are linked to the polls via
   the packets' DD sequence numbers.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |       2       |         Packet length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Router ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Area ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Checksum            |             AuType            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Authentication                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Authentication                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Interface MTU         |    Options    |0|0|0|0|0|I|M|MS
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     DD sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-                      An LSA Header                          -+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |


   The format of the Database Description packet is very similar to both
   the Link State Request and Link State Acknowledgment packets.  The
   main part of all three is a list of items, each item describing a
   piece of the link-state database.  The sending of Database

Top      Up      ToC       Page 169 
   Description Packets is documented in Section 10.8. The reception of
   Database Description packets is documented in Section 10.6.

   Interface MTU
      The size in bytes of the largest IP datagram that can be sent out
      the associated interface, without fragmentation.  The MTUs of
      common Internet link types can be found in Table 7-1 of [Ref22].
      Interface MTU should be set to 0 in Database Description packets
      sent over virtual links.

   Options
      The optional capabilities supported by the router, as documented
      in Section A.2.

   I-bit
      The Init bit.  When set to 1, this packet is the first in the
      sequence of Database Description Packets.

   M-bit
      The More bit.  When set to 1, it indicates that more Database
      Description Packets are to follow.

   MS-bit
      The Master/Slave bit.  When set to 1, it indicates that the router
      is the master during the Database Exchange process.  Otherwise,
      the router is the slave.

   DD sequence number
      Used to sequence the collection of Database Description Packets.
      The initial value (indicated by the Init bit being set) should be
      unique.  The DD sequence number then increments until the complete
      database description has been sent.

   The rest of the packet consists of a (possibly partial) list of the
   link-state database's pieces.  Each LSA in the database is described
   by its LSA header. The LSA header is documented in Section A.4.1.  It
   contains all the information required to uniquely identify both the
   LSA and the LSA's current instance.

Top      Up      ToC       Page 170 
A.3.4 The Link State Request packet

   Link State Request packets are OSPF packet type 3. After exchanging
   Database Description packets with a neighboring router, a router may
   find that parts of its link-state database are out-of-date.  The Link
   State Request packet is used to request the pieces of the neighbor's
   database that are more up-to-date.  Multiple Link State Request
   packets may need to be used.

   A router that sends a Link State Request packet has in mind the
   precise instance of the database pieces it is requesting. Each
   instance is defined by its LS sequence number, LS checksum, and LS
   age, although these fields are not specified in the Link State
   Request Packet itself.  The router may receive even more recent
   instances in response.

   The sending of Link State Request packets is documented in Section
   10.9.  The reception of Link State Request packets is documented in
   Section 10.7.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |       3       |         Packet length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Router ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Area ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Checksum            |             AuType            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Authentication                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Authentication                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          LS type                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Link State ID                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |

   Each LSA requested is specified by its LS type, Link State ID, and
   Advertising Router.  This uniquely identifies the LSA, but not its
   instance.  Link State Request packets are understood to be requests
   for the most recent instance (whatever that might be).

Top      Up      ToC       Page 171 
A.3.5 The Link State Update packet

   Link State Update packets are OSPF packet type 4.  These packets
   implement the flooding of LSAs.  Each Link State Update packet
   carries a collection of LSAs one hop further from their origin.
   Several LSAs may be included in a single packet.

   Link State Update packets are multicast on those physical networks
   that support multicast/broadcast.  In order to make the flooding
   procedure reliable, flooded LSAs are acknowledged in Link State
   Acknowledgment packets.  If retransmission of certain LSAs is
   necessary, the retransmitted LSAs are always carried by unicast Link
   State Update packets.  For more information on the reliable flooding
   of LSAs, consult Section 13.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |       4       |         Packet length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Router ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Area ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Checksum            |             AuType            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Authentication                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Authentication                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            # LSAs                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-                                                            +-+
       |                             LSAs                              |
       +-                                                            +-+
       |                              ...                              |



   # LSAs
      The number of LSAs included in this update.

   The body of the Link State Update packet consists of a list of LSAs.
   Each LSA begins with a common 20 byte header, described in Section
   A.4.1. Detailed formats of the different types of LSAs are described
   in Section A.4.

Top      Up      ToC       Page 172 
A.3.6 The Link State Acknowledgment packet

   Link State Acknowledgment Packets are OSPF packet type 5.  To make
   the flooding of LSAs reliable, flooded LSAs are explicitly
   acknowledged.  This acknowledgment is accomplished through the
   sending and receiving of Link State Acknowledgment packets.  Multiple
   LSAs can be acknowledged in a single Link State Acknowledgment
   packet.

   Depending on the state of the sending interface and the sender of the
   corresponding Link State Update packet, a Link State Acknowledgment
   packet is sent either to the multicast address AllSPFRouters, to the
   multicast address AllDRouters, or as a unicast.  The sending of Link
   State Acknowledgment packets is documented in Section 13.5.  The
   reception of Link State Acknowledgment packets is documented in
   Section 13.7.

   The format of this packet is similar to that of the Data Description
   packet.  The body of both packets is simply a list of LSA headers.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |       5       |         Packet length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Router ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Area ID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Checksum            |             AuType            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Authentication                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Authentication                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-                         An LSA Header                       -+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-                                                             -+
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |

Top      Up      ToC       Page 173 
   Each acknowledged LSA is described by its LSA header.  The LSA header
   is documented in Section A.4.1.  It contains all the information
   required to uniquely identify both the LSA and the LSA's current
   instance.

A.4 LSA formats

   This memo defines five distinct types of LSAs.  Each LSA begins with
   a standard 20 byte LSA header.  This header is explained in Section
   A.4.1.  Succeeding sections then diagram the separate LSA types.

   Each LSA describes a piece of the OSPF routing domain.  Every router
   originates a router-LSA.  In addition, whenever the router is elected
   Designated Router, it originates a network-LSA.  Other types of LSAs
   may also be originated (see Section 12.4). All LSAs are then flooded
   throughout the OSPF routing domain.  The flooding algorithm is
   reliable, ensuring that all routers have the same collection of LSAs.
   (See Section 13 for more information concerning the flooding
   algorithm).  This collection of LSAs is called the link-state
   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      Up      ToC       Page 174 
A.4.1 The LSA header

   All LSAs begin with a common 20 byte header.  This header contains
   enough information to uniquely identify the LSA (LS type, Link State
   ID, and Advertising Router).  Multiple instances of the LSA 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 LSA 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 LSA 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 LSA.  Each LSA type has a separate advertisement
      format.  The LSA types defined in this memo are as follows (see
      Section 12.1.3 for further explanation):


        LS Type   Description
        ___________________________________
        1         Router-LSAs
        2         Network-LSAs
        3         Summary-LSAs (IP network)
        4         Summary-LSAs (ASBR)
        5         AS-external-LSAs

Top      Up      ToC       Page 175 
   Link State ID
      This field identifies the portion of the internet environment
      that is being described by the LSA.  The contents of this field
      depend on the LSA's LS type.  For example, in network-LSAs 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 LSA.  For
      example, in network-LSAs this field is equal to the Router ID of
      the network's Designated Router.

   LS sequence number
      Detects old or duplicate LSAs.  Successive instances of an LSA
      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 LSA,
      including the LSA header but excluding the LS age field. See
      Section 12.1.7 for more details.

   length
      The length in bytes of the LSA.  This includes the 20 byte LSA
      header.

Top      Up      ToC       Page 176 
A.4.2 Router-LSAs

   Router-LSAs are the Type 1 LSAs.  Each router in an area originates a
   router-LSA.  The LSA describes the state and cost of the router's
   links (i.e., interfaces) to the area.  All of the router's links to
   the area must be described in a single router-LSA. For details
   concerning the construction of router-LSAs, see Section 12.4.1.

        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    |V|E|B|        0      |            # links            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Link ID                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Link Data                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |     # TOS     |            metric             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      TOS      |        0      |          TOS  metric          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Link ID                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Link Data                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |


   In router-LSAs, the Link State ID field is set to the router's OSPF
   Router ID. Router-LSAs are flooded throughout a single area only.

   bit V
      When set, the router is an endpoint of one or more fully adjacent
      virtual links having the described area as Transit area (V is for
      virtual link endpoint).

Top      Up      ToC       Page 177 
   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 in this LSA.  This must be
      the total collection of router links (i.e., interfaces) to the
      area.

   The following fields are used to describe each router link (i.e.,
   interface). 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
   Link Data field. For links to stub networks this field specifies the
   network's IP address mask.  For other link types the Link Data field
   specifies the router interface's IP address.

   Type
      A quick description of the router link.  One of the following.
      Note that host routes are classified as links to stub networks
      with network mask of 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 an LSA (i.e., another router or a transit
      network) the Link ID is equal to the neighboring LSA's Link
      State ID.  This provides the key for looking up the neighboring
      LSA in the link state database during the routing table
      calculation. See Section 12.2 for more details.

Top      Up      ToC       Page 178 
       Type   Link ID
       ______________________________________
       1      Neighboring router's Router ID
       2      IP address of Designated Router
       3      IP network/subnet number
       4      Neighboring router's Router ID

   Link Data
      Value again depends on the link's Type field. For connections to
      stub networks, Link Data specifies the network's IP address
      mask. For unnumbered point-to-point connections, it specifies
      the interface's MIB-II [Ref8] ifIndex value. For the other link
      types it specifies the router interface's IP 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.

   # TOS
      The number of different TOS metrics given for this link, not
      counting the required link metric (referred to as the TOS 0
      metric in [Ref9]).  For example, if no additional TOS metrics
      are given, this field is set to 0.

   metric
      The cost of using this router link.

   Additional TOS-specific information may also be included, for
   backward compatibility with previous versions of the OSPF
   specification ([Ref9]). Within each link, and for each desired TOS,
   TOS TOS-specific link information may be encoded as follows:

   TOS IP  Type of Service that this metric refers to. The encoding of
      TOS in OSPF LSAs is described in Section 12.3.

   TOS metric
      TOS-specific metric information.

Top      Up      ToC       Page 179 
A.4.3 Network-LSAs

   Network-LSAs are the Type 2 LSAs.  A network-LSA is originated for
   each broadcast and NBMA network in the area which supports two or
   more routers.  The network-LSA is originated by the network's
   Designated Router. The LSA describes all routers attached to the
   network, including the Designated Router itself.  The LSA'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.  This
   is why metric fields need not be specified in the network-LSA.  For
   details concerning the construction of network-LSAs, 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 LSA header's length field.

Top      Up      ToC       Page 180 
A.4.4 Summary-LSAs

   Summary-LSAs are the Type 3 and 4 LSAs.  These LSAs are originated by
   area border routers. Summary-LSAs describe inter-area destinations.
   For details concerning the construction of summary-LSAs, see Section
   12.4.3.

   Type 3 summary-LSAs are used when the destination is an IP network.
   In this case the LSA's Link State ID field is an IP network number
   (if necessary, the Link State ID can also have one or more of the
   network's "host" bits set; see Appendix E for details). When the
   destination is an AS boundary router, a Type 4 summary-LSA 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 summary-LSAs is identical.

        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                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      0        |                  metric                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     TOS       |                TOS  metric                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |


   For stub areas, Type 3 summary-LSAs 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 summary-LSA's Link State ID
   is always set to DefaultDestination (0.0.0.0) and the Network Mask is
   set to 0.0.0.0.

Top      Up      ToC       Page 181 
   Network Mask
      For Type 3 summary-LSAs, this indicates the destination network's
      IP address 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 summary-LSAs.

   metric
      The cost of this route.  Expressed in the same units as the
      interface costs in the router-LSAs.

   Additional TOS-specific information may also be included, for
   backward compatibility with previous versions of the OSPF
   specification ([Ref9]). For each desired TOS, TOS-specific
   information is encoded as follows:

   TOS IP Type of Service that this metric refers to. The encoding of
      TOS in OSPF LSAs is described in Section 12.3.

   TOS metric
      TOS-specific metric information.

Top      Up      ToC       Page 182 
A.4.5 AS-external-LSAs

   AS-external-LSAs are the Type 5 LSAs.  These LSAs are originated by
   AS boundary routers, and describe destinations external to the AS.
   For details concerning the construction of AS-external-LSAs, see
   Section 12.4.3.

   AS-external-LSAs usually describe a particular external destination.
   For these LSAs the Link State ID field specifies an IP network number
   (if necessary, the Link State ID can also have one or more of the
   network's "host" bits set; see Appendix E for details).  AS-
   external-LSAs 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.

        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|     0       |                  metric                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Forwarding address                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      External Route Tag                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |E|    TOS      |                TOS  metric                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Forwarding address                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      External Route Tag                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |

Top      Up      ToC       Page 183 
   Network Mask
      The IP address mask for the advertised destination.  For
      example, when advertising a class A network the mask 0xff000000
      would be used.

   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 it is expressed in the same units as the link state metric
      (i.e., the same units as interface cost).

   metric
      The cost of this route.  Interpretation depends on the external
      type indication (bit E above).

   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 LSA's originator (i.e.,
      the responsible AS boundary router).

   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.

   Additional TOS-specific information may also be included, for
   backward compatibility with previous versions of the OSPF
   specification ([Ref9]). For each desired TOS, TOS-specific
   information is encoded as follows:

   TOS The Type of Service that the following fields concern. The
      encoding of TOS in OSPF LSAs is described in Section 12.3.

   bit E
      For backward-compatibility with [Ref9].

   TOS metric
      TOS-specific metric information.

   Forwarding address
      For backward-compatibility with [Ref9].

   External Route Tag
      For backward-compatibility with [Ref9].

Top      Up      ToC       Page 184 
B. Architectural Constants

   Several OSPF protocol parameters have fixed architectural values.
   These parameters have been referred to in the text by names such as
   LSRefreshTime.  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
      LSA.  If the LS age field of one of the router's self-originated
      LSAs reaches the value LSRefreshTime, a new instance of the LSA is
      originated, even though the contents of the LSA (apart from the
      LSA header) will be the same.  The value of LSRefreshTime is set
      to 30 minutes.

   MinLSInterval
      The minimum time between distinct originations of any particular
      LSA.  The value of MinLSInterval is set to 5 seconds.

   MinLSArrival
      For any particular LSA, the minimum time that must elapse
      between reception of new LSA instances during flooding. LSA
      instances received at higher frequencies are discarded. The value
      of MinLSArrival is set to 1 second.

   MaxAge
      The maximum age that an LSA can attain. When an LSA's LS age field
      reaches MaxAge, it is reflooded in an attempt to flush the LSA
      from the routing domain (See Section 14). LSAs of age MaxAge are
      not used in the routing table calculation.  The value of MaxAge is
      set to 1 hour.

   CheckAge
      When the age of an LSA in the link state database hits a multiple
      of CheckAge, the LSA'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 an LSA is flooded
      throughout the AS.  Most of this time is accounted for by the LSAs
      sitting on router output queues (and therefore not aging) during
      the flooding process.  The value of MaxAgeDiff is set to 15
      minutes.

Top      Up      ToC       Page 185 
   LSInfinity
      The metric value indicating that the destination described by an
      LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as
      an alternative to premature aging (see Section 14.1). It is
      defined to be the 24-bit binary value of all ones: 0xffffff.

   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-
      LSAs and in stub areas' type 3 summary-LSAs.  Its value is the IP
      address 0.0.0.0. Its associated Network Mask is also always
      0.0.0.0.

   InitialSequenceNumber
      The value used for LS Sequence Number when originating the first
      instance of any LSA. Its value is the signed 32-bit integer
      0x80000001.

   MaxSequenceNumber
      The maximum value that LS Sequence Number can attain.  Its value
      is the signed 32-bit integer 0x7fffffff.

Top      Up      ToC       Page 186 
C. Configurable Constants

   The OSPF protocol has quite a few configurable parameters. These
   parameters are listed below.  They are grouped into general
   functional categories (area parameters, interface parameters, etc.).
   Sample values are given for some of the parameters.

   Some parameter settings need to be consistent among groups of
   routers.  For example, all routers in an area must agree on that
   area's parameters, and all routers attached to a network must agree
   on that network's IP network number and mask.

   Some parameters may be determined by router algorithms outside of
   this specification (e.g., the address of a host connected to the
   router via a SLIP line).  From OSPF's point of view, these items are
   still configurable.

C.1 Global parameters

   In general, a separate copy of the OSPF protocol is run for each
   area.  Because of this, most configuration parameters are defined on
   a per-area basis.  The few global configuration parameters are listed
   below.

   Router ID
       This is a 32-bit number that uniquely identifies the router in
       the Autonomous System.  One algorithm for Router ID assignment is
       to choose the largest or smallest IP address assigned to the
       router.  If a router's OSPF Router ID is changed, the router's
       OSPF software should be restarted before the new Router ID takes
       effect. Before restarting in order to change its Router ID, the
       router should flush its self-originated LSAs from the routing
       domain (see Section 14.1), or they will persist for up to MaxAge
       minutes.

   RFC1583Compatibility
       Controls the preference rules used in Section 16.4 when choosing
       among multiple AS-external-LSAs advertising the same destination.
       When set to "enabled", the preference rules remain those
       specified by RFC 1583 ([Ref9]). When set to "disabled", the
       preference rules are those stated in Section 16.4.1, which
       prevent routing loops when AS- external-LSAs for the same
       destination have been originated from different areas (see
       Section G.7). Set to "enabled" by default.

Top      Up      ToC       Page 187 
       In order to minimize the chance of routing loops, all OSPF
       routers in an OSPF routing domain should have
       RFC1583Compatibility set identically. When there are routers
       present that have not been updated with the functionality
       specified in Section 16.4.1 of this memo, all routers should have
       RFC1583Compatibility set to "enabled". Otherwise, all routers
       should have RFC1583Compatibility set to "disabled", preventing
       all routing loops.

C.2 Area parameters

   All routers belonging to an area must agree on that area's
   configuration.  Disagreements between two routers will lead to an
   inability for adjacencies to form between them, with a resulting
   hindrance to the flow of routing protocol and data traffic.  The
   following items must be configured for an area:

   Area ID
       This is a 32-bit number that identifies the area.  The Area ID of
       0.0.0.0 is reserved for the backbone.  If the area represents a
       subnetted network, the IP network number of the subnetted network
       may be used for the Area ID.

   List of address ranges
       An OSPF area is defined as a list of address ranges. Each address
       range consists of the following items:

       [IP address, mask]
           Describes the collection of IP addresses contained in the
           address range. Networks and hosts are assigned to an area
           depending on whether their addresses fall into one of the
           area's defining address ranges.  Routers are viewed as
           belonging to multiple areas, depending on their attached
           networks' area membership.

       Status  Set to either Advertise or DoNotAdvertise. Routing
           information is condensed at area boundaries.  External to the
           area, at most a single route is advertised (via a summary-
           LSA) for each address range. The route is advertised if and
           only if the address range's Status is set to Advertise.
           Unadvertised ranges allow the existence of certain networks
           to be intentionally hidden from other areas. Status is set to
           Advertise by default.

Top      Up      ToC       Page 188 
           As an example, suppose an IP subnetted network is to be its
           own OSPF area.  The area would be configured as a single
           address range, whose IP address is the address of the
           subnetted network, and whose mask is the natural class A, B,
           or C address mask. A single route would be advertised
           external to the area, describing the entire subnetted
           network.

       ExternalRoutingCapability
           Whether AS-external-LSAs will be flooded into/throughout the
           area.  If AS-external-LSAs are excluded from the area, the
           area is called a "stub".  Internal to stub areas, routing to
           external destinations will be based solely on a default
           summary route.  The backbone cannot be configured as a stub
           area.  Also, virtual links cannot be configured through stub
           areas.  For more information, see Section 3.6.

       StubDefaultCost
           If the area has been configured as a stub area, and the
           router itself is an area border router, then the
           StubDefaultCost indicates the cost of the default summary-LSA
           that the router should advertise into the area.

C.3 Router interface parameters

   Some of the configurable router interface parameters (such as IP
   interface address and subnet mask) actually imply properties of the
   attached networks, and therefore must be consistent across all the
   routers attached to that network.  The parameters that must be
   configured for a router interface are:

   IP interface address
       The IP protocol address for this interface.  This uniquely
       identifies the router over the entire internet.  An IP address is
       not required on point-to-point networks.  Such a point-to-point
       network is called "unnumbered".

   IP interface mask
       Also referred to as the subnet/network mask, this indicates the
       portion of the IP interface address that identifies the attached
       network.  Masking the IP interface address with the IP interface
       mask yields the IP network number of the attached network.  On
       point-to-point networks and virtual links, the IP interface mask
       is not defined. On these networks, the link itself is not
       assigned an IP network number, and so the addresses of each side
       of the link are assigned independently, if they are assigned at
       all.

Top      Up      ToC       Page 189 
   Area ID
       The OSPF area to which the attached network belongs.

   Interface output cost
       The cost of sending a packet on the interface, expressed in the
       link state metric.  This is advertised as the link cost for this
       interface in the router's router-LSA. The interface output cost
       must always be greater than 0.

   RxmtInterval
       The number of seconds between LSA retransmissions, for
       adjacencies belonging to this interface.  Also used when
       retransmitting Database Description and Link State Request
       Packets.  This should be well over the expected round-trip delay
       between any two routers on the attached network.  The setting of
       this value should be conservative or needless retransmissions
       will result.  Sample value for a local area network: 5 seconds.

   InfTransDelay
       The estimated number of seconds it takes to transmit a Link State
       Update Packet over this interface.  LSAs contained in the update
       packet must have their age incremented by this amount before
       transmission.  This value should take into account the
       transmission and propagation delays of the interface. It must be
       greater than 0.  Sample value for a local area network: 1 second.

   Router Priority
       An 8-bit unsigned integer. When two routers attached to a network
       both attempt to become Designated Router, the one with the
       highest Router Priority takes precedence. If there is still a
       tie, the router with the highest Router ID takes precedence.  A
       router whose Router Priority is set to 0 is ineligible to become
       Designated Router on the attached network.  Router Priority is
       only configured for interfaces to broadcast and NBMA networks.

   HelloInterval
       The length of time, in seconds, between the Hello Packets that
       the router sends on the interface.  This value is advertised in
       the router's Hello Packets.  It must be the same for all routers
       attached to a common network. The smaller the HelloInterval, the
       faster topological changes will be detected; however, more OSPF
       routing protocol traffic will ensue.  Sample value for a X.25 PDN
       network: 30 seconds.  Sample value for a local area network: 10
       seconds.

Top      Up      ToC       Page 190 
   RouterDeadInterval
       After ceasing to hear a router's Hello Packets, the number of
       seconds before its neighbors declare the router down.  This is
       also advertised in the router's Hello Packets in their
       RouterDeadInterval field.  This should be some multiple of the
       HelloInterval (say 4).  This value again must be the same for all
       routers attached to a common network.

   AuType
       Identifies the authentication procedure to be used on the
       attached network.  This value must be the same for all routers
       attached to the network.  See Appendix D for a discussion of the
       defined authentication types.

   Authentication key
       This configured data allows the authentication procedure to
       verify OSPF protocol packets received over the interface.  For
       example, if the AuType indicates simple password, the
       Authentication key would be a clear 64-bit password.
       Authentication keys associated with the other OSPF authentication
       types are discussed in Appendix D.

C.4 Virtual link parameters

   Virtual links are used to restore/increase connectivity of the
   backbone.  Virtual links may be configured between any pair of area
   border routers having interfaces to a common (non-backbone) area.
   The virtual link appears as an unnumbered point-to-point link in the
   graph for the backbone.  The virtual link must be configured in both
   of the area border routers.

   A virtual link appears in router-LSAs (for the backbone) as if it
   were a separate router interface to the backbone.  As such, it has
   all of the parameters associated with a router interface (see Section
   C.3).  Although a virtual link acts like an unnumbered point-to-point
   link, it does have an associated IP interface address.  This address
   is used as the IP source in OSPF protocol packets it sends along the
   virtual link, and is set dynamically during the routing table build
   process.  Interface output cost is also set dynamically on virtual
   links to be the cost of the intra-area path between the two routers.
   The parameter RxmtInterval must be configured, and should be well
   over the expected round-trip delay between the two routers.  This may
   be hard to estimate for a virtual link; it is better to err on the
   side of making it too large.  Router Priority is not used on virtual
   links.

Top      Up      ToC       Page 191 
   A virtual link is defined by the following two configurable
   parameters: the Router ID of the virtual link's other endpoint, and
   the (non-backbone) area through which the virtual link runs (referred
   to as the virtual link's Transit area).  Virtual links cannot be
   configured through stub areas.

C.5 NBMA network parameters

   OSPF treats an NBMA network much like it treats a broadcast network.
   Since there may be many routers attached to the network, a Designated
   Router is selected for the network.  This Designated Router then
   originates a network-LSA, which lists all routers attached to the
   NBMA network.

   However, due to the lack of broadcast capabilities, it may be
   necessary to use configuration parameters in the Designated Router
   selection.  These parameters will only need to be configured in those
   routers that are themselves eligible to become Designated Router
   (i.e., those router's whose Router Priority for the network is non-
   zero), and then only if no automatic procedure for discovering
   neighbors exists:

   List of all other attached routers
       The list of all other routers attached to the NBMA network.  Each
       router is listed by its IP interface address on the network.
       Also, for each router listed, that router's eligibility to become
       Designated Router must be defined.  When an interface to a NBMA
       network comes up, the router sends Hello Packets only to those
       neighbors eligible to become Designated Router, until the
       identity of the Designated Router is discovered.

   PollInterval
       If a neighboring router has become inactive (Hello Packets have
       not been seen for RouterDeadInterval seconds), it may still be
       necessary to send Hello Packets to the dead neighbor.  These
       Hello Packets will be sent at the reduced rate PollInterval,
       which should be much larger than HelloInterval.  Sample value for
       a PDN X.25 network: 2 minutes.

C.6 Point-to-MultiPoint network parameters

   On Point-to-MultiPoint networks, it may be necessary to configure the
   set of neighbors that are directly reachable over the Point-to-
   MultiPoint network. Each neighbor is identified by its IP address on
   the Point-to-MultiPoint network. Designated Routers are not elected
   on Point-to-MultiPoint networks, so the Designated Router eligibility
   of configured neighbors is undefined.

Top      Up      ToC       Page 192 
   Alternatively, neighbors on Point-to-MultiPoint networks may be
   dynamically discovered by lower-level protocols such as Inverse ARP
   ([Ref14]).

C.7 Host route parameters

   Host routes are advertised in router-LSAs as stub networks with mask
   0xffffffff.  They indicate either router interfaces to point-to-point
   networks, looped router interfaces, or IP hosts that are directly
   connected to the router (e.g., via a SLIP line). For each host
   directly connected to the router, the following items must be
   configured:

   Host IP address
       The IP address of the host.

   Cost of link to host
       The cost of sending a packet to the host, in terms of the link
       state metric. However, since the host probably has only a single
       connection to the internet, the actual configured cost in many
       cases is unimportant (i.e., will have no effect on routing).

   Area ID
       The OSPF area to which the host belongs.

Top      Up      ToC       Page 193 
D. Authentication

   All OSPF protocol exchanges are authenticated.  The OSPF packet
   header (see Section A.3.1) includes an authentication type field, and
   64-bits of data for use by the appropriate authentication scheme
   (determined by the type field).

   The authentication type is configurable on a per-interface (or
   equivalently, on a per-network/subnet) basis.  Additional
   authentication data is also configurable on a per-interface basis.

   Authentication types 0, 1 and 2 are defined by this specification.
   All other authentication types are reserved for definition by the
   IANA (iana@ISI.EDU).  The current list of authentication types is
   described below in Table 20.

          AuType       Description
          ___________________________________________
          0            Null authentication
          1            Simple password
          2            Cryptographic authentication
          All others   Reserved for assignment by the
                       IANA (iana@ISI.EDU)


                  Table 20: OSPF authentication types.


D.1 Null authentication

   Use of this authentication type means that routing exchanges over the
   network/subnet are not authenticated. The 64-bit authentication field
   in the OSPF header can contain anything; it is not examined on packet
   reception. When employing Null authentication, the entire contents of
   each OSPF packet (other than the 64-bit authentication field) are
   checksummed in order to detect data corruption.

D.2 Simple password authentication

   Using this authentication type, a 64-bit field is configured on a
   per-network basis.  All packets sent on a particular network must
   have this configured value in their OSPF header 64-bit authentication
   field.  This essentially serves as a "clear" 64- bit password. In
   addition, the entire contents of each OSPF packet (other than the
   64-bit authentication field) are checksummed in order to detect data
   corruption.

Top      Up      ToC       Page 194 
   Simple password authentication guards against routers inadvertently
   joining the routing domain; each router must first be configured with
   its attached networks' passwords before it can participate in
   routing.  However, simple password authentication is vulnerable to
   passive attacks currently widespread in the Internet (see [Ref16]).
   Anyone with physical access to the network can learn the password and
   compromise the security of the OSPF routing domain.

D.3 Cryptographic authentication

   Using this authentication type, a shared secret key is configured in
   all routers attached to a common network/subnet.  For each OSPF
   protocol packet, the key is used to generate/verify a "message
   digest" that is appended to the end of the OSPF packet. The message
   digest is a one-way function of the OSPF protocol packet and the
   secret key. Since the secret key is never sent over the network in
   the clear, protection is provided against passive attacks.

   The algorithms used to generate and verify the message digest are
   specified implicitly by the secret key. This specification completely
   defines the use of OSPF Cryptographic authentication when the MD5
   algorithm is used.

   In addition, a non-decreasing sequence number is included in each
   OSPF protocol packet to protect against replay attacks.  This
   provides long term protection; however, it is still possible to
   replay an OSPF packet until the sequence number changes. To implement
   this feature, each neighbor data structure

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              0                |    Key ID     | Auth Data Len |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Cryptographic sequence number                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 18: Usage of the Authentication field
              in the OSPF packet header when Cryptographic
                       Authentication is employed

   contains a new field called the "cryptographic sequence number".
   This field is initialized to zero, and is also set to zero whenever
   the neighbor's state transitions to "Down". Whenever an OSPF packet
   is accepted as authentic, the cryptographic sequence number is set to
   the received packet's sequence number.

Top      Up      ToC       Page 195 
   This specification does not provide a rollover procedure for the
   cryptographic sequence number. When the cryptographic sequence number
   that the router is sending hits the maximum value, the router should
   reset the cryptographic sequence number that it is sending back to 0.
   After this is done, the router's neighbors will reject the router's
   OSPF packets for a period of RouterDeadInterval, and then the router
   will be forced to reestablish all adjacencies over the interface.
   However, it is expected that many implementations will use "seconds
   since reboot" (or "seconds since 1960", etc.) as the cryptographic
   sequence number. Such a choice will essentially prevent rollover,
   since the cryptographic sequence number field is 32 bits in length.

   The OSPF Cryptographic authentication option does not provide
   confidentiality.

   When cryptographic authentication is used, the 64-bit Authentication
   field in the standard OSPF packet header is redefined as shown in
   Figure 18. The new field definitions are as follows:

   Key ID
       This field identifies the algorithm and secret key used to create
       the message digest appended to the OSPF packet. Key Identifiers
       are unique per-interface (or equivalently, per- subnet).

   Auth Data Len
       The length in bytes of the message digest appended to the OSPF
       packet.

   Cryptographic sequence number
       An unsigned 32-bit non-decreasing sequence number. Used to guard
       against replay attacks.

   The message digest appended to the OSPF packet is not actually
   considered part of the OSPF protocol packet: the message digest is
   not included in the OSPF header's packet length, although it is
   included in the packet's IP header length field.

   Each key is identified by the combination of interface and Key ID. An
   interface may have multiple keys active at any one time.  This
   enables smooth transition from one key to another. Each key has four
   time constants associated with it. These time constants can be
   expressed in terms of a time-of-day clock, or in terms of a router's
   local clock (e.g., number of seconds since last reboot):

   KeyStartAccept
       The time that the router will start accepting packets that
       have been created with the given key.

Top      Up      ToC       Page 196 
   KeyStartGenerate
       The time that the router will start using the key for packet
       generation.

   KeyStopGenerate
       The time that the router will stop using the key for packet
       generation.

   KeyStopAccept
       The time that the router will stop accepting packets that
       have been created with the given key.

   In order to achieve smooth key transition, KeyStartAccept should be
   less than KeyStartGenerate and KeyStopGenerate should be less than
   KeyStopAccept. If KeyStopGenerate and KeyStopAccept are left
   unspecified, the key's lifetime is infinite. When a new key replaces
   an old, the KeyStartGenerate time for the new key must be less than
   or equal to the KeyStopGenerate time of the old key.

   Key storage should persist across a system restart, warm or cold, to
   avoid operational issues. In the event that the last key associated
   with an interface expires, it is unacceptable to revert to an
   unauthenticated condition, and not advisable to disrupt routing.
   Therefore, the router should send a "last authentication key
   expiration" notification to the network manager and treat the key as
   having an infinite lifetime until the lifetime is extended, the key
   is deleted by network management, or a new key is configured.

D.4 Message generation

   After building the contents of an OSPF packet, the authentication
   procedure indicated by the sending interface's Autype value is called
   before the packet is sent. The authentication procedure modifies the
   OSPF packet as follows.

D.4.1 Generating Null authentication

   When using Null authentication, the packet is modified as follows:

   (1) The Autype field in the standard OSPF header is set to
       0.

Top      Up      ToC       Page 197 
   (2) The checksum field in the standard OSPF header is set to
       the standard IP checksum of the entire contents of the packet,
       starting with the OSPF packet header but excluding the 64-bit
       authentication field.  This checksum is calculated as the 16-bit
       one's complement of the one's complement sum of all the 16-bit
       words in the packet, excepting the authentication field.  If the
       packet's length is not an integral number of 16-bit words, the
       packet is padded with a byte of zero before checksumming.

D.4.2 Generating Simple password authentication

   When using Simple password authentication, the packet is modified as
   follows:

   (1) The Autype field in the standard OSPF header is set to 1.

   (2) The checksum field in the standard OSPF header is set to the
       standard IP checksum of the entire contents of the packet,
       starting with the OSPF packet header but excluding the 64-bit
       authentication field.  This checksum is calculated as the 16-bit
       one's complement of the one's complement sum of all the 16-bit
       words in the packet, excepting the authentication field.  If the
       packet's length is not an integral number of 16-bit words, the
       packet is padded with a byte of zero before checksumming.

   (3) The 64-bit authentication field in the OSPF packet header
       is set to the 64-bit password (i.e., authentication key) that has
       been configured for the interface.

D.4.3 Generating Cryptographic authentication

   When using Cryptographic authentication, there may be multiple keys
   configured for the interface. In this case, among the keys that are
   valid for message generation (i.e, that have KeyStartGenerate <=
   current time < KeyStopGenerate) choose the one with the most recent
   KeyStartGenerate time. Using this key, modify the packet as follows:

   (1) The Autype field in the standard OSPF header is set to
       2.

   (2) The checksum field in the standard OSPF header is not
       calculated, but is instead set to 0.

   (3) The Key ID (see Figure 18) is set to the chosen key's
       Key ID.

Top      Up      ToC       Page 198 
   (4) The Auth Data Len field is set to the length in bytes of
       the message digest that will be appended to the OSPF packet. When
       using MD5 as the authentication algorithm, Auth Data Len will be
       16.

   (5) The 32-bit Cryptographic sequence number (see Figure 18)
       is set to a non-decreasing value (i.e., a value at least as large
       as the last value sent out the interface).  The precise values to
       use in the cryptographic sequence number field are
       implementation-specific.  For example, it may be based on a
       simple counter, or be based on the system's clock.

   (6) The message digest is then calculated and appended to
       the OSPF packet.  The authentication algorithm to be used in
       calculating the digest is indicated by the key itself.  Input to
       the authentication algorithm consists of the OSPF packet and the
       secret key. When using MD5 as the authentication algorithm, the
       message digest calculation proceeds as follows:

          (a) The 16 byte MD5 key is appended to the OSPF packet.

          (b) Trailing pad and length fields are added, as specified in
              [Ref17].

          (c) The MD5 authentication algorithm is run over the
              concatenation of the OSPF packet, secret key, pad and
              length fields, producing a 16 byte message digest (see
              [Ref17]).

          (d) The MD5 digest is written over the OSPF key (i.e.,
              appended to the original OSPF packet). The digest is not
              counted in the OSPF packet's length field, but is included
              in the packet's IP length field. Any trailing pad or
              length fields beyond the digest are not counted or
              transmitted.

D.5 Message verification

   When an OSPF packet has been received on an interface, it must be
   authenticated. The authentication procedure is indicated by the
   setting of Autype in the standard OSPF packet header, which matches
   the setting of Autype for the receiving OSPF interface.

   If an OSPF protocol packet is accepted as authentic, processing of
   the packet continues as specified in Section 8.2. Packets which fail
   authentication are discarded.

Top      Up      ToC       Page 199 
D.5.1 Verifying Null authentication

   When using Null authentication, the checksum field in the OSPF header
   must be verified. It must be set to 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.)

D.5.2 Verifying Simple password authentication

   When using Simple password authentication, the received OSPF packet
   is authenticated as follows:

       (1) The checksum field in the OSPF header must be verified.
           It must be set to 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.)

       (2) The 64-bit authentication field in the OSPF packet
           header must be equal to the 64-bit password (i.e.,
           authentication key) that has been configured for the
           interface.

D.5.3 Verifying Cryptographic authentication

   When using Cryptographic authentication, the received OSPF packet is
   authenticated as follows:

       (1) Locate the receiving interface's configured key having
           Key ID equal to that specified in the received OSPF
           packet (see Figure 18). If the key is not found, or if
           the key is not valid for reception (i.e., current time <
           KeyStartAccept or current time >= KeyStopAccept), the
           OSPF packet is discarded.

       (2) If the cryptographic sequence number found in the OSPF
           header (see Figure 18) is less than the cryptographic
           sequence number recorded in the sending neighbor's data
           structure, the OSPF packet is discarded.

       (3) Verify the appended message digest in the following
           steps:

      (a) The received digest is set aside.

Top      Up      ToC       Page 200 
      (b) A new digest is calculated, as specified in Step 6
          of Section D.4.3.

      (c) The calculated and received digests are compared. If
          they do not match, the OSPF packet is discarded. If
          they do match, the OSPF protocol packet is accepted
          as authentic, and the "cryptographic sequence
          number" in the neighbor's data structure is set to
          the sequence number found in the packet's OSPF
          header.


Next RFC Part