Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1583

OSPF Version 2

Pages: 216
Obsoletes:  1247
Obsoleted by:  2178
Part 1 of 9 – Pages 1 to 21
None   None   Next

ToP   noToC   RFC1583 - Page 1
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.
ToP   noToC   RFC1583 - Page 2
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
ToP   noToC   RFC1583 - Page 3
    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
ToP   noToC   RFC1583 - Page 4
    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
ToP   noToC   RFC1583 - Page 5
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
ToP   noToC   RFC1583 - Page 6
        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.
ToP   noToC   RFC1583 - Page 7
        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
ToP   noToC   RFC1583 - Page 8
            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.
ToP   noToC   RFC1583 - Page 9
    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
ToP   noToC   RFC1583 - Page 10
        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.
ToP   noToC   RFC1583 - Page 11
    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
ToP   noToC   RFC1583 - Page 12
                                                  **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.
ToP   noToC   RFC1583 - Page 13
    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
ToP   noToC   RFC1583 - Page 14
                 +
                 | 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
ToP   noToC   RFC1583 - Page 15
                                **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.
ToP   noToC   RFC1583 - Page 16
                     **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
ToP   noToC   RFC1583 - Page 17
                                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
ToP   noToC   RFC1583 - Page 18
                   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.
ToP   noToC   RFC1583 - Page 19
        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
ToP   noToC   RFC1583 - Page 20
        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
ToP   noToC   RFC1583 - Page 21
        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).




(page 21 continued on part 2)

Next Section