Network Working Group                                             J. Moy
Request for Comments: 1583                                 Proteon, Inc.
Obsoletes: 1247                                               March 1994
Category: Standards Track


                             OSPF Version 2



Status of this Memo

    This document specifies an Internet standards track protocol for the
    Internet community, and requests discussion and suggestions for
    improvements.  Please refer to the current edition of the "Internet
    Official Protocol Standards" (STD 1) for the standardization state
    and status of this protocol.  Distribution of this memo is
    unlimited.

Abstract

    This memo documents version 2 of the OSPF protocol.  OSPF is a
    link-state routing protocol.  It is designed to be run internal to a
    single Autonomous System.  Each OSPF router maintains an identical
    database describing the Autonomous System's topology.  From this
    database, a routing table is calculated by constructing a shortest-
    path tree.

    OSPF recalculates routes quickly in the face of topological changes,
    utilizing a minimum of routing protocol traffic.  OSPF provides
    support for equal-cost multipath.  Separate routes can be calculated
    for each IP Type of Service.  An area routing capability is
    provided, enabling an additional level of routing protection and a
    reduction in routing protocol traffic.  In addition, all OSPF
    routing protocol exchanges are authenticated.

    OSPF Version 2 was originally documented in RFC 1247. The
    differences between RFC 1247 and this memo are explained in Appendix
    E. The differences consist of bug fixes and clarifications, and are
    backward-compatible in nature. Implementations of RFC 1247 and of
    this memo will interoperate.

    Please send comments to ospf@gated.cornell.edu.








Moy                                                             [Page 1]


RFC 1583                     OSPF Version 2                   March 1994


Table of Contents

    1       Introduction ........................................... 5
    1.1     Protocol Overview ...................................... 5
    1.2     Definitions of commonly used terms ..................... 6
    1.3     Brief history of link-state routing technology ......... 9
    1.4     Organization of this document .......................... 9
    2       The Topological Database .............................. 10
    2.1     The shortest-path tree ................................ 13
    2.2     Use of external routing information ................... 16
    2.3     Equal-cost multipath .................................. 20
    2.4     TOS-based routing ..................................... 20
    3       Splitting the AS into Areas ........................... 21
    3.1     The backbone of the Autonomous System ................. 22
    3.2     Inter-area routing .................................... 22
    3.3     Classification of routers ............................. 23
    3.4     A sample area configuration ........................... 24
    3.5     IP subnetting support ................................. 30
    3.6     Supporting stub areas ................................. 31
    3.7     Partitions of areas ................................... 32
    4       Functional Summary .................................... 34
    4.1     Inter-area routing .................................... 35
    4.2     AS external routes .................................... 35
    4.3     Routing protocol packets .............................. 35
    4.4     Basic implementation requirements ..................... 38
    4.5     Optional OSPF capabilities ............................ 39
    5       Protocol data structures .............................. 41
    6       The Area Data Structure ............................... 42
    7       Bringing Up Adjacencies ............................... 45
    7.1     The Hello Protocol .................................... 45
    7.2     The Synchronization of Databases ...................... 46
    7.3     The Designated Router ................................. 47
    7.4     The Backup Designated Router .......................... 48
    7.5     The graph of adjacencies .............................. 49
    8       Protocol Packet Processing ............................ 50
    8.1     Sending protocol packets .............................. 51
    8.2     Receiving protocol packets ............................ 53
    9       The Interface Data Structure .......................... 55
    9.1     Interface states ...................................... 58
    9.2     Events causing interface state changes ................ 61
    9.3     The Interface state machine ........................... 62
    9.4     Electing the Designated Router ........................ 65
    9.5     Sending Hello packets ................................. 67
    9.5.1   Sending Hello packets on non-broadcast networks ....... 68
    10      The Neighbor Data Structure ........................... 69
    10.1    Neighbor states ....................................... 72
    10.2    Events causing neighbor state changes ................. 75
    10.3    The Neighbor state machine ............................ 77



Moy                                                             [Page 2]


RFC 1583                     OSPF Version 2                   March 1994


    10.4    Whether to become adjacent ............................ 83
    10.5    Receiving Hello Packets ............................... 83
    10.6    Receiving Database Description Packets ................ 86
    10.7    Receiving Link State Request Packets .................. 89
    10.8    Sending Database Description Packets .................. 89
    10.9    Sending Link State Request Packets .................... 90
    10.10   An Example ............................................ 91
    11      The Routing Table Structure ........................... 93
    11.1    Routing table lookup .................................. 96
    11.2    Sample routing table, without areas ................... 97
    11.3    Sample routing table, with areas ...................... 98
    12      Link State Advertisements ............................ 100
    12.1    The Link State Advertisement Header .................. 101
    12.1.1  LS age ............................................... 102
    12.1.2  Options .............................................. 102
    12.1.3  LS type .............................................. 103
    12.1.4  Link State ID ........................................ 103
    12.1.5  Advertising Router ................................... 105
    12.1.6  LS sequence number ................................... 105
    12.1.7  LS checksum .......................................... 106
    12.2    The link state database .............................. 107
    12.3    Representation of TOS ................................ 108
    12.4    Originating link state advertisements ................ 109
    12.4.1  Router links ......................................... 112
    12.4.2  Network links ........................................ 118
    12.4.3  Summary links ........................................ 120
    12.4.4  Originating summary links into stub areas ............ 123
    12.4.5  AS external links .................................... 124
    13      The Flooding Procedure ............................... 126
    13.1    Determining which link state is newer ................ 130
    13.2    Installing link state advertisements in the database . 130
    13.3    Next step in the flooding procedure .................. 131
    13.4    Receiving self-originated link state ................. 134
    13.5    Sending Link State Acknowledgment packets ............ 135
    13.6    Retransmitting link state advertisements ............. 136
    13.7    Receiving link state acknowledgments ................. 138
    14      Aging The Link State Database ........................ 139
    14.1    Premature aging of advertisements .................... 139
    15      Virtual Links ........................................ 140
    16      Calculation Of The Routing Table ..................... 142
    16.1    Calculating the shortest-path tree for an area ....... 143
    16.1.1  The next hop calculation ............................. 149
    16.2    Calculating the inter-area routes .................... 150
    16.3    Examining transit areas' summary links ............... 152
    16.4    Calculating AS external routes ....................... 154
    16.5    Incremental updates -- summary link advertisements ... 156
    16.6    Incremental updates -- AS external link advertisements 157
    16.7    Events generated as a result of routing table changes  157



Moy                                                             [Page 3]


RFC 1583                     OSPF Version 2                   March 1994


    16.8    Equal-cost multipath ................................. 158
    16.9    Building the non-zero-TOS portion of the routing table 158
            Footnotes ............................................ 161
            References ........................................... 164
    A       OSPF data formats .................................... 166
    A.1     Encapsulation of OSPF packets ........................ 166
    A.2     The Options field .................................... 168
    A.3     OSPF Packet Formats .................................. 170
    A.3.1   The OSPF packet header ............................... 171
    A.3.2   The Hello packet ..................................... 173
    A.3.3   The Database Description packet ...................... 175
    A.3.4   The Link State Request packet ........................ 177
    A.3.5   The Link State Update packet ......................... 179
    A.3.6   The Link State Acknowledgment packet ................. 181
    A.4     Link state advertisement formats ..................... 183
    A.4.1   The Link State Advertisement header .................. 184
    A.4.2   Router links advertisements .......................... 186
    A.4.3   Network links advertisements ......................... 190
    A.4.4   Summary link advertisements .......................... 192
    A.4.5   AS external link advertisements ...................... 194
    B       Architectural Constants .............................. 196
    C       Configurable Constants ............................... 198
    C.1     Global parameters .................................... 198
    C.2     Area parameters ...................................... 198
    C.3     Router interface parameters .......................... 200
    C.4     Virtual link parameters .............................. 202
    C.5     Non-broadcast, multi-access network parameters ....... 203
    C.6     Host route parameters ................................ 203
    D       Authentication ....................................... 205
    D.1     AuType 0 -- No authentication ........................ 205
    D.2     AuType 1 -- Simple password .......................... 205
    E       Differences from RFC 1247 ............................ 207
    E.1     A fix for a problem with OSPF Virtual links .......... 207
    E.2     Supporting supernetting and subnet 0 ................. 208
    E.3     Obsoleting LSInfinity in router links advertisements . 209
    E.4     TOS encoding updated ................................. 209
    E.5     Summarizing routes into transit areas ................ 210
    E.6     Summarizing routes into stub areas ................... 210
    E.7     Flushing anomalous network links advertisements ...... 210
    E.8     Required Statistics appendix deleted ................. 211
    E.9     Other changes ........................................ 211
    F.      An algorithm for assigning Link State IDs ............ 213
            Security Considerations .............................. 216
            Author's Address ..................................... 216







Moy                                                             [Page 4]


RFC 1583                     OSPF Version 2                   March 1994


1.  Introduction

    This document is a specification of the Open Shortest Path First
    (OSPF) TCP/IP internet routing protocol.  OSPF is classified as an
    Interior Gateway Protocol (IGP).  This means that it distributes
    routing information between routers belonging to a single Autonomous
    System.  The OSPF protocol is based on link-state or SPF technology.
    This is a departure from the Bellman-Ford base used by traditional
    TCP/IP internet routing protocols.

    The OSPF protocol was developed by the OSPF working group of the
    Internet Engineering Task Force.  It has been designed expressly for
    the TCP/IP internet environment, including explicit support for IP
    subnetting, TOS-based routing and the tagging of externally-derived
    routing information.  OSPF also provides for the authentication of
    routing updates, and utilizes IP multicast when sending/receiving
    the updates.  In addition, much work has been done to produce a
    protocol that responds quickly to topology changes, yet involves
    small amounts of routing protocol traffic.

    The author would like to thank Fred Baker, Jeffrey Burgan, Rob
    Coltun, Dino Farinacci, Vince Fuller, Phanindra Jujjavarapu, Milo
    Medin, Kannan Varadhan and the rest of the OSPF working group for
    the ideas and support they have given to this project.

    1.1.  Protocol overview

        OSPF routes IP packets based solely on the destination IP
        address and IP Type of Service found in the IP packet header.
        IP packets are routed "as is" -- they are not encapsulated in
        any further protocol headers as they transit the Autonomous
        System.  OSPF is a dynamic routing protocol.  It quickly detects
        topological changes in the AS (such as router interface
        failures) and calculates new loop-free routes after a period of
        convergence.  This period of convergence is short and involves a
        minimum of routing traffic.

        In a link-state routing protocol, each router maintains a
        database describing the Autonomous System's topology.  Each
        participating router has an identical database.  Each individual
        piece of this database is a particular router's local state
        (e.g., the router's usable interfaces and reachable neighbors).
        The router distributes its local state throughout the Autonomous
        System by flooding.

        All routers run the exact same algorithm, in parallel.  From the
        topological database, each router constructs a tree of shortest
        paths with itself as root.  This shortest-path tree gives the



Moy                                                             [Page 5]


RFC 1583                     OSPF Version 2                   March 1994


        route to each destination in the Autonomous System.  Externally
        derived routing information appears on the tree as leaves.

        OSPF calculates separate routes for each Type of Service (TOS).
        When several equal-cost routes to a destination exist, traffic
        is distributed equally among them.  The cost of a route is
        described by a single dimensionless metric.

        OSPF allows sets of networks to be grouped together.  Such a
        grouping is called an area.  The topology of an area is hidden
        from the rest of the Autonomous System.  This information hiding
        enables a significant reduction in routing traffic.  Also,
        routing within the area is determined only by the area's own
        topology, lending the area protection from bad routing data.  An
        area is a generalization of an IP subnetted network.

        OSPF enables the flexible configuration of IP subnets.  Each
        route distributed by OSPF has a destination and mask.  Two
        different subnets of the same IP network number may have
        different sizes (i.e., different masks).  This is commonly
        referred to as variable length subnetting.  A packet is routed
        to the best (i.e., longest or most specific) match.  Host routes
        are considered to be subnets whose masks are "all ones"
        (0xffffffff).

        All OSPF protocol exchanges are authenticated.  This means that
        only trusted routers can participate in the Autonomous System's
        routing.  A variety of authentication schemes can be used; a
        single authentication scheme is configured for each area.  This
        enables some areas to use much stricter authentication than
        others.

        Externally derived routing data (e.g., routes learned from the
        Exterior Gateway Protocol (EGP)) is passed transparently
        throughout the Autonomous System.  This externally derived data
        is kept separate from the OSPF protocol's link state data.  Each
        external route can also be tagged by the advertising router,
        enabling the passing of additional information between routers
        on the boundaries of the Autonomous System.


    1.2.  Definitions of commonly used terms

        This section provides definitions for terms that have a specific
        meaning to the OSPF protocol and that are used throughout the
        text.  The reader unfamiliar with the Internet Protocol Suite is
        referred to [RS-85-153] for an introduction to IP.




Moy                                                             [Page 6]


RFC 1583                     OSPF Version 2                   March 1994


        Router
            A level three Internet Protocol packet switch.  Formerly
            called a gateway in much of the IP literature.

        Autonomous System
            A group of routers exchanging routing information via a
            common routing protocol.  Abbreviated as AS.

        Interior Gateway Protocol
            The routing protocol spoken by the routers belonging to an
            Autonomous system.  Abbreviated as IGP.  Each Autonomous
            System has a single IGP.  Separate Autonomous Systems may be
            running different IGPs.

        Router ID
            A 32-bit number assigned to each router running the OSPF
            protocol.  This number uniquely identifies the router within
            an Autonomous System.

        Network
            In this memo, an IP network/subnet/supernet.  It is possible
            for one physical network to be assigned multiple IP
            network/subnet numbers.  We consider these to be separate
            networks.  Point-to-point physical networks are an exception
            - they are considered a single network no matter how many
            (if any at all) IP network/subnet numbers are assigned to
            them.

        Network mask
            A 32-bit number indicating the range of IP addresses
            residing on a single IP network/subnet/supernet.  This
            specification displays network masks as hexadecimal numbers.
            For example, the network mask for a class C IP network is
            displayed as 0xffffff00.  Such a mask is often displayed
            elsewhere in the literature as 255.255.255.0.

        Multi-access networks
            Those physical networks that support the attachment of
            multiple (more than two) routers.  Each pair of routers on
            such a network is assumed to be able to communicate directly
            (e.g., multi-drop networks are excluded).

        Interface
            The connection between a router and one of its attached
            networks.  An interface has state information associated
            with it, which is obtained from the underlying lower level
            protocols and the routing protocol itself.  An interface to
            a network has associated with it a single IP address and



Moy                                                             [Page 7]


RFC 1583                     OSPF Version 2                   March 1994


            mask (unless the network is an unnumbered point-to-point
            network).  An interface is sometimes also referred to as a
            link.

        Neighboring routers
            Two routers that have interfaces to a common network.  On
            multi-access networks, neighbors are dynamically discovered
            by OSPF's Hello Protocol.

        Adjacency
            A relationship formed between selected neighboring routers
            for the purpose of exchanging routing information.  Not
            every pair of neighboring routers become adjacent.

        Link state advertisement
            Describes the local state of a router or network.  This
            includes the state of the router's interfaces and
            adjacencies.  Each link state advertisement is flooded
            throughout the routing domain.  The collected link state
            advertisements of all routers and networks forms the
            protocol's topological database.

        Hello Protocol
            The part of the OSPF protocol used to establish and maintain
            neighbor relationships.  On multi-access networks the Hello
            Protocol can also dynamically discover neighboring routers.

        Designated Router
            Each multi-access network that has at least two attached
            routers has a Designated Router.  The Designated Router
            generates a link state advertisement for the multi-access
            network and has other special responsibilities in the
            running of the protocol.  The Designated Router is elected
            by the Hello Protocol.

            The Designated Router concept enables a reduction in the
            number of adjacencies required on a multi-access network.
            This in turn reduces the amount of routing protocol traffic
            and the size of the topological database.

        Lower-level protocols
            The underlying network access protocols that provide
            services to the Internet Protocol and in turn the OSPF
            protocol.  Examples of these are the X.25 packet and frame
            levels for X.25 PDNs, and the ethernet data link layer for
            ethernets.





Moy                                                             [Page 8]


RFC 1583                     OSPF Version 2                   March 1994


    1.3.  Brief history of link-state routing technology

        OSPF is a link state routing protocol.  Such protocols are also
        referred to in the literature as SPF-based or distributed-
        database protocols.  This section gives a brief description of
        the developments in link-state technology that have influenced
        the OSPF protocol.

        The first link-state routing protocol was developed for use in
        the ARPANET packet switching network.  This protocol is
        described in [McQuillan].  It has formed the starting point for
        all other link-state protocols.  The homogeneous Arpanet
        environment, i.e., single-vendor packet switches connected by
        synchronous serial lines, simplified the design and
        implementation of the original protocol.

        Modifications to this protocol were proposed in [Perlman].
        These modifications dealt with increasing the fault tolerance of
        the routing protocol through, among other things, adding a
        checksum to the link state advertisements (thereby detecting
        database corruption).  The paper also included means for
        reducing the routing traffic overhead in a link-state protocol.
        This was accomplished by introducing mechanisms which enabled
        the interval between link state advertisement originations to be
        increased by an order of magnitude.

        A link-state algorithm has also been proposed for use as an ISO
        IS-IS routing protocol.  This protocol is described in [DEC].
        The protocol includes methods for data and routing traffic
        reduction when operating over broadcast networks.  This is
        accomplished by election of a Designated Router for each
        broadcast network, which then originates a link state
        advertisement for the network.

        The OSPF subcommittee of the IETF has extended this work in
        developing the OSPF protocol.  The Designated Router concept has
        been greatly enhanced to further reduce the amount of routing
        traffic required.  Multicast capabilities are utilized for
        additional routing bandwidth reduction.  An area routing scheme
        has been developed enabling information
        hiding/protection/reduction.  Finally, the algorithm has been
        modified for efficient operation in TCP/IP internets.


    1.4.  Organization of this document

        The first three sections of this specification give a general
        overview of the protocol's capabilities and functions.  Sections



Moy                                                             [Page 9]


RFC 1583                     OSPF Version 2                   March 1994


        4-16 explain the protocol's mechanisms in detail.  Packet
        formats, protocol constants and configuration items are
        specified in the appendices.

        Labels such as HelloInterval encountered in the text refer to
        protocol constants.  They may or may not be configurable.  The
        architectural constants are explained in Appendix B.  The
        configurable constants are explained in Appendix C.

        The detailed specification of the protocol is presented in terms
        of data structures.  This is done in order to make the
        explanation more precise.  Implementations of the protocol are
        required to support the functionality described, but need not
        use the precise data structures that appear in this memo.


2.  The Topological Database

    The Autonomous System's topological database describes a directed
    graph.  The vertices of the graph consist of routers and networks.
    A graph edge connects two routers when they are attached via a
    physical point-to-point network.  An edge connecting a router to a
    network indicates that the router has an interface on the network.

    The vertices of the graph can be further typed according to
    function.  Only some of these types carry transit data traffic; that
    is, traffic that is neither locally originated nor locally destined.
    Vertices that can carry transit traffic are indicated on the graph
    by having both incoming and outgoing edges.



                     Vertex type   Vertex name    Transit?
                     _____________________________________
                     1             Router         yes
                     2             Network        yes
                     3             Stub network   no


                          Table 1: OSPF vertex types.


    OSPF supports the following types of physical networks:


    Point-to-point networks
        A network that joins a single pair of routers.  A 56Kb serial
        line is an example of a point-to-point network.



Moy                                                            [Page 10]


RFC 1583                     OSPF Version 2                   March 1994


    Broadcast networks
        Networks supporting many (more than two) attached routers,
        together with the capability to address a single physical
        message to all of the attached routers (broadcast).  Neighboring
        routers are discovered dynamically on these nets using OSPF's
        Hello Protocol.  The Hello Protocol itself takes advantage of
        the broadcast capability.  The protocol makes further use of
        multicast capabilities, if they exist.  An ethernet is an
        example of a broadcast network.

    Non-broadcast networks
        Networks supporting many (more than two) routers, but having no
        broadcast capability.  Neighboring routers are also discovered
        on these nets using OSPF's Hello Protocol.  However, due to the
        lack of broadcast capability, some configuration information is
        necessary for the correct operation of the Hello Protocol.  On
        these networks, OSPF protocol packets that are normally
        multicast need to be sent to each neighboring router, in turn.
        An X.25 Public Data Network (PDN) is an example of a non-
        broadcast network.


    The neighborhood of each network node in the graph depends on
    whether the network has multi-access capabilities (either broadcast
    or non-broadcast) and, if so, the number of routers having an
    interface to the network.  The three cases are depicted in Figure 1.
    Rectangles indicate routers.  Circles and oblongs indicate multi-
    access networks.  Router names are prefixed with the letters RT and
    network names with the letter N.  Router interface names are
    prefixed by the letter I.  Lines between routers indicate point-to-
    point networks.  The left side of the figure shows a network with
    its connected routers, with the resulting graph shown on the right.

    Two routers joined by a point-to-point network are represented in
    the directed graph as being directly connected by a pair of edges,
    one in each direction.  Interfaces to physical point-to-point
    networks need not be assigned IP addresses.  Such a point-to-point
    network is called unnumbered.  The graphical representation of
    point-to-point networks is designed so that unnumbered networks can
    be supported naturally.  When interface addresses exist, they are
    modelled as stub routes.  Note that each router would then have a
    stub connection to the other router's interface address (see Figure
    1).

    When multiple routers are attached to a multi-access network, the
    directed graph shows all routers bidirectionally connected to the
    network vertex (again, see Figure 1).  If only a single router is
    attached to a multi-access network, the network will appear in the



Moy                                                            [Page 11]


RFC 1583                     OSPF Version 2                   March 1994





                                                  **FROM**

                                           *      |RT1|RT2|
                +---+Ia    +---+           *   ------------
                |RT1|------|RT2|           T   RT1|   | X |
                +---+    Ib+---+           O   RT2| X |   |
                                           *    Ia|   | X |
                                           *    Ib| X |   |

                     Physical point-to-point networks

                                                  **FROM**
                +---+      +---+
                |RT3|      |RT4|              |RT3|RT4|RT5|RT6|N2 |
                +---+      +---+        *  ------------------------
                  |    N2    |          *  RT3|   |   |   |   | X |
            +----------------------+    T  RT4|   |   |   |   | X |
                  |          |          O  RT5|   |   |   |   | X |
                +---+      +---+        *  RT6|   |   |   |   | X |
                |RT5|      |RT6|        *   N2| X | X | X | X |   |
                +---+      +---+

                          Multi-access networks

                                                  **FROM**
                      +---+                *
                      |RT7|                *      |RT7| N3|
                      +---+                T   ------------
                        |                  O   RT7|   |   |
            +----------------------+       *    N3| X |   |
                       N3                  *

                       Stub multi-access networks



                    Figure 1: Network map components

             Networks and routers are represented by vertices.
             An edge connects Vertex A to Vertex B iff the
             intersection of Column A and Row B is marked with
                                  an X.






Moy                                                            [Page 12]


RFC 1583                     OSPF Version 2                   March 1994


    directed graph as a stub connection.

    Each network (stub or transit) in the graph has an IP address and
    associated network mask.  The mask indicates the number of nodes on
    the network.  Hosts attached directly to routers (referred to as
    host routes) appear on the graph as stub networks.  The network mask
    for a host route is always 0xffffffff, which indicates the presence
    of a single node.

    Figure 2 shows a sample map of an Autonomous System.  The rectangle
    labelled H1 indicates a host, which has a SLIP connection to Router
    RT12.  Router RT12 is therefore advertising a host route.  Lines
    between routers indicate physical point-to-point networks.  The only
    point-to-point network that has been assigned interface addresses is
    the one joining Routers RT6 and RT10.  Routers RT5 and RT7 have EGP
    connections to other Autonomous Systems.  A set of EGP-learned
    routes have been displayed for both of these routers.

    A cost is associated with the output side of each router interface.
    This cost is configurable by the system administrator.  The lower
    the cost, the more likely the interface is to be used to forward
    data traffic.  Costs are also associated with the externally derived
    routing data (e.g., the EGP-learned routes).

    The directed graph resulting from the map in Figure 2 is depicted in
    Figure 3.  Arcs are labelled with the cost of the corresponding
    router output interface.  Arcs having no labelled cost have a cost
    of 0.  Note that arcs leading from networks to routers always have
    cost 0; they are significant nonetheless.  Note also that the
    externally derived routing data appears on the graph as stubs.

    The topological database (or what has been referred to above as the
    directed graph) is pieced together from link state advertisements
    generated by the routers.  The neighborhood of each transit vertex
    is represented in a single, separate link state advertisement.
    Figure 4 shows graphically the link state representation of the two
    kinds of transit vertices: routers and multi-access networks.
    Router RT12 has an interface to two broadcast networks and a SLIP
    line to a host.  Network N6 is a broadcast network with three
    attached routers.  The cost of all links from Network N6 to its
    attached routers is 0.  Note that the link state advertisement for
    Network N6 is actually generated by one of the attached routers: the
    router that has been elected Designated Router for the network.

    2.1.  The shortest-path tree

        When no OSPF areas are configured, each router in the Autonomous
        System has an identical topological database, leading to an



