home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2328.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  448.8 KB  |  12,202 lines

  1.  
  2.  
  3.  
  4.  
  5. Network    Working    Group                          J. Moy
  6. Request    for Comments: 2328             Ascend Communications, Inc.
  7. STD: 54                                  April 1998
  8. Obsoletes: 2178
  9. Category: Standards Track
  10.  
  11.  
  12.                  OSPF Version 2
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.     This document specifies an Internet    standards track    protocol for the
  18.     Internet community,    and requests discussion    and suggestions    for
  19.     improvements.  Please refer    to the current edition of the "Internet
  20.     Official Protocol Standards" (STD 1) for the standardization state
  21.     and    status of this protocol.  Distribution of this memo is
  22.     unlimited.
  23.  
  24. Copyright Notice
  25.  
  26.     Copyright (C) The Internet Society (1998).    All Rights Reserved.
  27.  
  28. Abstract
  29.  
  30.     This memo documents    version    2 of the OSPF protocol.     OSPF is a
  31.     link-state routing protocol.  It is    designed to be run internal to a
  32.     single Autonomous System.  Each OSPF router    maintains an identical
  33.     database describing    the Autonomous System's    topology.  From    this
  34.     database, a    routing    table is calculated by constructing a shortest-
  35.     path tree.
  36.  
  37.     OSPF recalculates routes quickly in    the face of topological    changes,
  38.     utilizing a    minimum    of routing protocol traffic.  OSPF provides
  39.     support for    equal-cost multipath.  An area routing capability is
  40.     provided, enabling an additional level of routing protection and a
  41.     reduction in routing protocol traffic.  In addition, all OSPF
  42.     routing protocol exchanges are authenticated.
  43.  
  44.     The    differences between this memo and RFC 2178 are explained in
  45.     Appendix G.    All differences    are backward-compatible    in nature.
  46.  
  47.  
  48.  
  49.  
  50. Moy                Standards Track            [Page 1]
  51.  
  52. RFC 2328             OSPF Version 2              April 1998
  53.  
  54.  
  55.     Implementations of this memo and of    RFCs 2178, 1583, and 1247 will
  56.     interoperate.
  57.  
  58.     Please send    comments to ospf@gated.cornell.edu.
  59.  
  60. Table of Contents
  61.  
  62.     1         Introduction ........................................... 6
  63.     1.1         Protocol Overview ...................................... 6
  64.     1.2         Definitions of commonly used terms    ..................... 8
  65.     1.3         Brief history of link-state routing technology ........ 11
  66.     1.4         Organization of this document ......................... 12
  67.     1.5         Acknowledgments ....................................... 12
  68.     2         The link-state database: organization and calculations  13
  69.     2.1         Representation of routers and networks ................ 13
  70.     2.1.1    Representation of non-broadcast networks .............. 15
  71.     2.1.2    An    example    link-state database ........................ 18
  72.     2.2         The shortest-path tree ................................ 21
  73.     2.3         Use of external routing information ................... 23
  74.     2.4         Equal-cost    multipath .................................. 26
  75.     3         Splitting the AS into Areas ........................... 26
  76.     3.1         The backbone of the Autonomous System ................. 27
  77.     3.2         Inter-area    routing    .................................... 27
  78.     3.3         Classification of routers ............................. 28
  79.     3.4         A sample area configuration ........................... 29
  80.     3.5         IP    subnetting support ................................. 35
  81.     3.6         Supporting    stub areas ................................. 37
  82.     3.7         Partitions    of areas ................................... 38
  83.     4         Functional    Summary    .................................... 40
  84.     4.1         Inter-area    routing    .................................... 41
  85.     4.2         AS    external routes    .................................... 41
  86.     4.3         Routing protocol packets .............................. 42
  87.     4.4         Basic implementation requirements ..................... 43
  88.     4.5         Optional OSPF capabilities    ............................ 46
  89.     5         Protocol data structures .............................. 47
  90.     6         The Area Data Structure ............................... 49
  91.     7         Bringing Up Adjacencies ............................... 52
  92.     7.1         The Hello Protocol    .................................... 52
  93.     7.2         The Synchronization of Databases ...................... 53
  94.     7.3         The Designated Router ................................. 54
  95.     7.4         The Backup    Designated Router .......................... 56
  96.     7.5         The graph of adjacencies .............................. 56
  97.  
  98.  
  99.  
  100. Moy                Standards Track            [Page 2]
  101.  
  102. RFC 2328             OSPF Version 2              April 1998
  103.  
  104.  
  105.     8         Protocol Packet Processing    ............................ 58
  106.     8.1         Sending protocol packets .............................. 58
  107.     8.2         Receiving protocol    packets    ............................ 61
  108.     9         The Interface Data    Structure .......................... 63
  109.     9.1         Interface states ...................................... 67
  110.     9.2         Events causing interface state changes ................ 70
  111.     9.3         The Interface state machine ........................... 72
  112.     9.4         Electing the Designated Router ........................ 75
  113.     9.5         Sending Hello packets ................................. 77
  114.     9.5.1    Sending Hello packets on NBMA networks ................ 79
  115.     10         The Neighbor Data Structure ........................... 80
  116.     10.1     Neighbor states ....................................... 83
  117.     10.2     Events causing neighbor state changes ................. 87
  118.     10.3     The Neighbor state    machine    ............................ 89
  119.     10.4     Whether to    become adjacent    ............................ 95
  120.     10.5     Receiving Hello Packets ............................... 96
  121.     10.6     Receiving Database    Description Packets ................ 99
  122.     10.7     Receiving Link State Request Packets ................. 102
  123.     10.8     Sending Database Description Packets ................. 103
  124.     10.9     Sending Link State    Request    Packets    ................... 104
  125.     10.10    An    Example    ........................................... 105
  126.     11         The Routing Table Structure .......................... 107
  127.     11.1     Routing table lookup ................................. 111
  128.     11.2     Sample routing table, without areas .................. 111
  129.     11.3     Sample routing table, with    areas ..................... 112
  130.     12         Link State    Advertisements (LSAs) ..................... 115
  131.     12.1     The LSA Header ....................................... 116
  132.     12.1.1   LS    age ............................................... 116
  133.     12.1.2   Options .............................................. 117
  134.     12.1.3   LS    type .............................................. 117
  135.     12.1.4   Link State    ID ........................................ 117
  136.     12.1.5   Advertising Router    ................................... 119
  137.     12.1.6   LS    sequence number    ................................... 120
  138.     12.1.7   LS    checksum .......................................... 121
  139.     12.2     The link state database .............................. 121
  140.     12.3     Representation of TOS ................................ 122
  141.     12.4     Originating LSAs ..................................... 123
  142.     12.4.1   Router-LSAs .......................................... 126
  143.     12.4.1.1 Describing    point-to-point interfaces ................. 130
  144.     12.4.1.2 Describing    broadcast and NBMA interfaces ............. 130
  145.     12.4.1.3 Describing    virtual    links ............................. 131
  146.     12.4.1.4 Describing    Point-to-MultiPoint interfaces ............ 131
  147.  
  148.  
  149.  
  150. Moy                Standards Track            [Page 3]
  151.  
  152. RFC 2328             OSPF Version 2              April 1998
  153.  
  154.  
  155.     12.4.1.5 Examples of router-LSAs .............................. 132
  156.     12.4.2   Network-LSAs ......................................... 133
  157.     12.4.2.1 Examples of network-LSAs ............................. 134
  158.     12.4.3   Summary-LSAs ......................................... 135
  159.     12.4.3.1 Originating summary-LSAs into stub    areas ............. 137
  160.     12.4.3.2 Examples of summary-LSAs ............................. 138
  161.     12.4.4   AS-external-LSAs ..................................... 139
  162.     12.4.4.1 Examples of AS-external-LSAs ......................... 140
  163.     13         The Flooding Procedure ............................... 143
  164.     13.1     Determining which LSA is newer ....................... 146
  165.     13.2     Installing    LSAs in    the database ...................... 147
  166.     13.3     Next step in the flooding procedure .................. 148
  167.     13.4     Receiving self-originated LSAs ....................... 151
  168.     13.5     Sending Link State    Acknowledgment packets ............ 152
  169.     13.6     Retransmitting LSAs .................................. 154
  170.     13.7     Receiving link state acknowledgments ................. 155
  171.     14         Aging The Link State Database ........................ 156
  172.     14.1     Premature aging of    LSAs .............................. 157
  173.     15         Virtual Links ........................................ 158
  174.     16         Calculation of the    routing    table ..................... 160
  175.     16.1     Calculating the shortest-path tree    for an area ....... 161
  176.     16.1.1   The next hop calculation ............................. 167
  177.     16.2     Calculating the inter-area    routes .................... 178
  178.     16.3     Examining transit areas' summary-LSAs ................ 170
  179.     16.4     Calculating AS external routes ....................... 173
  180.     16.4.1   External path preferences ............................ 175
  181.     16.5     Incremental updates -- summary-LSAs .................. 175
  182.     16.6     Incremental updates -- AS-external-LSAs .............. 177
  183.     16.7     Events generated as a result of routing table changes  177
  184.     16.8     Equal-cost    multipath ................................. 178
  185.          Footnotes ............................................ 179
  186.          References    ........................................... 183
  187.     A         OSPF data formats .................................... 185
  188.     A.1         Encapsulation of OSPF packets ........................ 185
  189.     A.2         The Options field .................................... 187
  190.     A.3         OSPF Packet Formats .................................. 189
  191.     A.3.1    The OSPF packet header ............................... 190
  192.     A.3.2    The Hello packet ..................................... 193
  193.     A.3.3    The Database Description packet ...................... 195
  194.     A.3.4    The Link State Request packet ........................ 197
  195.     A.3.5    The Link State Update packet ......................... 199
  196.     A.3.6    The Link State Acknowledgment packet ................. 201
  197.  
  198.  
  199.  
  200. Moy                Standards Track            [Page 4]
  201.  
  202. RFC 2328             OSPF Version 2              April 1998
  203.  
  204.  
  205.     A.4         LSA formats .......................................... 203
  206.     A.4.1    The LSA header ....................................... 204
  207.     A.4.2    Router-LSAs .......................................... 206
  208.     A.4.3    Network-LSAs ......................................... 210
  209.     A.4.4    Summary-LSAs ......................................... 212
  210.     A.4.5    AS-external-LSAs ..................................... 214
  211.     B         Architectural Constants .............................. 217
  212.     C         Configurable Constants ............................... 219
  213.     C.1         Global parameters .................................... 219
  214.     C.2         Area parameters ...................................... 220
  215.     C.3         Router interface parameters .......................... 221
  216.     C.4         Virtual link parameters .............................. 224
  217.     C.5         NBMA network parameters .............................. 224
  218.     C.6         Point-to-MultiPoint network parameters ............... 225
  219.     C.7         Host route    parameters ................................ 226
  220.     D         Authentication ....................................... 227
  221.     D.1         Null authentication .................................. 227
  222.     D.2         Simple password authentication ....................... 228
  223.     D.3         Cryptographic authentication ......................... 228
  224.     D.4         Message generation    ................................... 231
  225.     D.4.1    Generating    Null authentication ....................... 231
  226.     D.4.2    Generating    Simple password    authentication ............ 232
  227.     D.4.3    Generating    Cryptographic authentication .............. 232
  228.     D.5         Message verification ................................. 234
  229.     D.5.1    Verifying Null authentication ........................ 234
  230.     D.5.2    Verifying Simple password authentication ............. 234
  231.     D.5.3    Verifying Cryptographic authentication ............... 235
  232.     E         An    algorithm for assigning    Link State IDs ............ 236
  233.     F         Multiple interfaces to the    same network/subnet ....... 239
  234.     G         Differences from RFC 2178 ............................ 240
  235.     G.1         Flooding modifications ............................... 240
  236.     G.2         Changes to    external path preferences ................. 241
  237.     G.3         Incomplete    resolution of virtual next hops    ........... 241
  238.     G.4         Routing table lookup ................................. 241
  239.          Security Considerations .............................. 243
  240.          Author's Address ..................................... 243
  241.          Full Copyright Statement ............................. 244
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250. Moy                Standards Track            [Page 5]
  251.  
  252. RFC 2328             OSPF Version 2              April 1998
  253.  
  254.  
  255. 1.  Introduction
  256.  
  257.     This document is a specification of    the Open Shortest Path First
  258.     (OSPF) TCP/IP internet routing protocol.  OSPF is classified as an
  259.     Interior Gateway Protocol (IGP).  This means that it distributes
  260.     routing information    between    routers    belonging to a single Autonomous
  261.     System.  The OSPF protocol is based    on link-state or SPF technology.
  262.     This is a departure    from the Bellman-Ford base used    by traditional
  263.     TCP/IP internet routing protocols.
  264.  
  265.     The    OSPF protocol was developed by the OSPF    working    group of the
  266.     Internet Engineering Task Force.  It has been designed expressly for
  267.     the    TCP/IP internet    environment, including explicit    support    for CIDR
  268.     and    the tagging of externally-derived routing information.    OSPF
  269.     also provides for the authentication of routing updates, and
  270.     utilizes IP    multicast when sending/receiving the updates.  In
  271.     addition, much work    has been done to produce a protocol that
  272.     responds quickly to    topology changes, yet involves small amounts of
  273.     routing protocol traffic.
  274.  
  275.     1.1.  Protocol overview
  276.  
  277.     OSPF routes IP packets based solely on the destination IP
  278.     address    found in the IP    packet header.    IP packets are routed
  279.     "as is"    -- they    are not    encapsulated in    any further protocol
  280.     headers    as they    transit    the Autonomous System.    OSPF is    a
  281.     dynamic    routing    protocol.  It quickly detects topological
  282.     changes    in the AS (such    as router interface failures) and
  283.     calculates new loop-free routes    after a    period of convergence.
  284.     This period of convergence is short and    involves a minimum of
  285.     routing    traffic.
  286.  
  287.     In a link-state    routing    protocol, each router maintains    a
  288.     database describing the    Autonomous System's topology.  This
  289.     database is referred to    as the link-state database. Each
  290.     participating router has an identical database.     Each individual
  291.     piece of this database is a particular router's    local state
  292.     (e.g., the router's usable interfaces and reachable neighbors).
  293.     The router distributes its local state throughout the Autonomous
  294.     System by flooding.
  295.  
  296.  
  297.  
  298.  
  299.  
  300. Moy                Standards Track            [Page 6]
  301.  
  302. RFC 2328             OSPF Version 2              April 1998
  303.  
  304.  
  305.     All routers run    the exact same algorithm, in parallel.    From the
  306.     link-state database, each router constructs a tree of shortest
  307.     paths with itself as root.  This shortest-path tree gives the
  308.     route to each destination in the Autonomous System.  Externally
  309.     derived    routing    information appears on the tree    as leaves.
  310.  
  311.     When several equal-cost    routes to a destination    exist, traffic
  312.     is distributed equally among them.  The    cost of    a route    is
  313.     described by a single dimensionless metric.
  314.  
  315.     OSPF allows sets of networks to    be grouped together.  Such a
  316.     grouping is called an area.  The topology of an    area is    hidden
  317.     from the rest of the Autonomous    System.     This information hiding
  318.     enables    a significant reduction    in routing traffic.  Also,
  319.     routing    within the area    is determined only by the area's own
  320.     topology, lending the area protection from bad routing data.  An
  321.     area is    a generalization of an IP subnetted network.
  322.  
  323.     OSPF enables the flexible configuration    of IP subnets.    Each
  324.     route distributed by OSPF has a    destination and    mask.  Two
  325.     different subnets of the same IP network number    may have
  326.     different sizes    (i.e., different masks).  This is commonly
  327.     referred to as variable    length subnetting.  A packet is    routed
  328.     to the best (i.e., longest or most specific) match.  Host routes
  329.     are considered to be subnets whose masks are "all ones"
  330.     (0xffffffff).
  331.  
  332.     All OSPF protocol exchanges are    authenticated.    This means that
  333.     only trusted routers can participate in    the Autonomous System's
  334.     routing.  A variety of authentication schemes can be used; in
  335.     fact, separate authentication schemes can be configured    for each
  336.     IP subnet.
  337.  
  338.     Externally derived routing data    (e.g., routes learned from an
  339.     Exterior Gateway Protocol such as BGP; see [Ref23]) is
  340.     advertised throughout the Autonomous System.  This externally
  341.     derived    data is    kept separate from the OSPF protocol's link
  342.     state data.  Each external route can also be tagged by the
  343.     advertising router, enabling the passing of additional
  344.     information between routers on the boundary of the Autonomous
  345.     System.
  346.  
  347.  
  348.  
  349.  
  350. Moy                Standards Track            [Page 7]
  351.  
  352. RFC 2328             OSPF Version 2              April 1998
  353.  
  354.  
  355.     1.2.  Definitions of commonly used terms
  356.  
  357.     This section provides definitions for terms that have a    specific
  358.     meaning    to the OSPF protocol and that are used throughout the
  359.     text.  The reader unfamiliar with the Internet Protocol    Suite is
  360.     referred to [Ref13] for    an introduction    to IP.
  361.  
  362.  
  363.     Router
  364.         A level three Internet Protocol packet switch.  Formerly
  365.         called a gateway in    much of    the IP literature.
  366.  
  367.     Autonomous System
  368.         A group of routers exchanging routing information via a
  369.         common routing protocol.  Abbreviated as AS.
  370.  
  371.     Interior Gateway Protocol
  372.         The    routing    protocol spoken    by the routers belonging to an
  373.         Autonomous system.    Abbreviated as IGP.  Each Autonomous
  374.         System has a single    IGP.  Separate Autonomous Systems may be
  375.         running different IGPs.
  376.  
  377.     Router ID
  378.         A 32-bit number assigned to    each router running the    OSPF
  379.         protocol.  This number uniquely identifies the router within
  380.         an Autonomous System.
  381.  
  382.     Network
  383.         In this memo, an IP    network/subnet/supernet.  It is    possible
  384.         for    one physical network to    be assigned multiple IP
  385.         network/subnet numbers.  We    consider these to be separate
  386.         networks.  Point-to-point physical networks    are an exception
  387.         - they are considered a single network no matter how many
  388.         (if    any at all) IP network/subnet numbers are assigned to
  389.         them.
  390.  
  391.     Network    mask
  392.         A 32-bit number indicating the range of IP addresses
  393.         residing on    a single IP network/subnet/supernet.  This
  394.         specification displays network masks as hexadecimal    numbers.
  395.  
  396.  
  397.  
  398.  
  399.  
  400. Moy                Standards Track            [Page 8]
  401.  
  402. RFC 2328             OSPF Version 2              April 1998
  403.  
  404.  
  405.         For    example, the network mask for a    class C    IP network is
  406.         displayed as 0xffffff00.  Such a mask is often displayed
  407.         elsewhere in the literature    as 255.255.255.0.
  408.  
  409.     Point-to-point networks
  410.         A network that joins a single pair of routers.  A 56Kb
  411.         serial line    is an example of a point-to-point network.
  412.  
  413.     Broadcast networks
  414.         Networks supporting    many (more than    two) attached routers,
  415.         together with the capability to address a single physical
  416.         message to all of the attached routers (broadcast).
  417.         Neighboring    routers    are discovered dynamically on these nets
  418.         using OSPF's Hello Protocol.  The Hello Protocol itself
  419.         takes advantage of the broadcast capability.  The OSPF
  420.         protocol makes further use of multicast capabilities, if
  421.         they exist.     Each pair of routers on a broadcast network is
  422.         assumed to be able to communicate directly.    An ethernet is
  423.         an example of a broadcast network.
  424.  
  425.     Non-broadcast networks
  426.         Networks supporting    many (more than    two) routers, but having
  427.         no broadcast capability.  Neighboring routers are maintained
  428.         on these nets using    OSPF's Hello Protocol.    However, due to
  429.         the    lack of    broadcast capability, some configuration
  430.         information    may be necessary to aid    in the discovery of
  431.         neighbors.    On non-broadcast networks, OSPF    protocol packets
  432.         that are normally multicast    need to    be sent    to each
  433.         neighboring    router,    in turn. An X.25 Public    Data Network
  434.         (PDN) is an    example    of a non-broadcast network.
  435.  
  436.         OSPF runs in one of    two modes over non-broadcast networks.
  437.         The    first mode, called non-broadcast multi-access or NBMA,
  438.         simulates the operation of OSPF on a broadcast network. The
  439.         second mode, called    Point-to-MultiPoint, treats the    non-
  440.         broadcast network as a collection of point-to-point    links.
  441.         Non-broadcast networks are referred    to as NBMA networks or
  442.         Point-to-MultiPoint    networks, depending on OSPF's mode of
  443.         operation over the network.
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Moy                Standards Track            [Page 9]
  451.  
  452. RFC 2328             OSPF Version 2              April 1998
  453.  
  454.  
  455.     Interface
  456.         The    connection between a router and    one of its attached
  457.         networks.  An interface has    state information associated
  458.         with it, which is obtained from the    underlying lower level
  459.         protocols and the routing protocol itself.    An interface to
  460.         a network has associated with it a single IP address and
  461.         mask (unless the network is    an unnumbered point-to-point
  462.         network).  An interface is sometimes also referred to as a
  463.         link.
  464.  
  465.     Neighboring routers
  466.         Two    routers    that have interfaces to    a common network.
  467.         Neighbor relationships are maintained by, and usually
  468.         dynamically    discovered by, OSPF's Hello Protocol.
  469.  
  470.     Adjacency
  471.         A relationship formed between selected neighboring routers
  472.         for    the purpose of exchanging routing information.    Not
  473.         every pair of neighboring routers become adjacent.
  474.  
  475.     Link state advertisement
  476.         Unit of data describing the    local state of a router    or
  477.         network. For a router, this    includes the state of the
  478.         router's interfaces    and adjacencies.  Each link state
  479.         advertisement is flooded throughout    the routing domain. The
  480.         collected link state advertisements    of all routers and
  481.         networks forms the protocol's link state database.
  482.         Throughout this memo, link state advertisement is
  483.         abbreviated    as LSA.
  484.  
  485.     Hello Protocol
  486.         The    part of    the OSPF protocol used to establish and    maintain
  487.         neighbor relationships.  On    broadcast networks the Hello
  488.         Protocol can also dynamically discover neighboring routers.
  489.  
  490.     Flooding
  491.         The    part of    the OSPF protocol that distributes and
  492.         synchronizes the link-state    database between OSPF routers.
  493.  
  494.     Designated Router
  495.         Each broadcast and NBMA network that has at    least two
  496.         attached routers has a Designated Router.  The Designated
  497.  
  498.  
  499.  
  500. Moy                Standards Track               [Page 10]
  501.  
  502. RFC 2328             OSPF Version 2              April 1998
  503.  
  504.  
  505.         Router generates an    LSA for    the network and    has other
  506.         special responsibilities in    the running of the protocol.
  507.         The    Designated Router is elected by    the Hello Protocol.
  508.  
  509.         The    Designated Router concept enables a reduction in the
  510.         number of adjacencies required on a    broadcast or NBMA
  511.         network.  This in turn reduces the amount of routing
  512.         protocol traffic and the size of the link-state database.
  513.  
  514.     Lower-level protocols
  515.         The    underlying network access protocols that provide
  516.         services to    the Internet Protocol and in turn the OSPF
  517.         protocol.  Examples    of these are the X.25 packet and frame
  518.         levels for X.25 PDNs, and the ethernet data    link layer for
  519.         ethernets.
  520.  
  521.  
  522.     1.3.  Brief    history    of link-state routing technology
  523.  
  524.     OSPF is    a link state routing protocol.    Such protocols are also
  525.     referred to in the literature as SPF-based or distributed-
  526.     database protocols.  This section gives    a brief    description of
  527.     the developments in link-state technology that have influenced
  528.     the OSPF protocol.
  529.  
  530.     The first link-state routing protocol was developed for    use in
  531.     the ARPANET packet switching network.  This protocol is
  532.     described in [Ref3].  It has formed the    starting point for all
  533.     other link-state protocols.  The homogeneous ARPANET
  534.     environment, i.e., single-vendor packet    switches connected by
  535.     synchronous serial lines, simplified the design    and
  536.     implementation of the original protocol.
  537.  
  538.     Modifications to this protocol were proposed in    [Ref4].     These
  539.     modifications dealt with increasing the    fault tolerance    of the
  540.     routing    protocol through, among    other things, adding a checksum
  541.     to the LSAs (thereby detecting database    corruption).  The paper
  542.     also included means for    reducing the routing traffic overhead in
  543.     a link-state protocol.    This was accomplished by introducing
  544.     mechanisms which enabled the interval between LSA originations
  545.     to be increased    by an order of magnitude.
  546.  
  547.  
  548.  
  549.  
  550. Moy                Standards Track               [Page 11]
  551.  
  552. RFC 2328             OSPF Version 2              April 1998
  553.  
  554.  
  555.     A link-state algorithm has also    been proposed for use as an ISO
  556.     IS-IS routing protocol.     This protocol is described in [Ref2].
  557.     The protocol includes methods for data and routing traffic
  558.     reduction when operating over broadcast    networks.  This    is
  559.     accomplished by    election of a Designated Router    for each
  560.     broadcast network, which then originates an LSA    for the    network.
  561.  
  562.     The OSPF Working Group of the IETF has extended    this work in
  563.     developing the OSPF protocol.  The Designated Router concept has
  564.     been greatly enhanced to further reduce    the amount of routing
  565.     traffic    required.  Multicast capabilities are utilized for
  566.     additional routing bandwidth reduction.     An area routing scheme
  567.     has been developed enabling information
  568.     hiding/protection/reduction.  Finally, the algorithms have been
  569.     tailored for efficient operation in TCP/IP internets.
  570.  
  571.  
  572.     1.4.  Organization of this document
  573.  
  574.     The first three    sections of this specification give a general
  575.     overview of the    protocol's capabilities    and functions.    Sections
  576.     4-16 explain the protocol's mechanisms in detail.  Packet
  577.     formats, protocol constants and    configuration items are
  578.     specified in the appendices.
  579.  
  580.     Labels such as HelloInterval encountered in the    text refer to
  581.     protocol constants.  They may or may not be configurable.
  582.     Architectural constants    are summarized in Appendix B.
  583.     Configurable constants are summarized in Appendix C.
  584.  
  585.     The detailed specification of the protocol is presented    in terms
  586.     of data    structures.  This is done in order to make the
  587.     explanation more precise.  Implementations of the protocol are
  588.     required to support the    functionality described, but need not
  589.     use the    precise    data structures    that appear in this memo.
  590.  
  591.  
  592.     1.5.  Acknowledgments
  593.  
  594.     The author would like to thank Ran Atkinson, Fred Baker, Jeffrey
  595.     Burgan,    Rob Coltun, Dino Farinacci, Vince Fuller, Phanindra
  596.     Jujjavarapu, Milo Medin, Tom Pusateri, Kannan Varadhan,    Zhaohui
  597.  
  598.  
  599.  
  600. Moy                Standards Track               [Page 12]
  601.  
  602. RFC 2328             OSPF Version 2              April 1998
  603.  
  604.  
  605.     Zhang and the rest of the OSPF Working Group for the ideas and
  606.     support    they have given    to this    project.
  607.  
  608.     The OSPF Point-to-MultiPoint interface is based    on work    done by
  609.     Fred Baker.
  610.  
  611.     The OSPF Cryptographic Authentication option was developed by
  612.     Fred Baker and Ran Atkinson.
  613.  
  614.  
  615. 2.  The    Link-state Database: organization and calculations
  616.  
  617.     The    following subsections describe the organization    of OSPF's link-
  618.     state database, and    the routing calculations that are performed on
  619.     the    database in order to produce a router's    routing    table.
  620.  
  621.  
  622.     2.1.  Representation of routers and    networks
  623.  
  624.     The Autonomous System's    link-state database describes a    directed
  625.     graph.    The vertices of    the graph consist of routers and
  626.     networks.  A graph edge    connects two routers when they are
  627.     attached via a physical    point-to-point network.     An edge
  628.     connecting a router to a network indicates that    the router has
  629.     an interface on    the network. Networks can be either transit or
  630.     stub networks. Transit networks    are those capable of carrying
  631.     data traffic that is neither locally originated    nor locally
  632.     destined. A transit network is represented by a    graph vertex
  633.     having both incoming and outgoing edges. A stub    network's vertex
  634.     has only incoming edges.
  635.  
  636.     The neighborhood of each network node in the graph depends on
  637.     the network's type (point-to-point, broadcast, NBMA or Point-
  638.     to-MultiPoint) and the number of routers having    an interface to
  639.     the network.  Three cases are depicted in Figure 1a.  Rectangles
  640.     indicate routers.  Circles and oblongs indicate    networks.
  641.     Router names are prefixed with the letters RT and network names
  642.     with the letter    N.  Router interface names are prefixed    by the
  643.     letter I.  Lines between routers indicate point-to-point
  644.     networks.  The left side of the    figure shows networks with their
  645.     connected routers, with    the resulting graphs shown on the right.
  646.  
  647.  
  648.  
  649.  
  650. Moy                Standards Track               [Page 13]
  651.  
  652. RFC 2328             OSPF Version 2              April 1998
  653.  
  654.  
  655.  
  656.  
  657.  
  658.                           **FROM**
  659.  
  660.                        *      |RT1|RT2|
  661.         +---+Ia       +---+       *   ------------
  662.         |RT1|------|RT2|       T   RT1|   |    X |
  663.         +---+     Ib+---+       O   RT2| X |      |
  664.                        *    Ia|   |    X |
  665.                        *    Ib| X |      |
  666.  
  667.              Physical point-to-point networks
  668.  
  669.  
  670.                           **FROM**
  671.               +---+           *
  672.               |RT7|           *      |RT7|    N3|
  673.               +---+           T   ------------
  674.             |           O   RT7|   |      |
  675.         +----------------------+       *    N3| X |      |
  676.                N3           *
  677.  
  678.                   Stub networks
  679.  
  680.                           **FROM**
  681.         +---+       +---+
  682.         |RT3|       |RT4|          |RT3|RT4|RT5|RT6|N2 |
  683.         +---+       +---+    *  ------------------------
  684.           |    N2    |        *  RT3|      |   |      |   |    X |
  685.         +----------------------+    T  RT4|      |   |      |   |    X |
  686.           |         |        O  RT5|      |   |      |   |    X |
  687.         +---+       +---+    *  RT6|      |   |      |   |    X |
  688.         |RT5|       |RT6|    *   N2|    X | X |    X | X |      |
  689.         +---+       +---+
  690.  
  691.               Broadcast or NBMA networks
  692.  
  693.  
  694.  
  695.             Figure 1a: Network map components
  696.  
  697.  
  698.  
  699.  
  700. Moy                Standards Track               [Page 14]
  701.  
  702. RFC 2328             OSPF Version 2              April 1998
  703.  
  704.  
  705.          Networks and routers are represented by vertices.
  706.          An    edge connects Vertex A to Vertex B iff the
  707.          intersection of Column A and Row B    is marked with
  708.                   an X.
  709.  
  710.  
  711.  
  712.     The top    of Figure 1a shows two routers connected by a point-to-
  713.     point link. In the resulting link-state    database graph,    the two
  714.     router vertices    are directly connected by a pair of edges, one
  715.     in each    direction. Interfaces to point-to-point    networks need
  716.     not be assigned    IP addresses.  When interface addresses    are
  717.     assigned, they are modelled as stub links, with    each router
  718.     advertising a stub connection to the other router's interface
  719.     address. Optionally, an    IP subnet can be assigned to the point-
  720.     to-point network. In this case,    both routers advertise a stub
  721.     link to    the IP subnet, instead of advertising each others' IP
  722.     interface addresses.
  723.  
  724.     The middle of Figure 1a    shows a    network    with only one attached
  725.     router (i.e., a    stub network). In this case, the network appears
  726.     on the end of a    stub connection    in the link-state database's
  727.     graph.
  728.  
  729.     When multiple routers are attached to a    broadcast network, the
  730.     link-state database graph shows    all routers bidirectionally
  731.     connected to the network vertex. This is pictured at the bottom
  732.     of Figure 1a.
  733.  
  734.     Each network (stub or transit) in the graph has    an IP address
  735.     and associated network mask.  The mask indicates the number of
  736.     nodes on the network.  Hosts attached directly to routers
  737.     (referred to as    host routes) appear on the graph as stub
  738.     networks.  The network mask for    a host route is    always
  739.     0xffffffff, which indicates the    presence of a single node.
  740.  
  741.  
  742.     2.1.1.    Representation of non-broadcast    networks
  743.  
  744.         As mentioned previously, OSPF can run over non-broadcast
  745.         networks in    one of two modes: NBMA or Point-to-MultiPoint.
  746.         The    choice of mode determines the way that the Hello
  747.  
  748.  
  749.  
  750. Moy                Standards Track               [Page 15]
  751.  
  752. RFC 2328             OSPF Version 2              April 1998
  753.  
  754.  
  755.         protocol and flooding work over the    non-broadcast network,
  756.         and    the way    that the network is represented    in the link-
  757.         state database.
  758.  
  759.         In NBMA mode, OSPF emulates    operation over a broadcast
  760.         network: a Designated Router is elected for    the NBMA
  761.         network, and the Designated    Router originates an LSA for the
  762.         network. The graph representation for broadcast networks and
  763.         NBMA networks is identical.    This representation is pictured
  764.         in the middle of Figure 1a.
  765.  
  766.         NBMA mode is the most efficient way    to run OSPF over non-
  767.         broadcast networks,    both in    terms of link-state database
  768.         size and in    terms of the amount of routing protocol    traffic.
  769.         However, it    has one    significant restriction: it requires all
  770.         routers attached to    the NBMA network to be able to
  771.         communicate    directly. This restriction may be met on some
  772.         non-broadcast networks, such as an ATM subnet utilizing
  773.         SVCs. But it is often not met on other non-broadcast
  774.         networks, such as PVC-only Frame Relay networks. On    non-
  775.         broadcast networks where not all routers can communicate
  776.         directly you can break the non-broadcast network into
  777.         logical subnets, with the routers on each subnet being able
  778.         to communicate directly, and then run each separate    subnet
  779.         as an NBMA network (see [Ref15]). This however requires
  780.         quite a bit    of administrative overhead, and    is prone to
  781.         misconfiguration. It is probably better to run such    a non-
  782.         broadcast network in Point-to-Multipoint mode.
  783.  
  784.         In Point-to-MultiPoint mode, OSPF treats all router-to-
  785.         router connections over the    non-broadcast network as if they
  786.         were point-to-point    links. No Designated Router is elected
  787.         for    the network, nor is there an LSA generated for the
  788.         network. In    fact, a    vertex for the Point-to-MultiPoint
  789.         network does not appear in the graph of the    link-state
  790.         database.
  791.  
  792.         Figure 1b illustrates the link-state database representation
  793.         of a Point-to-MultiPoint network. On the left side of the
  794.         figure, a Point-to-MultiPoint network is pictured. It is
  795.         assumed that all routers can communicate directly, except
  796.         for    routers    RT4 and    RT5. I3    though I6 indicate the routers'
  797.  
  798.  
  799.  
  800. Moy                Standards Track               [Page 16]
  801.  
  802. RFC 2328             OSPF Version 2              April 1998
  803.  
  804.  
  805.         IP interface addresses on the Point-to-MultiPoint network.
  806.         In the graphical representation of the link-state database,
  807.         routers that can communicate directly over the Point-to-
  808.         MultiPoint network are joined by bidirectional edges, and
  809.         each router    also has a stub    connection to its own IP
  810.         interface address (which is    in contrast to the
  811.         representation of real point-to-point links; see Figure 1a).
  812.  
  813.         On some non-broadcast networks, use    of Point-to-MultiPoint
  814.         mode and data-link protocols such as Inverse ARP (see
  815.         [Ref14]) will allow    autodiscovery of OSPF neighbors    even
  816.         though broadcast support is    not available.
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.                           **FROM**
  824.         +---+       +---+
  825.         |RT3|       |RT4|          |RT3|RT4|RT5|RT6|
  826.         +---+       +---+    *  --------------------
  827.         I3|    N2    |I4    *  RT3|      | X |    X | X |
  828.         +----------------------+    T  RT4|    X |   |      | X |
  829.         I5|         |I6    O  RT5|    X |   |      | X |
  830.         +---+       +---+    *  RT6|    X | X |    X |   |
  831.         |RT5|       |RT6|    *   I3|    X |   |      |   |
  832.         +---+       +---+        I4|      | X |      |   |
  833.                         I5|      |   |    X |   |
  834.                         I6|      |   |      | X |
  835.  
  836.  
  837.  
  838.             Figure 1b: Network map components
  839.                Point-to-MultiPoint networks
  840.  
  841.          All routers can communicate directly over N2, except
  842.         routers    RT4 and    RT5. I3    through    I6 indicate IP
  843.                interface addresses
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850. Moy                Standards Track               [Page 17]
  851.  
  852. RFC 2328             OSPF Version 2              April 1998
  853.  
  854.  
  855.     2.1.2.    An example link-state database
  856.  
  857.         Figure 2 shows a sample map    of an Autonomous System.  The
  858.         rectangle labelled H1 indicates a host, which has a    SLIP
  859.         connection to Router RT12.    Router RT12 is therefore
  860.         advertising    a host route.  Lines between routers indicate
  861.         physical point-to-point networks.  The only    point-to-point
  862.         network that has been assigned interface addresses is the
  863.         one    joining    Routers    RT6 and    RT10.  Routers RT5 and RT7 have
  864.         BGP    connections to other Autonomous    Systems.  A set    of BGP-
  865.         learned routes have    been displayed for both    of these
  866.         routers.
  867.  
  868.         A cost is associated with the output side of each router
  869.         interface.    This cost is configurable by the system
  870.         administrator.  The    lower the cost,    the more likely    the
  871.         interface is to be used to forward data traffic.  Costs are
  872.         also associated with the externally    derived    routing    data
  873.         (e.g., the BGP-learned routes).
  874.  
  875.         The    directed graph resulting from the map in Figure    2 is
  876.         depicted in    Figure 3.  Arcs    are labelled with the cost of
  877.         the    corresponding router output interface.    Arcs having no
  878.         labelled cost have a cost of 0.  Note that arcs leading from
  879.         networks to    routers    always have cost 0; they are significant
  880.         nonetheless.  Note also that the externally    derived    routing
  881.         data appears on the    graph as stubs.
  882.  
  883.         The    link-state database is pieced together from LSAs
  884.         generated by the routers.  In the associated graphical
  885.         representation, the    neighborhood of    each router or transit
  886.         network is represented in a    single,    separate LSA.  Figure 4
  887.         shows these    LSAs graphically. Router RT12 has an interface
  888.         to two broadcast networks and a SLIP line to a host.
  889.         Network N6 is a broadcast network with three attached
  890.         routers.  The cost of all links from Network N6 to its
  891.         attached routers is    0.  Note that the LSA for Network N6 is
  892.         actually generated by one of the network's attached    routers:
  893.         the    router that has    been elected Designated    Router for the
  894.         network.
  895.  
  896.  
  897.  
  898.  
  899.  
  900. Moy                Standards Track               [Page 18]
  901.  
  902. RFC 2328             OSPF Version 2              April 1998
  903.  
  904.  
  905.  
  906.          +
  907.          | 3+---+              N12      N14
  908.            N1|--|RT1|\ 1            \ N13 /
  909.          |  +---+ \            8\ |8/8
  910.          +       \ ____          \|/
  911.                 /     \   1+---+8    8+---+6
  912.                *  N3  *---|RT4|------|RT5|--------+
  913.                 \____/    +---+     +---+          |
  914.           +        /    |           |7          |
  915.           | 3+---+ /    |           |          |
  916.         N2|--|RT2|/1    |1           |6          |
  917.           |  +---+    +---+8        6+---+          |
  918.           +          |RT3|--------------|RT6|          |
  919.                   +---+         +---+          |
  920.                 |2         Ia|7          |
  921.                 |           |          |
  922.                +---------+           |          |
  923.                    N4           |          |
  924.                            |          |
  925.                            |          |
  926.                N11               |          |
  927.            +---------+               |          |
  928.             |               |          |       N12
  929.             |3               |          |6 2/
  930.               +---+               |        +---+/
  931.               |RT9|               |        |RT7|---N15
  932.               +---+               |        +---+ 9
  933.             |1             +       |          |1
  934.                _|__             |     Ib|5        __|_
  935.               /       \      1+----+2   |    3+----+1   /    \
  936.              *    N9  *------|RT11|----|---|RT10|---*  N6     *
  937.               \____/       +----+    |     +----+       \____/
  938.             |             |              |
  939.             |1             +              |1
  940.          +--+   10+----+            N8            +---+
  941.          |H1|-----|RT12|                    |RT8|
  942.          +--+SLIP +----+                    +---+
  943.             |2                      |4
  944.             |                      |
  945.            +---------+                  +--------+
  946.                N10                      N7
  947.  
  948.  
  949.  
  950. Moy                Standards Track               [Page 19]
  951.  
  952. RFC 2328             OSPF Version 2              April 1998
  953.  
  954.  
  955.             Figure 2: A    sample Autonomous System
  956.  
  957.                 **FROM**
  958.  
  959.          |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
  960.          |1 |2 |3 |4 |5    |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
  961.           ----- ---------------------------------------------
  962.           RT1|  |  |  |  |    |  |  |     |  |  |  |  |0    |  |  |     |
  963.           RT2|  |  |  |  |    |  |  |     |  |  |  |  |0    |  |  |     |
  964.           RT3|  |  |  |  |    |6 |  |     |  |  |  |  |0    |  |  |     |
  965.           RT4|  |  |  |  |8    |  |  |     |  |  |  |  |0    |  |  |     |
  966.           RT5|  |  |  |8 |    |6 |6 |     |  |  |  |  |    |  |  |     |
  967.           RT6|  |  |8 |  |7    |  |  |     |  |5 |  |  |    |  |  |     |
  968.           RT7|  |  |  |  |6    |  |  |     |  |  |  |  |    |0 |  |     |
  969.       *   RT8|  |  |  |  |    |  |  |     |  |  |  |  |    |0 |  |     |
  970.       *   RT9|  |  |  |  |    |  |  |     |  |  |  |  |    |  |  |0 |
  971.       T  RT10|  |  |  |  |    |7 |  |     |  |  |  |  |    |0 |0 |     |
  972.       O  RT11|  |  |  |  |    |  |  |     |  |  |  |  |    |  |0 |0 |
  973.       *  RT12|  |  |  |  |    |  |  |     |  |  |  |  |    |  |  |0 |
  974.       *    N1|3 |  |  |  |    |  |  |     |  |  |  |  |    |  |  |     |
  975.            N2|  |3 |  |  |    |  |  |     |  |  |  |  |    |  |  |     |
  976.            N3|1 |1 |1 |1 |    |  |  |     |  |  |  |  |    |  |  |     |
  977.            N4|  |  |2 |  |    |  |  |     |  |  |  |  |    |  |  |     |
  978.            N6|  |  |  |  |    |  |1 |1 |  |1 |  |  |    |  |  |     |
  979.            N7|  |  |  |  |    |  |  |4 |  |  |  |  |    |  |  |     |
  980.            N8|  |  |  |  |    |  |  |     |  |3 |2 |  |    |  |  |     |
  981.            N9|  |  |  |  |    |  |  |     |1 |  |1 |1 |    |  |  |     |
  982.           N10|  |  |  |  |    |  |  |     |  |  |  |2 |    |  |  |     |
  983.           N11|  |  |  |  |    |  |  |     |3 |  |  |  |    |  |  |     |
  984.           N12|  |  |  |  |8    |  |2 |     |  |  |  |  |    |  |  |     |
  985.           N13|  |  |  |  |8    |  |  |     |  |  |  |  |    |  |  |     |
  986.           N14|  |  |  |  |8    |  |  |     |  |  |  |  |    |  |  |     |
  987.           N15|  |  |  |  |    |  |9 |     |  |  |  |  |    |  |  |     |
  988.            H1|  |  |  |  |    |  |  |     |  |  |  |10|    |  |  |     |
  989.  
  990.  
  991.              Figure 3: The resulting directed graph
  992.  
  993.          Networks and routers are represented by vertices.
  994.          An edge of cost X connects Vertex A to    Vertex B iff
  995.          the intersection of Column A and Row B    is marked
  996.                      with an X.
  997.  
  998.  
  999.  
  1000. Moy                Standards Track               [Page 20]
  1001.  
  1002. RFC 2328             OSPF Version 2              April 1998
  1003.  
  1004.  
  1005.              **FROM**                **FROM**
  1006.  
  1007.           |RT12|N9|N10|H1|           |RT9|RT11|RT12|N9|
  1008.        *  --------------------        *  ----------------------
  1009.        *  RT12|    |  |   |     |        *    RT9|   |    |     |0 |
  1010.        T    N9|1   |  |   |     |        T  RT11|   |    |     |0 |
  1011.        O   N10|2   |  |   |     |        O  RT12|   |    |     |0 |
  1012.        *    H1|10  |  |   |     |        *     N9|   |    |     |  |
  1013.        *                    *
  1014.         RT12's router-LSA           N9's network-LSA
  1015.  
  1016.           Figure 4: Individual link state components
  1017.  
  1018.           Networks and routers are represented by vertices.
  1019.           An edge of cost X    connects Vertex    A to Vertex B iff
  1020.           the intersection of Column A and Row B is    marked
  1021.                   with an X.
  1022.  
  1023.     2.2.  The shortest-path tree
  1024.  
  1025.     When no    OSPF areas are configured, each    router in the Autonomous
  1026.     System has an identical    link-state database, leading to    an
  1027.     identical graphical representation.  A router generates    its
  1028.     routing    table from this    graph by calculating a tree of shortest
  1029.     paths with the router itself as    root.  Obviously, the shortest-
  1030.     path tree depends on the router    doing the calculation.    The
  1031.     shortest-path tree for Router RT6 in our example is depicted in
  1032.     Figure 5.
  1033.  
  1034.     The tree gives the entire path to any destination network or
  1035.     host.  However,    only the next hop to the destination is    used in
  1036.     the forwarding process.     Note also that    the best route to any
  1037.     router has also    been calculated.  For the processing of    external
  1038.     data, we note the next hop and distance    to any router
  1039.     advertising external routes.  The resulting routing table for
  1040.     Router RT6 is pictured in Table    2.  Note that there is a
  1041.     separate route for each    end of a numbered point-to-point network
  1042.     (in this case, the serial line between Routers RT6 and RT10).
  1043.  
  1044.  
  1045.     Routes to networks belonging to    other AS'es (such as N12) appear
  1046.     as dashed lines    on the shortest    path tree in Figure 5.    Use of
  1047.  
  1048.  
  1049.  
  1050. Moy                Standards Track               [Page 21]
  1051.  
  1052. RFC 2328             OSPF Version 2              April 1998
  1053.  
  1054.  
  1055.  
  1056.                 RT6(origin)
  1057.             RT5    o------------o-----------o Ib
  1058.                /|\    6         |\        7
  1059.              8/8|8\         | \
  1060.              /    |  \        6|    \
  1061.             o    |   o         |     \7
  1062.            N12    o  N14         |      \
  1063.                N13      2  |       \
  1064.                 N4 o-----o RT3  \
  1065.                     /         \      5
  1066.                   1/     RT10 o-------o    Ia
  1067.                   /          |\
  1068.                RT4 o-----o N3         3|    \1
  1069.                 /|          |     \ N6      RT7
  1070.                    / |       N8 o      o---------o
  1071.                   /     |          |      |       /|
  1072.              RT2 o     o RT1          |      |     2/ |9
  1073.                 /     |          |      |RT8     /  |
  1074.                /3     |3     RT11 o      o    o   o
  1075.               /     |          |      |    N12 N15
  1076.               N2 o     o N1         1|      |4
  1077.                           |      |
  1078.                        N9 o      o N7
  1079.                          /|
  1080.                         / |
  1081.             N11     RT9       /  |RT12
  1082.              o--------o-------o   o--------o H1
  1083.                  3              |      10
  1084.                           |2
  1085.                           |
  1086.                           o    N10
  1087.  
  1088.  
  1089.              Figure 5: The SPF tree for    Router RT6
  1090.  
  1091.           Edges that are not marked    with a cost have a cost    of
  1092.           of zero (these are network-to-router links). Routes
  1093.           to networks N12-N15 are external information that    is
  1094.              considered in Section 2.3
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100. Moy                Standards Track               [Page 22]
  1101.  
  1102. RFC 2328             OSPF Version 2              April 1998
  1103.  
  1104.  
  1105.            Destination     Next  Hop   Distance
  1106.            __________________________________
  1107.            N1         RT3         10
  1108.            N2         RT3         10
  1109.            N3         RT3         7
  1110.            N4         RT3         8
  1111.            Ib         *         7
  1112.            Ia         RT10         12
  1113.            N6         RT10         8
  1114.            N7         RT10         12
  1115.            N8         RT10         10
  1116.            N9         RT10         11
  1117.            N10         RT10         13
  1118.            N11         RT10         14
  1119.            H1         RT10         21
  1120.            __________________________________
  1121.            RT5         RT5         6
  1122.            RT7         RT10         8
  1123.  
  1124.  
  1125.     Table 2: The portion of Router RT6's routing table listing local
  1126.                  destinations.
  1127.  
  1128.     this externally    derived    routing    information is considered in the
  1129.     next section.
  1130.  
  1131.  
  1132.     2.3.  Use of external routing information
  1133.  
  1134.     After the tree is created the external routing information is
  1135.     examined.  This    external routing information may originate from
  1136.     another    routing    protocol such as BGP, or be statically
  1137.     configured (static routes).  Default routes can    also be    included
  1138.     as part    of the Autonomous System's external routing information.
  1139.  
  1140.     External routing information is    flooded    unaltered throughout the
  1141.     AS.  In    our example, all the routers in    the Autonomous System
  1142.     know that Router RT7 has two external routes, with metrics 2 and
  1143.     9.
  1144.  
  1145.     OSPF supports two types    of external metrics.  Type 1 external
  1146.     metrics    are expressed in the same units    as OSPF    interface cost
  1147.  
  1148.  
  1149.  
  1150. Moy                Standards Track               [Page 23]
  1151.  
  1152. RFC 2328             OSPF Version 2              April 1998
  1153.  
  1154.  
  1155.     (i.e., in terms    of the link state metric).  Type 2 external
  1156.     metrics    are an order of    magnitude larger; any Type 2 metric is
  1157.     considered greater than    the cost of any    path internal to the AS.
  1158.     Use of Type 2 external metrics assumes that routing between
  1159.     AS'es is the major cost    of routing a packet, and eliminates the
  1160.     need for conversion of external    costs to internal link state
  1161.     metrics.
  1162.  
  1163.     As an example of Type 1    external metric    processing, suppose that
  1164.     the Routers RT7    and RT5    in Figure 2 are    advertising Type 1
  1165.     external metrics.  For each advertised external    route, the total
  1166.     cost from Router RT6 is    calculated as the sum of the external
  1167.     route's    advertised cost    and the    distance from Router RT6 to the
  1168.     advertising router.  When two routers are advertising the same
  1169.     external destination, RT6 picks    the advertising    router providing
  1170.     the minimum total cost.    RT6 then sets the next hop to the
  1171.     external destination equal to the next hop that    would be used
  1172.     when routing packets to    the chosen advertising router.
  1173.  
  1174.     In Figure 2, both Router RT5 and RT7 are advertising an    external
  1175.     route to destination Network N12.  Router RT7 is preferred since
  1176.     it is advertising N12 at a distance of 10 (8+2)    to Router RT6,
  1177.     which is better    than Router RT5's 14 (6+8).  Table 3 shows the
  1178.     entries    that are added to the routing table when external routes
  1179.     are examined:
  1180.  
  1181.  
  1182.  
  1183.              Destination   Next  Hop   Distance
  1184.              __________________________________
  1185.              N12           RT10       10
  1186.              N13           RT5       14
  1187.              N14           RT5       14
  1188.              N15           RT10       17
  1189.  
  1190.  
  1191.          Table 3: The portion of Router    RT6's routing table
  1192.                listing external destinations.
  1193.  
  1194.  
  1195.     Processing of Type 2 external metrics is simpler.  The AS
  1196.     boundary router    advertising the    smallest external metric is
  1197.  
  1198.  
  1199.  
  1200. Moy                Standards Track               [Page 24]
  1201.  
  1202. RFC 2328             OSPF Version 2              April 1998
  1203.  
  1204.  
  1205.     chosen,    regardless of the internal distance to the AS boundary
  1206.     router.     Suppose in our    example    both Router RT5    and Router RT7
  1207.     were advertising Type 2    external routes.  Then all traffic
  1208.     destined for Network N12 would be forwarded to Router RT7, since
  1209.     2 < 8.    When several equal-cost    Type 2 routes exist, the
  1210.     internal distance to the advertising routers is    used to    break
  1211.     the tie.
  1212.  
  1213.     Both Type 1 and    Type 2 external    metrics    can be present in the AS
  1214.     at the same time.  In that event, Type 1 external metrics always
  1215.     take precedence.
  1216.  
  1217.     This section has assumed that packets destined for external
  1218.     destinations are always    routed through the advertising AS
  1219.     boundary router.  This is not always desirable.     For example,
  1220.     suppose    in Figure 2 there is an    additional router attached to
  1221.     Network    N6, called Router RTX.    Suppose    further    that RTX does
  1222.     not participate    in OSPF    routing, but does exchange BGP
  1223.     information with the AS    boundary router    RT7.  Then, Router RT7
  1224.     would end up advertising OSPF external routes for all
  1225.     destinations that should be routed to RTX.  An extra hop will
  1226.     sometimes be introduced    if packets for these destinations need
  1227.     always be routed first to Router RT7 (the advertising router).
  1228.  
  1229.     To deal    with this situation, the OSPF protocol allows an AS
  1230.     boundary router    to specify a "forwarding address" in its AS-
  1231.     external-LSAs.    In the above example, Router RT7 would specify
  1232.     RTX's IP address as the    "forwarding address" for all those
  1233.     destinations whose packets should be routed directly to    RTX.
  1234.  
  1235.     The "forwarding    address" has one other application.  It    enables
  1236.     routers    in the Autonomous System's interior to function    as
  1237.     "route servers".  For example, in Figure 2 the router RT6 could
  1238.     become a route server, gaining external    routing    information
  1239.     through    a combination of static    configuration and external
  1240.     routing    protocols.  RT6    would then start advertising itself as
  1241.     an AS boundary router, and would originate a collection    of OSPF
  1242.     AS-external-LSAs.  In each AS-external-LSA, Router RT6 would
  1243.     specify    the correct Autonomous System exit point to use    for the
  1244.     destination through appropriate    setting    of the LSA's "forwarding
  1245.     address" field.
  1246.  
  1247.  
  1248.  
  1249.  
  1250. Moy                Standards Track               [Page 25]
  1251.  
  1252. RFC 2328             OSPF Version 2              April 1998
  1253.  
  1254.  
  1255.     2.4.  Equal-cost multipath
  1256.  
  1257.     The above discussion has been simplified by considering    only a
  1258.     single route to    any destination.  In reality, if multiple
  1259.     equal-cost routes to a destination exist, they are all
  1260.     discovered and used.  This requires no conceptual changes to the
  1261.     algorithm, and its discussion is postponed until we consider the
  1262.     tree-building process in more detail.
  1263.  
  1264.     With equal cost    multipath, a router potentially    has several
  1265.     available next hops towards any    given destination.
  1266.  
  1267.  
  1268. 3.  Splitting the AS into Areas
  1269.  
  1270.     OSPF allows    collections of contiguous networks and hosts to    be
  1271.     grouped together.  Such a group, together with the routers having
  1272.     interfaces to any one of the included networks, is called an area.
  1273.     Each area runs a separate copy of the basic    link-state routing
  1274.     algorithm.    This means that    each area has its own link-state
  1275.     database and corresponding graph, as explained in the previous
  1276.     section.
  1277.  
  1278.     The    topology of an area is invisible from the outside of the area.
  1279.     Conversely,    routers    internal to a given area know nothing of the
  1280.     detailed topology external to the area.  This isolation of knowledge
  1281.     enables the    protocol to effect a marked reduction in routing traffic
  1282.     as compared    to treating the    entire Autonomous System as a single
  1283.     link-state domain.
  1284.  
  1285.     With the introduction of areas, it is no longer true that all
  1286.     routers in the AS have an identical    link-state database.  A    router
  1287.     actually has a separate link-state database    for each area it is
  1288.     connected to.  (Routers connected to multiple areas    are called area
  1289.     border routers).  Two routers belonging to the same    area have, for
  1290.     that area, identical area link-state databases.
  1291.  
  1292.     Routing in the Autonomous System takes place on two    levels,
  1293.     depending on whether the source and    destination of a packet    reside
  1294.     in the same    area (intra-area routing is used) or different areas
  1295.     (inter-area    routing    is used).  In intra-area routing, the packet is
  1296.     routed solely on information obtained within the area; no routing
  1297.  
  1298.  
  1299.  
  1300. Moy                Standards Track               [Page 26]
  1301.  
  1302. RFC 2328             OSPF Version 2              April 1998
  1303.  
  1304.  
  1305.     information    obtained from outside the area can be used.  This
  1306.     protects intra-area    routing    from the injection of bad routing
  1307.     information.  We discuss inter-area    routing    in Section 3.2.
  1308.  
  1309.  
  1310.     3.1.  The backbone of the Autonomous System
  1311.  
  1312.     The OSPF backbone is the special OSPF Area 0 (often written as
  1313.     Area 0.0.0.0, since OSPF Area ID's are typically formatted as IP
  1314.     addresses). The    OSPF backbone always contains all area border
  1315.     routers. The backbone is responsible for distributing routing
  1316.     information between non-backbone areas.    The backbone must be
  1317.     contiguous. However, it    need not be physically contiguous;
  1318.     backbone connectivity can be established/maintained through the
  1319.     configuration of virtual links.
  1320.  
  1321.     Virtual    links can be configured    between    any two    backbone routers
  1322.     that have an interface to a common non-backbone    area.  Virtual
  1323.     links belong to    the backbone.  The protocol treats two routers
  1324.     joined by a virtual link as if they were connected by an
  1325.     unnumbered point-to-point backbone network.  On    the graph of the
  1326.     backbone, two such routers are joined by arcs whose costs are
  1327.     the intra-area distances between the two routers.  The routing
  1328.     protocol traffic that flows along the virtual link uses    intra-
  1329.     area routing only.
  1330.  
  1331.  
  1332.     3.2.  Inter-area routing
  1333.  
  1334.     When routing a packet between two non-backbone areas the
  1335.     backbone is used.  The path that the packet will travel    can be
  1336.     broken up into three contiguous    pieces:    an intra-area path from
  1337.     the source to an area border router, a backbone    path between the
  1338.     source and destination areas, and then another intra-area path
  1339.     to the destination.  The algorithm finds the set of such paths
  1340.     that have the smallest cost.
  1341.  
  1342.     Looking    at this    another    way, inter-area    routing    can be pictured
  1343.     as forcing a star configuration    on the Autonomous System, with
  1344.     the backbone as    hub and    each of    the non-backbone areas as
  1345.     spokes.
  1346.  
  1347.  
  1348.  
  1349.  
  1350. Moy                Standards Track               [Page 27]
  1351.  
  1352. RFC 2328             OSPF Version 2              April 1998
  1353.  
  1354.  
  1355.     The topology of    the backbone dictates the backbone paths used
  1356.     between    areas.    The topology of    the backbone can be enhanced by
  1357.     adding virtual links.  This gives the system administrator some
  1358.     control    over the routes    taken by inter-area traffic.
  1359.  
  1360.     The correct area border    router to use as the packet exits the
  1361.     source area is chosen in exactly the same way routers
  1362.     advertising external routes are    chosen.     Each area border router
  1363.     in an area summarizes for the area its cost to all networks
  1364.     external to the    area.  After the SPF tree is calculated    for the
  1365.     area, routes to    all inter-area destinations are    calculated by
  1366.     examining the summaries    of the area border routers.
  1367.  
  1368.  
  1369.     3.3.  Classification of routers
  1370.  
  1371.     Before the introduction    of areas, the only OSPF    routers    having a
  1372.     specialized function were those    advertising external routing
  1373.     information, such as Router RT5    in Figure 2.  When the AS is
  1374.     split into OSPF    areas, the routers are further divided according
  1375.     to function into the following four overlapping    categories:
  1376.  
  1377.  
  1378.     Internal routers
  1379.         A router with all directly connected networks belonging to
  1380.         the    same area. These routers run a single copy of the basic
  1381.         routing algorithm.
  1382.  
  1383.     Area border routers
  1384.         A router that attaches to multiple areas.  Area border
  1385.         routers run    multiple copies    of the basic algorithm,    one copy
  1386.         for    each attached area. Area border    routers    condense the
  1387.         topological    information of their attached areas for
  1388.         distribution to the    backbone.  The backbone    in turn
  1389.         distributes    the information    to the other areas.
  1390.  
  1391.     Backbone routers
  1392.         A router that has an interface to the backbone area.  This
  1393.         includes all routers that interface    to more    than one area
  1394.         (i.e., area    border routers).  However, backbone routers do
  1395.         not    have to    be area    border routers.     Routers with all
  1396.         interfaces connecting to the backbone area are supported.
  1397.  
  1398.  
  1399.  
  1400. Moy                Standards Track               [Page 28]
  1401.  
  1402. RFC 2328             OSPF Version 2              April 1998
  1403.  
  1404.  
  1405.     AS boundary routers
  1406.         A router that exchanges routing information    with routers
  1407.         belonging to other Autonomous Systems.  Such a router
  1408.         advertises AS external routing information throughout the
  1409.         Autonomous System.    The paths to each AS boundary router are
  1410.         known by every router in the AS.  This classification is
  1411.         completely independent of the previous classifications: AS
  1412.         boundary routers may be internal or    area border routers, and
  1413.         may    or may not participate in the backbone.
  1414.  
  1415.  
  1416.     3.4.  A sample area    configuration
  1417.  
  1418.     Figure 6 shows a sample    area configuration.  The first area
  1419.     consists of networks N1-N4, along with their attached routers
  1420.     RT1-RT4.  The second area consists of networks N6-N8, along with
  1421.     their attached routers RT7, RT8, RT10 and RT11.     The third area
  1422.     consists of networks N9-N11 and    Host H1, along with their
  1423.     attached routers RT9, RT11 and RT12.  The third    area has been
  1424.     configured so that networks N9-N11 and Host H1 will all    be
  1425.     grouped    into a single route, when advertised external to the
  1426.     area (see Section 3.5 for more details).
  1427.  
  1428.     In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are
  1429.     internal routers.  Routers RT3,    RT4, RT7, RT10 and RT11    are area
  1430.     border routers.     Finally, as before, Routers RT5 and RT7 are AS
  1431.     boundary routers.
  1432.  
  1433.     Figure 7 shows the resulting link-state    database for the Area 1.
  1434.     The figure completely describes    that area's intra-area routing.
  1435.     It also    shows the complete view    of the internet    for the    two
  1436.     internal routers RT1 and RT2.  It is the job of    the area border
  1437.     routers, RT3 and RT4, to advertise into    Area 1 the distances to
  1438.     all destinations external to the area.    These are indicated in
  1439.     Figure 7 by the    dashed stub routes.  Also, RT3 and RT4 must
  1440.     advertise into Area 1 the location of the AS boundary routers
  1441.     RT5 and    RT7.  Finally, AS-external-LSAs    from RT5 and RT7 are
  1442.     flooded    throughout the entire AS, and in particular throughout
  1443.     Area 1.     These LSAs are    included in Area 1's database, and yield
  1444.     routes to Networks N12-N15.
  1445.  
  1446.     Routers    RT3 and    RT4 must also summarize    Area 1's topology for
  1447.  
  1448.  
  1449.  
  1450. Moy                Standards Track               [Page 29]
  1451.  
  1452. RFC 2328             OSPF Version 2              April 1998
  1453.  
  1454.  
  1455.  
  1456.          ...........................
  1457.          .     +               .
  1458.          .     | 3+---+           .      N12      N14
  1459.          . N1|--|RT1|\ 1           .    \ N13 /
  1460.          .     |  +---+ \           .    8\ |8/8
  1461.          .     +       \ ____      .      \|/
  1462.          .            /     \   1+---+8    8+---+6
  1463.          .           *  N3  *---|RT4|------|RT5|--------+
  1464.          .            \____/    +---+     +---+          |
  1465.          .      +        /       \   .       |7          |
  1466.          .      | 3+---+ /        \  .       |          |
  1467.          .    N2|--|RT2|/1        1\ .       |6          |
  1468.          .      |  +---+          +---+8    6+---+          |
  1469.          .      +              |RT3|------|RT6|          |
  1470.          .                  +---+     +---+          |
  1471.          .                2/ .     Ia|7          |
  1472.          .                /  .       |          |
  1473.          .           +---------+ .       |          |
  1474.          .Area 1           N4      .       |          |
  1475.          ...........................       |          |
  1476.       ..........................           |          |
  1477.       .           N11       .           |          |
  1478.       .       +---------+       .           |          |
  1479.       .        |       .           |          |       N12
  1480.       .        |3       .         Ib|5          |6 2/
  1481.       .          +---+       .         +----+        +---+/
  1482.       .          |RT9|       .    .........|RT10|.....|RT7|---N15.
  1483.       .          +---+       .    .     +----+        +---+ 9    .
  1484.       .        |1       .    .    +    /3    1\      |1       .
  1485.       .           _|__       .    .    | /    \   __|_       .
  1486.       .          /       \      1+----+2   |/         \ /    \      .
  1487.       .         *    N9  *------|RT11|----|          *  N6     *     .
  1488.       .          \____/       +----+    |           \____/      .
  1489.       .        |       .    .    |              |           .
  1490.       .        |1       .    .    +              |1       .
  1491.       .  +--+   10+----+       .    .   N8            +---+      .
  1492.       .  |H1|-----|RT12|       .    .            |RT8|      .
  1493.       .  +--+SLIP +----+       .    .            +---+      .
  1494.       .        |2       .    .              |4       .
  1495.       .        |       .    .              |           .
  1496.       .       +---------+       .    .          +--------+   .
  1497.  
  1498.  
  1499.  
  1500. Moy                Standards Track               [Page 30]
  1501.  
  1502. RFC 2328             OSPF Version 2              April 1998
  1503.  
  1504.  
  1505.       .           N10       .    .              N7       .
  1506.       .               .    .Area 2                   .
  1507.       .Area    3           .    ................................
  1508.       ..........................
  1509.  
  1510.             Figure 6: A    sample OSPF area configuration
  1511.  
  1512.     distribution to    the backbone.  Their backbone LSAs are shown in
  1513.     Table 4.  These    summaries show which networks are contained in
  1514.     Area 1 (i.e., Networks N1-N4), and the distance    to these
  1515.     networks from the routers RT3 and RT4 respectively.
  1516.  
  1517.  
  1518.     The link-state database    for the    backbone is shown in Figure 8.
  1519.     The set    of routers pictured are    the backbone routers.  Router
  1520.     RT11 is    a backbone router because it belongs to    two areas.  In
  1521.     order to make the backbone connected, a    virtual    link has been
  1522.     configured between Routers R10 and R11.
  1523.  
  1524.     The area border    routers    RT3, RT4, RT7, RT10 and    RT11 condense
  1525.     the routing information    of their attached non-backbone areas for
  1526.     distribution via the backbone; these are the dashed stubs that
  1527.     appear in Figure 8.  Remember that the third area has been
  1528.     configured to condense Networks    N9-N11 and Host    H1 into    a single
  1529.     route.    This yields a single dashed line for networks N9-N11 and
  1530.     Host H1    in Figure 8.  Routers RT5 and RT7 are AS boundary
  1531.     routers; their externally derived information also appears on
  1532.     the graph in Figure 8 as stubs.
  1533.  
  1534.  
  1535.  
  1536.              Network   RT3 adv.      RT4 adv.
  1537.              _____________________________
  1538.              N1           4      4
  1539.              N2           4      4
  1540.              N3           1      1
  1541.              N4           2      3
  1542.  
  1543.           Table 4: Networks    advertised to the backbone
  1544.             by Routers RT3 and RT4.
  1545.  
  1546.  
  1547.  
  1548.  
  1549.  
  1550. Moy                Standards Track               [Page 31]
  1551.  
  1552. RFC 2328             OSPF Version 2              April 1998
  1553.  
  1554.  
  1555.  
  1556.                    **FROM**
  1557.  
  1558.               |RT|RT|RT|RT|RT|RT|
  1559.               |1 |2    |3 |4 |5 |7 |N3|
  1560.                ----- -------------------
  1561.                RT1|  |    |  |  |     |  |0 |
  1562.                RT2|  |    |  |  |     |  |0 |
  1563.                RT3|  |    |  |  |     |  |0 |
  1564.            *   RT4|  |    |  |  |     |  |0 |
  1565.            *   RT5|  |    |14|8 |     |  |  |
  1566.            T   RT7|  |    |20|14|     |  |  |
  1567.            O    N1|3 |    |  |  |     |  |  |
  1568.            *    N2|  |3    |  |  |     |  |  |
  1569.            *    N3|1 |1    |1 |1 |     |  |  |
  1570.             N4|  |    |2 |  |     |  |  |
  1571.              Ia,Ib|  |    |20|27|     |  |  |
  1572.             N6|  |    |16|15|     |  |  |
  1573.             N7|  |    |20|19|     |  |  |
  1574.             N8|  |    |18|18|     |  |  |
  1575.          N9-N11,H1|  |    |29|36|     |  |  |
  1576.                N12|  |    |  |  |8 |2 |  |
  1577.                N13|  |    |  |  |8 |  |  |
  1578.                N14|  |    |  |  |8 |  |  |
  1579.                N15|  |    |  |  |     |9 |  |
  1580.  
  1581.               Figure 7:    Area 1's Database.
  1582.  
  1583.           Networks and routers are represented by vertices.
  1584.           An edge of cost X    connects Vertex    A to Vertex B iff
  1585.           the intersection of Column A and Row B is    marked
  1586.                    with an X.
  1587.  
  1588.  
  1589.  
  1590.  
  1591.  
  1592.  
  1593.  
  1594.  
  1595.  
  1596.  
  1597.  
  1598.  
  1599.  
  1600. Moy                Standards Track               [Page 32]
  1601.  
  1602. RFC 2328             OSPF Version 2              April 1998
  1603.  
  1604.  
  1605.                   **FROM**
  1606.  
  1607.                 |RT|RT|RT|RT|RT|RT|RT
  1608.                 |3 |4 |5 |6    |7 |10|11|
  1609.              ------------------------
  1610.              RT3|  |  |  |6    |  |  |     |
  1611.              RT4|  |  |8 |    |  |  |     |
  1612.              RT5|  |8 |  |6    |6 |  |     |
  1613.              RT6|8 |  |7 |    |  |5 |     |
  1614.              RT7|  |  |6 |    |  |  |     |
  1615.              *    RT10|  |  |  |7    |  |  |2 |
  1616.              *    RT11|  |  |  |    |  |3 |     |
  1617.              T      N1|4 |4 |  |    |  |  |     |
  1618.              O      N2|4 |4 |  |    |  |  |     |
  1619.              *      N3|1 |1 |  |    |  |  |     |
  1620.              *      N4|2 |3 |  |    |  |  |     |
  1621.               Ia|  |  |  |    |  |5 |     |
  1622.               Ib|  |  |  |7    |  |  |     |
  1623.               N6|  |  |  |    |1 |1 |3 |
  1624.               N7|  |  |  |    |5 |5 |7 |
  1625.               N8|  |  |  |    |4 |3 |2 |
  1626.            N9-N11,H1|  |  |  |    |  |  |11|
  1627.              N12|  |  |8 |    |2 |  |     |
  1628.              N13|  |  |8 |    |  |  |     |
  1629.              N14|  |  |8 |    |  |  |     |
  1630.              N15|  |  |  |    |9 |  |     |
  1631.  
  1632.  
  1633.              Figure 8: The backbone's database.
  1634.  
  1635.           Networks and routers are represented by vertices.
  1636.           An edge of cost X    connects Vertex    A to Vertex B iff
  1637.           the intersection of Column A and Row B is    marked
  1638.                  with an X.
  1639.  
  1640.     The backbone enables the exchange of summary information between
  1641.     area border routers.  Every area border    router hears the area
  1642.     summaries from all other area border routers.  It then forms a
  1643.     picture    of the distance    to all networks    outside    of its area by
  1644.     examining the collected    LSAs, and adding in the    backbone
  1645.     distance to each advertising router.
  1646.  
  1647.  
  1648.  
  1649.  
  1650. Moy                Standards Track               [Page 33]
  1651.  
  1652. RFC 2328             OSPF Version 2              April 1998
  1653.  
  1654.  
  1655.     Again using Routers RT3    and RT4    as an example, the procedure
  1656.     goes as    follows: They first calculate the SPF tree for the
  1657.     backbone.  This    gives the distances to all other area border
  1658.     routers.  Also noted are the distances to networks (Ia and Ib)
  1659.     and AS boundary    routers    (RT5 and RT7) that belong to the
  1660.     backbone.  This    calculation is shown in    Table 5.
  1661.  
  1662.  
  1663.     Next, by looking at the    area summaries from these area border
  1664.     routers, RT3 and RT4 can determine the distance    to all networks
  1665.     outside    their area.  These distances are then advertised
  1666.     internally to the area by RT3 and RT4.    The advertisements that
  1667.     Router RT3 and RT4 will    make into Area 1 are shown in Table 6.
  1668.     Note that Table    6 assumes that an area range has been configured
  1669.     for the    backbone which groups Ia and Ib    into a single LSA.
  1670.  
  1671.  
  1672.     The information    imported into Area 1 by    Routers    RT3 and    RT4
  1673.     enables    an internal router, such as RT1, to choose an area
  1674.     border router intelligently.  Router RT1 would use RT4 for
  1675.     traffic    to Network N6, RT3 for traffic to Network N10, and would
  1676.  
  1677.  
  1678.                   dist  from   dist     from
  1679.                   RT3       RT4
  1680.            __________________________________
  1681.            to  RT3    *           21
  1682.            to  RT4    22       *
  1683.            to  RT7    20       14
  1684.            to  RT10   15       22
  1685.            to  RT11   18       25
  1686.            __________________________________
  1687.            to  Ia     20       27
  1688.            to  Ib     15       22
  1689.            __________________________________
  1690.            to  RT5    14       8
  1691.            to  RT7    20       14
  1692.  
  1693.          Table 5: Backbone distances calculated
  1694.             by Routers RT3 and RT4.
  1695.  
  1696.  
  1697.  
  1698.  
  1699.  
  1700. Moy                Standards Track               [Page 34]
  1701.  
  1702. RFC 2328             OSPF Version 2              April 1998
  1703.  
  1704.  
  1705.  
  1706.  
  1707.            Destination     RT3 adv.   RT4    adv.
  1708.            _________________________________
  1709.            Ia,Ib     20        27
  1710.            N6         16        15
  1711.            N7         20        19
  1712.            N8         18        18
  1713.            N9-N11,H1     29        36
  1714.            _________________________________
  1715.            RT5         14        8
  1716.            RT7         20        14
  1717.  
  1718.           Table 6: Destinations advertised into Area 1
  1719.             by Routers RT3 and RT4.
  1720.  
  1721.     load share between the two for traffic to Network N8.
  1722.  
  1723.     Router RT1 can also determine in this manner the shortest path
  1724.     to the AS boundary routers RT5 and RT7.     Then, by looking at RT5
  1725.     and RT7's AS-external-LSAs, Router RT1 can decide between RT5 or
  1726.     RT7 when sending to a destination in another Autonomous    System
  1727.     (one of    the networks N12-N15).
  1728.  
  1729.     Note that a failure of the line    between    Routers    RT6 and    RT10
  1730.     will cause the backbone    to become disconnected.     Configuring a
  1731.     virtual    link between Routers RT7 and RT10 will give the    backbone
  1732.     more connectivity and more resistance to such failures.
  1733.  
  1734.  
  1735.     3.5.  IP subnetting    support
  1736.  
  1737.     OSPF attaches an IP address mask to each advertised route.  The
  1738.     mask indicates the range of addresses being described by the
  1739.     particular route.  For example,    a summary-LSA for the
  1740.     destination 128.185.0.0    with a mask of 0xffff0000 actually is
  1741.     describing a single route to the collection of destinations
  1742.     128.185.0.0 - 128.185.255.255.    Similarly, host    routes are
  1743.     always advertised with a mask of 0xffffffff, indicating    the
  1744.     presence of only a single destination.
  1745.  
  1746.  
  1747.  
  1748.  
  1749.  
  1750. Moy                Standards Track               [Page 35]
  1751.  
  1752. RFC 2328             OSPF Version 2              April 1998
  1753.  
  1754.  
  1755.     Including the mask with    each advertised    destination enables the
  1756.     implementation of what is commonly referred to as variable-
  1757.     length subnetting.  This means that a single IP    class A, B, or C
  1758.     network    number can be broken up    into many subnets of various
  1759.     sizes.    For example, the network 128.185.0.0 could be broken up
  1760.     into 62    variable-sized subnets:    15 subnets of size 4K, 15
  1761.     subnets    of size    256, and 32 subnets of size 8.    Table 7    shows
  1762.     some of    the resulting network addresses    together with their
  1763.     masks.
  1764.  
  1765.  
  1766.  
  1767.           Network address   IP address mask   Subnet size
  1768.           _______________________________________________
  1769.           128.185.16.0        0xfffff000          4K
  1770.           128.185.1.0        0xffffff00          256
  1771.           128.185.0.8        0xfffffff8          8
  1772.  
  1773.  
  1774.              Table 7: Some sample subnet sizes.
  1775.  
  1776.  
  1777.     There are many possible    ways of    dividing up a class A, B, and C
  1778.     network    into variable sized subnets.  The precise procedure for
  1779.     doing so is beyond the scope of    this specification.  This
  1780.     specification however establishes the following    guideline: When
  1781.     an IP packet is    forwarded, it is always    forwarded to the network
  1782.     that is    the best match for the packet's    destination.  Here best
  1783.     match is synonymous with the longest or    most specific match.
  1784.     For example, the default route with destination    of 0.0.0.0 and
  1785.     mask 0x00000000    is always a match for every IP destination.  Yet
  1786.     it is always less specific than    any other match.  Subnet masks
  1787.     must be    assigned so that the best match    for any    IP destination
  1788.     is unambiguous.
  1789.  
  1790.     Attaching an address mask to each route    also enables the support
  1791.     of IP supernetting. For    example, a single physical network
  1792.     segment    could be assigned the [address,mask] pair
  1793.     [192.9.4.0,0xfffffc00].    The segment would then be single IP
  1794.     network, containing addresses from the four consecutive    class C
  1795.     network    numbers    192.9.4.0 through 192.9.7.0. Such addressing is
  1796.     now becoming commonplace with the advent of CIDR (see [Ref10]).
  1797.  
  1798.  
  1799.  
  1800. Moy                Standards Track               [Page 36]
  1801.  
  1802. RFC 2328             OSPF Version 2              April 1998
  1803.  
  1804.  
  1805.     In order to get    better aggregation at area boundaries, area
  1806.     address    ranges can be employed (see Section C.2    for more
  1807.     details).  Each    address    range is defined as an [address,mask]
  1808.     pair.  Many separate networks may then be contained in a single
  1809.     address    range, just as a subnetted network is composed of many
  1810.     separate subnets.  Area    border routers then summarize the area
  1811.     contents (for distribution to the backbone) by advertising a
  1812.     single route for each address range.  The cost of the route is
  1813.     the maximum cost to any    of the networks    falling    in the specified
  1814.     range.
  1815.  
  1816.     For example, an    IP subnetted network might be configured as a
  1817.     single OSPF area.  In that case, a single address range    could be
  1818.     configured:  a class A,    B, or C    network    number along with its
  1819.     natural    IP mask.  Inside the area, any number of variable sized
  1820.     subnets    could be defined.  However, external to    the area a
  1821.     single route for the entire subnetted network would be
  1822.     distributed, hiding even the fact that the network is subnetted
  1823.     at all.     The cost of this route    is the maximum of the set of
  1824.     costs to the component subnets.
  1825.  
  1826.  
  1827.     3.6.  Supporting stub areas
  1828.  
  1829.     In some    Autonomous Systems, the    majority of the    link-state
  1830.     database may consist of    AS-external-LSAs.  An OSPF AS-external-
  1831.     LSA is usually flooded throughout the entire AS.  However, OSPF
  1832.     allows certain areas to    be configured as "stub areas".    AS-
  1833.     external-LSAs are not flooded into/throughout stub areas;
  1834.     routing    to AS external destinations in these areas is based on a
  1835.     (per-area) default only.  This reduces the link-state database
  1836.     size, and therefore the    memory requirements, for a stub    area's
  1837.     internal routers.
  1838.  
  1839.     In order to take advantage of the OSPF stub area support,
  1840.     default    routing    must be    used in    the stub area.    This is
  1841.     accomplished as    follows.  One or more of the stub area's area
  1842.     border routers must advertise a    default    route into the stub area
  1843.     via summary-LSAs.  These summary defaults are flooded throughout
  1844.     the stub area, but no further.    (For this reason these defaults
  1845.     pertain    only to    the particular stub area).  These summary
  1846.     default    routes will be used for    any destination    that is    not
  1847.  
  1848.  
  1849.  
  1850. Moy                Standards Track               [Page 37]
  1851.  
  1852. RFC 2328             OSPF Version 2              April 1998
  1853.  
  1854.  
  1855.     explicitly reachable by    an intra-area or inter-area path (i.e.,
  1856.     AS external destinations).
  1857.  
  1858.     An area    can be configured as a stub when there is a single exit
  1859.     point from the area, or    when the choice    of exit    point need not
  1860.     be made    on a per-external-destination basis.  For example, Area
  1861.     3 in Figure 6 could be configured as a stub area, because all
  1862.     external traffic must travel though its    single area border
  1863.     router RT11.  If Area 3    were configured    as a stub, Router RT11
  1864.     would advertise    a default route    for distribution inside    Area 3
  1865.     (in a summary-LSA), instead of flooding    the AS-external-LSAs for
  1866.     Networks N12-N15 into/throughout the area.
  1867.  
  1868.     The OSPF protocol ensures that all routers belonging to    an area
  1869.     agree on whether the area has been configured as a stub.  This
  1870.     guarantees that    no confusion will arise    in the flooding    of AS-
  1871.     external-LSAs.
  1872.  
  1873.     There are a couple of restrictions on the use of stub areas.
  1874.     Virtual    links cannot be    configured through stub    areas.    In
  1875.     addition, AS boundary routers cannot be    placed internal    to stub
  1876.     areas.
  1877.  
  1878.  
  1879.     3.7.  Partitions of    areas
  1880.  
  1881.     OSPF does not actively attempt to repair area partitions.  When
  1882.     an area    becomes    partitioned, each component simply becomes a
  1883.     separate area.    The backbone then performs routing between the
  1884.     new areas.  Some destinations reachable    via intra-area routing
  1885.     before the partition will now require inter-area routing.
  1886.  
  1887.     However, in order to maintain full routing after the partition,
  1888.     an address range must not be split across multiple components of
  1889.     the area partition. Also, the backbone itself must not
  1890.     partition.  If it does,    parts of the Autonomous    System will
  1891.     become unreachable.  Backbone partitions can be    repaired by
  1892.     configuring virtual links (see Section 15).
  1893.  
  1894.     Another    way to think about area    partitions is to look at the
  1895.     Autonomous System graph    that was introduced in Section 2.  Area
  1896.     IDs can    be viewed as colors for    the graph's edges.[1] Each edge
  1897.  
  1898.  
  1899.  
  1900. Moy                Standards Track               [Page 38]
  1901.  
  1902. RFC 2328             OSPF Version 2              April 1998
  1903.  
  1904.  
  1905.     of the graph connects to a network, or is itself a point-to-
  1906.     point network.    In either case,    the edge is colored with the
  1907.     network's Area ID.
  1908.  
  1909.     A group    of edges, all having the same color, and interconnected
  1910.     by vertices, represents    an area.  If the topology of the
  1911.     Autonomous System is intact, the graph will have several regions
  1912.     of color, each color being a distinct Area ID.
  1913.  
  1914.     When the AS topology changes, one of the areas may become
  1915.     partitioned.  The graph    of the AS will then have multiple
  1916.     regions    of the same color (Area    ID).  The routing in the
  1917.     Autonomous System will continue    to function as long as these
  1918.     regions    of same    color are connected by the single backbone
  1919.     region.
  1920.  
  1921.  
  1922.  
  1923.  
  1924.  
  1925.  
  1926.  
  1927.  
  1928.  
  1929.  
  1930.  
  1931.  
  1932.  
  1933.  
  1934.  
  1935.  
  1936.  
  1937.  
  1938.  
  1939.  
  1940.  
  1941.  
  1942.  
  1943.  
  1944.  
  1945.  
  1946.  
  1947.  
  1948.  
  1949.  
  1950. Moy                Standards Track               [Page 39]
  1951.  
  1952. RFC 2328             OSPF Version 2              April 1998
  1953.  
  1954.  
  1955. 4.  Functional Summary
  1956.  
  1957.     A separate copy of OSPF's basic routing algorithm runs in each area.
  1958.     Routers having interfaces to multiple areas    run multiple copies of
  1959.     the    algorithm.  A brief summary of the routing algorithm follows.
  1960.  
  1961.     When a router starts, it first initializes the routing protocol data
  1962.     structures.     The router then waits for indications from the    lower-
  1963.     level protocols that its interfaces    are functional.
  1964.  
  1965.     A router then uses the OSPF's Hello    Protocol to acquire neighbors.
  1966.     The    router sends Hello packets to its neighbors, and in turn
  1967.     receives their Hello packets.  On broadcast    and point-to-point
  1968.     networks, the router dynamically detects its neighboring routers by
  1969.     sending its    Hello packets to the multicast address AllSPFRouters.
  1970.     On non-broadcast networks, some configuration information may be
  1971.     necessary in order to discover neighbors.  On broadcast and    NBMA
  1972.     networks the Hello Protocol    also elects a Designated router    for the
  1973.     network.
  1974.  
  1975.     The    router will attempt to form adjacencies    with some of its newly
  1976.     acquired neighbors.     Link-state databases are synchronized between
  1977.     pairs of adjacent routers.    On broadcast and NBMA networks,    the
  1978.     Designated Router determines which routers should become adjacent.
  1979.  
  1980.     Adjacencies    control    the distribution of routing information.
  1981.     Routing updates are    sent and received only on adjacencies.
  1982.  
  1983.     A router periodically advertises its state,    which is also called
  1984.     link state.     Link state is also advertised when a router's state
  1985.     changes.  A    router's adjacencies are reflected in the contents of
  1986.     its    LSAs.  This relationship between adjacencies and link state
  1987.     allows the protocol    to detect dead routers in a timely fashion.
  1988.  
  1989.     LSAs are flooded throughout    the area.  The flooding    algorithm is
  1990.     reliable, ensuring that all    routers    in an area have    exactly    the same
  1991.     link-state database.  This database    consists of the    collection of
  1992.     LSAs originated by each router belonging to    the area.  From    this
  1993.     database each router calculates a shortest-path tree, with itself as
  1994.     root.  This    shortest-path tree in turn yields a routing table for
  1995.     the    protocol.
  1996.  
  1997.  
  1998.  
  1999.  
  2000. Moy                Standards Track               [Page 40]
  2001.  
  2002. RFC 2328             OSPF Version 2              April 1998
  2003.  
  2004.  
  2005.     4.1.  Inter-area routing
  2006.  
  2007.     The previous section described the operation of    the protocol
  2008.     within a single    area.  For intra-area routing, no other    routing
  2009.     information is pertinent.  In order to be able to route    to
  2010.     destinations outside of    the area, the area border routers inject
  2011.     additional routing information into the    area.  This additional
  2012.     information is a distillation of the rest of the Autonomous
  2013.     System's topology.
  2014.  
  2015.     This distillation is accomplished as follows: Each area    border
  2016.     router is by definition    connected to the backbone.  Each area
  2017.     border router summarizes the topology of its attached non-
  2018.     backbone areas for transmission    on the backbone, and hence to
  2019.     all other area border routers.    An area    border router then has
  2020.     complete topological information concerning the    backbone, and
  2021.     the area summaries from    each of    the other area border routers.
  2022.     From this information, the router calculates paths to all
  2023.     inter-area destinations.  The router then advertises these paths
  2024.     into its attached areas.  This enables the area's internal
  2025.     routers    to pick    the best exit router when forwarding traffic
  2026.     inter-area destinations.
  2027.  
  2028.  
  2029.     4.2.  AS external routes
  2030.  
  2031.     Routers    that have information regarding    other Autonomous Systems
  2032.     can flood this information throughout the AS.  This external
  2033.     routing    information is distributed verbatim to every
  2034.     participating router.  There is    one exception: external    routing
  2035.     information is not flooded into    "stub" areas (see Section 3.6).
  2036.  
  2037.     To utilize external routing information, the path to all routers
  2038.     advertising external information must be known throughout the AS
  2039.     (excepting the stub areas).  For that reason, the locations of
  2040.     these AS boundary routers are summarized by the    (non-stub) area
  2041.     border routers.
  2042.  
  2043.  
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.  
  2050. Moy                Standards Track               [Page 41]
  2051.  
  2052. RFC 2328             OSPF Version 2              April 1998
  2053.  
  2054.  
  2055.     4.3.  Routing protocol packets
  2056.  
  2057.     The OSPF protocol runs directly    over IP, using IP protocol 89.
  2058.     OSPF does not provide any explicit fragmentation/reassembly
  2059.     support.  When fragmentation is    necessary, IP
  2060.     fragmentation/reassembly is used.  OSPF    protocol packets have
  2061.     been designed so that large protocol packets can generally be
  2062.     split into several smaller protocol packets.  This practice is
  2063.     recommended; IP    fragmentation should be    avoided    whenever
  2064.     possible.
  2065.  
  2066.     Routing    protocol packets should    always be sent with the    IP TOS
  2067.     field set to 0.     If at all possible, routing protocol packets
  2068.     should be given    preference over    regular    IP data    traffic, both
  2069.     when being sent    and received.  As an aid to accomplishing this,
  2070.     OSPF protocol packets should have their    IP precedence field set
  2071.     to the value Internetwork Control (see [Ref5]).
  2072.  
  2073.     All OSPF protocol packets share    a common protocol header that is
  2074.     described in Appendix A.  The OSPF packet types    are listed below
  2075.     in Table 8.  Their formats are also described in Appendix A.
  2076.  
  2077.  
  2078.  
  2079.          Type   Packet  name       Protocol  function
  2080.          __________________________________________________________
  2081.          1        Hello           Discover/maintain  neighbors
  2082.          2        Database Description   Summarize database contents
  2083.          3        Link State Request       Database download
  2084.          4        Link State Update       Database update
  2085.          5        Link State Ack       Flooding acknowledgment
  2086.  
  2087.  
  2088.                 Table 8: OSPF packet types.
  2089.  
  2090.  
  2091.     OSPF's Hello protocol uses Hello packets to discover and
  2092.     maintain neighbor relationships.  The Database Description and
  2093.     Link State Request packets are used in the forming of
  2094.     adjacencies.  OSPF's reliable update mechanism is implemented by
  2095.     the Link State Update and Link State Acknowledgment packets.
  2096.  
  2097.  
  2098.  
  2099.  
  2100. Moy                Standards Track               [Page 42]
  2101.  
  2102. RFC 2328             OSPF Version 2              April 1998
  2103.  
  2104.  
  2105.     Each Link State    Update packet carries a    set of new link    state
  2106.     advertisements (LSAs) one hop further away from    their point of
  2107.     origination.  A    single Link State Update packet    may contain the
  2108.     LSAs of    several    routers.  Each LSA is tagged with the ID of the
  2109.     originating router and a checksum of its link state contents.
  2110.     Each LSA also has a type field;    the different types of OSPF LSAs
  2111.     are listed below in Table 9.
  2112.  
  2113.     OSPF routing packets (with the exception of Hellos) are    sent
  2114.     only over adjacencies.    This means that    all OSPF protocol
  2115.     packets    travel a single    IP hop,    except those that are sent over
  2116.     virtual    adjacencies.  The IP source address of an OSPF protocol
  2117.     packet is one end of a router adjacency, and the IP destination
  2118.     address    is either the other end    of the adjacency or an IP
  2119.     multicast address.
  2120.  
  2121.  
  2122.     4.4.  Basic    implementation requirements
  2123.  
  2124.     An implementation of OSPF requires the following pieces    of
  2125.     system support:
  2126.  
  2127.  
  2128.     Timers
  2129.         Two    different kind of timers are required.    The first kind,
  2130.         called "single shot    timers", fire once and cause a protocol
  2131.         event to be    processed.  The    second kind, called "interval
  2132.         timers", fire at continuous    intervals.  These are used for
  2133.         the    sending    of packets at regular intervals.  A good example
  2134.         of this is the regular broadcast of    Hello packets. The
  2135.         granularity    of both    kinds of timers    is one second.
  2136.  
  2137.         Interval timers should be implemented to avoid drift.  In
  2138.         some router    implementations, packet    processing can affect
  2139.         timer execution.  When multiple routers are    attached to a
  2140.         single network, all    doing broadcasts, this can lead    to the
  2141.         synchronization of routing packets (which should be
  2142.         avoided).  If timers cannot    be implemented to avoid    drift,
  2143.         small random amounts should    be added to/subtracted from the
  2144.         interval timer at each firing.
  2145.  
  2146.  
  2147.  
  2148.  
  2149.  
  2150. Moy                Standards Track               [Page 43]
  2151.  
  2152. RFC 2328             OSPF Version 2              April 1998
  2153.  
  2154.  
  2155.  
  2156.  
  2157.     LS     LSA          LSA description
  2158.     type   name
  2159.     ________________________________________________________
  2160.     1      Router-LSAs      Originated by    all routers.
  2161.                   This LSA describes
  2162.                   the collected    states of the
  2163.                   router's interfaces to an
  2164.                   area.    Flooded    throughout a
  2165.                   single area only.
  2166.     ________________________________________________________
  2167.     2      Network-LSAs      Originated for broadcast
  2168.                   and NBMA networks by
  2169.                   the Designated Router. This
  2170.                   LSA contains the
  2171.                   list of routers connected
  2172.                   to the network. Flooded
  2173.                   throughout a single area only.
  2174.     ________________________________________________________
  2175.     3,4    Summary-LSAs      Originated by    area border
  2176.                   routers, and flooded through-
  2177.                   out the LSA's    associated
  2178.                   area.    Each summary-LSA
  2179.                   describes a route to a
  2180.                   destination outside the area,
  2181.                   yet still inside the AS
  2182.                   (i.e., an inter-area route).
  2183.                   Type 3 summary-LSAs describe
  2184.                   routes to networks. Type 4
  2185.                   summary-LSAs describe
  2186.                   routes to AS boundary    routers.
  2187.     ________________________________________________________
  2188.     5      AS-external-LSAs      Originated by    AS boundary
  2189.                   routers, and flooded through-
  2190.                   out the AS. Each
  2191.                   AS-external-LSA describes
  2192.                   a route to a destination in
  2193.                   another Autonomous System.
  2194.                   Default routes for the AS can
  2195.                   also be described by
  2196.                   AS-external-LSAs.
  2197.  
  2198.  
  2199.  
  2200. Moy                Standards Track               [Page 44]
  2201.  
  2202. RFC 2328             OSPF Version 2              April 1998
  2203.  
  2204.  
  2205.         Table 9: OSPF link state advertisements (LSAs).
  2206.  
  2207.  
  2208.  
  2209.     IP multicast
  2210.         Certain OSPF packets take the form of IP multicast
  2211.         datagrams.    Support    for receiving and sending IP multicast
  2212.         datagrams, along with the appropriate lower-level protocol
  2213.         support, is    required.  The IP multicast datagrams used by
  2214.         OSPF never travel more than    one hop. For this reason, the
  2215.         ability to forward IP multicast datagrams is not required.
  2216.         For    information on IP multicast, see [Ref7].
  2217.  
  2218.     Variable-length    subnet support
  2219.         The    router's IP protocol support must include the ability to
  2220.         divide a single IP class A,    B, or C    network    number into many
  2221.         subnets of various sizes.  This is commonly    called
  2222.         variable-length subnetting;    see Section 3.5    for details.
  2223.  
  2224.     IP supernetting    support
  2225.         The    router's IP protocol support must include the ability to
  2226.         aggregate contiguous collections of    IP class A, B, and C
  2227.         networks into larger quantities called supernets.
  2228.         Supernetting has been proposed as one way to improve the
  2229.         scaling of IP routing in the worldwide Internet. For more
  2230.         information    on IP supernetting, see    [Ref10].
  2231.  
  2232.     Lower-level protocol support
  2233.         The    lower level protocols referred to here are the network
  2234.         access protocols, such as the Ethernet data    link layer.
  2235.         Indications    must be    passed from these protocols to OSPF as
  2236.         the    network    interface goes up and down.  For example, on an
  2237.         ethernet it    would be valuable to know when the ethernet
  2238.         transceiver    cable becomes unplugged.
  2239.  
  2240.     Non-broadcast lower-level protocol support
  2241.         On non-broadcast networks, the OSPF    Hello Protocol can be
  2242.         aided by providing an indication when an attempt is    made to
  2243.         send a packet to a dead or non-existent router.  For
  2244.         example, on    an X.25    PDN a dead neighboring router may be
  2245.  
  2246.  
  2247.  
  2248.  
  2249.  
  2250. Moy                Standards Track               [Page 45]
  2251.  
  2252. RFC 2328             OSPF Version 2              April 1998
  2253.  
  2254.  
  2255.         indicated by the reception of a X.25 clear with an
  2256.         appropriate    cause and diagnostic, and this information would
  2257.         be passed to OSPF.
  2258.  
  2259.     List manipulation primitives
  2260.         Much of the    OSPF functionality is described    in terms of its
  2261.         operation on lists of LSAs.     For example, the collection of
  2262.         LSAs that will be retransmitted to an adjacent router until
  2263.         acknowledged are described as a list.  Any particular LSA
  2264.         may    be on many such    lists.    An OSPF    implementation needs to
  2265.         be able to manipulate these    lists, adding and deleting
  2266.         constituent    LSAs as    necessary.
  2267.  
  2268.     Tasking    support
  2269.         Certain procedures described in this specification invoke
  2270.         other procedures.  At times, these other procedures    should
  2271.         be executed    in-line, that is, before the current procedure
  2272.         is finished.  This is indicated in the text    by instructions
  2273.         to execute a procedure.  At    other times, the other
  2274.         procedures are to be executed only when the    current
  2275.         procedure has finished.  This is indicated by instructions
  2276.         to schedule    a task.
  2277.  
  2278.  
  2279.     4.5.  Optional OSPF    capabilities
  2280.  
  2281.     The OSPF protocol defines several optional capabilities.  A
  2282.     router indicates the optional capabilities that    it supports in
  2283.     its OSPF Hello packets,    Database Description packets and in its
  2284.     LSAs.  This enables routers supporting a mix of    optional
  2285.     capabilities to    coexist    in a single Autonomous System.
  2286.  
  2287.     Some capabilities must be supported by all routers attached to a
  2288.     specific area.    In this    case, a    router will not    accept a
  2289.     neighbor's Hello Packet    unless there is    a match    in reported
  2290.     capabilities (i.e., a capability mismatch prevents a neighbor
  2291.     relationship from forming).  An    example    of this    is the
  2292.     ExternalRoutingCapability (see below).
  2293.  
  2294.     Other capabilities can be negotiated during the    Database
  2295.     Exchange process.  This    is accomplished    by specifying the
  2296.     optional capabilities in Database Description packets.    A
  2297.  
  2298.  
  2299.  
  2300. Moy                Standards Track               [Page 46]
  2301.  
  2302. RFC 2328             OSPF Version 2              April 1998
  2303.  
  2304.  
  2305.     capability mismatch with a neighbor in this case will result in
  2306.     only a subset of the link state    database being exchanged between
  2307.     the two    neighbors.
  2308.  
  2309.     The routing table build    process    can also be affected by    the
  2310.     presence/absence of optional capabilities.  For    example, since
  2311.     the optional capabilities are reported in LSAs,    routers
  2312.     incapable of certain functions can be avoided when building the
  2313.     shortest path tree.
  2314.  
  2315.     The OSPF optional capabilities defined in this memo are    listed
  2316.     below.    See Section A.2    for more information.
  2317.  
  2318.  
  2319.     ExternalRoutingCapability
  2320.         Entire OSPF    areas can be configured    as "stubs" (see    Section
  2321.         3.6).  AS-external-LSAs will not be    flooded    into stub areas.
  2322.         This capability is represented by the E-bit    in the OSPF
  2323.         Options field (see Section A.2).  In order to ensure
  2324.         consistent configuration of    stub areas, all    routers
  2325.         interfacing    to such    an area    must have the E-bit clear in
  2326.         their Hello    packets    (see Sections 9.5 and 10.5).
  2327.  
  2328.  
  2329. 5.  Protocol Data Structures
  2330.  
  2331.     The    OSPF protocol is described herein in terms of its operation on
  2332.     various protocol data structures.  The following list comprises the
  2333.     top-level OSPF data    structures.  Any initialization    that needs to be
  2334.     done is noted.  OSPF areas,    interfaces and neighbors also have
  2335.     associated data structures that are    described later    in this
  2336.     specification.
  2337.  
  2338.     Router ID
  2339.     A 32-bit number    that uniquely identifies this router in    the AS.
  2340.     One possible implementation strategy would be to use the
  2341.     smallest IP interface address belonging    to the router. If a
  2342.     router's OSPF Router ID    is changed, the    router's OSPF software
  2343.     should be restarted before the new Router ID takes effect.  In
  2344.     this case the router should flush its self-originated LSAs from
  2345.     the routing domain (see    Section    14.1) before restarting, or they
  2346.     will persist for up to MaxAge minutes.
  2347.  
  2348.  
  2349.  
  2350. Moy                Standards Track               [Page 47]
  2351.  
  2352. RFC 2328             OSPF Version 2              April 1998
  2353.  
  2354.  
  2355.     Area structures
  2356.     Each one of the    areas to which the router is connected has its
  2357.     own data structure.  This data structure describes the working
  2358.     of the basic OSPF algorithm.  Remember that each area runs a
  2359.     separate copy of the basic OSPF    algorithm.
  2360.  
  2361.     Backbone (area) structure
  2362.     The OSPF backbone area is responsible for the dissemination of
  2363.     inter-area routing information.
  2364.  
  2365.     Virtual links configured
  2366.     The virtual links configured with this router as one endpoint.
  2367.     In order to have configured virtual links, the router itself
  2368.     must be    an area    border router.    Virtual    links are identified by
  2369.     the Router ID of the other endpoint -- which is    another    area
  2370.     border router.    These two endpoint routers must    be attached to a
  2371.     common area, called the    virtual    link's Transit area.  Virtual
  2372.     links are part of the backbone,    and behave as if they were
  2373.     unnumbered point-to-point networks between the two routers.  A
  2374.     virtual    link uses the intra-area routing of its    Transit    area to
  2375.     forward    packets.  Virtual links    are brought up and down    through
  2376.     the building of    the shortest-path trees    for the    Transit    area.
  2377.  
  2378.     List of external routes
  2379.     These are routes to destinations external to the Autonomous
  2380.     System,    that have been gained either through direct experience
  2381.     with another routing protocol (such as BGP), or    through
  2382.     configuration information, or through a    combination of the two
  2383.     (e.g., dynamic external    information to be advertised by    OSPF
  2384.     with configured    metric). Any router having these external routes
  2385.     is called an AS    boundary router.  These    routes are advertised by
  2386.     the router into    the OSPF routing domain    via AS-external-LSAs.
  2387.  
  2388.     List of AS-external-LSAs
  2389.     Part of    the link-state database.  These    have originated    from the
  2390.     AS boundary routers.  They comprise routes to destinations
  2391.     external to the    Autonomous System.  Note that, if the router is
  2392.     itself an AS boundary router, some of these AS-external-LSAs
  2393.     have been self-originated.
  2394.  
  2395.  
  2396.  
  2397.  
  2398.  
  2399.  
  2400. Moy                Standards Track               [Page 48]
  2401.  
  2402. RFC 2328             OSPF Version 2              April 1998
  2403.  
  2404.  
  2405.     The    routing    table
  2406.     Derived    from the link-state database.  Each entry in the routing
  2407.     table is indexed by a destination, and contains    the
  2408.     destination's cost and a set of    paths to use in    forwarding
  2409.     packets    to the destination. A path is described    by its type and
  2410.     next hop.  For more information, see Section 11.
  2411.  
  2412.     Figure 9 shows the collection of data structures present in    a
  2413.     typical router.  The router    pictured is RT10, from the map in Figure
  2414.     6.    Note that Router RT10 has a virtual link configured to Router
  2415.     RT11, with Area 2 as the link's Transit area.  This    is indicated by
  2416.     the    dashed line in Figure 9.  When the virtual link    becomes    active,
  2417.     through the    building of the    shortest path tree for Area 2, it
  2418.     becomes an interface to the    backbone (see the two backbone
  2419.     interfaces depicted    in Figure 9).
  2420.  
  2421. 6.  The    Area Data Structure
  2422.  
  2423.     The    area data structure contains all the information used to run the
  2424.     basic OSPF routing algorithm. Each area maintains its own link-state
  2425.     database. A    network    belongs    to a single area, and a    router interface
  2426.     connects to    a single area. Each router adjacency also belongs to a
  2427.     single area.
  2428.  
  2429.     The    OSPF backbone is the special OSPF area responsible for
  2430.     disseminating inter-area routing information.
  2431.  
  2432.     The    area link-state    database consists of the collection of router-
  2433.     LSAs, network-LSAs and summary-LSAs    that have originated from the
  2434.     area's routers.  This information is flooded throughout a single
  2435.     area only.    The list of AS-external-LSAs (see Section 5) is    also
  2436.     considered to be part of each area's link-state database.
  2437.  
  2438.     Area ID
  2439.     A 32-bit number    identifying the    area. The Area ID of 0.0.0.0 is
  2440.     reserved for the backbone.
  2441.  
  2442.     List of area address ranges
  2443.     In order to aggregate routing information at area boundaries,
  2444.     area address ranges can    be employed. Each address range    is
  2445.     specified by an    [address,mask] pair and    a status indication of
  2446.     either Advertise or DoNotAdvertise (see    Section    12.4.3).
  2447.  
  2448.  
  2449.  
  2450. Moy                Standards Track               [Page 49]
  2451.  
  2452. RFC 2328             OSPF Version 2              April 1998
  2453.  
  2454.  
  2455.  
  2456.  
  2457.  
  2458.                   +----+
  2459.                   |RT10|------+
  2460.                   +----+       \+-------------+
  2461.                  /        \        |Routing Table|
  2462.                 /         \        +-------------+
  2463.                /          \
  2464.           +------+      /           \    +--------+
  2465.           |Area 2|---+        +---|Backbone|
  2466.           +------+***********+        +--------+
  2467.          /          \          *       /          \
  2468.         /           \       *      /           \
  2469.        +---------+  +---------+       +------------+    +------------+
  2470.        |Interface|  |Interface|       |Virtual Link|    |Interface Ib|
  2471.        |  to N6     |  |  to N8  |       |   to RT11    |    +------------+
  2472.        +---------+  +---------+       +------------+          |
  2473.        /  \          |          |              |
  2474.       /    \      |          |              |
  2475.    +--------+ +--------+  |       +-------------+    +------------+
  2476.    |Neighbor| |Neighbor|  |       |Neighbor RT11|    |Neighbor RT6|
  2477.    |  RT8   | |     RT7   |  |       +-------------+    +------------+
  2478.    +--------+ +--------+  |
  2479.               |
  2480.              +-------------+
  2481.              |Neighbor RT11|
  2482.              +-------------+
  2483.  
  2484.  
  2485.         Figure 9: Router RT10's    Data structures
  2486.  
  2487.     Associated router interfaces
  2488.     This router's interfaces connecting to the area.  A router
  2489.     interface belongs to one and only one area (or the backbone).
  2490.     For the    backbone area this list    includes all the virtual links.
  2491.     A virtual link is identified by    the Router ID of its other
  2492.     endpoint; its cost is the cost of the shortest intra-area path
  2493.     through    the Transit area that exists between the two routers.
  2494.  
  2495.  
  2496.  
  2497.  
  2498.  
  2499.  
  2500. Moy                Standards Track               [Page 50]
  2501.  
  2502. RFC 2328             OSPF Version 2              April 1998
  2503.  
  2504.  
  2505.     List of router-LSAs
  2506.     A router-LSA is    generated by each router in the    area.  It
  2507.     describes the state of the router's interfaces to the area.
  2508.  
  2509.     List of network-LSAs
  2510.     One network-LSA    is generated for each transit broadcast    and NBMA
  2511.     network    in the area.  A    network-LSA describes the set of routers
  2512.     currently connected to the network.
  2513.  
  2514.     List of summary-LSAs
  2515.     Summary-LSAs originate from the    area's area border routers.
  2516.     They describe routes to    destinations internal to the Autonomous
  2517.     System,    yet external to    the area (i.e.,    inter-area
  2518.     destinations).
  2519.  
  2520.     Shortest-path tree
  2521.     The shortest-path tree for the area, with this router itself as
  2522.     root.  Derived from the    collected router-LSAs and network-LSAs
  2523.     by the Dijkstra    algorithm (see Section 16.1).
  2524.  
  2525.     TransitCapability
  2526.     This parameter indicates whether the area can carry data traffic
  2527.     that neither originates    nor terminates in the area itself. This
  2528.     parameter is calculated    when the area's    shortest-path tree is
  2529.     built (see Section 16.1, where TransitCapability is set    to TRUE
  2530.     if and only if there are one or    more fully adjacent virtual
  2531.     links using the    area as    Transit    area), and is used as an input
  2532.     to a subsequent    step of    the routing table build    process    (see
  2533.     Section    16.3). When an area's TransitCapability    is set to TRUE,
  2534.     the area is said to be a "transit area".
  2535.  
  2536.     ExternalRoutingCapability
  2537.     Whether    AS-external-LSAs will be flooded into/throughout the
  2538.     area.  This is a configurable parameter.  If AS-external-LSAs
  2539.     are excluded from the area, the    area is    called a "stub". Within
  2540.     stub areas, routing to AS external destinations    will be    based
  2541.     solely on a default summary route.  The    backbone cannot    be
  2542.     configured as a    stub area.  Also, virtual links    cannot be
  2543.     configured through stub    areas.    For more information, see
  2544.     Section    3.6.
  2545.  
  2546.  
  2547.  
  2548.  
  2549.  
  2550. Moy                Standards Track               [Page 51]
  2551.  
  2552. RFC 2328             OSPF Version 2              April 1998
  2553.  
  2554.  
  2555.     StubDefaultCost
  2556.     If the area has    been configured    as a stub area,    and the    router
  2557.     itself is an area border router, then the StubDefaultCost
  2558.     indicates the cost of the default summary-LSA that the router
  2559.     should advertise into the area.    See Section 12.4.3 for more
  2560.     information.
  2561.  
  2562.  
  2563.     Unless otherwise specified,    the remaining sections of this document
  2564.     refer to the operation of the OSPF protocol    within a single    area.
  2565.  
  2566.  
  2567. 7.  Bringing Up    Adjacencies
  2568.  
  2569.     OSPF creates adjacencies between neighboring routers for the purpose
  2570.     of exchanging routing information.    Not every two neighboring
  2571.     routers will become    adjacent.  This    section    covers the generalities
  2572.     involved in    creating adjacencies.  For further details consult
  2573.     Section 10.
  2574.  
  2575.  
  2576.     7.1.  The Hello Protocol
  2577.  
  2578.     The Hello Protocol is responsible for establishing and
  2579.     maintaining neighbor relationships.  It    also ensures that
  2580.     communication between neighbors    is bidirectional.  Hello packets
  2581.     are sent periodically out all router interfaces.  Bidirectional
  2582.     communication is indicated when    the router sees    itself listed in
  2583.     the neighbor's Hello Packet.  On broadcast and NBMA networks,
  2584.     the Hello Protocol elects a Designated Router for the network.
  2585.  
  2586.     The Hello Protocol works differently on    broadcast networks, NBMA
  2587.     networks and Point-to-MultiPoint networks.  On broadcast
  2588.     networks, each router advertises itself    by periodically
  2589.     multicasting Hello Packets.  This allows neighbors to be
  2590.     discovered dynamically.     These Hello Packets contain the
  2591.     router's view of the Designated    Router's identity, and the list
  2592.     of routers whose Hello Packets have been seen recently.
  2593.  
  2594.     On NBMA    networks some configuration information    may be necessary
  2595.     for the    operation of the Hello Protocol.  Each router that may
  2596.     potentially become Designated Router has a list    of all other
  2597.  
  2598.  
  2599.  
  2600. Moy                Standards Track               [Page 52]
  2601.  
  2602. RFC 2328             OSPF Version 2              April 1998
  2603.  
  2604.  
  2605.     routers    attached to the    network.  A router, having Designated
  2606.     Router potential, sends    Hello Packets to all other potential
  2607.     Designated Routers when    its interface to the NBMA network first
  2608.     becomes    operational.  This is an attempt to find the Designated
  2609.     Router for the network.     If the    router itself is elected
  2610.     Designated Router, it begins sending Hello Packets to all other
  2611.     routers    attached to the    network.
  2612.  
  2613.     On Point-to-MultiPoint networks, a router sends    Hello Packets to
  2614.     all neighbors with which it can    communicate directly. These
  2615.     neighbors may be discovered dynamically    through    a protocol such
  2616.     as Inverse ARP (see [Ref14]), or they may be configured.
  2617.  
  2618.     After a    neighbor has been discovered, bidirectional
  2619.     communication ensured, and (if on a broadcast or NBMA network) a
  2620.     Designated Router elected, a decision is made regarding    whether
  2621.     or not an adjacency should be formed with the neighbor (see
  2622.     Section    10.4). If an adjacency is to be    formed,    the first step
  2623.     is to synchronize the neighbors' link-state databases.    This is
  2624.     covered    in the next section.
  2625.  
  2626.  
  2627.     7.2.  The Synchronization of Databases
  2628.  
  2629.     In a link-state    routing    algorithm, it is very important    for all
  2630.     routers' link-state databases to stay synchronized.  OSPF
  2631.     simplifies this    by requiring only adjacent routers to remain
  2632.     synchronized.  The synchronization process begins as soon as the
  2633.     routers    attempt    to bring up the    adjacency.  Each router
  2634.     describes its database by sending a sequence of    Database
  2635.     Description packets to its neighbor.  Each Database Description
  2636.     Packet describes a set of LSAs belonging to the    router's
  2637.     database.  When    the neighbor sees an LSA that is more recent
  2638.     than its own database copy, it makes a note that this newer LSA
  2639.     should be requested.
  2640.  
  2641.     This sending and receiving of Database Description packets is
  2642.     called the "Database Exchange Process".     During    this process,
  2643.     the two    routers    form a master/slave relationship.  Each    Database
  2644.     Description Packet has a sequence number.  Database Description
  2645.     Packets    sent by    the master (polls) are acknowledged by the slave
  2646.     through    echoing    of the sequence    number.     Both polls and    their
  2647.  
  2648.  
  2649.  
  2650. Moy                Standards Track               [Page 53]
  2651.  
  2652. RFC 2328             OSPF Version 2              April 1998
  2653.  
  2654.  
  2655.     responses contain summaries of link state data.     The master is
  2656.     the only one allowed to    retransmit Database Description    Packets.
  2657.     It does    so only    at fixed intervals, the    length of which    is the
  2658.     configured per-interface constant RxmtInterval.
  2659.  
  2660.     Each Database Description contains an indication that there are
  2661.     more packets to    follow --- the M-bit.  The Database Exchange
  2662.     Process    is over    when a router has received and sent Database
  2663.     Description Packets with the M-bit off.
  2664.  
  2665.     During and after the Database Exchange Process,    each router has
  2666.     a list of those    LSAs for which the neighbor has    more up-to-date
  2667.     instances.  These LSAs are requested in    Link State Request
  2668.     Packets.  Link State Request packets that are not satisfied are
  2669.     retransmitted at fixed intervals of time RxmtInterval.    When the
  2670.     Database Description Process has completed and all Link    State
  2671.     Requests have been satisfied, the databases are    deemed
  2672.     synchronized and the routers are marked    fully adjacent.     At this
  2673.     time the adjacency is fully functional and is advertised in the
  2674.     two routers' router-LSAs.
  2675.  
  2676.     The adjacency is used by the flooding procedure    as soon    as the
  2677.     Database Exchange Process begins.  This    simplifies database
  2678.     synchronization, and guarantees    that it    finishes in a
  2679.     predictable period of time.
  2680.  
  2681.  
  2682.     7.3.  The Designated Router
  2683.  
  2684.     Every broadcast    and NBMA network has a Designated Router.  The
  2685.     Designated Router performs two main functions for the routing
  2686.     protocol:
  2687.  
  2688.     o   The    Designated Router originates a network-LSA on behalf of
  2689.         the    network.  This LSA lists the set of routers (including
  2690.         the    Designated Router itself) currently attached to    the
  2691.         network.  The Link State ID    for this LSA (see Section
  2692.         12.1.4) is the IP interface    address    of the Designated
  2693.         Router.  The IP network number can then be obtained    by using
  2694.         the    network's subnet/network mask.
  2695.  
  2696.  
  2697.  
  2698.  
  2699.  
  2700. Moy                Standards Track               [Page 54]
  2701.  
  2702. RFC 2328             OSPF Version 2              April 1998
  2703.  
  2704.  
  2705.     o   The    Designated Router becomes adjacent to all other    routers
  2706.         on the network.  Since the link state databases are
  2707.         synchronized across    adjacencies (through adjacency bring-up
  2708.         and    then the flooding procedure), the Designated Router
  2709.         plays a central part in the    synchronization    process.
  2710.  
  2711.  
  2712.     The Designated Router is elected by the    Hello Protocol.     A
  2713.     router's Hello Packet contains its Router Priority, which is
  2714.     configurable on    a per-interface    basis.    In general, when a
  2715.     router's interface to a    network    first becomes functional, it
  2716.     checks to see whether there is currently a Designated Router for
  2717.     the network.  If there is, it accepts that Designated Router,
  2718.     regardless of its Router Priority.  (This makes    it harder to
  2719.     predict    the identity of    the Designated Router, but ensures that
  2720.     the Designated Router changes less often.  See below.)
  2721.     Otherwise, the router itself becomes Designated    Router if it has
  2722.     the highest Router Priority on the network.  A more detailed
  2723.     (and more accurate) description    of Designated Router election is
  2724.     presented in Section 9.4.
  2725.  
  2726.     The Designated Router is the endpoint of many adjacencies.  In
  2727.     order to optimize the flooding procedure on broadcast networks,
  2728.     the Designated Router multicasts its Link State    Update Packets
  2729.     to the address AllSPFRouters, rather than sending separate
  2730.     packets    over each adjacency.
  2731.  
  2732.     Section    2 of this document discusses the directed graph
  2733.     representation of an area.  Router nodes are labelled with their
  2734.     Router ID.  Transit network nodes are actually labelled    with the
  2735.     IP address of their Designated Router.    It follows that    when the
  2736.     Designated Router changes, it appears as if the    network    node on
  2737.     the graph is replaced by an entirely new node.    This will cause
  2738.     the network and    all its    attached routers to originate new LSAs.
  2739.     Until the link-state databases again converge, some temporary
  2740.     loss of    connectivity may result.  This may result in ICMP
  2741.     unreachable messages being sent    in response to data traffic.
  2742.     For that reason, the Designated    Router should change only
  2743.     infrequently.  Router Priorities should    be configured so that
  2744.     the most dependable router on a    network    eventually becomes
  2745.     Designated Router.
  2746.  
  2747.  
  2748.  
  2749.  
  2750. Moy                Standards Track               [Page 55]
  2751.  
  2752. RFC 2328             OSPF Version 2              April 1998
  2753.  
  2754.  
  2755.     7.4.  The Backup Designated    Router
  2756.  
  2757.     In order to make the transition    to a new Designated Router
  2758.     smoother, there    is a Backup Designated Router for each broadcast
  2759.     and NBMA network.  The Backup Designated Router    is also    adjacent
  2760.     to all routers on the network, and becomes Designated Router
  2761.     when the previous Designated Router fails.  If there were no
  2762.     Backup Designated Router, when a new Designated    Router became
  2763.     necessary, new adjacencies would have to be formed between the
  2764.     new Designated Router and all other routers attached to    the
  2765.     network.  Part of the adjacency    forming    process    is the
  2766.     synchronizing of link-state databases, which can potentially
  2767.     take quite a long time.     During    this time, the network would not
  2768.     be available for transit data traffic.    The Backup Designated
  2769.     obviates the need to form these    adjacencies, since they    already
  2770.     exist.    This means the period of disruption in transit traffic
  2771.     lasts only as long as it takes to flood    the new    LSAs (which
  2772.     announce the new Designated Router).
  2773.  
  2774.     The Backup Designated Router does not generate a network-LSA for
  2775.     the network.  (If it did, the transition to a new Designated
  2776.     Router would be    even faster.  However, this is a tradeoff
  2777.     between    database size and speed    of convergence when the
  2778.     Designated Router disappears.)
  2779.  
  2780.     The Backup Designated Router is    also elected by    the Hello
  2781.     Protocol.  Each    Hello Packet has a field that specifies    the
  2782.     Backup Designated Router for the network.
  2783.  
  2784.     In some    steps of the flooding procedure, the Backup Designated
  2785.     Router plays a passive role, letting the Designated Router do
  2786.     more of    the work.  This    cuts down on the amount    of local routing
  2787.     traffic.  See Section 13.3 for more information.
  2788.  
  2789.  
  2790.     7.5.  The graph of adjacencies
  2791.  
  2792.     An adjacency is    bound to the network that the two routers have
  2793.     in common.  If two routers have    multiple networks in common,
  2794.     they may have multiple adjacencies between them.
  2795.  
  2796.  
  2797.  
  2798.  
  2799.  
  2800. Moy                Standards Track               [Page 56]
  2801.  
  2802. RFC 2328             OSPF Version 2              April 1998
  2803.  
  2804.  
  2805.     One can    picture    the collection of adjacencies on a network as
  2806.     forming    an undirected graph.  The vertices consist of routers,
  2807.     with an    edge joining two routers if they are adjacent.    The
  2808.     graph of adjacencies describes the flow    of routing protocol
  2809.     packets, and in    particular Link    State Update Packets, through
  2810.     the Autonomous System.
  2811.  
  2812.     Two graphs are possible, depending on whether a    Designated
  2813.     Router is elected for the network.  On physical    point-to-point
  2814.     networks, Point-to-MultiPoint networks and virtual links,
  2815.     neighboring routers become adjacent whenever they can
  2816.     communicate directly.  In contrast, on broadcast and NBMA
  2817.     networks only the Designated Router and    the Backup Designated
  2818.     Router become adjacent to all other routers attached to    the
  2819.     network.
  2820.  
  2821.  
  2822.  
  2823.       +---+           +---+
  2824.       |RT1|------------|RT2|        o---------------o
  2825.       +---+       N1       +---+       RT1           RT2
  2826.  
  2827.  
  2828.  
  2829.                          RT7
  2830.                           o---------+
  2831.         +---+   +---+   +---+         /|\        |
  2832.         |RT7|   |RT3|   |RT4|        / | \        |
  2833.         +---+   +---+   +---+           /  |  \        |
  2834.           |          |          |              /      |   \        |
  2835.      +-----------------------+      RT5o RT6o    oRT4 |
  2836.           |      |    N2          *      *   *        |
  2837.         +---+    +---+               *  *  *        |
  2838.         |RT5|    |RT6|            * * *        |
  2839.         +---+    +---+             ***        |
  2840.                           o---------+
  2841.                          RT3
  2842.  
  2843.  
  2844.           Figure 10: The graph of adjacencies
  2845.  
  2846.  
  2847.  
  2848.  
  2849.  
  2850. Moy                Standards Track               [Page 57]
  2851.  
  2852. RFC 2328             OSPF Version 2              April 1998
  2853.  
  2854.  
  2855.     These graphs are shown in Figure 10.  It is assumed that Router
  2856.     RT7 has    become the Designated Router, and Router RT3 the Backup
  2857.     Designated Router, for the Network N2.    The Backup Designated
  2858.     Router performs    a lesser function during the flooding procedure
  2859.     than the Designated Router (see    Section    13.3).    This is    the
  2860.     reason for the dashed lines connecting the Backup Designated
  2861.     Router RT3.
  2862.  
  2863.  
  2864. 8.  Protocol Packet Processing
  2865.  
  2866.     This section discusses the general processing of OSPF routing
  2867.     protocol packets.  It is very important that the router link-state
  2868.     databases remain synchronized.  For    this reason, routing protocol
  2869.     packets should get preferential treatment over ordinary data
  2870.     packets, both in sending and receiving.
  2871.  
  2872.     Routing protocol packets are sent along adjacencies    only (with the
  2873.     exception of Hello packets,    which are used to discover the
  2874.     adjacencies).  This    means that all routing protocol    packets    travel a
  2875.     single IP hop, except those    sent over virtual links.
  2876.  
  2877.     All    routing    protocol packets begin with a standard header.    The
  2878.     sections below provide details on how to fill in and verify    this
  2879.     standard header.  Then, for    each packet type, the section giving
  2880.     more details on that particular packet type's processing is    listed.
  2881.  
  2882.     8.1.  Sending protocol packets
  2883.  
  2884.     When a router sends a routing protocol packet, it fills    in the
  2885.     fields of the standard OSPF packet header as follows.  For more
  2886.     details    on the header format consult Section A.3.1:
  2887.  
  2888.     Version    #
  2889.         Set    to 2, the version number of the    protocol as documented
  2890.         in this specification.
  2891.  
  2892.     Packet type
  2893.         The    type of    OSPF packet, such as Link state    Update or Hello
  2894.         Packet.
  2895.  
  2896.  
  2897.  
  2898.  
  2899.  
  2900. Moy                Standards Track               [Page 58]
  2901.  
  2902. RFC 2328             OSPF Version 2              April 1998
  2903.  
  2904.  
  2905.     Packet length
  2906.         The    length of the entire OSPF packet in bytes, including the
  2907.         standard OSPF packet header.
  2908.  
  2909.     Router ID
  2910.         The    identity of the    router itself (who is originating the
  2911.         packet).
  2912.  
  2913.     Area ID
  2914.         The    OSPF area that the packet is being sent    into.
  2915.  
  2916.     Checksum
  2917.         The    standard IP 16-bit one's complement checksum of    the
  2918.         entire OSPF    packet,    excluding the 64-bit authentication
  2919.         field.  This checksum is calculated    as part    of the
  2920.         appropriate    authentication procedure; for some OSPF
  2921.         authentication types, the checksum calculation is omitted.
  2922.         See    Section    D.4 for    details.
  2923.  
  2924.     AuType and Authentication
  2925.         Each OSPF packet exchange is authenticated.     Authentication
  2926.         types are assigned by the protocol and are documented in
  2927.         Appendix D.     A different authentication procedure can be
  2928.         used for each IP network/subnet.  Autype indicates the type
  2929.         of authentication procedure    in use.    The 64-bit
  2930.         authentication field is then for use by the    chosen
  2931.         authentication procedure.  This procedure should be    the last
  2932.         called when    forming    the packet to be sent. See Section D.4
  2933.         for    details.
  2934.  
  2935.  
  2936.     The IP destination address for the packet is selected as
  2937.     follows.  On physical point-to-point networks, the IP
  2938.     destination is always set to the address AllSPFRouters.     On all
  2939.     other network types (including virtual links), the majority of
  2940.     OSPF packets are sent as unicasts, i.e., sent directly to the
  2941.     other end of the adjacency.  In    this case, the IP destination is
  2942.     just the Neighbor IP address associated    with the other end of
  2943.     the adjacency (see Section 10).     The only packets not sent as
  2944.     unicasts are on    broadcast networks; on these networks Hello
  2945.     packets    are sent to the    multicast destination AllSPFRouters, the
  2946.     Designated Router and its Backup send both Link    State Update
  2947.  
  2948.  
  2949.  
  2950. Moy                Standards Track               [Page 59]
  2951.  
  2952. RFC 2328             OSPF Version 2              April 1998
  2953.  
  2954.  
  2955.     Packets    and Link State Acknowledgment Packets to the multicast
  2956.     address    AllSPFRouters, while all other routers send both their
  2957.     Link State Update and Link State Acknowledgment    Packets    to the
  2958.     multicast address AllDRouters.
  2959.  
  2960.     Retransmissions    of Link    State Update packets are ALWAYS    sent
  2961.     directly to the    neighbor. On multi-access networks, this means
  2962.     that retransmissions should be sent to the neighbor's IP
  2963.     address.
  2964.  
  2965.     The IP source address should be    set to the IP address of the
  2966.     sending    interface.  Interfaces to unnumbered point-to-point
  2967.     networks have no associated IP address.     On these interfaces,
  2968.     the IP source should be    set to any of the other    IP addresses
  2969.     belonging to the router.  For this reason, there must be at
  2970.     least one IP address assigned to the router.[2]    Note that, for
  2971.     most purposes, virtual links act precisely the same as
  2972.     unnumbered point-to-point networks.  However, each virtual link
  2973.     does have an IP    interface address (discovered during the routing
  2974.     table build process) which is used as the IP source when sending
  2975.     packets    over the virtual link.
  2976.  
  2977.     For more information on    the format of specific OSPF packet
  2978.     types, consult the sections listed in Table 10.
  2979.  
  2980.  
  2981.  
  2982.          Type   Packet name           detailed section (transmit)
  2983.          _________________________________________________________
  2984.          1        Hello           Section  9.5
  2985.          2        Database description   Section 10.8
  2986.          3        Link state request       Section 10.9
  2987.          4        Link state update       Section 13.3
  2988.          5        Link state ack       Section 13.5
  2989.  
  2990.  
  2991.       Table 10:    Sections describing OSPF protocol packet transmission.
  2992.  
  2993.  
  2994.  
  2995.  
  2996.  
  2997.  
  2998.  
  2999.  
  3000. Moy                Standards Track               [Page 60]
  3001.  
  3002. RFC 2328             OSPF Version 2              April 1998
  3003.  
  3004.  
  3005.     8.2.  Receiving protocol packets
  3006.  
  3007.     Whenever a protocol packet is received by the router it    is
  3008.     marked with the    interface it was received on.  For routers that
  3009.     have virtual links configured, it may not be immediately obvious
  3010.     which interface    to associate the packet    with.  For example,
  3011.     consider the Router RT11 depicted in Figure 6.    If RT11    receives
  3012.     an OSPF    protocol packet    on its interface to Network N8,    it may
  3013.     want to    associate the packet with the interface    to Area    2, or
  3014.     with the virtual link to Router    RT10 (which is part of the
  3015.     backbone).  In the following, we assume    that the packet    is
  3016.     initially associated with the non-virtual  link.[3]
  3017.  
  3018.     In order for the packet    to be accepted at the IP level,    it must
  3019.     pass a number of tests,    even before the    packet is passed to OSPF
  3020.     for processing:
  3021.  
  3022.  
  3023.     o   The    IP checksum must be correct.
  3024.  
  3025.     o   The    packet's IP destination    address    must be    the IP address
  3026.         of the receiving interface,    or one of the IP multicast
  3027.         addresses AllSPFRouters or AllDRouters.
  3028.  
  3029.     o   The    IP protocol specified must be OSPF (89).
  3030.  
  3031.     o   Locally originated packets should not be passed on to OSPF.
  3032.         That is, the source    IP address should be examined to make
  3033.         sure this is not a multicast packet    that the router    itself
  3034.         generated.
  3035.  
  3036.  
  3037.     Next, the OSPF packet header is    verified.  The fields specified
  3038.     in the header must match those configured for the receiving
  3039.     interface.  If they do not, the    packet should be discarded:
  3040.  
  3041.  
  3042.     o   The    version    number field must specify protocol version 2.
  3043.  
  3044.     o   The    Area ID    found in the OSPF header must be verified.  If
  3045.         both of the    following cases    fail, the packet should    be
  3046.         discarded.    The Area ID specified in the header must either:
  3047.  
  3048.  
  3049.  
  3050. Moy                Standards Track               [Page 61]
  3051.  
  3052. RFC 2328             OSPF Version 2              April 1998
  3053.  
  3054.  
  3055.         (1)    Match the Area ID of the receiving interface.  In this
  3056.         case, the packet has been sent over a single hop.
  3057.         Therefore, the packet's    IP source address is required to
  3058.         be on the same network as the receiving    interface.  This
  3059.         can be verified    by comparing the packet's IP source
  3060.         address    to the interface's IP address, after masking
  3061.         both addresses with the    interface mask.     This comparison
  3062.         should not be performed    on point-to-point networks. On
  3063.         point-to-point networks, the interface addresses of each
  3064.         end of the link    are assigned independently, if they are
  3065.         assigned at all.
  3066.  
  3067.         (2)    Indicate the backbone.    In this    case, the packet has
  3068.         been sent over a virtual link.    The receiving router
  3069.         must be    an area    border router, and the Router ID
  3070.         specified in the packet    (the source router) must be the
  3071.         other end of a configured virtual link.     The receiving
  3072.         interface must also attach to the virtual link's
  3073.         configured Transit area.  If all of these checks
  3074.         succeed, the packet is accepted    and is from now    on
  3075.         associated with    the virtual link (and the backbone
  3076.         area).
  3077.  
  3078.     o   Packets whose IP destination is AllDRouters    should only be
  3079.         accepted if    the state of the receiving interface is    DR or
  3080.         Backup (see    Section    9.1).
  3081.  
  3082.     o   The    AuType specified in the    packet must match the AuType
  3083.         specified for the associated area.
  3084.  
  3085.     o   The    packet must be authenticated.  The authentication
  3086.         procedure is indicated by the setting of AuType (see
  3087.         Appendix D).  The authentication procedure may use one or
  3088.         more Authentication    keys, which can    be configured on a per-
  3089.         interface basis.  The authentication procedure may also
  3090.         verify the checksum    field in the OSPF packet header    (which,
  3091.         when used, is set to the standard IP 16-bit    one's complement
  3092.         checksum of    the OSPF packet's contents after excluding the
  3093.         64-bit authentication field).  If the authentication
  3094.         procedure fails, the packet    should be discarded.
  3095.  
  3096.  
  3097.  
  3098.  
  3099.  
  3100. Moy                Standards Track               [Page 62]
  3101.  
  3102. RFC 2328             OSPF Version 2              April 1998
  3103.  
  3104.  
  3105.     If the packet type is Hello, it    should then be further processed
  3106.     by the Hello Protocol (see Section 10.5).  All other packet
  3107.     types are sent/received    only on    adjacencies.  This means that
  3108.     the packet must    have been sent by one of the router's active
  3109.     neighbors.  If the receiving interface connects    to a broadcast
  3110.     network, Point-to-MultiPoint network or    NBMA network the sender
  3111.     is identified by the IP    source address found in    the packet's IP
  3112.     header.     If the    receiving interface connects to    a point-to-point
  3113.     network    or a virtual link, the sender is identified by the
  3114.     Router ID (source router) found    in the packet's    OSPF header.
  3115.     The data structure associated with the receiving interface
  3116.     contains the list of active neighbors.    Packets    not matching any
  3117.     active neighbor    are discarded.
  3118.  
  3119.     At this    point all received protocol packets are    associated with
  3120.     an active neighbor.  For the further input processing of
  3121.     specific packet    types, consult the sections listed in Table 11.
  3122.  
  3123.  
  3124.  
  3125.           Type   Packet name        detailed section (receive)
  3126.           ________________________________________________________
  3127.           1         Hello            Section 10.5
  3128.           2         Database description   Section 10.6
  3129.           3         Link state    request        Section 10.7
  3130.           4         Link state    update        Section 13
  3131.           5         Link state    ack        Section 13.7
  3132.  
  3133.  
  3134.       Table 11:    Sections describing OSPF protocol packet reception.
  3135.  
  3136.  
  3137.  
  3138. 9.  The    Interface Data Structure
  3139.  
  3140.     An OSPF interface is the connection    between    a router and a network.
  3141.     We assume a    single OSPF interface to each attached network/subnet,
  3142.     although supporting    multiple interfaces on a single    network    is
  3143.     considered in Appendix F. Each interface structure has at most one
  3144.     IP interface address.
  3145.  
  3146.  
  3147.  
  3148.  
  3149.  
  3150. Moy                Standards Track               [Page 63]
  3151.  
  3152. RFC 2328             OSPF Version 2              April 1998
  3153.  
  3154.  
  3155.     An OSPF interface can be considered    to belong to the area that
  3156.     contains the attached network.  All    routing    protocol packets
  3157.     originated by the router over this interface are labelled with the
  3158.     interface's    Area ID.  One or more router adjacencies may develop
  3159.     over an interface.    A router's LSAs    reflect    the state of its
  3160.     interfaces and their associated adjacencies.
  3161.  
  3162.     The    following data items are associated with an interface.    Note
  3163.     that a number of these items are actually configuration for    the
  3164.     attached network; such items must be the same for all routers
  3165.     connected to the network.
  3166.  
  3167.     Type
  3168.     The OSPF interface type    is either point-to-point, broadcast,
  3169.     NBMA, Point-to-MultiPoint or virtual link.
  3170.  
  3171.     State
  3172.     The functional level of    an interface.  State determines    whether
  3173.     or not full adjacencies    are allowed to form over the interface.
  3174.     State is also reflected    in the router's    LSAs.
  3175.  
  3176.     IP interface address
  3177.     The IP address associated with the interface.  This appears as
  3178.     the IP source address in all routing protocol packets originated
  3179.     over this interface.  Interfaces to unnumbered point-to-point
  3180.     networks do not    have an    associated IP address.
  3181.  
  3182.     IP interface mask
  3183.     Also referred to as the    subnet mask, this indicates the    portion
  3184.     of the IP interface address that identifies the    attached
  3185.     network.  Masking the IP interface address with    the IP interface
  3186.     mask yields the    IP network number of the attached network.  On
  3187.     point-to-point networks    and virtual links, the IP interface mask
  3188.     is not defined.    On these networks, the link itself is not
  3189.     assigned an IP network number, and so the addresses of each side
  3190.     of the link are    assigned independently,    if they    are assigned at
  3191.     all.
  3192.  
  3193.     Area ID
  3194.     The Area ID of the area    to which the attached network belongs.
  3195.     All routing protocol packets originating from the interface are
  3196.     labelled with this Area    ID.
  3197.  
  3198.  
  3199.  
  3200. Moy                Standards Track               [Page 64]
  3201.  
  3202. RFC 2328             OSPF Version 2              April 1998
  3203.  
  3204.  
  3205.     HelloInterval
  3206.     The length of time, in seconds,    between    the Hello packets that
  3207.     the router sends on the    interface.  Advertised in Hello    packets
  3208.     sent out this interface.
  3209.  
  3210.     RouterDeadInterval
  3211.     The number of seconds before the router's neighbors will declare
  3212.     it down, when they stop    hearing    the router's Hello Packets.
  3213.     Advertised in Hello packets sent out this interface.
  3214.  
  3215.     InfTransDelay
  3216.     The estimated number of    seconds    it takes to transmit a Link
  3217.     State Update Packet over this interface.  LSAs contained in the
  3218.     Link State Update packet will have their age incremented by this
  3219.     amount before transmission.  This value    should take into account
  3220.     transmission and propagation delays; it    must be    greater    than
  3221.     zero.
  3222.  
  3223.     Router Priority
  3224.     An 8-bit unsigned integer.  When two routers attached to a
  3225.     network    both attempt to    become Designated Router, the one with
  3226.     the highest Router Priority takes precedence.  A router    whose
  3227.     Router Priority    is set to 0 is ineligible to become Designated
  3228.     Router on the attached network.     Advertised in Hello packets
  3229.     sent out this interface.
  3230.  
  3231.     Hello Timer
  3232.     An interval timer that causes the interface to send a Hello
  3233.     packet.     This timer fires every    HelloInterval seconds.    Note
  3234.     that on    non-broadcast networks a separate Hello    packet is sent
  3235.     to each    qualified neighbor.
  3236.  
  3237.     Wait Timer
  3238.     A single shot timer that causes    the interface to exit the
  3239.     Waiting    state, and as a    consequence select a Designated    Router
  3240.     on the network.     The length of the timer is RouterDeadInterval
  3241.     seconds.
  3242.  
  3243.     List of neighboring    routers
  3244.     The other routers attached to this network.  This list is formed
  3245.     by the Hello Protocol.    Adjacencies will be formed to some of
  3246.  
  3247.  
  3248.  
  3249.  
  3250. Moy                Standards Track               [Page 65]
  3251.  
  3252. RFC 2328             OSPF Version 2              April 1998
  3253.  
  3254.  
  3255.     these neighbors.  The set of adjacent neighbors    can be
  3256.     determined by an examination of    all of the neighbors' states.
  3257.  
  3258.     Designated Router
  3259.     The Designated Router selected for the attached    network.  The
  3260.     Designated Router is selected on all broadcast and NBMA    networks
  3261.     by the Hello Protocol.    Two pieces of identification are kept
  3262.     for the    Designated Router: its Router ID and its IP interface
  3263.     address    on the network.     The Designated    Router advertises link
  3264.     state for the network; this network-LSA    is labelled with the
  3265.     Designated Router's IP address.     The Designated    Router is
  3266.     initialized to 0.0.0.0,    which indicates    the lack of a Designated
  3267.     Router.
  3268.  
  3269.     Backup Designated Router
  3270.     The Backup Designated Router is    also selected on all broadcast
  3271.     and NBMA networks by the Hello Protocol.  All routers on the
  3272.     attached network become    adjacent to both the Designated    Router
  3273.     and the    Backup Designated Router.  The Backup Designated Router
  3274.     becomes    Designated Router when the current Designated Router
  3275.     fails.    The Backup Designated Router is    initialized to 0.0.0.0,
  3276.     indicating the lack of a Backup    Designated Router.
  3277.  
  3278.     Interface output cost(s)
  3279.     The cost of sending a data packet on the interface, expressed in
  3280.     the link state metric.    This is    advertised as the link cost for
  3281.     this interface in the router-LSA. The cost of an interface must
  3282.     be greater than    zero.
  3283.  
  3284.     RxmtInterval
  3285.     The number of seconds between LSA retransmissions, for
  3286.     adjacencies belonging to this interface.  Also used when
  3287.     retransmitting Database    Description and    Link State Request
  3288.     Packets.
  3289.  
  3290.     AuType
  3291.     The type of authentication used    on the attached    network/subnet.
  3292.     Authentication types are defined in Appendix D.     All OSPF packet
  3293.     exchanges are authenticated.  Different    authentication schemes
  3294.     may be used on different networks/subnets.
  3295.  
  3296.  
  3297.  
  3298.  
  3299.  
  3300. Moy                Standards Track               [Page 66]
  3301.  
  3302. RFC 2328             OSPF Version 2              April 1998
  3303.  
  3304.  
  3305.     Authentication key
  3306.     This configured    data allows the    authentication procedure to
  3307.     generate and/or    verify OSPF protocol packets.  The
  3308.     Authentication key can be configured on    a per-interface    basis.
  3309.     For example, if    the AuType indicates simple password, the
  3310.     Authentication key would be a 64-bit clear password which is
  3311.     inserted into the OSPF packet header. If instead Autype
  3312.     indicates Cryptographic    authentication,    then the Authentication
  3313.     key is a shared    secret which enables the generation/verification
  3314.     of message digests which are appended to the OSPF protocol
  3315.     packets. When Cryptographic authentication is used, multiple
  3316.     simultaneous keys are supported    in order to achieve smooth key
  3317.     transition (see    Section    D.3).
  3318.  
  3319.  
  3320.     9.1.  Interface states
  3321.  
  3322.     The various states that    router interfaces may attain is
  3323.     documented in this section.  The states    are listed in order of
  3324.     progressing functionality.  For    example, the inoperative state
  3325.     is listed first, followed by a list of intermediate states
  3326.     before the final, fully    functional state is achieved.  The
  3327.     specification makes use    of this    ordering by sometimes making
  3328.     references such    as "those interfaces in    state greater than X".
  3329.     Figure 11 shows    the graph of interface state changes.  The arcs
  3330.     of the graph are labelled with the event causing the state
  3331.     change.     These events are documented in    Section    9.2.  The
  3332.     interface state    machine    is described in    more detail in Section
  3333.     9.3.
  3334.  
  3335.  
  3336.     Down
  3337.         This is the    initial    interface state.  In this state, the
  3338.         lower-level    protocols have indicated that the interface is
  3339.         unusable.  No protocol traffic at all will be sent or
  3340.         received on    such a interface.  In this state, interface
  3341.         parameters should be set to    their initial values.  All
  3342.         interface timers should be disabled, and there should be no
  3343.         adjacencies    associated with    the interface.
  3344.  
  3345.     Loopback
  3346.         In this state, the router's    interface to the network is
  3347.  
  3348.  
  3349.  
  3350. Moy                Standards Track               [Page 67]
  3351.  
  3352. RFC 2328             OSPF Version 2              April 1998
  3353.  
  3354.  
  3355.  
  3356.                   +----+   UnloopInd   +--------+
  3357.                   |Down|<--------------|Loopback|
  3358.                   +----+           +--------+
  3359.                      |
  3360.                      |InterfaceUp
  3361.               +-------+  |             +--------------+
  3362.               |Waiting|<-+-------------->|Point-to-point|
  3363.               +-------+             +--------------+
  3364.                   |
  3365.              WaitTimer|BackupSeen
  3366.                   |
  3367.                   |
  3368.                   |      NeighborChange
  3369.       +------+         +-+<---------------- +-------+
  3370.       |Backup|<----------|?|----------------->|DROther|
  3371.       +------+---------->+-+<-----+          +-------+
  3372.             Neighbor  |          |
  3373.             Change    |          |Neighbor
  3374.                   |          |Change
  3375.                   |        +--+
  3376.                   +---->|DR|
  3377.                     +--+
  3378.  
  3379.               Figure 11: Interface State changes
  3380.  
  3381.          In addition to    the state transitions pictured,
  3382.          Event InterfaceDown always forces Down    State, and
  3383.          Event LoopInd always forces Loopback State
  3384.  
  3385.  
  3386.         looped back.  The interface    may be looped back in hardware
  3387.         or software.  The interface    will be    unavailable for    regular
  3388.         data traffic.  However, it may still be desirable to gain
  3389.         information    on the quality of this interface, either through
  3390.         sending ICMP pings to the interface    or through something
  3391.         like a bit error test.  For    this reason, IP    packets    may
  3392.         still be addressed to an interface in Loopback state.  To
  3393.  
  3394.  
  3395.  
  3396.  
  3397.  
  3398.  
  3399.  
  3400. Moy                Standards Track               [Page 68]
  3401.  
  3402. RFC 2328             OSPF Version 2              April 1998
  3403.  
  3404.  
  3405.         facilitate this, such interfaces are advertised in router-
  3406.         LSAs as single host    routes,    whose destination is the IP
  3407.         interface address.[4]
  3408.  
  3409.     Waiting
  3410.         In this state, the router is trying    to determine the
  3411.         identity of    the (Backup) Designated    Router for the network.
  3412.         To do this,    the router monitors the    Hello Packets it
  3413.         receives.  The router is not allowed to elect a Backup
  3414.         Designated Router nor a Designated Router until it
  3415.         transitions    out of Waiting state.  This prevents unnecessary
  3416.         changes of (Backup)    Designated Router.
  3417.  
  3418.     Point-to-point
  3419.         In this state, the interface is operational, and connects
  3420.         either to a    physical point-to-point    network    or to a    virtual
  3421.         link.  Upon    entering this state, the router    attempts to form
  3422.         an adjacency with the neighboring router.  Hello Packets are
  3423.         sent to the    neighbor every HelloInterval seconds.
  3424.  
  3425.     DR Other
  3426.         The    interface is to    a broadcast or NBMA network on which
  3427.         another router has been selected to    be the Designated
  3428.         Router.  In    this state, the    router itself has not been
  3429.         selected Backup Designated Router either.  The router forms
  3430.         adjacencies    to both    the Designated Router and the Backup
  3431.         Designated Router (if they exist).
  3432.  
  3433.     Backup
  3434.         In this state, the router itself is    the Backup Designated
  3435.         Router on the attached network.  It    will be    promoted to
  3436.         Designated Router when the present Designated Router fails.
  3437.         The    router establishes adjacencies to all other routers
  3438.         attached to    the network.  The Backup Designated Router
  3439.         performs slightly different    functions during the Flooding
  3440.         Procedure, as compared to the Designated Router (see Section
  3441.         13.3).  See    Section    7.4 for    more details on    the functions
  3442.         performed by the Backup Designated Router.
  3443.  
  3444.     DR  In this state, this    router itself is the Designated    Router
  3445.         on the attached network.  Adjacencies are established to all
  3446.         other routers attached to the network.  The    router must also
  3447.  
  3448.  
  3449.  
  3450. Moy                Standards Track               [Page 69]
  3451.  
  3452. RFC 2328             OSPF Version 2              April 1998
  3453.  
  3454.  
  3455.         originate a    network-LSA for    the network node.  The network-
  3456.         LSA    will contain links to all routers (including the
  3457.         Designated Router itself) attached to the network.    See
  3458.         Section 7.3    for more details on the    functions performed by
  3459.         the    Designated Router.
  3460.  
  3461.  
  3462.     9.2.  Events causing interface state changes
  3463.  
  3464.     State changes can be effected by a number of events.  These
  3465.     events are pictured as the labelled arcs in Figure 11.    The
  3466.     label definitions are listed below.  For a detailed explanation
  3467.     of the effect of these events on OSPF protocol operation,
  3468.     consult    Section    9.3.
  3469.  
  3470.  
  3471.     InterfaceUp
  3472.         Lower-level    protocols have indicated that the network
  3473.         interface is operational.  This enables the    interface to
  3474.         transition out of Down state.  On virtual links, the
  3475.         interface operational indication is    actually a result of the
  3476.         shortest path calculation (see Section 16.7).
  3477.  
  3478.     WaitTimer
  3479.         The    Wait Timer has fired, indicating the end of the    waiting
  3480.         period that    is required before electing a (Backup)
  3481.         Designated Router.
  3482.  
  3483.     BackupSeen
  3484.         The    router has detected the    existence or non-existence of a
  3485.         Backup Designated Router for the network.  This is done in
  3486.         one    of two ways.  First, an    Hello Packet may be received
  3487.         from a neighbor claiming to    be itself the Backup Designated
  3488.         Router.  Alternatively, an Hello Packet may    be received from
  3489.         a neighbor claiming    to be itself the Designated Router, and
  3490.         indicating that there is no    Backup Designated Router.  In
  3491.         either case    there must be bidirectional communication with
  3492.         the    neighbor, i.e.,    the router must    also appear in the
  3493.         neighbor's Hello Packet.  This event signals an end    to the
  3494.         Waiting state.
  3495.  
  3496.  
  3497.  
  3498.  
  3499.  
  3500. Moy                Standards Track               [Page 70]
  3501.  
  3502. RFC 2328             OSPF Version 2              April 1998
  3503.  
  3504.  
  3505.     NeighborChange
  3506.         There has been a change in the set of bidirectional
  3507.         neighbors associated with the interface.  The (Backup)
  3508.         Designated Router needs to be recalculated.     The following
  3509.         neighbor changes lead to the NeighborChange    event.    For an
  3510.         explanation    of neighbor states, see    Section    10.1.
  3511.  
  3512.         o    Bidirectional communication has    been established to a
  3513.         neighbor.  In other words, the state of    the neighbor has
  3514.         transitioned to    2-Way or higher.
  3515.  
  3516.         o    There is no longer bidirectional communication with a
  3517.         neighbor.  In other words, the state of    the neighbor has
  3518.         transitioned to    Init or    lower.
  3519.  
  3520.         o    One of the bidirectional neighbors is newly declaring
  3521.         itself as either Designated Router or Backup Designated
  3522.         Router.     This is detected through examination of that
  3523.         neighbor's Hello Packets.
  3524.  
  3525.         o    One of the bidirectional neighbors is no longer
  3526.         declaring itself as Designated Router, or is no    longer
  3527.         declaring itself as Backup Designated Router.  This is
  3528.         again detected through examination of that neighbor's
  3529.         Hello Packets.
  3530.  
  3531.         o    The advertised Router Priority for a bidirectional
  3532.         neighbor has changed.  This is again detected through
  3533.         examination of that neighbor's Hello Packets.
  3534.  
  3535.     LoopInd
  3536.         An indication has been received that the interface is now
  3537.         looped back    to itself.  This indication can    be received
  3538.         either from    network    management or from the lower level
  3539.         protocols.
  3540.  
  3541.     UnloopInd
  3542.         An indication has been received that the interface is no
  3543.         longer looped back.     As with the LoopInd event, this
  3544.  
  3545.  
  3546.  
  3547.  
  3548.  
  3549.  
  3550. Moy                Standards Track               [Page 71]
  3551.  
  3552. RFC 2328             OSPF Version 2              April 1998
  3553.  
  3554.  
  3555.         indication can be received either from network management or
  3556.         from the lower level protocols.
  3557.  
  3558.     InterfaceDown
  3559.         Lower-level    protocols indicate that    this interface is no
  3560.         longer functional.    No matter what the current interface
  3561.         state is, the new interface    state will be Down.
  3562.  
  3563.     9.3.  The Interface    state machine
  3564.  
  3565.     A detailed description of the interface    state changes follows.
  3566.     Each state change is invoked by    an event (Section 9.2).     This
  3567.     event may produce different effects, depending on the current
  3568.     state of the interface.     For this reason, the state machine
  3569.     below is organized by current interface    state and received
  3570.     event.    Each entry in the state    machine    describes the resulting
  3571.     new interface state and    the required set of additional actions.
  3572.  
  3573.     When an    interface's state changes, it may be necessary to
  3574.     originate a new    router-LSA.  See Section 12.4 for more details.
  3575.  
  3576.     Some of    the required actions below involve generating events for
  3577.     the neighbor state machine.  For example, when an interface
  3578.     becomes    inoperative, all neighbor connections associated with
  3579.     the interface must be destroyed.  For more information on the
  3580.     neighbor state machine,    see Section 10.3.
  3581.  
  3582.  
  3583.      State(s):  Down
  3584.  
  3585.         Event:  InterfaceUp
  3586.  
  3587.     New state:  Depends upon action    routine
  3588.  
  3589.        Action:  Start the interval Hello Timer, enabling the
  3590.             periodic sending of    Hello packets out the interface.
  3591.             If the attached network is a physical point-to-point
  3592.             network, Point-to-MultiPoint network or virtual
  3593.             link, the interface    state transitions to Point-to-
  3594.             Point.  Else, if the router    is not eligible    to
  3595.             become Designated Router the interface state
  3596.             transitions    to DR Other.
  3597.  
  3598.  
  3599.  
  3600. Moy                Standards Track               [Page 72]
  3601.  
  3602. RFC 2328             OSPF Version 2              April 1998
  3603.  
  3604.  
  3605.             Otherwise, the attached network is a broadcast or
  3606.             NBMA network and the router    is eligible to become
  3607.             Designated Router.    In this    case, in an attempt to
  3608.             discover the attached network's Designated Router
  3609.             the    interface state    is set to Waiting and the single
  3610.             shot Wait Timer is started.     Additionally, if the
  3611.             network is an NBMA network examine the configured
  3612.             list of neighbors for this interface and generate
  3613.             the    neighbor event Start for each neighbor that is
  3614.             also eligible to become Designated Router.
  3615.  
  3616.  
  3617.      State(s):  Waiting
  3618.  
  3619.         Event:  BackupSeen
  3620.  
  3621.     New state:  Depends upon action    routine.
  3622.  
  3623.        Action:  Calculate the attached network's Backup Designated
  3624.             Router and Designated Router, as shown in Section
  3625.             9.4.  As a result of this calculation, the new state
  3626.             of the interface will be either DR Other, Backup or
  3627.             DR.
  3628.  
  3629.  
  3630.      State(s):  Waiting
  3631.  
  3632.         Event:  WaitTimer
  3633.  
  3634.     New state:  Depends upon action    routine.
  3635.  
  3636.        Action:  Calculate the attached network's Backup Designated
  3637.             Router and Designated Router, as shown in Section
  3638.             9.4.  As a result of this calculation, the new state
  3639.             of the interface will be either DR Other, Backup or
  3640.             DR.
  3641.  
  3642.  
  3643.      State(s):  DR Other, Backup or    DR
  3644.  
  3645.         Event:  NeighborChange
  3646.  
  3647.  
  3648.  
  3649.  
  3650. Moy                Standards Track               [Page 73]
  3651.  
  3652. RFC 2328             OSPF Version 2              April 1998
  3653.  
  3654.  
  3655.     New state:  Depends upon action    routine.
  3656.  
  3657.        Action:  Recalculate    the attached network's Backup Designated
  3658.             Router and Designated Router, as shown in Section
  3659.             9.4.  As a result of this calculation, the new state
  3660.             of the interface will be either DR Other, Backup or
  3661.             DR.
  3662.  
  3663.  
  3664.      State(s):  Any    State
  3665.  
  3666.         Event:  InterfaceDown
  3667.  
  3668.     New state:  Down
  3669.  
  3670.        Action:  All    interface variables are    reset, and interface
  3671.             timers disabled.  Also, all    neighbor connections
  3672.             associated with the    interface are destroyed.  This
  3673.             is done by generating the event KillNbr on all
  3674.             associated neighbors (see Section 10.2).
  3675.  
  3676.  
  3677.      State(s):  Any    State
  3678.  
  3679.         Event:  LoopInd
  3680.  
  3681.     New state:  Loopback
  3682.  
  3683.        Action:  Since this interface is no longer connected    to the
  3684.             attached network the actions associated with the
  3685.             above InterfaceDown    event are executed.
  3686.  
  3687.  
  3688.      State(s):  Loopback
  3689.  
  3690.         Event:  UnloopInd
  3691.  
  3692.     New state:  Down
  3693.  
  3694.        Action:  No actions are necessary.  For example, the
  3695.             interface variables    have already been reset    upon
  3696.             entering the Loopback state.  Note that reception of
  3697.  
  3698.  
  3699.  
  3700. Moy                Standards Track               [Page 74]
  3701.  
  3702. RFC 2328             OSPF Version 2              April 1998
  3703.  
  3704.  
  3705.             an InterfaceUp event is necessary before the
  3706.             interface again becomes fully functional.
  3707.  
  3708.  
  3709.     9.4.  Electing the Designated Router
  3710.  
  3711.     This section describes the algorithm used for calculating a
  3712.     network's Designated Router and    Backup Designated Router.  This
  3713.     algorithm is invoked by    the Interface state machine.  The
  3714.     initial    time a router runs the election    algorithm for a    network,
  3715.     the network's Designated Router    and Backup Designated Router are
  3716.     initialized to 0.0.0.0.     This indicates    the lack of both a
  3717.     Designated Router and a    Backup Designated Router.
  3718.  
  3719.     The Designated Router election algorithm proceeds as follows:
  3720.     Call the router    doing the calculation Router X.     The list of
  3721.     neighbors attached to the network and having established
  3722.     bidirectional communication with Router    X is examined.    This
  3723.     list is    precisely the collection of Router X's neighbors (on
  3724.     this network) whose state is greater than or equal to 2-Way (see
  3725.     Section    10.1).    Router X itself    is also    considered to be on the
  3726.     list.  Discard all routers from    the list that are ineligible to
  3727.     become Designated Router.  (Routers having Router Priority of 0
  3728.     are ineligible to become Designated Router.)  The following
  3729.     steps are then executed, considering only those    routers    that
  3730.     remain on the list:
  3731.  
  3732.     (1) Note the current values for    the network's Designated Router
  3733.         and    Backup Designated Router.  This    is used    later for
  3734.         comparison purposes.
  3735.  
  3736.     (2) Calculate the new Backup Designated    Router for the network
  3737.         as follows.     Only those routers on the list    that have not
  3738.         declared themselves    to be Designated Router    are eligible to
  3739.         become Backup Designated Router.  If one or    more of    these
  3740.         routers have declared themselves Backup Designated Router
  3741.         (i.e., they    are currently listing themselves as Backup
  3742.         Designated Router, but not as Designated Router, in    their
  3743.         Hello Packets) the one having highest Router Priority is
  3744.         declared to    be Backup Designated Router.  In case of a tie,
  3745.         the    one having the highest Router ID is chosen.  If    no
  3746.         routers have declared themselves Backup Designated Router,
  3747.  
  3748.  
  3749.  
  3750. Moy                Standards Track               [Page 75]
  3751.  
  3752. RFC 2328             OSPF Version 2              April 1998
  3753.  
  3754.  
  3755.         choose the router having highest Router Priority, (again
  3756.         excluding those routers who    have declared themselves
  3757.         Designated Router),    and again use the Router ID to break
  3758.         ties.
  3759.  
  3760.     (3) Calculate the new Designated Router    for the    network    as
  3761.         follows.  If one or    more of    the routers have declared
  3762.         themselves Designated Router (i.e.,    they are currently
  3763.         listing themselves as Designated Router in their Hello
  3764.         Packets) the one having highest Router Priority is declared
  3765.         to be Designated Router.  In case of a tie,    the one    having
  3766.         the    highest    Router ID is chosen.  If no routers have
  3767.         declared themselves    Designated Router, assign the Designated
  3768.         Router to be the same as the newly elected Backup Designated
  3769.         Router.
  3770.  
  3771.     (4) If Router X    is now newly the Designated Router or newly the
  3772.         Backup Designated Router, or is now    no longer the Designated
  3773.         Router or no longer    the Backup Designated Router, repeat
  3774.         steps 2 and    3, and then proceed to step 5.    For example, if
  3775.         Router X is    now the    Designated Router, when    step 2 is
  3776.         repeated X will no longer be eligible for Backup Designated
  3777.         Router election.  Among other things, this will ensure that
  3778.         no router will declare itself both Backup Designated Router
  3779.         and    Designated Router.[5]
  3780.  
  3781.     (5) As a result    of these calculations, the router itself may now
  3782.         be Designated Router or Backup Designated Router.  See
  3783.         Sections 7.3 and 7.4 for the additional duties this    would
  3784.         entail.  The router's interface state should be set
  3785.         accordingly.  If the router    itself is now Designated Router,
  3786.         the    new interface state is DR.  If the router itself is now
  3787.         Backup Designated Router, the new interface    state is Backup.
  3788.         Otherwise, the new interface state is DR Other.
  3789.  
  3790.     (6) If the attached network is an NBMA network,    and the    router
  3791.         itself has just become either Designated Router or Backup
  3792.         Designated Router, it must start sending Hello Packets to
  3793.         those neighbors that are not eligible to become Designated
  3794.         Router (see    Section    9.5.1).     This is done by invoking the
  3795.         neighbor event Start for each neighbor having a Router
  3796.         Priority of    0.
  3797.  
  3798.  
  3799.  
  3800. Moy                Standards Track               [Page 76]
  3801.  
  3802. RFC 2328             OSPF Version 2              April 1998
  3803.  
  3804.  
  3805.     (7) If the above calculations have caused the identity of either
  3806.         the    Designated Router or Backup Designated Router to change,
  3807.         the    set of adjacencies associated with this    interface will
  3808.         need to be modified.  Some adjacencies may need to be
  3809.         formed, and    others may need    to be broken.  To accomplish
  3810.         this, invoke the event AdjOK?  on all neighbors whose state
  3811.         is at least    2-Way.    This will cause    their eligibility for
  3812.         adjacency to be reexamined (see Sections 10.3 and 10.4).
  3813.  
  3814.  
  3815.     The reason behind the election algorithm's complexity is the
  3816.     desire for an orderly transition from Backup Designated    Router
  3817.     to Designated Router, when the current Designated Router fails.
  3818.     This orderly transition    is ensured through the introduction of
  3819.     hysteresis: no new Backup Designated Router can    be chosen until
  3820.     the old    Backup accepts its new Designated Router
  3821.     responsibilities.
  3822.  
  3823.     The above procedure may    elect the same router to be both
  3824.     Designated Router and Backup Designated    Router,    although that
  3825.     router will never be the calculating router (Router X) itself.
  3826.     The elected Designated Router may not be the router having the
  3827.     highest    Router Priority, nor will the Backup Designated    Router
  3828.     necessarily have the second highest Router Priority.  If Router
  3829.     X is not itself    eligible to become Designated Router, it is
  3830.     possible that neither a    Backup Designated Router nor a
  3831.     Designated Router will be selected in the above    procedure.  Note
  3832.     also that if Router X is the only attached router that is
  3833.     eligible to become Designated Router, it will select itself as
  3834.     Designated Router and there will be no Backup Designated Router
  3835.     for the    network.
  3836.  
  3837.  
  3838.     9.5.  Sending Hello    packets
  3839.  
  3840.     Hello packets are sent out each    functioning router interface.
  3841.     They are used to discover and maintain neighbor
  3842.     relationships.[6] On broadcast and NBMA    networks, Hello    Packets
  3843.     are also used to elect the Designated Router and Backup
  3844.     Designated Router.
  3845.  
  3846.  
  3847.  
  3848.  
  3849.  
  3850. Moy                Standards Track               [Page 77]
  3851.  
  3852. RFC 2328             OSPF Version 2              April 1998
  3853.  
  3854.  
  3855.     The format of an Hello packet is detailed in Section A.3.2.  The
  3856.     Hello Packet contains the router's Router Priority (used in
  3857.     choosing the Designated    Router), and the interval between Hello
  3858.     Packets    sent out the interface (HelloInterval).     The Hello
  3859.     Packet also indicates how often    a neighbor must    be heard from to
  3860.     remain active (RouterDeadInterval).  Both HelloInterval    and
  3861.     RouterDeadInterval must    be the same for    all routers attached to
  3862.     a common network.  The Hello packet also contains the IP address
  3863.     mask of    the attached network (Network Mask).  On unnumbered
  3864.     point-to-point networks    and on virtual links this field    should
  3865.     be set to 0.0.0.0.
  3866.  
  3867.     The Hello packet's Options field describes the router's    optional
  3868.     OSPF capabilities.  One    optional capability is defined in this
  3869.     specification (see Sections 4.5    and A.2).  The E-bit of    the
  3870.     Options    field should be    set if and only    if the attached    area is
  3871.     capable    of processing AS-external-LSAs (i.e., it is not    a stub
  3872.     area).    If the E-bit is    set incorrectly    the neighboring    routers
  3873.     will refuse to accept the Hello    Packet (see Section 10.5).
  3874.     Unrecognized bits in the Hello Packet's    Options    field should be
  3875.     set to zero.
  3876.  
  3877.     In order to ensure two-way communication between adjacent
  3878.     routers, the Hello packet contains the list of all routers on
  3879.     the network from which Hello Packets have been seen recently.
  3880.     The Hello packet also contains the router's current choice for
  3881.     Designated Router and Backup Designated    Router.     A value of
  3882.     0.0.0.0    in these fields    means that one has not yet been
  3883.     selected.
  3884.  
  3885.     On broadcast networks and physical point-to-point networks,
  3886.     Hello packets are sent every HelloInterval seconds to the IP
  3887.     multicast address AllSPFRouters.  On virtual links, Hello
  3888.     packets    are sent as unicasts (addressed    directly to the    other
  3889.     end of the virtual link) every HelloInterval seconds. On Point-
  3890.     to-MultiPoint networks,    separate Hello packets are sent    to each
  3891.     attached neighbor every    HelloInterval seconds. Sending of Hello
  3892.     packets    on NBMA    networks is covered in the next    section.
  3893.  
  3894.  
  3895.  
  3896.  
  3897.  
  3898.  
  3899.  
  3900. Moy                Standards Track               [Page 78]
  3901.  
  3902. RFC 2328             OSPF Version 2              April 1998
  3903.  
  3904.  
  3905.     9.5.1.    Sending    Hello packets on NBMA networks
  3906.  
  3907.         Static configuration information may be necessary in order
  3908.         for    the Hello Protocol to function on non-broadcast    networks
  3909.         (see Sections C.5 and C.6).     On NBMA networks, every
  3910.         attached router which is eligible to become    Designated
  3911.         Router becomes aware of all    of its neighbors on the    network
  3912.         (either through configuration or by    some unspecified
  3913.         mechanism).     Each neighbor is labelled with    the neighbor's
  3914.         Designated Router eligibility.
  3915.  
  3916.         The    interface state    must be    at least Waiting for any Hello
  3917.         Packets to be sent out the NBMA interface.    Hello Packets
  3918.         are    then sent directly (as unicasts) to some subset    of a
  3919.         router's neighbors.     Sometimes an Hello Packet is sent
  3920.         periodically on a timer; at    other times it is sent as a
  3921.         response to    a received Hello Packet.  A router's hello-
  3922.         sending behavior varies depending on whether the router
  3923.         itself is eligible to become Designated Router.
  3924.  
  3925.         If the router is eligible to become    Designated Router, it
  3926.         must periodically send Hello Packets to all    neighbors that
  3927.         are    also eligible.    In addition, if    the router is itself the
  3928.         Designated Router or Backup    Designated Router, it must also
  3929.         send periodic Hello    Packets    to all other neighbors.     This
  3930.         means that any two eligible    routers    are always exchanging
  3931.         Hello Packets, which is necessary for the correct operation
  3932.         of the Designated Router election algorithm.  To minimize
  3933.         the    number of Hello    Packets    sent, the number of eligible
  3934.         routers on an NBMA network should be kept small.
  3935.  
  3936.         If the router is not eligible to become Designated Router,
  3937.         it must periodically send Hello Packets to both the
  3938.         Designated Router and the Backup Designated    Router (if they
  3939.         exist).  It    must also send an Hello    Packet in reply    to an
  3940.         Hello Packet received from any eligible neighbor (other than
  3941.         the    current    Designated Router and Backup Designated    Router).
  3942.         This is needed to establish    an initial bidirectional
  3943.         relationship with any potential Designated Router.
  3944.  
  3945.         When sending Hello packets periodically to any neighbor, the
  3946.         interval between Hello Packets is determined by the
  3947.  
  3948.  
  3949.  
  3950. Moy                Standards Track               [Page 79]
  3951.  
  3952. RFC 2328             OSPF Version 2              April 1998
  3953.  
  3954.  
  3955.         neighbor's state.  If the neighbor is in state Down, Hello
  3956.         Packets are    sent every PollInterval    seconds.  Otherwise,
  3957.         Hello Packets are sent every HelloInterval seconds.
  3958.  
  3959.  
  3960. 10.  The Neighbor Data Structure
  3961.  
  3962.     An OSPF router converses with its neighboring routers.  Each
  3963.     separate conversation is described by a "neighbor data structure".
  3964.     Each conversation is bound to a particular OSPF router interface,
  3965.     and    is identified either by    the neighboring    router's OSPF Router ID
  3966.     or by its Neighbor IP address (see below).    Thus if    the OSPF router
  3967.     and    another    router have multiple attached networks in common,
  3968.     multiple conversations ensue, each described by a unique neighbor
  3969.     data structure.  Each separate conversation    is loosely referred to
  3970.     in the text    as being a separate "neighbor".
  3971.  
  3972.     The    neighbor data structure    contains all information pertinent to
  3973.     the    forming    or formed adjacency between the    two neighbors.
  3974.     (However, remember that not    all neighbors become adjacent.)     An
  3975.     adjacency can be viewed as a highly    developed conversation between
  3976.     two    routers.
  3977.  
  3978.  
  3979.     State
  3980.     The functional level of    the neighbor conversation.  This is
  3981.     described in more detail in Section 10.1.
  3982.  
  3983.     Inactivity Timer
  3984.     A single shot timer whose firing indicates that    no Hello Packet
  3985.     has been seen from this    neighbor recently.  The    length of the
  3986.     timer is RouterDeadInterval seconds.
  3987.  
  3988.     Master/Slave
  3989.     When the two neighbors are exchanging databases, they form a
  3990.     master/slave relationship.  The    master sends the first Database
  3991.     Description Packet, and    is the only part that is allowed to
  3992.     retransmit.  The slave can only    respond    to the master's    Database
  3993.     Description Packets.  The master/slave relationship is
  3994.     negotiated in state ExStart.
  3995.  
  3996.  
  3997.  
  3998.  
  3999.  
  4000. Moy                Standards Track               [Page 80]
  4001.  
  4002. RFC 2328             OSPF Version 2              April 1998
  4003.  
  4004.  
  4005.     DD Sequence    Number
  4006.     The DD Sequence    number of the Database Description packet that
  4007.     is currently being sent    to the neighbor.
  4008.  
  4009.     Last received Database Description packet
  4010.     The initialize(I), more    (M) and    master(MS) bits, Options field,
  4011.     and DD sequence    number contained in the    last Database
  4012.     Description packet received from the neighbor. Used to determine
  4013.     whether    the next Database Description packet received from the
  4014.     neighbor is a duplicate.
  4015.  
  4016.     Neighbor ID
  4017.     The OSPF Router    ID of the neighboring router.  The Neighbor ID
  4018.     is learned when    Hello packets are received from    the neighbor, or
  4019.     is configured if this is a virtual adjacency (see Section C.4).
  4020.  
  4021.     Neighbor Priority
  4022.     The Router Priority of the neighboring router.    Contained in the
  4023.     neighbor's Hello packets, this item is used when selecting the
  4024.     Designated Router for the attached network.
  4025.  
  4026.     Neighbor IP    address
  4027.     The IP address of the neighboring router's interface to    the
  4028.     attached network.  Used    as the Destination IP address when
  4029.     protocol packets are sent as unicasts along this adjacency.
  4030.     Also used in router-LSAs as the    Link ID    for the    attached network
  4031.     if the neighboring router is selected to be Designated Router
  4032.     (see Section 12.4.1).  The Neighbor IP address is learned when
  4033.     Hello packets are received from    the neighbor.  For virtual
  4034.     links, the Neighbor IP address is learned during the routing
  4035.     table build process (see Section 15).
  4036.  
  4037.     Neighbor Options
  4038.     The optional OSPF capabilities supported by the    neighbor.
  4039.     Learned    during the Database Exchange process (see Section 10.6).
  4040.     The neighbor's optional    OSPF capabilities are also listed in its
  4041.     Hello packets.    This enables received Hello Packets to be
  4042.     rejected (i.e.,    neighbor relationships will not    even start to
  4043.     form) if there is a mismatch in    certain    crucial    OSPF
  4044.     capabilities (see Section 10.5).  The optional OSPF capabilities
  4045.     are documented in Section 4.5.
  4046.  
  4047.  
  4048.  
  4049.  
  4050. Moy                Standards Track               [Page 81]
  4051.  
  4052. RFC 2328             OSPF Version 2              April 1998
  4053.  
  4054.  
  4055.     Neighbor's Designated Router
  4056.     The neighbor's idea of the Designated Router.  If this is the
  4057.     neighbor itself, this is important in the local    calculation of
  4058.     the Designated Router.    Defined    only on    broadcast and NBMA
  4059.     networks.
  4060.  
  4061.     Neighbor's Backup Designated Router
  4062.     The neighbor's idea of the Backup Designated Router.  If this is
  4063.     the neighbor itself, this is important in the local calculation
  4064.     of the Backup Designated Router.  Defined only on broadcast and
  4065.     NBMA networks.
  4066.  
  4067.  
  4068.     The    next set of variables are lists    of LSAs.  These    lists describe
  4069.     subsets of the area    link-state database.  This memo    defines    five
  4070.     distinct types of LSAs, all    of which may be    present    in an area
  4071.     link-state database: router-LSAs, network-LSAs, and    Type 3 and 4
  4072.     summary-LSAs (all stored in    the area data structure), and AS-
  4073.     external-LSAs (stored in the global    data structure).
  4074.  
  4075.  
  4076.     Link state retransmission list
  4077.     The list of LSAs that have been    flooded    but not    acknowledged on
  4078.     this adjacency.     These will be retransmitted at    intervals until
  4079.     they are acknowledged, or until    the adjacency is destroyed.
  4080.  
  4081.     Database summary list
  4082.     The complete list of LSAs that make up the area    link-state
  4083.     database, at the moment    the neighbor goes into Database    Exchange
  4084.     state.    This list is sent to the neighbor in Database
  4085.     Description packets.
  4086.  
  4087.     Link state request list
  4088.     The list of LSAs that need to be received from this neighbor in
  4089.     order to synchronize the two neighbors'    link-state databases.
  4090.     This list is created as    Database Description packets are
  4091.     received, and is then sent to the neighbor in Link State Request
  4092.     packets.  The list is depleted as appropriate Link State Update
  4093.     packets    are received.
  4094.  
  4095.  
  4096.  
  4097.  
  4098.  
  4099.  
  4100. Moy                Standards Track               [Page 82]
  4101.  
  4102. RFC 2328             OSPF Version 2              April 1998
  4103.  
  4104.  
  4105.     10.1.  Neighbor states
  4106.  
  4107.     The state of a neighbor    (really, the state of a    conversation
  4108.     being held with    a neighboring router) is documented in the
  4109.     following sections.  The states    are listed in order of
  4110.     progressing functionality.  For    example, the inoperative state
  4111.     is listed first, followed by a list of intermediate states
  4112.     before the final, fully    functional state is achieved.  The
  4113.     specification makes use    of this    ordering by sometimes making
  4114.     references such    as "those neighbors/adjacencies    in state greater
  4115.     than X".  Figures 12 and 13 show the graph of neighbor state
  4116.     changes.  The arcs of the graphs are labelled with the event
  4117.     causing    the state change.  The neighbor    events are documented in
  4118.     Section    10.2.
  4119.  
  4120.     The graph in Figure 12 shows the state changes effected    by the
  4121.     Hello Protocol.     The Hello Protocol is responsible for neighbor
  4122.     acquisition and    maintenance, and for ensuring two way
  4123.     communication between neighbors.
  4124.  
  4125.     The graph in Figure 13 shows the forming of an adjacency.  Not
  4126.     every two neighboring routers become adjacent (see Section
  4127.     10.4).    The adjacency starts to    form when the neighbor is in
  4128.     state ExStart.    After the two routers discover their
  4129.     master/slave status, the state transitions to Exchange.     At this
  4130.     point the neighbor starts to be    used in    the flooding procedure,
  4131.     and the    two neighboring    routers    begin synchronizing their
  4132.     databases.  When this synchronization is finished, the neighbor
  4133.     is in state Full and we    say that the two routers are fully
  4134.     adjacent.  At this point the adjacency is listed in LSAs.
  4135.  
  4136.     For a more detailed description    of neighbor state changes,
  4137.     together with the additional actions involved in each change,
  4138.     see Section 10.3.
  4139.  
  4140.  
  4141.     Down
  4142.         This is the    initial    state of a neighbor conversation.  It
  4143.         indicates that there has been no recent information    received
  4144.         from the neighbor.    On NBMA    networks, Hello    packets    may
  4145.         still be sent to "Down" neighbors, although    at a reduced
  4146.         frequency (see Section 9.5.1).
  4147.  
  4148.  
  4149.  
  4150. Moy                Standards Track               [Page 83]
  4151.  
  4152. RFC 2328             OSPF Version 2              April 1998
  4153.  
  4154.  
  4155.  
  4156.                    +----+
  4157.                    |Down|
  4158.                    +----+
  4159.                      |\
  4160.                      | \Start
  4161.                      |    \      +-------+
  4162.                  Hello   |     +---->|Attempt|
  4163.                 Received |           +-------+
  4164.                      |           |
  4165.                  +----+<-+           |HelloReceived
  4166.                  |Init|<---------------+
  4167.                  +----+<--------+
  4168.                 |        |
  4169.                 |2-Way        |1-Way
  4170.                 |Received   |Received
  4171.                 |        |
  4172.           +-------+        |     +-----+
  4173.           |ExStart|<--------+------->|2-Way|
  4174.           +-------+             +-----+
  4175.  
  4176.           Figure 12: Neighbor state    changes    (Hello Protocol)
  4177.  
  4178.           In addition to the state transitions pictured,
  4179.           Event    KillNbr    always forces Down State,
  4180.           Event    InactivityTimer    always forces Down State,
  4181.           Event    LLDown always forces Down State
  4182.  
  4183.  
  4184.  
  4185.  
  4186.  
  4187.  
  4188.  
  4189.  
  4190.  
  4191.  
  4192.  
  4193.  
  4194.  
  4195.  
  4196.  
  4197.  
  4198.  
  4199.  
  4200. Moy                Standards Track               [Page 84]
  4201.  
  4202. RFC 2328             OSPF Version 2              April 1998
  4203.  
  4204.  
  4205.                   +-------+
  4206.                   |ExStart|
  4207.                   +-------+
  4208.                     |
  4209.              NegotiationDone|
  4210.                     +->+--------+
  4211.                        |Exchange|
  4212.                     +--+--------+
  4213.                     |
  4214.                 Exchange|
  4215.                   Done  |
  4216.             +----+        |       +-------+
  4217.             |Full|<---------+----->|Loading|
  4218.             +----+<-+           +-------+
  4219.                 |  LoadingDone     |
  4220.                 +------------------+
  4221.  
  4222.         Figure 13: Neighbor    state changes (Database    Exchange)
  4223.  
  4224.         In addition to the state transitions pictured,
  4225.         Event SeqNumberMismatch    forces ExStart state,
  4226.         Event BadLSReq forces ExStart state,
  4227.         Event 1-Way forces Init    state,
  4228.         Event KillNbr always forces Down State,
  4229.         Event InactivityTimer always forces Down State,
  4230.         Event LLDown always forces Down    State,
  4231.         Event AdjOK? leads to adjacency    forming/breaking
  4232.  
  4233.     Attempt
  4234.         This state is only valid for neighbors attached to NBMA
  4235.         networks.  It indicates that no recent information has been
  4236.         received from the neighbor,    but that a more    concerted effort
  4237.         should be made to contact the neighbor.  This is done by
  4238.         sending the    neighbor Hello packets at intervals of
  4239.         HelloInterval (see Section 9.5.1).
  4240.  
  4241.     Init
  4242.         In this state, an Hello packet has recently    been seen from
  4243.         the    neighbor.  However, bidirectional communication    has not
  4244.         yet    been established with the neighbor (i.e., the router
  4245.         itself did not appear in the neighbor's Hello packet).  All
  4246.  
  4247.  
  4248.  
  4249.  
  4250. Moy                Standards Track               [Page 85]
  4251.  
  4252. RFC 2328             OSPF Version 2              April 1998
  4253.  
  4254.  
  4255.         neighbors in this state (or    higher)    are listed in the Hello
  4256.         packets sent from the associated interface.
  4257.  
  4258.     2-Way
  4259.         In this state, communication between the two routers is
  4260.         bidirectional.  This has been assured by the operation of
  4261.         the    Hello Protocol.     This is the most advanced state short
  4262.         of beginning adjacency establishment.  The (Backup)
  4263.         Designated Router is selected from the set of neighbors in
  4264.         state 2-Way    or greater.
  4265.  
  4266.     ExStart
  4267.         This is the    first step in creating an adjacency between the
  4268.         two    neighboring routers.  The goal of this step is to decide
  4269.         which router is the    master,    and to decide upon the initial
  4270.         DD sequence    number.     Neighbor conversations    in this    state or
  4271.         greater are    called adjacencies.
  4272.  
  4273.     Exchange
  4274.         In this state the router is    describing its entire link state
  4275.         database by    sending    Database Description packets to    the
  4276.         neighbor.  Each Database Description Packet    has a DD
  4277.         sequence number, and is explicitly acknowledged.  Only one
  4278.         Database Description Packet    is allowed outstanding at any
  4279.         one    time.  In this state, Link State Request Packets may
  4280.         also be sent asking    for the    neighbor's more    recent LSAs.
  4281.         All    adjacencies in Exchange    state or greater are used by the
  4282.         flooding procedure.     In fact, these    adjacencies are    fully
  4283.         capable of transmitting and    receiving all types of OSPF
  4284.         routing protocol packets.
  4285.  
  4286.     Loading
  4287.         In this state, Link    State Request packets are sent to the
  4288.         neighbor asking for    the more recent    LSAs that have been
  4289.         discovered (but not    yet received) in the Exchange state.
  4290.  
  4291.     Full
  4292.         In this state, the neighboring routers are fully adjacent.
  4293.         These adjacencies will now appear in router-LSAs and
  4294.         network-LSAs.
  4295.  
  4296.  
  4297.  
  4298.  
  4299.  
  4300. Moy                Standards Track               [Page 86]
  4301.  
  4302. RFC 2328             OSPF Version 2              April 1998
  4303.  
  4304.  
  4305.     10.2.  Events causing neighbor state changes
  4306.  
  4307.     State changes can be effected by a number of events.  These
  4308.     events are shown in the    labels of the arcs in Figures 12 and 13.
  4309.     The label definitions are as follows:
  4310.  
  4311.  
  4312.     HelloReceived
  4313.         An Hello packet has    been received from the neighbor.
  4314.  
  4315.     Start
  4316.         This is an indication that Hello Packets should now    be sent
  4317.         to the neighbor at intervals of HelloInterval seconds.  This
  4318.         event is generated only for    neighbors associated with NBMA
  4319.         networks.
  4320.  
  4321.     2-WayReceived
  4322.         Bidirectional communication    has been realized between the
  4323.         two    neighboring routers.  This is indicated    by the router
  4324.         seeing itself in the neighbor's Hello packet.
  4325.  
  4326.     NegotiationDone
  4327.         The    Master/Slave relationship has been negotiated, and DD
  4328.         sequence numbers have been exchanged.  This    signals    the
  4329.         start of the sending/receiving of Database Description
  4330.         packets.  For more information on the generation of    this
  4331.         event, consult Section 10.8.
  4332.  
  4333.     ExchangeDone
  4334.         Both routers have successfully transmitted a full sequence
  4335.         of Database    Description packets.  Each router now knows what
  4336.         parts of its link state database are out of    date.  For more
  4337.         information    on the generation of this event, consult Section
  4338.         10.8.
  4339.  
  4340.     BadLSReq
  4341.         A Link State Request has been received for an LSA not
  4342.         contained in the database.    This indicates an error    in the
  4343.         Database Exchange process.
  4344.  
  4345.     Loading    Done
  4346.         Link State Updates have been received for all out-of-date
  4347.  
  4348.  
  4349.  
  4350. Moy                Standards Track               [Page 87]
  4351.  
  4352. RFC 2328             OSPF Version 2              April 1998
  4353.  
  4354.  
  4355.         portions of    the database.  This is indicated by the    Link
  4356.         state request list becoming    empty after the    Database
  4357.         Exchange process has completed.
  4358.  
  4359.     AdjOK?
  4360.         A decision must be made as to whether an adjacency should be
  4361.         established/maintained with    the neighbor.  This event will
  4362.         start some adjacencies forming, and    destroy    others.
  4363.  
  4364.  
  4365.     The following events cause well    developed neighbors to revert to
  4366.     lesser states.    Unlike the above events, these events may occur
  4367.     when the neighbor conversation is in any of a number of    states.
  4368.  
  4369.  
  4370.     SeqNumberMismatch
  4371.         A Database Description packet has been received that either
  4372.         a) has an unexpected DD sequence number, b)    unexpectedly has
  4373.         the    Init bit set or    c) has an Options field    differing from
  4374.         the    last Options field received in a Database Description
  4375.         packet.  Any of these conditions indicate that some    error
  4376.         has    occurred during    adjacency establishment.
  4377.  
  4378.     1-Way
  4379.         An Hello packet has    been received from the neighbor, in
  4380.         which the router is    not mentioned.    This indicates that
  4381.         communication with the neighbor is not bidirectional.
  4382.  
  4383.     KillNbr
  4384.         This  is  an  indication that  all    communication  with  the
  4385.         neighbor  is now  impossible,  forcing  the     neighbor  to
  4386.         revert  to    Down  state.
  4387.  
  4388.     InactivityTimer
  4389.         The    inactivity Timer has fired.  This means    that no    Hello
  4390.         packets have been seen recently from the neighbor.    The
  4391.         neighbor reverts to    Down state.
  4392.  
  4393.     LLDown
  4394.         This is an indication from the lower level protocols that
  4395.         the    neighbor is now    unreachable.  For example, on an X.25
  4396.         network this could be indicated by an X.25 clear indication
  4397.  
  4398.  
  4399.  
  4400. Moy                Standards Track               [Page 88]
  4401.  
  4402. RFC 2328             OSPF Version 2              April 1998
  4403.  
  4404.  
  4405.         with appropriate cause and diagnostic fields.  This    event
  4406.         forces the neighbor    into Down state.
  4407.  
  4408.  
  4409.     10.3.  The Neighbor    state machine
  4410.  
  4411.     A detailed description of the neighbor state changes follows.
  4412.     Each state change is invoked by    an event (Section 10.2).  This
  4413.     event may produce different effects, depending on the current
  4414.     state of the neighbor.    For this reason, the state machine below
  4415.     is organized by    current    neighbor state and received event.  Each
  4416.     entry in the state machine describes the resulting new neighbor
  4417.     state and the required set of additional actions.
  4418.  
  4419.     When a neighbor's state    changes, it may    be necessary to    rerun
  4420.     the Designated Router election algorithm.  This    is determined by
  4421.     whether    the interface NeighborChange event is generated    (see
  4422.     Section    9.2).  Also, if    the Interface is in DR state (the router
  4423.     is itself Designated Router), changes in neighbor state    may
  4424.     cause a    new network-LSA    to be originated (see Section 12.4).
  4425.  
  4426.     When the neighbor state    machine    needs to invoke    the interface
  4427.     state machine, it should be done as a scheduled    task (see
  4428.     Section    4.4).  This simplifies things, by ensuring that    neither
  4429.     state machine will be executed recursively.
  4430.  
  4431.  
  4432.      State(s):  Down
  4433.  
  4434.         Event:  Start
  4435.  
  4436.     New state:  Attempt
  4437.  
  4438.        Action:  Send an Hello Packet to the    neighbor (this neighbor
  4439.             is always associated with an NBMA network) and start
  4440.             the    Inactivity Timer for the neighbor.  The    timer's
  4441.             later firing would indicate    that communication with
  4442.             the    neighbor was not attained.
  4443.  
  4444.  
  4445.      State(s):  Attempt
  4446.  
  4447.  
  4448.  
  4449.  
  4450. Moy                Standards Track               [Page 89]
  4451.  
  4452. RFC 2328             OSPF Version 2              April 1998
  4453.  
  4454.  
  4455.         Event:  HelloReceived
  4456.  
  4457.     New state:  Init
  4458.  
  4459.        Action:  Restart the    Inactivity Timer for the neighbor, since
  4460.             the    neighbor has now been heard from.
  4461.  
  4462.  
  4463.      State(s):  Down
  4464.  
  4465.         Event:  HelloReceived
  4466.  
  4467.     New state:  Init
  4468.  
  4469.        Action:  Start the Inactivity Timer for the neighbor.  The
  4470.             timer's later firing would indicate    that the
  4471.             neighbor is    dead.
  4472.  
  4473.  
  4474.      State(s):  Init or greater
  4475.  
  4476.         Event:  HelloReceived
  4477.  
  4478.     New state:  No state change.
  4479.  
  4480.        Action:  Restart the    Inactivity Timer for the neighbor, since
  4481.             the    neighbor has again been    heard from.
  4482.  
  4483.  
  4484.      State(s):  Init
  4485.  
  4486.         Event:  2-WayReceived
  4487.  
  4488.     New state:  Depends upon action    routine.
  4489.  
  4490.        Action:  Determine whether an adjacency should be established
  4491.             with the neighbor (see Section 10.4).  If not, the
  4492.             new    neighbor state is 2-Way.
  4493.  
  4494.             Otherwise (an adjacency should be established) the
  4495.             neighbor state transitions to ExStart.  Upon
  4496.             entering this state, the router increments the DD
  4497.  
  4498.  
  4499.  
  4500. Moy                Standards Track               [Page 90]
  4501.  
  4502. RFC 2328             OSPF Version 2              April 1998
  4503.  
  4504.  
  4505.             sequence number in the neighbor data structure.  If
  4506.             this is the    first time that    an adjacency has been
  4507.             attempted, the DD sequence number should be    assigned
  4508.             some unique    value (like the    time of    day clock).  It
  4509.             then declares itself master    (sets the master/slave
  4510.             bit    to master), and    starts sending Database
  4511.             Description    Packets, with the initialize (I), more
  4512.             (M)    and master (MS)    bits set.  This    Database
  4513.             Description    Packet should be otherwise empty.  This
  4514.             Database Description Packet    should be retransmitted
  4515.             at intervals of RxmtInterval until the next    state is
  4516.             entered (see Section 10.8).
  4517.  
  4518.  
  4519.      State(s):  ExStart
  4520.  
  4521.         Event:  NegotiationDone
  4522.  
  4523.     New state:  Exchange
  4524.  
  4525.        Action:  The    router must list the contents of its entire area
  4526.             link state database    in the neighbor    Database summary
  4527.             list.  The area link state database    consists of the
  4528.             router-LSAs, network-LSAs and summary-LSAs contained
  4529.             in the area    structure, along with the AS-external-
  4530.             LSAs contained in the global structure.  AS-
  4531.             external-LSAs are omitted from a virtual neighbor's
  4532.             Database summary list.  AS-external-LSAs are omitted
  4533.             from the Database summary list if the area has been
  4534.             configured as a stub (see Section 3.6).  LSAs whose
  4535.             age    is equal to MaxAge are instead added to    the
  4536.             neighbor's Link state retransmission list.    A
  4537.             summary of the Database summary list will be sent to
  4538.             the    neighbor in Database Description packets.  Each
  4539.             Database Description Packet    has a DD sequence
  4540.             number, and    is explicitly acknowledged.  Only one
  4541.             Database Description Packet    is allowed outstanding
  4542.             at any one time.  For more detail on the sending and
  4543.             receiving of Database Description packets, see
  4544.             Sections 10.8 and 10.6.
  4545.  
  4546.  
  4547.  
  4548.  
  4549.  
  4550. Moy                Standards Track               [Page 91]
  4551.  
  4552. RFC 2328             OSPF Version 2              April 1998
  4553.  
  4554.  
  4555.      State(s):  Exchange
  4556.  
  4557.         Event:  ExchangeDone
  4558.  
  4559.     New state:  Depends upon action    routine.
  4560.  
  4561.        Action:  If the neighbor Link state request list is empty,
  4562.             the    new neighbor state is Full.  No    other action is
  4563.             required.  This is an adjacency's final state.
  4564.  
  4565.             Otherwise, the new neighbor    state is Loading.  Start
  4566.             (or    continue) sending Link State Request packets to
  4567.             the    neighbor (see Section 10.9).  These are    requests
  4568.             for    the neighbor's more recent LSAs    (which were
  4569.             discovered but not yet received in the Exchange
  4570.             state).  These LSAs    are listed in the Link state
  4571.             request list associated with the neighbor.
  4572.  
  4573.  
  4574.      State(s):  Loading
  4575.  
  4576.         Event:  Loading Done
  4577.  
  4578.     New state:  Full
  4579.  
  4580.        Action:  No action required.     This is an adjacency's    final
  4581.             state.
  4582.  
  4583.  
  4584.      State(s):  2-Way
  4585.  
  4586.         Event:  AdjOK?
  4587.  
  4588.     New state:  Depends upon action    routine.
  4589.  
  4590.        Action:  Determine whether an adjacency should be formed with
  4591.             the    neighboring router (see    Section    10.4).    If not,
  4592.             the    neighbor state remains at 2-Way.  Otherwise,
  4593.             transition the neighbor state to ExStart and perform
  4594.             the    actions    associated with    the above state    machine
  4595.             entry for state Init and event 2-WayReceived.
  4596.  
  4597.  
  4598.  
  4599.  
  4600. Moy                Standards Track               [Page 92]
  4601.  
  4602. RFC 2328             OSPF Version 2              April 1998
  4603.  
  4604.  
  4605.      State(s):  ExStart or greater
  4606.  
  4607.         Event:  AdjOK?
  4608.  
  4609.     New state:  Depends upon action    routine.
  4610.  
  4611.        Action:  Determine whether the neighboring router should
  4612.             still be adjacent.    If yes,    there is no state change
  4613.             and    no further action is necessary.
  4614.  
  4615.             Otherwise, the (possibly partially formed) adjacency
  4616.             must be destroyed.    The neighbor state transitions
  4617.             to 2-Way.  The Link    state retransmission list,
  4618.             Database summary list and Link state request list
  4619.             are    cleared    of LSAs.
  4620.  
  4621.  
  4622.      State(s):  Exchange or    greater
  4623.  
  4624.         Event:  SeqNumberMismatch
  4625.  
  4626.     New state:  ExStart
  4627.  
  4628.        Action:  The    (possibly partially formed) adjacency is torn
  4629.             down, and then an attempt is made at
  4630.             reestablishment.  The neighbor state first
  4631.             transitions    to ExStart.  The Link state
  4632.             retransmission list, Database summary list and Link
  4633.             state request list are cleared of LSAs.  Then the
  4634.             router increments the DD sequence number in    the
  4635.             neighbor data structure, declares itself master
  4636.             (sets the master/slave bit to master), and starts
  4637.             sending Database Description Packets, with the
  4638.             initialize (I), more (M) and master    (MS) bits set.
  4639.             This Database Description Packet should be otherwise
  4640.             empty (see Section 10.8).
  4641.  
  4642.  
  4643.      State(s):  Exchange or    greater
  4644.  
  4645.         Event:  BadLSReq
  4646.  
  4647.  
  4648.  
  4649.  
  4650. Moy                Standards Track               [Page 93]
  4651.  
  4652. RFC 2328             OSPF Version 2              April 1998
  4653.  
  4654.  
  4655.     New state:  ExStart
  4656.  
  4657.        Action:  The    action for event BadLSReq is exactly the same as
  4658.             for    the neighbor event SeqNumberMismatch.  The
  4659.             (possibly partially    formed)    adjacency is torn down,
  4660.             and    then an    attempt    is made    at reestablishment.  For
  4661.             more information, see the neighbor state machine
  4662.             entry that is invoked when event SeqNumberMismatch
  4663.             is generated in state Exchange or greater.
  4664.  
  4665.  
  4666.      State(s):  Any    state
  4667.  
  4668.         Event:  KillNbr
  4669.  
  4670.     New state:  Down
  4671.  
  4672.        Action:  The    Link state retransmission list,    Database summary
  4673.             list and Link state    request    list are cleared of
  4674.             LSAs.  Also, the Inactivity    Timer is disabled.
  4675.  
  4676.  
  4677.      State(s):  Any    state
  4678.  
  4679.         Event:  LLDown
  4680.  
  4681.     New state:  Down
  4682.  
  4683.        Action:  The    Link state retransmission list,    Database summary
  4684.             list and Link state    request    list are cleared of
  4685.             LSAs.  Also, the Inactivity    Timer is disabled.
  4686.  
  4687.  
  4688.      State(s):  Any    state
  4689.  
  4690.         Event:  InactivityTimer
  4691.  
  4692.     New state:  Down
  4693.  
  4694.        Action:  The    Link state retransmission list,    Database summary
  4695.             list and Link state    request    list are cleared of
  4696.             LSAs.
  4697.  
  4698.  
  4699.  
  4700. Moy                Standards Track               [Page 94]
  4701.  
  4702. RFC 2328             OSPF Version 2              April 1998
  4703.  
  4704.  
  4705.      State(s):  2-Way or greater
  4706.  
  4707.         Event:  1-WayReceived
  4708.  
  4709.     New state:  Init
  4710.  
  4711.        Action:  The    Link state retransmission list,    Database summary
  4712.             list and Link state    request    list are cleared of
  4713.             LSAs.
  4714.  
  4715.  
  4716.      State(s):  2-Way or greater
  4717.  
  4718.         Event:  2-WayReceived
  4719.  
  4720.     New state:  No state change.
  4721.  
  4722.        Action:  No action required.
  4723.  
  4724.  
  4725.      State(s):  Init
  4726.  
  4727.         Event:  1-WayReceived
  4728.  
  4729.     New state:  No state change.
  4730.  
  4731.        Action:  No action required.
  4732.  
  4733.  
  4734.     10.4.  Whether to become adjacent
  4735.  
  4736.     Adjacencies are    established with some subset of    the router's
  4737.     neighbors.  Routers connected by point-to-point    networks,
  4738.     Point-to-MultiPoint networks and virtual links always become
  4739.     adjacent.  On broadcast    and NBMA networks, all routers become
  4740.     adjacent to both the Designated    Router and the Backup Designated
  4741.     Router.
  4742.  
  4743.     The adjacency-forming decision occurs in two places in the
  4744.     neighbor state machine.     First,    when bidirectional communication
  4745.     is initially established with the neighbor, and    secondly, when
  4746.     the identity of    the attached network's (Backup)    Designated
  4747.  
  4748.  
  4749.  
  4750. Moy                Standards Track               [Page 95]
  4751.  
  4752. RFC 2328             OSPF Version 2              April 1998
  4753.  
  4754.  
  4755.     Router changes.     If the    decision is made to not    attempt    an
  4756.     adjacency, the state of    the neighbor communication stops at 2-
  4757.     Way.
  4758.  
  4759.     An adjacency should be established with    a bidirectional    neighbor
  4760.     when at    least one of the following conditions holds:
  4761.  
  4762.  
  4763.     o   The    underlying network type    is point-to-point
  4764.  
  4765.     o   The    underlying network type    is Point-to-MultiPoint
  4766.  
  4767.     o   The    underlying network type    is virtual link
  4768.  
  4769.     o   The    router itself is the Designated    Router
  4770.  
  4771.     o   The    router itself is the Backup Designated Router
  4772.  
  4773.     o   The    neighboring router is the Designated Router
  4774.  
  4775.     o   The    neighboring router is the Backup Designated Router
  4776.  
  4777.  
  4778.     10.5.  Receiving Hello Packets
  4779.  
  4780.     This section explains the detailed processing of a received
  4781.     Hello Packet.  (See Section A.3.2 for the format of Hello
  4782.     packets.)  The generic input processing    of OSPF    packets    will
  4783.     have checked the validity of the IP header and the OSPF    packet
  4784.     header.     Next, the values of the Network Mask, HelloInterval,
  4785.     and RouterDeadInterval fields in the received Hello packet must
  4786.     be checked against the values configured for the receiving
  4787.     interface.  Any    mismatch causes    processing to stop and the
  4788.     packet to be dropped.  In other    words, the above fields    are
  4789.     really describing the attached network's configuration.    However,
  4790.     there is one exception to the above rule: on point-to-point
  4791.     networks and on    virtual    links, the Network Mask    in the received
  4792.     Hello Packet should be ignored.
  4793.  
  4794.     The receiving interface    attaches to a single OSPF area (this
  4795.     could be the backbone).     The setting of    the E-bit found    in the
  4796.     Hello Packet's Options field must match    this area's
  4797.  
  4798.  
  4799.  
  4800. Moy                Standards Track               [Page 96]
  4801.  
  4802. RFC 2328             OSPF Version 2              April 1998
  4803.  
  4804.  
  4805.     ExternalRoutingCapability.  If AS-external-LSAs    are not    flooded
  4806.     into/throughout    the area (i.e, the area    is a "stub") the E-bit
  4807.     must be    clear in received Hello    Packets, otherwise the E-bit
  4808.     must be    set.  A    mismatch causes    processing to stop and the
  4809.     packet to be dropped.  The setting of the rest of the bits in
  4810.     the Hello Packet's Options field should    be ignored.
  4811.  
  4812.     At this    point, an attempt is made to match the source of the
  4813.     Hello Packet to    one of the receiving interface's neighbors.  If
  4814.     the receiving interface    connects to a broadcast, Point-to-
  4815.     MultiPoint or NBMA network the source is identified by the IP
  4816.     source address found in    the Hello's IP header.    If the receiving
  4817.     interface connects to a    point-to-point link or a virtual link,
  4818.     the source is identified by the    Router ID found    in the Hello's
  4819.     OSPF packet header.  The interface's current list of neighbors
  4820.     is contained in    the interface's    data structure.     If a matching
  4821.     neighbor structure cannot be found, (i.e., this    is the first
  4822.     time the neighbor has been detected), one is created.  The
  4823.     initial    state of a newly created neighbor is set to Down.
  4824.  
  4825.     When receiving an Hello    Packet from a neighbor on a broadcast,
  4826.     Point-to-MultiPoint or NBMA network, set the neighbor
  4827.     structure's Neighbor ID    equal to the Router ID found in    the
  4828.     packet's OSPF header.  For these network types,    the neighbor
  4829.     structure's Router Priority field, Neighbor's Designated Router
  4830.     field, and Neighbor's Backup Designated    Router field are also
  4831.     set equal to the corresponding fields found in the received
  4832.     Hello Packet; changes in these fields should be    noted for
  4833.     possible use in    the steps below.  When receiving an Hello on a
  4834.     point-to-point network (but not    on a virtual link) set the
  4835.     neighbor structure's Neighbor IP address to the    packet's IP
  4836.     source address.
  4837.  
  4838.     Now the    rest of    the Hello Packet is examined, generating events
  4839.     to be given to the neighbor and    interface state    machines.  These
  4840.     state machines are specified either to be executed or scheduled
  4841.     (see Section 4.4).  For    example, by specifying below that the
  4842.     neighbor state machine be executed in line, several neighbor
  4843.     state transitions may be effected by a single received Hello:
  4844.  
  4845.  
  4846.  
  4847.  
  4848.  
  4849.  
  4850. Moy                Standards Track               [Page 97]
  4851.  
  4852. RFC 2328             OSPF Version 2              April 1998
  4853.  
  4854.  
  4855.     o   Each Hello Packet causes the neighbor state    machine    to be
  4856.         executed with the event HelloReceived.
  4857.  
  4858.     o   Then the list of neighbors contained in the    Hello Packet is
  4859.         examined.  If the router itself appears in this list, the
  4860.         neighbor state machine should be executed with the event 2-
  4861.         WayReceived.  Otherwise, the neighbor state    machine    should
  4862.         be executed    with the event 1-WayReceived, and the processing
  4863.         of the packet stops.
  4864.  
  4865.     o   Next, if a change in the neighbor's    Router Priority    field
  4866.         was    noted, the receiving interface's state machine is
  4867.         scheduled with the event NeighborChange.
  4868.  
  4869.     o   If the neighbor is both declaring itself to    be Designated
  4870.         Router (Hello Packet's Designated Router field = Neighbor IP
  4871.         address) and the Backup Designated Router field in the
  4872.         packet is equal to 0.0.0.0 and the receiving interface is in
  4873.         state Waiting, the receiving interface's state machine is
  4874.         scheduled with the event BackupSeen.  Otherwise, if    the
  4875.         neighbor is    declaring itself to be Designated Router and it
  4876.         had    not previously,    or the neighbor    is not declaring itself
  4877.         Designated Router where it had previously, the receiving
  4878.         interface's    state machine is scheduled with    the event
  4879.         NeighborChange.
  4880.  
  4881.     o   If the neighbor is declaring itself    to be Backup Designated
  4882.         Router (Hello Packet's Backup Designated Router field =
  4883.         Neighbor IP    address) and the receiving interface is    in state
  4884.         Waiting, the receiving interface's state machine is
  4885.         scheduled with the event BackupSeen.  Otherwise, if    the
  4886.         neighbor is    declaring itself to be Backup Designated Router
  4887.         and    it had not previously, or the neighbor is not declaring
  4888.         itself Backup Designated Router where it had previously, the
  4889.         receiving interface's state    machine    is scheduled with the
  4890.         event NeighborChange.
  4891.  
  4892.     On NBMA    networks, receipt of an    Hello Packet may also cause an
  4893.     Hello Packet to    be sent    back to    the neighbor in    response. See
  4894.     Section    9.5.1 for more details.
  4895.  
  4896.  
  4897.  
  4898.  
  4899.  
  4900. Moy                Standards Track               [Page 98]
  4901.  
  4902. RFC 2328             OSPF Version 2              April 1998
  4903.  
  4904.  
  4905.     10.6.  Receiving Database Description Packets
  4906.  
  4907.     This section explains the detailed processing of a received
  4908.     Database Description Packet.  The incoming Database Description
  4909.     Packet has already been    associated with    a neighbor and receiving
  4910.     interface by the generic input packet processing (Section 8.2).
  4911.     Whether    the Database Description packet    should be accepted, and
  4912.     if so, how it should be    further    processed depends upon the
  4913.     neighbor state.
  4914.  
  4915.     If a Database Description packet is accepted, the following
  4916.     packet fields should be    saved in the corresponding neighbor data
  4917.     structure under    "last received Database    Description packet":
  4918.     the packet's initialize(I), more (M) and master(MS) bits,
  4919.     Options    field, and DD sequence number. If these    fields are set
  4920.     identically in two consecutive Database    Description packets
  4921.     received from the neighbor, the    second Database    Description
  4922.     packet is considered to    be a "duplicate" in the    processing
  4923.     described below.
  4924.  
  4925.     If the Interface MTU field in the Database Description packet
  4926.     indicates an IP    datagram size that is larger than the router can
  4927.     accept on the receiving    interface without fragmentation, the
  4928.     Database Description packet is rejected.  Otherwise, if    the
  4929.     neighbor state is:
  4930.  
  4931.     Down
  4932.         The    packet should be rejected.
  4933.  
  4934.     Attempt
  4935.         The    packet should be rejected.
  4936.  
  4937.     Init
  4938.         The    neighbor state machine should be executed with the event
  4939.         2-WayReceived.  This causes    an immediate state change to
  4940.         either state 2-Way or state    ExStart. If the    new state is
  4941.         ExStart, the processing of the current packet should then
  4942.         continue in    this new state by falling through to case
  4943.         ExStart below.
  4944.  
  4945.  
  4946.  
  4947.  
  4948.  
  4949.  
  4950. Moy                Standards Track               [Page 99]
  4951.  
  4952. RFC 2328             OSPF Version 2              April 1998
  4953.  
  4954.  
  4955.     2-Way
  4956.         The    packet should be ignored.  Database Description    Packets
  4957.         are    used only for the purpose of bringing up adjacencies.[7]
  4958.  
  4959.     ExStart
  4960.         If the received packet matches one of the following    cases,
  4961.         then the neighbor state machine should be executed with the
  4962.         event NegotiationDone (causing the state to    transition to
  4963.         Exchange), the packet's Options field should be recorded in
  4964.         the    neighbor structure's Neighbor Options field and    the
  4965.         packet should be accepted as next in sequence and processed
  4966.         further (see below).  Otherwise, the packet    should be
  4967.         ignored.
  4968.  
  4969.         o    The initialize(I), more    (M) and    master(MS) bits    are set,
  4970.         the contents of    the packet are empty, and the neighbor's
  4971.         Router ID is larger than the router's own.  In this case
  4972.         the router is now Slave.  Set the master/slave bit to
  4973.         slave, and set the neighbor data structure's DD    sequence
  4974.         number to that specified by the    master.
  4975.  
  4976.         o    The initialize(I) and master(MS) bits are off, the
  4977.         packet's DD sequence number equals the neighbor    data
  4978.         structure's DD sequence    number (indicating
  4979.         acknowledgment)    and the    neighbor's Router ID is    smaller
  4980.         than the router's own.    In this    case the router    is
  4981.         Master.
  4982.  
  4983.     Exchange
  4984.         Duplicate Database Description packets are discarded by the
  4985.         master, and    cause the slave    to retransmit the last Database
  4986.         Description    packet that it had sent. Otherwise (the    packet
  4987.         is not a duplicate):
  4988.  
  4989.         o    If the state of    the MS-bit is inconsistent with    the
  4990.         master/slave state of the connection, generate the
  4991.         neighbor event SeqNumberMismatch and stop processing the
  4992.         packet.
  4993.  
  4994.         o    If the initialize(I) bit is set, generate the neighbor
  4995.         event SeqNumberMismatch    and stop processing the    packet.
  4996.  
  4997.  
  4998.  
  4999.  
  5000. Moy                Standards Track              [Page 100]
  5001.  
  5002. RFC 2328             OSPF Version 2              April 1998
  5003.  
  5004.  
  5005.         o    If the packet's    Options    field indicates    a different set
  5006.         of optional OSPF capabilities than were    previously
  5007.         received from the neighbor (recorded in    the Neighbor
  5008.         Options    field of the neighbor structure), generate the
  5009.         neighbor event SeqNumberMismatch and stop processing the
  5010.         packet.
  5011.  
  5012.         o    Database Description packets must be processed in
  5013.         sequence, as indicated by the packets' DD sequence
  5014.         numbers. If the    router is master, the next packet
  5015.         received should    have DD    sequence number    equal to the DD
  5016.         sequence number    in the neighbor    data structure.    If the
  5017.         router is slave, the next packet received should have DD
  5018.         sequence number    equal to one more than the DD sequence
  5019.         number stored in the neighbor data structure. In either
  5020.         case, if the packet is the next    in sequence it should be
  5021.         accepted and its contents processed as specified below.
  5022.  
  5023.         o    Else, generate the neighbor event SeqNumberMismatch and
  5024.         stop processing    the packet.
  5025.  
  5026.     Loading    or Full
  5027.         In this state, the router has sent and received an entire
  5028.         sequence of    Database Description Packets.  The only    packets
  5029.         received should be duplicates (see above).    In particular,
  5030.         the    packet's Options field should match the    set of optional
  5031.         OSPF capabilities previously indicated by the neighbor
  5032.         (stored in the neighbor structure's    Neighbor Options field).
  5033.         Any    other packets received,    including the reception    of a
  5034.         packet with    the Initialize(I) bit set, should generate the
  5035.         neighbor event SeqNumberMismatch.[8] Duplicates should be
  5036.         discarded by the master.  The slave    must respond to
  5037.         duplicates by repeating the    last Database Description packet
  5038.         that it had    sent.
  5039.  
  5040.  
  5041.     When the router    accepts    a received Database Description    Packet
  5042.     as the next in sequence    the packet contents are    processed as
  5043.     follows.  For each LSA listed, the LSA's LS type is checked for
  5044.     validity.  If the LS type is unknown (e.g., not    one of the LS
  5045.     types 1-5 defined by this specification), or if    this is    an AS-
  5046.     external-LSA (LS type =    5) and the neighbor is associated with a
  5047.  
  5048.  
  5049.  
  5050. Moy                Standards Track              [Page 101]
  5051.  
  5052. RFC 2328             OSPF Version 2              April 1998
  5053.  
  5054.  
  5055.     stub area, generate the    neighbor event SeqNumberMismatch and
  5056.     stop processing    the packet.  Otherwise,    the router looks up the
  5057.     LSA in its database to see whether it also has an instance of
  5058.     the LSA.  If it    does not, or if    the database copy is less recent
  5059.     (see Section 13.1), the    LSA is put on the Link state request
  5060.     list so    that it    can be requested (immediately or at some later
  5061.     time) in Link State Request Packets.
  5062.  
  5063.     When the router    accepts    a received Database Description    Packet
  5064.     as the next in sequence, it also performs the following    actions,
  5065.     depending on whether it    is master or slave:
  5066.  
  5067.  
  5068.     Master
  5069.         Increments the DD sequence number in the neighbor data
  5070.         structure.    If the router has already sent its entire
  5071.         sequence of    Database Description Packets, and the just
  5072.         accepted packet has    the more bit (M) set to    0, the neighbor
  5073.         event ExchangeDone is generated.  Otherwise, it should send
  5074.         a new Database Description to the slave.
  5075.  
  5076.     Slave
  5077.         Sets the DD    sequence number    in the neighbor    data structure
  5078.         to the DD sequence number appearing    in the received    packet.
  5079.         The    slave must send    a Database Description Packet in reply.
  5080.         If the received packet has the more    bit (M)    set to 0, and
  5081.         the    packet to be sent by the slave will also have the M-bit
  5082.         set    to 0, the neighbor event ExchangeDone is generated.
  5083.         Note that the slave    always generates this event before the
  5084.         master.
  5085.  
  5086.  
  5087.     10.7.  Receiving Link State    Request    Packets
  5088.  
  5089.     This section explains the detailed processing of received Link
  5090.     State Request packets.    Received Link State Request Packets
  5091.     specify    a list of LSAs that the    neighbor wishes    to receive.
  5092.     Link State Request Packets should be accepted when the neighbor
  5093.     is in states Exchange, Loading,    or Full.  In all other states
  5094.     Link State Request Packets should be ignored.
  5095.  
  5096.  
  5097.  
  5098.  
  5099.  
  5100. Moy                Standards Track              [Page 102]
  5101.  
  5102. RFC 2328             OSPF Version 2              April 1998
  5103.  
  5104.  
  5105.     Each LSA specified in the Link State Request packet should be
  5106.     located    in the router's    database, and copied into Link State
  5107.     Update packets for transmission    to the neighbor.  These    LSAs
  5108.     should NOT be placed on    the Link state retransmission list for
  5109.     the neighbor.  If an LSA cannot    be found in the    database,
  5110.     something has gone wrong with the Database Exchange process, and
  5111.     neighbor event BadLSReq    should be generated.
  5112.  
  5113.  
  5114.     10.8.  Sending Database Description    Packets
  5115.  
  5116.     This section describes how Database Description    Packets    are sent
  5117.     to a neighbor. The Database Description    packet's Interface MTU
  5118.     field is set to    the size of the    largest    IP datagram that can be
  5119.     sent out the sending interface,    without    fragmentation.    Common
  5120.     MTUs in    use in the Internet can    be found in Table 7-1 of
  5121.     [Ref22]. Interface MTU should be set to    0 in Database
  5122.     Description packets sent over virtual links.
  5123.  
  5124.     The router's optional OSPF capabilities    (see Section 4.5) are
  5125.     transmitted to the neighbor in the Options field of the    Database
  5126.     Description packet.  The router    should maintain    the same set of
  5127.     optional capabilities throughout the Database Exchange and
  5128.     flooding procedures.  If for some reason the router's optional
  5129.     capabilities change, the Database Exchange procedure should be
  5130.     restarted by reverting to neighbor state ExStart.  One optional
  5131.     capability is defined in this specification (see Sections 4.5
  5132.     and A.2). The E-bit should be set if and only if the attached
  5133.     network    belongs    to a non-stub area. Unrecognized bits in the
  5134.     Options    field should be    set to zero.
  5135.  
  5136.     The sending of Database    Description packets depends on the
  5137.     neighbor's state.  In state ExStart the    router sends empty
  5138.     Database Description packets, with the initialize (I), more (M)
  5139.     and master (MS)    bits set.  These packets are retransmitted every
  5140.     RxmtInterval seconds.
  5141.  
  5142.     In state Exchange the Database Description Packets actually
  5143.     contain    summaries of the link state information    contained in the
  5144.     router's database.  Each LSA in    the area's link-state database
  5145.     (at the    time the neighbor transitions into Exchange state) is
  5146.     listed in the neighbor Database    summary    list.  Each new    Database
  5147.  
  5148.  
  5149.  
  5150. Moy                Standards Track              [Page 103]
  5151.  
  5152. RFC 2328             OSPF Version 2              April 1998
  5153.  
  5154.  
  5155.     Description Packet copies its DD sequence number from the
  5156.     neighbor data structure    and then describes the current top of
  5157.     the Database summary list.  Items are removed from the Database
  5158.     summary    list when the previous packet is acknowledged.
  5159.  
  5160.     In state Exchange, the determination of    when to    send a Database
  5161.     Description packet depends on whether the router is master or
  5162.     slave:
  5163.  
  5164.  
  5165.     Master
  5166.         Database Description packets are sent when either a) the
  5167.         slave acknowledges the previous Database Description packet
  5168.         by echoing the DD sequence number or b) RxmtInterval seconds
  5169.         elapse without an acknowledgment, in which case the    previous
  5170.         Database Description packet    is retransmitted.
  5171.  
  5172.     Slave
  5173.         Database Description packets are sent only in response to
  5174.         Database Description packets received from the master.  If
  5175.         the    Database Description packet received from the master is
  5176.         new, a new Database    Description packet is sent, otherwise
  5177.         the    previous Database Description packet is    resent.
  5178.  
  5179.  
  5180.     In states Loading and Full the slave must resend its last
  5181.     Database Description packet in response    to duplicate Database
  5182.     Description packets received from the master.  For this    reason
  5183.     the slave must wait RouterDeadInterval seconds before freeing
  5184.     the last Database Description packet.  Reception of a Database
  5185.     Description packet from    the master after this interval will
  5186.     generate a SeqNumberMismatch neighbor event.
  5187.  
  5188.  
  5189.     10.9.  Sending Link    State Request Packets
  5190.  
  5191.     In neighbor states Exchange or Loading,    the Link state request
  5192.     list contains a    list of    those LSAs that    need to    be obtained from
  5193.     the neighbor.  To request these    LSAs, a    router sends the
  5194.     neighbor the beginning of the Link state request list, packaged
  5195.     in a Link State    Request    packet.
  5196.  
  5197.  
  5198.  
  5199.  
  5200. Moy                Standards Track              [Page 104]
  5201.  
  5202. RFC 2328             OSPF Version 2              April 1998
  5203.  
  5204.  
  5205.     When the neighbor responds to these requests with the proper
  5206.     Link State Update packet(s), the Link state request list is
  5207.     truncated and a    new Link State Request packet is sent.    This
  5208.     process    continues until    the Link state request list becomes
  5209.     empty. LSAs on the Link    state request list that    have been
  5210.     requested, but not yet received, are packaged into Link    State
  5211.     Request    packets    for retransmission at intervals    of RxmtInterval.
  5212.     There should be    at most    one Link State Request packet
  5213.     outstanding at any one time.
  5214.  
  5215.     When the Link state request list becomes empty,    and the    neighbor
  5216.     state is Loading (i.e.,    a complete sequence of Database
  5217.     Description packets has    been sent to and received from the
  5218.     neighbor), the Loading Done neighbor event is generated.
  5219.  
  5220.  
  5221.     10.10.  An Example
  5222.  
  5223.     Figure 14 shows    an example of an adjacency forming.  Routers RT1
  5224.     and RT2    are both connected to a    broadcast network.  It is
  5225.     assumed    that RT2 is the    Designated Router for the network, and
  5226.     that RT2 has a higher Router ID    than Router RT1.
  5227.  
  5228.     The neighbor state changes realized by each router are listed on
  5229.     the sides of the figure.
  5230.  
  5231.     At the beginning of Figure 14, Router RT1's interface to the
  5232.     network    becomes    operational.  It begins    sending    Hello Packets,
  5233.     although it doesn't know the identity of the Designated    Router
  5234.     or of any other    neighboring routers.  Router RT2 hears this
  5235.     hello (moving the neighbor to Init state), and in its next Hello
  5236.     Packet indicates that it is itself the Designated Router and
  5237.     that it    has heard Hello    Packets    from RT1.  This    in turn    causes
  5238.     RT1 to go to state ExStart, as it starts to bring up the
  5239.     adjacency.
  5240.  
  5241.     RT1 begins by asserting    itself as the master.  When it sees that
  5242.     RT2 is indeed the master (because of RT2's higher Router ID),
  5243.     RT1 transitions    to slave state and adopts its neighbor's DD
  5244.     sequence number.  Database Description packets are then
  5245.     exchanged, with    polls coming from the master (RT2) and responses
  5246.     from the slave (RT1).  This sequence of    Database Description
  5247.  
  5248.  
  5249.  
  5250. Moy                Standards Track              [Page 105]
  5251.  
  5252. RFC 2328             OSPF Version 2              April 1998
  5253.  
  5254.  
  5255.  
  5256.  
  5257.  
  5258.  
  5259.  
  5260.         +---+                      +---+
  5261.         |RT1|                      |RT2|
  5262.         +---+                      +---+
  5263.  
  5264.         Down                      Down
  5265.                 Hello(DR=0,seen=0)
  5266.                ------------------------------>
  5267.              Hello (DR=RT2,seen=RT1,...)      Init
  5268.                <------------------------------
  5269.         ExStart       D-D (Seq=x,I,M,Master)
  5270.                ------------------------------>
  5271.                D-D (Seq=y,I,M,Master)      ExStart
  5272.                <------------------------------
  5273.         Exchange       D-D (Seq=y,M,Slave)
  5274.                ------------------------------>
  5275.                D-D (Seq=y+1,M,Master)      Exchange
  5276.                <------------------------------
  5277.                D-D (Seq=y+1,M,Slave)
  5278.                ------------------------------>
  5279.                      ...
  5280.                      ...
  5281.                      ...
  5282.                D-D (Seq=y+n, Master)
  5283.                <------------------------------
  5284.                D-D (Seq=y+n, Slave)
  5285.          Loading   ------------------------------>
  5286.                  LS Request           Full
  5287.                ------------------------------>
  5288.                  LS Update
  5289.                <------------------------------
  5290.                  LS Request
  5291.                ------------------------------>
  5292.                  LS Update
  5293.                <------------------------------
  5294.          Full
  5295.  
  5296.  
  5297.  
  5298.  
  5299.  
  5300. Moy                Standards Track              [Page 106]
  5301.  
  5302. RFC 2328             OSPF Version 2              April 1998
  5303.  
  5304.  
  5305.            Figure 14: An adjacency bring-up example
  5306.  
  5307.  
  5308.  
  5309.  
  5310.  
  5311.     Packets    ends when both the poll    and associated response    has the
  5312.     M-bit off.
  5313.  
  5314.     In this    example, it is assumed that RT2    has a completely up to
  5315.     date database.    In that    case, RT2 goes immediately into    Full
  5316.     state.    RT1 will go into Full state after updating the necessary
  5317.     parts of its database.    This is    done by    sending    Link State
  5318.     Request    Packets, and receiving Link State Update Packets in
  5319.     response.  Note    that, while RT1    has waited until a complete set
  5320.     of Database Description    Packets    has been received (from    RT2)
  5321.     before sending any Link    State Request Packets, this need not be
  5322.     the case.  RT1 could have interleaved the sending of Link State
  5323.     Request    Packets    with the reception of Database Description
  5324.     Packets.
  5325.  
  5326.  
  5327. 11.  The Routing Table Structure
  5328.  
  5329.     The    routing    table data structure contains all the information
  5330.     necessary to forward an IP data packet toward its destination.  Each
  5331.     routing table entry    describes the collection of best paths to a
  5332.     particular destination.  When forwarding an    IP data    packet,    the
  5333.     routing table entry    providing the best match for the packet's IP
  5334.     destination    is located.  The matching routing table    entry then
  5335.     provides the next hop towards the packet's destination.  OSPF also
  5336.     provides for the existence of a default route (Destination ID =
  5337.     DefaultDestination,    Address    Mask =    0x00000000).  When the default
  5338.     route exists, it matches all IP destinations (although any other
  5339.     matching entry is a    better match).    Finding    the routing table entry
  5340.     that best matches an IP destination    is further described in    Section
  5341.     11.1.
  5342.  
  5343.     There is a single routing table in each router.  Two sample    routing
  5344.     tables are described in Sections 11.2 and 11.3.  The building of the
  5345.     routing table is discussed in Section 16.
  5346.  
  5347.  
  5348.  
  5349.  
  5350. Moy                Standards Track              [Page 107]
  5351.  
  5352. RFC 2328             OSPF Version 2              April 1998
  5353.  
  5354.  
  5355.     The    rest of    this section defines the fields    found in a routing table
  5356.     entry.  The    first set of fields describes the routing table    entry's
  5357.     destination.
  5358.  
  5359.  
  5360.     Destination    Type
  5361.     Destination type is either "network" or    "router". Only network
  5362.     entries    are actually used when forwarding IP data traffic.
  5363.     Router routing table entries are used solely as    intermediate
  5364.     steps in the routing table build process.
  5365.  
  5366.     A network is a range of    IP addresses, to which IP data traffic
  5367.     may be forwarded.  This    includes IP networks (class A, B, or C),
  5368.     IP subnets, IP supernets and single IP hosts.  The default route
  5369.     also falls into    this category.
  5370.  
  5371.     Router entries are kept    for area border    routers    and AS boundary
  5372.     routers.  Routing table    entries    for area border    routers    are used
  5373.     when calculating the inter-area    routes (see Section 16.2), and
  5374.     when maintaining configured virtual links (see Section 15).
  5375.     Routing    table entries for AS boundary routers are used when
  5376.     calculating the    AS external routes (see    Section    16.4).
  5377.  
  5378.     Destination    ID
  5379.     The destination's identifier or    name.  This depends on the
  5380.     Destination Type.  For networks, the identifier    is their
  5381.     associated IP address.    For routers, the identifier is the OSPF
  5382.     Router ID.[9]
  5383.  
  5384.     Address Mask
  5385.     Only defined for networks.  The    network's IP address together
  5386.     with its address mask defines a    range of IP addresses.    For IP
  5387.     subnets, the address mask is referred to as the    subnet mask.
  5388.     For host routes, the mask is "all ones"    (0xffffffff).
  5389.  
  5390.     Optional Capabilities
  5391.     When the destination is    a router this field indicates the
  5392.     optional OSPF capabilities supported by    the destination    router.
  5393.     The only optional capability defined by    this specification is
  5394.     the ability to process AS-external-LSAs.  For a    further
  5395.     discussion of OSPF's optional capabilities, see    Section    4.5.
  5396.  
  5397.  
  5398.  
  5399.  
  5400. Moy                Standards Track              [Page 108]
  5401.  
  5402. RFC 2328             OSPF Version 2              April 1998
  5403.  
  5404.  
  5405.     The    set of paths to    use for    a destination may vary based on    the OSPF
  5406.     area to which the paths belong.  This means    that there may be
  5407.     multiple routing table entries for the same    destination, depending
  5408.     on the values of the next field.
  5409.  
  5410.  
  5411.     Area
  5412.     This field indicates the area whose link state information has
  5413.     led to the routing table entry's collection of paths.  This is
  5414.     called the entry's associated area.  For sets of AS external
  5415.     paths, this field is not defined.  For destinations of type
  5416.     "router", there    may be separate    sets of    paths (and therefore
  5417.     separate routing table entries)    associated with    each of    several
  5418.     areas. For example, this will happen when two area border
  5419.     routers    share multiple areas in    common.     For destinations of
  5420.     type "network",    only the set of    paths associated with the best
  5421.     area (the one providing    the preferred route) is    kept.
  5422.  
  5423.  
  5424.     The    rest of    the routing table entry    describes the set of paths to
  5425.     the    destination.  The following fields pertain to the set of paths
  5426.     as a whole.     In other words, each one of the paths contained in a
  5427.     routing table entry    is of the same path-type and cost (see below).
  5428.  
  5429.  
  5430.     Path-type
  5431.     There are four possible    types of paths used to route traffic to
  5432.     the destination, listed    here in    decreasing order of preference:
  5433.     intra-area, inter-area,    type 1 external    or type    2 external.
  5434.     Intra-area paths indicate destinations belonging to one    of the
  5435.     router's attached areas.  Inter-area paths are paths to
  5436.     destinations in    other OSPF areas.  These are discovered    through
  5437.     the examination    of received summary-LSAs.  AS external paths are
  5438.     paths to destinations external to the AS.  These are detected
  5439.     through    the examination    of received AS-external-LSAs.
  5440.  
  5441.     Cost
  5442.     The link state cost of the path    to the destination.  For all
  5443.     paths except type 2 external paths this    describes the entire
  5444.     path's cost.  For Type 2 external paths, this field describes
  5445.     the cost of the    portion    of the path internal to    the AS.     This
  5446.  
  5447.  
  5448.  
  5449.  
  5450. Moy                Standards Track              [Page 109]
  5451.  
  5452. RFC 2328             OSPF Version 2              April 1998
  5453.  
  5454.  
  5455.     cost is    calculated as the sum of the costs of the path's
  5456.     constituent links.
  5457.  
  5458.     Type 2 cost
  5459.     Only valid for type 2 external paths.  For these paths,    this
  5460.     field indicates    the cost of the    path's external    portion.  This
  5461.     cost has been advertised by an AS boundary router, and is the
  5462.     most significant part of the total path    cost.  For example, a
  5463.     type 2 external    path with type 2 cost of 5 is always preferred
  5464.     over a path with type 2    cost of    10, regardless of the cost of
  5465.     the two    paths' internal    components.
  5466.  
  5467.     Link State Origin
  5468.     Valid only for intra-area paths, this field indicates the LSA
  5469.     (router-LSA or network-LSA) that directly references the
  5470.     destination.  For example, if the destination is a transit
  5471.     network, this is the transit network's network-LSA.  If    the
  5472.     destination is a stub network, this is the router-LSA for the
  5473.     attached router.  The LSA is discovered    during the shortest-path
  5474.     tree calculation (see Section 16.1).  Multiple LSAs may
  5475.     reference the destination, however a tie-breaking scheme always
  5476.     reduces    the choice to a    single LSA. The    Link State Origin field
  5477.     is not used by the OSPF    protocol, but it is used by the    routing
  5478.     table calculation in OSPF's Multicast routing extensions
  5479.     (MOSPF).
  5480.  
  5481.     When multiple paths    of equal path-type and cost exist to a
  5482.     destination    (called    elsewhere "equal-cost" paths), they are    stored
  5483.     in a single    routing    table entry.  Each one of the "equal-cost" paths
  5484.     is distinguished by    the following fields:
  5485.  
  5486.     Next hop
  5487.     The outgoing router interface to use when forwarding traffic to
  5488.     the destination.  On broadcast,    Point-to-MultiPoint and    NBMA
  5489.     networks, the next hop also includes the IP address of the next
  5490.     router (if any)    in the path towards the    destination.
  5491.  
  5492.     Advertising    router
  5493.     Valid only for inter-area and AS external paths.  This field
  5494.     indicates the Router ID    of the router advertising the summary-
  5495.     LSA or AS-external-LSA that led    to this    path.
  5496.  
  5497.  
  5498.  
  5499.  
  5500. Moy                Standards Track              [Page 110]
  5501.  
  5502. RFC 2328             OSPF Version 2              April 1998
  5503.  
  5504.  
  5505.     11.1.  Routing table lookup
  5506.  
  5507.     When an    IP data    packet is received, an OSPF router finds the
  5508.     routing    table entry that best matches the packet's destination.
  5509.     This routing table entry then provides the outgoing interface
  5510.     and next hop router to use in forwarding the packet. This
  5511.     section    describes the process of finding the best matching
  5512.     routing    table entry.
  5513.  
  5514.     Before the lookup begins, "discard" routing table entries should
  5515.     be inserted into the routing table for each of the router's
  5516.     active area address ranges (see    Section    3.5).  (An area    range is
  5517.     considered "active" if the range contains one or more networks
  5518.     reachable by intra-area    paths.)    The destination    of a "discard"
  5519.     entry is the set of addresses described    by its associated active
  5520.     area address range, and    the path type of each "discard"    entry is
  5521.     set to "inter-area".[10]
  5522.  
  5523.     Several    routing    table entries may match    the destination    address.
  5524.     In this    case, the "best    match" is the routing table entry that
  5525.     provides the most specific (longest) match. Another way    of
  5526.     saying this is to choose the entry that    specifies the narrowest
  5527.     range of IP addresses.[11] For example,    the entry for the
  5528.     address/mask pair of (128.185.1.0, 0xffffff00) is more specific
  5529.     than an    entry for the pair (128.185.0.0, 0xffff0000). The
  5530.     default    route is the least specific match, since it matches all
  5531.     destinations. (Note that for any single    routing    table entry,
  5532.     multiple paths may be possible.    In these cases,    the calculations
  5533.     in Sections 16.1, 16.2,    and 16.4 always    yield the paths    having
  5534.     the most preferential path-type, as described in Section 11).
  5535.  
  5536.     If there is no matching    routing    table entry, or    the best match
  5537.     routing    table entry is one of the above    "discard" routing table
  5538.     entries, then the packet's IP destination is considered
  5539.     unreachable. Instead of    being forwarded, the packet should then
  5540.     be discarded and an ICMP destination unreachable message should
  5541.     be returned to the packet's source.
  5542.  
  5543.     11.2.  Sample routing table, without areas
  5544.  
  5545.     Consider the Autonomous    System pictured    in Figure 2.  No OSPF
  5546.     areas have been    configured.  A single metric is    shown per
  5547.  
  5548.  
  5549.  
  5550. Moy                Standards Track              [Page 111]
  5551.  
  5552. RFC 2328             OSPF Version 2              April 1998
  5553.  
  5554.  
  5555.     outbound interface.  The calculation of    Router RT6's routing
  5556.     table proceeds as described in Section 2.2.  The resulting
  5557.     routing    table is shown in Table    12.  Destination types are
  5558.     abbreviated: Network as    "N", Router as "R".
  5559.  
  5560.     There are no instances of multiple equal-cost shortest paths in
  5561.     this example.  Also, since there are no    areas, there are no
  5562.     inter-area paths.
  5563.  
  5564.     Routers    RT5 and    RT7 are    AS boundary routers.  Intra-area routes
  5565.     have been calculated to    Routers    RT5 and    RT7.  This allows
  5566.     external routes    to be calculated to the    destinations advertised
  5567.     by RT5 and RT7 (i.e., Networks N12, N13, N14 and N15).    It is
  5568.     assumed    all AS-external-LSAs originated    by RT5 and RT7 are
  5569.     advertising type 1 external metrics.  This results in type 1
  5570.     external paths being calculated    to destinations    N12-N15.
  5571.  
  5572.  
  5573.  
  5574.     11.3.  Sample routing table, with areas
  5575.  
  5576.     Consider the previous example, this time split into OSPF areas.
  5577.     An OSPF    area configuration is pictured in Figure 6.  Router
  5578.     RT4's routing table will be described for this area
  5579.     configuration.    Router RT4 has a connection to Area 1 and a
  5580.     backbone connection.  This causes Router RT4 to    view the AS as
  5581.     the concatenation of the two graphs shown in Figures 7 and 8.
  5582.     The resulting routing table is displayed in Table 13.
  5583.  
  5584.     Again, Routers RT5 and RT7 are AS boundary routers.  Routers
  5585.     RT3, RT4, RT7, RT10 and    RT11 are area border routers.  Note that
  5586.     there are two routing entries for the area border router RT3,
  5587.     since it has two areas in common with RT4 (Area    1 and the
  5588.     backbone).
  5589.  
  5590.     Backbone paths have been calculated to all area    border routers.
  5591.     These are used when determining    the inter-area routes.    Note
  5592.     that all of the    inter-area routes are associated with the
  5593.     backbone; this is always the case when the calculating router is
  5594.     itself an area border router.  Routing information is condensed
  5595.     at area    boundaries.  In    this example, we assume    that Area 3 has
  5596.     been defined so    that networks N9-N11 and the host route    to H1
  5597.  
  5598.  
  5599.  
  5600. Moy                Standards Track              [Page 112]
  5601.  
  5602. RFC 2328             OSPF Version 2              April 1998
  5603.  
  5604.  
  5605.  
  5606.  
  5607.       Type   Dest   Area   Path     Type     Cost    Next     Adv.
  5608.                         Hop(s)     Router(s)
  5609.       ____________________________________________________________
  5610.       N         N1        0       intra-area     10    RT3     *
  5611.       N         N2        0       intra-area     10    RT3     *
  5612.       N         N3        0       intra-area     7    RT3     *
  5613.       N         N4        0       intra-area     8    RT3     *
  5614.       N         Ib        0       intra-area     7    *     *
  5615.       N         Ia        0       intra-area     12    RT10     *
  5616.       N         N6        0       intra-area     8    RT10     *
  5617.       N         N7        0       intra-area     12    RT10     *
  5618.       N         N8        0       intra-area     10    RT10     *
  5619.       N         N9        0       intra-area     11    RT10     *
  5620.       N         N10    0       intra-area     13    RT10     *
  5621.       N         N11    0       intra-area     14    RT10     *
  5622.       N         H1        0       intra-area     21    RT10     *
  5623.       R         RT5    0       intra-area     6    RT5     *
  5624.       R         RT7    0       intra-area     8    RT10     *
  5625.       ____________________________________________________________
  5626.       N         N12    *       type    1 ext.     10    RT10     RT7
  5627.       N         N13    *       type    1 ext.     14    RT5     RT5
  5628.       N         N14    *       type    1 ext.     14    RT5     RT5
  5629.       N         N15    *       type    1 ext.     17    RT10     RT7
  5630.  
  5631.  
  5632.            Table 12: The routing table for Router RT6
  5633.              (no configured    areas).
  5634.  
  5635.     are all    condensed to a single route when advertised into the
  5636.     backbone (by Router RT11).  Note that the cost of this route is
  5637.     the maximum of the set of costs    to its individual components.
  5638.  
  5639.     There is a virtual link    configured between Routers RT10    and
  5640.     RT11.  Without this configured virtual link, RT11 would    be
  5641.     unable to advertise a route for    networks N9-N11    and Host H1 into
  5642.     the backbone, and there    would not be an    entry for these    networks
  5643.     in Router RT4's    routing    table.
  5644.  
  5645.     In this    example    there are two equal-cost paths to Network N12.
  5646.     However, they both use the same    next hop (Router RT5).
  5647.  
  5648.  
  5649.  
  5650. Moy                Standards Track              [Page 113]
  5651.  
  5652. RFC 2328             OSPF Version 2              April 1998
  5653.  
  5654.  
  5655.     Router RT4's routing table would improve (i.e.,    some of    the
  5656.     paths in the routing table would become    shorter) if an
  5657.     additional virtual link    were configured    between    Router RT4 and
  5658.     Router RT3.  The new virtual link would    itself be associated
  5659.     with the first entry for area border router RT3    in Table 13 (an
  5660.     intra-area path    through    Area 1).  This would yield a cost of 1
  5661.     for the    virtual    link.  The routing table entries changes that
  5662.     would be caused    by the addition    of this    virtual    link are shown
  5663.  
  5664.  
  5665.    Type      Dest          Area   Path  Type       Cost      Next        Adv.
  5666.                           Hops(s)   Router(s)
  5667.    __________________________________________________________________
  5668.    N      N1          1         intra-area       4      RT1        *
  5669.    N      N2          1         intra-area       4      RT2        *
  5670.    N      N3          1         intra-area       1      *        *
  5671.    N      N4          1         intra-area       3      RT3        *
  5672.    R      RT3          1         intra-area       1      *        *
  5673.    __________________________________________________________________
  5674.    N      Ib          0         intra-area       22      RT5        *
  5675.    N      Ia          0         intra-area       27      RT5        *
  5676.    R      RT3          0         intra-area       21      RT5        *
  5677.    R      RT5          0         intra-area       8      *        *
  5678.    R      RT7          0         intra-area       14      RT5        *
  5679.    R      RT10          0         intra-area       22      RT5        *
  5680.    R      RT11          0         intra-area       25      RT5        *
  5681.    __________________________________________________________________
  5682.    N      N6          0         inter-area       15      RT5        RT7
  5683.    N      N7          0         inter-area       19      RT5        RT7
  5684.    N      N8          0         inter-area       18      RT5        RT7
  5685.    N      N9-N11,H1   0         inter-area       36      RT5        RT11
  5686.    __________________________________________________________________
  5687.    N      N12          *         type 1 ext.   16      RT5        RT5,RT7
  5688.    N      N13          *         type 1 ext.   16      RT5        RT5
  5689.    N      N14          *         type 1 ext.   16      RT5        RT5
  5690.    N      N15          *         type 1 ext.   23      RT5        RT7
  5691.  
  5692.  
  5693.           Table    13: Router RT4's routing table
  5694.                in the presence of areas.
  5695.  
  5696.  
  5697.  
  5698.  
  5699.  
  5700. Moy                Standards Track              [Page 114]
  5701.  
  5702. RFC 2328             OSPF Version 2              April 1998
  5703.  
  5704.  
  5705.     in Table 14.
  5706.  
  5707.  
  5708.  
  5709. 12.  Link State    Advertisements (LSAs)
  5710.  
  5711.     Each router    in the Autonomous System originates one    or more    link
  5712.     state advertisements (LSAs).  This memo defines five distinct types
  5713.     of LSAs, which are described in Section 4.3.  The collection of LSAs
  5714.     forms the link-state database.  Each separate type of LSA has a
  5715.     separate function.    Router-LSAs and    network-LSAs describe how an
  5716.     area's routers and networks    are interconnected.  Summary-LSAs
  5717.     provide a way of condensing    an area's routing information.    AS-
  5718.     external-LSAs provide a way    of transparently advertising
  5719.     externally-derived routing information throughout the Autonomous
  5720.     System.
  5721.  
  5722.     Each LSA begins with a standard 20-byte header.  This LSA header is
  5723.     discussed below.
  5724.  
  5725.  
  5726.  
  5727.  
  5728.  
  5729.  
  5730.  
  5731.     Type   Dest           Area   Path  Type   Cost      Next       Adv.
  5732.                           Hop(s)   Router(s)
  5733.     ________________________________________________________________
  5734.     N       Ib           0      intra-area   16      RT3       *
  5735.     N       Ia           0      intra-area   21      RT3       *
  5736.     R       RT3           0      intra-area   1      *       *
  5737.     R       RT10           0      intra-area   16      RT3       *
  5738.     R       RT11           0      intra-area   19      RT3       *
  5739.     ________________________________________________________________
  5740.     N       N9-N11,H1   0      inter-area   30      RT3       RT11
  5741.  
  5742.  
  5743.           Table    14: Changes resulting from an
  5744.             additional virtual link.
  5745.  
  5746.  
  5747.  
  5748.  
  5749.  
  5750. Moy                Standards Track              [Page 115]
  5751.  
  5752. RFC 2328             OSPF Version 2              April 1998
  5753.  
  5754.  
  5755.     12.1.  The LSA Header
  5756.  
  5757.     The LSA    header contains    the LS type, Link State    ID and
  5758.     Advertising Router fields.  The    combination of these three
  5759.     fields uniquely    identifies the LSA.
  5760.  
  5761.     There may be several instances of an LSA present in the
  5762.     Autonomous System, all at the same time.  It must then be
  5763.     determined which instance is more recent.  This    determination is
  5764.     made by    examining the LS sequence, LS checksum and LS age
  5765.     fields.     These fields are also contained in the    20-byte    LSA
  5766.     header.
  5767.  
  5768.     Several    of the OSPF packet types list LSAs.  When the instance
  5769.     is not important, an LSA is referred to    by its LS type,    Link
  5770.     State ID and Advertising Router    (see Link State    Request
  5771.     Packets).  Otherwise, the LS sequence number, LS age and LS
  5772.     checksum fields    must also be referenced.
  5773.  
  5774.     A detailed explanation of the fields contained in the LSA header
  5775.     follows.
  5776.  
  5777.  
  5778.     12.1.1.     LS age
  5779.  
  5780.         This field is the age of the LSA in    seconds.  It should be
  5781.         processed as an unsigned 16-bit integer.  It is set    to 0
  5782.         when the LSA is originated.     It must be incremented    by
  5783.         InfTransDelay on every hop of the flooding procedure.  LSAs
  5784.         are    also aged as they are held in each router's database.
  5785.  
  5786.         The    age of an LSA is never incremented past    MaxAge.     LSAs
  5787.         having age MaxAge are not used in the routing table
  5788.         calculation.  When an LSA's    age first reaches MaxAge, it is
  5789.         reflooded.    An LSA of age MaxAge is    finally    flushed    from the
  5790.         database when it is    no longer needed to ensure database
  5791.         synchronization.  For more information on the aging    of LSAs,
  5792.         consult Section 14.
  5793.  
  5794.         The    LS age field is    examined when a    router receives    two
  5795.         instances of an LSA, both having identical LS sequence
  5796.         numbers and    LS checksums.  An instance of age MaxAge is then
  5797.  
  5798.  
  5799.  
  5800. Moy                Standards Track              [Page 116]
  5801.  
  5802. RFC 2328             OSPF Version 2              April 1998
  5803.  
  5804.  
  5805.         always accepted as most recent; this allows    old LSAs to be
  5806.         flushed quickly from the routing domain.  Otherwise, if the
  5807.         ages differ    by more    than MaxAgeDiff, the instance having the
  5808.         smaller age    is accepted as most recent.[12]    See Section 13.1
  5809.         for    more details.
  5810.  
  5811.  
  5812.     12.1.2.     Options
  5813.  
  5814.         The    Options    field in the LSA header    indicates which    optional
  5815.         capabilities are associated    with the LSA.  OSPF's optional
  5816.         capabilities are described in Section 4.5.    One optional
  5817.         capability is defined by this specification, represented by
  5818.         the    E-bit found in the Options field.  The unrecognized bits
  5819.         in the Options field should    be set to zero.
  5820.  
  5821.         The    E-bit represents OSPF's    ExternalRoutingCapability.  This
  5822.         bit    should be set in all LSAs associated with the backbone,
  5823.         and    all LSAs associated with non-stub areas    (see Section
  5824.         3.6).  It should also be set in all    AS-external-LSAs.  It
  5825.         should be reset in all router-LSAs,    network-LSAs and
  5826.         summary-LSAs associated with a stub    area.  For all LSAs, the
  5827.         setting of the E-bit is for    informational purposes only; it
  5828.         does not affect the    routing    table calculation.
  5829.  
  5830.  
  5831.     12.1.3.     LS type
  5832.  
  5833.         The    LS type    field dictates the format and function of the
  5834.         LSA.  LSAs of different types have different names (e.g.,
  5835.         router-LSAs    or network-LSAs).  All LSA types defined by this
  5836.         memo, except the AS-external-LSAs (LS type = 5), are flooded
  5837.         throughout a single    area only.  AS-external-LSAs are flooded
  5838.         throughout the entire Autonomous System, excepting stub
  5839.         areas (see Section 3.6).  Each separate LSA    type is    briefly
  5840.         described below in Table 15.
  5841.  
  5842.     12.1.4.     Link State ID
  5843.  
  5844.         This field identifies the piece of the routing domain that
  5845.         is being described by the LSA.  Depending on the LSA's LS
  5846.         type, the Link State ID takes on the values    listed in Table
  5847.  
  5848.  
  5849.  
  5850. Moy                Standards Track              [Page 117]
  5851.  
  5852. RFC 2328             OSPF Version 2              April 1998
  5853.  
  5854.  
  5855.  
  5856.  
  5857.         LS Type   LSA description
  5858.         ________________________________________________
  5859.         1          These are    the router-LSAs.
  5860.               They describe the    collected
  5861.                states of the router's
  5862.               interfaces. For more information,
  5863.               consult Section 12.4.1.
  5864.         ________________________________________________
  5865.         2          These are    the network-LSAs.
  5866.               They describe the    set of routers
  5867.               attached to the network. For
  5868.               more information,    consult
  5869.               Section 12.4.2.
  5870.         ________________________________________________
  5871.         3 or 4    These are    the summary-LSAs.
  5872.               They describe inter-area routes,
  5873.               and enable the condensation of
  5874.               routing information at area
  5875.               borders. Originated by area border
  5876.               routers, the Type    3 summary-LSAs
  5877.               describe routes to networks while    the
  5878.               Type 4 summary-LSAs describe routes to
  5879.               AS boundary routers.
  5880.         ________________________________________________
  5881.         5          These are    the AS-external-LSAs.
  5882.               Originated by AS boundary    routers,
  5883.               they describe routes
  5884.               to destinations external to the
  5885.               Autonomous System. A default route for
  5886.               the Autonomous System can    also be
  5887.               described    by an AS-external-LSA.
  5888.  
  5889.  
  5890.         Table 15: OSPF link    state advertisements (LSAs).
  5891.  
  5892.         16.
  5893.  
  5894.  
  5895.         Actually, for Type 3 summary-LSAs (LS type = 3) and    AS-
  5896.         external-LSAs (LS type = 5), the Link State    ID may
  5897.  
  5898.  
  5899.  
  5900. Moy                Standards Track              [Page 118]
  5901.  
  5902. RFC 2328             OSPF Version 2              April 1998
  5903.  
  5904.  
  5905.  
  5906.  
  5907.         LS Type   Link State ID
  5908.         _______________________________________________
  5909.         1          The originating router's Router ID.
  5910.         2          The IP interface address of the
  5911.               network's    Designated Router.
  5912.         3          The destination network's    IP address.
  5913.         4          The Router ID of the described AS
  5914.               boundary router.
  5915.         5          The destination network's    IP address.
  5916.  
  5917.  
  5918.            Table 16: The LSA's Link State ID.
  5919.  
  5920.         additionally have one or more of the destination network's
  5921.         "host" bits    set. For example, when originating an AS-
  5922.         external-LSA for the network 10.0.0.0 with mask of
  5923.         255.0.0.0, the Link    State ID can be    set to anything    in the
  5924.         range 10.0.0.0 through 10.255.255.255 inclusive (although
  5925.         10.0.0.0 should be used whenever possible).    The freedom to
  5926.         set    certain    host bits allows a router to originate separate
  5927.         LSAs for two networks having the same address but different
  5928.         masks. See Appendix    E for details.
  5929.  
  5930.         When the LSA is describing a network (LS type = 2, 3 or 5),
  5931.         the    network's IP address is    easily derived by masking the
  5932.         Link State ID with the network/subnet mask contained in the
  5933.         body of the    LSA.  When the LSA is describing a router (LS
  5934.         type = 1 or    4), the    Link State ID is always    the described
  5935.         router's OSPF Router ID.
  5936.  
  5937.         When an AS-external-LSA (LS    Type = 5) is describing    a
  5938.         default route, its Link State ID is    set to
  5939.         DefaultDestination (0.0.0.0).
  5940.  
  5941.  
  5942.     12.1.5.     Advertising Router
  5943.  
  5944.         This field specifies the OSPF Router ID of the LSA's
  5945.         originator.     For router-LSAs, this field is    identical to the
  5946.         Link State ID field.  Network-LSAs are originated by the
  5947.  
  5948.  
  5949.  
  5950. Moy                Standards Track              [Page 119]
  5951.  
  5952. RFC 2328             OSPF Version 2              April 1998
  5953.  
  5954.  
  5955.         network's Designated Router.  Summary-LSAs originated by
  5956.         area border    routers.  AS-external-LSAs are originated by AS
  5957.         boundary routers.
  5958.  
  5959.  
  5960.     12.1.6.     LS sequence number
  5961.  
  5962.         The    sequence number    field is a signed 32-bit integer.  It is
  5963.         used to detect old and duplicate LSAs.  The    space of
  5964.         sequence numbers is    linearly ordered.  The larger the
  5965.         sequence number (when compared as signed 32-bit integers)
  5966.         the    more recent the    LSA.  To describe to sequence number
  5967.         space more precisely, let N    refer in the discussion    below to
  5968.         the    constant 2**31.
  5969.  
  5970.         The    sequence number    -N (0x80000000)    is reserved (and
  5971.         unused).  This leaves -N + 1 (0x80000001) as the smallest
  5972.         (and therefore oldest) sequence number; this sequence number
  5973.         is referred    to as the constant InitialSequenceNumber. A
  5974.         router uses    InitialSequenceNumber the first    time it
  5975.         originates any LSA.     Afterwards, the LSA's sequence    number
  5976.         is incremented each    time the router    originates a new
  5977.         instance of    the LSA.  When an attempt is made to increment
  5978.         the    sequence number    past the maximum value of N - 1
  5979.         (0x7fffffff; also referred to as MaxSequenceNumber), the
  5980.         current instance of    the LSA    must first be flushed from the
  5981.         routing domain.  This is done by prematurely aging the LSA
  5982.         (see Section 14.1) and reflooding it.  As soon as this flood
  5983.         has    been acknowledged by all adjacent neighbors, a new
  5984.         instance can be originated with sequence number of
  5985.         InitialSequenceNumber.
  5986.  
  5987.         The    router may be forced to    promote    the sequence number of
  5988.         one    of its LSAs when a more    recent instance    of the LSA is
  5989.         unexpectedly received during the flooding process.    This
  5990.         should be a    rare event.  This may indicate that an out-of-
  5991.         date LSA, originated by the    router itself before its last
  5992.         restart/reload, still exists in the    Autonomous System.  For
  5993.         more information see Section 13.4.
  5994.  
  5995.  
  5996.  
  5997.  
  5998.  
  5999.  
  6000. Moy                Standards Track              [Page 120]
  6001.  
  6002. RFC 2328             OSPF Version 2              April 1998
  6003.  
  6004.  
  6005.     12.1.7.     LS checksum
  6006.  
  6007.         This field is the checksum of the complete contents    of the
  6008.         LSA, excepting the LS age field.  The LS age field is
  6009.         excepted so    that an    LSA's age can be incremented without
  6010.         updating the checksum.  The    checksum used is the same that
  6011.         is used for    ISO connectionless datagrams; it is commonly
  6012.         referred to    as the Fletcher    checksum.  It is documented in
  6013.         Annex B of [Ref6].    The LSA    header also contains the length
  6014.         of the LSA in bytes; subtracting the size of the LS    age
  6015.         field (two bytes) yields the amount    of data    to checksum.
  6016.  
  6017.         The    checksum is used to detect data    corruption of an LSA.
  6018.         This corruption can    occur while an LSA is being flooded, or
  6019.         while it is    being held in a    router's memory.  The LS
  6020.         checksum field cannot take on the value of zero; the
  6021.         occurrence of such a value should be considered a checksum
  6022.         failure.  In other words, calculation of the checksum is not
  6023.         optional.
  6024.  
  6025.         The    checksum of an LSA is verified in two cases:  a) when it
  6026.         is received    in a Link State    Update Packet and b) at    times
  6027.         during the aging of    the link state database.  The detection
  6028.         of a checksum failure leads    to separate actions in each
  6029.         case.  See Sections    13 and 14 for more details.
  6030.  
  6031.         Whenever the LS sequence number field indicates that two
  6032.         instances of an LSA    are the    same, the LS checksum field is
  6033.         examined.  If there    is a difference, the instance with the
  6034.         larger LS checksum is considered to    be most    recent.[13] See
  6035.         Section 13.1 for more details.
  6036.  
  6037.  
  6038.     12.2.  The link state database
  6039.  
  6040.     A router has a separate    link state database for    every area to
  6041.     which it belongs. All routers belonging    to the same area have
  6042.     identical link state databases for the area.
  6043.  
  6044.     The databases for each individual area are always dealt    with
  6045.     separately.  The shortest path calculation is performed
  6046.     separately for each area (see Section 16).  Components of the
  6047.  
  6048.  
  6049.  
  6050. Moy                Standards Track              [Page 121]
  6051.  
  6052. RFC 2328             OSPF Version 2              April 1998
  6053.  
  6054.  
  6055.     area link-state    database are flooded throughout    the area only.
  6056.     Finally, when an adjacency (belonging to Area A) is being
  6057.     brought    up, only the database for Area A is synchronized between
  6058.     the two    routers.
  6059.  
  6060.     The area database is composed of router-LSAs, network-LSAs and
  6061.     summary-LSAs (all listed in the    area data structure).  In
  6062.     addition, external routes (AS-external-LSAs) are included in all
  6063.     non-stub area databases    (see Section 3.6).
  6064.  
  6065.     An implementation of OSPF must be able to access individual
  6066.     pieces of an area database.  This lookup function is based on an
  6067.     LSA's LS type, Link State ID and Advertising Router.[14] There
  6068.     will be    a single instance (the most up-to-date)    of each    LSA in
  6069.     the database.  The database lookup function is invoked during
  6070.     the LSA    flooding procedure (Section 13)    and the    routing    table
  6071.     calculation (Section 16).  In addition,    using this lookup
  6072.     function the router can    determine whether it has itself    ever
  6073.     originated a particular    LSA, and if so,    with what LS sequence
  6074.     number.
  6075.  
  6076.     An LSA is added    to a router's database when either a) it is
  6077.     received during    the flooding process (Section 13) or b)    it is
  6078.     originated by the router itself    (Section 12.4).     An LSA    is
  6079.     deleted    from a router's    database when either a)    it has been
  6080.     overwritten by a newer instance    during the flooding process
  6081.     (Section 13) or    b) the router originates a newer instance of one
  6082.     of its self-originated LSAs (Section 12.4) or c) the LSA ages
  6083.     out and    is flushed from    the routing domain (Section 14).
  6084.     Whenever an LSA    is deleted from    the database it    must also be
  6085.     removed    from all neighbors' Link state retransmission lists (see
  6086.     Section    10).
  6087.  
  6088.  
  6089.     12.3.  Representation of TOS
  6090.  
  6091.     For backward compatibility with    previous versions of the OSPF
  6092.     specification ([Ref9]),    TOS-specific information can be    included
  6093.     in router-LSAs,    summary-LSAs and AS-external-LSAs.  The    encoding
  6094.     of TOS in OSPF LSAs is specified in Table 17. That table relates
  6095.     the OSPF encoding to the IP packet header's TOS    field (defined
  6096.     in [Ref12]).  The OSPF encoding    is expressed as    a decimal
  6097.  
  6098.  
  6099.  
  6100. Moy                Standards Track              [Page 122]
  6101.  
  6102. RFC 2328             OSPF Version 2              April 1998
  6103.  
  6104.  
  6105.     integer, and the IP packet header's TOS    field is expressed in
  6106.     the binary TOS values used in [Ref12].
  6107.  
  6108.  
  6109.  
  6110.             OSPF encoding   RFC    1349 TOS values
  6111.             ___________________________________________
  6112.             0            0000 normal    service
  6113.             2            0001 minimize monetary cost
  6114.             4            0010 maximize reliability
  6115.             6            0011
  6116.             8            0100 maximize throughput
  6117.             10            0101
  6118.             12            0110
  6119.             14            0111
  6120.             16            1000 minimize delay
  6121.             18            1001
  6122.             20            1010
  6123.             22            1011
  6124.             24            1100
  6125.             26            1101
  6126.             28            1110
  6127.             30            1111
  6128.  
  6129.  
  6130.             Table 17: Representing TOS in OSPF.
  6131.  
  6132.  
  6133.     12.4.  Originating LSAs
  6134.  
  6135.     Into any given OSPF area, a router will    originate several LSAs.
  6136.     Each router originates a router-LSA.  If the router is also the
  6137.     Designated Router for any of the area's    networks, it will
  6138.     originate network-LSAs for those networks.
  6139.  
  6140.     Area border routers originate a    single summary-LSA for each
  6141.     known inter-area destination.  AS boundary routers originate a
  6142.     single AS-external-LSA for each    known AS external destination.
  6143.     Destinations are advertised one    at a time so that the change in
  6144.     any single route can be    flooded    without    reflooding the entire
  6145.     collection of routes.  During the flooding procedure, many LSAs
  6146.     can be carried by a single Link    State Update packet.
  6147.  
  6148.  
  6149.  
  6150. Moy                Standards Track              [Page 123]
  6151.  
  6152. RFC 2328             OSPF Version 2              April 1998
  6153.  
  6154.  
  6155.     As an example, consider    Router RT4 in Figure 6.     It is an area
  6156.     border router, having a    connection to Area 1 and the backbone.
  6157.     Router RT4 originates 5    distinct LSAs into the backbone    (one
  6158.     router-LSA, and    one summary-LSA    for each of the    networks N1-N4).
  6159.     Router RT4 will    also originate 8 distinct LSAs into Area 1 (one
  6160.     router-LSA and seven summary-LSAs as pictured in Figure    7).  If
  6161.     RT4 has    been selected as Designated Router for Network N3, it
  6162.     will also originate a network-LSA for N3 into Area 1.
  6163.  
  6164.     In this    same figure, Router RT5    will be    originating 3 distinct
  6165.     AS-external-LSAs (one for each of the networks N12-N14).  These
  6166.     will be    flooded    throughout the entire AS, assuming that    none of
  6167.     the areas have been configured as stubs.  However, if area 3 has
  6168.     been configured    as a stub area,    the AS-external-LSAs for
  6169.     networks N12-N14 will not be flooded into area 3 (see Section
  6170.     3.6).  Instead,    Router RT11 would originate a default summary-
  6171.     LSA that would be flooded throughout area 3 (see Section
  6172.     12.4.3).  This instructs all of    area 3's internal routers to
  6173.     send their AS external traffic to RT11.
  6174.  
  6175.     Whenever a new instance    of an LSA is originated, its LS    sequence
  6176.     number is incremented, its LS age is set to 0, its LS checksum
  6177.     is calculated, and the LSA is added to the link    state database
  6178.     and flooded out    the appropriate    interfaces.  See Section 13.2
  6179.     for details concerning the installation    of the LSA into    the link
  6180.     state database.     See Section 13.3 for details concerning the
  6181.     flooding of newly originated LSAs.
  6182.  
  6183.  
  6184.     The ten    events that can    cause a    new instance of    an LSA to be
  6185.     originated are:
  6186.  
  6187.  
  6188.     (1) The    LS age field of    one of the router's self-originated LSAs
  6189.         reaches the    value LSRefreshTime. In    this case, a new
  6190.         instance of    the LSA    is originated, even though the contents
  6191.         of the LSA (apart from the LSA header) will    be the same.
  6192.         This guarantees periodic originations of all LSAs.    This
  6193.         periodic updating of LSAs adds robustness to the link state
  6194.         algorithm.    LSAs that solely describe unreachable
  6195.         destinations should    not be refreshed, but should instead be
  6196.         flushed from the routing domain (see Section 14.1).
  6197.  
  6198.  
  6199.  
  6200. Moy                Standards Track              [Page 124]
  6201.  
  6202. RFC 2328             OSPF Version 2              April 1998
  6203.  
  6204.  
  6205.     When whatever is being described by an LSA changes, a new LSA is
  6206.     originated.  However, two instances of the same    LSA may    not be
  6207.     originated within the time period MinLSInterval.  This may
  6208.     require    that the generation of the next    instance be delayed by
  6209.     up to MinLSInterval.  The following events may cause the
  6210.     contents of an LSA to change.  These events should cause new
  6211.     originations if    and only if the    contents of the    new LSA    would be
  6212.     different:
  6213.  
  6214.  
  6215.     (2) An interface's state changes (see Section 9.1).  This may
  6216.         mean that it is necessary to produce a new instance    of the
  6217.         router-LSA.
  6218.  
  6219.     (3) An attached    network's Designated Router changes.  A    new
  6220.         router-LSA should be originated.  Also, if the router itself
  6221.         is now the Designated Router, a new    network-LSA should be
  6222.         produced.  If the router itself is no longer the Designated
  6223.         Router, any    network-LSA that it might have originated for
  6224.         the    network    should be flushed from the routing domain (see
  6225.         Section 14.1).
  6226.  
  6227.     (4) One    of the neighboring routers changes to/from the FULL
  6228.         state.  This may mean that it is necessary to produce a new
  6229.         instance of    the router-LSA.     Also, if the router is    itself
  6230.         the    Designated Router for the attached network, a new
  6231.         network-LSA    should be produced.
  6232.  
  6233.  
  6234.     The next four events concern area border routers only:
  6235.  
  6236.  
  6237.     (5) An intra-area route    has been added/deleted/modified    in the
  6238.         routing table.  This may cause a new instance of a summary-
  6239.         LSA    (for this route) to be originated in each attached area
  6240.         (possibly including    the backbone).
  6241.  
  6242.     (6) An inter-area route    has been added/deleted/modified    in the
  6243.         routing table.  This may cause a new instance of a summary-
  6244.         LSA    (for this route) to be originated in each attached area
  6245.         (but NEVER for the backbone).
  6246.  
  6247.  
  6248.  
  6249.  
  6250. Moy                Standards Track              [Page 125]
  6251.  
  6252. RFC 2328             OSPF Version 2              April 1998
  6253.  
  6254.  
  6255.     (7) The    router becomes newly attached to an area.  The router
  6256.         must then originate    summary-LSAs into the newly attached
  6257.         area for all pertinent intra-area and inter-area routes in
  6258.         the    router's routing table.     See Section 12.4.3 for    more
  6259.         details.
  6260.  
  6261.     (8) When the state of one of the router's configured virtual
  6262.         links changes, it may be necessary to originate a new
  6263.         router-LSA into the    virtual    link's Transit area (see the
  6264.         discussion of the router-LSA's bit V in Section 12.4.1), as
  6265.         well as originating    a new router-LSA into the backbone.
  6266.  
  6267.  
  6268.     The last two events concern AS boundary    routers    (and former AS
  6269.     boundary routers) only:
  6270.  
  6271.  
  6272.     (9) An external    route gained through direct experience with an
  6273.         external routing protocol (like BGP) changes.  This    will
  6274.         cause an AS    boundary router    to originate a new instance of
  6275.         an AS-external-LSA.
  6276.  
  6277.     (10)
  6278.         A router ceases to be an AS    boundary router, perhaps after
  6279.         restarting.    In this    situation the router should flush all
  6280.         AS-external-LSAs that it had previously originated.     These
  6281.         LSAs can be    flushed    via the    premature aging    procedure
  6282.         specified in Section 14.1.
  6283.  
  6284.  
  6285.     The construction of each type of LSA is    explained in detail
  6286.     below.    In general, these sections describe the    contents of the
  6287.     LSA body (i.e.,    the part coming    after the 20-byte LSA header).
  6288.     For information    concerning the building    of the LSA header, see
  6289.     Section    12.1.
  6290.  
  6291.     12.4.1.     Router-LSAs
  6292.  
  6293.         A router originates    a router-LSA for each area that    it
  6294.         belongs to.     Such an LSA describes the collected states of
  6295.         the    router's links to the area.  The LSA is    flooded
  6296.         throughout the particular area, and    no further.
  6297.  
  6298.  
  6299.  
  6300. Moy                Standards Track              [Page 126]
  6301.  
  6302. RFC 2328             OSPF Version 2              April 1998
  6303.  
  6304.  
  6305.  
  6306.           ....................................
  6307.           . 192.1.2              Area 1 .
  6308.           .    +                 .
  6309.           .    |                 .
  6310.           .    | 3+---+1             .
  6311.           .  N1    |--|RT1|-----+             .
  6312.           .    |  +---+      \             .
  6313.           .    |           \  _______N3  .
  6314.           .    +        \/     \   .    1+---+
  6315.           .            * 192.1.1 *------|RT4|
  6316.           .    +        /\_______/   .     +---+
  6317.           .    |           /     |         .
  6318.           .    | 3+---+1     /         |         .
  6319.           .  N2    |--|RT2|-----+        1|         .
  6320.           .    |  +---+       +---+8    .           6+---+
  6321.           .    |           |RT3|----------------|RT6|
  6322.           .    +           +---+     .        +---+
  6323.           . 192.1.3             |2         .     18.10.0.6|7
  6324.           .                 |         .          |
  6325.           .              +------------+ .
  6326.           .            192.1.4    (N4) .
  6327.           ....................................
  6328.  
  6329.  
  6330.             Figure 15: Area 1 with IP addresses    shown
  6331.  
  6332.         The    format of a router-LSA is shown    in Appendix A (Section
  6333.         A.4.2).  The first 20 bytes    of the LSA consist of the
  6334.         generic LSA    header that was    discussed in Section 12.1.
  6335.         router-LSAs    have LS    type = 1.
  6336.  
  6337.         A router also indicates whether it is an area border router,
  6338.         or an AS boundary router, by setting the appropriate bits
  6339.         (bit B and bit E, respectively) in its router-LSAs.    This
  6340.         enables paths to those types of routers to be saved    in the
  6341.         routing table, for later processing    of summary-LSAs    and AS-
  6342.         external-LSAs.  Bit    B should be set    whenever the router is
  6343.         actively attached to two or    more areas, even if the    router
  6344.         is not currently attached to the OSPF backbone area.  Bit E
  6345.         should never be set    in a router-LSA    for a stub area    (stub
  6346.         areas cannot contain AS boundary routers).
  6347.  
  6348.  
  6349.  
  6350. Moy                Standards Track              [Page 127]
  6351.  
  6352. RFC 2328             OSPF Version 2              April 1998
  6353.  
  6354.  
  6355.         In addition, the router sets bit V in its router-LSA for
  6356.         Area A if and only if the router is    the endpoint of    one or
  6357.         more fully adjacent    virtual    links having Area A as their
  6358.         Transit area. The setting of bit V enables other routers in
  6359.         Area A to discover whether the area    supports transit traffic
  6360.         (see TransitCapability in Section 6).
  6361.  
  6362.         The    router-LSA then    describes the router's working
  6363.         connections    (i.e., interfaces or links) to the area.  Each
  6364.         link is typed according to the kind    of attached network.
  6365.         Each link is also labelled with its    Link ID.  This Link ID
  6366.         gives a name to the    entity that is on the other end    of the
  6367.         link.  Table 18 summarizes the values used for the Type and
  6368.         Link ID fields.
  6369.  
  6370.  
  6371.  
  6372.            Link    type   Description     Link ID
  6373.            __________________________________________________
  6374.            1           Point-to-point     Neighbor Router ID
  6375.                    link
  6376.            2           Link to transit     Interface address of
  6377.                    network         Designated Router
  6378.            3           Link to stub     IP network number
  6379.                    network
  6380.            4           Virtual link     Neighbor Router ID
  6381.  
  6382.  
  6383.                Table 18: Link descriptions in the
  6384.                       router-LSA.
  6385.  
  6386.  
  6387.         In addition, the Link Data field is    specified for each link.
  6388.         This field gives 32    bits of    extra information for the link.
  6389.         For    links to transit networks, numbered point-to-point links
  6390.         and    virtual    links, this field specifies the    IP interface
  6391.         address of the associated router interface (this is    needed
  6392.         by the routing table calculation, see Section 16.1.1).  For
  6393.         links to stub networks, this field specifies the stub
  6394.         network's IP address mask.    For unnumbered point-to-point
  6395.         links, the Link Data field should be set to    the unnumbered
  6396.         interface's    MIB-II [Ref8] ifIndex value.
  6397.  
  6398.  
  6399.  
  6400. Moy                Standards Track              [Page 128]
  6401.  
  6402. RFC 2328             OSPF Version 2              April 1998
  6403.  
  6404.  
  6405.         Finally, the cost of using the link    for output is specified.
  6406.         The    output cost of a link is configurable.    With the
  6407.         exception of links to stub networks, the output cost must
  6408.         always be non-zero.
  6409.  
  6410.         To further describe    the process of building    the list of link
  6411.         descriptions, suppose a router wishes to build a router-LSA
  6412.         for    Area A.     The router examines its collection of interface
  6413.         data structures.  For each interface, the following    steps
  6414.         are    taken:
  6415.  
  6416.  
  6417.         o    If the attached    network    does not belong    to Area    A, no
  6418.         links are added    to the LSA, and    the next interface
  6419.         should be examined.
  6420.  
  6421.         o    If the state of    the interface is Down, no links    are
  6422.         added.
  6423.  
  6424.         o    If the state of    the interface is Loopback, add a Type 3
  6425.         link (stub network) as long as this is not an interface
  6426.         to an unnumbered point-to-point    network.  The Link ID
  6427.         should be set to the IP    interface address, the Link Data
  6428.         set to the mask    0xffffffff (indicating a host route),
  6429.         and the    cost set to 0.
  6430.  
  6431.         o    Otherwise, the link descriptions added to the router-LSA
  6432.         depend on the OSPF interface type. Link    descriptions
  6433.         used for point-to-point    interfaces are specified in
  6434.         Section    12.4.1.1, for virtual links in Section 12.4.1.2,
  6435.         for broadcast and NBMA interfaces in 12.4.1.3, and for
  6436.         Point-to-MultiPoint interfaces in 12.4.1.4.
  6437.  
  6438.         After consideration    of all the router interfaces, host links
  6439.         are    added to the router-LSA    by examining the list of
  6440.         attached hosts belonging to    Area A.     A host    route is
  6441.         represented    as a Type 3 link (stub network)    whose Link ID is
  6442.         the    host's IP address, Link    Data is    the mask of all    ones
  6443.         (0xffffffff), and cost the host's configured cost (see
  6444.         Section C.7).
  6445.  
  6446.  
  6447.  
  6448.  
  6449.  
  6450. Moy                Standards Track              [Page 129]
  6451.  
  6452. RFC 2328             OSPF Version 2              April 1998
  6453.  
  6454.  
  6455.         12.4.1.1.  Describing point-to-point interfaces
  6456.  
  6457.         For point-to-point interfaces, one or more link
  6458.         descriptions are added to the router-LSA as follows:
  6459.  
  6460.         o   If the neighboring router is fully adjacent, add a
  6461.             Type 1 link    (point-to-point). The Link ID should be
  6462.             set    to the Router ID of the    neighboring router. For
  6463.             numbered point-to-point networks, the Link Data
  6464.             should specify the IP interface address. For
  6465.             unnumbered point-to-point networks,    the Link Data
  6466.             field should specify the interface's MIB-II    [Ref8]
  6467.             ifIndex value. The cost should be set to the output
  6468.             cost of the    point-to-point interface.
  6469.  
  6470.         o   In addition, as long as the    state of the interface
  6471.             is "Point-to-Point"    (and regardless    of the
  6472.             neighboring    router state), a Type 3    link (stub
  6473.             network) should be added. There are    two forms that
  6474.             this stub link can take:
  6475.  
  6476.             Option 1
  6477.             Assuming that the neighboring router's IP
  6478.             address    is known, set the Link ID of the Type 3
  6479.             link to    the neighbor's IP address, the Link Data
  6480.             to the mask 0xffffffff (indicating a host
  6481.             route),    and the    cost to    the interface's
  6482.             configured output cost.[15]
  6483.  
  6484.             Option 2
  6485.             If a subnet has    been assigned to the point-to-
  6486.             point link, set    the Link ID of the Type    3 link
  6487.             to the subnet's    IP address, the    Link Data to the
  6488.             subnet's mask, and the cost to the interface's
  6489.             configured output cost.[16]
  6490.  
  6491.  
  6492.         12.4.1.2.  Describing broadcast and    NBMA interfaces
  6493.  
  6494.         For operational    broadcast and NBMA interfaces, a single
  6495.         link description is added to the router-LSA as follows:
  6496.  
  6497.  
  6498.  
  6499.  
  6500. Moy                Standards Track              [Page 130]
  6501.  
  6502. RFC 2328             OSPF Version 2              April 1998
  6503.  
  6504.  
  6505.         o   If the state of the    interface is Waiting, add a Type
  6506.             3 link (stub network) with Link ID set to the IP
  6507.             network number of the attached network, Link Data
  6508.             set    to the attached    network's address mask,    and cost
  6509.             equal to the interface's configured    output cost.
  6510.  
  6511.         o   Else, there    has been a Designated Router elected for
  6512.             the    attached network.  If the router is fully
  6513.             adjacent to    the Designated Router, or if the router
  6514.             itself is Designated Router    and is fully adjacent to
  6515.             at least one other router, add a single Type 2 link
  6516.             (transit network) with Link    ID set to the IP
  6517.             interface address of the attached network's
  6518.             Designated Router (which may be the    router itself),
  6519.             Link Data set to the router's own IP interface
  6520.             address, and cost equal to the interface's
  6521.             configured output cost.  Otherwise,    add a link as if
  6522.             the    interface state    were Waiting (see above).
  6523.  
  6524.  
  6525.         12.4.1.3.  Describing virtual links
  6526.  
  6527.         For virtual links, a link description is added to the
  6528.         router-LSA only    when the virtual neighbor is fully
  6529.         adjacent. In this case,    add a Type 4 link (virtual link)
  6530.         with Link ID set to the    Router ID of the virtual
  6531.         neighbor, Link Data set    to the IP interface address
  6532.         associated with    the virtual link and cost set to the
  6533.         cost calculated    for the    virtual    link during the    routing
  6534.         table calculation (see Section 15).
  6535.  
  6536.  
  6537.         12.4.1.4.  Describing Point-to-MultiPoint interfaces
  6538.  
  6539.         For operational    Point-to-MultiPoint interfaces,    one or
  6540.         more link descriptions are added to the    router-LSA as
  6541.         follows:
  6542.  
  6543.         o   A single Type 3 link (stub network)    is added with
  6544.             Link ID set    to the router's    own IP interface
  6545.             address, Link Data set to the mask 0xffffffff
  6546.             (indicating    a host route), and cost    set to 0.
  6547.  
  6548.  
  6549.  
  6550. Moy                Standards Track              [Page 131]
  6551.  
  6552. RFC 2328             OSPF Version 2              April 1998
  6553.  
  6554.  
  6555.         o   For    each fully adjacent neighbor associated    with the
  6556.             interface, add an additional Type 1    link (point-to-
  6557.             point) with    Link ID    set to the Router ID of    the
  6558.             neighboring    router,    Link Data set to the IP
  6559.             interface address and cost equal to    the interface's
  6560.             configured output cost.
  6561.  
  6562.  
  6563.         12.4.1.5.  Examples    of router-LSAs
  6564.  
  6565.         Consider the router-LSAs generated by Router RT3, as
  6566.         pictured in Figure 6.  The area    containing Router RT3
  6567.         (Area 1) has been redrawn, with    actual network
  6568.         addresses, in Figure 15.  Assume that the last byte of
  6569.         all of RT3's interface addresses is 3, giving it the
  6570.         interface addresses 192.1.1.3 and 192.1.4.3, and that
  6571.         the other routers have similar addressing schemes.  In
  6572.         addition, assume that all links    are functional,    and that
  6573.         Router IDs are assigned    as the smallest    IP interface
  6574.         address.
  6575.  
  6576.         RT3 originates two router-LSAs,    one for    Area 1 and one
  6577.         for the    backbone.  Assume that Router RT4 has been
  6578.         selected as the    Designated router for network 192.1.1.0.
  6579.         RT3's router-LSA for Area 1 is then shown below.  It
  6580.         indicates that RT3 has two connections to Area 1, the
  6581.         first a    link to    the transit network 192.1.1.0 and the
  6582.         second a link to the stub network 192.1.4.0.  Note that
  6583.         the transit network is identified by the IP interface of
  6584.         its Designated Router (i.e., the Link ID = 192.1.1.4
  6585.         which is the Designated    Router RT4's IP    interface to
  6586.         192.1.1.0).  Note also that RT3    has indicated that it is
  6587.         an area    border router.
  6588.  
  6589.     ; RT3's    router-LSA for Area 1
  6590.  
  6591.     LS age = 0               ;always true on origination
  6592.     Options    = (E-bit)           ;
  6593.     LS type    = 1               ;indicates router-LSA
  6594.     Link State ID =    192.1.1.3      ;RT3's Router ID
  6595.     Advertising Router = 192.1.1.3 ;RT3's Router ID
  6596.     bit E =    0               ;not an AS boundary router
  6597.  
  6598.  
  6599.  
  6600. Moy                Standards Track              [Page 132]
  6601.  
  6602. RFC 2328             OSPF Version 2              April 1998
  6603.  
  6604.  
  6605.     bit B =    1               ;area border router
  6606.     #links = 2
  6607.            Link ID = 192.1.1.4     ;IP address of Desig. Rtr.
  6608.            Link Data = 192.1.1.3   ;RT3's IP interface to net
  6609.            Type = 2               ;connects to transit network
  6610.            # TOS metrics = 0
  6611.            metric =    1
  6612.  
  6613.            Link ID = 192.1.4.0     ;IP Network number
  6614.            Link Data = 0xffffff00  ;Network    mask
  6615.            Type = 3               ;connects to stub network
  6616.            # TOS metrics = 0
  6617.            metric =    2
  6618.  
  6619.             Next RT3's router-LSA for the backbone is shown.  It
  6620.             indicates that RT3 has a single attachment to the
  6621.             backbone.  This attachment is via an unnumbered
  6622.             point-to-point link    to Router RT6.    RT3 has    again
  6623.             indicated that it is an area border    router.
  6624.  
  6625.     ; RT3's    router-LSA for the backbone
  6626.  
  6627.     LS age = 0               ;always true on origination
  6628.     Options    = (E-bit)           ;
  6629.     LS type    = 1               ;indicates router-LSA
  6630.     Link State ID =    192.1.1.3      ;RT3's router ID
  6631.     Advertising Router = 192.1.1.3 ;RT3's router ID
  6632.     bit E =    0               ;not an AS boundary router
  6633.     bit B =    1               ;area border router
  6634.     #links = 1
  6635.            Link ID = 18.10.0.6     ;Neighbor's Router ID
  6636.            Link Data = 0.0.0.3     ;MIB-II ifIndex of P-P link
  6637.            Type = 1               ;connects to router
  6638.            # TOS metrics = 0
  6639.            metric =    8
  6640.  
  6641.     12.4.2.     Network-LSAs
  6642.  
  6643.         A network-LSA is generated for every transit broadcast or
  6644.         NBMA network.  (A transit network is a network having two or
  6645.         more attached routers).  The network-LSA describes all the
  6646.         routers that are attached to the network.
  6647.  
  6648.  
  6649.  
  6650. Moy                Standards Track              [Page 133]
  6651.  
  6652. RFC 2328             OSPF Version 2              April 1998
  6653.  
  6654.  
  6655.         The    Designated Router for the network originates the LSA.
  6656.         The    Designated Router originates the LSA only if it    is fully
  6657.         adjacent to    at least one other router on the network.  The
  6658.         network-LSA    is flooded throughout the area that contains the
  6659.         transit network, and no further.  The network-LSA lists
  6660.         those routers that are fully adjacent to the Designated
  6661.         Router; each fully adjacent    router is identified by    its OSPF
  6662.         Router ID.    The Designated Router includes itself in this
  6663.         list.
  6664.  
  6665.         The    Link State ID for a network-LSA    is the IP interface
  6666.         address of the Designated Router.  This value, masked by the
  6667.         network's address mask (which is also contained in the
  6668.         network-LSA) yields    the network's IP address.
  6669.  
  6670.         A router that has formerly been the    Designated Router for a
  6671.         network, but is no longer, should flush the    network-LSA that
  6672.         it had previously originated.  This    LSA is no longer used in
  6673.         the    routing    table calculation.  It is flushed by prematurely
  6674.         incrementing the LSA's age to MaxAge and reflooding    (see
  6675.         Section 14.1). In addition,    in those rare cases where a
  6676.         router's Router ID has changed, any    network-LSAs that were
  6677.         originated with the    router's previous Router ID must be
  6678.         flushed. Since the router may have no idea what it's
  6679.         previous Router ID might have been,    these network-LSAs are
  6680.         indicated by having    their Link State ID equal to one of the
  6681.         router's IP    interface addresses and    their Advertising Router
  6682.         equal to some value    other than the router's    current    Router
  6683.         ID (see Section 13.4 for more details).
  6684.  
  6685.  
  6686.         12.4.2.1.  Examples    of network-LSAs
  6687.  
  6688.         Again consider the area    configuration in Figure    6.
  6689.         Network-LSAs are originated for    Network    N3 in Area 1,
  6690.         Networks N6 and    N8 in Area 2, and Network N9 in    Area 3.
  6691.         Assuming that Router RT4 has been selected as the
  6692.         Designated Router for Network N3, the following
  6693.         network-LSA is generated by RT4    on behalf of Network N3
  6694.         (see Figure 15 for the address assignments):
  6695.  
  6696.     ; Network-LSA for Network N3
  6697.  
  6698.  
  6699.  
  6700. Moy                Standards Track              [Page 134]
  6701.  
  6702. RFC 2328             OSPF Version 2              April 1998
  6703.  
  6704.  
  6705.     LS age = 0               ;always true on origination
  6706.     Options    = (E-bit)           ;
  6707.     LS type    = 2               ;indicates network-LSA
  6708.     Link State ID =    192.1.1.4      ;IP address of Desig. Rtr.
  6709.     Advertising Router = 192.1.1.4 ;RT4's Router ID
  6710.     Network    Mask = 0xffffff00
  6711.            Attached    Router = 192.1.1.4    ;Router ID
  6712.            Attached    Router = 192.1.1.1    ;Router ID
  6713.            Attached    Router = 192.1.1.2    ;Router ID
  6714.            Attached    Router = 192.1.1.3    ;Router ID
  6715.  
  6716.     12.4.3.     Summary-LSAs
  6717.  
  6718.         The    destination described by a summary-LSA is either an IP
  6719.         network, an    AS boundary router or a    range of IP addresses.
  6720.         Summary-LSAs are flooded throughout    a single area only.  The
  6721.         destination    described is one that is external to the area,
  6722.         yet    still belongs to the Autonomous    System.
  6723.  
  6724.         Summary-LSAs are originated    by area    border routers.     The
  6725.         precise summary routes to advertise    into an    area are
  6726.         determined by examining the    routing    table structure    (see
  6727.         Section 11)    in accordance with the algorithm described
  6728.         below. Note    that only intra-area routes are    advertised into
  6729.         the    backbone, while    both intra-area    and inter-area routes
  6730.         are    advertised into    the other areas.
  6731.  
  6732.         To determine which routes to advertise into    an attached Area
  6733.         A, each routing table entry    is processed as    follows.
  6734.         Remember that each routing table entry describes a set of
  6735.         equal-cost best paths to a particular destination:
  6736.  
  6737.         o    Only Destination Types of network and AS boundary router
  6738.         are advertised in summary-LSAs.     If the    routing    table
  6739.         entry's    Destination Type is area border    router,    examine
  6740.         the next routing table entry.
  6741.  
  6742.         o    AS external routes are never advertised    in summary-LSAs.
  6743.         If the routing table entry has Path-type of type 1
  6744.         external or type 2 external, examine the next routing
  6745.         table entry.
  6746.  
  6747.  
  6748.  
  6749.  
  6750. Moy                Standards Track              [Page 135]
  6751.  
  6752. RFC 2328             OSPF Version 2              April 1998
  6753.  
  6754.  
  6755.         o    Else, if the area associated with this set of paths is
  6756.         the Area A itself, do not generate a summary-LSA for the
  6757.         route.[17]
  6758.  
  6759.         o    Else, if the next hops associated with this set    of paths
  6760.         belong to Area A itself, do not    generate a summary-LSA
  6761.         for the    route.[18] This    is the logical equivalent of a
  6762.         Distance Vector    protocol's split horizon logic.
  6763.  
  6764.         o    Else, if the routing table cost    equals or exceeds the
  6765.         value LSInfinity, a summary-LSA    cannot be generated for
  6766.         this route.
  6767.  
  6768.         o    Else, if the destination of this route is an AS    boundary
  6769.         router,    a summary-LSA should be    originated if and only
  6770.         if the routing table entry describes the preferred path
  6771.         to the AS boundary router (see Step 3 of Section 16.4).
  6772.         If so, a Type 4    summary-LSA is originated for the
  6773.         destination, with Link State ID    equal to the AS    boundary
  6774.         router's Router    ID and metric equal to the routing table
  6775.         entry's    cost. Note: these LSAs should not be generated
  6776.         if Area    A has been configured as a stub    area.
  6777.  
  6778.         o    Else, the Destination type is network. If this is an
  6779.         inter-area route, generate a Type 3 summary-LSA    for the
  6780.         destination, with Link State ID    equal to the network's
  6781.         address    (if necessary, the Link    State ID can also have
  6782.         one or more of the network's host bits set; see    Appendix
  6783.         E for details) and metric equal    to the routing table
  6784.         cost.
  6785.  
  6786.         o    The one    remaining case is an intra-area    route to a
  6787.         network.  This means that the network is contained in
  6788.         one of the router's directly attached areas.  In
  6789.         general, this information must be condensed before
  6790.         appearing in summary-LSAs.  Remember that an area has a
  6791.         configured list    of address ranges, each    range consisting
  6792.         of an [address,mask] pair and a    status indication of
  6793.         either Advertise or DoNotAdvertise.  At    most a single
  6794.         Type 3 summary-LSA is originated for each range. When
  6795.         the range's status indicates Advertise,    a Type 3
  6796.         summary-LSA is generated with Link State ID equal to the
  6797.  
  6798.  
  6799.  
  6800. Moy                Standards Track              [Page 136]
  6801.  
  6802. RFC 2328             OSPF Version 2              April 1998
  6803.  
  6804.  
  6805.         range's    address    (if necessary, the Link    State ID can
  6806.         also have one or more of the range's "host" bits set;
  6807.         see Appendix E for details) and    cost equal to the
  6808.         largest    cost of    any of the component networks. When the
  6809.         range's    status indicates DoNotAdvertise, the Type 3
  6810.         summary-LSA is suppressed and the component networks
  6811.         remain hidden from other areas.
  6812.  
  6813.         By default, if a network is not    contained in any
  6814.         explicitly configured address range, a Type 3 summary-
  6815.         LSA is generated with Link State ID equal to the
  6816.         network's address (if necessary, the Link State    ID can
  6817.         also have one or more of the network's "host" bits set;
  6818.         see Appendix E for details) and    metric equal to    the
  6819.         network's routing table    cost.
  6820.  
  6821.         If an area is capable of carrying transit traffic (i.e.,
  6822.         its TransitCapability is set to    TRUE), routing
  6823.         information concerning backbone    networks should    not be
  6824.         condensed before being summarized into the area.  Nor
  6825.         should the advertisement of backbone networks into
  6826.         transit    areas be suppressed.  In other words, the
  6827.         backbone's configured ranges should be ignored when
  6828.         originating summary-LSAs into transit areas.
  6829.  
  6830.         If a router    advertises a summary-LSA for a destination which
  6831.         then becomes unreachable, the router must then flush the LSA
  6832.         from the routing domain by setting its age to MaxAge and
  6833.         reflooding (see Section 14.1).  Also, if the destination is
  6834.         still reachable, yet can no    longer be advertised according
  6835.         to the above procedure (e.g., it is    now an inter-area route,
  6836.         when it used to be an intra-area route associated with some
  6837.         non-backbone area; it would    thus no    longer be advertisable
  6838.         to the backbone), the LSA should also be flushed from the
  6839.         routing domain.
  6840.  
  6841.  
  6842.         12.4.3.1.  Originating summary-LSAs    into stub areas
  6843.  
  6844.         The algorithm in Section 12.4.3    is optional when Area A
  6845.         is an OSPF stub    area. Area border routers connecting to
  6846.         a stub area can    originate summary-LSAs into the    area
  6847.  
  6848.  
  6849.  
  6850. Moy                Standards Track              [Page 137]
  6851.  
  6852. RFC 2328             OSPF Version 2              April 1998
  6853.  
  6854.  
  6855.         according to the Section 12.4.3's algorithm, or    can
  6856.         choose to originate only a subset of the summary-LSAs,
  6857.         possibly under configuration control.  The fewer LSAs
  6858.         originated, the    smaller    the stub area's    link state
  6859.         database, further reducing the demands on its routers'
  6860.         resources. However, omitting LSAs may also lead    to sub-
  6861.         optimal    inter-area routing, although routing will
  6862.         continue to function.
  6863.  
  6864.         As specified in    Section    12.4.3,    Type 4 summary-LSAs
  6865.         (ASBR-summary-LSAs) are    never originated into stub
  6866.         areas.
  6867.  
  6868.         In a stub area,    instead    of importing external routes
  6869.         each area border router    originates a "default summary-
  6870.         LSA" into the area. The    Link State ID for the default
  6871.         summary-LSA is set to DefaultDestination, and the metric
  6872.         set to the (per-area) configurable parameter
  6873.         StubDefaultCost.  Note that StubDefaultCost need not be
  6874.         configured identically in all of the stub area's area
  6875.         border routers.
  6876.  
  6877.  
  6878.         12.4.3.2.  Examples    of summary-LSAs
  6879.  
  6880.         Consider again the area    configuration in Figure    6.
  6881.         Routers    RT3, RT4, RT7, RT10 and    RT11 are all area border
  6882.         routers, and therefore are originating summary-LSAs.
  6883.         Consider in particular Router RT4.  Its    routing    table
  6884.         was calculated as the example in Section 11.3.    RT4
  6885.         originates summary-LSAs    into both the backbone and Area
  6886.         1.  Into the backbone, Router RT4 originates separate
  6887.         LSAs for each of the networks N1-N4.  Into Area    1,
  6888.         Router RT4 originates separate LSAs for    networks N6-N8
  6889.         and the    AS boundary routers RT5,RT7.  It also condenses
  6890.         host routes Ia and Ib into a single summary-LSA.
  6891.         Finally, the routes to networks    N9,N10,N11 and Host H1
  6892.         are advertised by a single summary-LSA.     This
  6893.         condensation was originally performed by the router
  6894.         RT11.
  6895.  
  6896.  
  6897.  
  6898.  
  6899.  
  6900. Moy                Standards Track              [Page 138]
  6901.  
  6902. RFC 2328             OSPF Version 2              April 1998
  6903.  
  6904.  
  6905.         These LSAs are illustrated graphically in Figures 7 and
  6906.         8.  Two    of the summary-LSAs originated by Router RT4
  6907.         follow.     The actual IP addresses for the networks and
  6908.         routers    in question have been assigned in Figure 15.
  6909.  
  6910.     ; Summary-LSA for Network N1,
  6911.     ; originated by    Router RT4 into    the backbone
  6912.  
  6913.     LS age = 0            ;always true on origination
  6914.     Options    = (E-bit)        ;
  6915.     LS type    = 3            ;Type 3 summary-LSA
  6916.     Link State ID =    192.1.2.0   ;N1's IP network number
  6917.     Advertising Router = 192.1.1.4         ;RT4's ID
  6918.     metric = 4
  6919.  
  6920.     ; Summary-LSA for AS boundary router RT7
  6921.     ; originated by    Router RT4 into    Area 1
  6922.  
  6923.     LS age = 0            ;always true on origination
  6924.     Options    = (E-bit)        ;
  6925.     LS type    = 4            ;Type 4 summary-LSA
  6926.     Link State ID =    Router RT7's ID
  6927.     Advertising Router = 192.1.1.4         ;RT4's ID
  6928.     metric = 14
  6929.  
  6930.     12.4.4.     AS-external-LSAs
  6931.  
  6932.         AS-external-LSAs describe routes to    destinations external to
  6933.         the    Autonomous System.  Most AS-external-LSAs describe
  6934.         routes to specific external    destinations; in these cases the
  6935.         LSA's Link State ID    is set to the destination network's IP
  6936.         address (if    necessary, the Link State ID can also have one
  6937.         or more of the network's "host" bits set; see Appendix E for
  6938.         details).  However,    a default route    for the    Autonomous
  6939.         System can be described in an AS-external-LSA by setting the
  6940.         LSA's Link State ID    to DefaultDestination (0.0.0.0).  AS-
  6941.         external-LSAs are originated by AS boundary    routers.  An AS
  6942.         boundary router originates a single    AS-external-LSA    for each
  6943.         external route that    it has learned,    either through another
  6944.         routing protocol (such as BGP), or through configuration
  6945.         information.
  6946.  
  6947.  
  6948.  
  6949.  
  6950. Moy                Standards Track              [Page 139]
  6951.  
  6952. RFC 2328             OSPF Version 2              April 1998
  6953.  
  6954.  
  6955.         AS-external-LSAs are the only type of LSAs that are    flooded
  6956.         throughout the entire Autonomous System; all other types of
  6957.         LSAs are specific to a single area.     However, AS-external-
  6958.         LSAs are not flooded into/throughout stub areas (see Section
  6959.         3.6).  This    enables    a reduction in link state database size
  6960.         for    routers    internal to stub areas.
  6961.  
  6962.         The    metric that is advertised for an external route    can be
  6963.         one    of two types.  Type 1 metrics are comparable to    the link
  6964.         state metric.  Type    2 metrics are assumed to be larger than
  6965.         the    cost of    any intra-AS path.
  6966.  
  6967.         If a router    advertises an AS-external-LSA for a destination
  6968.         which then becomes unreachable, the    router must then flush
  6969.         the    LSA from the routing domain by setting its age to MaxAge
  6970.         and    reflooding (see    Section    14.1).
  6971.  
  6972.  
  6973.         12.4.4.1.  Examples    of AS-external-LSAs
  6974.  
  6975.         Consider once again the    AS pictured in Figure 6.  There
  6976.         are two    AS boundary routers: RT5 and RT7.  Router RT5
  6977.         originates three AS-external-LSAs, for networks    N12-N14.
  6978.         Router RT7 originates two AS-external-LSAs, for    networks
  6979.         N12 and    N15.  Assume that RT7 has learned its route to
  6980.         N12 via    BGP, and that it wishes    to advertise a Type 2
  6981.         metric to the AS.  RT7 would then originate the
  6982.         following LSA for N12:
  6983.  
  6984.     ; AS-external-LSA for Network N12,
  6985.     ; originated by    Router RT7
  6986.  
  6987.     LS age = 0            ;always true on origination
  6988.     Options    = (E-bit)        ;
  6989.     LS type    = 5            ;AS-external-LSA
  6990.     Link State ID =    N12's IP network number
  6991.     Advertising Router = Router RT7's ID
  6992.     bit E =    1            ;Type 2 metric
  6993.     metric = 2
  6994.     Forwarding address = 0.0.0.0
  6995.  
  6996.  
  6997.  
  6998.  
  6999.  
  7000. Moy                Standards Track              [Page 140]
  7001.  
  7002. RFC 2328             OSPF Version 2              April 1998
  7003.  
  7004.  
  7005.             In the above example, the forwarding address field
  7006.             has    been set to 0.0.0.0, indicating    that packets for
  7007.             the    external destination should be forwarded to the
  7008.             advertising    OSPF router (RT7).  This is not    always
  7009.             desirable.    Consider the example pictured in Figure
  7010.             16.     There are three OSPF routers (RTA, RTB    and RTC)
  7011.             connected to a common network.  Only one of    these
  7012.             routers, RTA, is exchanging    BGP information    with the
  7013.             non-OSPF router RTX.  RTA must then    originate AS-
  7014.             external-LSAs for those destinations it has    learned
  7015.             from RTX.  By using    the AS-external-LSA's forwarding
  7016.             address field, RTA can specify that    packets    for
  7017.             these destinations be forwarded directly to    RTX.
  7018.             Without this feature, Routers RTB and RTC would take
  7019.             an extra hop to get    to these destinations.
  7020.  
  7021.             Note that when the forwarding address field    is non-
  7022.             zero, it should point to a router belonging    to
  7023.             another Autonomous System.
  7024.  
  7025.             A forwarding address can also be specified for the
  7026.             default route.  For    example, in figure 16 RTA may
  7027.             want to specify that all externally-destined packets
  7028.             should by default be forwarded to its BGP peer RTX.
  7029.             The    resulting AS-external-LSA is pictured below.
  7030.             Note that the Link State ID    is set to
  7031.             DefaultDestination.
  7032.  
  7033.     ; Default route, originated by Router RTA
  7034.     ; Packets forwarded through RTX
  7035.  
  7036.     LS age = 0            ;always true on origination
  7037.     Options    = (E-bit)        ;
  7038.     LS type    = 5            ;AS-external-LSA
  7039.     Link State ID =    DefaultDestination  ; default route
  7040.     Advertising Router = Router RTA's ID
  7041.     bit E =    1            ;Type 2 metric
  7042.     metric = 1
  7043.     Forwarding address = RTX's IP address
  7044.  
  7045.             In figure 16, suppose instead that both RTA    and RTB
  7046.             exchange BGP information with RTX.    In this    case,
  7047.  
  7048.  
  7049.  
  7050. Moy                Standards Track              [Page 141]
  7051.  
  7052. RFC 2328             OSPF Version 2              April 1998
  7053.  
  7054.  
  7055.             RTA    and RTB    would originate    the same set of    AS-
  7056.             external-LSAs.  These LSAs,    if they    specify    the same
  7057.             metric, would be functionally equivalent since they
  7058.             would specify the same destination and forwarding
  7059.             address (RTX).  This leads to a clear duplication of
  7060.             effort.  If    only one of RTA    or RTB originated the
  7061.             set    of AS-external-LSAs, the routing would remain
  7062.             the    same, and the size of the link state database
  7063.             would decrease.  However, it must be unambiguously
  7064.             defined as to which    router originates the LSAs
  7065.             (otherwise neither may, or the identity of the
  7066.             originator may oscillate).    The following rule is
  7067.             thereby established: if two    routers, both reachable
  7068.             from one another, originate    functionally equivalent
  7069.             AS-external-LSAs (i.e., same destination, cost and
  7070.             non-zero forwarding    address), then the LSA
  7071.             originated by the router having the    highest    OSPF
  7072.             Router ID is used.    The router having the lower OSPF
  7073.             Router ID can then flush its LSA.  Flushing    an LSA
  7074.             is discussed in Section 14.1.
  7075.  
  7076.  
  7077.                 +
  7078.                 |
  7079.               +---+.....|.BGP
  7080.               |RTA|-----|.....+---+
  7081.               +---+    |-----|RTX|
  7082.                 |     +---+
  7083.               +---+    |
  7084.               |RTB|-----|
  7085.               +---+    |
  7086.                 |
  7087.               +---+    |
  7088.               |RTC|-----|
  7089.               +---+    |
  7090.                 |
  7091.                 +
  7092.  
  7093.  
  7094.            Figure 16: Forwarding address example
  7095.  
  7096.  
  7097.  
  7098.  
  7099.  
  7100. Moy                Standards Track              [Page 142]
  7101.  
  7102. RFC 2328             OSPF Version 2              April 1998
  7103.  
  7104.  
  7105. 13.  The Flooding Procedure
  7106.  
  7107.     Link State Update packets provide the mechanism for    flooding LSAs.
  7108.     A Link State Update    packet may contain several distinct LSAs, and
  7109.     floods each    LSA one    hop further from its point of origination.  To
  7110.     make the flooding procedure    reliable, each LSA must    be acknowledged
  7111.     separately.     Acknowledgments are transmitted in Link State
  7112.     Acknowledgment packets.  Many separate acknowledgments can also be
  7113.     grouped together into a single packet.
  7114.  
  7115.     The    flooding procedure starts when a Link State Update packet has
  7116.     been received.  Many consistency checks have been made on the
  7117.     received packet before being handed    to the flooding    procedure (see
  7118.     Section 8.2).  In particular, the Link State Update    packet has been
  7119.     associated with a particular neighbor, and a particular area.  If
  7120.     the    neighbor is in a lesser    state than Exchange, the packet    should
  7121.     be dropped without further processing.
  7122.  
  7123.     All    types of LSAs, other than AS-external-LSAs, are    associated with
  7124.     a specific area.  However, LSAs do not contain an area field.  An
  7125.     LSA's area must be deduced from the    Link State Update packet header.
  7126.  
  7127.     For    each LSA contained in a    Link State Update packet, the following
  7128.     steps are taken:
  7129.  
  7130.  
  7131.     (1)    Validate the LSA's LS checksum.     If the    checksum turns out to be
  7132.     invalid, discard the LSA and get the next one from the Link
  7133.     State Update packet.
  7134.  
  7135.     (2)    Examine    the LSA's LS type.  If the LS type is unknown, discard
  7136.     the LSA    and get    the next one from the Link State Update    Packet.
  7137.     This specification defines LS types 1-5    (see Section 4.3).
  7138.  
  7139.     (3)    Else if    this is    an AS-external-LSA (LS type = 5), and the area
  7140.     has been configured as a stub area, discard the    LSA and    get the
  7141.     next one from the Link State Update Packet.  AS-external-LSAs
  7142.     are not    flooded    into/throughout    stub areas (see    Section    3.6).
  7143.  
  7144.     (4)    Else if    the LSA's LS age is equal to MaxAge, and there is
  7145.     currently no instance of the LSA in the    router's link state
  7146.     database, and none of router's neighbors are in    states Exchange
  7147.  
  7148.  
  7149.  
  7150. Moy                Standards Track              [Page 143]
  7151.  
  7152. RFC 2328             OSPF Version 2              April 1998
  7153.  
  7154.  
  7155.     or Loading, then take the following actions: a)    Acknowledge the
  7156.     receipt    of the LSA by sending a    Link State Acknowledgment packet
  7157.     back to    the sending neighbor (see Section 13.5), and b)    Discard
  7158.     the LSA    and examine the    next LSA (if any) listed in the    Link
  7159.     State Update packet.
  7160.  
  7161.     (5)    Otherwise, find    the instance of    this LSA that is currently
  7162.     contained in the router's link state database.    If there is no
  7163.     database copy, or the received LSA is more recent than the
  7164.     database copy (see Section 13.1    below for the determination of
  7165.     which LSA is more recent) the following    steps must be performed:
  7166.  
  7167.     (a) If there is    already    a database copy, and if    the database
  7168.         copy was received via flooding and installed less than
  7169.         MinLSArrival seconds ago, discard the new LSA (without
  7170.         acknowledging it) and examine the next LSA (if any)    listed
  7171.         in the Link    State Update packet.
  7172.  
  7173.     (b) Otherwise immediately flood    the new    LSA out    some subset of
  7174.         the    router's interfaces (see Section 13.3).     In some cases
  7175.         (e.g., the state of    the receiving interface    is DR and the
  7176.         LSA    was received from a router other than the Backup DR) the
  7177.         LSA    will be    flooded    back out the receiving interface.  This
  7178.         occurrence should be noted for later use by    the
  7179.         acknowledgment process (Section 13.5).
  7180.  
  7181.     (c) Remove the current database    copy from all neighbors' Link
  7182.         state retransmission lists.
  7183.  
  7184.     (d) Install the    new LSA    in the link state database (replacing
  7185.         the    current    database copy).     This may cause    the routing
  7186.         table calculation to be scheduled.    In addition, timestamp
  7187.         the    new LSA    with the current time (i.e., the time it was
  7188.         received).    The flooding procedure cannot overwrite    the
  7189.         newly installed LSA    until MinLSArrival seconds have    elapsed.
  7190.         The    LSA installation process is discussed further in Section
  7191.         13.2.
  7192.  
  7193.     (e) Possibly acknowledge the receipt of    the LSA    by sending a
  7194.         Link State Acknowledgment packet back out the receiving
  7195.         interface.    This is    explained below    in Section 13.5.
  7196.  
  7197.  
  7198.  
  7199.  
  7200. Moy                Standards Track              [Page 144]
  7201.  
  7202. RFC 2328             OSPF Version 2              April 1998
  7203.  
  7204.  
  7205.     (f) If this new    LSA indicates that it was originated by    the
  7206.         receiving router itself (i.e., is considered a self-
  7207.         originated LSA), the router    must take special action, either
  7208.         updating the LSA or    in some    cases flushing it from the
  7209.         routing domain. For    a description of how self-originated
  7210.         LSAs are detected and subsequently handled,    see Section
  7211.         13.4.
  7212.  
  7213.     (6)    Else, if there is an instance of the LSA on the    sending
  7214.     neighbor's Link    state request list, an error has occurred in the
  7215.     Database Exchange process.  In this case, restart the Database
  7216.     Exchange process by generating the neighbor event BadLSReq for
  7217.     the sending neighbor and stop processing the Link State    Update
  7218.     packet.
  7219.  
  7220.     (7)    Else, if the received LSA is the same instance as the database
  7221.     copy (i.e., neither one    is more    recent)    the following two steps
  7222.     should be performed:
  7223.  
  7224.     (a) If the LSA is listed in the    Link state retransmission list
  7225.         for    the receiving adjacency, the router itself is expecting
  7226.         an acknowledgment for this LSA.  The router    should treat the
  7227.         received LSA as an acknowledgment by removing the LSA from
  7228.         the    Link state retransmission list.     This is termed    an
  7229.         "implied acknowledgment".  Its occurrence should be    noted
  7230.         for    later use by the acknowledgment    process    (Section 13.5).
  7231.  
  7232.     (b) Possibly acknowledge the receipt of    the LSA    by sending a
  7233.         Link State Acknowledgment packet back out the receiving
  7234.         interface.    This is    explained below    in Section 13.5.
  7235.  
  7236.     (8)    Else, the database copy    is more    recent.     If the    database copy
  7237.     has LS age equal to MaxAge and LS sequence number equal    to
  7238.     MaxSequenceNumber, simply discard the received LSA without
  7239.     acknowledging it. (In this case, the LSA's LS sequence number is
  7240.     wrapping, and the MaxSequenceNumber LSA    must be    completely
  7241.     flushed    before any new LSA instance can    be introduced).
  7242.     Otherwise, as long as the database copy    has not    been sent in a
  7243.     Link State Update within the last MinLSArrival seconds,    send the
  7244.     database copy back to the sending neighbor, encapsulated within
  7245.     a Link State Update Packet. The    Link State Update Packet should
  7246.     be sent    directly to the    neighbor. In so    doing, do not put the
  7247.  
  7248.  
  7249.  
  7250. Moy                Standards Track              [Page 145]
  7251.  
  7252. RFC 2328             OSPF Version 2              April 1998
  7253.  
  7254.  
  7255.     database copy of the LSA on the    neighbor's link    state
  7256.     retransmission list, and do not    acknowledge the    received (less
  7257.     recent)    LSA instance.
  7258.  
  7259.  
  7260.     13.1.  Determining which LSA is newer
  7261.  
  7262.     When a router encounters two instances of an LSA, it must
  7263.     determine which    is more    recent.     This occurred above when
  7264.     comparing a received LSA to its    database copy.    This comparison
  7265.     must also be done during the Database Exchange procedure which
  7266.     occurs during adjacency    bring-up.
  7267.  
  7268.     An LSA is identified by    its LS type, Link State    ID and
  7269.     Advertising Router.  For two instances of the same LSA,    the LS
  7270.     sequence number, LS age, and LS    checksum fields    are used to
  7271.     determine which    instance is more recent:
  7272.  
  7273.  
  7274.     o   The    LSA having the newer LS    sequence number    is more    recent.
  7275.         See    Section    12.1.6 for an explanation of the LS sequence
  7276.         number space.  If both instances have the same LS sequence
  7277.         number, then:
  7278.  
  7279.     o   If the two instances have different    LS checksums, then the
  7280.         instance having the    larger LS checksum (when considered as a
  7281.         16-bit unsigned integer) is    considered more    recent.
  7282.  
  7283.     o   Else, if only one of the instances has its LS age field set
  7284.         to MaxAge, the instance of age MaxAge is considered    to be
  7285.         more recent.
  7286.  
  7287.     o   Else, if the LS age    fields of the two instances differ by
  7288.         more than MaxAgeDiff, the instance having the smaller
  7289.         (younger) LS age is    considered to be more recent.
  7290.  
  7291.     o   Else, the two instances are    considered to be identical.
  7292.  
  7293.  
  7294.  
  7295.  
  7296.  
  7297.  
  7298.  
  7299.  
  7300. Moy                Standards Track              [Page 146]
  7301.  
  7302. RFC 2328             OSPF Version 2              April 1998
  7303.  
  7304.  
  7305.     13.2.  Installing LSAs in the database
  7306.  
  7307.     Installing a new LSA in    the database, either as    the result of
  7308.     flooding or a newly self-originated LSA, may cause the OSPF
  7309.     routing    table structure    to be recalculated.  The contents of the
  7310.     new LSA    should be compared to the old instance,    if present.  If
  7311.     there is no difference,    there is no need to recalculate    the
  7312.     routing    table. When comparing an LSA to    its previous instance,
  7313.     the following are all considered to be differences in contents:
  7314.  
  7315.         o    The LSA's Options field    has changed.
  7316.  
  7317.         o    One of the LSA instances has LS    age set    to MaxAge, and
  7318.         the other does not.
  7319.  
  7320.         o    The length field in the    LSA header has changed.
  7321.  
  7322.         o    The body of the    LSA (i.e., anything outside the    20-byte
  7323.         LSA header) has    changed. Note that this    excludes changes
  7324.         in LS Sequence Number and LS Checksum.
  7325.  
  7326.     If the contents    are different, the following pieces of the
  7327.     routing    table must be recalculated, depending on the new LSA's
  7328.     LS type    field:
  7329.  
  7330.  
  7331.     Router-LSAs and    network-LSAs
  7332.         The    entire routing table must be recalculated, starting with
  7333.         the    shortest path calculations for each area (not just the
  7334.         area whose link-state database has changed).  The reason
  7335.         that the shortest path calculation cannot be restricted to
  7336.         the    single changed area has    to do with the fact that AS
  7337.         boundary routers may belong    to multiple areas.  A change in
  7338.         the    area currently providing the best route    may force the
  7339.         router to use an intra-area    route provided by a different
  7340.         area.[19]
  7341.  
  7342.     Summary-LSAs
  7343.         The    best route to the destination described    by the summary-
  7344.         LSA    must be    recalculated (see Section 16.5).  If this
  7345.         destination    is an AS boundary router, it may also be
  7346.         necessary to re-examine all    the AS-external-LSAs.
  7347.  
  7348.  
  7349.  
  7350. Moy                Standards Track              [Page 147]
  7351.  
  7352. RFC 2328             OSPF Version 2              April 1998
  7353.  
  7354.  
  7355.     AS-external-LSAs
  7356.         The    best route to the destination described    by the AS-
  7357.         external-LSA must be recalculated (see Section 16.6).
  7358.  
  7359.  
  7360.     Also, any old instance of the LSA must be removed from the
  7361.     database when the new LSA is installed.     This old instance must
  7362.     also be    removed    from all neighbors' Link state retransmission
  7363.     lists (see Section 10).
  7364.  
  7365.  
  7366.     13.3.  Next    step in    the flooding procedure
  7367.  
  7368.     When a new (and    more recent) LSA has been received, it must be
  7369.     flooded    out some set of    the router's interfaces.  This section
  7370.     describes the second part of flooding procedure    (the first part
  7371.     being the processing that occurred in Section 13), namely,
  7372.     selecting the outgoing interfaces and adding the LSA to    the
  7373.     appropriate neighbors' Link state retransmission lists.     Also
  7374.     included in this part of the flooding procedure    is the
  7375.     maintenance of the neighbors' Link state request lists.
  7376.  
  7377.     This section is    equally    applicable to the flooding of an LSA
  7378.     that the router    itself has just    originated (see    Section    12.4).
  7379.     For these LSAs,    this section provides the entirety of the
  7380.     flooding procedure (i.e., the processing of Section 13 is not
  7381.     performed, since, for example, the LSA has not been received
  7382.     from a neighbor    and therefore does not need to be acknowledged).
  7383.  
  7384.     Depending upon the LSA's LS type, the LSA can be flooded out
  7385.     only certain interfaces.  These    interfaces, defined by the
  7386.     following, are called the eligible interfaces:
  7387.  
  7388.  
  7389.     AS-external-LSAs (LS Type = 5)
  7390.         AS-external-LSAs are flooded throughout the    entire AS, with
  7391.         the    exception of stub areas    (see Section 3.6).  The    eligible
  7392.         interfaces are all the router's interfaces,    excluding
  7393.         virtual links and those interfaces attaching to stub areas.
  7394.  
  7395.     All other LS types
  7396.         All    other types are    specific to a single area (Area    A).  The
  7397.  
  7398.  
  7399.  
  7400. Moy                Standards Track              [Page 148]
  7401.  
  7402. RFC 2328             OSPF Version 2              April 1998
  7403.  
  7404.  
  7405.         eligible interfaces    are all    those interfaces attaching to
  7406.         the    Area A.     If Area A is the backbone, this includes all
  7407.         the    virtual    links.
  7408.  
  7409.  
  7410.     Link state databases must remain synchronized over all
  7411.     adjacencies associated with the    above eligible interfaces.  This
  7412.     is accomplished    by executing the following steps on each
  7413.     eligible interface.  It    should be noted    that this procedure may
  7414.     decide not to flood an LSA out a particular interface, if there
  7415.     is a high probability that the attached    neighbors have already
  7416.     received the LSA.  However, in these cases the flooding
  7417.     procedure must be absolutely sure that the neighbors eventually
  7418.     do receive the LSA, so the LSA is still    added to each
  7419.     adjacency's Link state retransmission list.  For each eligible
  7420.     interface:
  7421.  
  7422.  
  7423.     (1) Each of the    neighbors attached to this interface are
  7424.         examined, to determine whether they    must receive the new
  7425.         LSA.  The following    steps are executed for each neighbor:
  7426.  
  7427.         (a)    If the neighbor    is in a    lesser state than Exchange, it
  7428.         does not participate in    flooding, and the next neighbor
  7429.         should be examined.
  7430.  
  7431.         (b)    Else, if the adjacency is not yet full (neighbor state
  7432.         is Exchange or Loading), examine the Link state    request
  7433.         list associated    with this adjacency.  If there is an
  7434.         instance of the    new LSA    on the list, it    indicates that
  7435.         the neighboring    router has an instance of the LSA
  7436.         already.  Compare the new LSA to the neighbor's    copy:
  7437.  
  7438.         o   If the new LSA is less recent, then    examine    the next
  7439.             neighbor.
  7440.  
  7441.         o   If the two copies are the same instance, then delete
  7442.             the    LSA from the Link state    request    list, and
  7443.             examine the    next neighbor.[20]
  7444.  
  7445.         o   Else, the new LSA is more recent.  Delete the LSA
  7446.             from the Link state    request    list.
  7447.  
  7448.  
  7449.  
  7450. Moy                Standards Track              [Page 149]
  7451.  
  7452. RFC 2328             OSPF Version 2              April 1998
  7453.  
  7454.  
  7455.         (c)    If the new LSA was received from this neighbor,    examine
  7456.         the next neighbor.
  7457.  
  7458.         (d)    At this    point we are not positive that the neighbor has
  7459.         an up-to-date instance of this new LSA.     Add the new LSA
  7460.         to the Link state retransmission list for the adjacency.
  7461.         This ensures that the flooding procedure is reliable;
  7462.         the LSA    will be    retransmitted at intervals until an
  7463.         acknowledgment is seen from the    neighbor.
  7464.  
  7465.     (2) The    router must now    decide whether to flood    the new    LSA out
  7466.         this interface.  If    in the previous    step, the LSA was NOT
  7467.         added to any of the    Link state retransmission lists, there
  7468.         is no need to flood    the LSA    out the    interface and the next
  7469.         interface should be    examined.
  7470.  
  7471.     (3) If the new LSA was received    on this    interface, and it was
  7472.         received from either the Designated    Router or the Backup
  7473.         Designated Router, chances are that    all the    neighbors have
  7474.         received the LSA already.  Therefore, examine the next
  7475.         interface.
  7476.  
  7477.     (4) If the new LSA was received    on this    interface, and the
  7478.         interface state is Backup (i.e., the router    itself is the
  7479.         Backup Designated Router), examine the next    interface.  The
  7480.         Designated Router will do the flooding on this interface.
  7481.         However, if    the Designated Router fails the    router (i.e.,
  7482.         the    Backup Designated Router) will end up retransmitting the
  7483.         updates.
  7484.  
  7485.     (5) If this step is reached, the LSA must be flooded out the
  7486.         interface.    Send a Link State Update packet    (including the
  7487.         new    LSA as contents) out the interface.  The LSA's LS age
  7488.         must be incremented    by InfTransDelay (which    must be    > 0)
  7489.         when it is copied into the outgoing    Link State Update packet
  7490.         (until the LS age field reaches the    maximum    value of
  7491.         MaxAge).
  7492.  
  7493.         On broadcast networks, the Link State Update packets are
  7494.         multicast.    The destination    IP address specified for the
  7495.         Link State Update Packet depends on    the state of the
  7496.         interface.    If the interface state is DR or    Backup,    the
  7497.  
  7498.  
  7499.  
  7500. Moy                Standards Track              [Page 150]
  7501.  
  7502. RFC 2328             OSPF Version 2              April 1998
  7503.  
  7504.  
  7505.         address AllSPFRouters should be used.  Otherwise, the
  7506.         address AllDRouters    should be used.
  7507.  
  7508.         On non-broadcast networks, separate    Link State Update
  7509.         packets must be sent, as unicasts, to each adjacent    neighbor
  7510.         (i.e., those in state Exchange or greater).     The destination
  7511.         IP addresses for these packets are the neighbors' IP
  7512.         addresses.
  7513.  
  7514.  
  7515.     13.4.  Receiving self-originated LSAs
  7516.  
  7517.     It is a    common occurrence for a    router to receive self-
  7518.     originated LSAs    via the    flooding procedure. A self-originated
  7519.     LSA is detected    when either 1) the LSA's Advertising Router is
  7520.     equal to the router's own Router ID or 2) the LSA is a network-
  7521.     LSA and    its Link State ID is equal to one of the router's own IP
  7522.     interface addresses.
  7523.  
  7524.     However, if the    received self-originated LSA is    newer than the
  7525.     last instance that the router actually originated, the router
  7526.     must take special action.  The reception of such an LSA
  7527.     indicates that there are LSAs in the routing domain that were
  7528.     originated by the router before    the last time it was restarted.
  7529.     In most    cases, the router must then advance the    LSA's LS
  7530.     sequence number    one past the received LS sequence number, and
  7531.     originate a new    instance of the    LSA.
  7532.  
  7533.     It may be the case the router no longer    wishes to originate the
  7534.     received LSA. Possible examples    include: 1) the    LSA is a
  7535.     summary-LSA or AS-external-LSA and the router no longer    has an
  7536.     (advertisable) route to    the destination, 2) the    LSA is a
  7537.     network-LSA but    the router is no longer    Designated Router for
  7538.     the network or 3) the LSA is a network-LSA whose Link State ID
  7539.     is one of the router's own IP interface    addresses but whose
  7540.     Advertising Router is not equal    to the router's    own Router ID
  7541.     (this latter case should be rare, and it indicates that    the
  7542.     router's Router    ID has changed since originating the LSA).  In
  7543.     all these cases, instead of updating the LSA, the LSA should be
  7544.     flushed    from the routing domain    by incrementing    the received
  7545.     LSA's LS age to    MaxAge and reflooding (see Section 14.1).
  7546.  
  7547.  
  7548.  
  7549.  
  7550. Moy                Standards Track              [Page 151]
  7551.  
  7552. RFC 2328             OSPF Version 2              April 1998
  7553.  
  7554.  
  7555.     13.5.  Sending Link    State Acknowledgment packets
  7556.  
  7557.     Each newly received LSA    must be    acknowledged.  This is usually
  7558.     done by    sending    Link State Acknowledgment packets.  However,
  7559.     acknowledgments    can also be accomplished implicitly by sending
  7560.     Link State Update packets (see step 7a of Section 13).
  7561.  
  7562.     Many acknowledgments may be grouped together into a single Link
  7563.     State Acknowledgment packet.  Such a packet is sent back out the
  7564.     interface which    received the LSAs.  The    packet can be sent in
  7565.     one of two ways: delayed and sent on an    interval timer,    or sent
  7566.     directly to a particular neighbor.  The    particular
  7567.     acknowledgment strategy    used depends on    the circumstances
  7568.     surrounding the    receipt    of the LSA.
  7569.  
  7570.     Sending    delayed    acknowledgments    accomplishes several things: 1)
  7571.     it facilitates the packaging of    multiple acknowledgments in a
  7572.     single Link State Acknowledgment packet, 2) it enables a single
  7573.     Link State Acknowledgment packet to indicate acknowledgments to
  7574.     several    neighbors at once (through multicasting) and 3)    it
  7575.     randomizes the Link State Acknowledgment packets sent by the
  7576.     various    routers    attached to a common network.  The fixed
  7577.     interval between a router's delayed transmissions must be short
  7578.     (less than RxmtInterval) or needless retransmissions will ensue.
  7579.  
  7580.     Direct acknowledgments are sent    directly to a particular
  7581.     neighbor in response to    the receipt of duplicate LSAs. Direct
  7582.     acknowledgments    are sent immediately when the duplicate    is
  7583.     received. On multi-access networks, these acknowledgments are
  7584.     sent directly to the neighbor's    IP address.
  7585.  
  7586.     The precise procedure for sending Link State Acknowledgment
  7587.     packets    is described in    Table 19.  The circumstances surrounding
  7588.     the receipt of the LSA are listed in the left column.  The
  7589.     acknowledgment action then taken is listed in one of the two
  7590.     right columns.    This action depends on the state of the
  7591.     concerned interface; interfaces    in state Backup    behave
  7592.     differently from interfaces in all other states.  Delayed
  7593.     acknowledgments    must be    delivered to all adjacent routers
  7594.     associated with    the interface.    On broadcast networks, this is
  7595.     accomplished by    sending    the delayed Link State Acknowledgment
  7596.     packets    as multicasts.    The Destination    IP address used    depends
  7597.  
  7598.  
  7599.  
  7600. Moy                Standards Track              [Page 152]
  7601.  
  7602. RFC 2328             OSPF Version 2              April 1998
  7603.  
  7604.  
  7605.  
  7606.  
  7607.  
  7608.  
  7609.                      Action taken in state
  7610.    Circumstances        Backup          All other states
  7611.    _________________________________________________________________
  7612.    LSA    has            No    acknowledgment      No  acknowledgment
  7613.    been     flooded back        sent.          sent.
  7614.    out receiving  in-
  7615.    terface  (see Sec-
  7616.    tion    13, step 5b).
  7617.    _________________________________________________________________
  7618.    LSA     is            Delayed acknowledg-      Delayed    ack-
  7619.    more     recent     than        ment sent if adver-      nowledgment sent.
  7620.    database copy, but        tisement   received
  7621.    was     not  flooded        from    Designated
  7622.    back    out receiving        Router,  otherwise
  7623.    interface            do nothing
  7624.    _________________________________________________________________
  7625.    LSA is a            Delayed acknowledg-      No  acknowledgment
  7626.    duplicate, and was        ment sent if adver-      sent.
  7627.    treated as an  im-        tisement   received
  7628.    plied  acknowledg-        from    Designated
  7629.    ment    (see  Section        Router,  otherwise
  7630.    13, step 7a).        do nothing
  7631.    _________________________________________________________________
  7632.    LSA is a            Direct acknowledg-      Direct acknowledg-
  7633.    duplicate, and was        ment sent.          ment sent.
  7634.    not treated as  an
  7635.    implied     ack-
  7636.    nowledgment.
  7637.    _________________________________________________________________
  7638.    LSA's LS            Direct acknowledg-      Direct acknowledg-
  7639.    age is equal    to        ment sent.          ment sent.
  7640.    MaxAge, and there is
  7641.    no current instance
  7642.    of the LSA
  7643.    in the link state
  7644.    database, and none
  7645.    of router's neighbors
  7646.    are in states Exchange
  7647.  
  7648.  
  7649.  
  7650. Moy                Standards Track              [Page 153]
  7651.  
  7652. RFC 2328             OSPF Version 2              April 1998
  7653.  
  7654.  
  7655.    or Loading (see
  7656.    Section 13, step 4).
  7657.  
  7658.  
  7659.          Table 19: Sending link state acknowledgements.
  7660.  
  7661.  
  7662.  
  7663.  
  7664.     on the state of    the interface.    If the interface state is DR or
  7665.     Backup,    the destination    AllSPFRouters is used.    In all other
  7666.     states,    the destination    AllDRouters is used.  On non-broadcast
  7667.     networks, delayed Link State Acknowledgment packets must be
  7668.     unicast    separately over    each adjacency (i.e., neighbor whose
  7669.     state is >= Exchange).
  7670.  
  7671.     The reasoning behind sending the above packets as multicasts is
  7672.     best explained by an example.  Consider    the network
  7673.     configuration depicted in Figure 15.  Suppose RT4 has been
  7674.     elected    as Designated Router, and RT3 as Backup    Designated
  7675.     Router for the network N3.  When Router    RT4 floods a new LSA to
  7676.     Network    N3, it is received by routers RT1, RT2,    and RT3.  These
  7677.     routers    will not flood the LSA back onto net N3, but they still
  7678.     must ensure that their link-state databases remain synchronized
  7679.     with their adjacent neighbors.    So RT1,    RT2, and RT4 are waiting
  7680.     to see an acknowledgment from RT3.  Likewise, RT4 and RT3 are
  7681.     both waiting to    see acknowledgments from RT1 and RT2.  This is
  7682.     best achieved by sending the acknowledgments as    multicasts.
  7683.  
  7684.     The reason that    the acknowledgment logic for Backup DRs    is
  7685.     slightly different is because they perform differently during
  7686.     the flooding of    LSAs (see Section 13.3,    step 4).
  7687.  
  7688.  
  7689.  
  7690.     13.6.  Retransmitting LSAs
  7691.  
  7692.     LSAs flooded out an adjacency are placed on the    adjacency's Link
  7693.     state retransmission list.  In order to    ensure that flooding is
  7694.     reliable, these    LSAs are retransmitted until they are
  7695.     acknowledged.  The length of time between retransmissions is a
  7696.     configurable per-interface value, RxmtInterval.     If this is set
  7697.  
  7698.  
  7699.  
  7700. Moy                Standards Track              [Page 154]
  7701.  
  7702. RFC 2328             OSPF Version 2              April 1998
  7703.  
  7704.  
  7705.     too low    for an interface, needless retransmissions will    ensue.
  7706.     If the value is    set too    high, the speed    of the flooding, in the
  7707.     face of    lost packets, may be affected.
  7708.  
  7709.     Several    retransmitted LSAs may fit into    a single Link State
  7710.     Update packet.    When LSAs are to be retransmitted, only    the
  7711.     number fitting in a single Link    State Update packet should be
  7712.     sent.  Another packet of retransmissions can be    sent whenever
  7713.     some of    the LSAs are acknowledged, or on the next firing of the
  7714.     retransmission timer.
  7715.  
  7716.     Link State Update Packets carrying retransmissions are always
  7717.     sent directly to the neighbor. On multi-access networks, this
  7718.     means that retransmissions are sent directly to    the neighbor's
  7719.     IP address.  Each LSA's    LS age must be incremented by
  7720.     InfTransDelay (which must be > 0) when it is copied into the
  7721.     outgoing Link State Update packet (until the LS    age field
  7722.     reaches    the maximum value of MaxAge).
  7723.  
  7724.     If an adjacent router goes down, retransmissions may occur until
  7725.     the adjacency is destroyed by OSPF's Hello Protocol.  When the
  7726.     adjacency is destroyed,    the Link state retransmission list is
  7727.     cleared.
  7728.  
  7729.  
  7730.     13.7.  Receiving link state    acknowledgments
  7731.  
  7732.     Many consistency checks    have been made on a received Link State
  7733.     Acknowledgment packet before it    is handed to the flooding
  7734.     procedure.  In particular, it has been associated with a
  7735.     particular neighbor.  If this neighbor is in a lesser state than
  7736.     Exchange, the Link State Acknowledgment    packet is discarded.
  7737.  
  7738.     Otherwise, for each acknowledgment in the Link State
  7739.     Acknowledgment packet, the following steps are performed:
  7740.  
  7741.  
  7742.     o   Does the LSA acknowledged have an instance on the Link state
  7743.         retransmission list    for the    neighbor?  If not, examine the
  7744.         next acknowledgment.  Otherwise:
  7745.  
  7746.  
  7747.  
  7748.  
  7749.  
  7750. Moy                Standards Track              [Page 155]
  7751.  
  7752. RFC 2328             OSPF Version 2              April 1998
  7753.  
  7754.  
  7755.     o   If the acknowledgment is for the same instance that    is
  7756.         contained on the list, remove the item from    the list and
  7757.         examine the    next acknowledgment.  Otherwise:
  7758.  
  7759.     o   Log    the questionable acknowledgment, and examine the next
  7760.         one.
  7761.  
  7762.  
  7763. 14.  Aging The Link State Database
  7764.  
  7765.     Each LSA has an LS age field.  The LS age is expressed in seconds.
  7766.     An LSA's LS    age field is incremented while it is contained in a
  7767.     router's database.    Also, when copied into a Link State Update
  7768.     Packet for flooding    out a particular interface, the    LSA's LS age is
  7769.     incremented    by InfTransDelay.
  7770.  
  7771.     An LSA's LS    age is never incremented past the value    MaxAge.     LSAs
  7772.     having age MaxAge are not used in the routing table    calculation.  As
  7773.     a router ages its link state database, an LSA's LS age may reach
  7774.     MaxAge.[21]    At this    time, the router must attempt to flush the LSA
  7775.     from the routing domain.  This is done simply by reflooding    the
  7776.     MaxAge LSA just as if it was a newly originated LSA    (see Section
  7777.     13.3).
  7778.  
  7779.     When creating a Database summary list for a    newly forming adjacency,
  7780.     any    MaxAge LSAs present in the link    state database are added to the
  7781.     neighbor's Link state retransmission list instead of the neighbor's
  7782.     Database summary list.  See    Section    10.3 for more details.
  7783.  
  7784.     A MaxAge LSA must be removed immediately from the router's link
  7785.     state database as soon as both a) it is no longer contained    on any
  7786.     neighbor Link state    retransmission lists and b) none of the    router's
  7787.     neighbors are in states Exchange or    Loading.
  7788.  
  7789.     When, in the process of aging the link state database, an LSA's LS
  7790.     age    hits a multiple    of CheckAge, its LS checksum should be verified.
  7791.     If the LS checksum is incorrect, a program or memory error has been
  7792.     detected, and at the very least the    router itself should be
  7793.     restarted.
  7794.  
  7795.  
  7796.  
  7797.  
  7798.  
  7799.  
  7800. Moy                Standards Track              [Page 156]
  7801.  
  7802. RFC 2328             OSPF Version 2              April 1998
  7803.  
  7804.  
  7805.     14.1.  Premature aging of LSAs
  7806.  
  7807.     An LSA can be flushed from the routing domain by setting its LS
  7808.     age to MaxAge, while leaving its LS sequence number alone, and
  7809.     then reflooding    the LSA.  This procedure follows the same course
  7810.     as flushing an LSA whose LS age    has naturally reached the value
  7811.     MaxAge (see Section 14).  In particular, the MaxAge LSA    is
  7812.     removed    from the router's link state database as soon as a) it
  7813.     is no longer contained on any neighbor Link state retransmission
  7814.     lists and b) none of the router's neighbors are    in states
  7815.     Exchange or Loading.  We call the setting of an    LSA's LS age to
  7816.     MaxAge "premature aging".
  7817.  
  7818.     Premature aging    is used    when it    is time    for a self-originated
  7819.     LSA's sequence number field to wrap.  At this point, the current
  7820.     LSA instance (having LS    sequence number    MaxSequenceNumber) must
  7821.     be prematurely aged and    flushed    from the routing domain    before a
  7822.     new instance with sequence number equal    to InitialSequenceNumber
  7823.     can be originated.  See    Section    12.1.6 for more    information.
  7824.  
  7825.     Premature aging    can also be used when, for example, one    of the
  7826.     router's previously advertised external    routes is no longer
  7827.     reachable.  In this circumstance, the router can flush its AS-
  7828.     external-LSA from the routing domain via premature aging. This
  7829.     procedure is preferable    to the alternative, which is to
  7830.     originate a new    LSA for    the destination    specifying a metric of
  7831.     LSInfinity.  Premature aging is    also be    used when unexpectedly
  7832.     receiving self-originated LSAs during the flooding procedure
  7833.     (see Section 13.4).
  7834.  
  7835.     A router may only prematurely age its own self-originated LSAs.
  7836.     The router may not prematurely age LSAs    that have been
  7837.     originated by other routers. An    LSA is considered self-
  7838.     originated when    either 1) the LSA's Advertising    Router is equal
  7839.     to the router's    own Router ID or 2) the    LSA is a network-LSA and
  7840.     its Link State ID is equal to one of the router's own IP
  7841.     interface addresses.
  7842.  
  7843.  
  7844.  
  7845.  
  7846.  
  7847.  
  7848.  
  7849.  
  7850. Moy                Standards Track              [Page 157]
  7851.  
  7852. RFC 2328             OSPF Version 2              April 1998
  7853.  
  7854.  
  7855. 15.  Virtual Links
  7856.  
  7857.     The    single backbone    area (Area ID =    0.0.0.0) cannot    be disconnected,
  7858.     or some areas of the Autonomous System will    become unreachable.  To
  7859.     establish/maintain connectivity of the backbone, virtual links can
  7860.     be configured through non-backbone areas.  Virtual links serve to
  7861.     connect physically separate    components of the backbone.  The two
  7862.     endpoints of a virtual link    are area border    routers.  The virtual
  7863.     link must be configured in both routers.  The configuration
  7864.     information    in each    router consists    of the other virtual endpoint
  7865.     (the other area border router), and    the non-backbone area the two
  7866.     routers have in common (called the Transit area).  Virtual links
  7867.     cannot be configured through stub areas (see Section 3.6).
  7868.  
  7869.     The    virtual    link is    treated    as if it were an unnumbered point-to-
  7870.     point network belonging to the backbone and    joining    the two    area
  7871.     border routers.  An    attempt    is made    to establish an    adjacency over
  7872.     the    virtual    link.  When this adjacency is established, the virtual
  7873.     link will be included in backbone router-LSAs, and OSPF packets
  7874.     pertaining to the backbone area will flow over the adjacency.  Such
  7875.     an adjacency has been referred to in this document as a "virtual
  7876.     adjacency".
  7877.  
  7878.     In each endpoint router, the cost and viability of the virtual link
  7879.     is discovered by examining the routing table entry for the other
  7880.     endpoint router.  (The entry's associated area must    be the
  7881.     configured Transit area).  This is called the virtual link's
  7882.     corresponding routing table    entry.    The InterfaceUp    event occurs for
  7883.     a virtual link when    its corresponding routing table    entry becomes
  7884.     reachable.    Conversely, the    InterfaceDown event occurs when    its
  7885.     routing table entry    becomes    unreachable.  In other words, the
  7886.     virtual link's viability is    determined by the existence of an
  7887.     intra-area path, through the Transit area, between the two
  7888.     endpoints.    Note that a virtual link whose underlying path has cost
  7889.     greater than hexadecimal 0xffff (the maximum size of an interface
  7890.     cost in a router-LSA) should be considered inoperational (i.e.,
  7891.     treated the    same as    if the path did    not exist).
  7892.  
  7893.     The    other details concerning virtual links are as follows:
  7894.  
  7895.     o    AS-external-LSAs are NEVER flooded over    virtual    adjacencies.
  7896.     This would be duplication of effort, since the same AS-
  7897.  
  7898.  
  7899.  
  7900. Moy                Standards Track              [Page 158]
  7901.  
  7902. RFC 2328             OSPF Version 2              April 1998
  7903.  
  7904.  
  7905.     external-LSAs are already flooded throughout the virtual link's
  7906.     Transit    area.  For this    same reason, AS-external-LSAs are not
  7907.     summarized over    virtual    adjacencies during the Database    Exchange
  7908.     process.
  7909.  
  7910.     o    The cost of a virtual link is NOT configured.  It is defined to
  7911.     be the cost of the intra-area path between the two defining area
  7912.     border routers.     This cost appears in the virtual link's
  7913.     corresponding routing table entry.  When the cost of a virtual
  7914.     link changes, a    new router-LSA should be originated for    the
  7915.     backbone area.
  7916.  
  7917.     o    Just as    the virtual link's cost    and viability are determined by
  7918.     the routing table build    process    (through construction of the
  7919.     routing    table entry for    the other endpoint), so    are the    IP
  7920.     interface address for the virtual interface and    the virtual
  7921.     neighbor's IP address.    These are used when sending OSPF
  7922.     protocol packets over the virtual link.    Note that when one (or
  7923.     both) of the virtual link endpoints connect to the Transit area
  7924.     via an unnumbered point-to-point link, it may be impossible to
  7925.     calculate either the virtual interface's IP address and/or the
  7926.     virtual    neighbor's IP address, thereby causing the virtual link
  7927.     to fail.
  7928.  
  7929.     o    In each    endpoint's router-LSA for the backbone,    the virtual link
  7930.     is represented as a Type 4 link    whose Link ID is set to    the
  7931.     virtual    neighbor's OSPF    Router ID and whose Link Data is set to
  7932.     the virtual interface's    IP address.  See Section 12.4.1    for more
  7933.     information.
  7934.  
  7935.     o    A non-backbone area can    carry transit data traffic (i.e., is
  7936.     considered a "transit area") if    and only if it serves as the
  7937.     Transit    area for one or    more fully adjacent virtual links (see
  7938.     TransitCapability in Sections 6    and 16.1). Such    an area    requires
  7939.     special    treatment when summarizing backbone networks into it
  7940.     (see Section 12.4.3), and during the routing calculation (see
  7941.     Section    16.3).
  7942.  
  7943.     o    The time between link state retransmissions, RxmtInterval, is
  7944.     configured for a virtual link.    This should be well over the
  7945.     expected round-trip delay between the two routers.  This may be
  7946.  
  7947.  
  7948.  
  7949.  
  7950. Moy                Standards Track              [Page 159]
  7951.  
  7952. RFC 2328             OSPF Version 2              April 1998
  7953.  
  7954.  
  7955.     hard to    estimate for a virtual link; it    is better to err on the
  7956.     side of    making it too large.
  7957.  
  7958.  
  7959. 16.  Calculation of the    routing    table
  7960.  
  7961.     This section details the OSPF routing table    calculation.  Using its
  7962.     attached areas' link state databases as input, a router runs the
  7963.     following algorithm, building its routing table step by step.  At
  7964.     each step, the router must access individual pieces    of the link
  7965.     state databases (e.g., a router-LSA    originated by a    certain    router).
  7966.     This access    is performed by    the lookup function discussed in Section
  7967.     12.2.  The lookup process may return an LSA    whose LS age is    equal to
  7968.     MaxAge.  Such an LSA should    not be used in the routing table
  7969.     calculation, and is    treated    just as    if the lookup process had
  7970.     failed.
  7971.  
  7972.     The    OSPF routing table's organization is explained in Section 11.
  7973.     Two    examples of the    routing    table build process are    presented in
  7974.     Sections 11.2 and 11.3.  This process can be broken    into the
  7975.     following steps:
  7976.  
  7977.     (1)    The present routing table is invalidated.  The routing table is
  7978.     built again from scratch.  The old routing table is saved so
  7979.     that changes in    routing    table entries can be identified.
  7980.  
  7981.     (2)    The intra-area routes are calculated by    building the shortest-
  7982.     path tree for each attached area.  In particular, all routing
  7983.     table entries whose Destination    Type is    "area border router" are
  7984.     calculated in this step.  This step is described in two    parts.
  7985.     At first the tree is constructed by only considering those links
  7986.     between    routers    and transit networks.  Then the    stub networks
  7987.     are incorporated into the tree.    During the area's shortest-path
  7988.     tree calculation, the area's TransitCapability is also
  7989.     calculated for later use in Step 4.
  7990.  
  7991.     (3)    The inter-area routes are calculated, through examination of
  7992.     summary-LSAs.  If the router is    attached to multiple areas
  7993.     (i.e., it is an    area border router), only backbone summary-LSAs
  7994.     are examined.
  7995.  
  7996.  
  7997.  
  7998.  
  7999.  
  8000. Moy                Standards Track              [Page 160]
  8001.  
  8002. RFC 2328             OSPF Version 2              April 1998
  8003.  
  8004.  
  8005.     (4)    In area    border routers connecting to one or more transit areas
  8006.     (i.e, non-backbone areas whose TransitCapability is found to be
  8007.     TRUE), the transit areas' summary-LSAs are examined to see
  8008.     whether    better paths exist using the transit areas than    were
  8009.     found in Steps 2-3 above.
  8010.  
  8011.     (5)    Routes to external destinations    are calculated,    through
  8012.     examination of AS-external-LSAs.  The locations    of the AS
  8013.     boundary routers (which    originate the AS-external-LSAs)    have
  8014.     been determined    in steps 2-4.
  8015.  
  8016.  
  8017.     Steps 2-5 are explained in further detail below.
  8018.  
  8019.     Changes made to routing table entries as a result of these
  8020.     calculations can cause the OSPF protocol to    take further actions.
  8021.     For    example, a change to an    intra-area route will cause an area
  8022.     border router to originate new summary-LSAs    (see Section 12.4).  See
  8023.     Section 16.7 for a complete    list of    the OSPF protocol actions
  8024.     resulting from routing table changes.
  8025.  
  8026.  
  8027.     16.1.  Calculating the shortest-path tree for an area
  8028.  
  8029.     This calculation yields    the set    of intra-area routes associated
  8030.     with an    area (called hereafter Area A).     A router calculates the
  8031.     shortest-path tree using itself    as the root.[22] The formation
  8032.     of the shortest    path tree is done here in two stages.  In the
  8033.     first stage, only links    between    routers    and transit networks are
  8034.     considered.  Using the Dijkstra    algorithm, a tree is formed from
  8035.     this subset of the link    state database.     In the    second stage,
  8036.     leaves are added to the    tree by    considering the    links to stub
  8037.     networks.
  8038.  
  8039.     The procedure will be explained    using the graph    terminology that
  8040.     was introduced in Section 2.  The area's link state database is
  8041.     represented as a directed graph.  The graph's vertices are
  8042.     routers, transit networks and stub networks.  The first    stage of
  8043.     the procedure concerns only the    transit    vertices (routers and
  8044.     transit    networks) and their connecting links.  Throughout the
  8045.     shortest path calculation, the following data is also associated
  8046.     with each transit vertex:
  8047.  
  8048.  
  8049.  
  8050. Moy                Standards Track              [Page 161]
  8051.  
  8052. RFC 2328             OSPF Version 2              April 1998
  8053.  
  8054.  
  8055.     Vertex (node) ID
  8056.         A 32-bit number which together with    the vertex type    (router
  8057.         or network)    uniquely identifies the    vertex.     For router
  8058.         vertices the Vertex    ID is the router's OSPF    Router ID.  For
  8059.         network vertices, it is the    IP address of the network's
  8060.         Designated Router.
  8061.  
  8062.     An LSA
  8063.         Each transit vertex    has an associated LSA.    For router
  8064.         vertices, this is a    router-LSA.  For transit networks, this
  8065.         is a network-LSA (which is actually    originated by the
  8066.         network's Designated Router).  In any case,    the LSA's Link
  8067.         State ID is    always equal to    the above Vertex ID.
  8068.  
  8069.     List of    next hops
  8070.         The    list of    next hops for the current set of shortest paths
  8071.         from the root to this vertex.  There can be    multiple
  8072.         shortest paths due to the equal-cost multipath capability.
  8073.         Each next hop indicates the    outgoing router    interface to use
  8074.         when forwarding traffic to the destination.     On broadcast,
  8075.         Point-to-MultiPoint    and NBMA networks, the next hop    also
  8076.         includes the IP address of the next    router (if any)    in the
  8077.         path towards the destination.
  8078.  
  8079.     Distance from root
  8080.         The    link state cost    of the current set of shortest paths
  8081.         from the root to the vertex.  The link state cost of a path
  8082.         is calculated as the sum of    the costs of the path's
  8083.         constituent    links (as advertised in    router-LSAs and
  8084.         network-LSAs).  One    path is    said to    be "shorter" than
  8085.         another if it has a    smaller    link state cost.
  8086.  
  8087.  
  8088.     The first stage    of the procedure (i.e.,    the Dijkstra algorithm)
  8089.     can now    be summarized as follows. At each iteration of the
  8090.     algorithm, there is a list of candidate    vertices.  Paths from
  8091.     the root to these vertices have    been found, but    not necessarily
  8092.     the shortest ones.  However, the paths to the candidate    vertex
  8093.     that is    closest    to the root are    guaranteed to be shortest; this
  8094.     vertex is added    to the shortest-path tree, removed from    the
  8095.     candidate list,    and its    adjacent vertices are examined for
  8096.     possible addition to/modification of the candidate list.  The
  8097.  
  8098.  
  8099.  
  8100. Moy                Standards Track              [Page 162]
  8101.  
  8102. RFC 2328             OSPF Version 2              April 1998
  8103.  
  8104.  
  8105.     algorithm then iterates    again.    It terminates when the candidate
  8106.     list becomes empty.
  8107.  
  8108.     The following steps describe the algorithm in detail.  Remember
  8109.     that we    are computing the shortest path    tree for Area A.  All
  8110.     references to link state database lookup below are from    Area A's
  8111.     database.
  8112.  
  8113.     (1) Initialize the algorithm's data structures.     Clear the list
  8114.         of candidate vertices.  Initialize the shortest-path tree to
  8115.         only the root (which is the    router doing the calculation).
  8116.         Set    Area A's TransitCapability to FALSE.
  8117.  
  8118.     (2) Call the vertex just added to the tree vertex V.  Examine
  8119.         the    LSA associated with vertex V.  This is a lookup    in the
  8120.         Area A's link state    database based on the Vertex ID.  If
  8121.         this is a router-LSA, and bit V of the router-LSA (see
  8122.         Section A.4.2) is set, set Area A's    TransitCapability to
  8123.         TRUE.  In any case,    each link described by the LSA gives the
  8124.         cost to an adjacent    vertex.     For each described link, (say
  8125.         it joins vertex V to vertex    W):
  8126.  
  8127.         (a)    If this    is a link to a stub network, examine the next
  8128.         link in    V's LSA.  Links    to stub    networks will be
  8129.         considered in the second stage of the shortest path
  8130.         calculation.
  8131.  
  8132.         (b)    Otherwise, W is    a transit vertex (router or transit
  8133.         network).  Look    up the vertex W's LSA (router-LSA or
  8134.         network-LSA) in    Area A's link state database.  If the
  8135.         LSA does not exist, or its LS age is equal to MaxAge, or
  8136.         it does    not have a link    back to    vertex V, examine the
  8137.         next link in V's LSA.[23]
  8138.  
  8139.         (c)    If vertex W is already on the shortest-path tree,
  8140.         examine    the next link in the LSA.
  8141.  
  8142.         (d)    Calculate the link state cost D    of the resulting path
  8143.         from the root to vertex    W.  D is equal to the sum of the
  8144.         link state cost    of the (already    calculated) shortest
  8145.         path to    vertex V and the advertised cost of the    link
  8146.         between    vertices V and W.  If D    is:
  8147.  
  8148.  
  8149.  
  8150. Moy                Standards Track              [Page 163]
  8151.  
  8152. RFC 2328             OSPF Version 2              April 1998
  8153.  
  8154.  
  8155.         o   Greater than the value that    already    appears    for
  8156.             vertex W on    the candidate list, then examine the
  8157.             next link.
  8158.  
  8159.         o   Equal to the value that appears for    vertex W on the
  8160.             candidate list, calculate the set of next hops that
  8161.             result from    using the advertised link.  Input to
  8162.             this calculation is    the destination    (W), and its
  8163.             parent (V).     This calculation is shown in Section
  8164.             16.1.1.  This set of hops should be    added to the
  8165.             next hop values that appear    for W on the candidate
  8166.             list.
  8167.  
  8168.         o   Less than the value    that appears for vertex    W on the
  8169.             candidate list, or if W does not yet appear    on the
  8170.             candidate list, then set the entry for W on    the
  8171.             candidate list to indicate a distance of D from the
  8172.             root.  Also    calculate the list of next hops    that
  8173.             result from    using the advertised link, setting the
  8174.             next hop values for    W accordingly.    The next hop
  8175.             calculation    is described in    Section    16.1.1;    it takes
  8176.             as input the destination (W) and its parent    (V).
  8177.  
  8178.     (3) If at this step the    candidate list is empty, the shortest-
  8179.         path tree (of transit vertices) has    been completely    built
  8180.         and    this stage of the procedure terminates.     Otherwise,
  8181.         choose the vertex belonging    to the candidate list that is
  8182.         closest to the root, and add it to the shortest-path tree
  8183.         (removing it from the candidate list in the    process). Note
  8184.         that when there is a choice    of vertices closest to the root,
  8185.         network vertices must be chosen before router vertices in
  8186.         order to necessarily find all equal-cost paths. This is
  8187.         consistent with the    tie-breakers that were introduced in the
  8188.         modified Dijkstra algorithm    used by    OSPF's Multicast routing
  8189.         extensions (MOSPF).
  8190.  
  8191.     (4) Possibly modify the    routing    table.    For those routing table
  8192.         entries modified, the associated area will be set to Area A,
  8193.         the    path type will be set to intra-area, and the cost will
  8194.         be set to the newly    discovered shortest path's calculated
  8195.         distance.
  8196.  
  8197.  
  8198.  
  8199.  
  8200. Moy                Standards Track              [Page 164]
  8201.  
  8202. RFC 2328             OSPF Version 2              April 1998
  8203.  
  8204.  
  8205.         If the newly added vertex is an area border    router or AS
  8206.         boundary router, a routing table entry is added whose
  8207.         destination    type is    "router".  The Options field found in
  8208.         the    associated router-LSA is copied    into the routing table
  8209.         entry's Optional capabilities field. Call the newly    added
  8210.         vertex Router X.  If Router    X is the endpoint of one of the
  8211.         calculating    router's virtual links,    and the    virtual    link
  8212.         uses Area A    as Transit area:  the virtual link is declared
  8213.         up,    the IP address of the virtual interface    is set to the IP
  8214.         address of the outgoing interface calculated above for
  8215.         Router X, and the virtual neighbor's IP address is set to
  8216.         Router X's interface address (contained in Router X's
  8217.         router-LSA)    that points back to the    root of    the shortest-
  8218.         path tree; equivalently, this is the interface that    points
  8219.         back to Router X's parent vertex on    the shortest-path tree
  8220.         (similar to    the calculation    in Section 16.1.1).
  8221.  
  8222.         If the newly added vertex is a transit network, the    routing
  8223.         table entry    for the    network    is located.  The entry's
  8224.         Destination    ID is the IP network number, which can be
  8225.         obtained by    masking    the Vertex ID (Link State ID) with its
  8226.         associated subnet mask (found in the body of the associated
  8227.         network-LSA).  If the routing table    entry already exists
  8228.         (i.e., there is already an intra-area route    to the
  8229.         destination    installed in the routing table), multiple
  8230.         vertices have mapped to the    same IP    network.  For example,
  8231.         this can occur when    a new Designated Router    is being
  8232.         established.  In this case,    the current routing table entry
  8233.         should be overwritten if and only if the newly found path is
  8234.         just as short and the current routing table    entry's    Link
  8235.         State Origin has a smaller Link State ID than the newly
  8236.         added vertex' LSA.
  8237.  
  8238.         If there is    no routing table entry for the network (the
  8239.         usual case), a routing table entry for the IP network should
  8240.         be added.  The routing table entry's Link State Origin
  8241.         should be set to the newly added vertex' LSA.
  8242.  
  8243.     (5) Iterate the    algorithm by returning to Step 2.
  8244.  
  8245.  
  8246.  
  8247.  
  8248.  
  8249.  
  8250. Moy                Standards Track              [Page 165]
  8251.  
  8252. RFC 2328             OSPF Version 2              April 1998
  8253.  
  8254.  
  8255.     The stub networks are added to the tree    in the procedure's
  8256.     second stage.  In this stage, all router vertices are again
  8257.     examined.  Those that have been    determined to be unreachable in
  8258.     the above first    phase are discarded.  For each reachable router
  8259.     vertex (call it    V), the    associated router-LSA is found in the
  8260.     link state database.  Each stub    network    link appearing in the
  8261.     LSA is then examined, and the following    steps are executed:
  8262.  
  8263.     (1) Calculate the distance D of    stub network from the root.  D
  8264.         is equal to    the distance from the root to the router vertex
  8265.         (calculated    in stage 1), plus the stub network link's
  8266.         advertised cost.  Compare this distance to the current best
  8267.         cost to the    stub network.  This is done by looking up the
  8268.         stub network's current routing table entry.     If the
  8269.         calculated distance    D is larger, go    on to examine the next
  8270.         stub network link in the LSA.
  8271.  
  8272.     (2) If this step is reached, the stub network's    routing    table
  8273.         entry must be updated.  Calculate the set of next hops that
  8274.         would result from using the    stub network link.  This
  8275.         calculation    is shown in Section 16.1.1; input to this
  8276.         calculation    is the destination (the    stub network) and the
  8277.         parent vertex (the router vertex).    If the distance    D is the
  8278.         same as the    current    routing    table cost, simply add this set
  8279.         of next hops to the    routing    table entry's list of next hops.
  8280.         In this case, the routing table already has    a Link State
  8281.         Origin.  If    this Link State    Origin is a router-LSA whose
  8282.         Link State ID is smaller than V's Router ID, reset the Link
  8283.         State Origin to V's    router-LSA.
  8284.  
  8285.         Otherwise D    is smaller than    the routing table cost.
  8286.         Overwrite the current routing table    entry by setting the
  8287.         routing table entry's cost to D, and by setting the    entry's
  8288.         list of next hops to the newly calculated set.  Set    the
  8289.         routing table entry's Link State Origin to V's router-LSA.
  8290.         Then go on to examine the next stub    network    link.
  8291.  
  8292.  
  8293.     For all    routing    table entries added/modified in    the second
  8294.     stage, the associated area will    be set to Area A and the path
  8295.     type will be set to intra-area.     When the list of reachable
  8296.     router-LSAs is exhausted, the second stage is completed.  At
  8297.  
  8298.  
  8299.  
  8300. Moy                Standards Track              [Page 166]
  8301.  
  8302. RFC 2328             OSPF Version 2              April 1998
  8303.  
  8304.  
  8305.     this time, all intra-area routes associated with Area A    have
  8306.     been determined.
  8307.  
  8308.     The specification does not require that    the above two stage
  8309.     method be used to calculate the    shortest path tree.  However, if
  8310.     another    algorithm is used, an identical    tree must be produced.
  8311.     For this reason, it is important to note that links between
  8312.     transit    vertices must be bidirectional in order    to be included
  8313.     in the above tree.  It should also be mentioned    that more
  8314.     efficient algorithms exist for calculating the tree; for
  8315.     example, the incremental SPF algorithm described in [Ref1].
  8316.  
  8317.  
  8318.     16.1.1.     The next hop calculation
  8319.  
  8320.         This section explains how to calculate the current set of
  8321.         next hops to use for a destination.     Each next hop consists
  8322.         of the outgoing interface to use in    forwarding packets to
  8323.         the    destination together with the IP address of the    next hop
  8324.         router (if any).  The next hop calculation is invoked each
  8325.         time a shorter path    to the destination is discovered.  This
  8326.         can    happen in either stage of the shortest-path tree
  8327.         calculation    (see Section 16.1).  In    stage 1    of the
  8328.         shortest-path tree calculation a shorter path is found as
  8329.         the    destination is added to    the candidate list, or when the
  8330.         destination's entry    on the candidate list is modified (Step
  8331.         2d of Stage    1).  In    stage 2    a shorter path is discovered
  8332.         each time the destination's    routing    table entry is modified
  8333.         (Step 2 of Stage 2).
  8334.  
  8335.         The    set of next hops to use    for the    destination may    be
  8336.         recalculated several times during the shortest-path    tree
  8337.         calculation, as shorter and    shorter    paths are discovered.
  8338.         In the end,    the destination's routing table    entry will
  8339.         always reflect the next hops resulting from    the absolute
  8340.         shortest path(s).
  8341.  
  8342.         Input to the next hop calculation is a) the    destination and
  8343.         b) its parent in the current shortest path between the root
  8344.         (the calculating router) and the destination.  The parent is
  8345.         always a transit vertex (i.e., always a router or a    transit
  8346.         network).
  8347.  
  8348.  
  8349.  
  8350. Moy                Standards Track              [Page 167]
  8351.  
  8352. RFC 2328             OSPF Version 2              April 1998
  8353.  
  8354.  
  8355.         If there is    at least one intervening router    in the current
  8356.         shortest path between the destination and the root,    the
  8357.         destination    simply inherits    the set    of next    hops from the
  8358.         parent.  Otherwise,    there are two cases.  In the first case,
  8359.         the    parent vertex is the root (the calculating router
  8360.         itself).  This means that the destination is either    a
  8361.         directly connected network or directly connected router.
  8362.         The    outgoing interface in this case    is simply the OSPF
  8363.         interface connecting to the    destination network/router. If
  8364.         the    destination is a router    which connects to the
  8365.         calculating    router via a Point-to-MultiPoint network, the
  8366.         destination's next hop IP address(es) can be determined by
  8367.         examining the destination's    router-LSA: each link pointing
  8368.         back to the    calculating router and having a    Link Data field
  8369.         belonging to the Point-to-MultiPoint network provides an IP
  8370.         address of the next    hop router. If the destination is a
  8371.         directly connected network,    or a router which connects to
  8372.         the    calculating router via a point-to-point    interface, no
  8373.         next hop IP    address    is required. If    the destination    is a
  8374.         router connected to    the calculating    router via a virtual
  8375.         link, the setting of the next hop should be    deferred until
  8376.         the    calculation in Section 16.3.
  8377.  
  8378.         In the second case,    the parent vertex is a network that
  8379.         directly connects the calculating router to    the destination
  8380.         router.  The list of next hops is then determined by
  8381.         examining the destination's    router-LSA.  For each link in
  8382.         the    router-LSA that    points back to the parent network, the
  8383.         link's Link    Data field provides the    IP address of a    next hop
  8384.         router.  The outgoing interface to use can then be derived
  8385.         from the next hop IP address (or it    can be inherited from
  8386.         the    parent network).
  8387.  
  8388.  
  8389.     16.2.  Calculating the inter-area routes
  8390.  
  8391.     The inter-area routes are calculated by    examining summary-LSAs.
  8392.     If the router has active attachments to    multiple areas,    only
  8393.     backbone summary-LSAs are examined.  Routers attached to a
  8394.     single area examine that area's    summary-LSAs.  In either case,
  8395.     the summary-LSAs examined below    are all    part of    a single area's
  8396.     link state database (call it Area A).
  8397.  
  8398.  
  8399.  
  8400. Moy                Standards Track              [Page 168]
  8401.  
  8402. RFC 2328             OSPF Version 2              April 1998
  8403.  
  8404.  
  8405.     Summary-LSAs are originated by the area    border routers.     Each
  8406.     summary-LSA in Area A is considered in turn.  Remember that the
  8407.     destination described by a summary-LSA is either a network (Type
  8408.     3 summary-LSAs)    or an AS boundary router (Type 4 summary-LSAs).
  8409.     For each summary-LSA:
  8410.  
  8411.  
  8412.     (1) If the cost    specified by the LSA is    LSInfinity, or if the
  8413.         LSA's LS age is equal to MaxAge, then examine the the next
  8414.         LSA.
  8415.  
  8416.     (2) If the LSA was originated by the calculating router    itself,
  8417.         examine the    next LSA.
  8418.  
  8419.     (3) If it is a Type 3 summary-LSA, and the collection of
  8420.         destinations described by the summary-LSA equals one of the
  8421.         router's configured    area address ranges (see Section 3.5),
  8422.         and    the particular area address range is active, then the
  8423.         summary-LSA    should be ignored.  "Active" means that    there
  8424.         are    one or more reachable (by intra-area paths) networks
  8425.         contained in the area range.
  8426.  
  8427.     (4) Else, call the destination described by the    LSA N (for Type
  8428.         3 summary-LSAs, N's    address    is obtained by masking the LSA's
  8429.         Link State ID with the network/subnet mask contained in the
  8430.         body of the    LSA), and the area border originating the LSA
  8431.         BR.     Look up the routing table entry for BR    having Area A as
  8432.         its    associated area.  If no    such entry exists for router BR
  8433.         (i.e., BR is unreachable in    Area A), do nothing with this
  8434.         LSA    and consider the next in the list.  Else, this LSA
  8435.         describes an inter-area path to destination    N, whose cost is
  8436.         the    distance to BR plus the    cost specified in the LSA. Call
  8437.         the    cost of    this inter-area    path IAC.
  8438.  
  8439.     (5) Next, look up the routing table entry for the destination N.
  8440.         (If    N is an    AS boundary router, look up the    "router" routing
  8441.         table entry    associated with    Area A).  If no    entry exists for
  8442.         N or if the    entry's    path type is "type 1 external" or "type
  8443.         2 external", then install the inter-area path to N,    with
  8444.         associated area Area A, cost IAC, next hop equal to    the list
  8445.         of next hops to router BR, and Advertising router equal to
  8446.         BR.
  8447.  
  8448.  
  8449.  
  8450. Moy                Standards Track              [Page 169]
  8451.  
  8452. RFC 2328             OSPF Version 2              April 1998
  8453.  
  8454.  
  8455.     (6) Else, if the paths present in the table are    intra-area
  8456.         paths, do nothing with the LSA (intra-area paths are always
  8457.         preferred).
  8458.  
  8459.     (7) Else, the paths present in the routing table are also
  8460.         inter-area paths.  Install the new path through BR if it is
  8461.         cheaper, overriding    the paths in the routing table.
  8462.         Otherwise, if the new path is the same cost, add it    to the
  8463.         list of paths that appear in the routing table entry.
  8464.  
  8465.     16.3.  Examining transit areas' summary-LSAs
  8466.  
  8467.     This step is only performed by area border routers attached to
  8468.     one or more non-backbone areas that are    capable    of carrying
  8469.     transit    traffic    (i.e., "transit    areas",    or those areas whose
  8470.     TransitCapability parameter has    been set to TRUE in Step 2 of
  8471.     the Dijkstra algorithm (see Section 16.1).
  8472.  
  8473.     The purpose of the calculation below is    to examine the transit
  8474.     areas to see whether they provide any better (shorter) paths
  8475.     than the paths previously calculated in    Sections 16.1 and 16.2.
  8476.     Any paths found    that are better    than or    equal to previously
  8477.     discovered paths are installed in the routing table.
  8478.  
  8479.     The calculation    also determines    the actual next    hop(s) for those
  8480.     destinations whose next    hop was    calculated as a    virtual    link in
  8481.     Sections 16.1 and 16.2.     After completion of the calculation
  8482.     below, any paths calculated in Sections    16.1 and 16.2 that still
  8483.     have unresolved    virtual    next hops should be discarded.
  8484.  
  8485.     The calculation    proceeds as follows. All the transit areas'
  8486.     summary-LSAs are examined in turn.  Each such summary-LSA
  8487.     describes a route through a transit area Area A    to a Network N
  8488.     (N's address is    obtained by masking the    LSA's Link State ID with
  8489.     the network/subnet mask    contained in the body of the LSA) or in
  8490.     the case of a Type 4 summary-LSA, to an    AS boundary router N.
  8491.     Suppose    also that the summary-LSA was originated by an area
  8492.     border router BR.
  8493.  
  8494.     (1) If the cost    advertised by the summary-LSA is LSInfinity, or
  8495.         if the LSA's LS age    is equal to MaxAge, then examine the
  8496.         next LSA.
  8497.  
  8498.  
  8499.  
  8500. Moy                Standards Track              [Page 170]
  8501.  
  8502. RFC 2328             OSPF Version 2              April 1998
  8503.  
  8504.  
  8505.     (2) If the summary-LSA was originated by the calculating router
  8506.         itself, examine the    next LSA.
  8507.  
  8508.     (3) Look up the    routing    table entry for    N. (If N is an AS
  8509.         boundary router, look up the "router" routing table    entry
  8510.         associated with the    backbone area).    If it does not exist, or
  8511.         if the route type is other than intra-area or inter-area, or
  8512.         if the area    associated with    the routing table entry    is not
  8513.         the    backbone area, then examine the    next LSA. In other
  8514.         words, this    calculation only updates backbone intra-area
  8515.         routes found in Section 16.1 and inter-area    routes found in
  8516.         Section 16.2.
  8517.  
  8518.     (4) Look up the    routing    table entry for    the advertising    router
  8519.         BR associated with the Area    A. If it is unreachable, examine
  8520.         the    next LSA. Otherwise, the cost to destination N is the
  8521.         sum    of the cost in BR's Area A routing table entry and the
  8522.         cost advertised in the LSA.    Call this cost IAC.
  8523.  
  8524.     (5) If this cost is less than the cost occurring in N's    routing
  8525.         table entry, overwrite N's list of next hops with those used
  8526.         for    BR, and    set N's    routing    table cost to IAC. Else, if IAC
  8527.         is the same    as N's current cost, add BR's list of next hops
  8528.         to N's list    of next    hops. In any case, the area associated
  8529.         with N's routing table entry must remain the backbone area,
  8530.         and    the path type (either intra-area or inter-area)    must
  8531.         also remain    the same.
  8532.  
  8533.     It is important    to note    that the above calculation never makes
  8534.     unreachable destinations reachable, but    instead    just potentially
  8535.     finds better paths to already reachable    destinations.  The
  8536.     calculation installs any better    cost found into    the routing
  8537.     table entry, from which    it may be readvertised in summary-LSAs
  8538.     to other areas.
  8539.  
  8540.     As an example of the calculation, consider the Autonomous System
  8541.     pictured in Figure 17.    There is a single non-backbone area
  8542.     (Area 1) that physically divides the backbone into two separate
  8543.     pieces.    To maintain connectivity of the    backbone, a virtual link
  8544.     has been configured between routers RT1    and RT4. On the    right
  8545.     side of    the figure, Network N1 belongs to the backbone.    The
  8546.     dotted lines indicate that there is a much shorter intra-area
  8547.  
  8548.  
  8549.  
  8550. Moy                Standards Track              [Page 171]
  8551.  
  8552. RFC 2328             OSPF Version 2              April 1998
  8553.  
  8554.  
  8555.  
  8556.               ........................
  8557.               .    Area 1 (transit)     .          +
  8558.               .                 .          |
  8559.               .         +---+1       1+---+100      |
  8560.               .         |RT2|----------|RT4|=========|
  8561.               .       1/+---+********* +---+      |
  8562.               .       /*******         .          |
  8563.               .     1/*Virtual         .          |
  8564.            1+---+/*  Link         .           Net|work
  8565.          =======|RT1|*             .          | N1
  8566.             +---+\             .          |
  8567.               .      \             .          |
  8568.               .       \             .          |
  8569.               .       1\+---+1       1+---+20      |
  8570.               .         |RT3|----------|RT5|=========|
  8571.               .         +---+        +---+      |
  8572.               .                 .          |
  8573.               ........................          +
  8574.  
  8575.             Figure 17: Routing through transit areas
  8576.  
  8577.     backbone path between router RT5 and Network N1    (cost 20) than
  8578.     there is between Router    RT4 and    Network    N1 (cost 100). Both
  8579.     Router RT4 and Router RT5 will inject summary-LSAs for Network
  8580.     N1 into    Area 1.
  8581.  
  8582.     After the shortest-path    tree has been calculated for the
  8583.     backbone in Section 16.1, Router RT1 (left end of the virtual
  8584.     link) will have    calculated a path through Router RT4 for all
  8585.     data traffic destined for Network N1. However, since Router RT5
  8586.     is so much closer to Network N1, all routers internal to Area 1
  8587.     (e.g., Routers RT2 and RT3) will forward their Network N1
  8588.     traffic    towards    Router RT5, instead of RT4. And    indeed,    after
  8589.     examining Area 1's summary-LSAs    by the above calculation, Router
  8590.     RT1 will also forward Network N1 traffic towards RT5. Note that
  8591.     in this    example    the virtual link enables transit data traffic to
  8592.     be forwarded through Area 1, but the actual path the transit
  8593.     data traffic takes does    not follow the virtual link.  In other
  8594.     words, virtual links allow transit traffic to be forwarded
  8595.     through    an area, but do    not dictate the    precise    path that the
  8596.     traffic    will take.
  8597.  
  8598.  
  8599.  
  8600. Moy                Standards Track              [Page 172]
  8601.  
  8602. RFC 2328             OSPF Version 2              April 1998
  8603.  
  8604.  
  8605.     16.4.  Calculating AS external routes
  8606.  
  8607.     AS external routes are calculated by examining AS-external-LSAs.
  8608.     Each of    the AS-external-LSAs is    considered in turn.  Most AS-
  8609.     external-LSAs describe routes to specific IP destinations.  An
  8610.     AS-external-LSA    can also describe a default route for the
  8611.     Autonomous System (Destination ID = DefaultDestination,
  8612.     network/subnet mask = 0x00000000).  For    each AS-external-LSA:
  8613.  
  8614.  
  8615.     (1) If the cost    specified by the LSA is    LSInfinity, or if the
  8616.         LSA's LS age is equal to MaxAge, then examine the next LSA.
  8617.  
  8618.     (2) If the LSA was originated by the calculating router    itself,
  8619.         examine the    next LSA.
  8620.  
  8621.     (3) Call the destination described by the LSA N.  N's address is
  8622.         obtained by    masking    the LSA's Link State ID    with the
  8623.         network/subnet mask    contained in the body of the LSA.  Look
  8624.         up the routing table entries (potentially one per attached
  8625.         area) for the AS boundary router (ASBR) that originated the
  8626.         LSA. If no entries exist for router    ASBR (i.e., ASBR is
  8627.         unreachable), do nothing with this LSA and consider    the next
  8628.         in the list.
  8629.  
  8630.         Else, this LSA describes an    AS external path to destination
  8631.         N.    Examine    the forwarding address specified in the    AS-
  8632.         external-LSA.  This    indicates the IP address to which
  8633.         packets for    the destination    should be forwarded.
  8634.  
  8635.         If the forwarding address is set to    0.0.0.0, packets should
  8636.         be sent to the ASBR    itself.    Among the multiple routing table
  8637.         entries for    the ASBR, select the preferred entry as    follows.
  8638.         If RFC1583Compatibility is set to "disabled", prune    the set
  8639.         of routing table entries for the ASBR as described in
  8640.         Section 16.4.1. In any case, among the remaining routing
  8641.         table entries, select the routing table entry with the least
  8642.         cost; when there are multiple least    cost routing table
  8643.         entries the    entry whose associated area has    the largest OSPF
  8644.         Area ID (when considered as    an unsigned 32-bit integer) is
  8645.         chosen.
  8646.  
  8647.  
  8648.  
  8649.  
  8650. Moy                Standards Track              [Page 173]
  8651.  
  8652. RFC 2328             OSPF Version 2              April 1998
  8653.  
  8654.  
  8655.         If the forwarding address is non-zero, look    up the
  8656.         forwarding address in the routing table.[24] The matching
  8657.         routing table entry    must specify an    intra-area or inter-area
  8658.         path; if no    such path exists, do nothing with the LSA and
  8659.         consider the next in the list.
  8660.  
  8661.     (4) Let    X be the cost specified    by the preferred routing table
  8662.         entry for the ASBR/forwarding address, and Y the cost
  8663.         specified in the LSA.  X is    in terms of the    link state
  8664.         metric, and    Y is a type 1 or 2 external metric.
  8665.  
  8666.     (5) Look up the    routing    table entry for    the destination    N.  If
  8667.         no entry exists for    N, install the AS external path    to N,
  8668.         with next hop equal    to the list of next hops to the
  8669.         forwarding address,    and advertising    router equal to    ASBR.
  8670.         If the external metric type    is 1, then the path-type is set
  8671.         to type 1 external and the cost is equal to    X+Y.  If the
  8672.         external metric type is 2, the path-type is    set to type 2
  8673.         external, the link state component of the route's cost is X,
  8674.         and    the type 2 cost    is Y.
  8675.  
  8676.     (6) Compare the    AS external path described by the LSA with the
  8677.         existing paths in N's routing table    entry, as follows. If
  8678.         the    new path is preferred, it replaces the present paths in
  8679.         N's    routing    table entry.  If the new path is of equal
  8680.         preference,    it is added to N's routing table entry's list of
  8681.         paths.
  8682.  
  8683.         (a)    Intra-area and inter-area paths    are always preferred
  8684.         over AS    external paths.
  8685.  
  8686.         (b)    Type 1 external    paths are always preferred over    type 2
  8687.         external paths.    When all paths are type    2 external
  8688.         paths, the paths with the smallest advertised type 2
  8689.         metric are always preferred.
  8690.  
  8691.         (c)    If the new AS external path is still indistinguishable
  8692.         from the current paths in the N's routing table    entry,
  8693.         and RFC1583Compatibility is set    to "disabled", select
  8694.         the preferred paths based on the intra-AS paths    to the
  8695.         ASBR/forwarding    addresses, as specified    in Section
  8696.         16.4.1.
  8697.  
  8698.  
  8699.  
  8700. Moy                Standards Track              [Page 174]
  8701.  
  8702. RFC 2328             OSPF Version 2              April 1998
  8703.  
  8704.  
  8705.         (d)    If the new AS external path is still indistinguishable
  8706.         from the current paths in the N's routing table    entry,
  8707.         select the preferred path based    on a least cost
  8708.         comparison.  Type 1 external paths are compared    by
  8709.         looking    at the sum of the distance to the forwarding
  8710.         address    and the    advertised type    1 metric (X+Y).     Type 2
  8711.         external paths advertising equal type 2    metrics    are
  8712.         compared by looking at the distance to the forwarding
  8713.         addresses.
  8714.  
  8715.     16.4.1.     External path preferences
  8716.  
  8717.         When multiple intra-AS paths are available to
  8718.         ASBRs/forwarding addresses,    the following rules indicate
  8719.         which paths    are preferred. These rules apply when the same
  8720.         ASBR is reachable through multiple areas, or when trying to
  8721.         decide which of several AS-external-LSAs should be
  8722.         preferred. In the former case the paths all    terminate at the
  8723.         same ASBR, while in    the latter the paths terminate at
  8724.         separate ASBRs/forwarding addresses. In either case, each
  8725.         path is represented    by a separate routing table entry as
  8726.         defined in Section 11.
  8727.  
  8728.         This section only applies when RFC1583Compatibility    is set
  8729.         to "disabled".
  8730.  
  8731.         The    path preference    rules, stated from highest to lowest
  8732.         preference,    are as follows.    Note that as a result of these
  8733.         rules, there may still be multiple paths of    the highest
  8734.         preference.    In this    case, the path to use must be determined
  8735.         based on cost, as described    in Section 16.4.
  8736.  
  8737.         o    Intra-area paths using non-backbone areas are always the
  8738.         most preferred.
  8739.  
  8740.         o    The other paths, intra-area backbone paths and inter-
  8741.         area paths, are    of equal preference.
  8742.  
  8743.     16.5.  Incremental updates -- summary-LSAs
  8744.  
  8745.     When a new summary-LSA is received, it is not necessary    to
  8746.     recalculate the    entire routing table.  Call the    destination
  8747.  
  8748.  
  8749.  
  8750. Moy                Standards Track              [Page 175]
  8751.  
  8752. RFC 2328             OSPF Version 2              April 1998
  8753.  
  8754.  
  8755.     described by the summary-LSA N (N's address is obtained    by
  8756.     masking    the LSA's Link State ID    with the network/subnet    mask
  8757.     contained in the body of the LSA), and let Area    A be the area to
  8758.     which the LSA belongs. There are then two separate cases:
  8759.  
  8760.     Case 1:    Area A is the backbone and/or the router is not    an area
  8761.         border router.
  8762.         In this case, the following    calculations must be performed.
  8763.         First, if there is presently an inter-area route to    the
  8764.         destination    N, N's routing table entry is invalidated,
  8765.         saving the entry's values for later    comparisons. Then the
  8766.         calculation    in Section 16.2    is run again for the single
  8767.         destination    N. In this calculation,    all of Area A's
  8768.         summary-LSAs that describe a route to N are    examined.  In
  8769.         addition, if the router is an area border router attached to
  8770.         one    or more    transit    areas, the calculation in Section 16.3
  8771.         must be run    again for the single destination.  If the
  8772.         results of these calculations have changed the cost/path to
  8773.         an AS boundary router (as would be the case    for a Type 4
  8774.         summary-LSA) or to any forwarding addresses, all AS-
  8775.         external-LSAs will have to be reexamined by    rerunning the
  8776.         calculation    in Section 16.4.  Otherwise, if    N is now newly
  8777.         unreachable, the calculation in Section 16.4 must be rerun
  8778.         for    the single destination N, in case an alternate external
  8779.         route to N exists.
  8780.  
  8781.     Case 2:    Area A is a transit area and the router    is an area
  8782.         border router.
  8783.         In this case, the following    calculations must be performed.
  8784.         First, if N's routing table    entry presently    contains one or
  8785.         more inter-area paths that utilize the transit area    Area A,
  8786.         these paths    should be removed. If this removes all paths
  8787.         from the routing table entry, the entry should be
  8788.         invalidated.  The entry's old values should    be saved for
  8789.         later comparisons. Next the    calculation in Section 16.3 must
  8790.         be run again for the single    destination N. If the results of
  8791.         this calculation have caused the cost to N to increase, the
  8792.         complete routing table calculation must be rerun starting
  8793.         with the Dijkstra algorithm    specified in Section 16.1.
  8794.         Otherwise, if the cost/path    to an AS boundary router (as
  8795.         would be the case for a Type 4 summary-LSA)    or to any
  8796.         forwarding addresses has changed, all AS-external-LSAs will
  8797.  
  8798.  
  8799.  
  8800. Moy                Standards Track              [Page 176]
  8801.  
  8802. RFC 2328             OSPF Version 2              April 1998
  8803.  
  8804.  
  8805.         have to be reexamined by rerunning the calculation in
  8806.         Section 16.4.  Otherwise, if N is now newly    unreachable, the
  8807.         calculation    in Section 16.4    must be    rerun for the single
  8808.         destination    N, in case an alternate    external route to N
  8809.         exists.
  8810.  
  8811.     16.6.  Incremental updates -- AS-external-LSAs
  8812.  
  8813.     When a new AS-external-LSA is received,    it is not necessary to
  8814.     recalculate the    entire routing table.  Call the    destination
  8815.     described by the AS-external-LSA N.  N's address is obtained by
  8816.     masking    the LSA's Link State ID    with the network/subnet    mask
  8817.     contained in the body of the LSA. If there is already an intra-
  8818.     area or    inter-area route to the    destination, no    recalculation is
  8819.     necessary (internal routes take    precedence).
  8820.  
  8821.     Otherwise, the procedure in Section 16.4 will have to be
  8822.     performed, but only for    those AS-external-LSAs whose destination
  8823.     is N.  Before this procedure is    performed, the present routing
  8824.     table entry for    N should be invalidated.
  8825.  
  8826.     16.7.  Events generated as a result    of routing table changes
  8827.  
  8828.     Changes    to routing table entries sometimes cause the OSPF area
  8829.     border routers to take additional actions.  These routers need
  8830.     to act on the following    routing    table changes:
  8831.  
  8832.     o   The    cost or    path type of a routing table entry has changed.
  8833.         If the destination described by this entry is a Network or
  8834.         AS boundary    router,    and this is not    simply a change    of AS
  8835.         external routes, new summary-LSAs may have to be generated
  8836.         (potentially one for each attached area, including the
  8837.         backbone).    See Section 12.4.3 for more information.  If a
  8838.         previously advertised entry    has been deleted, or is    no
  8839.         longer advertisable    to a particular    area, the LSA must be
  8840.         flushed from the routing domain by setting its LS age to
  8841.         MaxAge and reflooding (see Section 14.1).
  8842.  
  8843.     o   A routing table entry associated with a configured virtual
  8844.         link has changed.  The destination of such a routing table
  8845.         entry is an    area border router.  The change    indicates a
  8846.         modification to the    virtual    link's cost or viability.
  8847.  
  8848.  
  8849.  
  8850. Moy                Standards Track              [Page 177]
  8851.  
  8852. RFC 2328             OSPF Version 2              April 1998
  8853.  
  8854.  
  8855.         If the entry indicates that    the area border    router is newly
  8856.         reachable, the corresponding virtual link is now
  8857.         operational.  An InterfaceUp event should be generated for
  8858.         the    virtual    link, which will cause a virtual adjacency to
  8859.         begin to form (see Section 10.3).  At this time the    virtual
  8860.         link's IP interface    address    and the    virtual    neighbor's
  8861.         Neighbor IP    address    are also calculated.
  8862.  
  8863.         If the entry indicates that    the area border    router is no
  8864.         longer reachable, the virtual link and its associated
  8865.         adjacency should be    destroyed.  This means an InterfaceDown
  8866.         event should be generated for the associated virtual link.
  8867.  
  8868.         If the cost    of the entry has changed, and there is a fully
  8869.         established    virtual    adjacency, a new router-LSA for    the
  8870.         backbone must be originated.  This in turn may cause further
  8871.         routing table changes.
  8872.  
  8873.     16.8.  Equal-cost multipath
  8874.  
  8875.     The OSPF protocol maintains multiple equal-cost    routes to all
  8876.     destinations.  This can    be seen    in the steps used above    to
  8877.     calculate the routing table, and in the    definition of the
  8878.     routing    table structure.
  8879.  
  8880.     Each one of the    multiple routes    will be    of the same type
  8881.     (intra-area, inter-area, type 1    external or type 2 external),
  8882.     cost, and will have the    same associated    area.  However,    each
  8883.     route may specify a separate next hop and Advertising router.
  8884.  
  8885.     There is no requirement    that a router running OSPF keep    track of
  8886.     all possible equal-cost    routes to a destination.  An
  8887.     implementation may choose to keep only a fixed number of routes
  8888.     to any given destination.  This    does not affect    any of the
  8889.     algorithms presented in    this specification.
  8890.  
  8891.  
  8892.  
  8893.  
  8894.  
  8895.  
  8896.  
  8897.  
  8898.  
  8899.  
  8900. Moy                Standards Track              [Page 178]
  8901.  
  8902. RFC 2328             OSPF Version 2              April 1998
  8903.  
  8904.  
  8905. Footnotes
  8906.  
  8907.  
  8908.     [1]The graph's vertices represent either routers, transit networks,
  8909.     or stub networks.  Since routers may belong    to multiple areas, it is
  8910.     not    possible to color the graph's vertices.
  8911.  
  8912.     [2]It is possible for all of a router's interfaces to be unnumbered
  8913.     point-to-point links.  In this case, an IP address must be assigned
  8914.     to the router.  This address will then be advertised in the    router's
  8915.     router-LSA as a host route.
  8916.  
  8917.     [3]Note that in these cases    both interfaces, the non-virtual and the
  8918.     virtual, would have    the same IP address.
  8919.  
  8920.     [4]Note that no host route is generated for, and no    IP packets can
  8921.     be addressed to, interfaces    to unnumbered point-to-point networks.
  8922.     This is regardless of such an interface's state.
  8923.  
  8924.     [5]It is instructive to see    what happens when the Designated Router
  8925.     for    the network crashes.  Call the Designated Router for the network
  8926.     RT1, and the Backup    Designated Router RT2.    If Router RT1 crashes
  8927.     (or    maybe its interface to the network dies), the other routers on
  8928.     the    network    will detect RT1's absence within RouterDeadInterval
  8929.     seconds.  All routers may not detect this at precisely the same
  8930.     time; the routers that detect RT1's    absence    before RT2 does    will,
  8931.     for    a time,    select RT2 to be both Designated Router    and Backup
  8932.     Designated Router.    When RT2 detects that RT1 is gone it will move
  8933.     itself to Designated Router.  At this time,    the remaining router
  8934.     having highest Router Priority will    be selected as Backup Designated
  8935.     Router.
  8936.  
  8937.     [6]On point-to-point networks, the lower level protocols indicate
  8938.     whether the    neighbor is up and running.  Likewise, existence of the
  8939.     neighbor on    virtual    links is indicated by the routing table
  8940.     calculation.  However, in both these cases,    the Hello Protocol is
  8941.     still used.     This ensures that communication between the neighbors
  8942.     is bidirectional, and that each of the neighbors has a functioning
  8943.     routing protocol layer.
  8944.  
  8945.     [7]When the    identity of the    Designated Router is changing, it may be
  8946.     quite common for a neighbor    in this    state to send the router a
  8947.  
  8948.  
  8949.  
  8950. Moy                Standards Track              [Page 179]
  8951.  
  8952. RFC 2328             OSPF Version 2              April 1998
  8953.  
  8954.  
  8955.     Database Description packet; this means that there is some momentary
  8956.     disagreement on the    Designated Router's identity.
  8957.  
  8958.     [8]Note that it is possible    for a router to    resynchronize any of its
  8959.     fully established adjacencies by setting the adjacency's state back
  8960.     to ExStart.     This will cause the other end of the adjacency    to
  8961.     process a SeqNumberMismatch    event, and therefore to    also go    back to
  8962.     ExStart state.
  8963.  
  8964.     [9]The address space of IP networks    and the    address    space of OSPF
  8965.     Router IDs may overlap.  That is, a    network    may have an IP address
  8966.     which is identical (when considered    as a 32-bit number) to some
  8967.     router's Router ID.
  8968.  
  8969.     [10]"Discard" entries are necessary    to ensure that route
  8970.     summarization at area boundaries will not cause packet looping.
  8971.  
  8972.     [11]It is assumed that, for    two different address ranges matching
  8973.     the    destination, one range is more specific    than the other.    Non-
  8974.     contiguous subnet masks can    be configured to violate this
  8975.     assumption.    Such subnet mask configurations    cannot be handled by the
  8976.     OSPF protocol.
  8977.  
  8978.     [12]MaxAgeDiff is an architectural constant.  It indicates the
  8979.     maximum dispersion of ages,    in seconds, that can occur for a single
  8980.     LSA    instance as it is flooded throughout the routing domain.  If two
  8981.     LSAs differ    by more    than this, they    are assumed to be different
  8982.     instances of the same LSA.    This can occur when a router restarts
  8983.     and    loses track of the LSA's previous LS sequence number.  See
  8984.     Section 13.4 for more details.
  8985.  
  8986.     [13]When two LSAs have different LS    checksums, they    are assumed to
  8987.     be separate    instances.  This can occur when    a router restarts, and
  8988.     loses track    of the LSA's previous LS sequence number.  In the case
  8989.     where the two LSAs have the    same LS    sequence number, it is not
  8990.     possible to    determine which    LSA is actually    newer.    However, if the
  8991.     wrong LSA is accepted as newer, the    originating router will    simply
  8992.     originate another instance.     See Section 13.4 for further details.
  8993.  
  8994.     [14]There is one instance where a lookup must be done based    on
  8995.     partial information.  This is during the routing table calculation,
  8996.     when a network-LSA must be found based solely on its Link State ID.
  8997.  
  8998.  
  8999.  
  9000. Moy                Standards Track              [Page 180]
  9001.  
  9002. RFC 2328             OSPF Version 2              April 1998
  9003.  
  9004.  
  9005.     The    lookup in this case is still well defined, since no two
  9006.     network-LSAs can have the same Link    State ID.
  9007.  
  9008.     [15]This is    the way    RFC 1583 specified point-to-point
  9009.     representation.  It    has three advantages: a) it does not require
  9010.     allocating a subnet    to the point-to-point link, b) it tends    to bias
  9011.     the    routing    so that    packets    destined for the point-to-point
  9012.     interface will actually be received    over the interface (which is
  9013.     useful for diagnostic purposes) and    c) it allows network
  9014.     bootstrapping of a neighbor, without requiring that    the bootstrap
  9015.     program contain an OSPF implementation.
  9016.  
  9017.     [16]This is    the more traditional point-to-point representation used
  9018.     by protocols such as RIP.
  9019.  
  9020.     [17]This clause covers the case: Inter-area    routes are not
  9021.     summarized to the backbone.     This is because inter-area routes are
  9022.     always associated with the backbone    area.
  9023.  
  9024.     [18]This clause is only invoked when a non-backbone    Area A supports
  9025.     transit data traffic (i.e.,    has TransitCapability set to TRUE).  For
  9026.     example, in    the area configuration of Figure 6, Area 2 can support
  9027.     transit traffic due    to the configured virtual link between Routers
  9028.     RT10 and RT11. As a    result,    Router RT11 need only originate    a single
  9029.     summary-LSA    into Area 2 (having the    collapsed destination N9-
  9030.     N11,H1), since all of Router RT11's    other eligible routes have next
  9031.     hops belonging to Area 2 itself (and as such only need be advertised
  9032.     by other area border routers; in this case,    Routers    RT10 and RT7).
  9033.  
  9034.     [19]By keeping more    information in the routing table, it is    possible
  9035.     for    an implementation to recalculate the shortest path tree    for only
  9036.     a single area.  In fact, there are incremental algorithms that allow
  9037.     an implementation to recalculate only a portion of a single    area's
  9038.     shortest path tree [Ref1].    However, these algorithms are beyond the
  9039.     scope of this specification.
  9040.  
  9041.     [20]This is    how the    Link state request list    is emptied, which
  9042.     eventually causes the neighbor state to transition to Full.     See
  9043.     Section 10.9 for more details.
  9044.  
  9045.     [21]It should be a relatively rare occurrence for an LSA's LS age to
  9046.     reach MaxAge in this fashion.  Usually, the    LSA will be replaced by
  9047.  
  9048.  
  9049.  
  9050. Moy                Standards Track              [Page 181]
  9051.  
  9052. RFC 2328             OSPF Version 2              April 1998
  9053.  
  9054.  
  9055.     a more recent instance before it ages out.
  9056.  
  9057.     [22]Strictly speaking, because of equal-cost multipath, the
  9058.     algorithm does not create a    tree.  We continue to use the "tree"
  9059.     terminology    because    that is    what occurs most often in the existing
  9060.     literature.
  9061.  
  9062.     [23]Note that the presence of any link back    to V is    sufficient; it
  9063.     need not be    the matching half of the link under consideration from V
  9064.     to W. This is enough to ensure that, before    data traffic flows
  9065.     between a pair of neighboring routers, their link state databases
  9066.     will be synchronized.
  9067.  
  9068.     [24]When the forwarding address is non-zero, it should point to a
  9069.     router belonging to    another    Autonomous System.  See    Section    12.4.4
  9070.     for    more details.
  9071.  
  9072.  
  9073.  
  9074.  
  9075.  
  9076.  
  9077.  
  9078.  
  9079.  
  9080.  
  9081.  
  9082.  
  9083.  
  9084.  
  9085.  
  9086.  
  9087.  
  9088.  
  9089.  
  9090.  
  9091.  
  9092.  
  9093.  
  9094.  
  9095.  
  9096.  
  9097.  
  9098.  
  9099.  
  9100. Moy                Standards Track              [Page 182]
  9101.  
  9102. RFC 2328             OSPF Version 2              April 1998
  9103.  
  9104.  
  9105. References
  9106.  
  9107.     [Ref1]  McQuillan, J., I. Richer and E. Rosen, "ARPANET Routing
  9108.         Algorithm Improvements", BBN Technical Report 3803,    April
  9109.         1978.
  9110.  
  9111.     [Ref2]  Digital Equipment Corporation, "Information    processing
  9112.         systems -- Data communications -- Intermediate System to
  9113.         Intermediate System    Intra-Domain Routing Protocol",    October
  9114.         1987.
  9115.  
  9116.     [Ref3]  McQuillan, J., et.al., "The    New Routing Algorithm for the
  9117.         ARPANET", IEEE Transactions    on Communications, May 1980.
  9118.  
  9119.     [Ref4]  Perlman, R., "Fault-Tolerant Broadcast of Routing
  9120.         Information", Computer Networks, December 1983.
  9121.  
  9122.     [Ref5]  Postel, J.,    "Internet Protocol", STD 5, RFC    791, September
  9123.         1981.
  9124.  
  9125.     [Ref6]  McKenzie, A., "ISO Transport Protocol specification    ISO DP
  9126.         8073", RFC 905, April 1984.
  9127.  
  9128.     [Ref7]  Deering, S., "Host extensions for IP multicasting",    STD 5,
  9129.         RFC    1112, May 1988.
  9130.  
  9131.     [Ref8]  McCloghrie,    K., and    M. Rose, "Management Information Base
  9132.         for    network    management of TCP/IP-based internets: MIB-II",
  9133.         STD    17, RFC    1213, March 1991.
  9134.  
  9135.     [Ref9]  Moy, J., "OSPF Version 2", RFC 1583, March 1994.
  9136.  
  9137.     [Ref10] Fuller, V.,    T. Li, J. Yu, and K. Varadhan, "Classless
  9138.         Inter-Domain Routing (CIDR): an Address Assignment and
  9139.         Aggregation    Strategy", RFC1519, September 1993.
  9140.  
  9141.     [Ref11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
  9142.         1700, October 1994.
  9143.  
  9144.     [Ref12] Almquist, P., "Type    of Service in the Internet Protocol
  9145.         Suite", RFC    1349, July 1992.
  9146.  
  9147.  
  9148.  
  9149.  
  9150. Moy                Standards Track              [Page 183]
  9151.  
  9152. RFC 2328             OSPF Version 2              April 1998
  9153.  
  9154.  
  9155.     [Ref13] Leiner, B.,    et.al.,    "The DARPA Internet Protocol Suite", DDN
  9156.         Protocol Handbook, April 1985.
  9157.  
  9158.     [Ref14] Bradley, T., and C.    Brown, "Inverse    Address    Resolution
  9159.         Protocol", RFC 1293, January 1992.
  9160.  
  9161.     [Ref15] deSouza, O., and M.    Rodrigues, "Guidelines for Running OSPF
  9162.         Over Frame Relay Networks",    RFC 1586, March    1994.
  9163.  
  9164.     [Ref16] Bellovin, S., "Security Problems in    the TCP/IP Protocol
  9165.         Suite", ACM    Computer Communications    Review,    Volume 19,
  9166.         Number 2, pp. 32-38, April 1989.
  9167.  
  9168.     [Ref17] Rivest, R.,    "The MD5 Message-Digest    Algorithm", RFC    1321,
  9169.         April 1992.
  9170.  
  9171.     [Ref18] Moy, J., "Multicast    Extensions to OSPF", RFC 1584, March
  9172.         1994.
  9173.  
  9174.     [Ref19] Coltun, R.,    and V. Fuller, "The OSPF NSSA Option", RFC 1587,
  9175.         March 1994.
  9176.  
  9177.     [Ref20] Ferguson, D., "The OSPF External Attributes    LSA", work in
  9178.         progress.
  9179.  
  9180.     [Ref21] Moy, J., "Extending    OSPF to    Support    Demand Circuits", RFC
  9181.         1793, April    1995.
  9182.  
  9183.     [Ref22] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
  9184.         November 1990.
  9185.  
  9186.     [Ref23] Rekhter, Y., and T.    Li, "A Border Gateway Protocol 4 (BGP-
  9187.         4)", RFC 1771, March 1995.
  9188.  
  9189.     [Ref24] Hinden, R.,    "Internet Routing Protocol Standardization
  9190.         Criteria", BBN, October 1991.
  9191.  
  9192.     [Ref25] Moy, J., "OSPF Version 2", RFC 2178, July 1997.
  9193.  
  9194.     [Ref26] Rosen, E., "Vulnerabilities    of Network Control Protocols: An
  9195.         Example", Computer Communication Review, July 1981.
  9196.  
  9197.  
  9198.  
  9199.  
  9200. Moy                Standards Track              [Page 184]
  9201.  
  9202. RFC 2328             OSPF Version 2              April 1998
  9203.  
  9204.  
  9205. A. OSPF    data formats
  9206.  
  9207.     This appendix describes the    format of OSPF protocol    packets    and OSPF
  9208.     LSAs.  The OSPF protocol runs directly over    the IP network layer.
  9209.     Before any data formats are    described, the details of the OSPF
  9210.     encapsulation are explained.
  9211.  
  9212.     Next the OSPF Options field    is described.  This field describes
  9213.     various capabilities that may or may not be    supported by pieces of
  9214.     the    OSPF routing domain. The OSPF Options field is contained in OSPF
  9215.     Hello packets, Database Description    packets    and in OSPF LSAs.
  9216.  
  9217.     OSPF packet    formats    are detailed in    Section    A.3.  A    description of
  9218.     OSPF LSAs appears in Section A.4.
  9219.  
  9220. A.1 Encapsulation of OSPF packets
  9221.  
  9222.     OSPF runs directly over the    Internet Protocol's network layer.  OSPF
  9223.     packets are    therefore encapsulated solely by IP and    local data-link
  9224.     headers.
  9225.  
  9226.     OSPF does not define a way to fragment its protocol    packets, and
  9227.     depends on IP fragmentation    when transmitting packets larger than
  9228.     the    network    MTU. If    necessary, the length of OSPF packets can be up
  9229.     to 65,535 bytes (including the IP header).    The OSPF packet    types
  9230.     that are likely to be large    (Database Description Packets, Link
  9231.     State Request, Link    State Update, and Link State Acknowledgment
  9232.     packets) can usually be split into several separate    protocol
  9233.     packets, without loss of functionality.  This is recommended; IP
  9234.     fragmentation should be avoided whenever possible.    Using this
  9235.     reasoning, an attempt should be made to limit the sizes of OSPF
  9236.     packets sent over virtual links to 576 bytes unless    Path MTU
  9237.     Discovery is being performed (see [Ref22]).
  9238.  
  9239.     The    other important    features of OSPF's IP encapsulation are:
  9240.  
  9241.     o    Use of IP multicast.  Some OSPF    messages are multicast,    when
  9242.     sent over broadcast networks.  Two distinct IP multicast
  9243.     addresses are used.  Packets sent to these multicast addresses
  9244.     should never be    forwarded; they    are meant to travel a single hop
  9245.     only.  To ensure that these packets will not travel multiple
  9246.     hops, their IP TTL must    be set to 1.
  9247.  
  9248.  
  9249.  
  9250. Moy                Standards Track              [Page 185]
  9251.  
  9252. RFC 2328             OSPF Version 2              April 1998
  9253.  
  9254.  
  9255.     AllSPFRouters
  9256.         This multicast address has been assigned the value
  9257.         224.0.0.5.    All routers running OSPF should    be prepared to
  9258.         receive packets sent to this address.  Hello packets are
  9259.         always sent    to this    destination.  Also, certain OSPF
  9260.         protocol packets are sent to this address during the
  9261.         flooding procedure.
  9262.  
  9263.     AllDRouters
  9264.         This multicast address has been assigned the value
  9265.         224.0.0.6.    Both the Designated Router and Backup Designated
  9266.         Router must    be prepared to receive packets destined    to this
  9267.         address.  Certain OSPF protocol packets are    sent to    this
  9268.         address during the flooding    procedure.
  9269.  
  9270.     o    OSPF is    IP protocol number 89.    This number has    been registered
  9271.     with the Network Information Center.  IP protocol number
  9272.     assignments are    documented in [Ref11].
  9273.  
  9274.     o    All OSPF routing protocol packets are sent using the normal
  9275.     service    TOS value of binary 0000 defined in [Ref12].
  9276.  
  9277.     o    Routing    protocol packets are sent with IP precedence set to
  9278.     Internetwork Control.  OSPF protocol packets should be given
  9279.     precedence over    regular    IP data    traffic, in both sending and
  9280.     receiving.  Setting the    IP precedence field in the IP header to
  9281.     Internetwork Control [Ref5] may    help implement this objective.
  9282.  
  9283.  
  9284.  
  9285.  
  9286.  
  9287.  
  9288.  
  9289.  
  9290.  
  9291.  
  9292.  
  9293.  
  9294.  
  9295.  
  9296.  
  9297.  
  9298.  
  9299.  
  9300. Moy                Standards Track              [Page 186]
  9301.  
  9302. RFC 2328             OSPF Version 2              April 1998
  9303.  
  9304.  
  9305. A.2 The    Options    field
  9306.  
  9307.     The    OSPF Options field is present in OSPF Hello packets, Database
  9308.     Description    packets    and all    LSAs.  The Options field enables OSPF
  9309.     routers to support (or not support)    optional capabilities, and to
  9310.     communicate    their capability level to other    OSPF routers.  Through
  9311.     this mechanism routers of differing    capabilities can be mixed within
  9312.     an OSPF routing domain.
  9313.  
  9314.     When used in Hello packets,    the Options field allows a router to
  9315.     reject a neighbor because of a capability mismatch.     Alternatively,
  9316.     when capabilities are exchanged in Database    Description packets a
  9317.     router can choose not to forward certain LSAs to a neighbor    because
  9318.     of its reduced functionality.  Lastly, listing capabilities    in LSAs
  9319.     allows routers to forward traffic around reduced functionality
  9320.     routers, by    excluding them from parts of the routing table
  9321.     calculation.
  9322.  
  9323.     Five bits of the OSPF Options field    have been assigned, although
  9324.     only one (the E-bit) is described completely by this memo. Each bit
  9325.     is described briefly below.    Routers    should reset (i.e.  clear)
  9326.     unrecognized bits in the Options field when    sending    Hello packets or
  9327.     Database Description packets and when originating LSAs. Conversely,
  9328.     routers encountering unrecognized Option bits in received Hello
  9329.     Packets, Database Description packets or LSAs should ignore    the
  9330.     capability and process the packet/LSA normally.
  9331.  
  9332.                +------------------------------------+
  9333.                | * | * | DC | EA | N/P | MC | E    | * |
  9334.                +------------------------------------+
  9335.  
  9336.                  The Options field
  9337.  
  9338.  
  9339.     E-bit
  9340.     This bit describes the way AS-external-LSAs are    flooded, as
  9341.     described in Sections 3.6, 9.5,    10.8 and 12.1.2    of this    memo.
  9342.  
  9343.     MC-bit
  9344.     This bit describes whether IP multicast    datagrams are forwarded
  9345.     according to the specifications    in [Ref18].
  9346.  
  9347.  
  9348.  
  9349.  
  9350. Moy                Standards Track              [Page 187]
  9351.  
  9352. RFC 2328             OSPF Version 2              April 1998
  9353.  
  9354.  
  9355.     N/P-bit
  9356.     This bit describes the handling    of Type-7 LSAs,    as specified in
  9357.     [Ref19].
  9358.  
  9359.     EA-bit
  9360.     This bit describes the router's    willingness to receive and
  9361.     forward    External-Attributes-LSAs, as specified in [Ref20].
  9362.  
  9363.     DC-bit
  9364.     This bit describes the router's    handling of demand circuits, as
  9365.     specified in [Ref21].
  9366.  
  9367.  
  9368.  
  9369.  
  9370.  
  9371.  
  9372.  
  9373.  
  9374.  
  9375.  
  9376.  
  9377.  
  9378.  
  9379.  
  9380.  
  9381.  
  9382.  
  9383.  
  9384.  
  9385.  
  9386.  
  9387.  
  9388.  
  9389.  
  9390.  
  9391.  
  9392.  
  9393.  
  9394.  
  9395.  
  9396.  
  9397.  
  9398.  
  9399.  
  9400. Moy                Standards Track              [Page 188]
  9401.  
  9402. RFC 2328             OSPF Version 2              April 1998
  9403.  
  9404.  
  9405. A.3 OSPF Packet    Formats
  9406.  
  9407.     There are five distinct OSPF packet    types.    All OSPF packet    types
  9408.     begin with a standard 24 byte header.  This    header is described
  9409.     first.  Each packet    type is    then described in a succeeding section.
  9410.     In these sections each packet's division into fields is displayed,
  9411.     and    then the field definitions are enumerated.
  9412.  
  9413.     All    OSPF packet types (other than the OSPF Hello packets) deal with
  9414.     lists of LSAs.  For    example, Link State Update packets implement the
  9415.     flooding of    LSAs throughout    the OSPF routing domain.  Because of
  9416.     this, OSPF protocol    packets    cannot be parsed unless    the format of
  9417.     LSAs is also understood.  The format of LSAs is described in Section
  9418.     A.4.
  9419.  
  9420.     The    receive    processing of OSPF packets is detailed in Section 8.2.
  9421.     The    sending    of OSPF    packets    is explained in    Section    8.1.
  9422.  
  9423.  
  9424.  
  9425.  
  9426.  
  9427.  
  9428.  
  9429.  
  9430.  
  9431.  
  9432.  
  9433.  
  9434.  
  9435.  
  9436.  
  9437.  
  9438.  
  9439.  
  9440.  
  9441.  
  9442.  
  9443.  
  9444.  
  9445.  
  9446.  
  9447.  
  9448.  
  9449.  
  9450. Moy                Standards Track              [Page 189]
  9451.  
  9452. RFC 2328             OSPF Version 2              April 1998
  9453.  
  9454.  
  9455. A.3.1 The OSPF packet header
  9456.  
  9457.     Every OSPF packet starts with a standard 24    byte header.  This
  9458.     header contains all    the information    necessary to determine whether
  9459.     the    packet should be accepted for further processing.  This
  9460.     determination is described in Section 8.2 of the specification.
  9461.  
  9462.  
  9463.     0            1            2            3
  9464.     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
  9465.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9466.        |   Version #   |     Type      |     Packet    length           |
  9467.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9468.        |              Router ID                   |
  9469.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9470.        |               Area    ID                   |
  9471.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9472.        |       Checksum           |         AuType           |
  9473.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9474.        |               Authentication                   |
  9475.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9476.        |               Authentication                   |
  9477.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9478.  
  9479.  
  9480.  
  9481.     Version #
  9482.     The OSPF version number.  This specification documents version 2
  9483.     of the protocol.
  9484.  
  9485.     Type
  9486.     The OSPF packet    types are as follows. See Sections A.3.2 through
  9487.     A.3.6 for details.
  9488.  
  9489.  
  9490.  
  9491.  
  9492.  
  9493.  
  9494.  
  9495.  
  9496.  
  9497.  
  9498.  
  9499.  
  9500. Moy                Standards Track              [Page 190]
  9501.  
  9502. RFC 2328             OSPF Version 2              April 1998
  9503.  
  9504.  
  9505.  
  9506.               Type     Description
  9507.               ________________________________
  9508.               1     Hello
  9509.               2     Database Description
  9510.               3     Link State Request
  9511.               4     Link State Update
  9512.               5     Link State Acknowledgment
  9513.  
  9514.  
  9515.  
  9516.  
  9517.     Packet length
  9518.     The length of the OSPF protocol    packet in bytes.  This length
  9519.     includes the standard OSPF header.
  9520.  
  9521.     Router ID
  9522.     The Router ID of the packet's source.
  9523.  
  9524.     Area ID
  9525.     A 32 bit number    identifying the    area that this packet belongs
  9526.     to.  All OSPF packets are associated with a single area.  Most
  9527.     travel a single    hop only.  Packets travelling over a virtual
  9528.     link are labelled with the backbone Area ID of 0.0.0.0.
  9529.  
  9530.     Checksum
  9531.     The standard IP    checksum of the    entire contents    of the packet,
  9532.     starting with the OSPF packet header but excluding the 64-bit
  9533.     authentication field.  This checksum is    calculated as the 16-bit
  9534.     one's complement of the    one's complement sum of    all the    16-bit
  9535.     words in the packet, excepting the authentication field.  If the
  9536.     packet's length    is not an integral number of 16-bit words, the
  9537.     packet is padded with a    byte of    zero before checksumming.  The
  9538.     checksum is considered to be part of the packet    authentication
  9539.     procedure; for some authentication types the checksum
  9540.     calculation is omitted.
  9541.  
  9542.     AuType
  9543.     Identifies the authentication procedure    to be used for the
  9544.     packet.     Authentication    is discussed in    Appendix D of the
  9545.     specification.    Consult    Appendix D for a list of the currently
  9546.     defined    authentication types.
  9547.  
  9548.  
  9549.  
  9550. Moy                Standards Track              [Page 191]
  9551.  
  9552. RFC 2328             OSPF Version 2              April 1998
  9553.  
  9554.  
  9555.     Authentication
  9556.     A 64-bit field for use by the authentication scheme. See
  9557.     Appendix D for details.
  9558.  
  9559.  
  9560.  
  9561.  
  9562.  
  9563.  
  9564.  
  9565.  
  9566.  
  9567.  
  9568.  
  9569.  
  9570.  
  9571.  
  9572.  
  9573.  
  9574.  
  9575.  
  9576.  
  9577.  
  9578.  
  9579.  
  9580.  
  9581.  
  9582.  
  9583.  
  9584.  
  9585.  
  9586.  
  9587.  
  9588.  
  9589.  
  9590.  
  9591.  
  9592.  
  9593.  
  9594.  
  9595.  
  9596.  
  9597.  
  9598.  
  9599.  
  9600. Moy                Standards Track              [Page 192]
  9601.  
  9602. RFC 2328             OSPF Version 2              April 1998
  9603.  
  9604.  
  9605. A.3.2 The Hello    packet
  9606.  
  9607.     Hello packets are OSPF packet type 1.  These packets are sent
  9608.     periodically on all    interfaces (including virtual links) in    order to
  9609.     establish and maintain neighbor relationships.  In addition, Hello
  9610.     Packets are    multicast on those physical networks having a multicast
  9611.     or broadcast capability, enabling dynamic discovery    of neighboring
  9612.     routers.
  9613.  
  9614.     All    routers    connected to a common network must agree on certain
  9615.     parameters (Network    mask, HelloInterval and    RouterDeadInterval).
  9616.     These parameters are included in Hello packets, so that differences
  9617.     can    inhibit    the forming of neighbor    relationships.    A detailed
  9618.     explanation    of the receive processing for Hello packets is presented
  9619.     in Section 10.5.  The sending of Hello packets is covered in Section
  9620.     9.5.
  9621.  
  9622.  
  9623.     0            1            2            3
  9624.     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
  9625.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9626.        |   Version #   |       1       |     Packet    length           |
  9627.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9628.        |              Router ID                   |
  9629.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9630.        |               Area    ID                   |
  9631.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9632.        |       Checksum           |         AuType           |
  9633.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9634.        |               Authentication                   |
  9635.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9636.        |               Authentication                   |
  9637.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9638.        |            Network    Mask                   |
  9639.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9640.        |     HelloInterval           |    Options    |    Rtr    Pri    |
  9641.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9642.        |             RouterDeadInterval                   |
  9643.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9644.        |              Designated Router                   |
  9645.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9646.        |           Backup Designated Router               |
  9647.  
  9648.  
  9649.  
  9650. Moy                Standards Track              [Page 193]
  9651.  
  9652. RFC 2328             OSPF Version 2              April 1998
  9653.  
  9654.  
  9655.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9656.        |              Neighbor                   |
  9657.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9658.        |                  ...                   |
  9659.  
  9660.  
  9661.     Network mask
  9662.     The network mask associated with this interface.  For example,
  9663.     if the interface is to a class B network whose third byte is
  9664.     used for subnetting, the network mask is 0xffffff00.
  9665.  
  9666.     Options
  9667.     The optional capabilities supported by the router, as documented
  9668.     in Section A.2.
  9669.  
  9670.     HelloInterval
  9671.     The number of seconds between this router's Hello packets.
  9672.  
  9673.     Rtr    Pri
  9674.     This router's Router Priority.    Used in    (Backup) Designated
  9675.     Router election.  If set to 0, the router will be ineligible to
  9676.     become (Backup)    Designated Router.
  9677.  
  9678.     RouterDeadInterval
  9679.     The number of seconds before declaring a silent    router down.
  9680.  
  9681.     Designated Router
  9682.     The identity of    the Designated Router for this network,    in the
  9683.     view of    the sending router.  The Designated Router is identified
  9684.     here by    its IP interface address on the    network.  Set to 0.0.0.0
  9685.     if there is no Designated Router.
  9686.  
  9687.     Backup Designated Router
  9688.     The identity of    the Backup Designated Router for this network,
  9689.     in the view of the sending router.  The    Backup Designated Router
  9690.     is identified here by its IP interface address on the network.
  9691.     Set to 0.0.0.0 if there    is no Backup Designated    Router.
  9692.  
  9693.     Neighbor
  9694.     The Router IDs of each router from whom    valid Hello packets have
  9695.     been seen recently on the network.  Recently means in the last
  9696.     RouterDeadInterval seconds.
  9697.  
  9698.  
  9699.  
  9700. Moy                Standards Track              [Page 194]
  9701.  
  9702. RFC 2328             OSPF Version 2              April 1998
  9703.  
  9704.  
  9705. A.3.3 The Database Description packet
  9706.  
  9707.     Database Description packets are OSPF packet type 2.  These    packets
  9708.     are    exchanged when an adjacency is being initialized.  They    describe
  9709.     the    contents of the    link-state database.  Multiple packets may be
  9710.     used to describe the database.  For    this purpose a poll-response
  9711.     procedure is used.    One of the routers is designated to be the
  9712.     master, the    other the slave.  The master sends Database Description
  9713.     packets (polls) which are acknowledged by Database Description
  9714.     packets sent by the    slave (responses).  The    responses are linked to
  9715.     the    polls via the packets' DD sequence numbers.
  9716.  
  9717.     0            1            2            3
  9718.     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
  9719.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9720.        |   Version #   |       2       |     Packet    length           |
  9721.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9722.        |              Router ID                   |
  9723.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9724.        |               Area    ID                   |
  9725.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9726.        |       Checksum           |         AuType           |
  9727.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9728.        |               Authentication                   |
  9729.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9730.        |               Authentication                   |
  9731.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9732.        |     Interface MTU           |    Options    |0|0|0|0|0|I|M|MS
  9733.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9734.        |             DD    sequence number                   |
  9735.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9736.        |                                   |
  9737.        +-                                  -+
  9738.        |                                   |
  9739.        +-               An LSA Header                  -+
  9740.        |                                   |
  9741.        +-                                  -+
  9742.        |                                   |
  9743.        +-                                  -+
  9744.        |                                   |
  9745.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9746.        |                  ...                   |
  9747.  
  9748.  
  9749.  
  9750. Moy                Standards Track              [Page 195]
  9751.  
  9752. RFC 2328             OSPF Version 2              April 1998
  9753.  
  9754.  
  9755.     The    format of the Database Description packet is very similar to
  9756.     both the Link State    Request    and Link State Acknowledgment packets.
  9757.     The    main part of all three is a list of items, each    item describing
  9758.     a piece of the link-state database.     The sending of    Database
  9759.     Description    Packets    is documented in Section 10.8.    The reception of
  9760.     Database Description packets is documented in Section 10.6.
  9761.  
  9762.     Interface MTU
  9763.     The size in bytes of the largest IP datagram that can be sent
  9764.     out the    associated interface, without fragmentation.  The MTUs
  9765.     of common Internet link    types can be found in Table 7-1    of
  9766.     [Ref22]. Interface MTU should be set to    0 in Database
  9767.     Description packets sent over virtual links.
  9768.  
  9769.     Options
  9770.     The optional capabilities supported by the router, as documented
  9771.     in Section A.2.
  9772.  
  9773.     I-bit
  9774.     The Init bit.  When set    to 1, this packet is the first in the
  9775.     sequence of Database Description Packets.
  9776.  
  9777.     M-bit
  9778.     The More bit.  When set    to 1, it indicates that    more Database
  9779.     Description Packets are    to follow.
  9780.  
  9781.     MS-bit
  9782.     The Master/Slave bit.  When set    to 1, it indicates that    the
  9783.     router is the master during the    Database Exchange process.
  9784.     Otherwise, the router is the slave.
  9785.  
  9786.     DD sequence    number
  9787.     Used to    sequence the collection    of Database Description    Packets.
  9788.     The initial value (indicated by    the Init bit being set)    should
  9789.     be unique.  The    DD sequence number then    increments until the
  9790.     complete database description has been sent.
  9791.  
  9792.     The    rest of    the packet consists of a (possibly partial) list of the
  9793.     link-state database's pieces.  Each    LSA in the database is described
  9794.     by its LSA header.    The LSA    header is documented in    Section    A.4.1.
  9795.     It contains    all the    information required to    uniquely identify both
  9796.     the    LSA and    the LSA's current instance.
  9797.  
  9798.  
  9799.  
  9800. Moy                Standards Track              [Page 196]
  9801.  
  9802. RFC 2328             OSPF Version 2              April 1998
  9803.  
  9804.  
  9805. A.3.4 The Link State Request packet
  9806.  
  9807.     Link State Request packets are OSPF    packet type 3.    After exchanging
  9808.     Database Description packets with a    neighboring router, a router may
  9809.     find that parts of its link-state database are out-of-date.     The
  9810.     Link State Request packet is used to request the pieces of the
  9811.     neighbor's database    that are more up-to-date.  Multiple Link State
  9812.     Request packets may    need to    be used.
  9813.  
  9814.     A router that sends    a Link State Request packet has    in mind    the
  9815.     precise instance of    the database pieces it is requesting. Each
  9816.     instance is    defined    by its LS sequence number, LS checksum,    and LS
  9817.     age, although these    fields are not specified in the    Link State
  9818.     Request Packet itself.  The    router may receive even    more recent
  9819.     instances in response.
  9820.  
  9821.     The    sending    of Link    State Request packets is documented in Section
  9822.     10.9.  The reception of Link State Request packets is documented in
  9823.     Section 10.7.
  9824.  
  9825.     0            1            2            3
  9826.     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
  9827.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9828.        |   Version #   |       3       |     Packet    length           |
  9829.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9830.        |              Router ID                   |
  9831.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9832.        |               Area    ID                   |
  9833.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9834.        |       Checksum           |         AuType           |
  9835.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9836.        |               Authentication                   |
  9837.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9838.        |               Authentication                   |
  9839.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9840.        |              LS type                   |
  9841.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9842.        |               Link State ID                   |
  9843.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9844.        |             Advertising Router                   |
  9845.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9846.        |                  ...                   |
  9847.  
  9848.  
  9849.  
  9850. Moy                Standards Track              [Page 197]
  9851.  
  9852. RFC 2328             OSPF Version 2              April 1998
  9853.  
  9854.  
  9855.     Each LSA requested is specified by its LS type, Link State ID, and
  9856.     Advertising    Router.     This uniquely identifies the LSA, but not its
  9857.     instance.  Link State Request packets are understood to be requests
  9858.     for    the most recent    instance (whatever that    might be).
  9859.  
  9860.  
  9861.  
  9862.  
  9863.  
  9864.  
  9865.  
  9866.  
  9867.  
  9868.  
  9869.  
  9870.  
  9871.  
  9872.  
  9873.  
  9874.  
  9875.  
  9876.  
  9877.  
  9878.  
  9879.  
  9880.  
  9881.  
  9882.  
  9883.  
  9884.  
  9885.  
  9886.  
  9887.  
  9888.  
  9889.  
  9890.  
  9891.  
  9892.  
  9893.  
  9894.  
  9895.  
  9896.  
  9897.  
  9898.  
  9899.  
  9900. Moy                Standards Track              [Page 198]
  9901.  
  9902. RFC 2328             OSPF Version 2              April 1998
  9903.  
  9904.  
  9905. A.3.5 The Link State Update packet
  9906.  
  9907.     Link State Update packets are OSPF packet type 4.  These packets
  9908.     implement the flooding of LSAs.  Each Link State Update packet
  9909.     carries a collection of LSAs one hop further from their origin.
  9910.     Several LSAs may be    included in a single packet.
  9911.  
  9912.     Link State Update packets are multicast on those physical networks
  9913.     that support multicast/broadcast.  In order    to make    the flooding
  9914.     procedure reliable,    flooded    LSAs are acknowledged in Link State
  9915.     Acknowledgment packets.  If    retransmission of certain LSAs is
  9916.     necessary, the retransmitted LSAs are always sent directly to the
  9917.     neighbor.  For more    information on the reliable flooding of    LSAs,
  9918.     consult Section 13.
  9919.  
  9920.     0            1            2            3
  9921.     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
  9922.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9923.        |   Version #   |       4       |     Packet    length           |
  9924.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9925.        |              Router ID                   |
  9926.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9927.        |               Area    ID                   |
  9928.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9929.        |       Checksum           |         AuType           |
  9930.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9931.        |               Authentication                   |
  9932.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9933.        |               Authentication                   |
  9934.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9935.        |                # LSAs                   |
  9936.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  9937.        |                                   |
  9938.        +-                                 +-+
  9939.        |                 LSAs                   |
  9940.        +-                                 +-+
  9941.        |                  ...                   |
  9942.  
  9943.  
  9944.  
  9945.  
  9946.  
  9947.  
  9948.  
  9949.  
  9950. Moy                Standards Track              [Page 199]
  9951.  
  9952. RFC 2328             OSPF Version 2              April 1998
  9953.  
  9954.  
  9955.     # LSAs
  9956.     The number of LSAs included in this update.
  9957.  
  9958.  
  9959.     The    body of    the Link State Update packet consists of a list    of LSAs.
  9960.     Each LSA begins with a common 20 byte header, described in Section
  9961.     A.4.1. Detailed formats of the different types of LSAs are described
  9962.     in Section A.4.
  9963.  
  9964.  
  9965.  
  9966.  
  9967.  
  9968.  
  9969.  
  9970.  
  9971.  
  9972.  
  9973.  
  9974.  
  9975.  
  9976.  
  9977.  
  9978.  
  9979.  
  9980.  
  9981.  
  9982.  
  9983.  
  9984.  
  9985.  
  9986.  
  9987.  
  9988.  
  9989.  
  9990.  
  9991.  
  9992.  
  9993.  
  9994.  
  9995.  
  9996.  
  9997.  
  9998.  
  9999.  
  10000. Moy                Standards Track              [Page 200]
  10001.  
  10002. RFC 2328             OSPF Version 2              April 1998
  10003.  
  10004.  
  10005. A.3.6 The Link State Acknowledgment packet
  10006.  
  10007.     Link State Acknowledgment Packets are OSPF packet type 5.  To make
  10008.     the    flooding of LSAs reliable, flooded LSAs    are explicitly
  10009.     acknowledged.  This    acknowledgment is accomplished through the
  10010.     sending and    receiving of Link State    Acknowledgment packets.
  10011.     Multiple LSAs can be acknowledged in a single Link State
  10012.     Acknowledgment packet.
  10013.  
  10014.     Depending on the state of the sending interface and    the sender of
  10015.     the    corresponding Link State Update    packet,    a Link State
  10016.     Acknowledgment packet is sent either to the    multicast address
  10017.     AllSPFRouters, to the multicast address AllDRouters, or as a
  10018.     unicast.  The sending of Link State    Acknowledgement    packets    is
  10019.     documented in Section 13.5.     The reception of Link State
  10020.     Acknowledgement packets is documented in Section 13.7.
  10021.  
  10022.     The    format of this packet is similar to that of the    Data Description
  10023.     packet.  The body of both packets is simply    a list of LSA headers.
  10024.  
  10025.  
  10026.     0            1            2            3
  10027.     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
  10028.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10029.        |   Version #   |       5       |     Packet    length           |
  10030.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10031.        |              Router ID                   |
  10032.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10033.        |               Area    ID                   |
  10034.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10035.        |       Checksum           |         AuType           |
  10036.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10037.        |               Authentication                   |
  10038.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10039.        |               Authentication                   |
  10040.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10041.        |                                   |
  10042.        +-                                  -+
  10043.        |                                   |
  10044.        +-              An LSA Header                  -+
  10045.        |                                   |
  10046.        +-                                  -+
  10047.  
  10048.  
  10049.  
  10050. Moy                Standards Track              [Page 201]
  10051.  
  10052. RFC 2328             OSPF Version 2              April 1998
  10053.  
  10054.  
  10055.        |                                   |
  10056.        +-                                  -+
  10057.        |                                   |
  10058.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10059.        |                  ...                   |
  10060.  
  10061.  
  10062.     Each acknowledged LSA is described by its LSA header.  The LSA
  10063.     header is documented in Section A.4.1.  It contains    all the
  10064.     information    required to uniquely identify both the LSA and the LSA's
  10065.     current instance.
  10066.  
  10067.  
  10068.  
  10069.  
  10070.  
  10071.  
  10072.  
  10073.  
  10074.  
  10075.  
  10076.  
  10077.  
  10078.  
  10079.  
  10080.  
  10081.  
  10082.  
  10083.  
  10084.  
  10085.  
  10086.  
  10087.  
  10088.  
  10089.  
  10090.  
  10091.  
  10092.  
  10093.  
  10094.  
  10095.  
  10096.  
  10097.  
  10098.  
  10099.  
  10100. Moy                Standards Track              [Page 202]
  10101.  
  10102. RFC 2328             OSPF Version 2              April 1998
  10103.  
  10104.  
  10105. A.4 LSA    formats
  10106.  
  10107.     This memo defines five distinct types of LSAs.  Each LSA begins with
  10108.     a standard 20 byte LSA header.  This header    is explained in    Section
  10109.     A.4.1.  Succeeding sections    then diagram the separate LSA types.
  10110.  
  10111.     Each LSA describes a piece of the OSPF routing domain.  Every router
  10112.     originates a router-LSA.  In addition, whenever the    router is
  10113.     elected Designated Router, it originates a network-LSA.  Other types
  10114.     of LSAs may    also be    originated (see    Section    12.4).    All LSAs are
  10115.     then flooded throughout the    OSPF routing domain.  The flooding
  10116.     algorithm is reliable, ensuring that all routers have the same
  10117.     collection of LSAs.     (See Section 13 for more information concerning
  10118.     the    flooding algorithm).  This collection of LSAs is called    the
  10119.     link-state database.
  10120.  
  10121.     From the link state    database, each router constructs a shortest path
  10122.     tree with itself as    root.  This yields a routing table (see    Section
  10123.     11).  For the details of the routing table build process, see
  10124.     Section 16.
  10125.  
  10126.  
  10127.  
  10128.  
  10129.  
  10130.  
  10131.  
  10132.  
  10133.  
  10134.  
  10135.  
  10136.  
  10137.  
  10138.  
  10139.  
  10140.  
  10141.  
  10142.  
  10143.  
  10144.  
  10145.  
  10146.  
  10147.  
  10148.  
  10149.  
  10150. Moy                Standards Track              [Page 203]
  10151.  
  10152. RFC 2328             OSPF Version 2              April 1998
  10153.  
  10154.  
  10155. A.4.1 The LSA header
  10156.  
  10157.     All    LSAs begin with    a common 20 byte header.  This header contains
  10158.     enough information to uniquely identify the    LSA (LS    type, Link State
  10159.     ID,    and Advertising    Router).  Multiple instances of    the LSA    may
  10160.     exist in the routing domain    at the same time.  It is then necessary
  10161.     to determine which instance    is more    recent.     This is accomplished by
  10162.     examining the LS age, LS sequence number and LS checksum fields that
  10163.     are    also contained in the LSA header.
  10164.  
  10165.  
  10166.     0            1            2            3
  10167.     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
  10168.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10169.        |        LS age           |    Options    |    LS type    |
  10170.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10171.        |            Link State ID                   |
  10172.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10173.        |             Advertising Router                   |
  10174.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10175.        |             LS    sequence number                   |
  10176.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10177.        |     LS checksum           |         length           |
  10178.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10179.  
  10180.  
  10181.  
  10182.     LS age
  10183.     The time in seconds since the LSA was originated.
  10184.  
  10185.     Options
  10186.     The optional capabilities supported by the described portion of
  10187.     the routing domain.  OSPF's optional capabilities are documented
  10188.     in Section A.2.
  10189.  
  10190.     LS type
  10191.     The type of the    LSA.  Each LSA type has    a separate advertisement
  10192.     format.     The LSA types defined in this memo are    as follows (see
  10193.     Section    12.1.3 for further explanation):
  10194.  
  10195.  
  10196.  
  10197.  
  10198.  
  10199.  
  10200. Moy                Standards Track              [Page 204]
  10201.  
  10202. RFC 2328             OSPF Version 2              April 1998
  10203.  
  10204.  
  10205.  
  10206.             LS Type      Description
  10207.             ___________________________________
  10208.             1      Router-LSAs
  10209.             2      Network-LSAs
  10210.             3      Summary-LSAs (IP network)
  10211.             4      Summary-LSAs (ASBR)
  10212.             5      AS-external-LSAs
  10213.  
  10214.  
  10215.  
  10216.  
  10217.     Link State ID
  10218.     This field identifies the portion of the internet environment
  10219.     that is    being described    by the LSA.  The contents of this field
  10220.     depend on the LSA's LS type.  For example, in network-LSAs the
  10221.     Link State ID is set to    the IP interface address of the
  10222.     network's Designated Router (from which    the network's IP address
  10223.     can be derived).  The Link State ID is further discussed in
  10224.     Section    12.1.4.
  10225.  
  10226.     Advertising    Router
  10227.     The Router ID of the router that originated the    LSA.  For
  10228.     example, in network-LSAs this field is equal to    the Router ID of
  10229.     the network's Designated Router.
  10230.  
  10231.     LS sequence    number
  10232.     Detects    old or duplicate LSAs.    Successive instances of    an LSA
  10233.     are given successive LS    sequence numbers.  See Section 12.1.6
  10234.     for more details.
  10235.  
  10236.     LS checksum
  10237.     The Fletcher checksum of the complete contents of the LSA,
  10238.     including the LSA header but excluding the LS age field. See
  10239.     Section    12.1.7 for more    details.
  10240.  
  10241.     length
  10242.     The length in bytes of the LSA.     This includes the 20 byte LSA
  10243.     header.
  10244.  
  10245.  
  10246.  
  10247.  
  10248.  
  10249.  
  10250. Moy                Standards Track              [Page 205]
  10251.  
  10252. RFC 2328             OSPF Version 2              April 1998
  10253.  
  10254.  
  10255. A.4.2 Router-LSAs
  10256.  
  10257.     Router-LSAs    are the    Type 1 LSAs.  Each router in an    area originates
  10258.     a router-LSA.  The LSA describes the state and cost    of the router's
  10259.     links (i.e., interfaces) to    the area.  All of the router's links to
  10260.     the    area must be described in a single router-LSA.    For details
  10261.     concerning the construction    of router-LSAs,    see Section 12.4.1.
  10262.  
  10263.  
  10264.     0            1            2            3
  10265.     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
  10266.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10267.        |        LS age           |     Options   |       1       |
  10268.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10269.        |            Link State ID                   |
  10270.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10271.        |             Advertising Router                   |
  10272.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10273.        |             LS    sequence number                   |
  10274.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10275.        |     LS checksum           |         length           |
  10276.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10277.        |    0     |V|E|B|    0      |        # links           |
  10278.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10279.        |              Link ID                   |
  10280.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10281.        |             Link Data                   |
  10282.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10283.        |     Type      |     # TOS     |        metric           |
  10284.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10285.        |                  ...                   |
  10286.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10287.        |      TOS      |    0      |      TOS  metric           |
  10288.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10289.        |              Link ID                   |
  10290.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10291.        |             Link Data                   |
  10292.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10293.        |                  ...                   |
  10294.  
  10295.  
  10296.  
  10297.  
  10298.  
  10299.  
  10300. Moy                Standards Track              [Page 206]
  10301.  
  10302. RFC 2328             OSPF Version 2              April 1998
  10303.  
  10304.  
  10305.     In router-LSAs, the    Link State ID field is set to the router's OSPF
  10306.     Router ID. Router-LSAs are flooded throughout a single area    only.
  10307.  
  10308.     bit    V
  10309.     When set, the router is    an endpoint of one or more fully
  10310.     adjacent virtual links having the described area as Transit area
  10311.     (V is for virtual link endpoint).
  10312.  
  10313.     bit    E
  10314.     When set, the router is    an AS boundary router (E is for
  10315.     external).
  10316.  
  10317.     bit    B
  10318.     When set, the router is    an area    border router (B is for    border).
  10319.  
  10320.     # links
  10321.     The number of router links described in    this LSA.  This    must be
  10322.     the total collection of    router links (i.e., interfaces)    to the
  10323.     area.
  10324.  
  10325.  
  10326.     The    following fields are used to describe each router link (i.e.,
  10327.     interface).    Each router link is typed (see the below Type field).
  10328.     The    Type field indicates the kind of link being described.    It may
  10329.     be a link to a transit network, to another router or to a stub
  10330.     network.  The values of all    the other fields describing a router
  10331.     link depend    on the link's Type.  For example, each link has    an
  10332.     associated 32-bit Link Data    field.    For links to stub networks this
  10333.     field specifies the    network's IP address mask.  For    other link types
  10334.     the    Link Data field    specifies the router interface's IP address.
  10335.  
  10336.  
  10337.     Type
  10338.     A quick    description of the router link.     One of    the following.
  10339.     Note that host routes are classified as    links to stub networks
  10340.     with network mask of 0xffffffff.
  10341.  
  10342.  
  10343.  
  10344.  
  10345.  
  10346.  
  10347.  
  10348.  
  10349.  
  10350. Moy                Standards Track              [Page 207]
  10351.  
  10352. RFC 2328             OSPF Version 2              April 1998
  10353.  
  10354.  
  10355.  
  10356.          Type    Description
  10357.          __________________________________________________
  10358.          1    Point-to-point connection to another router
  10359.          2    Connection to a    transit    network
  10360.          3    Connection to a    stub network
  10361.          4    Virtual    link
  10362.  
  10363.  
  10364.  
  10365.  
  10366.     Link ID
  10367.     Identifies the object that this    router link connects to.  Value
  10368.     depends    on the link's Type.  When connecting to    an object that
  10369.     also originates    an LSA (i.e., another router or    a transit
  10370.     network) the Link ID is    equal to the neighboring LSA's Link
  10371.     State ID.  This    provides the key for looking up    the neighboring
  10372.     LSA in the link    state database during the routing table
  10373.     calculation. See Section 12.2 for more details.
  10374.  
  10375.  
  10376.  
  10377.                Type   Link ID
  10378.                ______________________________________
  10379.                1      Neighboring router's Router ID
  10380.                2      IP address of Designated Router
  10381.                3      IP network/subnet    number
  10382.                4      Neighboring router's Router ID
  10383.  
  10384.  
  10385.  
  10386.  
  10387.     Link Data
  10388.     Value again depends on the link's Type field. For connections to
  10389.     stub networks, Link Data specifies the network's IP address
  10390.     mask. For unnumbered point-to-point connections, it specifies
  10391.     the interface's    MIB-II [Ref8] ifIndex value. For the other link
  10392.     types it specifies the router interface's IP address. This
  10393.     latter piece of    information is needed during the routing table
  10394.     build process, when calculating    the IP address of the next hop.
  10395.     See Section 16.1.1 for more details.
  10396.  
  10397.  
  10398.  
  10399.  
  10400. Moy                Standards Track              [Page 208]
  10401.  
  10402. RFC 2328             OSPF Version 2              April 1998
  10403.  
  10404.  
  10405.     # TOS
  10406.     The number of different    TOS metrics given for this link, not
  10407.     counting the required link metric (referred to as the TOS 0
  10408.     metric in [Ref9]).  For    example, if no additional TOS metrics
  10409.     are given, this    field is set to    0.
  10410.  
  10411.     metric
  10412.     The cost of using this router link.
  10413.  
  10414.  
  10415.     Additional TOS-specific information    may also be included, for
  10416.     backward compatibility with    previous versions of the OSPF
  10417.     specification ([Ref9]). Within each    link, and for each desired TOS,
  10418.     TOS    TOS-specific link information may be encoded as    follows:
  10419.  
  10420.     TOS    IP Type    of Service that    this metric refers to.    The encoding of
  10421.     TOS in OSPF LSAs is described in Section 12.3.
  10422.  
  10423.     TOS    metric
  10424.     TOS-specific metric information.
  10425.  
  10426.  
  10427.  
  10428.  
  10429.  
  10430.  
  10431.  
  10432.  
  10433.  
  10434.  
  10435.  
  10436.  
  10437.  
  10438.  
  10439.  
  10440.  
  10441.  
  10442.  
  10443.  
  10444.  
  10445.  
  10446.  
  10447.  
  10448.  
  10449.  
  10450. Moy                Standards Track              [Page 209]
  10451.  
  10452. RFC 2328             OSPF Version 2              April 1998
  10453.  
  10454.  
  10455. A.4.3 Network-LSAs
  10456.  
  10457.     Network-LSAs are the Type 2    LSAs.  A network-LSA is    originated for
  10458.     each broadcast and NBMA network in the area    which supports two or
  10459.     more routers.  The network-LSA is originated by the    network's
  10460.     Designated Router.    The LSA    describes all routers attached to the
  10461.     network, including the Designated Router itself.  The LSA's    Link
  10462.     State ID field lists the IP    interface address of the Designated
  10463.     Router.
  10464.  
  10465.     The    distance from the network to all attached routers is zero.  This
  10466.     is why metric fields need not be specified in the network-LSA.  For
  10467.     details concerning the construction    of network-LSAs, see Section
  10468.     12.4.2.
  10469.  
  10470.  
  10471.     0            1            2            3
  10472.     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
  10473.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10474.        |        LS age           |      Options  |      2           |
  10475.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10476.        |            Link State ID                   |
  10477.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10478.        |             Advertising Router                   |
  10479.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10480.        |             LS    sequence number                   |
  10481.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10482.        |     LS checksum           |         length           |
  10483.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10484.        |             Network Mask                   |
  10485.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10486.        |            Attached Router                   |
  10487.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10488.        |                  ...                   |
  10489.  
  10490.  
  10491.  
  10492.     Network Mask
  10493.     The IP address mask for    the network.  For example, a class A
  10494.     network    would have the mask 0xff000000.
  10495.  
  10496.  
  10497.  
  10498.  
  10499.  
  10500. Moy                Standards Track              [Page 210]
  10501.  
  10502. RFC 2328             OSPF Version 2              April 1998
  10503.  
  10504.  
  10505.     Attached Router
  10506.     The Router IDs of each of the routers attached to the network.
  10507.     Actually, only those routers that are fully adjacent to    the
  10508.     Designated Router are listed.  The Designated Router includes
  10509.     itself in this list.  The number of routers included can be
  10510.     deduced    from the LSA header's length field.
  10511.  
  10512.  
  10513.  
  10514.  
  10515.  
  10516.  
  10517.  
  10518.  
  10519.  
  10520.  
  10521.  
  10522.  
  10523.  
  10524.  
  10525.  
  10526.  
  10527.  
  10528.  
  10529.  
  10530.  
  10531.  
  10532.  
  10533.  
  10534.  
  10535.  
  10536.  
  10537.  
  10538.  
  10539.  
  10540.  
  10541.  
  10542.  
  10543.  
  10544.  
  10545.  
  10546.  
  10547.  
  10548.  
  10549.  
  10550. Moy                Standards Track              [Page 211]
  10551.  
  10552. RFC 2328             OSPF Version 2              April 1998
  10553.  
  10554.  
  10555. A.4.4 Summary-LSAs
  10556.  
  10557.     Summary-LSAs are the Type 3    and 4 LSAs.  These LSAs    are originated
  10558.     by area border routers. Summary-LSAs describe inter-area
  10559.     destinations.  For details concerning the construction of summary-
  10560.     LSAs, see Section 12.4.3.
  10561.  
  10562.     Type 3 summary-LSAs    are used when the destination is an IP network.
  10563.     In this case the LSA's Link    State ID field is an IP    network    number
  10564.     (if    necessary, the Link State ID can also have one or more of the
  10565.     network's "host" bits set; see Appendix E for details). When the
  10566.     destination    is an AS boundary router, a Type 4 summary-LSA is used,
  10567.     and    the Link State ID field    is the AS boundary router's OSPF Router
  10568.     ID.     (To see why it    is necessary to    advertise the location of each
  10569.     ASBR, consult Section 16.4.)  Other    than the difference in the Link
  10570.     State ID field, the    format of Type 3 and 4 summary-LSAs is
  10571.     identical.
  10572.  
  10573.  
  10574.     0            1            2            3
  10575.     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
  10576.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10577.        |        LS age           |     Options   |    3 or 4     |
  10578.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10579.        |            Link State ID                   |
  10580.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10581.        |             Advertising Router                   |
  10582.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10583.        |             LS    sequence number                   |
  10584.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10585.        |     LS checksum           |         length           |
  10586.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10587.        |             Network Mask                   |
  10588.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10589.        |      0           |          metric               |
  10590.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10591.        |     TOS       |        TOS  metric               |
  10592.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10593.        |                  ...                   |
  10594.  
  10595.  
  10596.  
  10597.  
  10598.  
  10599.  
  10600. Moy                Standards Track              [Page 212]
  10601.  
  10602. RFC 2328             OSPF Version 2              April 1998
  10603.  
  10604.  
  10605.     For    stub areas, Type 3 summary-LSAs    can also be used to describe a
  10606.     (per-area) default route.  Default summary routes are used in stub
  10607.     areas instead of flooding a    complete set of    external routes.  When
  10608.     describing a default summary route,    the summary-LSA's Link State ID
  10609.     is always set to DefaultDestination    (0.0.0.0) and the Network Mask
  10610.     is set to 0.0.0.0.
  10611.  
  10612.     Network Mask
  10613.     For Type 3 summary-LSAs, this indicates    the destination
  10614.     network's IP address mask.  For    example, when advertising the
  10615.     location of a class A network the value    0xff000000 would be
  10616.     used.  This field is not meaningful and    must be    zero for Type 4
  10617.     summary-LSAs.
  10618.  
  10619.     metric
  10620.     The cost of this route.     Expressed in the same units as    the
  10621.     interface costs    in the router-LSAs.
  10622.  
  10623.     Additional TOS-specific information    may also be included, for
  10624.     backward compatibility with    previous versions of the OSPF
  10625.     specification ([Ref9]). For    each desired TOS, TOS-specific
  10626.     information    is encoded as follows:
  10627.  
  10628.     TOS    IP Type    of Service that    this metric refers to.    The encoding of
  10629.     TOS in OSPF LSAs is described in Section 12.3.
  10630.  
  10631.     TOS    metric
  10632.     TOS-specific metric information.
  10633.  
  10634.  
  10635.  
  10636.  
  10637.  
  10638.  
  10639.  
  10640.  
  10641.  
  10642.  
  10643.  
  10644.  
  10645.  
  10646.  
  10647.  
  10648.  
  10649.  
  10650. Moy                Standards Track              [Page 213]
  10651.  
  10652. RFC 2328             OSPF Version 2              April 1998
  10653.  
  10654.  
  10655. A.4.5 AS-external-LSAs
  10656.  
  10657.     AS-external-LSAs are the Type 5 LSAs.  These LSAs are originated by
  10658.     AS boundary    routers, and describe destinations external to the AS.
  10659.     For    details    concerning the construction of AS-external-LSAs, see
  10660.     Section 12.4.3.
  10661.  
  10662.     AS-external-LSAs usually describe a    particular external destination.
  10663.     For    these LSAs the Link State ID field specifies an    IP network
  10664.     number (if necessary, the Link State ID can    also have one or more of
  10665.     the    network's "host" bits set; see Appendix    E for details).     AS-
  10666.     external-LSAs are also used    to describe a default route.  Default
  10667.     routes are used when no specific route exists to the destination.
  10668.     When describing a default route, the Link State ID is always set to
  10669.     DefaultDestination (0.0.0.0) and the Network Mask is set to    0.0.0.0.
  10670.  
  10671.  
  10672.     0            1            2            3
  10673.     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
  10674.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10675.        |        LS age           |     Options   |      5           |
  10676.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10677.        |            Link State ID                   |
  10678.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10679.        |             Advertising Router                   |
  10680.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10681.        |             LS    sequence number                   |
  10682.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10683.        |     LS checksum           |         length           |
  10684.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10685.        |             Network Mask                   |
  10686.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10687.        |E|     0       |          metric               |
  10688.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10689.        |              Forwarding address               |
  10690.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10691.        |              External Route Tag               |
  10692.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10693.        |E|    TOS      |        TOS  metric               |
  10694.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10695.        |              Forwarding address               |
  10696.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10697.  
  10698.  
  10699.  
  10700. Moy                Standards Track              [Page 214]
  10701.  
  10702. RFC 2328             OSPF Version 2              April 1998
  10703.  
  10704.  
  10705.        |              External Route Tag               |
  10706.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  10707.        |                  ...                   |
  10708.  
  10709.  
  10710.  
  10711.     Network Mask
  10712.     The IP address mask for    the advertised destination.  For
  10713.     example, when advertising a class A network the    mask 0xff000000
  10714.     would be used.
  10715.  
  10716.     bit    E
  10717.     The type of external metric.  If bit E is set, the metric
  10718.     specified is a Type 2 external metric.    This means the metric is
  10719.     considered larger than any link    state path.  If    bit E is zero,
  10720.     the specified metric is    a Type 1 external metric.  This    means
  10721.     that it    is expressed in    the same units as the link state metric
  10722.     (i.e., the same    units as interface cost).
  10723.  
  10724.     metric
  10725.     The cost of this route.     Interpretation    depends    on the external
  10726.     type indication    (bit E above).
  10727.  
  10728.     Forwarding address
  10729.     Data traffic for the advertised    destination will be forwarded to
  10730.     this address.  If the Forwarding address is set    to 0.0.0.0, data
  10731.     traffic    will be    forwarded instead to the LSA's originator (i.e.,
  10732.     the responsible    AS boundary router).
  10733.  
  10734.     External Route Tag
  10735.     A 32-bit field attached    to each    external route.     This is not
  10736.     used by    the OSPF protocol itself.  It may be used to communicate
  10737.     information between AS boundary    routers; the precise nature of
  10738.     such information is outside the    scope of this specification.
  10739.  
  10740.     Additional TOS-specific information    may also be included, for
  10741.     backward compatibility with    previous versions of the OSPF
  10742.     specification ([Ref9]). For    each desired TOS, TOS-specific
  10743.     information    is encoded as follows:
  10744.  
  10745.     TOS    The Type of Service that the following fields concern.    The
  10746.     encoding of TOS    in OSPF    LSAs is    described in Section 12.3.
  10747.  
  10748.  
  10749.  
  10750. Moy                Standards Track              [Page 215]
  10751.  
  10752. RFC 2328             OSPF Version 2              April 1998
  10753.  
  10754.  
  10755.     bit    E
  10756.     For backward-compatibility with    [Ref9].
  10757.  
  10758.     TOS    metric
  10759.     TOS-specific metric information.
  10760.  
  10761.     Forwarding address
  10762.     For backward-compatibility with    [Ref9].
  10763.  
  10764.     External Route Tag
  10765.     For backward-compatibility with    [Ref9].
  10766.  
  10767.  
  10768.  
  10769.  
  10770.  
  10771.  
  10772.  
  10773.  
  10774.  
  10775.  
  10776.  
  10777.  
  10778.  
  10779.  
  10780.  
  10781.  
  10782.  
  10783.  
  10784.  
  10785.  
  10786.  
  10787.  
  10788.  
  10789.  
  10790.  
  10791.  
  10792.  
  10793.  
  10794.  
  10795.  
  10796.  
  10797.  
  10798.  
  10799.  
  10800. Moy                Standards Track              [Page 216]
  10801.  
  10802. RFC 2328             OSPF Version 2              April 1998
  10803.  
  10804.  
  10805. B. Architectural Constants
  10806.  
  10807.     Several OSPF protocol parameters have fixed    architectural values.
  10808.     These parameters have been referred    to in the text by names    such as
  10809.     LSRefreshTime.  The    same naming convention is used for the
  10810.     configurable protocol parameters.  They are    defined    in Appendix C.
  10811.  
  10812.     The    name of    each architectural constant follows, together with its
  10813.     value and a    short description of its function.
  10814.  
  10815.  
  10816.     LSRefreshTime
  10817.     The maximum time between distinct originations of any particular
  10818.     LSA.  If the LS    age field of one of the    router's self-originated
  10819.     LSAs reaches the value LSRefreshTime, a    new instance of    the LSA
  10820.     is originated, even though the contents    of the LSA (apart from
  10821.     the LSA    header)    will be    the same.  The value of    LSRefreshTime is
  10822.     set to 30 minutes.
  10823.  
  10824.     MinLSInterval
  10825.     The minimum time between distinct originations of any particular
  10826.     LSA.  The value    of MinLSInterval is set    to 5 seconds.
  10827.  
  10828.     MinLSArrival
  10829.     For any    particular LSA,    the minimum time that must elapse
  10830.     between    reception of new LSA instances during flooding.    LSA
  10831.     instances received at higher frequencies are discarded.    The
  10832.     value of MinLSArrival is set to    1 second.
  10833.  
  10834.     MaxAge
  10835.     The maximum age    that an    LSA can    attain.    When an    LSA's LS age
  10836.     field reaches MaxAge, it is reflooded in an attempt to flush the
  10837.     LSA from the routing domain (See Section 14). LSAs of age MaxAge
  10838.     are not    used in    the routing table calculation.    The value of
  10839.     MaxAge is set to 1 hour.
  10840.  
  10841.     CheckAge
  10842.     When the age of    an LSA in the link state database hits a
  10843.     multiple of CheckAge, the LSA's    checksum is verified.  An
  10844.     incorrect checksum at this time    indicates a serious error.  The
  10845.     value of CheckAge is set to 5 minutes.
  10846.  
  10847.  
  10848.  
  10849.  
  10850. Moy                Standards Track              [Page 217]
  10851.  
  10852. RFC 2328             OSPF Version 2              April 1998
  10853.  
  10854.  
  10855.     MaxAgeDiff
  10856.     The maximum time dispersion that can occur, as an LSA is flooded
  10857.     throughout the AS.  Most of this time is accounted for by the
  10858.     LSAs sitting on    router output queues (and therefore not    aging)
  10859.     during the flooding process.  The value    of MaxAgeDiff is set to
  10860.     15 minutes.
  10861.  
  10862.     LSInfinity
  10863.     The metric value indicating that the destination described by an
  10864.     LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as
  10865.     an alternative to premature aging (see Section 14.1). It is
  10866.     defined    to be the 24-bit binary    value of all ones: 0xffffff.
  10867.  
  10868.     DefaultDestination
  10869.     The Destination    ID that    indicates the default route.  This route
  10870.     is used    when no    other matching routing table entry can be found.
  10871.     The default destination    can only be advertised in AS-external-
  10872.     LSAs and in stub areas'    type 3 summary-LSAs.  Its value    is the
  10873.     IP address 0.0.0.0. Its    associated Network Mask    is also    always
  10874.     0.0.0.0.
  10875.  
  10876.     InitialSequenceNumber
  10877.     The value used for LS Sequence Number when originating the first
  10878.     instance of any    LSA. Its value is the signed 32-bit integer
  10879.     0x80000001.
  10880.  
  10881.     MaxSequenceNumber
  10882.     The maximum value that LS Sequence Number can attain.  Its value
  10883.     is the signed 32-bit integer 0x7fffffff.
  10884.  
  10885.  
  10886.  
  10887.  
  10888.  
  10889.  
  10890.  
  10891.  
  10892.  
  10893.  
  10894.  
  10895.  
  10896.  
  10897.  
  10898.  
  10899.  
  10900. Moy                Standards Track              [Page 218]
  10901.  
  10902. RFC 2328             OSPF Version 2              April 1998
  10903.  
  10904.  
  10905. C. Configurable    Constants
  10906.  
  10907.     The    OSPF protocol has quite    a few configurable parameters.    These
  10908.     parameters are listed below.  They are grouped into    general
  10909.     functional categories (area    parameters, interface parameters, etc.).
  10910.     Sample values are given for    some of    the parameters.
  10911.  
  10912.     Some parameter settings need to be consistent among    groups of
  10913.     routers.  For example, all routers in an area must agree on    that
  10914.     area's parameters, and all routers attached    to a network must agree
  10915.     on that network's IP network number    and mask.
  10916.  
  10917.     Some parameters may    be determined by router    algorithms outside of
  10918.     this specification (e.g., the address of a host connected to the
  10919.     router via a SLIP line).  From OSPF's point    of view, these items are
  10920.     still configurable.
  10921.  
  10922.     C.1    Global parameters
  10923.  
  10924.     In general, a separate copy of the OSPF    protocol is run    for each
  10925.     area.  Because of this,    most configuration parameters are
  10926.     defined    on a per-area basis.  The few global configuration
  10927.     parameters are listed below.
  10928.  
  10929.  
  10930.     Router ID
  10931.         This is a 32-bit number that uniquely identifies the router
  10932.         in the Autonomous System.  One algorithm for Router    ID
  10933.         assignment is to choose the    largest    or smallest IP address
  10934.         assigned to    the router.  If    a router's OSPF    Router ID is
  10935.         changed, the router's OSPF software    should be restarted
  10936.         before the new Router ID takes effect. Before restarting in
  10937.         order to change its    Router ID, the router should flush its
  10938.         self-originated LSAs from the routing domain (see Section
  10939.         14.1), or they will    persist    for up to MaxAge minutes.
  10940.  
  10941.     RFC1583Compatibility
  10942.         Controls the preference rules used in Section 16.4 when
  10943.         choosing among multiple AS-external-LSAs advertising the
  10944.         same destination. When set to "enabled", the preference
  10945.         rules remain those specified by RFC    1583 ([Ref9]). When set
  10946.         to "disabled", the preference rules    are those stated in
  10947.  
  10948.  
  10949.  
  10950. Moy                Standards Track              [Page 219]
  10951.  
  10952. RFC 2328             OSPF Version 2              April 1998
  10953.  
  10954.  
  10955.         Section 16.4.1, which prevent routing loops    when AS-
  10956.         external-LSAs for the same destination have    been originated
  10957.         from different areas. Set to "enabled" by default.
  10958.  
  10959.         In order to    minimize the chance of routing loops, all OSPF
  10960.         routers in an OSPF routing domain should have
  10961.         RFC1583Compatibility set identically. When there are routers
  10962.         present that have not been updated with the    functionality
  10963.         specified in Section 16.4.1    of this    memo, all routers should
  10964.         have RFC1583Compatibility set to "enabled".    Otherwise, all
  10965.         routers should have    RFC1583Compatibility set to "disabled",
  10966.         preventing all routing loops.
  10967.  
  10968.     C.2    Area parameters
  10969.  
  10970.     All routers belonging to an area must agree on that area's
  10971.     configuration.    Disagreements between two routers will lead to
  10972.     an inability for adjacencies to    form between them, with    a
  10973.     resulting hindrance to the flow    of routing protocol and    data
  10974.     traffic.  The following    items must be configured for an    area:
  10975.  
  10976.  
  10977.     Area ID
  10978.         This is a 32-bit number that identifies the    area.  The Area
  10979.         ID of 0.0.0.0 is reserved for the backbone.     If the    area
  10980.         represents a subnetted network, the    IP network number of the
  10981.         subnetted network may be used for the Area ID.
  10982.  
  10983.     List of    address    ranges
  10984.         An OSPF area is defined as a list of address ranges. Each
  10985.         address range consists of the following items:
  10986.  
  10987.         [IP    address, mask]
  10988.             Describes the collection of    IP addresses contained
  10989.             in the address range. Networks and hosts are
  10990.             assigned to    an area    depending on whether their
  10991.             addresses fall into    one of the area's defining
  10992.             address ranges.  Routers are viewed    as belonging to
  10993.             multiple areas, depending on their attached
  10994.             networks' area membership.
  10995.  
  10996.  
  10997.  
  10998.  
  10999.  
  11000. Moy                Standards Track              [Page 220]
  11001.  
  11002. RFC 2328             OSPF Version 2              April 1998
  11003.  
  11004.  
  11005.         Status  Set    to either Advertise or DoNotAdvertise.    Routing
  11006.             information    is condensed at    area boundaries.
  11007.             External to    the area, at most a single route is
  11008.             advertised (via a summary-LSA) for each address
  11009.             range. The route is    advertised if and only if the
  11010.             address range's Status is set to Advertise.
  11011.             Unadvertised ranges    allow the existence of certain
  11012.             networks to    be intentionally hidden    from other
  11013.             areas. Status is set to Advertise by default.
  11014.  
  11015.         As an example, suppose an IP subnetted network is to be its
  11016.         own    OSPF area.  The    area would be configured as a single
  11017.         address range, whose IP address is the address of the
  11018.         subnetted network, and whose mask is the natural class A, B,
  11019.         or C address mask.    A single route would be    advertised
  11020.         external to    the area, describing the entire    subnetted
  11021.         network.
  11022.  
  11023.     ExternalRoutingCapability
  11024.         Whether AS-external-LSAs will be flooded into/throughout the
  11025.         area.  If AS-external-LSAs are excluded from the area, the
  11026.         area is called a "stub".  Internal to stub areas, routing to
  11027.         external destinations will be based    solely on a default
  11028.         summary route.  The    backbone cannot    be configured as a stub
  11029.         area.  Also, virtual links cannot be configured through stub
  11030.         areas.  For    more information, see Section 3.6.
  11031.  
  11032.     StubDefaultCost
  11033.         If the area    has been configured as a stub area, and    the
  11034.         router itself is an    area border router, then the
  11035.         StubDefaultCost indicates the cost of the default summary-
  11036.         LSA    that the router    should advertise into the area.
  11037.  
  11038.     C.3    Router interface parameters
  11039.  
  11040.     Some of    the configurable router    interface parameters (such as IP
  11041.     interface address and subnet mask) actually imply properties of
  11042.     the attached networks, and therefore must be consistent    across
  11043.     all the    routers    attached to that network.  The parameters that
  11044.     must be    configured for a router    interface are:
  11045.  
  11046.  
  11047.  
  11048.  
  11049.  
  11050. Moy                Standards Track              [Page 221]
  11051.  
  11052. RFC 2328             OSPF Version 2              April 1998
  11053.  
  11054.  
  11055.     IP interface address
  11056.         The    IP protocol address for    this interface.     This uniquely
  11057.         identifies the router over the entire internet.  An    IP
  11058.         address is not required on point-to-point networks.     Such a
  11059.         point-to-point network is called "unnumbered".
  11060.  
  11061.     IP interface mask
  11062.         Also referred to as    the subnet/network mask, this indicates
  11063.         the    portion    of the IP interface address that identifies the
  11064.         attached network.  Masking the IP interface    address    with the
  11065.         IP interface mask yields the IP network number of the
  11066.         attached network.  On point-to-point networks and virtual
  11067.         links, the IP interface mask is not    defined. On these
  11068.         networks, the link itself is not assigned an IP network
  11069.         number, and    so the addresses of each side of the link are
  11070.         assigned independently, if they are    assigned at all.
  11071.  
  11072.     Area ID
  11073.         The    OSPF area to which the attached    network    belongs.
  11074.  
  11075.     Interface output cost
  11076.         The    cost of    sending    a packet on the    interface, expressed in
  11077.         the    link state metric.  This is advertised as the link cost
  11078.         for    this interface in the router's router-LSA. The interface
  11079.         output cost    must always be greater than 0.
  11080.  
  11081.     RxmtInterval
  11082.         The    number of seconds between LSA retransmissions, for
  11083.         adjacencies    belonging to this interface.  Also used    when
  11084.         retransmitting Database Description    and Link State Request
  11085.         Packets.  This should be well over the expected round-trip
  11086.         delay between any two routers on the attached network.  The
  11087.         setting of this value should be conservative or needless
  11088.         retransmissions will result.  Sample value for a local area
  11089.         network: 5 seconds.
  11090.  
  11091.     InfTransDelay
  11092.         The    estimated number of seconds it takes to    transmit a Link
  11093.         State Update Packet    over this interface.  LSAs contained in
  11094.         the    update packet must have    their age incremented by this
  11095.         amount before transmission.     This value should take    into
  11096.         account the    transmission and propagation delays of the
  11097.  
  11098.  
  11099.  
  11100. Moy                Standards Track              [Page 222]
  11101.  
  11102. RFC 2328             OSPF Version 2              April 1998
  11103.  
  11104.  
  11105.         interface.    It must    be greater than    0.  Sample value for a
  11106.         local area network:    1 second.
  11107.  
  11108.     Router Priority
  11109.         An 8-bit unsigned integer.    When two routers attached to a
  11110.         network both attempt to become Designated Router, the one
  11111.         with the highest Router Priority takes precedence.    If there
  11112.         is still a tie, the    router with the    highest    Router ID takes
  11113.         precedence.     A router whose    Router Priority    is set to 0 is
  11114.         ineligible to become Designated Router on the attached
  11115.         network.  Router Priority is only configured for interfaces
  11116.         to broadcast and NBMA networks.
  11117.  
  11118.     HelloInterval
  11119.         The    length of time,    in seconds, between the    Hello Packets
  11120.         that the router sends on the interface.  This value    is
  11121.         advertised in the router's Hello Packets.  It must be the
  11122.         same for all routers attached to a common network.    The
  11123.         smaller the    HelloInterval, the faster topological changes
  11124.         will be detected; however, more OSPF routing protocol
  11125.         traffic will ensue.     Sample    value for a X.25 PDN network: 30
  11126.         seconds.  Sample value for a local area network: 10    seconds.
  11127.  
  11128.     RouterDeadInterval
  11129.         After ceasing to hear a router's Hello Packets, the    number
  11130.         of seconds before its neighbors declare the    router down.
  11131.         This is also advertised in the router's Hello Packets in
  11132.         their RouterDeadInterval field.  This should be some
  11133.         multiple of    the HelloInterval (say 4).  This value again
  11134.         must be the    same for all routers attached to a common
  11135.         network.
  11136.  
  11137.     AuType
  11138.         Identifies the authentication procedure to be used on the
  11139.         attached network.  This value must be the same for all
  11140.         routers attached to    the network.  See Appendix D for a
  11141.         discussion of the defined authentication types.
  11142.  
  11143.     Authentication key
  11144.         This configured data allows    the authentication procedure to
  11145.         verify OSPF    protocol packets received over the interface.
  11146.         For    example, if the    AuType indicates simple    password, the
  11147.  
  11148.  
  11149.  
  11150. Moy                Standards Track              [Page 223]
  11151.  
  11152. RFC 2328             OSPF Version 2              April 1998
  11153.  
  11154.  
  11155.         Authentication key would be    a clear    64-bit password.
  11156.         Authentication keys    associated with    the other OSPF
  11157.         authentication types are discussed in Appendix D.
  11158.  
  11159.     C.4    Virtual    link parameters
  11160.  
  11161.     Virtual    links are used to restore/increase connectivity    of the
  11162.     backbone.  Virtual links may be    configured between any pair of
  11163.     area border routers having interfaces to a common (non-backbone)
  11164.     area.  The virtual link    appears    as an unnumbered point-to-point
  11165.     link in    the graph for the backbone.  The virtual link must be
  11166.     configured in both of the area border routers.
  11167.  
  11168.     A virtual link appears in router-LSAs (for the backbone) as if
  11169.     it were    a separate router interface to the backbone.  As such,
  11170.     it has all of the parameters associated    with a router interface
  11171.     (see Section C.3).  Although a virtual link acts like an
  11172.     unnumbered point-to-point link,    it does    have an    associated IP
  11173.     interface address.  This address is used as the    IP source in
  11174.     OSPF protocol packets it sends along the virtual link, and is
  11175.     set dynamically    during the routing table build process.
  11176.     Interface output cost is also set dynamically on virtual links
  11177.     to be the cost of the intra-area path between the two routers.
  11178.     The parameter RxmtInterval must    be configured, and should be
  11179.     well over the expected round-trip delay    between    the two    routers.
  11180.     This may be hard to estimate for a virtual link; it is better to
  11181.     err on the side    of making it too large.     Router    Priority is not
  11182.     used on    virtual    links.
  11183.  
  11184.     A virtual link is defined by the following two configurable
  11185.     parameters: the    Router ID of the virtual link's    other endpoint,
  11186.     and the    (non-backbone) area through which the virtual link runs
  11187.     (referred to as    the virtual link's Transit area).  Virtual links
  11188.     cannot be configured through stub areas.
  11189.  
  11190.     C.5    NBMA network parameters
  11191.  
  11192.     OSPF treats an NBMA network much like it treats    a broadcast
  11193.     network.  Since    there may be many routers attached to the
  11194.     network, a Designated Router is    selected for the network.  This
  11195.     Designated Router then originates a network-LSA, which lists all
  11196.     routers    attached to the    NBMA network.
  11197.  
  11198.  
  11199.  
  11200. Moy                Standards Track              [Page 224]
  11201.  
  11202. RFC 2328             OSPF Version 2              April 1998
  11203.  
  11204.  
  11205.     However, due to    the lack of broadcast capabilities, it may be
  11206.     necessary to use configuration parameters in the Designated
  11207.     Router selection.  These parameters will only need to be
  11208.     configured in those routers that are themselves    eligible to
  11209.     become Designated Router (i.e.,    those router's whose Router
  11210.     Priority for the network is non-zero), and then    only if    no
  11211.     automatic procedure for    discovering neighbors exists:
  11212.  
  11213.  
  11214.     List of    all other attached routers
  11215.         The    list of    all other routers attached to the NBMA network.
  11216.         Each router    is listed by its IP interface address on the
  11217.         network.  Also, for    each router listed, that router's
  11218.         eligibility    to become Designated Router must be defined.
  11219.         When an interface to a NBMA    network    comes up, the router
  11220.         sends Hello    Packets    only to    those neighbors    eligible to
  11221.         become Designated Router, until the    identity of the
  11222.         Designated Router is discovered.
  11223.  
  11224.     PollInterval
  11225.         If a neighboring router has    become inactive    (Hello Packets
  11226.         have not been seen for RouterDeadInterval seconds),    it may
  11227.         still be necessary to send Hello Packets to    the dead
  11228.         neighbor.  These Hello Packets will    be sent    at the reduced
  11229.         rate PollInterval, which should be much larger than
  11230.         HelloInterval.  Sample value for a PDN X.25    network: 2
  11231.         minutes.
  11232.  
  11233.     C.6    Point-to-MultiPoint network parameters
  11234.  
  11235.     On Point-to-MultiPoint networks, it may    be necessary to
  11236.     configure the set of neighbors that are    directly reachable over
  11237.     the Point-to-MultiPoint    network. Each neighbor is identified by
  11238.     its IP address on the Point-to-MultiPoint network. Designated
  11239.     Routers    are not    elected    on Point-to-MultiPoint networks, so the
  11240.     Designated Router eligibility of configured neighbors is
  11241.     undefined.
  11242.  
  11243.     Alternatively, neighbors on Point-to-MultiPoint    networks may be
  11244.     dynamically discovered by lower-level protocols    such as    Inverse
  11245.     ARP ([Ref14]).
  11246.  
  11247.  
  11248.  
  11249.  
  11250. Moy                Standards Track              [Page 225]
  11251.  
  11252. RFC 2328             OSPF Version 2              April 1998
  11253.  
  11254.  
  11255.     C.7    Host route parameters
  11256.  
  11257.     Host routes are    advertised in router-LSAs as stub networks with
  11258.     mask 0xffffffff.  They indicate    either router interfaces to
  11259.     point-to-point networks, looped    router interfaces, or IP hosts
  11260.     that are directly connected to the router (e.g., via a SLIP
  11261.     line).    For each host directly connected to the    router,    the
  11262.     following items    must be    configured:
  11263.  
  11264.  
  11265.     Host IP    address
  11266.         The    IP address of the host.
  11267.  
  11268.     Cost of    link to    host
  11269.         The    cost of    sending    a packet to the    host, in terms of the
  11270.         link state metric.    However, since the host    probably has
  11271.         only a single connection to    the internet, the actual
  11272.         configured cost in many cases is unimportant (i.e.,    will
  11273.         have no effect on routing).
  11274.  
  11275.     Area ID
  11276.         The    OSPF area to which the host belongs.
  11277.  
  11278.  
  11279.  
  11280.  
  11281.  
  11282.  
  11283.  
  11284.  
  11285.  
  11286.  
  11287.  
  11288.  
  11289.  
  11290.  
  11291.  
  11292.  
  11293.  
  11294.  
  11295.  
  11296.  
  11297.  
  11298.  
  11299.  
  11300. Moy                Standards Track              [Page 226]
  11301.  
  11302. RFC 2328             OSPF Version 2              April 1998
  11303.  
  11304.  
  11305. D. Authentication
  11306.  
  11307.     All    OSPF protocol exchanges    are authenticated.  The    OSPF packet
  11308.     header (see    Section    A.3.1) includes    an authentication type field,
  11309.     and    64-bits    of data    for use    by the appropriate authentication scheme
  11310.     (determined    by the type field).
  11311.  
  11312.     The    authentication type is configurable on a per-interface (or
  11313.     equivalently, on a per-network/subnet) basis.  Additional
  11314.     authentication data    is also    configurable on    a per-interface    basis.
  11315.  
  11316.     Authentication types 0, 1 and 2 are    defined    by this    specification.
  11317.     All    other authentication types are reserved    for definition by the
  11318.     IANA (iana@ISI.EDU).  The current list of authentication types is
  11319.     described below in Table 20.
  11320.  
  11321.  
  11322.  
  11323.           AuType       Description
  11324.           ___________________________________________
  11325.           0           Null authentication
  11326.           1           Simple password
  11327.           2           Cryptographic authentication
  11328.           All others   Reserved    for assignment by the
  11329.                    IANA (iana@ISI.EDU)
  11330.  
  11331.  
  11332.               Table 20:    OSPF authentication types.
  11333.  
  11334.  
  11335.  
  11336.     D.1    Null authentication
  11337.  
  11338.     Use of this authentication type    means that routing exchanges
  11339.     over the network/subnet    are not    authenticated.    The 64-bit
  11340.     authentication field in    the OSPF header    can contain anything; it
  11341.     is not examined    on packet reception. When employing Null
  11342.     authentication,    the entire contents of each OSPF packet    (other
  11343.     than the 64-bit    authentication field) are checksummed in order
  11344.     to detect data corruption.
  11345.  
  11346.  
  11347.  
  11348.  
  11349.  
  11350. Moy                Standards Track              [Page 227]
  11351.  
  11352. RFC 2328             OSPF Version 2              April 1998
  11353.  
  11354.  
  11355.     D.2    Simple password    authentication
  11356.  
  11357.     Using this authentication type,    a 64-bit field is configured on
  11358.     a per-network basis.  All packets sent on a particular network
  11359.     must have this configured value    in their OSPF header 64-bit
  11360.     authentication field.  This essentially    serves as a "clear" 64-
  11361.     bit password. In addition, the entire contents of each OSPF
  11362.     packet (other than the 64-bit authentication field) are
  11363.     checksummed in order to    detect data corruption.
  11364.  
  11365.     Simple password    authentication guards against routers
  11366.     inadvertently joining the routing domain; each router must first
  11367.     be configured with its attached    networks' passwords before it
  11368.     can participate    in routing.  However, simple password
  11369.     authentication is vulnerable to    passive    attacks    currently
  11370.     widespread in the Internet (see    [Ref16]). Anyone with physical
  11371.     access to the network can learn    the password and compromise the
  11372.     security of the    OSPF routing domain.
  11373.  
  11374.     D.3    Cryptographic authentication
  11375.  
  11376.     Using this authentication type,    a shared secret    key is
  11377.     configured in all routers attached to a    common network/subnet.
  11378.     For each OSPF protocol packet, the key is used to
  11379.     generate/verify    a "message digest" that    is appended to the end
  11380.     of the OSPF packet. The    message    digest is a one-way function of
  11381.     the OSPF protocol packet and the secret    key. Since the secret
  11382.     key is never sent over the network in the clear, protection is
  11383.     provided against passive attacks.
  11384.  
  11385.     The algorithms used to generate    and verify the message digest
  11386.     are specified implicitly by the    secret key. This specification
  11387.     completely defines the use of OSPF Cryptographic authentication
  11388.     when the MD5 algorithm is used.
  11389.  
  11390.     In addition, a non-decreasing sequence number is included in
  11391.     each OSPF protocol packet to protect against replay attacks.
  11392.     This provides long term    protection; however, it    is still
  11393.     possible to replay an OSPF packet until    the sequence number
  11394.     changes. To implement this feature, each neighbor data structure
  11395.     contains a new field called the    "cryptographic sequence    number".
  11396.     This field is initialized to zero, and is also set to zero
  11397.  
  11398.  
  11399.  
  11400. Moy                Standards Track              [Page 228]
  11401.  
  11402. RFC 2328             OSPF Version 2              April 1998
  11403.  
  11404.  
  11405.  
  11406.  
  11407.     0            1            2            3
  11408.     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
  11409.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  11410.        |          0               |    Key    ID     | Auth Data Len |
  11411.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  11412.        |         Cryptographic sequence    number               |
  11413.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  11414.  
  11415.            Figure 18: Usage of the Authentication field
  11416.            in the OSPF packet header when Cryptographic
  11417.               Authentication is employed
  11418.  
  11419.     whenever the neighbor's    state transitions to "Down". Whenever an
  11420.     OSPF packet is accepted    as authentic, the cryptographic    sequence
  11421.     number is set to the received packet's sequence    number.
  11422.  
  11423.     This specification does    not provide a rollover procedure for the
  11424.     cryptographic sequence number. When the    cryptographic sequence
  11425.     number that the    router is sending hits the maximum value, the
  11426.     router should reset the    cryptographic sequence number that it is
  11427.     sending    back to    0. After this is done, the router's neighbors
  11428.     will reject the    router's OSPF packets for a period of
  11429.     RouterDeadInterval, and    then the router    will be    forced to
  11430.     reestablish all    adjacencies over the interface.    However, it is
  11431.     expected that many implementations will    use "seconds since
  11432.     reboot"    (or "seconds since 1960", etc.)    as the cryptographic
  11433.     sequence number. Such a    choice will essentially    prevent
  11434.     rollover, since    the cryptographic sequence number field    is 32
  11435.     bits in    length.
  11436.  
  11437.     The OSPF Cryptographic authentication option does not provide
  11438.     confidentiality.
  11439.  
  11440.     When cryptographic authentication is used, the 64-bit
  11441.     Authentication field in    the standard OSPF packet header    is
  11442.     redefined as shown in Figure 18. The new field definitions are
  11443.     as follows:
  11444.  
  11445.  
  11446.  
  11447.  
  11448.  
  11449.  
  11450. Moy                Standards Track              [Page 229]
  11451.  
  11452. RFC 2328             OSPF Version 2              April 1998
  11453.  
  11454.  
  11455.     Key ID
  11456.         This field identifies the algorithm    and secret key used to
  11457.         create the message digest appended to the OSPF packet. Key
  11458.         Identifiers    are unique per-interface (or equivalently, per-
  11459.         subnet).
  11460.  
  11461.     Auth Data Len
  11462.         The    length in bytes    of the message digest appended to the
  11463.         OSPF packet.
  11464.  
  11465.     Cryptographic sequence number
  11466.         An unsigned    32-bit non-decreasing sequence number. Used to
  11467.         guard against replay attacks.
  11468.  
  11469.     The message digest appended to the OSPF    packet is not actually
  11470.     considered part    of the OSPF protocol packet: the message digest
  11471.     is not included    in the OSPF header's packet length, although it
  11472.     is included in the packet's IP header length field.
  11473.  
  11474.     Each key is identified by the combination of interface and Key
  11475.     ID. An interface may have multiple keys    active at any one time.
  11476.     This enables smooth transition from one    key to another.    Each key
  11477.     has four time constants    associated with    it. These time constants
  11478.     can be expressed in terms of a time-of-day clock, or in    terms of
  11479.     a router's local clock (e.g., number of    seconds    since last
  11480.     reboot):
  11481.  
  11482.     KeyStartAccept
  11483.         The    time that the router will start    accepting packets that
  11484.         have been created with the given key.
  11485.  
  11486.     KeyStartGenerate
  11487.         The    time that the router will start    using the key for packet
  11488.         generation.
  11489.  
  11490.     KeyStopGenerate
  11491.         The    time that the router will stop using the key for packet
  11492.         generation.
  11493.  
  11494.     KeyStopAccept
  11495.         The    time that the router will stop accepting packets that
  11496.         have been created with the given key.
  11497.  
  11498.  
  11499.  
  11500. Moy                Standards Track              [Page 230]
  11501.  
  11502. RFC 2328             OSPF Version 2              April 1998
  11503.  
  11504.  
  11505.     In order to achieve smooth key transition, KeyStartAccept should
  11506.     be less    than KeyStartGenerate and KeyStopGenerate should be less
  11507.     than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are
  11508.     left unspecified, the key's lifetime is    infinite. When a new key
  11509.     replaces an old, the KeyStartGenerate time for the new key must
  11510.     be less    than or    equal to the KeyStopGenerate time of the old
  11511.     key.
  11512.  
  11513.     Key storage should persist across a system restart, warm or
  11514.     cold, to avoid operational issues. In the event    that the last
  11515.     key associated with an interface expires, it is    unacceptable to
  11516.     revert to an unauthenticated condition,    and not    advisable to
  11517.     disrupt    routing.  Therefore, the router    should send a "last
  11518.     authentication key expiration" notification to the network
  11519.     manager    and treat the key as having an infinite    lifetime until
  11520.     the lifetime is    extended, the key is deleted by    network
  11521.     management, or a new key is configured.
  11522.  
  11523.     D.4    Message    generation
  11524.  
  11525.     After building the contents of an OSPF packet, the
  11526.     authentication procedure indicated by the sending interface's
  11527.     Autype value is    called before the packet is sent. The
  11528.     authentication procedure modifies the OSPF packet as follows.
  11529.  
  11530.     D.4.1 Generating Null authentication
  11531.  
  11532.         When using Null authentication, the    packet is modified as
  11533.         follows:
  11534.  
  11535.         (1)    The Autype field in the    standard OSPF header is    set to
  11536.         0.
  11537.  
  11538.         (2)    The checksum field in the standard OSPF    header is set to
  11539.         the standard IP    checksum of the    entire contents    of the
  11540.         packet,    starting with the OSPF packet header but
  11541.         excluding the 64-bit authentication field.  This
  11542.         checksum is calculated as the 16-bit one's complement of
  11543.         the one's complement sum of all    the 16-bit words in the
  11544.         packet,    excepting the authentication field.  If    the
  11545.  
  11546.  
  11547.  
  11548.  
  11549.  
  11550. Moy                Standards Track              [Page 231]
  11551.  
  11552. RFC 2328             OSPF Version 2              April 1998
  11553.  
  11554.  
  11555.         packet's length    is not an integral number of 16-bit
  11556.         words, the packet is padded with a byte    of zero    before
  11557.         checksumming.
  11558.  
  11559.     D.4.2 Generating Simple    password authentication
  11560.  
  11561.         When using Simple password authentication, the packet is
  11562.         modified as    follows:
  11563.  
  11564.         (1)    The Autype field in the    standard OSPF header is    set to
  11565.         1.
  11566.  
  11567.         (2)    The checksum field in the standard OSPF    header is set to
  11568.         the standard IP    checksum of the    entire contents    of the
  11569.         packet,    starting with the OSPF packet header but
  11570.         excluding the 64-bit authentication field.  This
  11571.         checksum is calculated as the 16-bit one's complement of
  11572.         the one's complement sum of all    the 16-bit words in the
  11573.         packet,    excepting the authentication field.  If    the
  11574.         packet's length    is not an integral number of 16-bit
  11575.         words, the packet is padded with a byte    of zero    before
  11576.         checksumming.
  11577.  
  11578.         (3)    The 64-bit authentication field    in the OSPF packet
  11579.         header is set to the 64-bit password (i.e.,
  11580.         authentication key) that has been configured for the
  11581.         interface.
  11582.  
  11583.     D.4.3 Generating Cryptographic authentication
  11584.  
  11585.         When using Cryptographic authentication, there may be
  11586.         multiple keys configured for the interface.    In this    case,
  11587.         among the keys that    are valid for message generation (i.e,
  11588.         that have KeyStartGenerate <= current time <
  11589.         KeyStopGenerate) choose the    one with the most recent
  11590.         KeyStartGenerate time. Using this key, modify the packet as
  11591.         follows:
  11592.  
  11593.         (1)    The Autype field in the    standard OSPF header is    set to
  11594.         2.
  11595.  
  11596.  
  11597.  
  11598.  
  11599.  
  11600. Moy                Standards Track              [Page 232]
  11601.  
  11602. RFC 2328             OSPF Version 2              April 1998
  11603.  
  11604.  
  11605.         (2)    The checksum field in the standard OSPF    header is not
  11606.         calculated, but    is instead set to 0.
  11607.  
  11608.         (3)    The Key    ID (see    Figure 18) is set to the chosen    key's
  11609.         Key ID.
  11610.  
  11611.         (4)    The Auth Data Len field    is set to the length in    bytes of
  11612.         the message digest that    will be    appended to the    OSPF
  11613.         packet.    When using MD5 as the authentication algorithm,
  11614.         Auth Data Len will be 16.
  11615.  
  11616.         (5)    The 32-bit Cryptographic sequence number (see Figure 18)
  11617.         is set to a non-decreasing value (i.e.,    a value    at least
  11618.         as large as the    last value sent    out the    interface). The
  11619.         precise    values to use in the cryptographic sequence
  11620.         number field are implementation-specific. For example,
  11621.         it may be based    on a simple counter, or    be based on the
  11622.         system's clock.
  11623.  
  11624.         (6)    The message digest is then calculated and appended to
  11625.         the OSPF packet.  The authentication algorithm to be
  11626.         used in    calculating the    digest is indicated by the key
  11627.         itself.     Input to the authentication algorithm consists
  11628.         of the OSPF packet and the secret key. When using MD5 as
  11629.         the authentication algorithm, the message digest
  11630.         calculation proceeds as    follows:
  11631.  
  11632.         (a) The    16 byte    MD5 key    is appended to the OSPF    packet.
  11633.  
  11634.         (b) Trailing pad and length fields are added, as
  11635.             specified in [Ref17].
  11636.  
  11637.         (c) The    MD5 authentication algorithm is    run over the
  11638.             concatenation of the OSPF packet, secret key, pad
  11639.             and    length fields, producing a 16 byte message
  11640.             digest (see    [Ref17]).
  11641.  
  11642.         (d) The    MD5 digest is written over the OSPF key    (i.e.,
  11643.             appended to    the original OSPF packet). The digest is
  11644.             not    counted    in the OSPF packet's length field, but
  11645.  
  11646.  
  11647.  
  11648.  
  11649.  
  11650. Moy                Standards Track              [Page 233]
  11651.  
  11652. RFC 2328             OSPF Version 2              April 1998
  11653.  
  11654.  
  11655.             is included    in the packet's    IP length field. Any
  11656.             trailing pad or length fields beyond the digest are
  11657.             not    counted    or transmitted.
  11658.  
  11659.     D.5    Message    verification
  11660.  
  11661.     When an    OSPF packet has    been received on an interface, it must
  11662.     be authenticated. The authentication procedure is indicated by
  11663.     the setting of Autype in the standard OSPF packet header, which
  11664.     matches    the setting of Autype for the receiving    OSPF interface.
  11665.  
  11666.     If an OSPF protocol packet is accepted as authentic, processing
  11667.     of the packet continues    as specified in    Section    8.2. Packets
  11668.     which fail authentication are discarded.
  11669.  
  11670.     D.5.1 Verifying    Null authentication
  11671.  
  11672.         When using Null authentication, the    checksum field in the
  11673.         OSPF header    must be    verified. It must be set to the    16-bit
  11674.         one's complement of    the one's complement sum of all    the 16-
  11675.         bit    words in the packet, excepting the authentication field.
  11676.         (If    the packet's length is not an integral number of 16-bit
  11677.         words, the packet is padded    with a byte of zero before
  11678.         checksumming.)
  11679.  
  11680.     D.5.2 Verifying    Simple password    authentication
  11681.  
  11682.         When using Simple password authentication, the received OSPF
  11683.         packet is authenticated as follows:
  11684.  
  11685.         (1)    The checksum field in the OSPF header must be verified.
  11686.         It must    be set to the 16-bit one's complement of the
  11687.         one's complement sum of    all the    16-bit words in    the
  11688.         packet,    excepting the authentication field.  (If the
  11689.         packet's length    is not an integral number of 16-bit
  11690.         words, the packet is padded with a byte    of zero    before
  11691.         checksumming.)
  11692.  
  11693.         (2)    The 64-bit authentication field    in the OSPF packet
  11694.         header must be equal to    the 64-bit password (i.e.,
  11695.         authentication key) that has been configured for the
  11696.         interface.
  11697.  
  11698.  
  11699.  
  11700. Moy                Standards Track              [Page 234]
  11701.  
  11702. RFC 2328             OSPF Version 2              April 1998
  11703.  
  11704.  
  11705.     D.5.3 Verifying    Cryptographic authentication
  11706.  
  11707.         When using Cryptographic authentication, the received OSPF
  11708.         packet is authenticated as follows:
  11709.  
  11710.         (1)    Locate the receiving interface's configured key    having
  11711.         Key ID equal to    that specified in the received OSPF
  11712.         packet (see Figure 18).    If the key is not found, or if
  11713.         the key    is not valid for reception (i.e., current time <
  11714.         KeyStartAccept or current time >= KeyStopAccept), the
  11715.         OSPF packet is discarded.
  11716.  
  11717.         (2)    If the cryptographic sequence number found in the OSPF
  11718.         header (see Figure 18) is less than the    cryptographic
  11719.         sequence number    recorded in the    sending    neighbor's data
  11720.         structure, the OSPF packet is discarded.
  11721.  
  11722.         (3)    Verify the appended message digest in the following
  11723.         steps:
  11724.  
  11725.         (a) The    received digest    is set aside.
  11726.  
  11727.         (b) A new digest is calculated,    as specified in    Step 6
  11728.             of Section D.4.3.
  11729.  
  11730.         (c) The    calculated and received    digests    are compared. If
  11731.             they do not    match, the OSPF    packet is discarded. If
  11732.             they do match, the OSPF protocol packet is accepted
  11733.             as authentic, and the "cryptographic sequence
  11734.             number" in the neighbor's data structure is    set to
  11735.             the    sequence number    found in the packet's OSPF
  11736.             header.
  11737.  
  11738.  
  11739.  
  11740.  
  11741.  
  11742.  
  11743.  
  11744.  
  11745.  
  11746.  
  11747.  
  11748.  
  11749.  
  11750. Moy                Standards Track              [Page 235]
  11751.  
  11752. RFC 2328             OSPF Version 2              April 1998
  11753.  
  11754.  
  11755. E. An algorithm    for assigning Link State IDs
  11756.  
  11757.     The    Link State ID in AS-external-LSAs and summary-LSAs is usually
  11758.     set    to the described network's IP address. However,    if necessary one
  11759.     or more of the network's host bits may be set in the Link State ID.
  11760.     This allows    the router to originate    separate LSAs for networks
  11761.     having the same address, yet different masks. Such networks    can
  11762.     occur in the presence of supernetting and subnet 0s    (see [Ref10]).
  11763.  
  11764.     This appendix gives    one possible algorithm for setting the host bits
  11765.     in Link State IDs.    The choice of such an algorithm    is a local
  11766.     decision. Separate routers are free    to use different algorithms,
  11767.     since the only LSAs    affected are the ones that the router itself
  11768.     originates.    The only requirement on    the algorithms used is that the
  11769.     network's IP address should    be used    as the Link State ID whenever
  11770.     possible; this maximizes interoperability with OSPF    implementations
  11771.     predating RFC 1583.
  11772.  
  11773.     The    algorithm below    is stated for AS-external-LSAs.     This is only
  11774.     for    clarity; the exact same    algorithm can be used for summary-LSAs.
  11775.     Suppose that the router wishes to originate    an AS-external-LSA for a
  11776.     network having address NA and mask NM1. The    following steps    are then
  11777.     used to determine the LSA's    Link State ID:
  11778.  
  11779.     (1)    Determine whether the router is    already    originating an AS-
  11780.     external-LSA with Link State ID    equal to NA (in    such an    LSA the
  11781.     router itself will be listed as    the LSA's Advertising Router).
  11782.     If not,    the Link State ID is set equal to NA and the algorithm
  11783.     terminates. Otherwise,
  11784.  
  11785.     (2)    Obtain the network mask    from the body of the already existing
  11786.     AS-external-LSA. Call this mask    NM2. There are then two    cases:
  11787.  
  11788.     o   NM1    is longer (i.e., more specific)    than NM2. In this case,
  11789.         set    the Link State ID in the new LSA to be the network
  11790.         [NA,NM1] with all the host bits set    (i.e., equal to    NA or'ed
  11791.         together with all the bits that are    not set    in NM1,    which is
  11792.         network [NA,NM1]'s broadcast address).
  11793.  
  11794.     o   NM2    is longer than NM1. In this case, change the existing
  11795.         LSA    (having    Link State ID of NA) to    reference the new
  11796.         network [NA,NM1] by    incrementing the sequence number,
  11797.  
  11798.  
  11799.  
  11800. Moy                Standards Track              [Page 236]
  11801.  
  11802. RFC 2328             OSPF Version 2              April 1998
  11803.  
  11804.  
  11805.         changing the mask in the body to NM1 and inserting the cost
  11806.         of the new network.    Then originate a new LSA for the old
  11807.         network [NA,NM2], with Link    State ID equal to NA or'ed
  11808.         together with the bits that    are not    set in NM2 (i.e.,
  11809.         network [NA,NM2]'s broadcast address).
  11810.  
  11811.     The    above algorithm    assumes    that all masks are contiguous; this
  11812.     ensures that when two networks have    the same address, one mask is
  11813.     more specific than the other. The algorithm    also assumes that no
  11814.     network exists having an address equal to another network's
  11815.     broadcast address. Given these two assumptions, the    above algorithm
  11816.     always produces unique Link    State IDs. The above algorithm can also
  11817.     be reworded    as follows:  When originating an AS-external-LSA, try to
  11818.     use    the network number as the Link State ID.  If that produces a
  11819.     conflict, examine the two networks in conflict. One    will be    a subset
  11820.     of the other. For the less specific    network, use the network number
  11821.     as the Link    State ID and for the more specific use the network's
  11822.     broadcast address instead (i.e., flip all the "host" bits to 1).  If
  11823.     the    most specific network was originated first, this will cause you
  11824.     to originate two LSAs at once.
  11825.  
  11826.     As an example of the algorithm, consider its operation when    the
  11827.     following sequence of events occurs    in a single router (Router A).
  11828.  
  11829.  
  11830.     (1)    Router A wants to originate an AS-external-LSA for
  11831.     [10.0.0.0,255.255.255.0]:
  11832.  
  11833.     (a) A Link State ID of 10.0.0.0    is used.
  11834.  
  11835.     (2)    Router A then wants to originate an AS-external-LSA for
  11836.     [10.0.0.0,255.255.0.0]:
  11837.  
  11838.     (a) The    LSA for    [10.0.0,0,255.255.255.0] is reoriginated using a
  11839.         new    Link State ID of 10.0.0.255.
  11840.  
  11841.     (b) A Link State ID of 10.0.0.0    is used    for
  11842.         [10.0.0.0,255.255.0.0].
  11843.  
  11844.     (3)    Router A then wants to originate an AS-external-LSA for
  11845.     [10.0.0.0,255.0.0.0]:
  11846.  
  11847.  
  11848.  
  11849.  
  11850. Moy                Standards Track              [Page 237]
  11851.  
  11852. RFC 2328             OSPF Version 2              April 1998
  11853.  
  11854.  
  11855.     (a) The    LSA for    [10.0.0.0,255.255.0.0] is reoriginated using a
  11856.         new    Link State ID of 10.0.255.255.
  11857.  
  11858.     (b) A Link State ID of 10.0.0.0    is used    for
  11859.         [10.0.0.0,255.0.0.0].
  11860.  
  11861.     (c) The    network    [10.0.0.0,255.255.255.0] keeps its Link    State ID
  11862.         of 10.0.0.255.
  11863.  
  11864.  
  11865.  
  11866.  
  11867.  
  11868.  
  11869.  
  11870.  
  11871.  
  11872.  
  11873.  
  11874.  
  11875.  
  11876.  
  11877.  
  11878.  
  11879.  
  11880.  
  11881.  
  11882.  
  11883.  
  11884.  
  11885.  
  11886.  
  11887.  
  11888.  
  11889.  
  11890.  
  11891.  
  11892.  
  11893.  
  11894.  
  11895.  
  11896.  
  11897.  
  11898.  
  11899.  
  11900. Moy                Standards Track              [Page 238]
  11901.  
  11902. RFC 2328             OSPF Version 2              April 1998
  11903.  
  11904.  
  11905. F. Multiple interfaces to the same network/subnet
  11906.  
  11907.     There are at least two ways    to support multiple physical interfaces
  11908.     to the same    IP subnet. Both    methods    will interoperate with
  11909.     implementations of RFC 1583    (and of    course this memo). The two
  11910.     methods are    sketched briefly below.    An assumption has been made that
  11911.     each interface has been assigned a separate    IP address (otherwise,
  11912.     support for    multiple interfaces is more of a link-level or ARP issue
  11913.     than an OSPF issue).
  11914.  
  11915.     Method 1:
  11916.     Run the    entire OSPF functionality over both interfaces,    sending
  11917.     and receiving hellos, flooding,    supporting separate interface
  11918.     and neighbor FSMs for each interface, etc. When    doing this all
  11919.     other routers on the subnet will treat the two interfaces as
  11920.     separate neighbors, since neighbors are    identified (on broadcast
  11921.     and NBMA networks) by their IP address.
  11922.  
  11923.     Method 1 has the following disadvantages:
  11924.  
  11925.     (1) You    increase the total number of neighbors and adjacencies.
  11926.  
  11927.     (2) You    lose the bidirectionality test on both interfaces, since
  11928.         bidirectionality is    based on Router    ID.
  11929.  
  11930.     (3) You    have to    consider both interfaces together during the
  11931.         Designated Router election,    since if you declare both to be
  11932.         DR simultaneously you can confuse the tie-breaker (which is
  11933.         Router ID).
  11934.  
  11935.     Method 2:
  11936.     Run OSPF over only one interface (call it the primary
  11937.     interface), but    include    both the primary and secondary
  11938.     interfaces in your Router-LSA.
  11939.  
  11940.     Method 2 has the following disadvantages:
  11941.  
  11942.     (1) You    lose the bidirectionality test on the secondary
  11943.         interface.
  11944.  
  11945.     (2) When the primary interface fails, you need to promote the
  11946.         secondary interface    to primary status.
  11947.  
  11948.  
  11949.  
  11950. Moy                Standards Track              [Page 239]
  11951.  
  11952. RFC 2328             OSPF Version 2              April 1998
  11953.  
  11954.  
  11955. G. Differences from RFC    2178
  11956.  
  11957.     This section documents the differences between this    memo and RFC
  11958.     2178.  All differences are backward-compatible. Implementations of
  11959.     this memo and of RFCs 2178,    1583, and 1247 will interoperate.
  11960.  
  11961.     G.1    Flooding modifications
  11962.  
  11963.     Three changes have been    made to    the flooding procedure in
  11964.     Section    13.
  11965.  
  11966.     The first change is to step 4 in Section 13. Now MaxAge    LSAs are
  11967.     acknowledged and then discarded    only when both a) there    is no
  11968.     database copy of the LSA and b)    none of    router's neighbors are
  11969.     in states Exchange or Loading. In all other cases, the MaxAge
  11970.     LSA is processed like any other    LSA, installing    the LSA    in the
  11971.     database and flooding it out the appropriate interfaces    when the
  11972.     LSA is more recent than    the database copy (Step    5 of Section
  11973.     13). This change also affects the contents of Table 19.
  11974.  
  11975.     The second change is to    step 5a    in Section 13. The MinLSArrival
  11976.     check is meant only for    LSAs received during flooding, and
  11977.     should not be performed    on those LSAs that the router itself
  11978.     originates.
  11979.  
  11980.     The third change is to step 8 in Section 13. Confusion between
  11981.     routers    as to which LSA    instance is more recent    can cause a
  11982.     disastrous amount of flooding in a link-state protocol (see
  11983.     [Ref26]). OSPF guards against this problem in two ways:    a) the
  11984.     LS age field is    used like a TTL    field in flooding, to eventually
  11985.     remove looping LSAs from the network (see Section 13.3), and b)
  11986.     routers    refuse to accept LSA updates more frequently than once
  11987.     every MinLSArrival seconds (see    Section    13).  However, there is
  11988.     still one case in RFC 2178 where disagreements regarding which
  11989.     LSA is more recent can cause a lot of flooding traffic:
  11990.     responding to old LSAs by reflooding the database copy.     For
  11991.     this reason, Step 8 of Section 13 has been amended to only
  11992.     respond    with the database copy when that copy has not been sent
  11993.     in any Link State Update within    the last MinLSArrival seconds.
  11994.  
  11995.  
  11996.  
  11997.  
  11998.  
  11999.  
  12000. Moy                Standards Track              [Page 240]
  12001.  
  12002. RFC 2328             OSPF Version 2              April 1998
  12003.  
  12004.  
  12005.     G.2    Changes    to external path preferences
  12006.  
  12007.     There is still the possibility of a routing loop in RFC    2178
  12008.     when both a) virtual links are in use and b) the same external
  12009.     route is being imported    by multiple ASBRs, each    of which is in a
  12010.     separate area. To fix this problem, Section 16.4.1 has been
  12011.     revised. To choose the correct ASBR/forwarding address,    intra-
  12012.     area paths through non-backbone    areas are always preferred.
  12013.     However, intra-area paths through the backbone area (Area 0) and
  12014.     inter-area paths are now of equal preference, and must be
  12015.     compared solely    based on cost.
  12016.  
  12017.     The reasoning behind this change is as follows.    When virtual
  12018.     links are in use, an intra-area    backbone path for one router can
  12019.     turn into an inter-area    path in    a router several hops closer to
  12020.     the destination. Hence,    intra-area backbone paths and inter-area
  12021.     paths must be of equal preference. We can safely compare their
  12022.     costs, preferring the path with    the smallest cost, due to the
  12023.     calculations in    Section    16.3.
  12024.  
  12025.     Thanks to Michael Briggs and Jeremy McCooey of the UNH
  12026.     InterOperability Lab for pointing out this problem.
  12027.  
  12028.     G.3    Incomplete resolution of virtual next hops
  12029.  
  12030.     One of the functions of    the calculation    in Section 16.3    is to
  12031.     determine the actual next hop(s) for those destinations    whose
  12032.     next hop was calculated    as a virtual link in Sections 16.1 and
  12033.     16.2.  After completion    of the calculation in Section 16.3, any
  12034.     paths calculated in Sections 16.1 and 16.2 that    still have
  12035.     unresolved virtual next    hops should be discarded.
  12036.  
  12037.     G.4    Routing    table lookup
  12038.  
  12039.     The routing table lookup algorithm in Section 11.1 has been
  12040.     modified to reflect current practice. The "best    match" routing
  12041.     table entry is now always selected to be the one providing the
  12042.     most specific (longest)    match. Suppose for example a router is
  12043.     forwarding packets to the destination 192.9.1.1. A routing table
  12044.     entry for 192.9.1/24 will always be a better match than    the
  12045.     routing    table entry for    192.9/16, regardless of    the routing
  12046.     table entries' path-types. Note    however    that when multiple paths
  12047.  
  12048.  
  12049.  
  12050. Moy                Standards Track              [Page 241]
  12051.  
  12052. RFC 2328             OSPF Version 2              April 1998
  12053.  
  12054.  
  12055.     are available for a given routing table    entry, the calculations
  12056.     in Sections 16.1, 16.2,    and 16.4 always    yield the paths    having
  12057.     the most preferential path-type. (Intra-area paths are the most
  12058.     preferred, followed in order by    inter-area, type 1 external and
  12059.     type 2 external    paths; see Section 11).
  12060.  
  12061.  
  12062.  
  12063.  
  12064.  
  12065.  
  12066.  
  12067.  
  12068.  
  12069.  
  12070.  
  12071.  
  12072.  
  12073.  
  12074.  
  12075.  
  12076.  
  12077.  
  12078.  
  12079.  
  12080.  
  12081.  
  12082.  
  12083.  
  12084.  
  12085.  
  12086.  
  12087.  
  12088.  
  12089.  
  12090.  
  12091.  
  12092.  
  12093.  
  12094.  
  12095.  
  12096.  
  12097.  
  12098.  
  12099.  
  12100. Moy                Standards Track              [Page 242]
  12101.  
  12102. RFC 2328             OSPF Version 2              April 1998
  12103.  
  12104.  
  12105. Security Considerations
  12106.  
  12107.     All    OSPF protocol exchanges    are authenticated. OSPF    supports
  12108.     multiple types of authentication; the type of authentication in use
  12109.     can    be configured on a per network segment basis. One of OSPF's
  12110.     authentication types, namely the Cryptographic authentication
  12111.     option, is believed    to be secure against passive attacks and provide
  12112.     significant    protection against active attacks. When    using the
  12113.     Cryptographic authentication option, each router appends a "message
  12114.     digest" to its transmitted OSPF packets. Receivers then use    the
  12115.     shared secret key and received digest to verify that each received
  12116.     OSPF packet    is authentic.
  12117.  
  12118.     The    quality    of the security    provided by the    Cryptographic
  12119.     authentication option depends completely on    the strength of    the
  12120.     message digest algorithm (MD5 is currently the only    message    digest
  12121.     algorithm specified), the strength of the key being    used, and the
  12122.     correct implementation of the security mechanism in    all
  12123.     communicating OSPF implementations.     It also requires that all
  12124.     parties maintain the secrecy of the    shared secret key.
  12125.  
  12126.     None of the    OSPF authentication types provide confidentiality. Nor
  12127.     do they protect against traffic analysis. Key management is    also not
  12128.     addressed by this memo.
  12129.  
  12130.     For    more information, see Sections 8.1, 8.2, and Appendix D.
  12131.  
  12132. Author's Address
  12133.  
  12134.     John Moy
  12135.     Ascend Communications, Inc.
  12136.     1 Robbins Road
  12137.     Westford, MA 01886
  12138.  
  12139.     Phone: 978-952-1367
  12140.     Fax:   978-392-2075
  12141.     EMail: jmoy@casc.com
  12142.  
  12143.  
  12144.  
  12145.  
  12146.  
  12147.  
  12148.  
  12149.  
  12150. Moy                Standards Track              [Page 243]
  12151.  
  12152. RFC 2328             OSPF Version 2              April 1998
  12153.  
  12154.  
  12155. Full Copyright Statement
  12156.  
  12157.     Copyright (C) The Internet Society (1998).    All Rights Reserved.
  12158.  
  12159.     This document and translations of it may be    copied and furnished to
  12160.     others, and    derivative works that comment on or otherwise explain it
  12161.     or assist in its implementation may    be prepared, copied, published
  12162.     and    distributed, in    whole or in part, without restriction of any
  12163.     kind, provided that    the above copyright notice and this paragraph
  12164.     are    included on all    such copies and    derivative works.  However, this
  12165.     document itself may    not be modified    in any way, such as by removing
  12166.     the    copyright notice or references to the Internet Society or other
  12167.     Internet organizations, except as needed for the purpose of
  12168.     developing Internet    standards in which case    the procedures for
  12169.     copyrights defined in the Internet Standards process must be
  12170.     followed, or as required to    translate it into languages other than
  12171.     English.
  12172.  
  12173.     The    limited    permissions granted above are perpetual    and will not be
  12174.     revoked by the Internet Society or its successors or assigns.
  12175.  
  12176.     This document and the information contained    herein is provided on an
  12177.     "AS    IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  12178.     TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  12179.     BUT    NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE    INFORMATION
  12180.     HEREIN WILL    NOT INFRINGE ANY RIGHTS    OR ANY IMPLIED WARRANTIES OF
  12181.     MERCHANTABILITY OR FITNESS FOR A PARTICULAR    PURPOSE.
  12182.  
  12183.  
  12184.  
  12185.  
  12186.  
  12187.  
  12188.  
  12189.  
  12190.  
  12191.  
  12192.  
  12193.  
  12194.  
  12195.  
  12196.  
  12197.  
  12198.  
  12199.  
  12200. Moy                Standards Track              [Page 244]
  12201.  
  12202.