Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 1583

OSPF Version 2

Pages: 216
Obsoletes:  1247
Obsoleted by:  2178
Part 9 of 9 – Pages 198 to 216
First   Prev   None

ToP   noToC   RFC1583 - Page 198   prevText
C. Configurable Constants

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

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

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

    C.1 Global parameters

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

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

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

    C.2 Area parameters

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

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

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

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

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

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

            Each area can be configured for a separate type of
            authentication.  See Appendix D for a discussion of the
            defined authentication types.

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

            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.

    C.3 Router interface parameters

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

        IP interface address
            The IP protocol address for this interface.  This uniquely
            identifies the router over the entire internet.  An IP
            address is not required on serial lines.  Such a serial line
            is called "unnumbered".

        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.

        Interface output cost(s)
            The cost of sending a packet on the interface, expressed in
            the link state metric.  This is advertised as the link cost
            for this interface in the router's router links
            advertisement.  There may be a separate cost for each IP
            Type of Service.  The interface output cost(s) must always
            be greater than 0.
ToP   noToC   RFC1583 - Page 201
            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.  This should be
            well over the expected round-trip delay between any two
            routers on the attached network.  The setting of this value
            should be conservative or needless retransmissions will
            result.  It will need to be larger on low speed serial lines
            and virtual links.  Sample value for a local area network: 5

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

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

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

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

        Authentication key
            This configured data allows the authentication procedure to
            generate and/or verify the authentication field in the OSPF
            header.  This value again must be the same for all routers
            attached to a common network.  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.
            There could be a separate password for each network.

    C.4 Virtual link parameters

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

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

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

    C.5 Non-broadcast, multi-access network parameters

        OSPF treats a non-broadcast, multi-access network much like it
        treats a broadcast network.  Since there may be many routers
        attached to the network, a Designated Router is selected for the
ToP   noToC   RFC1583 - Page 203
        network.  This Designated Router then originates a networks
        links advertisement, which lists all routers attached to the
        non-broadcast network.

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

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

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

    C.6 Host route parameters

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

        Host IP address
            The IP address of the host.

        Cost of link to host
            The cost of sending a packet to the host, in terms of the
            link state metric.  There may be multiple costs configured,
            one for each IP TOS.  However, since the host probably has
ToP   noToC   RFC1583 - Page 204
            only a single connection to the internet, the actual
            configured cost(s) in many cases is unimportant (i.e., will
            have no effect on routing).
ToP   noToC   RFC1583 - Page 205
D. Authentication

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

    The authentication type is configurable on a per-area basis.
    Additional authentication data is configurable on a per-interface
    basis.  For example, if an area uses a simple password scheme for
    authentication, a separate password may be configured for each
    network contained in the area.

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

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

                      Table 20: OSPF authentication types.

    D.1 AuType 0 -- No authentication

        Use of this authentication type means that routing exchanges in
        the area are not authenticated.  The 64-bit field in the OSPF
        header can contain anything; it is not examined on packet

    D.2 AuType 1 -- Simple password

        Using this authentication type, a 64-bit field is configured on
        a per-network basis.  All packets sent on a particular network
        must have this configured value in their OSPF header 64-bit
        authentication field.  This essentially serves as a "clear" 64-
        bit password.
ToP   noToC   RFC1583 - Page 206
        This guards against routers inadvertently joining the area.
        They must first be configured with their attached networks'
        passwords before they can participate in the routing domain.
ToP   noToC   RFC1583 - Page 207
E. Differences from RFC 1247

    This section documents the differences between this memo and RFC
    1247.  These differences include a fix for a problem involving OSPF
    virtual links, together with minor enhancements and clarifications
    to the protocol. All differences are backward-compatible.
    Implementations of this memo and of RFC 1247 will interoperate.

    E.1 A fix for a problem with OSPF Virtual links

        In RFC 1247, certain configurations of OSPF virtual links can
        cause routing loops. The root of the problem is that while there
        is an information mismatch at the boundary of any virtual link's
        Transit area, a backbone path can still cross the boundary. RFC
        1247 attempted to compensate for this information mismatch by
        adjusting any backbone path as it enters the transit area (see
        Section 16.3 in RFC 1247). However, this proved not to be
        enough. This memo fixes the problem by having all area border
        routers determine, by looking at summary links, whether better
        backbone paths can be found through the transit areas.

        This fix simplifies the OSPF virtual link logic, and consists of
        the following components:

        o   A new bit has been defined in the router links
            advertisement, called bit V. Bit V is set in a router's
            router links advertisement for Area A if and only if the
            router is an endpoint of an active virtual link that uses
            Area A as its Transit area (see Sections 12.4.1 and A.4.2).
            This enables the other routers attached to Area A to
            discover whether the area supports any virtual links (i.e.,
            is a transit area). This discovery is done during the
            calculation of Area A's shortest-path tree (see Section

        o   To aid in the description of the algorithm, a new parameter
            has been added to the OSPF area structure:
            TransitCapability. This parameter indicates whether the area
            supports any active virtual links. Equivalently, it
            indicates whether the area can carry traffic that neither
            originates nor terminates in the area itself.

        o   The calculation in Section 16.3 of RFC 1247 has been
            replaced. The new calculation, performed by area border
            routers only, examines the summary links belonging to all
            attached transit areas to see whether the transit areas can
            provide better paths than those already found in Sections
            16.1 and 16.2.