Moy                                                            [Page 13]


RFC 1583                     OSPF Version 2                   March 1994



                 +
                 | 3+---+                     N12      N14
               N1|--|RT1|\ 1                    \ N13 /
                 |  +---+ \                     8\ |8/8
                 +         \ ____                 \|/
                            /    \   1+---+8    8+---+6
                           *  N3  *---|RT4|------|RT5|--------+
                            \____/    +---+      +---+        |
                  +         /   |                  |7         |
                  | 3+---+ /    |                  |          |
                N2|--|RT2|/1    |1                 |6         |
                  |  +---+    +---+8            6+---+        |
                  +           |RT3|--------------|RT6|        |
                              +---+              +---+        |
                                |2               Ia|7         |
                                |                  |          |
                           +---------+             |          |
                               N4                  |          |
                                                   |          |
                                                   |          |
                       N11                         |          |
                   +---------+                     |          |
                        |                          |          |    N12
                        |3                         |          |6 2/
                      +---+                        |        +---+/
                      |RT9|                        |        |RT7|---N15
                      +---+                        |        +---+ 9
                        |1                   +     |          |1
                       _|__                  |   Ib|5       __|_
                      /    \      1+----+2   |  3+----+1   /    \
                     *  N9  *------|RT11|----|---|RT10|---*  N6  *
                      \____/       +----+    |   +----+    \____/
                        |                    |                |
                        |1                   +                |1
             +--+   10+----+                N8              +---+
             |H1|-----|RT12|                                |RT8|
             +--+SLIP +----+                                +---+
                        |2                                    |4
                        |                                     |
                   +---------+                            +--------+
                       N10                                    N7

                    Figure 2: A sample Autonomous System







Moy                                                            [Page 14]


RFC 1583                     OSPF Version 2                   March 1994


                                **FROM**

                 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
                 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
              ----- ---------------------------------------------
              RT1|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT2|  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |  |
              RT3|  |  |  |  |  |6 |  |  |  |  |  |  |0 |  |  |  |
              RT4|  |  |  |  |8 |  |  |  |  |  |  |  |0 |  |  |  |
              RT5|  |  |  |8 |  |6 |6 |  |  |  |  |  |  |  |  |  |
              RT6|  |  |8 |  |7 |  |  |  |  |5 |  |  |  |  |  |  |
              RT7|  |  |  |  |6 |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT8|  |  |  |  |  |  |  |  |  |  |  |  |  |0 |  |  |
          *   RT9|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          T  RT10|  |  |  |  |  |7 |  |  |  |  |  |  |  |0 |0 |  |
          O  RT11|  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |0 |
          *  RT12|  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |0 |
          *    N1|3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N2|  |3 |  |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N3|1 |1 |1 |1 |  |  |  |  |  |  |  |  |  |  |  |  |
               N4|  |  |2 |  |  |  |  |  |  |  |  |  |  |  |  |  |
               N6|  |  |  |  |  |  |1 |1 |  |1 |  |  |  |  |  |  |
               N7|  |  |  |  |  |  |  |4 |  |  |  |  |  |  |  |  |
               N8|  |  |  |  |  |  |  |  |  |3 |2 |  |  |  |  |  |
               N9|  |  |  |  |  |  |  |  |1 |  |1 |1 |  |  |  |  |
              N10|  |  |  |  |  |  |  |  |  |  |  |2 |  |  |  |  |
              N11|  |  |  |  |  |  |  |  |3 |  |  |  |  |  |  |  |
              N12|  |  |  |  |8 |  |2 |  |  |  |  |  |  |  |  |  |
              N13|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N14|  |  |  |  |8 |  |  |  |  |  |  |  |  |  |  |  |
              N15|  |  |  |  |  |  |9 |  |  |  |  |  |  |  |  |  |
               H1|  |  |  |  |  |  |  |  |  |  |  |10|  |  |  |  |


                     Figure 3: The resulting directed graph

                 Networks and routers are represented by vertices.
                 An edge of cost X connects Vertex A to Vertex B iff
                 the intersection of Column A and Row B is marked
                                     with an X.











Moy                                                            [Page 15]


RFC 1583                     OSPF Version 2                   March 1994


                     **FROM**                       **FROM**

                  |RT12|N9|N10|H1|             |RT9|RT11|RT12|N9|
           *  --------------------          *  ----------------------
           *  RT12|    |  |   |  |          *   RT9|   |    |    |0 |
           T    N9|1   |  |   |  |          T  RT11|   |    |    |0 |
           O   N10|2   |  |   |  |          O  RT12|   |    |    |0 |
           *    H1|10  |  |   |  |          *    N9|   |    |    |  |
           *                                *
                RT12's router links            N9's network links
                   advertisement                  advertisement

                  Figure 4: Individual link state components

              Networks and routers are represented by vertices.
              An edge of cost X connects Vertex A to Vertex B iff
              the intersection of Column A and Row B is marked
                                  with an X.

        identical graphical representation.  A router generates its
        routing table from this graph by calculating a tree of shortest
        paths with the router itself as root.  Obviously, the shortest-
        path tree depends on the router doing the calculation.  The
        shortest-path tree for Router RT6 in our example is depicted in
        Figure 5.

        The tree gives the entire route to any destination network or
        host.  However, only the next hop to the destination is used in
        the forwarding process.  Note also that the best route to any
        router has also been calculated.  For the processing of external
        data, we note the next hop and distance to any router
        advertising external routes.  The resulting routing table for
        Router RT6 is pictured in Table 2.  Note that there is a
        separate route for each end of a numbered serial line (in this
        case, the serial line between Routers RT6 and RT10).


        Routes to networks belonging to other AS'es (such as N12) appear
        as dashed lines on the shortest path tree in Figure 5.  Use of
        this externally derived routing information is considered in the
        next section.


    2.2.  Use of external routing information

        After the tree is created the external routing information is
        examined.  This external routing information may originate from
        another routing protocol such as EGP, or be statically



Moy                                                            [Page 16]


RFC 1583                     OSPF Version 2                   March 1994



                                RT6(origin)
                    RT5 o------------o-----------o Ib
                       /|\    6      |\     7
                     8/8|8\          | \
                     /  |  \         |  \
                    o   |   o        |   \7
                   N12  o  N14       |    \
                       N13        2  |     \
                            N4 o-----o RT3  \
                                    /        \    5
                                  1/     RT10 o-------o Ia
                                  /           |\
                       RT4 o-----o N3        3| \1
                                /|            |  \ N6     RT7
                               / |         N8 o   o---------o
                              /  |            |   |        /|
                         RT2 o   o RT1        |   |      2/ |9
                            /    |            |   |RT8   /  |
                           /3    |3      RT11 o   o     o   o
                          /      |            |   |    N12 N15
                      N2 o       o N1        1|   |4
                                              |   |
                                           N9 o   o N7
                                             /|
                                            / |
                        N11      RT9       /  |RT12
                         o--------o-------o   o--------o H1
                             3                |   10
                                              |2
                                              |
                                              o N10


                     Figure 5: The SPF tree for Router RT6

              Edges that are not marked with a cost have a cost of
              of zero (these are network-to-router links). Routes
              to networks N12-N15 are external information that is
                         considered in Section 2.2











Moy                                                            [Page 17]


RFC 1583                     OSPF Version 2                   March 1994


                   Destination   Next  Hop   Distance
                   __________________________________
                   N1            RT3         10
                   N2            RT3         10
                   N3            RT3         7
                   N4            RT3         8
                   Ib            *           7
                   Ia            RT10        12
                   N6            RT10        8
                   N7            RT10        12
                   N8            RT10        10
                   N9            RT10        11
                   N10           RT10        13
                   N11           RT10        14
                   H1            RT10        21
                   __________________________________
                   RT5           RT5         6
                   RT7           RT10        8


    Table 2: The portion of Router RT6's routing table listing local
                             destinations.

        configured (static routes).  Default routes can also be included
        as part of the Autonomous System's external routing information.

        External routing information is flooded unaltered throughout the
        AS.  In our example, all the routers in the Autonomous System
        know that Router RT7 has two external routes, with metrics 2 and
        9.

        OSPF supports two types of external metrics.  Type 1 external
        metrics are equivalent to the link state metric.  Type 2
        external metrics are greater than the cost of any path internal
        to the AS.  Use of Type 2 external metrics assumes that routing
        between AS'es is the major cost of routing a packet, and
        eliminates the need for conversion of external costs to internal
        link state metrics.

        As an example of Type 1 external metric processing, suppose that
        the Routers RT7 and RT5 in Figure 2 are advertising Type 1
        external metrics.  For each external route, the distance from
        Router RT6 is calculated as the sum of the external route's cost
        and the distance from Router RT6 to the advertising router.  For
        every external destination, the router advertising the shortest
        route is discovered, and the next hop to the advertising router
        becomes the next hop to the destination.




Moy                                                            [Page 18]


RFC 1583                     OSPF Version 2                   March 1994


        Both Router RT5 and RT7 are advertising an external route to
        destination Network N12.  Router RT7 is preferred since it is
        advertising N12 at a distance of 10 (8+2) to Router RT6, which
        is better than Router RT5's 14 (6+8).  Table 3 shows the entries
        that are added to the routing table when external routes are
        examined:



                         Destination   Next  Hop   Distance
                         __________________________________
                         N12           RT10        10
                         N13           RT5         14
                         N14           RT5         14
                         N15           RT10        17


                 Table 3: The portion of Router RT6's routing table
                           listing external destinations.


        Processing of Type 2 external metrics is simpler.  The AS
        boundary router advertising the smallest external metric is
        chosen, regardless of the internal distance to the AS boundary
        router.  Suppose in our example both Router RT5 and Router RT7
        were advertising Type 2 external routes.  Then all traffic
        destined for Network N12 would be forwarded to Router RT7, since
        2 < 8.  When several equal-cost Type 2 routes exist, the
        internal distance to the advertising routers is used to break
        the tie.

        Both Type 1 and Type 2 external metrics can be present in the AS
        at the same time.  In that event, Type 1 external metrics always
        take precedence.

        This section has assumed that packets destined for external
        destinations are always routed through the advertising AS
        boundary router.  This is not always desirable.  For example,
        suppose in Figure 2 there is an additional router attached to
        Network N6, called Router RTX.  Suppose further that RTX does
        not participate in OSPF routing, but does exchange EGP
        information with the AS boundary router RT7.  Then, Router RT7
        would end up advertising OSPF external routes for all
        destinations that should be routed to RTX.  An extra hop will
        sometimes be introduced if packets for these destinations need
        always be routed first to Router RT7 (the advertising router).

        To deal with this situation, the OSPF protocol allows an AS



Moy                                                            [Page 19]


RFC 1583                     OSPF Version 2                   March 1994


        boundary router to specify a "forwarding address" in its
        external advertisements.  In the above example, Router RT7 would
        specify RTX's IP address as the "forwarding address" for all
        those destinations whose packets should be routed directly to
        RTX.

        The "forwarding address" has one other application.  It enables
        routers in the Autonomous System's interior to function as
        "route servers".  For example, in Figure 2 the router RT6 could
        become a route server, gaining external routing information
        through a combination of static configuration and external
        routing protocols.  RT6 would then start advertising itself as
        an AS boundary router, and would originate a collection of OSPF
        external advertisements.  In each external advertisement, Router
        RT6 would specify the correct Autonomous System exit point to
        use for the destination through appropriate setting of the
        advertisement's "forwarding address" field.


    2.3.  Equal-cost multipath

        The above discussion has been simplified by considering only a
        single route to any destination.  In reality, if multiple
        equal-cost routes to a destination exist, they are all
        discovered and used.  This requires no conceptual changes to the
        algorithm, and its discussion is postponed until we consider the
        tree-building process in more detail.

        With equal cost multipath, a router potentially has several
        available next hops towards any given destination.


    2.4.  TOS-based routing

        OSPF can calculate a separate set of routes for each IP Type of
        Service. This means that, for any destination, there can
        potentially be multiple routing table entries, one for each IP
        TOS. The IP TOS values are represented in OSPF exactly as they
        appear in the IP packet header.

        Up to this point, all examples shown have assumed that routes do
        not vary on TOS.  In order to differentiate routes based on TOS,
        separate interface costs can be configured for each TOS.  For
        example, in Figure 2 there could be multiple costs (one for each
        TOS) listed for each interface.  A cost for TOS 0 must always be
        specified.

        When interface costs vary based on TOS, a separate shortest path



Moy                                                            [Page 20]


RFC 1583                     OSPF Version 2                   March 1994


        tree is calculated for each TOS (see Section 2.1).  In addition,
        external costs can vary based on TOS.  For example, in Figure 2
        Router RT7 could advertise a separate type 1 external metric for
        each TOS.  Then, when calculating the TOS X distance to Network
        N15 the cost of the shortest TOS X path to RT7 would be added to
        the TOS X cost advertised by RT7 for Network N15 (see Section
        2.2).

        All OSPF implementations must be capable of calculating routes
        based on TOS.  However, OSPF routers can be configured to route
        all packets on the TOS 0 path (see Appendix C), eliminating the
        need to calculate non-zero TOS paths.  This can be used to
        conserve routing table space and processing resources in the
        router.  These TOS-0-only routers can be mixed with routers that
        do route based on TOS.  TOS-0-only routers will be avoided as
        much as possible when forwarding traffic requesting a non-zero
        TOS.

        It may be the case that no path exists for some non-zero TOS,
        even if the router is calculating non-zero TOS paths.  In that
        case, packets requesting that non-zero TOS are routed along the
        TOS 0 path (see Section 11.1).


3.  Splitting the AS into Areas

    OSPF allows collections of contiguous networks and hosts to be
    grouped together.  Such a group, together with the routers having
    interfaces to any one of the included networks, is called an area.
    Each area runs a separate copy of the basic link-state routing
    algorithm.  This means that each area has its own topological
    database and corresponding graph, as explained in the previous
    section.

    The topology of an area is invisible from the outside of the area.
    Conversely, routers internal to a given area know nothing of the
    detailed topology external to the area.  This isolation of knowledge
    enables the protocol to effect a marked reduction in routing traffic
    as compared to treating the entire Autonomous System as a single
    link-state domain.

    With the introduction of areas, it is no longer true that all
    routers in the AS have an identical topological database.  A router
    actually has a separate topological database for each area it is
    connected to.  (Routers connected to multiple areas are called area
    border routers).  Two routers belonging to the same area have, for
    that area, identical area topological databases.




Moy                                                            [Page 21]


RFC 1583                     OSPF Version 2                   March 1994


    Routing in the Autonomous System takes place on two levels,
    depending on whether the source and destination of a packet reside
    in the same area (intra-area routing is used) or different areas
    (inter-area routing is used).  In intra-area routing, the packet is
    routed solely on information obtained within the area; no routing
    information obtained from outside the area can be used.  This
    protects intra-area routing from the injection of bad routing
    information.  We discuss inter-area routing in Section 3.2.


    3.1.  The backbone of the Autonomous System

        The backbone consists of those networks not contained in any
        area, their attached routers, and those routers that belong to
        multiple areas.  The backbone must be contiguous.

        It is possible to define areas in such a way that the backbone
        is no longer contiguous.  In this case the system administrator
        must restore backbone connectivity by configuring virtual links.

        Virtual links can be configured between any two backbone routers
        that have an interface to a common non-backbone area.  Virtual
        links belong to the backbone.  The protocol treats two routers
        joined by a virtual link as if they were connected by an
        unnumbered point-to-point network.  On the graph of the
        backbone, two such routers are joined by arcs whose costs are
        the intra-area distances between the two routers.  The routing
        protocol traffic that flows along the virtual link uses intra-
        area routing only.

        The backbone is responsible for distributing routing information
        between areas.  The backbone itself has all of the properties of
        an area.  The topology of the backbone is invisible to each of
        the areas, while the backbone itself knows nothing of the
        topology of the areas.


    3.2.  Inter-area routing

        When routing a packet between two areas the backbone is used.
        The path that the packet will travel can be broken up into three
        contiguous pieces: an intra-area path from the source to an area
        border router, a backbone path between the source and
        destination areas, and then another intra-area path to the
        destination.  The algorithm finds the set of such paths that
        have the smallest cost.

        Looking at this another way, inter-area routing can be pictured



Moy                                                            [Page 22]


RFC 1583                     OSPF Version 2                   March 1994


        as forcing a star configuration on the Autonomous System, with
        the backbone as hub and each of the areas as spokes.

        The topology of the backbone dictates the backbone paths used
        between areas.  The topology of the backbone can be enhanced by
        adding virtual links.  This gives the system administrator some
        control over the routes taken by inter-area traffic.

        The correct area border router to use as the packet exits the
        source area is chosen in exactly the same way routers
        advertising external routes are chosen.  Each area border router
        in an area summarizes for the area its cost to all networks
        external to the area.  After the SPF tree is calculated for the
        area, routes to all other networks are calculated by examining
        the summaries of the area border routers.


    3.3.  Classification of routers

        Before the introduction of areas, the only OSPF routers having a
        specialized function were those advertising external routing
        information, such as Router RT5 in Figure 2.  When the AS is
        split into OSPF areas, the routers are further divided according
        to function into the following four overlapping categories:


        Internal routers
            A router with all directly connected networks belonging to
            the same area.  Routers with only backbone interfaces also
            belong to this category.  These routers run a single copy of
            the basic routing algorithm.

        Area border routers
            A router that attaches to multiple areas.  Area border
            routers run multiple copies of the basic algorithm, one copy
            for each attached area and an additional copy for the
            backbone.  Area border routers condense the topological
            information of their attached areas for distribution to the
            backbone.  The backbone in turn distributes the information
            to the other areas.

        Backbone routers
            A router that has an interface to the backbone.  This
            includes all routers that interface to more than one area
            (i.e., area border routers).  However, backbone routers do
            not have to be area border routers.  Routers with all
            interfaces connected to the backbone are considered to be
            internal routers.



Moy                                                            [Page 23]


RFC 1583                     OSPF Version 2                   March 1994


        AS boundary routers
            A router that exchanges routing information with routers
            belonging to other Autonomous Systems.  Such a router has AS
            external routes that are advertised throughout the
            Autonomous System.  The path to each AS boundary router is
            known by every router in the AS.  This classification is
            completely independent of the previous classifications: AS
            boundary routers may be internal or area border routers, and
            may or may not participate in the backbone.


    3.4.  A sample area configuration

        Figure 6 shows a sample area configuration.  The first area
        consists of networks N1-N4, along with their attached routers
        RT1-RT4.  The second area consists of networks N6-N8, along with
        their attached routers RT7, RT8, RT10 and RT11.  The third area
        consists of networks N9-N11 and Host H1, along with their
        attached routers RT9, RT11 and RT12.  The third area has been
        configured so that networks N9-N11 and Host H1 will all be
        grouped into a single route, when advertised external to the
        area (see Section 3.5 for more details).

        In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are
        internal routers.  Routers RT3, RT4, RT7, RT10 and RT11 are area
        border routers.  Finally, as before, Routers RT5 and RT7 are AS
        boundary routers.

        Figure 7 shows the resulting topological database for the Area
        1.  The figure completely describes that area's intra-area
        routing.  It also shows the complete view of the internet for
        the two internal routers RT1 and RT2.  It is the job of the area
        border routers, RT3 and RT4, to advertise into Area 1 the
        distances to all destinations external to the area.  These are
        indicated in Figure 7 by the dashed stub routes.  Also, RT3 and
        RT4 must advertise into Area 1 the location of the AS boundary
        routers RT5 and RT7.  Finally, external advertisements from RT5
        and RT7 are flooded throughout the entire AS, and in particular
        throughout Area 1.  These advertisements are included in Area
        1's database, and yield routes to Networks N12-N15.

        Routers RT3 and RT4 must also summarize Area 1's topology for
        distribution to the backbone.  Their backbone advertisements are
        shown in Table 4.  These summaries show which networks are
        contained in Area 1 (i.e., Networks N1-N4), and the distance to
        these networks from the routers RT3 and RT4 respectively.





Moy                                                            [Page 24]


RFC 1583                     OSPF Version 2                   March 1994



             ...........................
             .   +                     .
             .   | 3+---+              .      N12      N14
             . N1|--|RT1|\ 1           .        \ N13 /
             .   |  +---+ \            .        8\ |8/8
             .   +         \ ____      .          \|/
             .              /    \   1+---+8    8+---+6
             .             *  N3  *---|RT4|------|RT5|--------+
             .              \____/    +---+      +---+        |
             .    +         /      \   .           |7         |
             .    | 3+---+ /        \  .           |          |
             .  N2|--|RT2|/1        1\ .           |6         |
             .    |  +---+            +---+8    6+---+        |
             .    +                   |RT3|------|RT6|        |
             .                        +---+      +---+        |
             .                      2/ .         Ia|7         |
             .                      /  .           |          |
             .             +---------+ .           |          |
             .Area 1           N4      .           |          |
             ...........................           |          |
          ..........................               |          |
          .            N11         .               |          |
          .        +---------+     .               |          |
          .             |          .               |          |    N12
          .             |3         .             Ib|5         |6 2/
          .           +---+        .             +----+     +---+/
          .           |RT9|        .    .........|RT10|.....|RT7|---N15.
          .           +---+        .    .        +----+     +---+ 9    .
          .             |1         .    .    +  /3    1\      |1       .
          .            _|__        .    .    | /        \   __|_       .
          .           /    \      1+----+2   |/          \ /    \      .
          .          *  N9  *------|RT11|----|            *  N6  *     .
          .           \____/       +----+    |             \____/      .
          .             |          .    .    |                |        .
          .             |1         .    .    +                |1       .
          .  +--+   10+----+       .    .   N8              +---+      .
          .  |H1|-----|RT12|       .    .                   |RT8|      .
          .  +--+SLIP +----+       .    .                   +---+      .
          .             |2         .    .                     |4       .
          .             |          .    .                     |        .
          .        +---------+     .    .                 +--------+   .
          .            N10         .    .                     N7       .
          .                        .    .Area 2                        .
          .Area 3                  .    ................................
          ..........................

                    Figure 6: A sample OSPF area configuration



Moy                                                            [Page 25]


RFC 1583                     OSPF Version 2                   March 1994


                     Network   RT3 adv.   RT4 adv.
                     _____________________________
                     N1        4          4
                     N2        4          4
                     N3        1          1
                     N4        2          3


              Table 4: Networks advertised to the backbone
                        by Routers RT3 and RT4.

        The topological database for the backbone is shown in Figure 8.
        The set of routers pictured are the backbone routers.  Router
        RT11 is a backbone router because it belongs to two areas.  In
        order to make the backbone connected, a virtual link has been
        configured between Routers R10 and R11.

        Again, Routers RT3, RT4, RT7, RT10 and RT11 are area border
        routers.  As Routers RT3 and RT4 did above, they have condensed
        the routing information of their attached areas for distribution
        via the backbone; these are the dashed stubs that appear in
        Figure 8.  Remember that the third area has been configured to
        condense Networks N9-N11 and Host H1 into a single route.  This
        yields a single dashed line for networks N9-N11 and Host H1 in
        Figure 8.  Routers RT5 and RT7 are AS boundary routers; their
        externally derived information also appears on the graph in
        Figure 8 as stubs.

        The backbone enables the exchange of summary information between
        area border routers.  Every area border router hears the area
        summaries from all other area border routers.  It then forms a
        picture of the distance to all networks outside of its area by
        examining the collected advertisements, and adding in the
        backbone distance to each advertising router.

        Again using Routers RT3 and RT4 as an example, the procedure
        goes as follows: They first calculate the SPF tree for the
        backbone.  This gives the distances to all other area border
        routers.  Also noted are the distances to networks (Ia and Ib)
        and AS boundary routers (RT5 and RT7) that belong to the
        backbone.  This calculation is shown in Table 5.


        Next, by looking at the area summaries from these area border
        routers, RT3 and RT4 can determine the distance to all networks
        outside their area.  These distances are then advertised
        internally to the area by RT3 and RT4.  The advertisements that
        Router RT3 and RT4 will make into Area 1 are shown in Table 6.



