Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2178

OSPF Version 2

Pages: 211
Obsoletes:  1583
Obsoleted by:  2328
Part 5 of 8 – Pages 107 to 137
First   Prev   Next

ToP   noToC   RFC2178 - Page 107   prevText
12.4.  Originating LSAs

   Into any given OSPF area, a router will originate several LSAs.  Each
   router originates a router-LSA.  If the router is also the Designated
   Router for any of the area's networks, it will originate network-LSAs
   for those networks.

   Area border routers originate a single summary-LSA for each known
   inter-area destination.  AS boundary routers originate a single AS-
   external-LSA for each known AS external destination.  Destinations
   are advertised one at a time so that the change in any single route
   can be flooded without reflooding the entire collection of routes.
   During the flooding procedure, many LSAs can be carried by a single
   Link State Update packet.

   As an example, consider Router RT4 in Figure 6.  It is an area border
   router, having a connection to Area 1 and the backbone.  Router RT4
   originates 5 distinct LSAs into the backbone (one router-LSA, and one
   summary-LSA for each of the networks N1-N4).  Router RT4 will also
   originate 8 distinct LSAs into Area 1 (one router-LSA and seven
   summary-LSAs as pictured in Figure 7).  If RT4 has been selected as
   Designated Router for Network N3, it will also originate a network-
   LSA for N3 into Area 1.

   In this same figure, Router RT5 will be originating 3 distinct AS-
   external-LSAs (one for each of the networks N12-N14).  These will be
   flooded throughout the entire AS, assuming that none of the areas
ToP   noToC   RFC2178 - Page 108
   have been configured as stubs.  However, if area 3 has been
   configured as a stub area, the AS-external-LSAs for networks N12-N14
   will not be flooded into area 3 (see Section 3.6).  Instead, Router
   RT11 would originate a default summary- LSA that would be flooded
   throughout area 3 (see Section 12.4.3).  This instructs all of area
   3's internal routers to send their AS external traffic to RT11.

   Whenever a new instance of an LSA is originated, its LS sequence
   number is incremented, its LS age is set to 0, its LS checksum is
   calculated, and the LSA is added to the link state database and
   flooded out the appropriate interfaces.  See Section 13.2 for details
   concerning the installation of the LSA into the link state database.
   See Section 13.3 for details concerning the flooding of newly
   originated LSAs.

   The ten events that can cause a new instance of an LSA to be
   originated are:

   (1) The LS age field of one of the router's self-originated LSAs
       reaches the value LSRefreshTime. In this case, a new
       instance of the LSA is originated, even though the contents
       of the LSA (apart from the LSA header) will be the same.
       This guarantees periodic originations of all LSAs.  This
       periodic updating of LSAs adds robustness to the link state
       algorithm.  LSAs that solely describe unreachable
       destinations should not be refreshed, but should instead be
       flushed from the routing domain (see Section 14.1).

   When whatever is being described by an LSA changes, a new LSA is
   originated.  However, two instances of the same LSA may not be
   originated within the time period MinLSInterval.  This may require
   that the generation of the next instance be delayed by up to
   MinLSInterval.  The following events may cause the contents of an LSA
   to change.  These events should cause new originations if and only if
   the contents of the new LSA would be different:

   (2) An interface's state changes (see Section 9.1).  This may
       mean that it is necessary to produce a new instance of the
       router-LSA.

   (3) An attached network's Designated Router changes.  A new
       router-LSA should be originated.  Also, if the router itself
       is now the Designated Router, a new network-LSA should be
       produced.  If the router itself is no longer the Designated
       Router, any network-LSA that it might have originated for
       the network should be flushed from the routing domain (see
       Section 14.1).
ToP   noToC   RFC2178 - Page 109
   (4) One of the neighboring routers changes to/from the FULL
       state.  This may mean that it is necessary to produce a new
       instance of the router-LSA.  Also, if the router is itself
       the Designated Router for the attached network, a new
       network-LSA should be produced.

   The next four events concern area border routers only:

   (5) An intra-area route has been added/deleted/modified in the
       routing table.  This may cause a new instance of a summary-
       LSA (for this route) to be originated in each attached area
       (possibly including the backbone).

   (6) An inter-area route has been added/deleted/modified in the
       routing table.  This may cause a new instance of a summary-
       LSA (for this route) to be originated in each attached area
       (but NEVER for the backbone).

   (7) The router becomes newly attached to an area.  The router
       must then originate summary-LSAs into the newly attached
       area for all pertinent intra-area and inter-area routes in
       the router's routing table.  See Section 12.4.3 for more
       details.

   (8) When the state of one of the router's configured virtual
       links changes, it may be necessary to originate a new
       router-LSA into the virtual link's Transit area (see the
       discussion of the router-LSA's bit V in Section 12.4.1), as
       well as originating a new router-LSA into the backbone.

   The last two events concern AS boundary routers (and former AS
   boundary routers) only:

   (9) An external route gained through direct experience with an
       external routing protocol (like BGP) changes.  This will
       cause an AS boundary router to originate a new instance of
       an AS-external-LSA.

   (10)
       A router ceases to be an AS boundary router, perhaps after
       restarting. In this situation the router should flush all
       AS-external-LSAs that it had previously originated.  These
       LSAs can be flushed via the premature aging procedure
       specified in Section 14.1.
ToP   noToC   RFC2178 - Page 110
   The construction of each type of LSA is explained in detail below. In
   general, these sections describe the contents of the LSA body (i.e.,
   the part coming after the 20-byte LSA header).  For information
   concerning the building of the LSA header, see Section 12.1.

12.4.1.  Router-LSAs

   A router originates a router-LSA for each area that it belongs to.
   Such an LSA describes the collected states of the router's links to
   the area.  The LSA is flooded throughout the particular area, and no
   further.  The format of a router-LSA is shown in Appendix A (Section
   A.4.2).  The first 20 bytes of the LSA consist of the generic LSA
   header that was discussed in Section 12.1.  router-LSAs have LS type
   = 1.

   A router also indicates whether it is an area border router, or an AS
   boundary router, by setting the appropriate bits

                  ....................................
                  . 192.1.2                   Area 1 .
                  .     +                            .
                  .     |                            .
                  .     | 3+---+1                    .
                  .  N1 |--|RT1|-----+               .
                  .     |  +---+      \              .
                  .     |              \  _______N3  .
                  .     +               \/       \   .  1+---+
                  .                     * 192.1.1 *------|RT4|
                  .     +               /\_______/   .   +---+
                  .     |              /     |       .
                  .     | 3+---+1     /      |       .
                  .  N2 |--|RT2|-----+      1|       .
                  .     |  +---+           +---+8    .         6+---+
                  .     |                  |RT3|----------------|RT6|
                  .     +                  +---+     .          +---+
                  . 192.1.3                  |2      .   18.10.0.6|7
                  .                          |       .            |
                  .                   +------------+ .
                  .                     192.1.4 (N4) .
                  ....................................

               Figure 15: Area 1 with IP addresses shown

   (bit B and bit E, respectively) in its router-LSAs. This enables
   paths to those types of routers to be saved in the routing table, for
   later processing of summary-LSAs and AS-external-LSAs.  Bit B should
   be set whenever the router is actively attached to two or more areas,
   even if the router is not currently attached to the OSPF backbone