ToP   noToC   RFC1583 - Page 208
        o   The incremental calculations in Section 16.5 have been
            updated as a result of the new calculations in Section 16.3.

    E.2 Supporting supernetting and subnet 0

        In RFC 1247, an OSPF router cannot originate separate AS
        external link advertisements (or separate summary link
        advertisements) for two networks that have the same address but
        different masks. This situation can arise when subnet 0 of a
        network has been assigned (a practice that is generally
        discouraged), or when using supernetting as described in [RFC
        1519] (a practice that is generally encouraged to reduce the
        size of routing tables), or even when in transition from one
        mask to another on a subnet.  Using supernetting as an example,
        you might want to aggregate the four class C networks, advertising one route for the aggregation
        and another for the single class C network

        The reason behind this limitation is that in RFC 1247, the Link
        State ID of AS external link advertisements and summary link
        advertisements is set equal to the described network's IP
        address. In the above example, RFC 1247 would assign both
        advertisements the Link State ID of, making them in
        essence the same advertisement. This memo fixes the problem by
        relaxing the setting of the Link State ID so that any of the
        "host" bits of the network address can also be set. This allows
        you to disambiguate advertisements for networks having the same
        address but different masks. Given an AS external link
        advertisement (or a summary link advertisement), the described
        network's address can now be obtained by masking the Link State
        ID with the network mask carried in the body of the
        advertisement.  Again using the above example, the aggregate can
        now be advertised using a Link State ID of and the
        single class C network advertised simultaneously using the Link
        State ID of

        Appendix F gives one possible algorithm for setting one or more
        "host" bits in the Link State ID in order to disambiguate
        advertisements. It should be noted that this is a local
        decision. Each router in an OSPF system is free to use its own
        algorithm, since only those advertisements originated by the
        router itself are affected.

        It is believed that this change will be more or less compatible
        with implementations of RFC 1247. Implementations of RFC 1247
        will probably either a) install routing table entries that won't
        be used or b) do the correct processing as outlined in this memo
        or c) mark the advertisement as unusable when presented with a
ToP   noToC   RFC1583 - Page 209
        Link State ID that has one or more of the host bits set.
        However, in the interest of interoperability, implementations of
        this memo should only set the host bits in Link State IDs when
        absolutely necessary.

        The change affects Sections 12.1.4, 12.4.3, 12.4.5, 16.2, 16.3,
        16.4, 16.5, 16.6, A.4.4 and A.4.5.

    E.3 Obsoleting LSInfinity in router links advertisements

        The metric of LSInfinity can no longer be used in router links
        advertisements to indicate unusable links. This is being done
        for several reasons:

        o   It removes any possible confusion in an OSPF area as to just
            which routers/networks are reachable in the area. For
            example, the above virtual link fix relies on detecting the
            existence of virtual links when running the Dijkstra.
            However, when one-directional links (i.e., cost of
            LSInfinity in one direction, but not the other) are
            possible, some routers may detect the existence of virtual
            links while others may not. This may defeat the fix for the
            virtual link problem.

        o   It also helps OSPF's Multicast routing extensions (MOSPF),
            because one-way reachability can lead to places that are
            reachable via unicast but not multicast, or vice versa.

        The two prior justifications for using LSInfinity in router
        links advertisements were 1) it was a way to not support TOS
        before TOS was optional and 2) it went along with strong TOS
        interpretations. These justifications are no longer valid.
        However, LSInfinity will continue to mean "unreachable" in
        summary link advertisements and AS external link advertisements,
        as some implementations use this as an alternative to the
        premature aging procedure specified in Section 14.1.

        This change has one other side effect. When two routers are
        connected via a virtual link whose underlying path is non-TOS-
        capable, they must now revert to being non-TOS-capable routers
        themselves, instead of the previous behavior of advertising the
        non-zero TOS costs of the virtual link as LSInfinity. See
        Section 15 for details.

    E.4 TOS encoding updated

        The encoding of TOS in OSPF link state advertisements has been
        updated to reflect the new TOS value (minimize monetary cost)