Moy                                                            [Page 26]


RFC 1583                     OSPF Version 2                   March 1994



                               **FROM**

                          |RT|RT|RT|RT|RT|RT|
                          |1 |2 |3 |4 |5 |7 |N3|
                       ----- -------------------
                       RT1|  |  |  |  |  |  |0 |
                       RT2|  |  |  |  |  |  |0 |
                       RT3|  |  |  |  |  |  |0 |
                   *   RT4|  |  |  |  |  |  |0 |
                   *   RT5|  |  |14|8 |  |  |  |
                   T   RT7|  |  |20|14|  |  |  |
                   O    N1|3 |  |  |  |  |  |  |
                   *    N2|  |3 |  |  |  |  |  |
                   *    N3|1 |1 |1 |1 |  |  |  |
                        N4|  |  |2 |  |  |  |  |
                     Ia,Ib|  |  |15|22|  |  |  |
                        N6|  |  |16|15|  |  |  |
                        N7|  |  |20|19|  |  |  |
                        N8|  |  |18|18|  |  |  |
                 N9-N11,H1|  |  |19|16|  |  |  |
                       N12|  |  |  |  |8 |2 |  |
                       N13|  |  |  |  |8 |  |  |
                       N14|  |  |  |  |8 |  |  |
                       N15|  |  |  |  |  |9 |  |

                      Figure 7: Area 1's Database.

              Networks and routers are represented by vertices.
              An edge of cost X connects Vertex A to Vertex B iff
              the intersection of Column A and Row B is marked
                               with an X.



















Moy                                                            [Page 27]


RFC 1583                     OSPF Version 2                   March 1994


                                  **FROM**

                            |RT|RT|RT|RT|RT|RT|RT
                            |3 |4 |5 |6 |7 |10|11|
                         ------------------------
                         RT3|  |  |  |6 |  |  |  |
                         RT4|  |  |8 |  |  |  |  |
                         RT5|  |8 |  |6 |6 |  |  |
                         RT6|8 |  |7 |  |  |5 |  |
                         RT7|  |  |6 |  |  |  |  |
                     *  RT10|  |  |  |7 |  |  |2 |
                     *  RT11|  |  |  |  |  |3 |  |
                     T    N1|4 |4 |  |  |  |  |  |
                     O    N2|4 |4 |  |  |  |  |  |
                     *    N3|1 |1 |  |  |  |  |  |
                     *    N4|2 |3 |  |  |  |  |  |
                          Ia|  |  |  |  |  |5 |  |
                          Ib|  |  |  |7 |  |  |  |
                          N6|  |  |  |  |1 |1 |3 |
                          N7|  |  |  |  |5 |5 |7 |
                          N8|  |  |  |  |4 |3 |2 |
                   N9-N11,H1|  |  |  |  |  |  |1 |
                         N12|  |  |8 |  |2 |  |  |
                         N13|  |  |8 |  |  |  |  |
                         N14|  |  |8 |  |  |  |  |
                         N15|  |  |  |  |9 |  |  |


                     Figure 8: The backbone's database.

              Networks and routers are represented by vertices.
              An edge of cost X connects Vertex A to Vertex B iff
              the intersection of Column A and Row B is marked
                                 with an X.

















Moy                                                            [Page 28]


RFC 1583                     OSPF Version 2                   March 1994


                 Area  border   dist  from   dist  from
                 router         RT3          RT4
                 ______________________________________
                 to  RT3        *            21
                 to  RT4        22           *
                 to  RT7        20           14
                 to  RT10       15           22
                 to  RT11       18           25
                 ______________________________________
                 to  Ia         20           27
                 to  Ib         15           22
                 ______________________________________
                 to  RT5        14           8
                 to  RT7        20           14


                 Table 5: Backbone distances calculated
                        by Routers RT3 and RT4.

        Note that Table 6 assumes that an area range has been configured
        for the backbone which groups Ia and Ib into a single
        advertisement.


        The information imported into Area 1 by Routers RT3 and RT4
        enables an internal router, such as RT1, to choose an area
        border router intelligently.  Router RT1 would use RT4 for
        traffic to Network N6, RT3 for traffic to Network N10, and would
        load share between the two for traffic to Network N8.



                   Destination   RT3 adv.   RT4 adv.
                   _________________________________
                   Ia,Ib         15         22
                   N6            16         15
                   N7            20         19
                   N8            18         18
                   N9-N11,H1     19         26
                   _________________________________
                   RT5           14         8
                   RT7           20         14


              Table 6: Destinations advertised into Area 1
                        by Routers RT3 and RT4.





Moy                                                            [Page 29]


RFC 1583                     OSPF Version 2                   March 1994


        Router RT1 can also determine in this manner the shortest path
        to the AS boundary routers RT5 and RT7.  Then, by looking at RT5
        and RT7's external advertisements, Router RT1 can decide between
        RT5 or RT7 when sending to a destination in another Autonomous
        System (one of the networks N12-N15).

        Note that a failure of the line between Routers RT6 and RT10
        will cause the backbone to become disconnected.  Configuring a
        virtual link between Routers RT7 and RT10 will give the backbone
        more connectivity and more resistance to such failures. Also, a
        virtual link between RT7 and RT10 would allow a much shorter
        path between the third area (containing N9) and the router RT7,
        which is advertising a good route to external network N12.


    3.5.  IP subnetting support

        OSPF attaches an IP address mask to each advertised route.  The
        mask indicates the range of addresses being described by the
        particular route.  For example, a summary advertisement for the
        destination 128.185.0.0 with a mask of 0xffff0000 actually is
        describing a single route to the collection of destinations
        128.185.0.0 - 128.185.255.255.  Similarly, host routes are
        always advertised with a mask of 0xffffffff, indicating the
        presence of only a single destination.

        Including the mask with each advertised destination enables the
        implementation of what is commonly referred to as variable-
        length subnetting.  This means that a single IP class A, B, or C
        network number can be broken up into many subnets of various
        sizes.  For example, the network 128.185.0.0 could be broken up
        into 62 variable-sized subnets: 15 subnets of size 4K, 15
        subnets of size 256, and 32 subnets of size 8.  Table 7 shows
        some of the resulting network addresses together with their
        masks:



                  Network address   IP address mask   Subnet size
                  _______________________________________________
                  128.185.16.0      0xfffff000        4K
                  128.185.1.0       0xffffff00        256
                  128.185.0.8       0xfffffff8        8


                         Table 7: Some sample subnet sizes.





Moy                                                            [Page 30]


RFC 1583                     OSPF Version 2                   March 1994


        There are many possible ways of dividing up a class A, B, and C
        network into variable sized subnets.  The precise procedure for
        doing so is beyond the scope of this specification.  This
        specification however establishes the following guideline: When
        an IP packet is forwarded, it is always forwarded to the network
        that is the best match for the packet's destination.  Here best
        match is synonymous with the longest or most specific match.
        For example, the default route with destination of 0.0.0.0 and
        mask 0x00000000 is always a match for every IP destination.  Yet
        it is always less specific than any other match.  Subnet masks
        must be assigned so that the best match for any IP destination
        is unambiguous.

        The OSPF area concept is modelled after an IP subnetted network.
        OSPF areas have been loosely defined to be a collection of
        networks.  In actuality, an OSPF area is specified to be a list
        of address ranges (see Section C.2 for more details).  Each
        address range is defined as an [address,mask] pair.  Many
        separate networks may then be contained in a single address
        range, just as a subnetted network is composed of many separate
        subnets.  Area border routers then summarize the area contents
        (for distribution to the backbone) by advertising a single route
        for each address range.  The cost of the route is the minimum
        cost to any of the networks falling in the specified range.

        For example, an IP subnetted network can be configured as a
        single OSPF area.  In that case, the area would be defined as a
        single address range: a class A, B, or C network number along
        with its natural IP mask.  Inside the area, any number of
        variable sized subnets could be defined.  External to the area,
        a single route for the entire subnetted network would be
        distributed, hiding even the fact that the network is subnetted
        at all.  The cost of this route is the minimum of the set of
        costs to the component subnets.


    3.6.  Supporting stub areas

        In some Autonomous Systems, the majority of the topological
        database may consist of AS external advertisements.  An OSPF AS
        external advertisement is usually flooded throughout the entire
        AS.  However, OSPF allows certain areas to be configured as
        "stub areas".  AS external advertisements are not flooded
        into/throughout stub areas; routing to AS external destinations
        in these areas is based on a (per-area) default only.  This
        reduces the topological database size, and therefore the memory
        requirements, for a stub area's internal routers.




Moy                                                            [Page 31]


RFC 1583                     OSPF Version 2                   March 1994


        In order to take advantage of the OSPF stub area support,
        default routing must be used in the stub area.  This is
        accomplished as follows.  One or more of the stub area's area
        border routers must advertise a default route into the stub area
        via summary link advertisements.  These summary defaults are
        flooded throughout the stub area, but no further.  (For this
        reason these defaults pertain only to the particular stub area).
        These summary default routes will match any destination that is
        not explicitly reachable by an intra-area or inter-area path
        (i.e., AS external destinations).

        An area can be configured as stub when there is a single exit
        point from the area, or when the choice of exit point need not
        be made on a per-external-destination basis.  For example, Area
        3 in Figure 6 could be configured as a stub area, because all
        external traffic must travel though its single area border
        router RT11.  If Area 3 were configured as a stub, Router RT11
        would advertise a default route for distribution inside Area 3
        (in a summary link advertisement), instead of flooding the AS
        external advertisements for Networks N12-N15 into/throughout the
        area.

        The OSPF protocol ensures that all routers belonging to an area
        agree on whether the area has been configured as a stub.  This
        guarantees that no confusion will arise in the flooding of AS
        external advertisements.

        There are a couple of restrictions on the use of stub areas.
        Virtual links cannot be configured through stub areas.  In
        addition, AS boundary routers cannot be placed internal to stub
        areas.


    3.7.  Partitions of areas

        OSPF does not actively attempt to repair area partitions.  When
        an area becomes partitioned, each component simply becomes a
        separate area.  The backbone then performs routing between the
        new areas.  Some destinations reachable via intra-area routing
        before the partition will now require inter-area routing.

        In the previous section, an area was described as a list of
        address ranges.  Any particular address range must still be
        completely contained in a single component of the area
        partition.  This has to do with the way the area contents are
        summarized to the backbone.  Also, the backbone itself must not
        partition.  If it does, parts of the Autonomous System will
        become unreachable.  Backbone partitions can be repaired by



Moy                                                            [Page 32]


RFC 1583                     OSPF Version 2                   March 1994


        configuring virtual links (see Section 15).

        Another way to think about area partitions is to look at the
        Autonomous System graph that was introduced in Section 2.  Area
        IDs can be viewed as colors for the graph's edges.[1] Each edge
        of the graph connects to a network, or is itself a point-to-
        point network.  In either case, the edge is colored with the
        network's Area ID.

        A group of edges, all having the same color, and interconnected
        by vertices, represents an area.  If the topology of the
        Autonomous System is intact, the graph will have several regions
        of color, each color being a distinct Area ID.

        When the AS topology changes, one of the areas may become
        partitioned.  The graph of the AS will then have multiple
        regions of the same color (Area ID).  The routing in the
        Autonomous System will continue to function as long as these
        regions of same color are connected by the single backbone
        region.































Moy                                                            [Page 33]


RFC 1583                     OSPF Version 2                   March 1994


4.  Functional Summary

    A separate copy of OSPF's basic routing algorithm runs in each area.
    Routers having interfaces to multiple areas run multiple copies of
    the algorithm.  A brief summary of the routing algorithm follows.

    When a router starts, it first initializes the routing protocol data
    structures.  The router then waits for indications from the lower-
    level protocols that its interfaces are functional.

    A router then uses the OSPF's Hello Protocol to acquire neighbors.
    The router sends Hello packets to its neighbors, and in turn
    receives their Hello packets.  On broadcast and point-to-point
    networks, the router dynamically detects its neighboring routers by
    sending its Hello packets to the multicast address AllSPFRouters.
    On non-broadcast networks, some configuration information is
    necessary in order to discover neighbors.  On all multi-access
    networks (broadcast or non-broadcast), the Hello Protocol also
    elects a Designated router for the network.

    The router will attempt to form adjacencies with some of its newly
    acquired neighbors.  Topological databases are synchronized between
    pairs of adjacent routers.  On multi-access networks, the Designated
    Router determines which routers should become adjacent.

    Adjacencies control the distribution of routing protocol packets.
    Routing protocol packets are sent and received only on adjacencies.
    In particular, distribution of topological database updates proceeds
    along adjacencies.

    A router periodically advertises its state, which is also called
    link state.  Link state is also advertised when a router's state
    changes.  A router's adjacencies are reflected in the contents of
    its link state advertisements.  This relationship between
    adjacencies and link state allows the protocol to detect dead
    routers in a timely fashion.

    Link state advertisements are flooded throughout the area.  The
    flooding algorithm is reliable, ensuring that all routers in an area
    have exactly the same topological database.  This database consists
    of the collection of link state advertisements received from each
    router belonging to the area.  From this database each router
    calculates a shortest-path tree, with itself as root.  This
    shortest-path tree in turn yields a routing table for the protocol.







Moy                                                            [Page 34]


RFC 1583                     OSPF Version 2                   March 1994


    4.1.  Inter-area routing

        The previous section described the operation of the protocol
        within a single area.  For intra-area routing, no other routing
        information is pertinent.  In order to be able to route to
        destinations outside of the area, the area border routers inject
        additional routing information into the area.  This additional
        information is a distillation of the rest of the Autonomous
        System's topology.

        This distillation is accomplished as follows: Each area border
        router is by definition connected to the backbone.  Each area
        border router summarizes the topology of its attached areas for
        transmission on the backbone, and hence to all other area border
        routers.  An area border router then has complete topological
        information concerning the backbone, and the area summaries from
        each of the other area border routers.  From this information,
        the router calculates paths to all destinations not contained in
        its attached areas.  The router then advertises these paths into
        its attached areas.  This enables the area's internal routers to
        pick the best exit router when forwarding traffic to
        destinations in other areas.


    4.2.  AS external routes

        Routers that have information regarding other Autonomous Systems
        can flood this information throughout the AS.  This external
        routing information is distributed verbatim to every
        participating router.  There is one exception: external routing
        information is not flooded into "stub" areas (see Section 3.6).

        To utilize external routing information, the path to all routers
        advertising external information must be known throughout the AS
        (excepting the stub areas).  For that reason, the locations of
        these AS boundary routers are summarized by the (non-stub) area
        border routers.


    4.3.  Routing protocol packets

        The OSPF protocol runs directly over IP, using IP protocol 89.
        OSPF does not provide any explicit fragmentation/reassembly
        support.  When fragmentation is necessary, IP
        fragmentation/reassembly is used.  OSPF protocol packets have
        been designed so that large protocol packets can generally be
        split into several smaller protocol packets.  This practice is
        recommended; IP fragmentation should be avoided whenever



Moy                                                            [Page 35]


RFC 1583                     OSPF Version 2                   March 1994


        possible.

        Routing protocol packets should always be sent with the IP TOS
        field set to 0.  If at all possible, routing protocol packets
        should be given preference over regular IP data traffic, both
        when being sent and received.  As an aid to accomplishing this,
        OSPF protocol packets should have their IP precedence field set
        to the value Internetwork Control (see [RFC 791]).

        All OSPF protocol packets share a common protocol header that is
        described in Appendix A.  The OSPF packet types are listed below
        in Table 8.  Their formats are also described in Appendix A.



             Type   Packet  name           Protocol  function
             __________________________________________________________
             1      Hello                  Discover/maintain  neighbors
             2      Database Description   Summarize database contents
             3      Link State Request     Database download
             4      Link State Update      Database update
             5      Link State Ack         Flooding acknowledgment


                            Table 8: OSPF packet types.


        OSPF's Hello protocol uses Hello packets to discover and
        maintain neighbor relationships.  The Database Description and
        Link State Request packets are used in the forming of
        adjacencies.  OSPF's reliable update mechanism is implemented by
        the Link State Update and Link State Acknowledgment packets.

        Each Link State Update packet carries a set of new link state
        advertisements one hop further away from their point of
        origination.  A single Link State Update packet may contain the
        link state advertisements of several routers.  Each
        advertisement is tagged with the ID of the originating router
        and a checksum of its link state contents.  The five different
        types of OSPF link state advertisements are listed below in
        Table 9.

        As mentioned above, OSPF routing packets (with the exception of
        Hellos) are sent only over adjacencies.  Note that this means
        that all OSPF protocol packets travel a single IP hop, except
        those that are sent over virtual adjacencies.  The IP source
        address of an OSPF protocol packet is one end of a router
        adjacency, and the IP destination address is either the other



Moy                                                            [Page 36]


RFC 1583                     OSPF Version 2                   March 1994




       LS     Advertisement      Advertisement description
       type   name
       _________________________________________________________
       1      Router links       Originated by all routers.
              advertisements     This advertisement describes
                                 the collected states of the
                                 router's interfaces to an
                                 area. Flooded throughout a
                                 single area only.
       _________________________________________________________
       2      Network links      Originated for multi-access
              advertisements     networks by the Designated
                                 Router. This advertisement
                                 contains the list of routers
                                 connected to the network.
                                 Flooded throughout a single
                                 area only.
       _________________________________________________________
       3,4    Summary link       Originated by area border
              advertisements     routers, and flooded through-
                                 out the advertisement's
                                 associated area. Each summary
                                 link advertisement describes
                                 a route to a destination out-
                                 side the area, yet still inside
                                 the AS (i.e., an inter-area
                                 route). Type 3 advertisements
                                 describe routes to networks.
                                 Type 4 advertisements describe
                                 routes to AS boundary routers.
       _________________________________________________________
       5      AS external link   Originated by AS boundary
              advertisements     routers, and flooded through-
                                 out the AS. Each AS external
                                 link advertisement describes
                                 a route to a destination in
                                 another Autonomous System.
                                 Default routes for the AS can
                                 also be described by AS
                                 external link advertisements.


                Table 9: OSPF link state advertisements.






Moy                                                            [Page 37]


RFC 1583                     OSPF Version 2                   March 1994


        end of the adjacency or an IP multicast address.


    4.4.  Basic implementation requirements

        An implementation of OSPF requires the following pieces of
        system support:


        Timers
            Two different kind of timers are required.  The first kind,
            called single shot timers, fire once and cause a protocol
            event to be processed.  The second kind, called interval
            timers, fire at continuous intervals.  These are used for
            the sending of packets at regular intervals.  A good example
            of this is the regular broadcast of Hello packets (on
            broadcast networks).  The granularity of both kinds of
            timers is one second.

            Interval timers should be implemented to avoid drift.  In
            some router implementations, packet processing can affect
            timer execution.  When multiple routers are attached to a
            single network, all doing broadcasts, this can lead to the
            synchronization of routing packets (which should be
            avoided).  If timers cannot be implemented to avoid drift,
            small random amounts should be added to/subtracted from the
            timer interval at each firing.

        IP multicast
            Certain OSPF packets take the form of IP multicast
            datagrams.  Support for receiving and sending IP multicast
            datagrams, along with the appropriate lower-level protocol
            support, is required.  The IP multicast datagrams used by
            OSPF never travel more than one hop. For this reason, the
            ability to forward IP multicast datagrams is not required.
            For information on IP multicast, see [RFC 1112].

        Variable-length subnet support
            The router's IP protocol support must include the ability to
            divide a single IP class A, B, or C network number into many
            subnets of various sizes.  This is commonly called
            variable-length subnetting; see Section 3.5 for details.

        IP supernetting support
            The router's IP protocol support must include the ability to
            aggregate contiguous collections of IP class A, B, and C
            networks into larger quantities called supernets.
            Supernetting has been proposed as one way to improve the



Moy                                                            [Page 38]


RFC 1583                     OSPF Version 2                   March 1994


            scaling of IP routing in the worldwide Internet. For more
            information on IP supernetting, see [RFC 1519].

        Lower-level protocol support
            The lower level protocols referred to here are the network
            access protocols, such as the Ethernet data link layer.
            Indications must be passed from these protocols to OSPF as
            the network interface goes up and down.  For example, on an
            ethernet it would be valuable to know when the ethernet
            transceiver cable becomes unplugged.

        Non-broadcast lower-level protocol support
            Remember that non-broadcast networks are multi-access
            networks such as a X.25 PDN.  On these networks, the Hello
            Protocol can be aided by providing an indication to OSPF
            when an attempt is made to send a packet to a dead or non-
            existent router.  For example, on an X.25 PDN a dead
            neighboring router may be indicated by the reception of a
            X.25 clear with an appropriate cause and diagnostic, and
            this information would be passed to OSPF.

        List manipulation primitives
            Much of the OSPF functionality is described in terms of its
            operation on lists of link state advertisements.  For
            example, the collection of advertisements that will be
            retransmitted to an adjacent router until acknowledged are
            described as a list.  Any particular advertisement may be on
            many such lists.  An OSPF implementation needs to be able to
            manipulate these lists, adding and deleting constituent
            advertisements as necessary.

        Tasking support
            Certain procedures described in this specification invoke
            other procedures.  At times, these other procedures should
            be executed in-line, that is, before the current procedure
            is finished.  This is indicated in the text by instructions
            to execute a procedure.  At other times, the other
            procedures are to be executed only when the current
            procedure has finished.  This is indicated by instructions
            to schedule a task.


    4.5.  Optional OSPF capabilities

        The OSPF protocol defines several optional capabilities.  A
        router indicates the optional capabilities that it supports in
        its OSPF Hello packets, Database Description packets and in its
        link state advertisements.  This enables routers supporting a



Moy                                                            [Page 39]


RFC 1583                     OSPF Version 2                   March 1994


        mix of optional capabilities to coexist in a single Autonomous
        System.

        Some capabilities must be supported by all routers attached to a
        specific area.  In this case, a router will not accept a
        neighbor's Hello Packet unless there is a match in reported
        capabilities (i.e., a capability mismatch prevents a neighbor
        relationship from forming).  An example of this is the
        ExternalRoutingCapability (see below).

        Other capabilities can be negotiated during the Database
        Exchange process.  This is accomplished by specifying the
        optional capabilities in Database Description packets.  A
        capability mismatch with a neighbor in this case will result in
        only a subset of link state advertisements being exchanged
        between the two neighbors.

        The routing table build process can also be affected by the
        presence/absence of optional capabilities.  For example, since
        the optional capabilities are reported in link state
        advertisements, routers incapable of certain functions can be
        avoided when building the shortest path tree.  An example of
        this is the TOS routing capability (see below).

        The current OSPF optional capabilities are listed below.  See
        Section A.2 for more information.


        ExternalRoutingCapability
            Entire OSPF areas can be configured as "stubs" (see Section
            3.6).  AS external advertisements will not be flooded into
            stub areas.  This capability is represented by the E-bit in
            the OSPF options field (see Section A.2).  In order to
            ensure consistent configuration of stub areas, all routers
            interfacing to such an area must have the E-bit clear in
            their Hello packets (see Sections 9.5 and 10.5).

        TOS capability
            All OSPF implementations must be able to calculate separate
            routes based on IP Type of Service.  However, to save
            routing table space and processing resources, an OSPF router
            can be configured to ignore TOS when forwarding packets.  In
            this case, the router calculates routes for TOS 0 only.
            This capability is represented by the T-bit in the OSPF
            options field (see Section A.2).  TOS-capable routers will
            attempt to avoid non-TOS-capable routers when calculating
            non-zero TOS paths.