ToP   noToC   RFC2178 - Page 111
   area.  Bit E should never be set in a router-LSA for a stub area
   (stub areas cannot contain AS boundary routers).

   In addition, the router sets bit V in its router-LSA for Area A if
   and only if the router is the endpoint of one or more fully adjacent
   virtual links having Area A as their Transit area. The setting of bit
   V enables other routers in Area A to discover whether the area
   supports transit traffic (see TransitCapability in Section 6).

   The router-LSA then describes the router's working connections (i.e.,
   interfaces or links) to the area.  Each link is typed according to
   the kind of attached network.  Each link is also labelled with its
   Link ID.  This Link ID gives a name to the entity that is on the
   other end of the link.  Table 18 summarizes the values used for the
   Type and Link ID fields.

           Link type   Description       Link ID
           __________________________________________________
           1           Point-to-point    Neighbor Router ID
                       link
           2           Link to transit   Interface address of
                       network           Designated Router
           3           Link to stub      IP network number
                       network
           4           Virtual link      Neighbor Router ID

                   Table 18: Link descriptions in the
                              router-LSA.

   In addition, the Link Data field is specified for each link.  This
   field gives 32 bits of extra information for the link.  For links to
   transit networks, numbered point-to-point links and virtual links,
   this field specifies the IP interface address of the associated
   router interface (this is needed by the routing table calculation,
   see Section 16.1.1).  For links to stub networks, this field
   specifies the stub network's IP address mask. For unnumbered point-
   to-point links, the Link Data field should be set to the unnumbered
   interface's MIB-II [Ref8] ifIndex value.

   Finally, the cost of using the link for output is specified.  The
   output cost of a link is configurable. With the exception of links to
   stub networks, the output cost must always be non-zero.

   To further describe the process of building the list of link
   descriptions, suppose a router wishes to build a router-LSA for Area
   A.  The router examines its collection of interface data structures.
   For each interface, the following steps are taken:
ToP   noToC   RFC2178 - Page 112
   o    If the attached network does not belong to Area A, no
       links are added to the LSA, and the next interface should be
       examined.

   o    If the state of the interface is Down, no links are added.

   o    If the state of the interface is Loopback, add a Type 3
       link (stub network) as long as this is not an interface to an
       unnumbered point-to-point network.  The Link ID should be set to
       the IP interface address, the Link Data set to the
       mask 0xffffffff (indicating a host route), and the cost set to 0.

   o   Otherwise, the link descriptions added to the router-LSA
       depend on the OSPF interface type. Link descriptions used for
       point-to-point interfaces are specified in Section 12.4.1.1, for
       virtual links in Section 12.4.1.2, for broadcast and NBMA
       interfaces in 12.4.1.3, and for Point-to-MultiPoint interfaces in
       12.4.1.4.

   After consideration of all the router interfaces, host links are
   added to the router-LSA by examining the list of attached hosts
   belonging to Area A.  A host route is represented as a Type 3 link
   (stub network) whose Link ID is the host's IP address, Link Data is
   the mask of all ones (0xffffffff), and cost the host's configured
   cost (see Section C.7).

12.4.1.1.  Describing point-to-point interfaces

   For point-to-point interfaces, one or more link descriptions are
   added to the router-LSA as follows:

   o   If the neighboring router is fully adjacent, add a
       Type 1 link (point-to-point). The Link ID should be set to the
       Router ID of the neighboring router. For numbered point-to-point
       networks, the Link Data should specify the IP interface address.
       For unnumbered point-to-point networks, the Link Data field
       should specify the interface's MIB-II [Ref8] ifIndex value. The
       cost should be set to the output cost of the point-to-point
       interface.

   o   In addition, as long as the state of the interface
       is "Point-to-Point" (and regardless of the neighboring router
       state), a Type 3 link (stub network) should be added. There are
       two forms that this stub link can take:
ToP   noToC   RFC2178 - Page 113
   Option 1
      Assuming that the neighboring router's IP address is known, set
      the Link ID of the Type 3 link to the neighbor's IP address, the
      Link Data to the mask 0xffffffff (indicating a host route), and
      the cost to the interface's configured output cost.[15]

   Option 2
      If a subnet has been assigned to the point-to-point link, set the
      Link ID of the Type 3 link to the subnet's IP address, the Link
      Data to the subnet's mask, and the cost to the interface's
      configured output cost.[16]

12.4.1.2.  Describing broadcast and NBMA interfaces

   For operational broadcast and NBMA interfaces, a single link
   description is added to the router-LSA as follows:

   o   If the state of the interface is Waiting, add a Type
       3 link (stub network) with Link ID set to the IP network number
       of the attached network, Link Data set to the attached network's
       address mask, and cost equal to the interface's configured output
       cost.

   o   Else, there has been a Designated Router elected for
       the attached network.  If the router is fully adjacent to the
       Designated Router, or if the router itself is Designated Router
       and is fully adjacent to at least one other router, add a single
       Type 2 link (transit network) with Link ID set to the IP
       interface address of the attached network's Designated Router
       (which may be the router itself), Link Data set to the router's
       own IP interface address, and cost equal to the interface's
       configured output cost.  Otherwise, add a link as if the
       interface state were Waiting (see above).

12.4.1.3.  Describing virtual links

   For virtual links, a link description is added to the router-LSA only
   when the virtual neighbor is fully adjacent. In this case, add a Type
   4 link (virtual link) with Link ID set to the Router ID of the
   virtual neighbor, Link Data set to the IP interface address
   associated with the virtual link and cost set to the cost calculated
   for the virtual link during the routing table calculation (see
   Section 15).
ToP   noToC   RFC2178 - Page 114
12.4.1.4.  Describing Point-to-MultiPoint interfaces

   For operational Point-to-MultiPoint interfaces, one or more link
   descriptions are added to the router-LSA as follows:

   o   A single Type 3 link (stub network) is added with
       Link ID set to the router's own IP interface address, Link Data
       set to the mask 0xffffffff (indicating a host route), and cost
       set to 0.

   o   For each fully adjacent neighbor associated with the
       interface, add an additional Type 1 link (point-to-point) with
       Link ID set to the Router ID of the neighboring router, Link Data
       set to the IP interface address and cost equal to the interface's
       configured output cost.

12.4.1.5.  Examples of router-LSAs

   Consider the router-LSAs generated by Router RT3, as pictured in
   Figure 6.  The area containing Router RT3 (Area 1) has been redrawn,
   with actual network addresses, in Figure 15.  Assume that the last
   byte of all of RT3's interface addresses is 3, giving it the
   interface addresses 192.1.1.3 and 192.1.4.3, and that the other
   routers have similar addressing schemes.  In addition, assume that
   all links are functional, and that Router IDs are assigned as the
   smallest IP interface address.

   RT3 originates two router-LSAs, one for Area 1 and one for the
   backbone.  Assume that Router RT4 has been selected as the Designated
   router for network 192.1.1.0.  RT3's router-LSA for Area 1 is then
   shown below.  It indicates that RT3 has two connections to Area 1,
   the first a link to the transit network 192.1.1.0 and the second a
   link to the stub network 192.1.4.0.  Note that the transit network is
   identified by the IP interface of its Designated Router (i.e., the
   Link ID = 192.1.1.4 which is the Designated Router RT4's IP interface
   to 192.1.1.0).  Note also that RT3 has indicated that it is an area
   border router.