ToP   noToC   RFC1583 - Page 210
        defined by [RFC 1349]. The OSPF encoding is defined in Section
        12.3, which is identical in content to Section A.5 of [RFC

    E.5 Summarizing routes into transit areas

        RFC 1247 mandated that routes associated with Area A are never
        summarized back into Area A. However, this memo further reduces
        the number of summary links originated by refusing to summarize
        into Area A those routes having next hops belonging to Area A.
        This is an optimization over RFC 1247 behavior when virtual
        links are present.  For example, in the area configuration of
        Figure 6, Router RT11 need only originate a single summary link
        having the (collapsed) destination N9-N11,H1 into its connected
        transit area Area 2, since all of its other eligible routes have
        next hops belonging to Area 2 (and as such only need be
        advertised by other area border routers; in this case, Routers
        RT10 and RT7). This is the logical equivalent of a Distance
        Vector protocol's split horizon logic.

        This change appears in Section 12.4.3.

    E.6 Summarizing routes into stub areas

        RFC 1247 mandated that area border routers attached to stub
        areas must summarize all inter-area routes into the stub areas.
        However, while area border routers connected to OSPF stub areas
        must originate default summary links into the stub area, they
        need not summarize other routes into the stub area. The amount
        of summarization done into stub areas can instead be put under
        configuration control. The network administrator can then make
        the trade-off between optimal routing and database size.

        This change appears in Sections 12.4.3 and 12.4.4.

    E.7 Flushing anomalous network links advertisements

        Text was added indicating that a network links advertisement
        whose Link State ID is equal to one of the router's own IP
        interface addresses should be considered to be self-originated,
        regardless of the setting of the advertisement's Advertising
        Router. If the Advertising Router of such an advertisement is
        not equal to the router's own Router ID, the advertisement
        should be flushed from the routing domain using the premature
        aging procedure specified in Section 14.1. This case should be
        rare, and it indicates that the router's Router ID has changed
        since originating the advertisement.
ToP   noToC   RFC1583 - Page 211
        Failure to flush these anomalous advertisements could lead to
        multiple network links advertisements having the same Link State
        ID. This in turn could cause the Dijkstra calculation in Section
        16.1 to fail, since it would be impossible to tell which network
        links advertisement is valid (i.e., more recent).

        This change appears in Sections 13.4 and 14.1.

    E.8 Required Statistics appendix deleted

        Appendix D of RFC 1247, which specified a list of required
        statistics for an OSPF implementation, has been deleted. That
        appendix has been superseded by the two documents: the OSPF
        Version 2 Management Information Base and the OSPF Version 2

    E.9 Other changes

        The following small changes were also made to RFC 1247:

        o   When representing unnumbered point-to-point networks in
            router links advertisements, the corresponding Link Data
            field should be set to the unnumbered interface's MIB-II
            [RFC 1213] ifIndex value.

        o   A comment was added to Step 3 of the Dijkstra algorithm in
            Section 16.1. When removing vertices from the candidate
            list, and when there is a choice of vertices closest to the
            root, network vertices must be chosen before router vertices
            in order to necessarily find all equal-cost paths.

        o   A comment was added to Section 12.4.3 noting that a summary
            link advertisement cannot express a reachable destination
            whose path cost equals or exceeds LSInfinity.

        o   A comment was added to Section 15 noting that a virtual link
            whose underlying path has cost greater than hexadecimal
            0xffff (the maximum size of an interface cost in a router
            links advertisement) should be considered inoperational.

        o   An option was added to the definition of area address
            ranges, allowing the network administrator to specify that a
            particular range should not be advertised to other OSPF
            areas. This enables the existence of certain networks to be
            hidden from other areas. This change appears in Sections
            12.4.3 and C.2.
ToP   noToC   RFC1583 - Page 212
        o   A note was added reminding implementors that bit E (the AS
            boundary router indication) should never be set in a router
            links advertisement for a stub area, since stub areas cannot
            contain AS boundary routers.  This change appears in Section
ToP   noToC   RFC1583 - Page 213
F. An algorithm for assigning Link State IDs

    In RFC 1247, the Link State ID in AS external link advertisements
    and summary link advertisements is set to the described network's IP
    address. This memo relaxes that requirement, allowing one or more of
    the network's host bits to be set in the Link State ID. This allows
    the router to originate separate advertisements for networks having
    the same addresses, yet different masks. Such networks can occur in
    the presence of supernetting and subnet 0s (see Section E.2 for more

    This appendix gives one possible algorithm for setting the host bits
    in Link State IDs.  The choice of such an algorithm is a local
    decision. Separate routers are free to use different algorithms,
    since the only advertisements affected are the ones that the router
    itself originates. The only requirement on the algorithms used is
    that the network's IP address should be used as the Link State ID
    (the RFC 1247 behavior) whenever possible.

    The algorithm below is stated for AS external link advertisements.
    This is only for clarity; the exact same algorithm can be used for
    summary link advertisements. Suppose that the router wishes to
    originate an AS external link advertisement for a network having
    address NA and mask NM1. The following steps are then used to
    determine the advertisement's Link State ID:

    (1) Determine whether the router is already originating an AS
        external link advertisement with Link State ID equal to NA (in
        such an advertisement the router itself will be listed as the
        advertisement's Advertising Router).  If not, set the Link State
        ID equal to NA (the RFC 1247 behavior) and the algorithm
        terminates. Otherwise,

    (2) Obtain the network mask from the body of the already existing AS
        external link advertisement. Call this mask NM2. There are then
        two cases:

        o   NM1 is longer (i.e., more specific) than NM2. In this case,
            set the Link State ID in the new advertisement to be the
            network [NA,NM1] with all the host bits set (i.e., equal to
            NA or'ed together with all the bits that are not set in NM1,
            which is network [NA,NM1]'s broadcast address).

        o   NM2 is longer than NM1. In this case, change the existing
            advertisement (having Link State ID of NA) to reference the
            new network [NA,NM1] by incrementing the sequence number,
            changing the mask in the body to NM1 and using the cost for
            the new network. Then originate a new advertisement for the
ToP   noToC   RFC1583 - Page 214
            old network [NA,NM2], with Link State ID equal to NA or'ed
            together with the bits that are not set in NM2 (i.e.,
            network [NA,NM2]'s broadcast address).

    The above algorithm assumes that all masks are contiguous; this
    ensures that when two networks have the same address, one mask is
    more specific than the other. The algorithm also assumes that no
    network exists having an address equal to another network's
    broadcast address. Given these two assumptions, the above algorithm
    always produces unique Link State IDs. The above algorithm can also
    be reworded as follows: When originating an AS external link state
    advertisement, try to use the network number as the Link State ID.
    If that produces a conflict, examine the two networks in conflict.
    One will be a subset of the other. For the less specific network,
    use the network number as the Link State ID and for the more
    specific use the network's broadcast address instead (i.e., flip all
    the "host" bits to 1).  If the most specific network was originated
    first, this will cause you to originate two link state
    advertisements at once.

    As an example of the algorithm, consider its operation when the
    following sequence of events occurs in a single router (Router A).

    (1) Router A wants to originate an AS external link advertisement
        for [,]:

        (a) A Link State ID of is used.

    (2) Router A then wants to originate an AS external link
        advertisement for [,]:

        (a) The advertisement for [10.0.0,0,] is
            reoriginated using a new Link State ID of

        (b) A Link State ID of is used for

    (3) Router A then wants to originate an AS external link
        advertisement for [,]:

        (a) The advertisement for [,] is reoriginated
            using a new Link State ID of

        (b) A Link State ID of is used for
ToP   noToC   RFC1583 - Page 215
        (c) The network [,] keeps its Link State ID
ToP   noToC   RFC1583 - Page 216
Security Considerations

    All OSPF protocol exchanges are authenticated. This is accomplished
    through authentication fields contained in the OSPF packet header.
    For more information, see Sections 8.1, 8.2, and Appendix D.

Author's Address

    John Moy
    Proteon, Inc.
    9 Technology Drive
    Westborough, MA 01581

    Phone: 508-898-2800
    Fax:   508-898-3176