Moy                                                            [Page 40]


RFC 1583                     OSPF Version 2                   March 1994


5.  Protocol Data Structures

    The OSPF protocol is described in this specification in terms of its
    operation on various protocol data structures.  The following list
    comprises the top-level OSPF data structures.  Any initialization
    that needs to be done is noted.  OSPF areas, interfaces and
    neighbors also have associated data structures that are described
    later in this specification.


    Router ID
        A 32-bit number that uniquely identifies this router in the AS.
        One possible implementation strategy would be to use the
        smallest IP interface address belonging to the router. If a
        router's OSPF Router ID is changed, the router's OSPF software
        should be restarted before the new Router ID takes effect.
        Before restarting in order to change its Router ID, the router
        should flush its self-originated link state advertisements from
        the routing domain (see Section 14.1), or they will persist for
        up to MaxAge minutes.

    Area structures
        Each one of the areas to which the router is connected has its
        own data structure.  This data structure describes the working
        of the basic algorithm.  Remember that each area runs a separate
        copy of the basic algorithm.

    Backbone (area) structure
        The basic algorithm operates on the backbone as if it were an
        area.  For this reason the backbone is represented as an area
        structure.

    Virtual links configured
        The virtual links configured with this router as one endpoint.
        In order to have configured virtual links, the router itself
        must be an area border router.  Virtual links are identified by
        the Router ID of the other endpoint -- which is another area
        border router.  These two endpoint routers must be attached to a
        common area, called the virtual link's Transit area.  Virtual
        links are part of the backbone, and behave as if they were
        unnumbered point-to-point networks between the two routers.  A
        virtual link uses the intra-area routing of its Transit area to
        forward packets.  Virtual links are brought up and down through
        the building of the shortest-path trees for the Transit area.

    List of external routes
        These are routes to destinations external to the Autonomous
        System, that have been gained either through direct experience



Moy                                                            [Page 41]


RFC 1583                     OSPF Version 2                   March 1994


        with another routing protocol (such as EGP), or through
        configuration information, or through a combination of the two
        (e.g., dynamic external information to be advertised by OSPF
        with configured metric). Any router having these external routes
        is called an AS boundary router.  These routes are advertised by
        the router into the OSPF routing domain via AS external link
        advertisements.

    List of AS external link advertisements
        Part of the topological database.  These have originated from
        the AS boundary routers.  They comprise routes to destinations
        external to the Autonomous System.  Note that, if the router is
        itself an AS boundary router, some of these AS external link
        advertisements have been self-originated.

    The routing table
        Derived from the topological database.  Each destination that
        the router can forward to is represented by a cost and a set of
        paths.  A path is described by its type and next hop.  For more
        information, see Section 11.

    TOS capability
        This item indicates whether the router will calculate separate
        routes based on TOS.  This is a configurable parameter.  For
        more information, see Sections 4.5 and 16.9.


    Figure 9 shows the collection of data structures present in a
    typical router.  The router pictured is RT10, from the map in Figure
    6.  Note that Router RT10 has a virtual link configured to Router
    RT11, with Area 2 as the link's Transit area.  This is indicated by
    the dashed line in Figure 9.  When the virtual link becomes active,
    through the building of the shortest path tree for Area 2, it
    becomes an interface to the backbone (see the two backbone
    interfaces depicted in Figure 9).

6.  The Area Data Structure

    The area data structure contains all the information used to run the
    basic routing algorithm. Each area maintains its own topological
    database. A network belongs to a single area, and a router interface
    connects to a single area. Each router adjacency also belongs to a
    single area.

    The OSPF backbone has all the properties of an area.  For that
    reason it is also represented by an area data structure.  Note that
    some items in the structure apply differently to the backbone than
    to non-backbone areas.



Moy                                                            [Page 42]


RFC 1583                     OSPF Version 2                   March 1994





                              +----+
                              |RT10|------+
                              +----+       \+-------------+
                             /      \       |Routing Table|
                            /        \      +-------------+
                           /          \
              +------+    /            \    +--------+
              |Area 2|---+              +---|Backbone|
              +------+***********+          +--------+
             /        \           *        /          \
            /          \           *      /            \
       +---------+  +---------+    +------------+       +------------+
       |Interface|  |Interface|    |Virtual Link|       |Interface Ib|
       |  to N6  |  |  to N8  |    |   to RT11  |       +------------+
       +---------+  +---------+    +------------+             |
           /  \           |               |                   |
          /    \          |               |                   |
   +--------+ +--------+  |        +-------------+      +------------+
   |Neighbor| |Neighbor|  |        |Neighbor RT11|      |Neighbor RT6|
   |  RT8   | |  RT7   |  |        +-------------+      +------------+
   +--------+ +--------+  |
                          |
                     +-------------+
                     |Neighbor RT11|
                     +-------------+


                Figure 9: Router RT10's Data structures

    The area topological (or link state) database consists of the
    collection of router links, network links and summary link
    advertisements that have originated from the area's routers.  This
    information is flooded throughout a single area only.  The list of
    AS external link advertisements (see Section 5) is also considered
    to be part of each area's topological database.


    Area ID
        A 32-bit number identifying the area.  0.0.0.0 is reserved for
        the Area ID of the backbone.  If assigning subnetted networks as
        separate areas, the IP network number could be used as the Area
        ID.

    List of component address ranges
        The address ranges that define the area.  Each address range is



Moy                                                            [Page 43]


RFC 1583                     OSPF Version 2                   March 1994


        specified by an [address,mask] pair and a status indication of
        either Advertise or DoNotAdvertise (see Section 12.4.3). Each
        network is then assigned to an area depending on the address
        range that it falls into (specified address ranges are not
        allowed to overlap).  As an example, if an IP subnetted network
        is to be its own separate OSPF area, the area is defined to
        consist of a single address range - an IP network number with
        its natural (class A, B or C) mask.

    Associated router interfaces
        This router's interfaces connecting to the area.  A router
        interface belongs to one and only one area (or the backbone).
        For the backbone structure this list includes all the virtual
        links.  A virtual link is identified by the Router ID of its
        other endpoint; its cost is the cost of the shortest intra-area
        path through the Transit area that exists between the two
        routers.

    List of router links advertisements
        A router links advertisement is generated by each router in the
        area.  It describes the state of the router's interfaces to the
        area.

    List of network links advertisements
        One network links advertisement is generated for each transit
        multi-access network in the area.  A network links advertisement
        describes the set of routers currently connected to the network.

    List of summary link advertisements
        Summary link advertisements originate from the area's area
        border routers.  They describe routes to destinations internal
        to the Autonomous System, yet external to the area.

    Shortest-path tree
        The shortest-path tree for the area, with this router itself as
        root.  Derived from the collected router links and network links
        advertisements by the Dijkstra algorithm (see Section 16.1).

    AuType
        The type of authentication used for this area.  Authentication
        types are defined in Appendix D.  All OSPF packet exchanges are
        authenticated.  Different authentication schemes may be used in
        different areas.

    TransitCapability
        Set to TRUE if and only if there are one or more active virtual
        links using the area as a Transit area. Equivalently, this
        parameter indicates whether the area can carry data traffic that



Moy                                                            [Page 44]