ToP   noToC   RFC2178 - Page 115
     ; RT3's router-LSA for Area 1

     LS age = 0                     ;always true on origination
     Options = (E-bit)              ;
     LS type = 1                    ;indicates router-LSA
     Link State ID = 192.1.1.3      ;RT3's Router ID
     Advertising Router = 192.1.1.3 ;RT3's Router ID
     bit E = 0                      ;not an AS boundary router
     bit B = 1                      ;area border router
     #links = 2
            Link ID = 192.1.1.4     ;IP address of Desig. Rtr.
            Link Data = 192.1.1.3   ;RT3's IP interface to net
            Type = 2                ;connects to transit network
            # TOS metrics = 0
            metric = 1

            Link ID = 192.1.4.0     ;IP Network number
            Link Data = 0xffffff00  ;Network mask
            Type = 3                ;connects to stub network
            # TOS metrics = 0
            metric = 2

   Next RT3's router-LSA for the backbone is shown.  It indicates that
   RT3 has a single attachment to the backbone.  This attachment is via
   an unnumbered point-to-point link to Router RT6.  RT3 has again
   indicated that it is an area border router.


     ; RT3's router-LSA for the backbone

     LS age = 0                     ;always true on origination
     Options = (E-bit)              ;
     LS type = 1                    ;indicates router-LSA
     Link State ID = 192.1.1.3      ;RT3's router ID
     Advertising Router = 192.1.1.3 ;RT3's router ID
     bit E = 0                      ;not an AS boundary router
     bit B = 1                      ;area border router
     #links = 1
            Link ID = 18.10.0.6     ;Neighbor's Router ID
            Link Data = 0.0.0.3     ;MIB-II ifIndex of P-P link
            Type = 1                ;connects to router
            # TOS metrics = 0
            metric = 8
ToP   noToC   RFC2178 - Page 116
12.4.2.  Network-LSAs

   A network-LSA is generated for every transit broadcast or NBMA
   network.  (A transit network is a network having two or more attached
   routers).  The network-LSA describes all the routers that are
   attached to the network.

   The Designated Router for the network originates the LSA.  The
   Designated Router originates the LSA only if it is fully adjacent to
   at least one other router on the network.  The network-LSA is flooded
   throughout the area that contains the transit network, and no
   further.  The network-LSA lists those routers that are fully adjacent
   to the Designated Router; each fully adjacent router is identified by
   its OSPF Router ID. The Designated Router includes itself in this
   list.

   The Link State ID for a network-LSA is the IP interface address of
   the Designated Router.  This value, masked by the network's address
   mask (which is also contained in the network-LSA) yields the
   network's IP address.

   A router that has formerly been the Designated Router for a network,
   but is no longer, should flush the network-LSA that it had previously
   originated.  This LSA is no longer used in the routing table
   calculation.  It is flushed by prematurely incrementing the LSA's age
   to MaxAge and reflooding (see Section 14.1). In addition, in those
   rare cases where a router's Router ID has changed, any network-LSAs
   that were originated with the router's previous Router ID must be
   flushed. Since the router may have no idea what it's previous Router
   ID might have been, these network-LSAs are indicated by having their
   Link State ID equal to one of the router's IP interface addresses and
   their Advertising Router equal to some value other than the router's
   current Router ID (see Section 13.4 for more details).

12.4.2.1.  Examples of network-LSAs

   Again consider the area configuration in Figure 6.  Network-LSAs are
   originated for Network N3 in Area 1, Networks N6 and N8 in Area 2,
   and Network N9 in Area 3.  Assuming that Router RT4 has been selected
   as the Designated Router for Network N3, the following network-LSA is
   generated by RT4 on behalf of Network N3 (see Figure 15 for the
   address assignments):
ToP   noToC   RFC2178 - Page 117
     ; Network-LSA for Network N3

     LS age = 0                     ;always true on origination
     Options = (E-bit)              ;
     LS type = 2                    ;indicates network-LSA
     Link State ID = 192.1.1.4      ;IP address of Desig. Rtr.
     Advertising Router = 192.1.1.4 ;RT4's Router ID
     Network Mask = 0xffffff00
            Attached Router = 192.1.1.4    ;Router ID
            Attached Router = 192.1.1.1    ;Router ID
            Attached Router = 192.1.1.2    ;Router ID
            Attached Router = 192.1.1.3    ;Router ID

12.4.3.  Summary-LSAs

   The destination described by a summary-LSA is either an IP network,
   an AS boundary router or a range of IP addresses.  Summary-LSAs are
   flooded throughout a single area only.  The destination described is
   one that is external to the area, yet still belongs to the Autonomous
   System.

   Summary-LSAs are originated by area border routers.  The precise
   summary routes to advertise into an area are determined by examining
   the routing table structure (see Section 11) in accordance with the
   algorithm described below. Note that only intra-area routes are
   advertised into the backbone, while both intra-area and inter-area
   routes are advertised into the other areas.

   To determine which routes to advertise into an attached Area A, each
   routing table entry is processed as follows.  Remember that each
   routing table entry describes a set of equal-cost best paths to a
   particular destination:

   o  Only Destination Types of network and AS boundary router
      are advertised in summary-LSAs.  If the routing table entry's
      Destination Type is area border router, examine the next routing
      table entry.

   o  AS external routes are never advertised in summary-LSAs.
      If the routing table entry has Path-type of type 1 external or
      type 2 external, examine the next routing table entry.

   o  Else, if the area associated with this set of paths is
      the Area A itself, do not generate a summary-LSA for the
      route.[17]
ToP   noToC   RFC2178 - Page 118
   o  Else, if the next hops associated with this set of paths
      belong to Area A itself, do not generate a summary-LSA for the
      route.[18] This is the logical equivalent of a Distance Vector
      protocol's split horizon logic.

   o  Else, if the routing table cost equals or exceeds the
      value LSInfinity, a summary-LSA cannot be generated for this
      route.

   o  Else, if the destination of this route is an AS boundary
      router, a summary-LSA should be originated if and only if the
      routing table entry describes the preferred path to the AS
      boundary router (see Step 3 of Section 16.4).  If so, a Type 4
      summary-LSA is originated for the destination, with Link State ID
      equal to the AS boundary router's Router ID and metric equal to
      the routing table entry's cost. Note: these LSAs should not be
      generated if Area A has been configured as a stub area.

   o  Else, the Destination type is network. If this is an
      inter-area route, generate a Type 3 summary-LSA for the
      destination, with Link State ID equal to the network's address (if
      necessary, the Link State ID can also have one or more of the
      network's host bits set; see Appendix E for details) and metric
      equal to the routing table cost.

   o  The one remaining case is an intra-area route to a network.  This
      means that the network is contained in one of the router's
      directly attached areas.  In general, this information must be
      condensed before appearing in summary-LSAs.  Remember that an area
      has a configured list of address ranges, each range consisting of
      an [address,mask] pair and a status indication of either Advertise
      or DoNotAdvertise.  At most a single Type 3 summary-LSA is
      originated for each range. When the range's status indicates
      Advertise, a Type 3 summary-LSA is generated with Link State ID
      equal to the range's address (if necessary, the Link State ID can
      also have one or more of the range's "host" bits set; see Appendix
      E for details) and cost equal to the largest cost of any of the
      component networks. When the range's status indicates
      DoNotAdvertise, the Type 3 summary-LSA is suppressed and the
      component networks remain hidden from other areas.

   By default, if a network is not contained in any explicitly
   configured address range, a Type 3 summary-LSA is generated with Link
   State ID equal to the network's address (if necessary, the Link State
   ID can also have one or more of the network's "host" bits set; see
   Appendix E for details) and metric equal to the network's routing
   table cost.
ToP   noToC   RFC2178 - Page 119
   If an area is capable of carrying transit traffic (i.e., its
   TransitCapability is set to TRUE), routing information concerning
   backbone networks should not be condensed before being summarized
   into the area.  Nor should the advertisement of backbone networks
   into transit areas be suppressed.  In other words, the backbone's
   configured ranges should be ignored when originating summary-LSAs
   into transit areas.

   If a router advertises a summary-LSA for a destination which then
   becomes unreachable, the router must then flush the LSA from the
   routing domain by setting its age to MaxAge and reflooding (see
   Section 14.1).  Also, if the destination is still reachable, yet can
   no longer be advertised according to the above procedure (e.g., it is
   now an inter-area route, when it used to be an intra-area route
   associated with some non-backbone area; it would thus no longer be
   advertisable to the backbone), the LSA should also be flushed from
   the routing domain.

12.4.3.1.  Originating summary-LSAs into stub areas

   The algorithm in Section 12.4.3 is optional when Area A is an OSPF
   stub area. Area border routers connecting to a stub area can
   originate summary-LSAs into the area according to the Section
   12.4.3's algorithm, or can choose to originate only a subset of the
   summary-LSAs, possibly under configuration control.  The fewer LSAs
   originated, the smaller the stub area's link state database, further
   reducing the demands on its routers' resources. However, omitting
   LSAs may also lead to sub-optimal inter-area routing, although
   routing will continue to function.

   As specified in Section 12.4.3, Type 4 summary-LSAs (ASBR-summary-
   LSAs) are never originated into stub areas.

   In a stub area, instead of importing external routes each area border
   router originates a "default summary-LSA" into the area. The Link
   State ID for the default summary-LSA is set to DefaultDestination,
   and the metric set to the (per-area) configurable parameter
   StubDefaultCost.  Note that StubDefaultCost need not be configured
   identically in all of the stub area's area border routers.

12.4.3.2.  Examples of summary-LSAs

   Consider again the area configuration in Figure 6.  Routers RT3, RT4,
   RT7, RT10 and RT11 are all area border routers, and therefore are
   originating summary-LSAs.  Consider in particular Router RT4.  Its
   routing table was calculated as the example in Section 11.3. RT4
   originates summary-LSAs into both the backbone and Area 1.  Into the
   backbone, Router RT4 originates separate LSAs for each of the
ToP   noToC   RFC2178 - Page 120
   networks N1-N4.  Into Area 1, Router RT4 originates separate LSAs for
   networks N6-N8 and the AS boundary routers RT5,RT7.  It also
   condenses host routes Ia and Ib into a single summary-LSA.  Finally,
   the routes to networks N9,N10,N11 and Host H1 are advertised by a
   single summary-LSA.  This condensation was originally performed by
   the router RT11.

   These LSAs are illustrated graphically in Figures 7 and 8.  Two of
   the summary-LSAs originated by Router RT4 follow.  The actual IP
   addresses for the networks and routers in question have been assigned
   in Figure 15.

     ; Summary-LSA for Network N1,
     ; originated by Router RT4 into the backbone

     LS age = 0                  ;always true on origination
     Options = (E-bit)           ;
     LS type = 3                 ;Type 3 summary-LSA
     Link State ID = 192.1.2.0   ;N1's IP network number
     Advertising Router = 192.1.1.4       ;RT4's ID
     metric = 4

     ; Summary-LSA for AS boundary router RT7
     ; originated by Router RT4 into Area 1

     LS age = 0                  ;always true on origination
     Options = (E-bit)           ;
     LS type = 4                 ;Type 4 summary-LSA
     Link State ID = Router RT7's ID
     Advertising Router = 192.1.1.4       ;RT4's ID
     metric = 14

12.4.4.  AS-external-LSAs

   AS-external-LSAs describe routes to destinations external to the
   Autonomous System.  Most AS-external-LSAs describe routes to specific
   external destinations; in these cases the LSA's Link State ID is set
   to the destination network's IP address (if necessary, the Link State
   ID can also have one or more of the network's "host" bits set; see
   Appendix E for details).  However, a default route for the Autonomous
   System can be described in an AS-external-LSA by setting the LSA's
   Link State ID to DefaultDestination (0.0.0.0).  AS-external-LSAs are
   originated by AS boundary routers.  An AS boundary router originates
   a single AS-external-LSA for each external route that it has learned,
   either through another routing protocol (such as BGP), or through
   configuration information.
ToP   noToC   RFC2178 - Page 121
   AS-external-LSAs are the only type of LSAs that are flooded
   throughout the entire Autonomous System; all other types of LSAs are
   specific to a single area.  However, AS-external-LSAs are not flooded
   into/throughout stub areas (see Section 3.6).  This enables a
   reduction in link state database size for routers internal to stub
   areas.

   The metric that is advertised for an external route can be one of two
   types.  Type 1 metrics are comparable to the link state metric.  Type
   2 metrics are assumed to be larger than the cost of any intra-AS
   path.

   If a router advertises an AS-external-LSA for a destination which
   then becomes unreachable, the router must then flush the LSA from the
   routing domain by setting its age to MaxAge and reflooding (see
   Section 14.1).

12.4.4.1.  Examples of AS-external-LSAs

   Consider once again the AS pictured in Figure 6.  There are two AS
   boundary routers: RT5 and RT7.  Router RT5 originates three AS-
   external-LSAs, for networks N12-N14.  Router RT7 originates two AS-
   external-LSAs, for networks N12 and N15.  Assume that RT7 has learned
   its route to N12 via BGP, and that it wishes to advertise a Type 2
   metric to the AS.  RT7 would then originate the following LSA for
   N12:

     ; AS-external-LSA for Network N12,
     ; originated by Router RT7

     LS age = 0                  ;always true on origination
     Options = (E-bit)           ;
     LS type = 5                 ;AS-external-LSA
     Link State ID = N12's IP network number
     Advertising Router = Router RT7's ID
     bit E = 1                   ;Type 2 metric
     metric = 2
     Forwarding address = 0.0.0.0

   In the above example, the forwarding address field has been set to
   0.0.0.0, indicating that packets for the external destination should
   be forwarded to the advertising OSPF router (RT7). This is not always
   desirable.  Consider the example pictured in Figure 16.  There are
   three OSPF routers (RTA, RTB and RTC) connected to a common network.
   Only one of these routers, RTA, is exchanging BGP information with
   the non-OSPF router RTX.  RTA must then originate AS- external-LSAs
   for those destinations it has learned from RTX.  By using the AS-
   external-LSA's forwarding address field, RTA can specify that packets