RFC 1583                     OSPF Version 2                   March 1994


        neither originates nor terminates in the area itself. This
        parameter is calculated when the area's shortest-path tree is
        built (see Section 16.1, and is used as an input to a subsequent
        step of the routing table build process (see Section 16.3).

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

    StubDefaultCost
        If the area has been configured as a stub area, and the router
        itself is an area border router, then the StubDefaultCost
        indicates the cost of the default summary link that the router
        should advertise into the area.  There can be a separate cost
        configured for each IP TOS.  See Section 12.4.3 for more
        information.


    Unless otherwise specified, the remaining sections of this document
    refer to the operation of the protocol in a single area.


7.  Bringing Up Adjacencies

    OSPF creates adjacencies between neighboring routers for the purpose
    of exchanging routing information.  Not every two neighboring
    routers will become adjacent.  This section covers the generalities
    involved in creating adjacencies.  For further details consult
    Section 10.


    7.1.  The Hello Protocol

        The Hello Protocol is responsible for establishing and
        maintaining neighbor relationships.  It also ensures that
        communication between neighbors is bidirectional.  Hello packets
        are sent periodically out all router interfaces.  Bidirectional
        communication is indicated when the router sees itself listed in
        the neighbor's Hello Packet.

        On multi-access networks, the Hello Protocol elects a Designated
        Router for the network.  Among other things, the Designated



Moy                                                            [Page 45]


RFC 1583                     OSPF Version 2                   March 1994


        Router controls what adjacencies will be formed over the network
        (see below).

        The Hello Protocol works differently on broadcast networks, as
        compared to non-broadcast networks.  On broadcast networks, each
        router advertises itself by periodically multicasting Hello
        Packets.  This allows neighbors to be discovered dynamically.
        These Hello Packets contain the router's view of the Designated
        Router's identity, and the list of routers whose Hello Packets
        have been seen recently.

        On non-broadcast networks some configuration information is
        necessary for the operation of the Hello Protocol.  Each router
        that may potentially become Designated Router has a list of all
        other routers attached to the network.  A router, having
        Designated Router potential, sends Hello Packets to all other
        potential Designated Routers when its interface to the non-
        broadcast network first becomes operational.  This is an attempt
        to find the Designated Router for the network.  If the router
        itself is elected Designated Router, it begins sending Hello
        Packets to all other routers attached to the network.

        After a neighbor has been discovered, bidirectional
        communication ensured, and (if on a multi-access network) a
        Designated Router elected, a decision is made regarding whether
        or not an adjacency should be formed with the neighbor (see
        Section 10.4).  An attempt is always made to establish
        adjacencies over point-to-point networks and virtual links.  The
        first step in bringing up an adjacency is to synchronize the
        neighbors' topological databases.  This is covered in the next
        section.


    7.2.  The Synchronization of Databases

        In a link-state routing algorithm, it is very important for all
        routers' topological databases to stay synchronized.  OSPF
        simplifies this by requiring only adjacent routers to remain
        synchronized.  The synchronization process begins as soon as the
        routers attempt to bring up the adjacency.  Each router
        describes its database by sending a sequence of Database
        Description packets to its neighbor.  Each Database Description
        Packet describes a set of link state advertisements belonging to
        the router's database.  When the neighbor sees a link state
        advertisement that is more recent than its own database copy, it
        makes a note that this newer advertisement should be requested.

        This sending and receiving of Database Description packets is



Moy                                                            [Page 46]


RFC 1583                     OSPF Version 2                   March 1994


        called the "Database Exchange Process".  During this process,
        the two routers form a master/slave relationship.  Each Database
        Description Packet has a sequence number.  Database Description
        Packets sent by the master (polls) are acknowledged by the slave
        through echoing of the sequence number.  Both polls and their
        responses contain summaries of link state data.  The master is
        the only one allowed to retransmit Database Description Packets.
        It does so only at fixed intervals, the length of which is the
        configured constant RxmtInterval.

        Each Database Description contains an indication that there are
        more packets to follow --- the M-bit.  The Database Exchange
        Process is over when a router has received and sent Database
        Description Packets with the M-bit off.

        During and after the Database Exchange Process, each router has
        a list of those link state advertisements for which the neighbor
        has more up-to-date instances.  These advertisements are
        requested in Link State Request Packets.  Link State Request
        packets that are not satisfied are retransmitted at fixed
        intervals of time RxmtInterval.  When the Database Description
        Process has completed and all Link State Requests have been
        satisfied, the databases are deemed synchronized and the routers
        are marked fully adjacent.  At this time the adjacency is fully
        functional and is advertised in the two routers' link state
        advertisements.

        The adjacency is used by the flooding procedure as soon as the
        Database Exchange Process begins.  This simplifies database
        synchronization, and guarantees that it finishes in a
        predictable period of time.


    7.3.  The Designated Router

        Every multi-access network has a Designated Router.  The
        Designated Router performs two main functions for the routing
        protocol:

        o   The Designated Router originates a network links
            advertisement on behalf of the network.  This advertisement
            lists the set of routers (including the Designated Router
            itself) currently attached to the network.  The Link State
            ID for this advertisement (see Section 12.1.4) is the IP
            interface address of the Designated Router.  The IP network
            number can then be obtained by using the subnet/network
            mask.




Moy                                                            [Page 47]


RFC 1583                     OSPF Version 2                   March 1994


        o   The Designated Router becomes adjacent to all other routers
            on the network.  Since the link state databases are
            synchronized across adjacencies (through adjacency bring-up
            and then the flooding procedure), the Designated Router
            plays a central part in the synchronization process.


        The Designated Router is elected by the Hello Protocol.  A
        router's Hello Packet contains its Router Priority, which is
        configurable on a per-interface basis.  In general, when a
        router's interface to a network first becomes functional, it
        checks to see whether there is currently a Designated Router for
        the network.  If there is, it accepts that Designated Router,
        regardless of its Router Priority.  (This makes it harder to
        predict the identity of the Designated Router, but ensures that
        the Designated Router changes less often.  See below.)
        Otherwise, the router itself becomes Designated Router if it has
        the highest Router Priority on the network.  A more detailed
        (and more accurate) description of Designated Router election is
        presented in Section 9.4.

        The Designated Router is the endpoint of many adjacencies.  In
        order to optimize the flooding procedure on broadcast networks,
        the Designated Router multicasts its Link State Update Packets
        to the address AllSPFRouters, rather than sending separate
        packets over each adjacency.

        Section 2 of this document discusses the directed graph
        representation of an area.  Router nodes are labelled with their
        Router ID.  Multi-access network nodes are actually labelled
        with the IP address of their Designated Router.  It follows that
        when the Designated Router changes, it appears as if the network
        node on the graph is replaced by an entirely new node.  This
        will cause the network and all its attached routers to originate
        new link state advertisements.  Until the topological databases
        again converge, some temporary loss of connectivity may result.
        This may result in ICMP unreachable messages being sent in
        response to data traffic.  For that reason, the Designated
        Router should change only infrequently.  Router Priorities
        should be configured so that the most dependable router on a
        network eventually becomes Designated Router.


    7.4.  The Backup Designated Router

        In order to make the transition to a new Designated Router
        smoother, there is a Backup Designated Router for each multi-
        access network.  The Backup Designated Router is also adjacent



Moy                                                            [Page 48]


RFC 1583                     OSPF Version 2                   March 1994


        to all routers on the network, and becomes Designated Router
        when the previous Designated Router fails.  If there were no
        Backup Designated Router, when a new Designated Router became
        necessary, new adjacencies would have to be formed between the
        new Designated Router and all other routers attached to the
        network.  Part of the adjacency forming process is the
        synchronizing of topological databases, which can potentially
        take quite a long time.  During this time, the network would not
        be available for transit data traffic.  The Backup Designated
        obviates the need to form these adjacencies, since they already
        exist.  This means the period of disruption in transit traffic
        lasts only as long as it takes to flood the new link state
        advertisements (which announce the new Designated Router).

        The Backup Designated Router does not generate a network links
        advertisement for the network.  (If it did, the transition to a
        new Designated Router would be even faster.  However, this is a
        tradeoff between database size and speed of convergence when the
        Designated Router disappears.)

        The Backup Designated Router is also elected by the Hello
        Protocol.  Each Hello Packet has a field that specifies the
        Backup Designated Router for the network.

        In some steps of the flooding procedure, the Backup Designated
        Router plays a passive role, letting the Designated Router do
        more of the work.  This cuts down on the amount of local routing
        traffic.  See Section 13.3 for more information.


    7.5.  The graph of adjacencies

        An adjacency is bound to the network that the two routers have
        in common.  If two routers have multiple networks in common,
        they may have multiple adjacencies between them.

        One can picture the collection of adjacencies on a network as
        forming an undirected graph.  The vertices consist of routers,
        with an edge joining two routers if they are adjacent.  The
        graph of adjacencies describes the flow of routing protocol
        packets, and in particular Link State Update Packets, through
        the Autonomous System.

        Two graphs are possible, depending on whether the common network
        is multi-access.  On physical point-to-point networks (and
        virtual links), the two routers joined by the network will be
        adjacent after their databases have been synchronized.  On
        multi-access networks, both the Designated Router and the Backup



Moy                                                            [Page 49]


RFC 1583                     OSPF Version 2                   March 1994


        Designated Router are adjacent to all other routers attached to
        the network, and these account for all adjacencies.

        These graphs are shown in Figure 10.  It is assumed that Router
        RT7 has become the Designated Router, and Router RT3 the Backup
        Designated Router, for the Network N2.  The Backup Designated
        Router performs a lesser function during the flooding procedure
        than the Designated Router (see Section 13.3).  This is the
        reason for the dashed lines connecting the Backup Designated
        Router RT3.


8.  Protocol Packet Processing

    This section discusses the general processing of OSPF routing
    protocol packets.  It is very important that the router topological
    databases remain synchronized.  For this reason, routing protocol
    packets should get preferential treatment over ordinary data
    packets, both in sending and receiving.

    Routing protocol packets are sent along adjacencies only (with the



          +---+            +---+
          |RT1|------------|RT2|            o---------------o
          +---+    N1      +---+           RT1             RT2



                                                 RT7
                                                  o---------+
            +---+   +---+   +---+                /|\        |
            |RT7|   |RT3|   |RT4|               / | \       |
            +---+   +---+   +---+              /  |  \      |
              |       |       |               /   |   \     |
         +-----------------------+        RT5o RT6o    oRT4 |
                  |       |     N2            *   *   *     |
                +---+   +---+                  *  *  *      |
                |RT5|   |RT6|                   * * *       |
                +---+   +---+                    ***        |
                                                  o---------+
                                                 RT3


                  Figure 10: The graph of adjacencies





Moy                                                            [Page 50]


RFC 1583                     OSPF Version 2                   March 1994


    exception of Hello packets, which are used to discover the
    adjacencies).  This means that all routing protocol packets travel a
    single IP hop, except those sent over virtual links.

    All routing protocol packets begin with a standard header.  The
    sections below give the details on how to fill in and verify this
    standard header.  Then, for each packet type, the section is listed
    that gives more details on that particular packet type's processing.

    8.1.  Sending protocol packets

        When a router sends a routing protocol packet, it fills in the
        fields of the standard OSPF packet header as follows.  For more
        details on the header format consult Section A.3.1:


        Version #
            Set to 2, the version number of the protocol as documented
            in this specification.

        Packet type
            The type of OSPF packet, such as Link state Update or Hello
            Packet.

        Packet length
            The length of the entire OSPF packet in bytes, including the
            standard OSPF packet header.

        Router ID
            The identity of the router itself (who is originating the
            packet).

        Area ID
            The OSPF area that the packet is being sent into.

        Checksum
            The standard IP 16-bit one's complement checksum of the
            entire OSPF packet, excluding the 64-bit authentication
            field.  This checksum should be calculated before handing
            the packet to the appropriate authentication procedure.

        AuType and Authentication
            Each OSPF packet exchange is authenticated.  Authentication
            types are assigned by the protocol and documented in
            Appendix D.  A different authentication scheme can be used
            for each OSPF area.  The 64-bit authentication field is set
            by the appropriate authentication procedure (determined by
            AuType).  This procedure should be the last called when



Moy                                                            [Page 51]


RFC 1583                     OSPF Version 2                   March 1994


            forming the packet to be sent.  The setting of the
            authentication field is determined by the packet contents
            and the authentication key (which is configurable on a per-
            interface basis).


        The IP destination address for the packet is selected as
        follows.  On physical point-to-point networks, the IP
        destination is always set to the address AllSPFRouters.  On all
        other network types (including virtual links), the majority of
        OSPF packets are sent as unicasts, i.e., sent directly to the
        other end of the adjacency.  In this case, the IP destination is
        just the Neighbor IP address associated with the other end of
        the adjacency (see Section 10).  The only packets not sent as
        unicasts are on broadcast networks; on these networks Hello
        packets are sent to the multicast destination AllSPFRouters, the
        Designated Router and its Backup send both Link State Update
        Packets and Link State Acknowledgment Packets to the multicast
        address AllSPFRouters, while all other routers send both their
        Link State Update and Link State Acknowledgment Packets to the
        multicast address AllDRouters.

        Retransmissions of Link State Update packets are ALWAYS sent as
        unicasts.

        The IP source address should be set to the IP address of the
        sending interface.  Interfaces to unnumbered point-to-point
        networks have no associated IP address.  On these interfaces,
        the IP source should be set to any of the other IP addresses
        belonging to the router.  For this reason, there must be at
        least one IP address assigned to the router.[2] Note that, for
        most purposes, virtual links act precisely the same as
        unnumbered point-to-point networks.  However, each virtual link
        does have an IP interface address (discovered during the routing
        table build process) which is used as the IP source when sending
        packets over the virtual link.

        For more information on the format of specific OSPF packet
        types, consult the sections listed in Table 10.












Moy                                                            [Page 52]


RFC 1583                     OSPF Version 2                   March 1994



             Type   Packet name            detailed section (transmit)
             _________________________________________________________
             1      Hello                  Section  9.5
             2      Database description   Section 10.8
             3      Link state request     Section 10.9
             4      Link state update      Section 13.3
             5      Link state ack         Section 13.5


            Table 10: Sections describing OSPF protocol packet transmission.



    8.2.  Receiving protocol packets

        Whenever a protocol packet is received by the router it is
        marked with the interface it was received on.  For routers that
        have virtual links configured, it may not be immediately obvious
        which interface to associate the packet with.  For example,
        consider the Router RT11 depicted in Figure 6.  If RT11 receives
        an OSPF protocol packet on its interface to Network N8, it may
        want to associate the packet with the interface to Area 2, or
        with the virtual link to Router RT10 (which is part of the
        backbone).  In the following, we assume that the packet is
        initially associated with the non-virtual  link.[3]

        In order for the packet to be accepted at the IP level, it must
        pass a number of tests, even before the packet is passed to OSPF
        for processing:


        o   The IP checksum must be correct.

        o   The packet's IP destination address must be the IP address
            of the receiving interface, or one of the IP multicast
            addresses AllSPFRouters or AllDRouters.

        o   The IP protocol specified must be OSPF (89).

        o   Locally originated packets should not be passed on to OSPF.
            That is, the source IP address should be examined to make
            sure this is not a multicast packet that the router itself
            generated.


        Next, the OSPF packet header is verified.  The fields specified
        in the header must match those configured for the receiving



Moy                                                            [Page 53]


RFC 1583                     OSPF Version 2                   March 1994


        interface.  If they do not, the packet should be discarded:


        o   The version number field must specify protocol version 2.

        o   The 16-bit one's complement checksum of the OSPF packet's
            contents must be verified.  Remember that the 64-bit
            authentication field must be excluded from the checksum
            calculation.

        o   The Area ID found in the OSPF header must be verified.  If
            both of the following cases fail, the packet should be
            discarded.  The Area ID specified in the header must either:

            (1) Match the Area ID of the receiving interface.  In this
                case, the packet has been sent over a single hop.
                Therefore, the packet's IP source address must be on the
                same network as the receiving interface.  This can be
                determined by comparing the packet's IP source address
                to the interface's IP address, after masking both
                addresses with the interface mask.  This comparison
                should not be performed on point-to-point networks. On
                point-to-point networks, the interface addresses of each
                end of the link are assigned independently, if they are
                assigned at all.

            (2) Indicate the backbone.  In this case, the packet has
                been sent over a virtual link.  The receiving router
                must be an area border router, and the Router ID
                specified in the packet (the source router) must be the
                other end of a configured virtual link.  The receiving
                interface must also attach to the virtual link's
                configured Transit area.  If all of these checks
                succeed, the packet is accepted and is from now on
                associated with the virtual link (and the backbone
                area).

        o   Packets whose IP destination is AllDRouters should only be
            accepted if the state of the receiving interface is DR or
            Backup (see Section 9.1).

        o   The AuType specified in the packet must match the AuType
            specified for the associated area.


        Next, the packet must be authenticated.  This depends on the
        AuType specified (see Appendix D).  The authentication procedure
        may use an Authentication key, which can be configured on a



Moy                                                            [Page 54]


RFC 1583                     OSPF Version 2                   March 1994


        per-interface basis.  If the authentication fails, the packet
        should be discarded.

        If the packet type is Hello, it should then be further processed
        by the Hello Protocol (see Section 10.5).  All other packet
        types are sent/received only on adjacencies.  This means that
        the packet must have been sent by one of the router's active
        neighbors.  If the receiving interface is a multi-access network
        (either broadcast or non-broadcast) the sender is identified by
        the IP source address found in the packet's IP header.  If the
        receiving interface is a point-to-point link or a virtual link,
        the sender is identified by the Router ID (source router) found
        in the packet's OSPF header.  The data structure associated with
        the receiving interface contains the list of active neighbors.
        Packets not matching any active neighbor are discarded.

        At this point all received protocol packets are associated with
        an active neighbor.  For the further input processing of
        specific packet types, consult the sections listed in Table 11.



              Type   Packet name            detailed section (receive)
              ________________________________________________________
              1      Hello                  Section 10.5
              2      Database description   Section 10.6
              3      Link state request     Section 10.7
              4      Link state update      Section 13
              5      Link state ack         Section 13.7


            Table 11: Sections describing OSPF protocol packet reception.



9.  The Interface Data Structure

    An OSPF interface is the connection between a router and a network.
    There is a single OSPF interface structure for each attached
    network; each interface structure has at most one IP interface
    address (see below).  The support for multiple addresses on a single
    network is a matter for future consideration.

    An OSPF interface can be considered to belong to the area that
    contains the attached network.  All routing protocol packets
    originated by the router over this interface are labelled with the
    interface's Area ID.  One or more router adjacencies may develop
    over an interface.  A router's link state advertisements reflect the



Moy                                                            [Page 55]


RFC 1583                     OSPF Version 2                   March 1994


    state of its interfaces and their associated adjacencies.

    The following data items are associated with an interface.  Note
    that a number of these items are actually configuration for the
    attached network; those items must be the same for all routers
    connected to the network.


    Type
        The kind of network to which the interface attaches.  Its value
        is either broadcast, non-broadcast yet still multi-access,
        point-to-point or virtual link.

    State
        The functional level of an interface.  State determines whether
        or not full adjacencies are allowed to form over the interface.
        State is also reflected in the router's link state
        advertisements.

    IP interface address
        The IP address associated with the interface.  This appears as
        the IP source address in all routing protocol packets originated
        over this interface.  Interfaces to unnumbered point-to-point
        networks do not have an associated IP address.

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

    Area ID
        The Area ID of the area to which the attached network belongs.
        All routing protocol packets originating from the interface are
        labelled with this Area ID.

    HelloInterval
        The length of time, in seconds, between the Hello packets that
        the router sends on the interface.  Advertised in Hello packets
        sent out this interface.

    RouterDeadInterval
        The number of seconds before the router's neighbors will declare



Moy                                                            [Page 56]


RFC 1583                     OSPF Version 2                   March 1994


        it down, when they stop hearing the router's Hello Packets.
        Advertised in Hello packets sent out this interface.

    InfTransDelay
        The estimated number of seconds it takes to transmit a Link
        State Update Packet over this interface.  Link state
        advertisements contained in the Link State Update packet will
        have their age incremented by this amount before transmission.
        This value should take into account transmission and propagation
        delays; it must be greater than zero.

    Router Priority
        An 8-bit unsigned integer.  When two routers attached to a
        network both attempt to become Designated Router, the one with
        the highest Router Priority takes precedence.  A router whose
        Router Priority is set to 0 is ineligible to become Designated
        Router on the attached network.  Advertised in Hello packets
        sent out this interface.

    Hello Timer
        An interval timer that causes the interface to send a Hello
        packet.  This timer fires every HelloInterval seconds.  Note
        that on non-broadcast networks a separate Hello packet is sent
        to each qualified neighbor.

    Wait Timer
        A single shot timer that causes the interface to exit the
        Waiting state, and as a consequence select a Designated Router
        on the network.  The length of the timer is RouterDeadInterval
        seconds.

    List of neighboring routers
        The other routers attached to this network.  On multi-access
        networks, this list is formed by the Hello Protocol.
        Adjacencies will be formed to some of these neighbors.  The set
        of adjacent neighbors can be determined by an examination of all
        of the neighbors' states.

    Designated Router
        The Designated Router selected for the attached network.  The
        Designated Router is selected on all multi-access networks by
        the Hello Protocol.  Two pieces of identification are kept for
        the Designated Router: its Router ID and its IP interface
        address on the network.  The Designated Router advertises link
        state for the network; this network link state advertisement is
        labelled with the Designated Router's IP address.  The
        Designated Router is initialized to 0.0.0.0, which indicates the
        lack of a Designated Router.



Moy                                                            [Page 57]


RFC 1583                     OSPF Version 2                   March 1994


    Backup Designated Router
        The Backup Designated Router is also selected on all multi-
        access networks by the Hello Protocol.  All routers on the
        attached network become adjacent to both the Designated Router
        and the Backup Designated Router.  The Backup Designated Router
        becomes Designated Router when the current Designated Router
        fails.  The Backup Designated Router is initialized to 0.0.0.0,
        indicating the lack of a Backup Designated Router.

    Interface output cost(s)
        The cost of sending a data packet on the interface, expressed in
        the link state metric.  This is advertised as the link cost for
        this interface in the router links advertisement.  There may be
        a separate cost for each IP Type of Service.  The cost of an
        interface must be greater than zero.

    RxmtInterval
        The number of seconds between link state advertisement
        retransmissions, for adjacencies belonging to this interface.
        Also used when retransmitting Database Description and Link
        State Request Packets.

    Authentication key
        This configured data allows the authentication procedure to
        generate and/or verify the Authentication field in the OSPF
        header.  The Authentication key can be configured on a per-
        interface basis.  For example, if the AuType indicates simple
        password, the Authentication key would be a 64-bit password.
        This key would be inserted directly into the OSPF header when
        originating routing protocol packets, and there could be a
        separate password for each network.


    9.1.  Interface states

        The various states that router interfaces may attain is
        documented in this section.  The states are listed in order of
        progressing functionality.  For example, the inoperative state
        is listed first, followed by a list of intermediate states
        before the final, fully functional state is achieved.  The
        specification makes use of this ordering by sometimes making
        references such as "those interfaces in state greater than X".
        Figure 11 shows the graph of interface state changes.  The arcs
        of the graph are labelled with the event causing the state
        change.  These events are documented in Section 9.2.  The
        interface state machine is described in more detail in Section
        9.3.




Moy                                                            [Page 58]


RFC 1583                     OSPF Version 2                   March 1994



                                  +----+   UnloopInd   +--------+
                                  |Down|<--------------|Loopback|
                                  +----+               +--------+
                                     |
                                     |InterfaceUp
                          +-------+  |               +--------------+
                          |Waiting|<-+-------------->|Point-to-point|
                          +-------+                  +--------------+
                              |
                     WaitTimer|BackupSeen
                              |
                              |
                              |   NeighborChange
          +------+           +-+<---------------- +-------+
          |Backup|<----------|?|----------------->|DROther|
          +------+---------->+-+<-----+           +-------+
                    Neighbor  |       |
                    Change    |       |Neighbor
                              |       |Change
                              |     +--+
                              +---->|DR|
                                    +--+

                      Figure 11: Interface State changes

                 In addition to the state transitions pictured,
                 Event InterfaceDown always forces Down State, and
                 Event LoopInd always forces Loopback State


        Down
            This is the initial interface state.  In this state, the
            lower-level protocols have indicated that the interface is
            unusable.  No protocol traffic at all will be sent or
            received on such a interface.  In this state, interface
            parameters should be set to their initial values.  All
            interface timers should be disabled, and there should be no
            adjacencies associated with the interface.

        Loopback
            In this state, the router's interface to the network is
            looped back.  The interface may be looped back in hardware
            or software.  The interface will be unavailable for regular
            data traffic.  However, it may still be desirable to gain
            information on the quality of this interface, either through
            sending ICMP pings to the interface or through something
            like a bit error test.  For this reason, IP packets may



Moy                                                            [Page 59]


RFC 1583                     OSPF Version 2                   March 1994


            still be addressed to an interface in Loopback state.  To
            facilitate this, such interfaces are advertised in router
            links advertisements as single host routes, whose
            destination is the IP interface address.[4]

        Waiting
            In this state, the router is trying to determine the
            identity of the (Backup) Designated Router for the network.
            To do this, the router monitors the Hello Packets it
            receives.  The router is not allowed to elect a Backup
            Designated Router nor a Designated Router until it
            transitions out of Waiting state.  This prevents unnecessary
            changes of (Backup) Designated Router.

        Point-to-point
            In this state, the interface is operational, and connects
            either to a physical point-to-point network or to a virtual
            link.  Upon entering this state, the router attempts to form
            an adjacency with the neighboring router.  Hello Packets are
            sent to the neighbor every HelloInterval seconds.

        DR Other
            The interface is to a multi-access network on which another
            router has been selected to be the Designated Router.  In
            this state, the router itself has not been selected Backup
            Designated Router either.  The router forms adjacencies to
            both the Designated Router and the Backup Designated Router
            (if they exist).

        Backup
            In this state, the router itself is the Backup Designated
            Router on the attached network.  It will be promoted to
            Designated Router when the present Designated Router fails.
            The router establishes adjacencies to all other routers
            attached to the network.  The Backup Designated Router
            performs slightly different functions during the Flooding
            Procedure, as compared to the Designated Router (see Section
            13.3).  See Section 7.4 for more details on the functions
            performed by the Backup Designated Router.

        DR  In this state, this router itself is the Designated Router
            on the attached network.  Adjacencies are established to all
            other routers attached to the network.  The router must also
            originate a network links advertisement for the network
            node.  The advertisement will contain links to all routers
            (including the Designated Router itself) attached to the
            network.  See Section 7.3 for more details on the functions
            performed by the Designated Router.



Moy                                                            [Page 60]


RFC 1583                     OSPF Version 2                   March 1994


    9.2.  Events causing interface state changes

        State changes can be effected by a number of events.  These
        events are pictured as the labelled arcs in Figure 11.  The
        label definitions are listed below.  For a detailed explanation
        of the effect of these events on OSPF protocol operation,
        consult Section 9.3.


        InterfaceUp
            Lower-level protocols have indicated that the network
            interface is operational.  This enables the interface to
            transition out of Down state.  On virtual links, the
            interface operational indication is actually a result of the
            shortest path calculation (see Section 16.7).

        WaitTimer
            The Wait Timer has fired, indicating the end of the waiting
            period that is required before electing a (Backup)
            Designated Router.

        BackupSeen
            The router has detected the existence or non-existence of a
            Backup Designated Router for the network.  This is done in
            one of two ways.  First, an Hello Packet may be received
            from a neighbor claiming to be itself the Backup Designated
            Router.  Alternatively, an Hello Packet may be received from
            a neighbor claiming to be itself the Designated Router, and
            indicating that there is no Backup Designated Router.  In
            either case there must be bidirectional communication with
            the neighbor, i.e., the router must also appear in the
            neighbor's Hello Packet.  This event signals an end to the
            Waiting state.

        NeighborChange
            There has been a change in the set of bidirectional
            neighbors associated with the interface.  The (Backup)
            Designated Router needs to be recalculated.  The following
            neighbor changes lead to the NeighborChange event.  For an
            explanation of neighbor states, see Section 10.1.

            o   Bidirectional communication has been established to a
                neighbor.  In other words, the state of the neighbor has
                transitioned to 2-Way or higher.

            o   There is no longer bidirectional communication with a
                neighbor.  In other words, the state of the neighbor has
                transitioned to Init or lower.



Moy                                                            [Page 61]


RFC 1583                     OSPF Version 2                   March 1994


            o   One of the bidirectional neighbors is newly declaring
                itself as either Designated Router or Backup Designated
                Router.  This is detected through examination of that
                neighbor's Hello Packets.

            o   One of the bidirectional neighbors is no longer
                declaring itself as Designated Router, or is no longer
                declaring itself as Backup Designated Router.  This is
                again detected through examination of that neighbor's
                Hello Packets.

            o   The advertised Router Priority for a bidirectional
                neighbor has changed.  This is again detected through
                examination of that neighbor's Hello Packets.

        LoopInd
            An indication has been received that the interface is now
            looped back to itself.  This indication can be received
            either from network management or from the lower level
            protocols.

        UnloopInd
            An indication has been received that the interface is no
            longer looped back.  As with the LoopInd event, this
            indication can be received either from network management or
            from the lower level protocols.

        InterfaceDown
            Lower-level protocols indicate that this interface is no
            longer functional.  No matter what the current interface
            state is, the new interface state will be Down.


    9.3.  The Interface state machine

        A detailed description of the interface state changes follows.
        Each state change is invoked by an event (Section 9.2).  This
        event may produce different effects, depending on the current
        state of the interface.  For this reason, the state machine
        below is organized by current interface state and received
        event.  Each entry in the state machine describes the resulting
        new interface state and the required set of additional actions.

        When an interface's state changes, it may be necessary to
        originate a new router links advertisement.  See Section 12.4
        for more details.

        Some of the required actions below involve generating events for



Moy                                                            [Page 62]


RFC 1583                     OSPF Version 2                   March 1994


        the neighbor state machine.  For example, when an interface
        becomes inoperative, all neighbor connections associated with
        the interface must be destroyed.  For more information on the
        neighbor state machine, see Section 10.3.


         State(s):  Down

            Event:  InterfaceUp

        New state:  Depends upon action routine

           Action:  Start the interval Hello Timer, enabling the
                    periodic sending of Hello packets out the interface.
                    If the attached network is a physical point-to-point
                    network or virtual link, the interface state
                    transitions to Point-to-Point.  Else, if the router
                    is not eligible to become Designated Router the
                    interface state transitions to DR Other.

                    Otherwise, the attached network is multi-access and
                    the router is eligible to become Designated Router.
                    In this case, in an attempt to discover the attached
                    network's Designated Router the interface state is
                    set to Waiting and the single shot Wait Timer is
                    started.  If in addition the attached network is
                    non-broadcast, examine the configured list of
                    neighbors for this interface and generate the
                    neighbor event Start for each neighbor that is also
                    eligible to become Designated Router.


         State(s):  Waiting

            Event:  BackupSeen

        New state:  Depends upon action routine.

           Action:  Calculate the attached network's Backup Designated
                    Router and Designated Router, as shown in Section
                    9.4.  As a result of this calculation, the new state
                    of the interface will be either DR Other, Backup or
                    DR.


         State(s):  Waiting





Moy                                                            [Page 63]


RFC 1583                     OSPF Version 2                   March 1994


            Event:  WaitTimer

        New state:  Depends upon action routine.

           Action:  Calculate the attached network's Backup Designated
                    Router and Designated Router, as shown in Section
                    9.4.  As a result of this calculation, the new state
                    of the interface will be either DR Other, Backup or
                    DR.


         State(s):  DR Other, Backup or DR

            Event:  NeighborChange

        New state:  Depends upon action routine.

           Action:  Recalculate the attached network's Backup Designated
                    Router and Designated Router, as shown in Section
                    9.4.  As a result of this calculation, the new state
                    of the interface will be either DR Other, Backup or
                    DR.


         State(s):  Any State

            Event:  InterfaceDown

        New state:  Down

           Action:  All interface variables are reset, and interface
                    timers disabled.  Also, all neighbor connections
                    associated with the interface are destroyed.  This
                    is done by generating the event KillNbr on all
                    associated neighbors (see Section 10.2).


         State(s):  Any State

            Event:  LoopInd

        New state:  Loopback

           Action:  Since this interface is no longer connected to the
                    attached network the actions associated with the
                    above InterfaceDown event are executed.





Moy                                                            [Page 64]


RFC 1583                     OSPF Version 2                   March 1994


         State(s):  Loopback

            Event:  UnloopInd

        New state:  Down

           Action:  No actions are necessary.  For example, the
                    interface variables have already been reset upon
                    entering the Loopback state.  Note that reception of
                    an InterfaceUp event is necessary before the
                    interface again becomes fully functional.


    9.4.  Electing the Designated Router

        This section describes the algorithm used for calculating a
        network's Designated Router and Backup Designated Router.  This
        algorithm is invoked by the Interface state machine.  The
        initial time a router runs the election algorithm for a network,
        the network's Designated Router and Backup Designated Router are
        initialized to 0.0.0.0.  This indicates the lack of both a
        Designated Router and a Backup Designated Router.

        The Designated Router election algorithm proceeds as follows:
        Call the router doing the calculation Router X.  The list of
        neighbors attached to the network and having established
        bidirectional communication with Router X is examined.  This
        list is precisely the collection of Router X's neighbors (on
        this network) whose state is greater than or equal to 2-Way (see
        Section 10.1).  Router X itself is also considered to be on the
        list.  Discard all routers from the list that are ineligible to
        become Designated Router.  (Routers having Router Priority of 0
        are ineligible to become Designated Router.)  The following
        steps are then executed, considering only those routers that
        remain on the list:


        (1) Note the current values for the network's Designated Router
            and Backup Designated Router.  This is used later for
            comparison purposes.

        (2) Calculate the new Backup Designated Router for the network
            as follows.  Only those routers on the list that have not
            declared themselves to be Designated Router are eligible to
            become Backup Designated Router.  If one or more of these
            routers have declared themselves Backup Designated Router
            (i.e., they are currently listing themselves as Backup
            Designated Router, but not as Designated Router, in their



Moy                                                            [Page 65]


RFC 1583                     OSPF Version 2                   March 1994


            Hello Packets) the one having highest Router Priority is
            declared to be Backup Designated Router.  In case of a tie,
            the one having the highest Router ID is chosen.  If no
            routers have declared themselves Backup Designated Router,
            choose the router having highest Router Priority, (again
            excluding those routers who have declared themselves
            Designated Router), and again use the Router ID to break
            ties.

        (3) Calculate the new Designated Router for the network as
            follows.  If one or more of the routers have declared
            themselves Designated Router (i.e., they are currently
            listing themselves as Designated Router in their Hello
            Packets) the one having highest Router Priority is declared
            to be Designated Router.  In case of a tie, the one having
            the highest Router ID is chosen.  If no routers have
            declared themselves Designated Router, assign the Designated
            Router to be the same as the newly elected Backup Designated
            Router.

        (4) If Router X is now newly the Designated Router or newly the
            Backup Designated Router, or is now no longer the Designated
            Router or no longer the Backup Designated Router, repeat
            steps 2 and 3, and then proceed to step 5.  For example, if
            Router X is now the Designated Router, when step 2 is
            repeated X will no longer be eligible for Backup Designated
            Router election.  Among other things, this will ensure that
            no router will declare itself both Backup Designated Router
            and Designated Router.[5]

        (5) As a result of these calculations, the router itself may now
            be Designated Router or Backup Designated Router.  See
            Sections 7.3 and 7.4 for the additional duties this would
            entail.  The router's interface state should be set
            accordingly.  If the router itself is now Designated Router,
            the new interface state is DR.  If the router itself is now
            Backup Designated Router, the new interface state is Backup.
            Otherwise, the new interface state is DR Other.

        (6) If the attached network is non-broadcast, and the router
            itself has just become either Designated Router or Backup
            Designated Router, it must start sending Hello Packets to
            those neighbors that are not eligible to become Designated
            Router (see Section 9.5.1).  This is done by invoking the
            neighbor event Start for each neighbor having a Router
            Priority of 0.





Moy                                                            [Page 66]


RFC 1583                     OSPF Version 2                   March 1994


        (7) If the above calculations have caused the identity of either
            the Designated Router or Backup Designated Router to change,
            the set of adjacencies associated with this interface will
            need to be modified.  Some adjacencies may need to be
            formed, and others may need to be broken.  To accomplish
            this, invoke the event AdjOK?  on all neighbors whose state
            is at least 2-Way.  This will cause their eligibility for
            adjacency to be reexamined (see Sections 10.3 and 10.4).


        The reason behind the election algorithm's complexity is the
        desire for an orderly transition from Backup Designated Router
        to Designated Router, when the current Designated Router fails.
        This orderly transition is ensured through the introduction of
        hysteresis: no new Backup Designated Router can be chosen until
        the old Backup accepts its new Designated Router
        responsibilities.

        The above procedure may elect the same router to be both
        Designated Router and Backup Designated Router, although that
        router will never be the calculating router (Router X) itself.
        The elected Designated Router may not be the router having the
        highest Router Priority, nor will the Backup Designated Router
        necessarily have the second highest Router Priority.  If Router
        X is not itself eligible to become Designated Router, it is
        possible that neither a Backup Designated Router nor a
        Designated Router will be selected in the above procedure.  Note
        also that if Router X is the only attached router that is
        eligible to become Designated Router, it will select itself as
        Designated Router and there will be no Backup Designated Router
        for the network.


    9.5.  Sending Hello packets

        Hello packets are sent out each functioning router interface.
        They are used to discover and maintain neighbor
        relationships.[6] On multi-access networks, Hello Packets are
        also used to elect the Designated Router and Backup Designated
        Router, and in that way determine what adjacencies should be
        formed.

        The format of an Hello packet is detailed in Section A.3.2.  The
        Hello Packet contains the router's Router Priority (used in
        choosing the Designated Router), and the interval between Hello
        Packets sent out the interface (HelloInterval).  The Hello
        Packet also indicates how often a neighbor must be heard from to
        remain active (RouterDeadInterval).  Both HelloInterval and



Moy                                                            [Page 67]


RFC 1583                     OSPF Version 2                   March 1994


        RouterDeadInterval must be the same for all routers attached to
        a common network.  The Hello packet also contains the IP address
        mask of the attached network (Network Mask).  On unnumbered
        point-to-point networks and on virtual links this field should
        be set to 0.0.0.0.

        The Hello packet's Options field describes the router's optional
        OSPF capabilities.  There are currently two optional
        capabilities defined (see Sections 4.5 and A.2).  The T-bit of
        the Options field should be set if the router is capable of
        calculating separate routes for each IP TOS.  The E-bit should
        be set if and only if the attached area is capable of processing
        AS external advertisements (i.e., it is not a stub area).  If
        the E-bit is set incorrectly the neighboring routers will refuse
        to accept the Hello Packet (see Section 10.5).  The rest of the
        Hello Packet's Options field should be set to zero.

        In order to ensure two-way communication between adjacent
        routers, the Hello packet contains the list of all routers from
        which Hello Packets have been seen recently.  The Hello packet
        also contains the router's current choice for Designated Router
        and Backup Designated Router.  A value of 0.0.0.0 in these
        fields means that one has not yet been selected.

        On broadcast networks and physical point-to-point networks,
        Hello packets are sent every HelloInterval seconds to the IP
        multicast address AllSPFRouters.  On virtual links, Hello
        packets are sent as unicasts (addressed directly to the other
        end of the virtual link) every HelloInterval seconds.  On non-
        broadcast networks, the sending of Hello packets is more
        complicated.  This will be covered in the next section.


        9.5.1.  Sending Hello packets on non-broadcast networks

            Static configuration information is necessary in order for
            the Hello Protocol to function on non-broadcast networks
            (see Section C.5).  Every attached router which is eligible
            to become Designated Router has a configured list of all of
            its neighbors on the network.  Each listed neighbor is
            labelled with its Designated Router eligibility.

            The interface state must be at least Waiting for any Hello
            Packets to be sent.  Hello Packets are then sent directly
            (as unicasts) to some subset of a router's neighbors.
            Sometimes an Hello Packet is sent periodically on a timer;
            at other times it is sent as a response to a received Hello
            Packet.  A router's hello-sending behavior varies depending



Moy                                                            [Page 68]


RFC 1583                     OSPF Version 2                   March 1994


            on whether the router itself is eligible to become
            Designated Router.

            If the router is eligible to become Designated Router, it
            must periodically send Hello Packets to all neighbors that
            are also eligible.  In addition, if the router is itself the
            Designated Router or Backup Designated Router, it must also
            send periodic Hello Packets to all other neighbors.  This
            means that any two eligible routers are always exchanging
            Hello Packets, which is necessary for the correct operation
            of the Designated Router election algorithm.  To minimize
            the number of Hello Packets sent, the number of eligible
            routers on a non-broadcast network should be kept small.

            If the router is not eligible to become Designated Router,
            it must periodically send Hello Packets to both the
            Designated Router and the Backup Designated Router (if they
            exist).  It must also send an Hello Packet in reply to an
            Hello Packet received from any eligible neighbor (other than
            the current Designated Router and Backup Designated Router).
            This is needed to establish an initial bidirectional
            relationship with any potential Designated Router.

            When sending Hello packets periodically to any neighbor, the
            interval between Hello Packets is determined by the
            neighbor's state.  If the neighbor is in state Down, Hello
            Packets are sent every PollInterval seconds.  Otherwise,
            Hello Packets are sent every HelloInterval seconds.