ToP   noToC   RFC2178 - Page 122
   for these destinations be forwarded directly to RTX.  Without this
   feature, Routers RTB and RTC would take an extra hop to get to these
   destinations.

   Note that when the forwarding address field is non-zero, it should
   point to a router belonging to another Autonomous System.

   A forwarding address can also be specified for the default route. For
   example, in figure 16 RTA may want to specify that all externally-
   destined packets should by default be forwarded to its BGP peer RTX.
   The resulting AS-external-LSA is pictured below.  Note that the Link
   State ID is set to DefaultDestination.

     ; Default route, originated by Router RTA
     ; Packets forwarded through RTX

     LS age = 0                  ;always true on origination
     Options = (E-bit)           ;
     LS type = 5                 ;AS-external-LSA
     Link State ID = DefaultDestination  ; default route
     Advertising Router = Router RTA's ID
     bit E = 1                   ;Type 2 metric
     metric = 1
     Forwarding address = RTX's IP address

   In figure 16, suppose instead that both RTA and RTB exchange BGP
   information with RTX.  In this case, RTA and RTB would originate the
   same set of AS-external-LSAs.  These LSAs, if they specify the same
   metric, would be functionally equivalent since they would specify the
   same destination and forwarding address (RTX). This leads to a clear
   duplication of effort.  If only one of RTA or RTB originated the set
   of AS-external-LSAs, the routing would remain the same, and the size
   of the link state database would decrease.  However, it must be
   unambiguously defined as to which router originates the LSAs
   (otherwise neither may, or the identity of the originator may
   oscillate). The following rule is thereby established: if two
   routers, both reachable from one another, originate functionally
   equivalent AS-external-LSAs (i.e., same destination, cost and non-
   zero forwarding address), then the LSA originated by the router
   having the highest OSPF Router ID is used.  The router having the
   lower OSPF Router ID can then flush its LSA.  Flushing an LSA is
   discussed in Section 14.1.

13.  The Flooding Procedure

   Link State Update packets provide the mechanism for flooding LSAs.  A
   Link State Update packet may contain several distinct LSAs, and
   floods each LSA one hop further from its point of origination.  To
ToP   noToC   RFC2178 - Page 123
   make the flooding procedure reliable, each LSA must be acknowledged
   separately.  Acknowledgments are transmitted in Link State
   Acknowledgment packets.  Many separate acknowledgments can also be
   grouped together into a single packet.

   The flooding procedure starts when a Link State Update packet has
   been received.  Many consistency checks have been made on the
   received packet before being handed to the flooding procedure (see
   Section 8.2).  In particular, the Link State Update packet has been
   associated with a particular neighbor, and a particular area.  If the
   neighbor is in a lesser state than Exchange, the packet should be
   dropped without further processing.

                                +
                                |
                      +---+.....|.BGP
                      |RTA|-----|.....+---+
                      +---+     |-----|RTX|
                                |     +---+
                      +---+     |
                      |RTB|-----|
                      +---+     |
                                |
                      +---+     |
                      |RTC|-----|
                      +---+     |
                                |
                                +

                 Figure 16: Forwarding address example

   All types of LSAs, other than AS-external-LSAs, are associated with a
   specific area.  However, LSAs do not contain an area field.  An LSA's
   area must be deduced from the Link State Update packet header.

   For each LSA contained in a Link State Update packet, the following
   steps are taken:


    (1) Validate the LSA's LS checksum.  If the checksum turns out to be
        invalid, discard the LSA and get the next one from the Link
        State Update packet.

    (2) Examine the LSA's LS type.  If the LS type is unknown, discard
        the LSA and get the next one from the Link State Update Packet.
        This specification defines LS types 1-5 (see Section 4.3).

    (3) Else if this is an AS-external-LSA (LS type = 5), and the area
ToP   noToC   RFC2178 - Page 124
        has been configured as a stub area, discard the LSA and get the
        next one from the Link State Update Packet.  AS-external-LSAs
        are not flooded into/throughout stub areas (see Section 3.6).

    (4) Else if the LSA's LS age is equal to MaxAge, and there is
        currently no instance of the LSA in the router's link state
        database, then take the following actions:

        (a) Acknowledge the receipt of the LSA by sending a Link State
            Acknowledgment packet back to the sending neighbor (see
            Section 13.5).

        (b) Purge all outstanding requests for equal or previous
            instances of the LSA from the sending neighbor's Link State
            Request list (see Section 10).

        (c) If the sending neighbor is in state Exchange or in state
            Loading, then install the MaxAge LSA in the link state
            database.  Otherwise, simply discard the LSA.  In either
            case, examine the next LSA (if any) listed in the Link State
            Update packet.

    (5) Otherwise, find the instance of this LSA that is currently
        contained in the router's link state database.  If there is no
        database copy, or the received LSA is more recent than the
        database copy (see Section 13.1 below for the determination of
        which LSA is more recent) the following steps must be performed:

        (a) If there is already a database copy, and if the database
            copy was installed less than MinLSArrival seconds ago,
            discard the new LSA (without acknowledging it) and examine
            the next LSA (if any) listed in the Link State Update
            packet.

        (b) Otherwise immediately flood the new LSA out some subset of
            the router's interfaces (see Section 13.3).  In some cases
            (e.g., the state of the receiving interface is DR and the
            LSA was received from a router other than the Backup DR) the
            LSA will be flooded back out the receiving interface.  This
            occurrence should be noted for later use by the
            acknowledgment process (Section 13.5).

        (c) Remove the current database copy from all neighbors' Link
            state retransmission lists.

        (d) Install the new LSA in the link state database (replacing
            the current database copy).  This may cause the routing
            table calculation to be scheduled.  In addition, timestamp
ToP   noToC   RFC2178 - Page 125
            the new LSA with the current time (i.e., the time it was
            received).  The flooding procedure cannot overwrite the
            newly installed LSA until MinLSArrival seconds have elapsed.
            The LSA installation process is discussed further in Section
            13.2.

        (e) Possibly acknowledge the receipt of the LSA by sending a
            Link State Acknowledgment packet back out the receiving
            interface.  This is explained below in Section 13.5.

        (f) If this new LSA indicates that it was originated by the
            receiving router itself (i.e., is considered a self-
            originated LSA), the router must take special action, either
            updating the LSA or in some cases flushing it from the
            routing domain. For a description of how self-originated
            LSAs are detected and subsequently handled, see Section
            13.4.

    (6) Else, if there is an instance of the LSA on the sending
        neighbor's Link state request list, an error has occurred in the
        Database Exchange process.  In this case, restart the Database
        Exchange process by generating the neighbor event BadLSReq for
        the sending neighbor and stop processing the Link State Update
        packet.

    (7) Else, if the received LSA is the same instance as the database
        copy (i.e., neither one is more recent) the following two steps
        should be performed:

        (a) If the LSA is listed in the Link state retransmission list
            for the receiving adjacency, the router itself is expecting
            an acknowledgment for this LSA.  The router should treat the
            received LSA as an acknowledgment by removing the LSA from
            the Link state retransmission list.  This is termed an
            "implied acknowledgment".  Its occurrence should be noted
            for later use by the acknowledgment process (Section 13.5).

        (b) Possibly acknowledge the receipt of the LSA by sending a
            Link State Acknowledgment packet back out the receiving
            interface.  This is explained below in Section 13.5.

    (8) Else, the database copy is more recent.  If the database copy
        has LS age equal to MaxAge and LS sequence number equal to
        MaxSequenceNumber, simply discard the received LSA without
        acknowledging it. (In this case, the LSA's LS sequence number is
        wrapping, and the MaxSequenceNumber LSA must be completely
        flushed before any new LSA instance can be introduced).
        Otherwise, send the database copy back to the sending neighbor,
ToP   noToC   RFC2178 - Page 126
        encapsulated within a Link State Update Packet. The Link State
        Update Packet should be unicast to the neighbor. In so doing, do
        not put the database copy of the LSA on the neighbor's link
        state retransmission list, and do not acknowledge the received
        (less recent) LSA instance.

13.1.  Determining which LSA is newer

   When a router encounters two instances of an LSA, it must determine
   which is more recent.  This occurred above when comparing a received
   LSA to its database copy. This comparison must also be done during
   the Database Exchange procedure which occurs during adjacency bring-
   up.

   An LSA is identified by its LS type, Link State ID and Advertising
   Router.  For two instances of the same LSA, the LS sequence number,
   LS age, and LS checksum fields are used to determine which instance
   is more recent:

   o   The LSA having the newer LS sequence number is more recent.
       See Section 12.1.6 for an explanation of the LS sequence number
       space.  If both instances have the same LS sequence number, then:

   o   If the two instances have different LS checksums, then the
       instance having the larger LS checksum (when considered as a 16-
       bit unsigned integer) is considered more recent.

   o   Else, if only one of the instances has its LS age field set
       to MaxAge, the instance of age MaxAge is considered to be more
       recent.

   o   Else, if the LS age fields of the two instances differ by
       more than MaxAgeDiff, the instance having the smaller (younger)
       LS age is considered to be more recent.

   o   Else, the two instances are considered to be identical.
ToP   noToC   RFC2178 - Page 127
13.2.  Installing LSAs in the database

   Installing a new LSA in the database, either as the result of
   flooding or a newly self-originated LSA, may cause the OSPF routing
   table structure to be recalculated.  The contents of the new LSA
   should be compared to the old instance, if present.  If there is no
   difference, there is no need to recalculate the routing table. When
   comparing an LSA to its previous instance, the following are all
   considered to be differences in contents:

   o   The LSA's Options field has changed.

   o   One of the LSA instances has LS age set to MaxAge, and
       the other does not.

   o   The length field in the LSA header has changed.

   o   The body of the LSA (i.e., anything outside the 20-byte
       LSA header) has changed. Note that this excludes changes in LS
       Sequence Number and LS Checksum.

   If the contents are different, the following pieces of the routing
   table must be recalculated, depending on the new LSA's LS type field:

   Router-LSAs and network-LSAs
      The entire routing table must be recalculated, starting with the
      shortest path calculations for each area (not just the area whose
      link-state database has changed).  The reason that the shortest
      path calculation cannot be restricted to the single changed area
      has to do with the fact that AS boundary routers may belong to
      multiple areas.  A change in the area currently providing the best
      route may force the router to use an intra-area route provided by
      a different area.[19]

   Summary-LSAs
      The best route to the destination described by the summary-LSA
      must be recalculated (see Section 16.5).  If this destination is
      an AS boundary router, it may also be necessary to re-examine all
      the AS-external-LSAs.

   AS-external-LSAs
      The best route to the destination described by the AS-external-LSA
      must be recalculated (see Section 16.6).

      Also, any old instance of the LSA must be removed from the
      database when the new LSA is installed.  This old instance must
      also be removed from all neighbors' Link state retransmission
      lists (see Section 10).
ToP   noToC   RFC2178 - Page 128
13.3.  Next step in the flooding procedure

   When a new (and more recent) LSA has been received, it must be
   flooded out some set of the router's interfaces.  This section
   describes the second part of flooding procedure (the first part being
   the processing that occurred in Section 13), namely, selecting the
   outgoing interfaces and adding the LSA to the appropriate neighbors'
   Link state retransmission lists.  Also included in this part of the
   flooding procedure is the maintenance of the neighbors' Link state
   request lists.

   This section is equally applicable to the flooding of an LSA that the
   router itself has just originated (see Section 12.4).

   For these LSAs, this section provides the entirety of the flooding
   procedure (i.e., the processing of Section 13 is not performed,
   since, for example, the LSA has not been received from a neighbor and
   therefore does not need to be acknowledged).

   Depending upon the LSA's LS type, the LSA can be flooded out only
   certain interfaces.  These interfaces, defined by the following, are
   called the eligible interfaces:

   AS-external-LSAs (LS Type = 5)
      AS-external-LSAs are flooded throughout the entire AS, with the
      exception of stub areas (see Section 3.6).  The eligible
      interfaces are all the router's interfaces, excluding virtual
      links and those interfaces attaching to stub areas.

   All other LS types
      All other types are specific to a single area (Area A).  The
      eligible interfaces are all those interfaces attaching to the Area
      A.  If Area A is the backbone, this includes all the virtual
      links.

   Link state databases must remain synchronized over all adjacencies
   associated with the above eligible interfaces.  This is accomplished
   by executing the following steps on each eligible interface.  It
   should be noted that this procedure may decide not to flood an LSA
   out a particular interface, if there is a high probability that the
   attached neighbors have already received the LSA.  However, in these
   cases the flooding procedure must be absolutely sure that the
   neighbors eventually do receive the LSA, so the LSA is still added to
   each adjacency's Link state retransmission list.  For each eligible
   interface:
ToP   noToC   RFC2178 - Page 129
   (1) Each of the neighbors attached to this interface are
       examined, to determine whether they must receive the new
       LSA.  The following steps are executed for each neighbor:

       (a) If the neighbor is in a lesser state than Exchange, it
           does not participate in flooding, and the next neighbor
           should be examined.

       (b) Else, if the adjacency is not yet full (neighbor state
           is Exchange or Loading), examine the Link state request
           list associated with this adjacency.  If there is an
           instance of the new LSA on the list, it indicates that
           the neighboring router has an instance of the LSA
           already.  Compare the new LSA to the neighbor's copy:

           o   If the new LSA is less recent, then examine the next
               neighbor.

           o   If the two copies are the same instance, then delete
               the LSA from the Link state request list, and
               examine the next neighbor.[20]

           o   Else, the new LSA is more recent.  Delete the LSA
               from the Link state request list.

       (c) If the new LSA was received from this neighbor, examine
           the next neighbor.

       (d) At this point we are not positive that the neighbor has
           an up-to-date instance of this new LSA.  Add the new LSA
           to the Link state retransmission list for the adjacency.
           This ensures that the flooding procedure is reliable;
           the LSA will be retransmitted at intervals until an
           acknowledgment is seen from the neighbor.

   (2) The router must now decide whether to flood the new LSA out
       this interface.  If in the previous step, the LSA was NOT
       added to any of the Link state retransmission lists, there
       is no need to flood the LSA out the interface and the next
       interface should be examined.

   (3) If the new LSA was received on this interface, and it was
       received from either the Designated Router or the Backup
       Designated Router, chances are that all the neighbors have
       received the LSA already.  Therefore, examine the next
       interface.
ToP   noToC   RFC2178 - Page 130
   (4) If the new LSA was received on this interface, and the
       interface state is Backup (i.e., the router itself is the
       Backup Designated Router), examine the next interface.  The
       Designated Router will do the flooding on this interface.
       However, if the Designated Router fails the router (i.e.,
       the Backup Designated Router) will end up retransmitting the
       updates.

   (5) If this step is reached, the LSA must be flooded out the
       interface.  Send a Link State Update packet (including the
       new LSA as contents) out the interface.  The LSA's LS age
       must be incremented by InfTransDelay (which must be > 0)
       when it is copied into the outgoing Link State Update packet
       (until the LS age field reaches the maximum value of
       MaxAge).

       On broadcast networks, the Link State Update packets are
       multicast.  The destination IP address specified for the
       Link State Update Packet depends on the state of the
       interface.  If the interface state is DR or Backup, the
       address AllSPFRouters should be used.  Otherwise, the
       address AllDRouters should be used.

       On non-broadcast networks, separate Link State Update
       packets must be sent, as unicasts, to each adjacent neighbor
       (i.e., those in state Exchange or greater).  The destination
       IP addresses for these packets are the neighbors' IP
       addresses.