10.  The Neighbor Data Structure

    An OSPF router converses with its neighboring routers.  Each
    separate conversation is described by a "neighbor data structure".
    Each conversation is bound to a particular OSPF router interface,
    and is identified either by the neighboring router's OSPF Router ID
    or by its Neighbor IP address (see below).  Thus if the OSPF router
    and another router have multiple attached networks in common,
    multiple conversations ensue, each described by a unique neighbor
    data structure.  Each separate conversation is loosely referred to
    in the text as being a separate "neighbor".

    The neighbor data structure contains all information pertinent to
    the forming or formed adjacency between the two neighbors.
    (However, remember that not all neighbors become adjacent.)  An
    adjacency can be viewed as a highly developed conversation between
    two routers.




Moy                                                            [Page 69]


RFC 1583                     OSPF Version 2                   March 1994


    State
        The functional level of the neighbor conversation.  This is
        described in more detail in Section 10.1.

    Inactivity Timer
        A single shot timer whose firing indicates that no Hello Packet
        has been seen from this neighbor recently.  The length of the
        timer is RouterDeadInterval seconds.

    Master/Slave
        When the two neighbors are exchanging databases, they form a
        master/slave relationship.  The master sends the first Database
        Description Packet, and is the only part that is allowed to
        retransmit.  The slave can only respond to the master's Database
        Description Packets.  The master/slave relationship is
        negotiated in state ExStart.

    DD Sequence Number
        A 32-bit number identifying individual Database Description
        packets.  When the neighbor state ExStart is entered, the DD
        sequence number should be set to a value not previously seen by
        the neighboring router.  One possible scheme is to use the
        machine's time of day counter.  The DD sequence number is then
        incremented by the master with each new Database Description
        packet sent.  The slave's DD sequence number indicates the last
        packet received from the master.  Only one packet is allowed
        outstanding at a time.

    Neighbor ID
        The OSPF Router ID of the neighboring router.  The Neighbor ID
        is learned when Hello packets are received from the neighbor, or
        is configured if this is a virtual adjacency (see Section C.4).

    Neighbor Priority
        The Router Priority of the neighboring router.  Contained in the
        neighbor's Hello packets, this item is used when selecting the
        Designated Router for the attached network.

    Neighbor IP address
        The IP address of the neighboring router's interface to the
        attached network.  Used as the Destination IP address when
        protocol packets are sent as unicasts along this adjacency.
        Also used in router links advertisements as the Link ID for the
        attached network if the neighboring router is selected to be
        Designated Router (see Section 12.4.1).  The Neighbor IP address
        is learned when Hello packets are received from the neighbor.
        For virtual links, the Neighbor IP address is learned during the
        routing table build process (see Section 15).



Moy                                                            [Page 70]


RFC 1583                     OSPF Version 2                   March 1994


    Neighbor Options
        The optional OSPF capabilities supported by the neighbor.
        Learned during the Database Exchange process (see Section 10.6).
        The neighbor's optional OSPF capabilities are also listed in its
        Hello packets.  This enables received Hello Packets to be
        rejected (i.e., neighbor relationships will not even start to
        form) if there is a mismatch in certain crucial OSPF
        capabilities (see Section 10.5).  The optional OSPF capabilities
        are documented in Section 4.5.

    Neighbor's Designated Router
        The neighbor's idea of the Designated Router.  If this is the
        neighbor itself, this is important in the local calculation of
        the Designated Router.  Defined only on multi-access networks.

    Neighbor's Backup Designated Router
        The neighbor's idea of the Backup Designated Router.  If this is
        the neighbor itself, this is important in the local calculation
        of the Backup Designated Router.  Defined only on multi-access
        networks.


    The next set of variables are lists of link state advertisements.
    These lists describe subsets of the area topological database.
    There can be five distinct types of link state advertisements in an
    area topological database: router links, network links, and Type 3
    and 4 summary links (all stored in the area data structure), and AS
    external links (stored in the global data structure).


    Link state retransmission list
        The list of link state advertisements that have been flooded but
        not acknowledged on this adjacency.  These will be retransmitted
        at intervals until they are acknowledged, or until the adjacency
        is destroyed.

    Database summary list
        The complete list of link state advertisements that make up the
        area topological database, at the moment the neighbor goes into
        Database Exchange state.  This list is sent to the neighbor in
        Database Description packets.

    Link state request list
        The list of link state advertisements that need to be received
        from this neighbor in order to synchronize the two neighbors'
        topological databases.  This list is created as Database
        Description packets are received, and is then sent to the
        neighbor in Link State Request packets.  The list is depleted as



Moy                                                            [Page 71]


RFC 1583                     OSPF Version 2                   March 1994


        appropriate Link State Update packets are received.


    10.1.  Neighbor states

        The state of a neighbor (really, the state of a conversation
        being held with a neighboring router) is documented in the
        following sections.  The states are listed in order of
        progressing functionality.  For example, the inoperative state
        is listed first, followed by a list of intermediate states
        before the final, fully functional state is achieved.  The
        specification makes use of this ordering by sometimes making
        references such as "those neighbors/adjacencies in state greater
        than X".  Figures 12 and 13 show the graph of neighbor state
        changes.  The arcs of the graphs are labelled with the event
        causing the state change.  The neighbor events are documented in
        Section 10.2.

        The graph in Figure 12 shows the state changes effected by the
        Hello Protocol.  The Hello Protocol is responsible for neighbor

                                   +----+
                                   |Down|
                                   +----+
                                     |                               | Start
                                     |        +-------+
                             Hello   |   +---->|Attempt|
                            Received |         +-------+
                                     |             |
                             +----+<-+             |HelloReceived
                             |Init|<---------------+
                             +----+<--------+
                                |           |
                                |2-Way      |1-Way
                                |Received   |Received
                                |           |
              +-------+         |        +-----+
              |ExStart|<--------+------->|2-Way|
              +-------+                  +-----+

              Figure 12: Neighbor state changes (Hello Protocol)

                  In addition to the state transitions pictured,
                  Event KillNbr always forces Down State,
                  Event InactivityTimer always forces Down State,
                  Event LLDown always forces Down State





Moy                                                            [Page 72]


RFC 1583                     OSPF Version 2                   March 1994


        acquisition and maintenance, and for ensuring two way
        communication between neighbors.

        The graph in Figure 13 shows the forming of an adjacency.  Not
        every two neighboring routers become adjacent (see Section
        10.4).  The adjacency starts to form when the neighbor is in
        state ExStart.  After the two routers discover their
        master/slave status, the state transitions to Exchange.  At this
        point the neighbor starts to be used in the flooding procedure,
        and the two neighboring routers begin synchronizing their
        databases.  When this synchronization is finished, the neighbor
        is in state Full and we say that the two routers are fully
        adjacent.  At this point the adjacency is listed in link state
        advertisements.

        For a more detailed description of neighbor state changes,
        together with the additional actions involved in each change,
        see Section 10.3.

                                  +-------+
                                  |ExStart|
                                  +-------+
                                    |
                     NegotiationDone|
                                    +->+--------+
                                       |Exchange|
                                    +--+--------+
                                    |
                            Exchange|
                              Done  |
                    +----+          |      +-------+
                    |Full|<---------+----->|Loading|
                    +----+<-+              +-------+
                            |  LoadingDone     |
                            +------------------+

            Figure 13: Neighbor state changes (Database Exchange)

                In addition to the state transitions pictured,
                Event SeqNumberMismatch forces ExStart state,
                Event BadLSReq forces ExStart state,
                Event 1-Way forces Init state,
                Event KillNbr always forces Down State,
                Event InactivityTimer always forces Down State,
                Event LLDown always forces Down State,
                Event AdjOK? leads to adjacency forming/breaking





Moy                                                            [Page 73]


RFC 1583                     OSPF Version 2                   March 1994


        Down
            This is the initial state of a neighbor conversation.  It
            indicates that there has been no recent information received
            from the neighbor.  On non-broadcast networks, Hello packets
            may still be sent to "Down" neighbors, although at a reduced
            frequency (see Section 9.5.1).

        Attempt
            This state is only valid for neighbors attached to non-
            broadcast networks.  It indicates that no recent information
            has been received from the neighbor, but that a more
            concerted effort should be made to contact the neighbor.
            This is done by sending the neighbor Hello packets at
            intervals of HelloInterval (see Section 9.5.1).

        Init
            In this state, an Hello packet has recently been seen from
            the neighbor.  However, bidirectional communication has not
            yet been established with the neighbor (i.e., the router
            itself did not appear in the neighbor's Hello packet).  All
            neighbors in this state (or higher) are listed in the Hello
            packets sent from the associated interface.

        2-Way
            In this state, communication between the two routers is
            bidirectional.  This has been assured by the operation of
            the Hello Protocol.  This is the most advanced state short
            of beginning adjacency establishment.  The (Backup)
            Designated Router is selected from the set of neighbors in
            state 2-Way or greater.

        ExStart
            This is the first step in creating an adjacency between the
            two neighboring routers.  The goal of this step is to decide
            which router is the master, and to decide upon the initial
            DD sequence number.  Neighbor conversations in this state or
            greater are called adjacencies.

        Exchange
            In this state the router is describing its entire link state
            database by sending Database Description packets to the
            neighbor.  Each Database Description Packet has a DD
            sequence number, and is explicitly acknowledged.  Only one
            Database Description Packet is allowed outstanding at any
            one time.  In this state, Link State Request Packets may
            also be sent asking for the neighbor's more recent
            advertisements.  All adjacencies in Exchange state or
            greater are used by the flooding procedure.  In fact, these



Moy                                                            [Page 74]


RFC 1583                     OSPF Version 2                   March 1994


            adjacencies are fully capable of transmitting and receiving
            all types of OSPF routing protocol packets.

        Loading
            In this state, Link State Request packets are sent to the
            neighbor asking for the more recent advertisements that have
            been discovered (but not yet received) in the Exchange
            state.

        Full
            In this state, the neighboring routers are fully adjacent.
            These adjacencies will now appear in router links and
            network links advertisements.


    10.2.  Events causing neighbor state changes

        State changes can be effected by a number of events.  These
        events are shown in the labels of the arcs in Figures 12 and 13.
        The label definitions are as follows:


        HelloReceived
            A Hello packet has been received from a neighbor.

        Start
            This is an indication that Hello Packets should now be sent
            to the neighbor at intervals of HelloInterval seconds.  This
            event is generated only for neighbors associated with non-
            broadcast networks.

        2-WayReceived
            Bidirectional communication has been realized between the
            two neighboring routers.  This is indicated by this router
            seeing itself in the other's Hello packet.

        NegotiationDone
            The Master/Slave relationship has been negotiated, and DD
            sequence numbers have been exchanged.  This signals the
            start of the sending/receiving of Database Description
            packets.  For more information on the generation of this
            event, consult Section 10.8.

        ExchangeDone
            Both routers have successfully transmitted a full sequence
            of Database Description packets.  Each router now knows what
            parts of its link state database are out of date.  For more
            information on the generation of this event, consult Section



Moy                                                            [Page 75]


RFC 1583                     OSPF Version 2                   March 1994


            10.8.

        BadLSReq
            A Link State Request has been received for a link state
            advertisement not contained in the database.  This indicates
            an error in the Database Exchange process.

        Loading Done
            Link State Updates have been received for all out-of-date
            portions of the database.  This is indicated by the Link
            state request list becoming empty after the Database
            Exchange process has completed.

        AdjOK?
            A decision must be made (again) as to whether an adjacency
            should be established/maintained with the neighbor.  This
            event will start some adjacencies forming, and destroy
            others.


        The following events cause well developed neighbors to revert to
        lesser states.  Unlike the above events, these events may occur
        when the neighbor conversation is in any of a number of states.


        SeqNumberMismatch
            A Database Description packet has been received that either
            a) has an unexpected DD sequence number, b) unexpectedly has
            the Init bit set or c) has an Options field differing from
            the last Options field received in a Database Description
            packet.  Any of these conditions indicate that some error
            has occurred during adjacency establishment.

        1-Way
            An Hello packet has been received from the neighbor, in
            which this router is not mentioned.  This indicates that
            communication with the neighbor is not bidirectional.

        KillNbr
            This  is  an  indication that  all  communication  with  the
            neighbor  is now  impossible,  forcing  the  neighbor  to
            revert  to  Down  state.

        InactivityTimer
            The inactivity Timer has fired.  This means that no Hello
            packets have been seen recently from the neighbor.  The
            neighbor reverts to Down state.




Moy                                                            [Page 76]


RFC 1583                     OSPF Version 2                   March 1994


        LLDown
            This is an indication from the lower level protocols that
            the neighbor is now unreachable.  For example, on an X.25
            network this could be indicated by an X.25 clear indication
            with appropriate cause and diagnostic fields.  This event
            forces the neighbor into Down state.


    10.3.  The Neighbor state machine

        A detailed description of the neighbor state changes follows.
        Each state change is invoked by an event (Section 10.2).  This
        event may produce different effects, depending on the current
        state of the neighbor.  For this reason, the state machine below
        is organized by current neighbor state and received event.  Each
        entry in the state machine describes the resulting new neighbor
        state and the required set of additional actions.

        When a neighbor's state changes, it may be necessary to rerun
        the Designated Router election algorithm.  This is determined by
        whether the interface NeighborChange event is generated (see
        Section 9.2).  Also, if the Interface is in DR state (the router
        is itself Designated Router), changes in neighbor state may
        cause a new network links advertisement to be originated (see
        Section 12.4).

        When the neighbor state machine needs to invoke the interface
        state machine, it should be done as a scheduled task (see
        Section 4.4).  This simplifies things, by ensuring that neither
        state machine will be executed recursively.


         State(s):  Down

            Event:  Start

        New state:  Attempt

           Action:  Send an Hello Packet to the neighbor (this neighbor
                    is always associated with a non-broadcast network)
                    and start the Inactivity Timer for the neighbor.
                    The timer's later firing would indicate that
                    communication with the neighbor was not attained.


         State(s):  Attempt





Moy                                                            [Page 77]


RFC 1583                     OSPF Version 2                   March 1994


            Event:  HelloReceived

        New state:  Init

           Action:  Restart the Inactivity Timer for the neighbor, since
                    the neighbor has now been heard from.


         State(s):  Down

            Event:  HelloReceived

        New state:  Init

           Action:  Start the Inactivity Timer for the neighbor.  The
                    timer's later firing would indicate that the
                    neighbor is dead.


         State(s):  Init or greater

            Event:  HelloReceived

        New state:  No state change.

           Action:  Restart the Inactivity Timer for the neighbor, since
                    the neighbor has again been heard from.


         State(s):  Init

            Event:  2-WayReceived

        New state:  Depends upon action routine.

           Action:  Determine whether an adjacency should be established
                    with the neighbor (see Section 10.4).  If not, the
                    new neighbor state is 2-Way.

                    Otherwise (an adjacency should be established) the
                    neighbor state transitions to ExStart.  Upon
                    entering this state, the router increments the DD
                    sequence number for this neighbor.  If this is the
                    first time that an adjacency has been attempted, the
                    DD sequence number should be assigned some unique
                    value (like the time of day clock).  It then
                    declares itself master (sets the master/slave bit to
                    master), and starts sending Database Description



Moy                                                            [Page 78]


RFC 1583                     OSPF Version 2                   March 1994


                    Packets, with the initialize (I), more (M) and
                    master (MS) bits set.  This Database Description
                    Packet should be otherwise empty.  This Database
                    Description Packet should be retransmitted at
                    intervals of RxmtInterval until the next state is
                    entered (see Section 10.8).


         State(s):  ExStart

            Event:  NegotiationDone

        New state:  Exchange

           Action:  The router must list the contents of its entire area
                    link state database in the neighbor Database summary
                    list.  The area link state database consists of the
                    router links, network links and summary links
                    contained in the area structure, along with the AS
                    external links contained in the global structure.
                    AS external link advertisements are omitted from a
                    virtual neighbor's Database summary list.  AS
                    external advertisements are omitted from the
                    Database summary list if the area has been
                    configured as a stub (see Section 3.6).
                    Advertisements whose age is equal to MaxAge are
                    instead added to the neighbor's Link state
                    retransmission list.  A summary of the Database
                    summary list will be sent to the neighbor in
                    Database Description packets.  Each Database
                    Description Packet has a DD sequence number, and is
                    explicitly acknowledged.  Only one Database
                    Description Packet is allowed outstanding at any one
                    time.  For more detail on the sending and receiving
                    of Database Description packets, see Sections 10.8
                    and 10.6.


         State(s):  Exchange

            Event:  ExchangeDone

        New state:  Depends upon action routine.

           Action:  If the neighbor Link state request list is empty,
                    the new neighbor state is Full.  No other action is
                    required.  This is an adjacency's final state.




Moy                                                            [Page 79]


RFC 1583                     OSPF Version 2                   March 1994


                    Otherwise, the new neighbor state is Loading.  Start
                    (or continue) sending Link State Request packets to
                    the neighbor (see Section 10.9).  These are requests
                    for the neighbor's more recent advertisements (which
                    were discovered but not yet received in the Exchange
                    state).  These advertisements are listed in the Link
                    state request list associated with the neighbor.


         State(s):  Loading

            Event:  Loading Done

        New state:  Full

           Action:  No action required.  This is an adjacency's final
                    state.


         State(s):  2-Way

            Event:  AdjOK?

        New state:  Depends upon action routine.

           Action:  Determine whether an adjacency should be formed with
                    the neighboring router (see Section 10.4).  If not,
                    the neighbor state remains at 2-Way.  Otherwise,
                    transition the neighbor state to ExStart and perform
                    the actions associated with the above state machine
                    entry for state Init and event 2-WayReceived.


         State(s):  ExStart or greater

            Event:  AdjOK?

        New state:  Depends upon action routine.

           Action:  Determine whether the neighboring router should
                    still be adjacent.  If yes, there is no state change
                    and no further action is necessary.

                    Otherwise, the (possibly partially formed) adjacency
                    must be destroyed.  The neighbor state transitions
                    to 2-Way.  The Link state retransmission list,
                    Database summary list and Link state request list
                    are cleared of link state advertisements.



Moy                                                            [Page 80]


RFC 1583                     OSPF Version 2                   March 1994


         State(s):  Exchange or greater

            Event:  SeqNumberMismatch

        New state:  ExStart

           Action:  The (possibly partially formed) adjacency is torn
                    down, and then an attempt is made at
                    reestablishment.  The neighbor state first
                    transitions to ExStart.  The Link state
                    retransmission list, Database summary list and Link
                    state request list are cleared of link state
                    advertisements.  Then the router increments the DD
                    sequence number for this neighbor, declares itself
                    master (sets the master/slave bit to master), and
                    starts sending Database Description Packets, with
                    the initialize (I), more (M) and master (MS) bits
                    set.  This Database Description Packet should be
                    otherwise empty (see Section 10.8).


         State(s):  Exchange or greater

            Event:  BadLSReq

        New state:  ExStart

           Action:  The action for event BadLSReq is exactly the same as
                    for the neighbor event SeqNumberMismatch.  The
                    (possibly partially formed) adjacency is torn down,
                    and then an attempt is made at reestablishment.  For
                    more information, see the neighbor state machine
                    entry that is invoked when event SeqNumberMismatch
                    is generated in state Exchange or greater.


         State(s):  Any state

            Event:  KillNbr

        New state:  Down

           Action:  The Link state retransmission list, Database summary
                    list and Link state request list are cleared of link
                    state advertisements.  Also, the Inactivity Timer is
                    disabled.





Moy                                                            [Page 81]


RFC 1583                     OSPF Version 2                   March 1994


         State(s):  Any state

            Event:  LLDown

        New state:  Down

           Action:  The Link state retransmission list, Database summary
                    list and Link state request list are cleared of link
                    state advertisements.  Also, the Inactivity Timer is
                    disabled.


         State(s):  Any state

            Event:  InactivityTimer

        New state:  Down

           Action:  The Link state retransmission list, Database summary
                    list and Link state request list are cleared of link
                    state advertisements.


         State(s):  2-Way or greater

            Event:  1-WayReceived

        New state:  Init

           Action:  The Link state retransmission list, Database summary
                    list and Link state request list are cleared of link
                    state advertisements.


         State(s):  2-Way or greater

            Event:  2-WayReceived

        New state:  No state change.

           Action:  No action required.


         State(s):  Init

            Event:  1-WayReceived





Moy                                                            [Page 82]


RFC 1583                     OSPF Version 2                   March 1994


        New state:  No state change.

           Action:  No action required.


    10.4.  Whether to become adjacent

        Adjacencies are established with some subset of the router's
        neighbors.  Routers connected by point-to-point networks and
        virtual links always become adjacent.  On multi-access networks,
        all routers become adjacent to both the Designated Router and
        the Backup Designated Router.

        The adjacency-forming decision occurs in two places in the
        neighbor state machine.  First, when bidirectional communication
        is initially established with the neighbor, and secondly, when
        the identity of the attached network's (Backup) Designated
        Router changes.  If the decision is made to not attempt an
        adjacency, the state of the neighbor communication stops at 2-
        Way.

        An adjacency should be established with a bidirectional neighbor
        when at least one of the following conditions holds:


        o   The underlying network type is point-to-point

        o   The underlying network type is virtual link

        o   The router itself is the Designated Router

        o   The router itself is the Backup Designated Router

        o   The neighboring router is the Designated Router

        o   The neighboring router is the Backup Designated Router


    10.5.  Receiving Hello Packets

        This section explains the detailed processing of a received
        Hello Packet.  (See Section A.3.2 for the format of Hello
        packets.)  The generic input processing of OSPF packets will
        have checked the validity of the IP header and the OSPF packet
        header.  Next, the values of the Network Mask, HelloInterval,
        and RouterDeadInterval fields in the received Hello packet must
        be checked against the values configured for the receiving
        interface.  Any mismatch causes processing to stop and the



Moy                                                            [Page 83]


RFC 1583                     OSPF Version 2                   March 1994


        packet to be dropped.  In other words, the above fields are
        really describing the attached network's configuration. However,
        there is one exception to the above rule: on point-to-point
        networks and on virtual links, the Network Mask in the received
        Hello Packet should be ignored.

        The receiving interface attaches to a single OSPF area (this
        could be the backbone).  The setting of the E-bit found in the
        Hello Packet's Options field must match this area's
        ExternalRoutingCapability.  If AS external advertisements are
        not flooded into/throughout the area (i.e, the area is a "stub")
        the E-bit must be clear in received Hello Packets, otherwise the
        E-bit must be set.  A mismatch causes processing to stop and the
        packet to be dropped.  The setting of the rest of the bits in
        the Hello Packet's Options field should be ignored.

        At this point, an attempt is made to match the source of the
        Hello Packet to one of the receiving interface's neighbors.  If
        the receiving interface is a multi-access network (either
        broadcast or non-broadcast) the source is identified by the IP
        source address found in the Hello's IP header.  If the receiving
        interface is a point-to-point link or a virtual link, the source
        is identified by the Router ID found in the Hello's OSPF packet
        header.  The interface's current list of neighbors is contained
        in the interface's data structure.  If a matching neighbor
        structure cannot be found, (i.e., this is the first time the
        neighbor has been detected), one is created.  The initial state
        of a newly created neighbor is set to Down.

        When receiving an Hello Packet from a neighbor on a multi-access
        network (broadcast or non-broadcast), set the neighbor
        structure's Neighbor ID equal to the Router ID found in the
        packet's OSPF header.  When receiving an Hello on a point-to-
        point network (but not on a virtual link) set the neighbor
        structure's Neighbor IP address to the packet's IP source
        address.

        Now the rest of the Hello Packet is examined, generating events
        to be given to the neighbor and interface state machines.  These
        state machines are specified either to be executed or scheduled
        (see Section 4.4).  For example, by specifying below that the
        neighbor state machine be executed in line, several neighbor
        state transitions may be effected by a single received Hello:


        o   Each Hello Packet causes the neighbor state machine to be
            executed with the event HelloReceived.