13.4.  Receiving self-originated LSAs

   It is a common occurrence for a router to receive self-originated
   LSAs via the flooding procedure. A self-originated LSA is detected
   when either 1) the LSA's Advertising Router is equal to the router's
   own Router ID or 2) the LSA is a network-LSA and its Link State ID is
   equal to one of the router's own IP interface addresses.

   However, if the received self-originated LSA is newer than the last
   instance that the router actually originated, the router must take
   special action.  The reception of such an LSA indicates that there
   are LSAs in the routing domain that were originated by the router
   before the last time it was restarted.  In most cases, the router
   must then advance the LSA's LS sequence number one past the received
   LS sequence number, and originate a new instance of the LSA.

   It may be the case the router no longer wishes to originate the
   received LSA. Possible examples include: 1) the LSA is a summary-LSA
   or AS-external-LSA and the router no longer has an (advertisable)
ToP   noToC   RFC2178 - Page 131
   route to the destination, 2) the LSA is a network-LSA but the router
   is no longer Designated Router for the network or 3) the LSA is a
   network-LSA whose Link State ID is one of the router's own IP
   interface addresses but whose Advertising Router is not equal to the
   router's own Router ID (this latter case should be rare, and it
   indicates that the router's Router ID has changed since originating
   the LSA).  In all these cases, instead of updating the LSA, the LSA
   should be flushed from the routing domain by incrementing the
   received LSA's LS age to MaxAge and reflooding (see Section 14.1).

13.5.  Sending Link State Acknowledgment packets

   Each newly received LSA must be acknowledged.  This is usually done
   by sending Link State Acknowledgment packets.  However,
   acknowledgments can also be accomplished implicitly by sending Link
   State Update packets (see step 7a of Section 13).

   Many acknowledgments may be grouped together into a single Link State
   Acknowledgment packet.  Such a packet is sent back out the interface
   which received the LSAs.  The packet can be sent in one of two ways:
   delayed and sent on an interval timer, or sent directly (as a
   unicast) to a particular neighbor.  The particular acknowledgment
   strategy used depends on the circumstances surrounding the receipt of
   the LSA.

   Sending delayed acknowledgments accomplishes several things: 1) it
   facilitates the packaging of multiple acknowledgments in a single
   Link State Acknowledgment packet, 2) it enables a single Link State
   Acknowledgment packet to indicate acknowledgments to several
   neighbors at once (through multicasting) and 3) it randomizes the
   Link State Acknowledgment packets sent by the various routers
   attached to a common network.  The fixed interval between a router's
   delayed transmissions must be short (less than RxmtInterval) or
   needless retransmissions will ensue.

   Direct acknowledgments are sent to a particular neighbor in response
   to the receipt of duplicate LSAs.  These acknowledgments are sent as
   unicasts, and are sent immediately when the duplicate is received.

   The precise procedure for sending Link State Acknowledgment packets
   is described in Table 19.  The circumstances surrounding the receipt
   of the LSA are listed in the left column.  The acknowledgment action
   then taken is listed in one of the two right columns.  This action
   depends on the state of the concerned interface; interfaces in state
   Backup behave differently from interfaces in all other states.
   Delayed acknowledgments must be delivered to all adjacent routers
   associated with the interface.  On broadcast networks, this is
   accomplished by sending the delayed Link State Acknowledgment packets
ToP   noToC   RFC2178 - Page 132
   as multicasts.  The Destination IP address used depends on the state
   of the interface.  If the interface state is DR or Backup, the
   destination AllSPFRouters is used.  In all other states, the
   destination AllDRouters is used.  On non-broadcast networks, delayed
   Link State Acknowledgment packets must be unicast separately over
   each adjacency (i.e., neighbor whose state is >= Exchange).

                                    Action taken in state
    Circumstances          Backup                All other states
    _______________________________________________________________
    LSA  has               No  acknowledgment    No  acknowledgment
    been  flooded back     sent.                 sent.
    out receiving  in-
    terface  (see Sec-
    tion 13, step 5b).
    _______________________________________________________________
    LSA   is               Delayed acknowledg-   Delayed       ack-
    more  recent  than     ment sent if adver-   nowledgment sent.
    database copy, but     tisement   received
    was   not  flooded     from    Designated
    back out receiving     Router,  otherwise
    interface              do nothing
    _______________________________________________________________
    LSA is a               Delayed acknowledg-   No  acknowledgment
    duplicate, and was     ment sent if adver-   sent.
    treated as an  im-     tisement   received
    plied  acknowledg-     from    Designated
    ment (see  Section     Router,  otherwise
    13, step 7a).          do nothing
    _______________________________________________________________
    LSA is a               Direct acknowledg-    Direct acknowledg-
    duplicate, and was     ment sent.            ment sent.
    not treated as  an
    implied       ack-
    nowledgment.
    _______________________________________________________________
    LSA's LS               Direct acknowledg-    Direct acknowledg-
    age is equal to        ment sent.            ment sent.
    MaxAge, and there is
    no current instance
    of the LSA
    in the link state
    database (see
    Section 13, step 4).


             Table 19: Sending link state acknowledgments.
ToP   noToC   RFC2178 - Page 133
   The reasoning behind sending the above packets as multicasts is best
   explained by an example.  Consider the network configuration depicted
   in Figure 15.  Suppose RT4 has been elected as Designated Router, and
   RT3 as Backup Designated Router for the network N3.  When Router RT4
   floods a new LSA to Network N3, it is received by routers RT1, RT2,
   and RT3.  These routers will not flood the LSA back onto net N3, but
   they still must ensure that their link-state databases remain
   synchronized with their adjacent neighbors.  So RT1, RT2, and RT4 are
   waiting to see an acknowledgment from RT3.  Likewise, RT4 and RT3 are
   both waiting to see acknowledgments from RT1 and RT2.  This is best
   achieved by sending the acknowledgments as multicasts.

   The reason that the acknowledgment logic for Backup DRs is slightly
   different is because they perform differently during the flooding of
   LSAs (see Section 13.3, step 4).


13.6.  Retransmitting LSAs

   LSAs flooded out an adjacency are placed on the adjacency's Link
   state retransmission list.  In order to ensure that flooding is
   reliable, these LSAs are retransmitted until they are acknowledged.
   The length of time between retransmissions is a configurable per-
   interface value, RxmtInterval.  If this is set too low for an
   interface, needless retransmissions will ensue.  If the value is set
   too high, the speed of the flooding, in the face of lost packets, may
   be affected.

   Several retransmitted LSAs may fit into a single Link State Update
   packet.  When LSAs are to be retransmitted, only the number fitting
   in a single Link State Update packet should be sent.  Another packet
   of retransmissions can be sent whenever some of the LSAs are
   acknowledged, or on the next firing of the retransmission timer.

   Link State Update Packets carrying retransmissions are always sent as
   unicasts (directly to the physical address of the neighbor).  They
   are never sent as multicasts.  Each LSA's LS age must be incremented
   by InfTransDelay (which must be > 0) when it is copied into the
   outgoing Link State Update packet (until the LS age field reaches the
   maximum value of MaxAge).

   If an adjacent router goes down, retransmissions may occur until the
   adjacency is destroyed by OSPF's Hello Protocol.  When the adjacency
   is destroyed, the Link state retransmission list is cleared.
ToP   noToC   RFC2178 - Page 134
13.7.  Receiving link state acknowledgments

   Many consistency checks have been made on a received Link State
   Acknowledgment packet before it is handed to the flooding procedure.
   In particular, it has been associated with a particular neighbor.  If
   this neighbor is in a lesser state than Exchange, the Link State
   Acknowledgment packet is discarded.

   Otherwise, for each acknowledgment in the Link State Acknowledgment
   packet, the following steps are performed:


   o   Does the LSA acknowledged have an instance on the Link state
       retransmission list for the neighbor?  If not, examine the
       next acknowledgment.  Otherwise:

   o   If the acknowledgment is for the same instance that is
       contained on the list, remove the item from the list and
       examine the next acknowledgment.  Otherwise:

      o   Log the questionable acknowledgment, and examine the next
          one.

14.  Aging The Link State Database

   Each LSA has an LS age field.  The LS age is expressed in seconds.
   An LSA's LS age field is incremented while it is contained in a
   router's database.  Also, when copied into a Link State Update Packet
   for flooding out a particular interface, the LSA's LS age is
   incremented by InfTransDelay.

   An LSA's LS age is never incremented past the value MaxAge.  LSAs
   having age MaxAge are not used in the routing table calculation.  As
   a router ages its link state database, an LSA's LS age may reach
   MaxAge.[21]  At this time, the router must attempt to flush the LSA
   from the routing domain.  This is done simply by reflooding the
   MaxAge LSA just as if it was a newly originated LSA (see Section
   13.3).

   When creating a Database summary list for a newly forming adjacency,
   any MaxAge LSAs present in the link state database are added to the
   neighbor's Link state retransmission list instead of the neighbor's
   Database summary list.  See Section 10.3 for more details.

   A MaxAge LSA must be removed immediately from the router's link state
   database as soon as both a) it is no longer contained on any neighbor
   Link state retransmission lists and b) none of the router's neighbors
   are in states Exchange or Loading.
ToP   noToC   RFC2178 - Page 135
   When, in the process of aging the link state database, an LSA's LS
   age hits a multiple of CheckAge, its LS checksum should be verified.
   If the LS checksum is incorrect, a program or memory error has been
   detected, and at the very least the router itself should be
   restarted.

14.1.  Premature aging of LSAs

   An LSA can be flushed from the routing domain by setting its LS age
   to MaxAge and reflooding the LSA.  This procedure follows the same
   course as flushing an LSA whose LS age has naturally reached the
   value MaxAge (see Section 14).  In particular, the MaxAge LSA is
   removed from the router's link state database as soon as a) it is no
   longer contained on any neighbor Link state retransmission lists and
   b) none of the router's neighbors are in states Exchange or Loading.
   We call the setting of an LSA's LS age to MaxAge "premature aging".

   Premature aging is used when it is time for a self-originated LSA's
   sequence number field to wrap.  At this point, the current LSA
   instance (having LS sequence number MaxSequenceNumber) must be
   prematurely aged and flushed from the routing domain before a new
   instance with sequence number equal to InitialSequenceNumber can be
   originated.  See Section 12.1.6 for more information.

   Premature aging can also be used when, for example, one of the
   router's previously advertised external routes is no longer
   reachable.  In this circumstance, the router can flush its AS-
   external-LSA from the routing domain via premature aging. This
   procedure is preferable to the alternative, which is to originate a
   new LSA for the destination specifying a metric of LSInfinity.
   Premature aging is also be used when unexpectedly receiving self-
   originated LSAs during the flooding procedure (see Section 13.4).

   A router may only prematurely age its own self-originated LSAs.  The
   router may not prematurely age LSAs that have been originated by
   other routers. An LSA is considered self- originated when either 1)
   the LSA's Advertising Router is equal to the router's own Router ID
   or 2) the LSA is a network-LSA and its Link State ID is equal to one
   of the router's own IP interface addresses.

15.  Virtual Links

   The single backbone area (Area ID = 0.0.0.0) cannot be disconnected,
   or some areas of the Autonomous System will become unreachable.  To
   establish/maintain connectivity of the backbone, virtual links can be
   configured through non-backbone areas.  Virtual links serve to
   connect physically separate components of the backbone.  The two
   endpoints of a virtual link are area border routers.  The virtual
ToP   noToC   RFC2178 - Page 136
   link must be configured in both routers.  The configuration
   information in each router consists of the other virtual endpoint
   (the other area border router), and the non-backbone area the two
   routers have in common (called the Transit area).  Virtual links
   cannot be configured through stub areas (see Section 3.6).

   The virtual link is treated as if it were an unnumbered point-to-
   point network belonging to the backbone and joining the two area
   border routers.  An attempt is made to establish an adjacency over
   the virtual link.  When this adjacency is established, the virtual
   link will be included in backbone router-LSAs, and OSPF packets
   pertaining to the backbone area will flow over the adjacency.  Such
   an adjacency has been referred to in this document as a "virtual
   adjacency".

   In each endpoint router, the cost and viability of the virtual link
   is discovered by examining the routing table entry for the other
   endpoint router.  (The entry's associated area must be the configured
   Transit area).  This is called the virtual link's corresponding
   routing table entry. The InterfaceUp event occurs for a virtual link
   when its corresponding routing table entry becomes reachable.
   Conversely, the InterfaceDown event occurs when its routing table
   entry becomes unreachable.  In other words, the virtual link's
   viability is determined by the existence of an intra-area path,
   through the Transit area, between the two endpoints. Note that a
   virtual link whose underlying path has cost greater than hexadecimal
   0xffff (the maximum size of an interface cost in a router-LSA) should
   be considered inoperational (i.e., treated the same as if the path
   did not exist).

   The other details concerning virtual links are as follows:

   o AS-external-LSAs are NEVER flooded over virtual adjacencies.  This
   would be duplication of effort, since the same AS-external-LSAs are
   already flooded throughout the virtual link's Transit area.  For this
   same reason, AS-external-LSAs are not summarized over virtual
   adjacencies during the Database Exchange process.

   o The cost of a virtual link is NOT configured.  It is defined to be
   the cost of the intra-area path between the two defining area border
   routers.  This cost appears in the virtual link's corresponding
   routing table entry.  When the cost of a virtual link changes, a new
   router-LSA should be originated for the backbone area.

   o Just as the virtual link's cost and viability are determined by the
   routing table build process (through construction of the routing
   table entry for the other endpoint), so are the IP interface address
   for the virtual interface and the virtual neighbor's IP address.
ToP   noToC   RFC2178 - Page 137
   These are used when sending OSPF protocol packets over the virtual
   link. Note that when one (or both) of the virtual link endpoints
   connect to the Transit area via an unnumbered point-to-point link, it
   may be impossible to calculate either the virtual interface's IP
   address and/or the virtual neighbor's IP address, thereby causing the
   virtual link to fail.

   o In each endpoint's router-LSA for the backbone, the virtual link is
   represented as a Type 4 link whose Link ID is set to the virtual
   neighbor's OSPF Router ID and whose Link Data is set to the virtual
   interface's IP address.  See Section 12.4.1 for more information.

   o A non-backbone area can carry transit data traffic (i.e., is
   considered a "transit area") if and only if it serves as the Transit
   area for one or more fully adjacent virtual links (see
   TransitCapability in Sections 6 and 16.1). Such an area requires
   special treatment when summarizing backbone networks into it (see
   Section 12.4.3), and during the routing calculation (see Section
   16.3).

   o The time between link state retransmissions, RxmtInterval, is
   configured for a virtual link. This 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.



(page 137 continued on part 6)

Next Section