Moy                                                            [Page 84]


RFC 1583                     OSPF Version 2                   March 1994


        o   Then the list of neighbors contained in the Hello Packet is
            examined.  If the router itself appears in this list, the
            neighbor state machine should be executed with the event 2-
            WayReceived.  Otherwise, the neighbor state machine should
            be executed with the event 1-WayReceived, and the processing
            of the packet stops.

        o   Next, the Hello Packet's Router Priority field is examined.
            If this field is different than the one previously received
            from the neighbor, the receiving interface's state machine
            is scheduled with the event NeighborChange.  In any case,
            the Router Priority field in the neighbor data structure
            should be updated accordingly.

        o   Next the Designated Router field in the Hello Packet is
            examined.  If the neighbor is both declaring itself to be
            Designated Router (Designated Router field = Neighbor IP
            address) and the Backup Designated Router field in the
            packet is equal to 0.0.0.0 and the receiving interface is in
            state Waiting, the receiving interface's state machine is
            scheduled with the event BackupSeen.  Otherwise, if the
            neighbor is declaring itself to be Designated Router and it
            had not previously, or the neighbor is not declaring itself
            Designated Router where it had previously, the receiving
            interface's state machine is scheduled with the event
            NeighborChange.  In any case, the Neighbors' Designated
            Router item in the neighbor structure is updated
            accordingly.

        o   Finally, the Backup Designated Router field in the Hello
            Packet is examined.  If the neighbor is declaring itself to
            be Backup Designated Router (Backup Designated Router field
            = Neighbor IP address) and the receiving interface is in
            state Waiting, the receiving interface's state machine is
            scheduled with the event BackupSeen.  Otherwise, if the
            neighbor is declaring itself to be Backup Designated Router
            and it had not previously, or the neighbor is not declaring
            itself Backup Designated Router where it had previously, the
            receiving interface's state machine is scheduled with the
            event NeighborChange.  In any case, the Neighbor's Backup
            Designated Router item in the neighbor structure is updated
            accordingly.

        On non-broadcast multi-access networks, receipt of an Hello
        Packet may also cause an Hello Packet to be sent back to the
        neighbor in response. See Section 9.5.1 for more details.





Moy                                                            [Page 85]


RFC 1583                     OSPF Version 2                   March 1994


    10.6.  Receiving Database Description Packets

        This section explains the detailed processing of a received
        Database Description Packet.  The incoming Database Description
        Packet has already been associated with a neighbor and receiving
        interface by the generic input packet processing (Section 8.2).
        The further processing of the Database Description Packet
        depends on the neighbor state.  If the neighbor's state is Down
        or Attempt the packet should be ignored.  Otherwise, if the
        state is:


        Init
            The neighbor state machine should be executed with the event
            2-WayReceived.  This causes an immediate state change to
            either state 2-Way or state ExStart. If the new state is
            ExStart, the processing of the current packet should then
            continue in this new state by falling through to case
            ExStart below.

        2-Way
            The packet should be ignored.  Database Description Packets
            are used only for the purpose of bringing up adjacencies.[7]

        ExStart
            If the received packet matches one of the following cases,
            then the neighbor state machine should be executed with the
            event NegotiationDone (causing the state to transition to
            Exchange), the packet's Options field should be recorded in
            the neighbor structure's Neighbor Options field and the
            packet should be accepted as next in sequence and processed
            further (see below).  Otherwise, the packet should be
            ignored.

            o   The initialize(I), more (M) and master(MS) bits are set,
                the contents of the packet are empty, and the neighbor's
                Router ID is larger than the router's own.  In this case
                the router is now Slave.  Set the master/slave bit to
                slave, and set the DD sequence number to that specified
                by the master.

            o   The initialize(I) and master(MS) bits are off, the
                packet's DD sequence number equals the router's own DD
                sequence number (indicating acknowledgment) and the
                neighbor's Router ID is smaller than the router's own.
                In this case the router is Master.





Moy                                                            [Page 86]


RFC 1583                     OSPF Version 2                   March 1994


        Exchange
            If the state of the MS-bit is inconsistent with the
            master/slave state of the connection, generate the neighbor
            event SeqNumberMismatch and stop processing the packet.
            Otherwise:

            o   If the initialize(I) bit is set, generate the neighbor
                event SeqNumberMismatch and stop processing the packet.

            o   If the packet's Options field indicates a different set
                of optional OSPF capabilities than were previously
                received from the neighbor (recorded in the Neighbor
                Options field of the neighbor structure), generate the
                neighbor event SeqNumberMismatch and stop processing the
                packet.

            o   If the router is master, and the packet's DD sequence
                number equals the router's own DD sequence number (this
                packet is the next in sequence) the packet should be
                accepted and its contents processed (below).

            o   If the router is master, and the packet's DD sequence
                number is one less than the router's DD sequence number,
                the packet is a duplicate.  Duplicates should be
                discarded by the master.

            o   If the router is slave, and the packet's DD sequence
                number is one more than the router's own DD sequence
                number (this packet is the next in sequence) the packet
                should be accepted and its contents processed (below).

            o   If the router is slave, and the packet's DD sequence
                number is equal to the router's DD sequence number, the
                packet is a duplicate.  The slave must respond to
                duplicates by repeating the last Database Description
                packet that it had sent.

            o   Else, generate the neighbor event SeqNumberMismatch and
                stop processing the packet.

        Loading or Full
            In this state, the router has sent and received an entire
            sequence of Database Description Packets.  The only packets
            received should be duplicates (see above).  In particular,
            the packet's Options field should match the set of optional
            OSPF capabilities previously indicated by the neighbor
            (stored in the neighbor structure's Neighbor Options field).
            Any other packets received, including the reception of a



Moy                                                            [Page 87]


RFC 1583                     OSPF Version 2                   March 1994


            packet with the Initialize(I) bit set, should generate the
            neighbor event SeqNumberMismatch.[8] Duplicates should be
            discarded by the master.  The slave must respond to
            duplicates by repeating the last Database Description packet
            that it had sent.


        When the router accepts a received Database Description Packet
        as the next in sequence the packet contents are processed as
        follows.  For each link state advertisement listed, the
        advertisement's LS type is checked for validity.  If the LS type
        is unknown (e.g., not one of the LS types 1-5 defined by this
        specification), or if this is a AS external advertisement (LS
        type = 5) and the neighbor is associated with a stub area,
        generate the neighbor event SeqNumberMismatch and stop
        processing the packet.  Otherwise, the router looks up the
        advertisement in its database to see whether it also has an
        instance of the link state advertisement.  If it does not, or if
        the database copy is less recent (see Section 13.1), the link
        state advertisement is put on the Link state request list so
        that it can be requested (immediately or at some later time) in
        Link State Request Packets.

        When the router accepts a received Database Description Packet
        as the next in sequence, it also performs the following actions,
        depending on whether it is master or slave:


        Master
            Increments the DD sequence number.  If the router has
            already sent its entire sequence of Database Description
            Packets, and the just accepted packet has the more bit (M)
            set to 0, the neighbor event ExchangeDone is generated.
            Otherwise, it should send a new Database Description to the
            slave.

        Slave
            Sets the DD sequence number to the DD sequence number
            appearing in the received packet.  The slave must send a
            Database Description Packet in reply.  If the received
            packet has the more bit (M) set to 0, and the packet to be
            sent by the slave will also have the M-bit set to 0, the
            neighbor event ExchangeDone is generated.  Note that the
            slave always generates this event before the master.







Moy                                                            [Page 88]


RFC 1583                     OSPF Version 2                   March 1994


    10.7.  Receiving Link State Request Packets

        This section explains the detailed processing of received Link
        State Request packets.  Received Link State Request Packets
        specify a list of link state advertisements that the neighbor
        wishes to receive.  Link State Request Packets should be
        accepted when the neighbor is in states Exchange, Loading, or
        Full.  In all other states Link State Request Packets should be
        ignored.

        Each link state advertisement specified in the Link State
        Request packet should be located in the router's database, and
        copied into Link State Update packets for transmission to the
        neighbor.  These link state advertisements should NOT be placed
        on the Link state retransmission list for the neighbor.  If a
        link state advertisement cannot be found in the database,
        something has gone wrong with the Database Exchange process, and
        neighbor event BadLSReq should be generated.


    10.8.  Sending Database Description Packets

        This section describes how Database Description Packets are sent
        to a neighbor.  The router's optional OSPF capabilities (see
        Section 4.5) are transmitted to the neighbor in the Options
        field of the Database Description packet.  The router should
        maintain the same set of optional capabilities throughout the
        Database Exchange and flooding procedures.  If for some reason
        the router's optional capabilities change, the Database Exchange
        procedure should be restarted by reverting to neighbor state
        ExStart.  There are currently two optional capabilities defined.
        The T-bit should be set if and only if the router is capable of
        calculating separate routes for each IP TOS.  The E-bit should
        be set if and only if the attached network belongs to a non-stub
        area.  The rest of the Options field should be set to zero.

        The sending of Database Description packets depends on the
        neighbor's state.  In state ExStart the router sends empty
        Database Description packets, with the initialize (I), more (M)
        and master (MS) bits set.  These packets are retransmitted every
        RxmtInterval seconds.

        In state Exchange the Database Description Packets actually
        contain summaries of the link state information contained in the
        router's database.  Each link state advertisement in the area's
        topological database (at the time the neighbor transitions into
        Exchange state) is listed in the neighbor Database summary list.
        When a new Database Description Packet is to be sent, the



Moy                                                            [Page 89]


RFC 1583                     OSPF Version 2                   March 1994


        packet's DD sequence number is incremented, and the (new) top of
        the Database summary list is described by the packet.  Items are
        removed from the Database summary list when the previous packet
        is acknowledged.

        In state Exchange, the determination of when to send a Database
        Description packet depends on whether the router is master or
        slave:


        Master
            Database Description packets are sent when either a) the
            slave acknowledges the previous Database Description packet
            by echoing the DD sequence number or b) RxmtInterval seconds
            elapse without an acknowledgment, in which case the previous
            Database Description packet is retransmitted.

        Slave
            Database Description packets are sent only in response to
            Database Description packets received from the master.  If
            the Database Description packet received from the master is
            new, a new Database Description packet is sent, otherwise
            the previous Database Description packet is resent.


        In states Loading and Full the slave must resend its last
        Database Description packet in response to duplicate Database
        Description packets received from the master.  For this reason
        the slave must wait RouterDeadInterval seconds before freeing
        the last Database Description packet.  Reception of a Database
        Description packet from the master after this interval will
        generate a SeqNumberMismatch neighbor event.


    10.9.  Sending Link State Request Packets

        In neighbor states Exchange or Loading, the Link state request
        list contains a list of those link state advertisements that
        need to be obtained from the neighbor.  To request these
        advertisements, a router sends the neighbor the beginning of the
        Link state request list, packaged in a Link State Request
        packet.

        When the neighbor responds to these requests with the proper
        Link State Update packet(s), the Link state request list is
        truncated and a new Link State Request packet is sent.  This
        process continues until the Link state request list becomes
        empty.  Unsatisfied Link State Request packets are retransmitted



Moy                                                            [Page 90]


RFC 1583                     OSPF Version 2                   March 1994


        at intervals of RxmtInterval.  There should be at most one Link
        State Request packet outstanding at any one time.

        When the Link state request list becomes empty, and the neighbor
        state is Loading (i.e., a complete sequence of Database
        Description packets has been sent to and received from the
        neighbor), the Loading Done neighbor event is generated.


    10.10.  An Example

        Figure 14 shows an example of an adjacency forming.  Routers RT1
        and RT2 are both connected to a broadcast network.  It is
        assumed that RT2 is the Designated Router for the network, and
        that RT2 has a higher Router ID than Router RT1.

        The neighbor state changes realized by each router are listed on
        the sides of the figure.

        At the beginning of Figure 14, Router RT1's interface to the
        network becomes operational.  It begins sending Hello Packets,
        although it doesn't know the identity of the Designated Router
        or of any other neighboring routers.  Router RT2 hears this
        hello (moving the neighbor to Init state), and in its next Hello
        Packet indicates that it is itself the Designated Router and
        that it has heard Hello Packets from RT1.  This in turn causes
        RT1 to go to state ExStart, as it starts to bring up the
        adjacency.

        RT1 begins by asserting itself as the master.  When it sees that
        RT2 is indeed the master (because of RT2's higher Router ID),
        RT1 transitions to slave state and adopts its neighbor's DD
        sequence number.  Database Description packets are then
        exchanged, with polls coming from the master (RT2) and responses
        from the slave (RT1).  This sequence of Database Description
        Packets ends when both the poll and associated response has the
        M-bit off.

        In this example, it is assumed that RT2 has a completely up to
        date database.  In that case, RT2 goes immediately into Full
        state.  RT1 will go into Full state after updating the necessary
        parts of its database.  This is done by sending Link State
        Request Packets, and receiving Link State Update Packets in
        response.  Note that, while RT1 has waited until a complete set
        of Database Description Packets has been received (from RT2)
        before sending any Link State Request Packets, this need not be
        the case.  RT1 could have interleaved the sending of Link State
        Request Packets with the reception of Database Description



Moy                                                            [Page 91]


RFC 1583                     OSPF Version 2                   March 1994







            +---+                                         +---+
            |RT1|                                         |RT2|
            +---+                                         +---+

            Down                                          Down
                            Hello(DR=0,seen=0)
                       ------------------------------>
                         Hello (DR=RT2,seen=RT1,...)      Init
                       <------------------------------
            ExStart        D-D (Seq=x,I,M,Master)
                       ------------------------------>
                           D-D (Seq=y,I,M,Master)         ExStart
                       <------------------------------
            Exchange       D-D (Seq=y,M,Slave)
                       ------------------------------>
                           D-D (Seq=y+1,M,Master)         Exchange
                       <------------------------------
                           D-D (Seq=y+1,M,Slave)
                       ------------------------------>
                                     ...
                                     ...
                                     ...
                           D-D (Seq=y+n, Master)
                       <------------------------------
                           D-D (Seq=y+n, Slave)
             Loading   ------------------------------>
                                 LS Request                Full
                       ------------------------------>
                                 LS Update
                       <------------------------------
                                 LS Request
                       ------------------------------>
                                 LS Update
                       <------------------------------
             Full


                   Figure 14: An adjacency bring-up example








Moy                                                            [Page 92]


RFC 1583                     OSPF Version 2                   March 1994


        Packets.


11.  The Routing Table Structure

    The routing table data structure contains all the information
    necessary to forward an IP data packet toward its destination.  Each
    routing table entry describes the collection of best paths to a
    particular destination.  When forwarding an IP data packet, the
    routing table entry providing the best match for the packet's IP
    destination is located.  The matching routing table entry then
    provides the next hop towards the packet's destination.  OSPF also
    provides for the existence of a default route (Destination ID =
    DefaultDestination, Address Mask =  0x00000000).  When the default
    route exists, it matches all IP destinations (although any other
    matching entry is a better match).  Finding the routing table entry
    that best matches an IP destination is further described in Section
    11.1.

    There is a single routing table in each router.  Two sample routing
    tables are described in Sections 11.2 and 11.3.  The building of the
    routing table is discussed in Section 16.

    The rest of this section defines the fields found in a routing table
    entry.  The first set of fields describes the routing table entry's
    destination.


    Destination Type
        The destination can be one of three types.  Only the first type,
        Network, is actually used when forwarding IP data traffic.  The
        other destinations are used solely as intermediate steps in the
        routing table build process.

        Network
            A range of IP addresses, to which IP data traffic may be
            forwarded.  This includes IP networks (class A, B, or C), IP
            subnets, IP supernets and single IP hosts.  The default
            route also falls in this category.

        Area border router
            Routers that are connected to multiple OSPF areas.  Such
            routers originate summary link advertisements.  These
            routing table entries are used when calculating the inter-
            area routes (see Section 16.2).  These routing table entries
            may also be associated with configured virtual links.





Moy                                                            [Page 93]


RFC 1583                     OSPF Version 2                   March 1994


        AS boundary router
            Routers that originate AS external link advertisements.
            These routing table entries are used when calculating the AS
            external routes (see Section 16.4).

    Destination ID
        The destination's identifier or name.  This depends on the
        Destination Type.  For networks, the identifier is their
        associated IP address.  For all other types, the identifier is
        the OSPF Router ID.[9]

    Address Mask
        Only defined for networks.  The network's IP address together
        with its address mask defines a range of IP addresses.  For IP
        subnets, the address mask is referred to as the subnet mask.
        For host routes, the mask is "all ones" (0xffffffff).

    Optional Capabilities
        When the destination is a router (either an area border router
        or an AS boundary router) this field indicates the optional OSPF
        capabilities supported by the destination router.  The two
        optional capabilities currently defined by this specification
        are the ability to route based on IP TOS and the ability to
        process AS external link advertisements.  For a further
        discussion of OSPF's optional capabilities, see Section 4.5.


    The set of paths to use for a destination may vary based on IP Type
    of Service and the OSPF area to which the paths belong.  This means
    that there may be multiple routing table entries for the same
    destination, depending on the values of the next two fields.


    Type of Service
        There can be a separate set of routes for each IP Type of
        Service.  The encoding of TOS in OSPF link state advertisements
        is described in Section 12.3.

    Area
        This field indicates the area whose link state information has
        led to the routing table entry's collection of paths.  This is
        called the entry's associated area.  For sets of AS external
        paths, this field is not defined.  For destinations of type
        "area border router", there may be separate sets of paths (and
        therefore separate routing table entries) associated with each
        of several areas.  This will happen when two area border routers
        share multiple areas in common.  For all other destination
        types, only the set of paths associated with the best area (the



Moy                                                            [Page 94]


RFC 1583                     OSPF Version 2                   March 1994


        one providing the shortest route) is kept.


    The rest of the routing table entry describes the set of paths to
    the destination.  The following fields pertain to the set of paths
    as a whole.  In other words, each one of the paths contained in a
    routing table entry is of the same path-type and cost (see below).


    Path-type
        There are four possible types of paths used to route traffic to
        the destination, listed here in order of preference: intra-area,
        inter-area, type 1 external or type 2 external.  Intra-area
        paths indicate destinations belonging to one of the router's
        attached areas.  Inter-area paths are paths to destinations in
        other OSPF areas.  These are discovered through the examination
        of received summary link advertisements.  AS external paths are
        paths to destinations external to the AS.  These are detected
        through the examination of received AS external link
        advertisements.

    Cost
        The link state cost of the path to the destination.  For all
        paths except type 2 external paths this describes the entire
        path's cost.  For Type 2 external paths, this field describes
        the cost of the portion of the path internal to the AS.  This
        cost is calculated as the sum of the costs of the path's
        constituent links.

    Type 2 cost
        Only valid for type 2 external paths.  For these paths, this
        field indicates the cost of the path's external portion.  This
        cost has been advertised by an AS boundary router, and is the
        most significant part of the total path cost.  For example, a
        type 2 external path with type 2 cost of 5 is always preferred
        over a path with type 2 cost of 10, regardless of the cost of
        the two paths' internal components.

    Link State Origin
        Valid only for intra-area paths, this field indicates the link
        state advertisement (router links or network links) that
        directly references the destination.  For example, if the
        destination is a transit network, this is the transit network's
        network links advertisement.  If the destination is a stub
        network, this is the router links advertisement for the attached
        router.  The advertisement is discovered during the shortest-
        path tree calculation (see Section 16.1).  Multiple
        advertisements may reference the destination, however a tie-



Moy                                                            [Page 95]


RFC 1583                     OSPF Version 2                   March 1994


        breaking scheme always reduces the choice to a single
        advertisement. The Link State Origin field is not used by the
        OSPF protocol, but it is used by the routing table calculation
        in OSPF's Multicast routing extensions (MOSPF).

    When multiple paths of equal path-type and cost exist to a
    destination (called elsewhere "equal-cost" paths), they are stored
    in a single routing table entry.  Each one of the "equal-cost" paths
    is distinguished by the following fields:


    Next hop
        The outgoing router interface to use when forwarding traffic to
        the destination.  On multi-access networks, the next hop also
        includes the IP address of the next router (if any) in the path
        towards the destination.  This next router will always be one of
        the adjacent neighbors.

    Advertising router
        Valid only for inter-area and AS external paths.  This field
        indicates the Router ID of the router advertising the summary
        link or AS external link that led to this path.


    11.1.  Routing table lookup

        When an IP data packet is received, an OSPF router finds the
        routing table entry that best matches the packet's destination.
        This routing table entry then provides the outgoing interface
        and next hop router to use in forwarding the packet. This
        section describes the process of finding the best matching
        routing table entry. The process consists of a number of steps,
        wherein the collection of routing table entries is progressively
        pruned. In the end, the single routing table entry remaining is
        the called best match.

        Note that the steps described below may fail to produce a best
        match routing table entry (i.e., all existing routing table
        entries are pruned for some reason or another). In this case,
        the packet's IP destination is considered unreachable. Instead
        of being forwarded, the packet should be dropped and an ICMP
        destination unreachable message should be returned to the
        packet's source.


        (1) Select the complete set of "matching" routing table entries
            from the routing table.  Each routing table entry describes
            a (set of) path(s) to a range of IP addresses. If the data



Moy                                                            [Page 96]


RFC 1583                     OSPF Version 2                   March 1994


            packet's IP destination falls into an entry's range of IP
            addresses, the routing table entry is called a match. (It is
            quite likely that multiple entries will match the data
            packet.  For example, a default route will match all
            packets.)

        (2) Suppose that the packet's IP destination falls into one of
            the router's configured area address ranges (see Section
            3.5), and that the particular area address range is active.
            This means that there are one or more reachable (by intra-
            area paths) networks contained in the area address range.
            The packet's IP destination is then required to belong to
            one of these constituent networks. For this reason, only
            matching routing table entries with path-type of intra-area
            are considered (all others are pruned). If no such matching
            entries exist, the destination is unreachable (see above).
            Otherwise, skip to step 4.

        (3) Reduce the set of matching entries to those having the most
            preferential path-type (see Section 11). OSPF has a four
            level hierarchy of paths. Intra-area paths are the most
            preferred, followed in order by inter-area, type 1 external
            and type 2 external paths.

        (4) Select the remaining routing table entry that provides the
            longest (most specific) match. Another way of saying this is
            to choose the remaining entry that specifies the narrowest
            range of IP addresses.[10] For example, the entry for the
            address/mask pair of (128.185.1.0, 0xffffff00) is more
            specific than an entry for the pair (128.185.0.0,
            0xffff0000). The default route is the least specific match,
            since it matches all destinations.

        (5) At this point, there may still be multiple routing table
            entries remaining. Each routing entry will specify the same
            range of IP addresses, but a different IP Type of Service.
            Select the routing table entry whose TOS value matches the
            TOS found in the packet header. If there is no routing table
            entry for this TOS, select the routing table entry for TOS
            0. In other words, packets requesting TOS X are routed along
            the TOS 0 path if a TOS X path does not exist.


    11.2.  Sample routing table, without areas

        Consider the Autonomous System pictured in Figure 2.  No OSPF
        areas have been configured.  A single metric is shown per
        outbound interface, indicating that routes will not vary based



Moy                                                            [Page 97]


RFC 1583                     OSPF Version 2                   March 1994


        on TOS.  The calculation of Router RT6's routing table proceeds
        as described in Section 2.1.  The resulting routing table is
        shown in Table 12.  Destination types are abbreviated: Network
        as "N", area border router as "BR" and AS boundary router as
        "ASBR".

        There are no instances of multiple equal-cost shortest paths in
        this example.  Also, since there are no areas, there are no
        inter-area paths.

        Routers RT5 and RT7 are AS boundary routers.  Intra-area routes
        have been calculated to Routers RT5 and RT7.  This allows
        external routes to be calculated to the destinations advertised
        by RT5 and RT7 (i.e., Networks N12, N13, N14 and N15).  It is
        assumed all AS external advertisements originated by RT5 and RT7
        are advertising type 1 external metrics.  This results in type 1
        external paths being calculated to destinations N12-N15.



    11.3.  Sample routing table, with areas

        Consider the previous example, this time split into OSPF areas.
        An OSPF area configuration is pictured in Figure 6.  Router
        RT4's routing table will be described for this area
        configuration.  Router RT4 has a connection to Area 1 and a
        backbone connection.  This causes Router RT4 to view the AS as
        the concatenation of the two graphs shown in Figures 7 and 8.
        The resulting routing table is displayed in Table 13.

        Again, Routers RT5 and RT7 are AS boundary routers.  Routers
        RT3, RT4, RT7, RT10 and RT11 are area border routers.  Note that
        there are two routing table entries (in this case having
        identical paths) for Router RT7, in its dual capacities as an
        area border router and an AS boundary router.  Note also that
        there are two routing entries for the area border router RT3,
        since it has two areas in common with RT4 (Area 1 and the
        backbone).

        Backbone paths have been calculated to all area border routers
        (BR).  These are used when determining the inter-area routes.
        Note that all of the inter-area routes are associated with the
        backbone; this is always the case when the calculating router is
        itself an area border router.  Routing information is condensed
        at area boundaries.  In this example, we assume that Area 3 has
        been defined so that networks N9-N11 and the host route to H1
        are all condensed to a single route when advertised into the
        backbone (by Router RT11).  Note that the cost of this route is



Moy                                                            [Page 98]


RFC 1583                     OSPF Version 2                   March 1994




      Type   Dest   Area   Path  Type    Cost   Next     Adv.
                                                Hop(s)   Router(s)
      ____________________________________________________________
      N      N1     0      intra-area    10     RT3      *
      N      N2     0      intra-area    10     RT3      *
      N      N3     0      intra-area    7      RT3      *
      N      N4     0      intra-area    8      RT3      *
      N      Ib     0      intra-area    7      *        *
      N      Ia     0      intra-area    12     RT10     *
      N      N6     0      intra-area    8      RT10     *
      N      N7     0      intra-area    12     RT10     *
      N      N8     0      intra-area    10     RT10     *
      N      N9     0      intra-area    11     RT10     *
      N      N10    0      intra-area    13     RT10     *
      N      N11    0      intra-area    14     RT10     *
      N      H1     0      intra-area    21     RT10     *
      ASBR   RT5    0      intra-area    6      RT5      *
      ASBR   RT7    0      intra-area    8      RT10     *
      ____________________________________________________________
      N      N12    *      type 1 ext.   10     RT10     RT7
      N      N13    *      type 1 ext.   14     RT5      RT5
      N      N14    *      type 1 ext.   14     RT5      RT5
      N      N15    *      type 1 ext.   17     RT10     RT7


               Table 12: The routing table for Router RT6
                         (no configured areas).

        the minimum of the set of costs to its individual components.

        There is a virtual link configured between Routers RT10 and
        RT11.  Without this configured virtual link, RT11 would be
        unable to advertise a route for networks N9-N11 and Host H1 into
        the backbone, and there would not be an entry for these networks
        in Router RT4's routing table.

        In this example there are two equal-cost paths to Network N12.
        However, they both use the same next hop (Router RT5).



        Router RT4's routing table would improve (i.e., some of the
        paths in the routing table would become shorter) if an
        additional virtual link were configured between Router RT4 and
        Router RT3.  The new virtual link would itself be associated
        with the first entry for area border router RT3 in Table 13 (an



Moy                                                            [Page 99]


RFC 1583                     OSPF Version 2                   March 1994




   Type   Dest        Area   Path  Type    Cost   Next      Adv.
                                                  Hops(s)   Router(s)
   __________________________________________________________________
   N      N1          1      intra-area    4      RT1       *
   N      N2          1      intra-area    4      RT2       *
   N      N3          1      intra-area    1      *         *
   N      N4          1      intra-area    3      RT3       *
   BR     RT3         1      intra-area    1      *         *
   __________________________________________________________________
   N      Ib          0      intra-area    22     RT5       *
   N      Ia          0      intra-area    27     RT5       *
   BR     RT3         0      intra-area    21     RT5       *
   BR     RT7         0      intra-area    14     RT5       *
   BR     RT10        0      intra-area    22     RT5       *
   BR     RT11        0      intra-area    25     RT5       *
   ASBR   RT5         0      intra-area    8      *         *
   ASBR   RT7         0      intra-area    14     RT5       *
   __________________________________________________________________
   N      N6          0      inter-area    15     RT5       RT7
   N      N7          0      inter-area    19     RT5       RT7
   N      N8          0      inter-area    18     RT5       RT7
   N      N9-N11,H1   0      inter-area    26     RT5       RT11
   __________________________________________________________________
   N      N12         *      type 1 ext.   16     RT5       RT5,RT7
   N      N13         *      type 1 ext.   16     RT5       RT5
   N      N14         *      type 1 ext.   16     RT5       RT5
   N      N15         *      type 1 ext.   23     RT5       RT7


                  Table 13: Router RT4's routing table
                       in the presence of areas.

        intra-area path through Area 1).  This would yield a cost of 1
        for the virtual link.  The routing table entries changes that
        would be caused by the addition of this virtual link are shown
        in Table 14.



12.  Link State Advertisements

    Each router in the Autonomous System originates one or more link
    state advertisements.  There are five distinct types of link state
    advertisements, which are described in Section 4.3.  The collection
    of link state advertisements forms the link state or topological
    database.  Each separate type of advertisement has a separate



Moy                                                           [Page 100]


RFC 1583                     OSPF Version 2                   March 1994




    Type   Dest        Area   Path  Type   Cost   Next     Adv.
                                                  Hop(s)   Router(s)
    ________________________________________________________________
    N      Ib          0      intra-area   16     RT3      *
    N      Ia          0      intra-area   21     RT3      *
    BR     RT3         0      intra-area   1      *        *
    BR     RT10        0      intra-area   16     RT3      *
    BR     RT11        0      intra-area   19     RT3      *
    ________________________________________________________________
    N      N9-N11,H1   0      inter-area   20     RT3      RT11


                  Table 14: Changes resulting from an
                        additional virtual link.

    function.  Router links and network links advertisements describe
    how an area's routers and networks are interconnected.  Summary link
    advertisements provide a way of condensing an area's routing
    information.  AS external advertisements provide a way of
    transparently advertising externally-derived routing information
    throughout the Autonomous System.

    Each link state advertisement begins with a standard 20-byte header.
    This link state advertisement header is discussed below.


    12.1.  The Link State Advertisement Header

        The link state advertisement header contains the LS type, Link
        State ID and Advertising Router fields.  The combination of
        these three fields uniquely identifies the link state
        advertisement.

        There may be several instances of an advertisement present in
        the Autonomous System, all at the same time.  It must then be
        determined which instance is more recent.  This determination is
        made by examining the LS sequence, LS checksum and LS age
        fields.  These fields are also contained in the 20-byte link
        state advertisement header.

        Several of the OSPF packet types list link state advertisements.
        When the instance is not important, an advertisement is referred
        to by its LS type, Link State ID and Advertising Router (see
        Link State Request Packets).  Otherwise, the LS sequence number,
        LS age and LS checksum fields must also be referenced.




Moy                                                           [Page 101]


RFC 1583                     OSPF Version 2                   March 1994


        A detailed explanation of the fields contained in the link state
        advertisement header follows.


        12.1.1.  LS age

            This field is the age of the link state advertisement in
            seconds.  It should be processed as an unsigned 16-bit
            integer.  It is set to 0 when the link state advertisement
            is originated.  It must be incremented by InfTransDelay on
            every hop of the flooding procedure.  Link state
            advertisements are also aged as they are held in each
            router's database.

            The age of a link state advertisement is never incremented
            past MaxAge.  Advertisements having age MaxAge are not used
            in the routing table calculation.  When an advertisement's
            age first reaches MaxAge, it is reflooded.  A link state
            advertisement of age MaxAge is finally flushed from the
            database when it is no longer needed to ensure database
            synchronization.  For more information on the aging of link
            state advertisements, consult Section 14.

            The LS age field is examined when a router receives two
            instances of a link state advertisement, both having
            identical LS sequence numbers and LS checksums.  An instance
            of age MaxAge is then always accepted as most recent; this
            allows old advertisements to be flushed quickly from the
            routing domain.  Otherwise, if the ages differ by more than
            MaxAgeDiff, the instance having the smaller age is accepted
            as most recent.[11] See Section 13.1 for more details.


        12.1.2.  Options

            The Options field in the link state advertisement header
            indicates which optional capabilities are associated with
            the advertisement.  OSPF's optional capabilities are
            described in Section 4.5.  There are currently two optional
            capabilities defined; they are represented by the T-bit and
            E-bit found in the Options field.  The rest of the Options
            field should be set to zero.

            The E-bit represents OSPF's ExternalRoutingCapability.  This
            bit should be set in all advertisements associated with the
            backbone, and all advertisements associated with non-stub
            areas (see Section 3.6).  It should also be set in all AS
            external link advertisements.  It should be reset in all



Moy                                                           [Page 102]


RFC 1583                     OSPF Version 2                   March 1994


            router links, network links and summary link advertisements
            associated with a stub area.  For all link state
            advertisements, the setting of the E-bit is for
            informational purposes only; it does not affect the routing
            table calculation.

            The T-bit represents OSPF's TOS routing capability.  This
            bit should be set in a router links advertisement if and
            only if the router is capable of calculating separate routes
            for each IP TOS (see Section 2.4).  The T-bit should always
            be set in network links advertisements.  It should be set in
            summary link and AS external link advertisements if and only
            if the advertisement describes paths for all TOS values,
            instead of just the TOS 0 path.  Note that, with the T-bit
            set, there may still be only a single metric in the
            advertisement (the TOS 0 metric).  This would mean that
            paths for non-zero TOS exist, but are equivalent to the TOS
            0 path.  A link state advertisement's T-bit is examined when
            calculating the routing table's non-zero TOS paths (see
            Section 16.9).


        12.1.3.  LS type

            The LS type field dictates the format and function of the
            link state advertisement.  Advertisements of different types
            have different names (e.g., router links or network links).
            All advertisement types, except the AS external link
            advertisements (LS type = 5), are flooded throughout a
            single area only.  AS external link advertisements are
            flooded throughout the entire Autonomous System, excepting
            stub areas (see Section 3.6).  Each separate advertisement
            type is briefly described below in Table 15.

        12.1.4.  Link State ID

            This field identifies the piece of the routing domain that
            is being described by the advertisement.  Depending on the
            advertisement's LS type, the Link State ID takes on the
            values listed in Table 16.


            Actually, for Type 3 summary link (LS type = 3)
            advertisements and AS external link (LS type = 5)
            advertisements, the Link State ID may additionally have one
            or more of the destination network's "host" bits set. For
            example, when originating an AS external link for the
            network 10.0.0.0 with mask of 255.0.0.0, the Link State ID



Moy                                                           [Page 103]


RFC 1583                     OSPF Version 2                   March 1994




           LS Type   Advertisement description
           __________________________________________________
           1         These are the router links
                     advertisements. They describe the
                     collected states of the router's
                     interfaces. For more information,
                     consult Section 12.4.1.
           __________________________________________________
           2         These are the network links
                     advertisements. They describe the set
                     of routers attached to the network. For
                     more information, consult
                     Section 12.4.2.
           __________________________________________________
           3 or 4    These are the summary link
                     advertisements. They describe
                     inter-area routes, and enable the
                     condensation of routing information at
                     area borders. Originated by area border
                     routers, the Type 3 advertisements
                     describe routes to networks while the
                     Type 4 advertisements describe routes to
                     AS boundary routers.
           __________________________________________________
           5         These are the AS external link
                     advertisements. Originated by AS
                     boundary routers, they describe routes
                     to destinations external to the
                     Autonomous System. A default route for
                     the Autonomous System can also be
                     described by an AS external link
                     advertisement.


               Table 15: OSPF link state advertisements.














Moy                                                           [Page 104]


RFC 1583                     OSPF Version 2                   March 1994


            LS Type   Link State ID
            _______________________________________________
            1         The originating router's Router ID.
            2         The IP interface address of the
                      network's Designated Router.
            3         The destination network's IP address.
            4         The Router ID of the described AS
                      boundary router.
            5         The destination network's IP address.


              Table 16: The advertisement's Link State ID.

            can be set to anything in the range 10.0.0.0 through
            10.255.255.255 inclusive (although 10.0.0.0 should be used
            whenever possible). The freedom to set certain host bits
            allows a router to originate separate advertisements for two
            networks having the same address but different masks. See
            Appendix F for details.

            When the link state advertisement is describing a network
            (LS type = 2, 3 or 5), the network's IP address is easily
            derived by masking the Link State ID with the network/subnet
            mask contained in the body of the link state advertisement.
            When the link state advertisement is describing a router (LS
            type = 1 or 4), the Link State ID is always the described
            router's OSPF Router ID.

            When an AS external advertisement (LS Type = 5) is
            describing a default route, its Link State ID is set to
            DefaultDestination (0.0.0.0).


        12.1.5.  Advertising Router

            This field specifies the OSPF Router ID of the
            advertisement's originator.  For router links
            advertisements, this field is identical to the Link State ID
            field.  Network link advertisements are originated by the
            network's Designated Router.  Summary link advertisements
            are originated by area border routers.  AS external link
            advertisements are originated by AS boundary routers.


        12.1.6.  LS sequence number

            The sequence number field is a signed 32-bit integer.  It is
            used to detect old and duplicate link state advertisements.



Moy                                                           [Page 105]


RFC 1583                     OSPF Version 2                   March 1994


            The space of sequence numbers is linearly ordered.  The
            larger the sequence number (when compared as signed 32-bit
            integers) the more recent the advertisement.  To describe to
            sequence number space more precisely, let N refer in the
            discussion below to the constant 2**31.

            The sequence number -N (0x80000000) is reserved (and
            unused).  This leaves -N + 1 (0x80000001) as the smallest
            (and therefore oldest) sequence number.  A router uses this
            sequence number the first time it originates any link state
            advertisement.  Afterwards, the advertisement's sequence
            number is incremented each time the router originates a new
            instance of the advertisement.  When an attempt is made to
            increment the sequence number past the maximum value of N -
            1 (0x7fffffff), the current instance of the advertisement
            must first be flushed from the routing domain.  This is done
            by prematurely aging the advertisement (see Section 14.1)
            and reflooding it.  As soon as this flood has been
            acknowledged by all adjacent neighbors, a new instance can
            be originated with sequence number of -N + 1 (0x80000001).

            The router may be forced to promote the sequence number of
            one of its advertisements when a more recent instance of the
            advertisement is unexpectedly received during the flooding
            process.  This should be a rare event.  This may indicate
            that an out-of-date advertisement, originated by the router
            itself before its last restart/reload, still exists in the
            Autonomous System.  For more information see Section 13.4.


        12.1.7.  LS checksum

            This field is the checksum of the complete contents of the
            advertisement, excepting the LS age field.  The LS age field
            is excepted so that an advertisement's age can be
            incremented without updating the checksum.  The checksum
            used is the same that is used for ISO connectionless
            datagrams; it is commonly referred to as the Fletcher
            checksum.  It is documented in Annex B of [RFC 905].  The
            link state advertisement header also contains the length of
            the advertisement in bytes; subtracting the size of the LS
            age field (two bytes) yields the amount of data to checksum.

            The checksum is used to detect data corruption of an
            advertisement.  This corruption can occur while an
            advertisement is being flooded, or while it is being held in
            a router's memory.  The LS checksum field cannot take on the
            value of zero; the occurrence of such a value should be



Moy                                                           [Page 106]


RFC 1583                     OSPF Version 2                   March 1994


            considered a checksum failure.  In other words, calculation
            of the checksum is not optional.

            The checksum of a link state advertisement is verified in
            two cases: a) when it is received in a Link State Update
            Packet and b) at times during the aging of the link state
            database.  The detection of a checksum failure leads to
            separate actions in each case.  See Sections 13 and 14 for
            more details.

            Whenever the LS sequence number field indicates that two
            instances of an advertisement are the same, the LS checksum
            field is examined.  If there is a difference, the instance
            with the larger LS checksum is considered to be most
            recent.[12] See Section 13.1 for more details.


    12.2.  The link state database

        A router has a separate link state database for every area to
        which it belongs.  The link state database has been referred to
        elsewhere in the text as the topological database.  All routers
        belonging to the same area have identical topological databases
        for the area.

        The databases for each individual area are always dealt with
        separately.  The shortest path calculation is performed
        separately for each area (see Section 16).  Components of the
        area topological database are flooded throughout the area only.
        Finally, when an adjacency (belonging to Area A) is being
        brought up, only the database for Area A is synchronized between
        the two routers.

        The area database is composed of router links advertisements,
        network links advertisements, and summary link advertisements
        (all listed in the area data structure).  In addition, external
        routes (AS external advertisements) are included in all non-stub
        area databases (see Section 3.6).

        An implementation of OSPF must be able to access individual
        pieces of an area database.  This lookup function is based on an
        advertisement's LS type, Link State ID and Advertising
        Router.[13] There will be a single instance (the most up-to-
        date) of each link state advertisement in the database.  The
        database lookup function is invoked during the link state
        flooding procedure (Section 13) and the routing table
        calculation (Section 16).  In addition, using this lookup
        function the router can determine whether it has itself ever



Moy                                                           [Page 107]


RFC 1583                     OSPF Version 2                   March 1994


        originated a particular link state advertisement, and if so,
        with what LS sequence number.

        A link state advertisement is added to a router's database when
        either a) it is received during the flooding process (Section
        13) or b) it is originated by the router itself (Section 12.4).
        A link state advertisement is deleted from a router's database
        when either a) it has been overwritten by a newer instance
        during the flooding process (Section 13) or b) the router
        originates a newer instance of one of its self-originated
        advertisements (Section 12.4) or c) the advertisement ages out
        and is flushed from the routing domain (Section 14).  Whenever a
        link state advertisement is deleted from the database it must
        also be removed from all neighbors' Link state retransmission
        lists (see Section 10).


    12.3.  Representation of TOS

        All OSPF link state advertisements (with the exception of
        network links advertisements) specify metrics.  In router links
        advertisements, the metrics indicate the costs of the described
        interfaces.  In summary link and AS external link
        advertisements, the metric indicates the cost of the described
        path.  In all of these advertisements, a separate metric can be
        specified for each IP TOS.  The encoding of TOS in OSPF link
        state advertisements is specified in Table 17. That table
        relates the OSPF encoding to the IP packet header's TOS field
        (defined in [RFC 1349]).  The OSPF encoding is expressed as a
        decimal integer, and the IP packet header's TOS field is
        expressed in the binary TOS values used in [RFC 1349].




















Moy                                                           [Page 108]


RFC 1583                     OSPF Version 2                   March 1994



                    OSPF encoding   RFC 1349 TOS values
                    ___________________________________________
                    0               0000 normal service
                    2               0001 minimize monetary cost
                    4               0010 maximize reliability
                    6               0011
                    8               0100 maximize throughput
                    10              0101
                    12              0110
                    14              0111
                    16              1000 minimize delay
                    18              1001
                    20              1010
                    22              1011
                    24              1100
                    26              1101
                    28              1110
                    30              1111


                        Table 17: Representing TOS in OSPF.


        Each OSPF link state advertisement must specify the TOS 0
        metric.  Other TOS metrics, if they appear, must appear in order
        of increasing TOS encoding.  For example, the TOS 8 (maximize
        throughput) metric must always appear before the TOS 16
        (minimize delay) metric when both are specified.  If a metric
        for some non-zero TOS is not specified, its cost defaults to the
        cost for TOS 0, unless the T-bit is reset in the advertisement's
        Options field (see Section 12.1.2 for more details).


    12.4.  Originating link state advertisements

        Into any given OSPF area, a router will originate several link
        state advertisements.  Each router originates a router links
        advertisement.  If the router is also the Designated Router for
        any of the area's networks, it will originate network links
        advertisements for those networks.

        Area border routers originate a single summary link
        advertisement for each known inter-area destination.  AS
        boundary routers originate a single AS external link
        advertisement for each known AS external destination.
        Destinations are advertised one at a time so that the change in
        any single route can be flooded without reflooding the entire



Moy                                                           [Page 109]


RFC 1583                     OSPF Version 2                   March 1994


        collection of routes.  During the flooding procedure, many link
        state advertisements can be carried by a single Link State
        Update packet.

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

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

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


        The ten events that can cause a new instance of a link state
        advertisement to be originated are:


        (1) The LS age field of one of the router's self-originated
            advertisements reaches the value LSRefreshTime. In this
            case, a new instance of the link state advertisement is
            originated, even though the contents of the advertisement
            (apart from the link state advertisement header) will be the
            same.  This guarantees periodic originations of all link
            state advertisements. This periodic updating of link state



Moy                                                           [Page 110]


RFC 1583                     OSPF Version 2                   March 1994


            advertisements adds robustness to the link state algorithm.
            Link state advertisements that solely describe unreachable
            destinations should not be refreshed, but should instead be
            flushed from the routing domain (see Section 14.1).


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


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

        (3) An attached network's Designated Router changes.  A new
            router links advertisement should be originated.  Also, if
            the router itself is now the Designated Router, a new
            network links advertisement should be produced.  If the
            router itself is no longer the Designated Router, any
            network links advertisement that it might have originated
            for the network should be flushed from the routing domain
            (see Section 14.1).

        (4) One of the neighboring routers changes to/from the FULL
            state.  This may mean that it is necessary to produce a new
            instance of the router links advertisement.  Also, if the
            router is itself the Designated Router for the attached
            network, a new network links advertisement should be
            produced.


        The next four events concern area border routers only:


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

        (6) An inter-area route has been added/deleted/modified in the
            routing table.  This may cause a new instance of a summary



Moy                                                           [Page 111]


RFC 1583                     OSPF Version 2                   March 1994


            links advertisement (for this route) to be originated in
            each attached area (but NEVER for the backbone).

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

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


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


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

        (10)
            A router ceases to be an AS boundary router, perhaps after
            restarting. In this situation the router should flush all AS
            external link advertisements that it had previously
            originated.  These advertisements can be flushed via the
            premature aging procedure specified in Section 14.1.


        The construction of each type of link state advertisement is
        explained in detail below.  In general, these sections describe
        the contents of the advertisement body (i.e., the part coming
        after the 20-byte advertisement header).  For information
        concerning the building of the link state advertisement header,
        see Section 12.1.

        12.4.1.  Router links

            A router originates a router links advertisement for each
            area that it belongs to.  Such an advertisement describes
            the collected states of the router's links to the area.  The
            advertisement is flooded throughout the particular area, and
            no further.



Moy                                                           [Page 112]


RFC 1583                     OSPF Version 2                   March 1994



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


                    Figure 15: Area 1 with IP addresses shown

            The format of a router links advertisement is shown in
            Appendix A (Section A.4.2).  The first 20 bytes of the
            advertisement consist of the generic link state
            advertisement header that was discussed in Section 12.1.
            Router links advertisements have LS type = 1.  The router
            indicates whether it is willing to calculate separate routes
            for each IP TOS by setting (or resetting) the T-bit of the
            link state advertisement's Options field.

            A router also indicates whether it is an area border router,
            or an AS boundary router, by setting the appropriate bits
            (bit B and bit E, respectively) in its router links
            advertisements. This enables paths to those types of routers
            to be saved in the routing table, for later processing of
            summary link advertisements and AS external link
            advertisements.  Bit B should be set whenever the router is
            actively attached to two or more areas, even if the router
            is not currently attached to the OSPF backbone area.  Bit E
            should never be set in a router links advertisement for a
            stub area (stub areas cannot contain AS boundary routers).
            In addition, the router sets bit V in its router links



Moy                                                           [Page 113]


RFC 1583                     OSPF Version 2                   March 1994


            advertisement for Area A if and only if it is the endpoint
            of an active virtual link using Area A as its Transit area.
            This enables the other routers attached to Area A to
            discover whether the area supports any virtual links (i.e.,
            is a transit area).

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



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


                           Table 18: Link descriptions in the
                              router links advertisement.


            In addition, the Link Data field is specified for each link.
            This field gives 32 bits of extra information for the link.
            For links to transit networks, numbered links to routers and
            virtual links, this field specifies the IP interface address
            of the associated router interface (thi