Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2328

OSPF Version 2

Pages: 244
Internet Standard: 54
Errata
Obsoletes:  2178
Updated by:  57096549684568607474804293559454
Part 8 of 8 – Pages 203 to 244
First   Prev   None

Top   ToC   RFC2328 - Page 203   prevText
A.4 LSA formats

    This memo defines five distinct types of LSAs.  Each LSA begins with
    a standard 20 byte LSA header.  This header is explained in Section
    A.4.1.  Succeeding sections then diagram the separate LSA types.

    Each LSA describes a piece of the OSPF routing domain.  Every router
    originates a router-LSA.  In addition, whenever the router is
    elected Designated Router, it originates a network-LSA.  Other types
    of LSAs may also be originated (see Section 12.4).  All LSAs are
    then flooded throughout the OSPF routing domain.  The flooding
    algorithm is reliable, ensuring that all routers have the same
    collection of LSAs.  (See Section 13 for more information concerning
    the flooding algorithm).  This collection of LSAs is called the
    link-state database.

    From the link state database, each router constructs a shortest path
    tree with itself as root.  This yields a routing table (see Section
    11).  For the details of the routing table build process, see
    Section 16.
Top   ToC   RFC2328 - Page 204
A.4.1 The LSA header

    All LSAs begin with a common 20 byte header.  This header contains
    enough information to uniquely identify the LSA (LS type, Link State
    ID, and Advertising Router).  Multiple instances of the LSA may
    exist in the routing domain at the same time.  It is then necessary
    to determine which instance is more recent.  This is accomplished by
    examining the LS age, LS sequence number and LS checksum fields that
    are also contained in the LSA header.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |    Options    |    LS type    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



    LS age
        The time in seconds since the LSA was originated.

    Options
        The optional capabilities supported by the described portion of
        the routing domain.  OSPF's optional capabilities are documented
        in Section A.2.

    LS type
        The type of the LSA.  Each LSA type has a separate advertisement
        format.  The LSA types defined in this memo are as follows (see
        Section 12.1.3 for further explanation):
Top   ToC   RFC2328 - Page 205
                        LS Type   Description
                        ___________________________________
                        1         Router-LSAs
                        2         Network-LSAs
                        3         Summary-LSAs (IP network)
                        4         Summary-LSAs (ASBR)
                        5         AS-external-LSAs




    Link State ID
        This field identifies the portion of the internet environment
        that is being described by the LSA.  The contents of this field
        depend on the LSA's LS type.  For example, in network-LSAs the
        Link State ID is set to the IP interface address of the
        network's Designated Router (from which the network's IP address
        can be derived).  The Link State ID is further discussed in
        Section 12.1.4.

    Advertising Router
        The Router ID of the router that originated the LSA.  For
        example, in network-LSAs this field is equal to the Router ID of
        the network's Designated Router.

    LS sequence number
        Detects old or duplicate LSAs.  Successive instances of an LSA
        are given successive LS sequence numbers.  See Section 12.1.6
        for more details.

    LS checksum
        The Fletcher checksum of the complete contents of the LSA,
        including the LSA header but excluding the LS age field. See
        Section 12.1.7 for more details.

    length
        The length in bytes of the LSA.  This includes the 20 byte LSA
        header.
Top   ToC   RFC2328 - Page 206
A.4.2 Router-LSAs

    Router-LSAs are the Type 1 LSAs.  Each router in an area originates
    a router-LSA.  The LSA describes the state and cost of the router's
    links (i.e., interfaces) to the area.  All of the router's links to
    the area must be described in a single router-LSA.  For details
    concerning the construction of router-LSAs, see Section 12.4.1.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |     Options   |       1       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    0    |V|E|B|        0      |            # links            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Link ID                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Link Data                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |     # TOS     |            metric             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      TOS      |        0      |          TOS  metric          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Link ID                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Link Data                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
Top   ToC   RFC2328 - Page 207
    In router-LSAs, the Link State ID field is set to the router's OSPF
    Router ID. Router-LSAs are flooded throughout a single area only.

    bit V
        When set, the router is an endpoint of one or more fully
        adjacent virtual links having the described area as Transit area
        (V is for virtual link endpoint).

    bit E
        When set, the router is an AS boundary router (E is for
        external).

    bit B
        When set, the router is an area border router (B is for border).

    # links
        The number of router links described in this LSA.  This must be
        the total collection of router links (i.e., interfaces) to the
        area.


    The following fields are used to describe each router link (i.e.,
    interface). Each router link is typed (see the below Type field).
    The Type field indicates the kind of link being described.  It may
    be a link to a transit network, to another router or to a stub
    network.  The values of all the other fields describing a router
    link depend on the link's Type.  For example, each link has an
    associated 32-bit Link Data field.  For links to stub networks this
    field specifies the network's IP address mask.  For other link types
    the Link Data field specifies the router interface's IP address.


    Type
        A quick description of the router link.  One of the following.
        Note that host routes are classified as links to stub networks
        with network mask of 0xffffffff.
Top   ToC   RFC2328 - Page 208
                 Type   Description
                 __________________________________________________
                 1      Point-to-point connection to another router
                 2      Connection to a transit network
                 3      Connection to a stub network
                 4      Virtual link




    Link ID
        Identifies the object that this router link connects to.  Value
        depends on the link's Type.  When connecting to an object that
        also originates an LSA (i.e., another router or a transit
        network) the Link ID is equal to the neighboring LSA's Link
        State ID.  This provides the key for looking up the neighboring
        LSA in the link state database during the routing table
        calculation. See Section 12.2 for more details.



                       Type   Link ID
                       ______________________________________
                       1      Neighboring router's Router ID
                       2      IP address of Designated Router
                       3      IP network/subnet number
                       4      Neighboring router's Router ID




    Link Data
        Value again depends on the link's Type field. For connections to
        stub networks, Link Data specifies the network's IP address
        mask. For unnumbered point-to-point connections, it specifies
        the interface's MIB-II [Ref8] ifIndex value. For the other link
        types it specifies the router interface's IP address. This
        latter piece of information is needed during the routing table
        build process, when calculating the IP address of the next hop.
        See Section 16.1.1 for more details.
Top   ToC   RFC2328 - Page 209
    # TOS
        The number of different TOS metrics given for this link, not
        counting the required link metric (referred to as the TOS 0
        metric in [Ref9]).  For example, if no additional TOS metrics
        are given, this field is set to 0.

    metric
        The cost of using this router link.


    Additional TOS-specific information may also be included, for
    backward compatibility with previous versions of the OSPF
    specification ([Ref9]). Within each link, and for each desired TOS,
    TOS TOS-specific link information may be encoded as follows:

    TOS IP Type of Service that this metric refers to.  The encoding of
        TOS in OSPF LSAs is described in Section 12.3.

    TOS metric
        TOS-specific metric information.
Top   ToC   RFC2328 - Page 210
A.4.3 Network-LSAs

    Network-LSAs are the Type 2 LSAs.  A network-LSA is originated for
    each broadcast and NBMA network in the area which supports two or
    more routers.  The network-LSA is originated by the network's
    Designated Router.  The LSA describes all routers attached to the
    network, including the Designated Router itself.  The LSA's Link
    State ID field lists the IP interface address of the Designated
    Router.

    The distance from the network to all attached routers is zero.  This
    is why metric fields need not be specified in the network-LSA.  For
    details concerning the construction of network-LSAs, see Section
    12.4.2.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |      Options  |      2        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Network Mask                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Attached Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |



    Network Mask
        The IP address mask for the network.  For example, a class A
        network would have the mask 0xff000000.
Top   ToC   RFC2328 - Page 211
    Attached Router
        The Router IDs of each of the routers attached to the network.
        Actually, only those routers that are fully adjacent to the
        Designated Router are listed.  The Designated Router includes
        itself in this list.  The number of routers included can be
        deduced from the LSA header's length field.
Top   ToC   RFC2328 - Page 212
A.4.4 Summary-LSAs

    Summary-LSAs are the Type 3 and 4 LSAs.  These LSAs are originated
    by area border routers. Summary-LSAs describe inter-area
    destinations.  For details concerning the construction of summary-
    LSAs, see Section 12.4.3.

    Type 3 summary-LSAs are used when the destination is an IP network.
    In this case the LSA's Link State ID field is an IP network number
    (if necessary, the Link State ID can also have one or more of the
    network's "host" bits set; see Appendix E for details). When the
    destination is an AS boundary router, a Type 4 summary-LSA is used,
    and the Link State ID field is the AS boundary router's OSPF Router
    ID.  (To see why it is necessary to advertise the location of each
    ASBR, consult Section 16.4.)  Other than the difference in the Link
    State ID field, the format of Type 3 and 4 summary-LSAs is
    identical.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |     Options   |    3 or 4     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Network Mask                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      0        |                  metric                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     TOS       |                TOS  metric                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
Top   ToC   RFC2328 - Page 213
    For stub areas, Type 3 summary-LSAs can also be used to describe a
    (per-area) default route.  Default summary routes are used in stub
    areas instead of flooding a complete set of external routes.  When
    describing a default summary route, the summary-LSA's Link State ID
    is always set to DefaultDestination (0.0.0.0) and the Network Mask
    is set to 0.0.0.0.

    Network Mask
        For Type 3 summary-LSAs, this indicates the destination
        network's IP address mask.  For example, when advertising the
        location of a class A network the value 0xff000000 would be
        used.  This field is not meaningful and must be zero for Type 4
        summary-LSAs.

    metric
        The cost of this route.  Expressed in the same units as the
        interface costs in the router-LSAs.

    Additional TOS-specific information may also be included, for
    backward compatibility with previous versions of the OSPF
    specification ([Ref9]). For each desired TOS, TOS-specific
    information is encoded as follows:

    TOS IP Type of Service that this metric refers to.  The encoding of
        TOS in OSPF LSAs is described in Section 12.3.

    TOS metric
        TOS-specific metric information.
Top   ToC   RFC2328 - Page 214
A.4.5 AS-external-LSAs

    AS-external-LSAs are the Type 5 LSAs.  These LSAs are originated by
    AS boundary routers, and describe destinations external to the AS.
    For details concerning the construction of AS-external-LSAs, see
    Section 12.4.3.

    AS-external-LSAs usually describe a particular external destination.
    For these LSAs the Link State ID field specifies an IP network
    number (if necessary, the Link State ID can also have one or more of
    the network's "host" bits set; see Appendix E for details).  AS-
    external-LSAs are also used to describe a default route.  Default
    routes are used when no specific route exists to the destination.
    When describing a default route, the Link State ID is always set to
    DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |     Options   |      5        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Network Mask                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |E|     0       |                  metric                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Forwarding address                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      External Route Tag                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |E|    TOS      |                TOS  metric                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Forwarding address                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC2328 - Page 215
       |                      External Route Tag                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |



    Network Mask
        The IP address mask for the advertised destination.  For
        example, when advertising a class A network the mask 0xff000000
        would be used.

    bit E
        The type of external metric.  If bit E is set, the metric
        specified is a Type 2 external metric.  This means the metric is
        considered larger than any link state path.  If bit E is zero,
        the specified metric is a Type 1 external metric.  This means
        that it is expressed in the same units as the link state metric
        (i.e., the same units as interface cost).

    metric
        The cost of this route.  Interpretation depends on the external
        type indication (bit E above).

    Forwarding address
        Data traffic for the advertised destination will be forwarded to
        this address.  If the Forwarding address is set to 0.0.0.0, data
        traffic will be forwarded instead to the LSA's originator (i.e.,
        the responsible AS boundary router).

    External Route Tag
        A 32-bit field attached to each external route.  This is not
        used by the OSPF protocol itself.  It may be used to communicate
        information between AS boundary routers; the precise nature of
        such information is outside the scope of this specification.

    Additional TOS-specific information may also be included, for
    backward compatibility with previous versions of the OSPF
    specification ([Ref9]). For each desired TOS, TOS-specific
    information is encoded as follows:

    TOS The Type of Service that the following fields concern.  The
        encoding of TOS in OSPF LSAs is described in Section 12.3.
Top   ToC   RFC2328 - Page 216
    bit E
        For backward-compatibility with [Ref9].

    TOS metric
        TOS-specific metric information.

    Forwarding address
        For backward-compatibility with [Ref9].

    External Route Tag
        For backward-compatibility with [Ref9].
Top   ToC   RFC2328 - Page 217
B. Architectural Constants

    Several OSPF protocol parameters have fixed architectural values.
    These parameters have been referred to in the text by names such as
    LSRefreshTime.  The same naming convention is used for the
    configurable protocol parameters.  They are defined in Appendix C.

    The name of each architectural constant follows, together with its
    value and a short description of its function.


    LSRefreshTime
        The maximum time between distinct originations of any particular
        LSA.  If the LS age field of one of the router's self-originated
        LSAs reaches the value LSRefreshTime, a new instance of the LSA
        is originated, even though the contents of the LSA (apart from
        the LSA header) will be the same.  The value of LSRefreshTime is
        set to 30 minutes.

    MinLSInterval
        The minimum time between distinct originations of any particular
        LSA.  The value of MinLSInterval is set to 5 seconds.

    MinLSArrival
        For any particular LSA, the minimum time that must elapse
        between reception of new LSA instances during flooding. LSA
        instances received at higher frequencies are discarded. The
        value of MinLSArrival is set to 1 second.

    MaxAge
        The maximum age that an LSA can attain. When an LSA's LS age
        field reaches MaxAge, it is reflooded in an attempt to flush the
        LSA from the routing domain (See Section 14). LSAs of age MaxAge
        are not used in the routing table calculation.  The value of
        MaxAge is set to 1 hour.

    CheckAge
        When the age of an LSA in the link state database hits a
        multiple of CheckAge, the LSA's checksum is verified.  An
        incorrect checksum at this time indicates a serious error.  The
        value of CheckAge is set to 5 minutes.
Top   ToC   RFC2328 - Page 218
    MaxAgeDiff
        The maximum time dispersion that can occur, as an LSA is flooded
        throughout the AS.  Most of this time is accounted for by the
        LSAs sitting on router output queues (and therefore not aging)
        during the flooding process.  The value of MaxAgeDiff is set to
        15 minutes.

    LSInfinity
        The metric value indicating that the destination described by an
        LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as
        an alternative to premature aging (see Section 14.1). It is
        defined to be the 24-bit binary value of all ones: 0xffffff.

    DefaultDestination
        The Destination ID that indicates the default route.  This route
        is used when no other matching routing table entry can be found.
        The default destination can only be advertised in AS-external-
        LSAs and in stub areas' type 3 summary-LSAs.  Its value is the
        IP address 0.0.0.0. Its associated Network Mask is also always
        0.0.0.0.

    InitialSequenceNumber
        The value used for LS Sequence Number when originating the first
        instance of any LSA. Its value is the signed 32-bit integer
        0x80000001.

    MaxSequenceNumber
        The maximum value that LS Sequence Number can attain.  Its value
        is the signed 32-bit integer 0x7fffffff.
Top   ToC   RFC2328 - Page 219
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 LSAs from the routing domain (see Section
            14.1), or they will persist for up to MaxAge minutes.

        RFC1583Compatibility
            Controls the preference rules used in Section 16.4 when
            choosing among multiple AS-external-LSAs advertising the
            same destination. When set to "enabled", the preference
            rules remain those specified by RFC 1583 ([Ref9]). When set
            to "disabled", the preference rules are those stated in
Top   ToC   RFC2328 - Page 220
            Section 16.4.1, which prevent routing loops when AS-
            external-LSAs for the same destination have been originated
            from different areas. Set to "enabled" by default.

            In order to minimize the chance of routing loops, all OSPF
            routers in an OSPF routing domain should have
            RFC1583Compatibility set identically. When there are routers
            present that have not been updated with the functionality
            specified in Section 16.4.1 of this memo, all routers should
            have RFC1583Compatibility set to "enabled". Otherwise, all
            routers should have RFC1583Compatibility set to "disabled",
            preventing all routing loops.

    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
        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 0.0.0.0 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.
Top   ToC   RFC2328 - Page 221
            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-LSA) 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
            network.

        ExternalRoutingCapability
            Whether AS-external-LSAs will be flooded into/throughout the
            area.  If AS-external-LSAs are 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.

        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-
            LSA that the router should advertise into the area.

    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:
Top   ToC   RFC2328 - Page 222
        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 point-to-point networks.  Such a
            point-to-point network is called "unnumbered".

        IP interface mask
            Also referred to as the subnet/network 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 OSPF area to which the attached network belongs.

        Interface output cost
            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-LSA. The interface
            output cost must always be greater than 0.

        RxmtInterval
            The number of seconds between LSA 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.  Sample value for a local area
            network: 5 seconds.

        InfTransDelay
            The estimated number of seconds it takes to transmit a Link
            State Update Packet over this interface.  LSAs 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
Top   ToC   RFC2328 - Page 223
            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 broadcast and NBMA networks.

        HelloInterval
            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; however, 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.

        RouterDeadInterval
            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
            network.

        AuType
            Identifies the authentication procedure to be used on the
            attached network.  This value must be the same for all
            routers attached to the network.  See Appendix D for a
            discussion of the defined authentication types.

        Authentication key
            This configured data allows the authentication procedure to
            verify OSPF protocol packets received over the interface.
            For example, if the AuType indicates simple password, the
Top   ToC   RFC2328 - Page 224
            Authentication key would be a clear 64-bit password.
            Authentication keys associated with the other OSPF
            authentication types are discussed in Appendix D.

    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-LSAs (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 NBMA network parameters

        OSPF treats an NBMA 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 network.  This
        Designated Router then originates a network-LSA, which lists all
        routers attached to the NBMA network.
Top   ToC   RFC2328 - Page 225
        However, due to the lack of broadcast capabilities, it may be
        necessary to use configuration parameters in the Designated
        Router selection.  These parameters will only need to 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), and then only if no
        automatic procedure for discovering neighbors exists:


        List of all other attached routers
            The list of all other routers attached to the NBMA 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 NBMA 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.

        PollInterval
            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
            minutes.

    C.6 Point-to-MultiPoint network parameters

        On Point-to-MultiPoint networks, it may be necessary to
        configure the set of neighbors that are directly reachable over
        the Point-to-MultiPoint network. Each neighbor is identified by
        its IP address on the Point-to-MultiPoint network. Designated
        Routers are not elected on Point-to-MultiPoint networks, so the
        Designated Router eligibility of configured neighbors is
        undefined.

        Alternatively, neighbors on Point-to-MultiPoint networks may be
        dynamically discovered by lower-level protocols such as Inverse
        ARP ([Ref14]).
Top   ToC   RFC2328 - Page 226
    C.7 Host route parameters

        Host routes are advertised in router-LSAs 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.  However, since the host probably has
            only a single connection to the internet, the actual
            configured cost in many cases is unimportant (i.e., will
            have no effect on routing).

        Area ID
            The OSPF area to which the host belongs.
Top   ToC   RFC2328 - Page 227
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-interface (or
    equivalently, on a per-network/subnet) basis.  Additional
    authentication data is also configurable on a per-interface basis.

    Authentication types 0, 1 and 2 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            Null authentication
                  1            Simple password
                  2            Cryptographic authentication
                  All others   Reserved for assignment by the
                               IANA (iana@ISI.EDU)


                      Table 20: OSPF authentication types.



    D.1 Null authentication

        Use of this authentication type means that routing exchanges
        over the network/subnet are not authenticated.  The 64-bit
        authentication field in the OSPF header can contain anything; it
        is not examined on packet reception. When employing Null
        authentication, the entire contents of each OSPF packet (other
        than the 64-bit authentication field) are checksummed in order
        to detect data corruption.
Top   ToC   RFC2328 - Page 228
    D.2 Simple password authentication

        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. In addition, the entire contents of each OSPF
        packet (other than the 64-bit authentication field) are
        checksummed in order to detect data corruption.

        Simple password authentication guards against routers
        inadvertently joining the routing domain; each router must first
        be configured with its attached networks' passwords before it
        can participate in routing.  However, simple password
        authentication is vulnerable to passive attacks currently
        widespread in the Internet (see [Ref16]). Anyone with physical
        access to the network can learn the password and compromise the
        security of the OSPF routing domain.

    D.3 Cryptographic authentication

        Using this authentication type, a shared secret key is
        configured in all routers attached to a common network/subnet.
        For each OSPF protocol packet, the key is used to
        generate/verify a "message digest" that is appended to the end
        of the OSPF packet. The message digest is a one-way function of
        the OSPF protocol packet and the secret key. Since the secret
        key is never sent over the network in the clear, protection is
        provided against passive attacks.

        The algorithms used to generate and verify the message digest
        are specified implicitly by the secret key. This specification
        completely defines the use of OSPF Cryptographic authentication
        when the MD5 algorithm is used.

        In addition, a non-decreasing sequence number is included in
        each OSPF protocol packet to protect against replay attacks.
        This provides long term protection; however, it is still
        possible to replay an OSPF packet until the sequence number
        changes. To implement this feature, each neighbor data structure
        contains a new field called the "cryptographic sequence number".
        This field is initialized to zero, and is also set to zero
Top   ToC   RFC2328 - Page 229
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              0                |    Key ID     | Auth Data Len |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Cryptographic sequence number                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 18: Usage of the Authentication field
                   in the OSPF packet header when Cryptographic
                          Authentication is employed

        whenever the neighbor's state transitions to "Down". Whenever an
        OSPF packet is accepted as authentic, the cryptographic sequence
        number is set to the received packet's sequence number.

        This specification does not provide a rollover procedure for the
        cryptographic sequence number. When the cryptographic sequence
        number that the router is sending hits the maximum value, the
        router should reset the cryptographic sequence number that it is
        sending back to 0. After this is done, the router's neighbors
        will reject the router's OSPF packets for a period of
        RouterDeadInterval, and then the router will be forced to
        reestablish all adjacencies over the interface. However, it is
        expected that many implementations will use "seconds since
        reboot" (or "seconds since 1960", etc.) as the cryptographic
        sequence number. Such a choice will essentially prevent
        rollover, since the cryptographic sequence number field is 32
        bits in length.

        The OSPF Cryptographic authentication option does not provide
        confidentiality.

        When cryptographic authentication is used, the 64-bit
        Authentication field in the standard OSPF packet header is
        redefined as shown in Figure 18. The new field definitions are
        as follows:
Top   ToC   RFC2328 - Page 230
        Key ID
            This field identifies the algorithm and secret key used to
            create the message digest appended to the OSPF packet. Key
            Identifiers are unique per-interface (or equivalently, per-
            subnet).

        Auth Data Len
            The length in bytes of the message digest appended to the
            OSPF packet.

        Cryptographic sequence number
            An unsigned 32-bit non-decreasing sequence number. Used to
            guard against replay attacks.

        The message digest appended to the OSPF packet is not actually
        considered part of the OSPF protocol packet: the message digest
        is not included in the OSPF header's packet length, although it
        is included in the packet's IP header length field.

        Each key is identified by the combination of interface and Key
        ID. An interface may have multiple keys active at any one time.
        This enables smooth transition from one key to another. Each key
        has four time constants associated with it. These time constants
        can be expressed in terms of a time-of-day clock, or in terms of
        a router's local clock (e.g., number of seconds since last
        reboot):

        KeyStartAccept
            The time that the router will start accepting packets that
            have been created with the given key.

        KeyStartGenerate
            The time that the router will start using the key for packet
            generation.

        KeyStopGenerate
            The time that the router will stop using the key for packet
            generation.

        KeyStopAccept
            The time that the router will stop accepting packets that
            have been created with the given key.
Top   ToC   RFC2328 - Page 231
        In order to achieve smooth key transition, KeyStartAccept should
        be less than KeyStartGenerate and KeyStopGenerate should be less
        than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are
        left unspecified, the key's lifetime is infinite. When a new key
        replaces an old, the KeyStartGenerate time for the new key must
        be less than or equal to the KeyStopGenerate time of the old
        key.

        Key storage should persist across a system restart, warm or
        cold, to avoid operational issues. In the event that the last
        key associated with an interface expires, it is unacceptable to
        revert to an unauthenticated condition, and not advisable to
        disrupt routing.  Therefore, the router should send a "last
        authentication key expiration" notification to the network
        manager and treat the key as having an infinite lifetime until
        the lifetime is extended, the key is deleted by network
        management, or a new key is configured.

    D.4 Message generation

        After building the contents of an OSPF packet, the
        authentication procedure indicated by the sending interface's
        Autype value is called before the packet is sent. The
        authentication procedure modifies the OSPF packet as follows.

        D.4.1 Generating Null authentication

            When using Null authentication, the packet is modified as
            follows:

            (1) The Autype field in the standard OSPF header is set to
                0.

            (2) The checksum field in the standard OSPF header is set to
                the standard IP checksum of the entire contents of the
                packet, starting with the OSPF packet header but
                excluding the 64-bit authentication field.  This
                checksum is calculated as the 16-bit one's complement of
                the one's complement sum of all the 16-bit words in the
                packet, excepting the authentication field.  If the
Top   ToC   RFC2328 - Page 232
                packet's length is not an integral number of 16-bit
                words, the packet is padded with a byte of zero before
                checksumming.

        D.4.2 Generating Simple password authentication

            When using Simple password authentication, the packet is
            modified as follows:

            (1) The Autype field in the standard OSPF header is set to
                1.

            (2) The checksum field in the standard OSPF header is set to
                the standard IP checksum of the entire contents of the
                packet, starting with the OSPF packet header but
                excluding the 64-bit authentication field.  This
                checksum is calculated as the 16-bit one's complement of
                the one's complement sum of all the 16-bit words in the
                packet, excepting the authentication field.  If the
                packet's length is not an integral number of 16-bit
                words, the packet is padded with a byte of zero before
                checksumming.

            (3) The 64-bit authentication field in the OSPF packet
                header is set to the 64-bit password (i.e.,
                authentication key) that has been configured for the
                interface.

        D.4.3 Generating Cryptographic authentication

            When using Cryptographic authentication, there may be
            multiple keys configured for the interface. In this case,
            among the keys that are valid for message generation (i.e,
            that have KeyStartGenerate <= current time <
            KeyStopGenerate) choose the one with the most recent
            KeyStartGenerate time. Using this key, modify the packet as
            follows:

            (1) The Autype field in the standard OSPF header is set to
                2.
Top   ToC   RFC2328 - Page 233
            (2) The checksum field in the standard OSPF header is not
                calculated, but is instead set to 0.

            (3) The Key ID (see Figure 18) is set to the chosen key's
                Key ID.

            (4) The Auth Data Len field is set to the length in bytes of
                the message digest that will be appended to the OSPF
                packet. When using MD5 as the authentication algorithm,
                Auth Data Len will be 16.

            (5) The 32-bit Cryptographic sequence number (see Figure 18)
                is set to a non-decreasing value (i.e., a value at least
                as large as the last value sent out the interface). The
                precise values to use in the cryptographic sequence
                number field are implementation-specific. For example,
                it may be based on a simple counter, or be based on the
                system's clock.

            (6) The message digest is then calculated and appended to
                the OSPF packet.  The authentication algorithm to be
                used in calculating the digest is indicated by the key
                itself.  Input to the authentication algorithm consists
                of the OSPF packet and the secret key. When using MD5 as
                the authentication algorithm, the message digest
                calculation proceeds as follows:

                (a) The 16 byte MD5 key is appended to the OSPF packet.

                (b) Trailing pad and length fields are added, as
                    specified in [Ref17].

                (c) The MD5 authentication algorithm is run over the
                    concatenation of the OSPF packet, secret key, pad
                    and length fields, producing a 16 byte message
                    digest (see [Ref17]).

                (d) The MD5 digest is written over the OSPF key (i.e.,
                    appended to the original OSPF packet). The digest is
                    not counted in the OSPF packet's length field, but
Top   ToC   RFC2328 - Page 234
                    is included in the packet's IP length field. Any
                    trailing pad or length fields beyond the digest are
                    not counted or transmitted.

    D.5 Message verification

        When an OSPF packet has been received on an interface, it must
        be authenticated. The authentication procedure is indicated by
        the setting of Autype in the standard OSPF packet header, which
        matches the setting of Autype for the receiving OSPF interface.

        If an OSPF protocol packet is accepted as authentic, processing
        of the packet continues as specified in Section 8.2. Packets
        which fail authentication are discarded.

        D.5.1 Verifying Null authentication

            When using Null authentication, the checksum field in the
            OSPF header must be verified. It must be set to the 16-bit
            one's complement of the one's complement sum of all the 16-
            bit words in the packet, excepting the authentication field.
            (If the packet's length is not an integral number of 16-bit
            words, the packet is padded with a byte of zero before
            checksumming.)

        D.5.2 Verifying Simple password authentication

            When using Simple password authentication, the received OSPF
            packet is authenticated as follows:

            (1) The checksum field in the OSPF header must be verified.
                It must be set to the 16-bit one's complement of the
                one's complement sum of all the 16-bit words in the
                packet, excepting the authentication field.  (If the
                packet's length is not an integral number of 16-bit
                words, the packet is padded with a byte of zero before
                checksumming.)

            (2) The 64-bit authentication field in the OSPF packet
                header must be equal to the 64-bit password (i.e.,
                authentication key) that has been configured for the
                interface.
Top   ToC   RFC2328 - Page 235
        D.5.3 Verifying Cryptographic authentication

            When using Cryptographic authentication, the received OSPF
            packet is authenticated as follows:

            (1) Locate the receiving interface's configured key having
                Key ID equal to that specified in the received OSPF
                packet (see Figure 18). If the key is not found, or if
                the key is not valid for reception (i.e., current time <
                KeyStartAccept or current time >= KeyStopAccept), the
                OSPF packet is discarded.

            (2) If the cryptographic sequence number found in the OSPF
                header (see Figure 18) is less than the cryptographic
                sequence number recorded in the sending neighbor's data
                structure, the OSPF packet is discarded.

            (3) Verify the appended message digest in the following
                steps:

                (a) The received digest is set aside.

                (b) A new digest is calculated, as specified in Step 6
                    of Section D.4.3.

                (c) The calculated and received digests are compared. If
                    they do not match, the OSPF packet is discarded. If
                    they do match, the OSPF protocol packet is accepted
                    as authentic, and the "cryptographic sequence
                    number" in the neighbor's data structure is set to
                    the sequence number found in the packet's OSPF
                    header.
Top   ToC   RFC2328 - Page 236
E. An algorithm for assigning Link State IDs

    The Link State ID in AS-external-LSAs and summary-LSAs is usually
    set to the described network's IP address. However, if necessary one
    or more of the network's host bits may be set in the Link State ID.
    This allows the router to originate separate LSAs for networks
    having the same address, yet different masks. Such networks can
    occur in the presence of supernetting and subnet 0s (see [Ref10]).

    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 LSAs 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 whenever
    possible; this maximizes interoperability with OSPF implementations
    predating RFC 1583.

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

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

    (2) Obtain the network mask from the body of the already existing
        AS-external-LSA. 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 LSA 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
            LSA (having Link State ID of NA) to reference the new
            network [NA,NM1] by incrementing the sequence number,
Top   ToC   RFC2328 - Page 237
            changing the mask in the body to NM1 and inserting the cost
            of the new network. Then originate a new LSA for the 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-LSA, 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 LSAs 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-LSA for
        [10.0.0.0,255.255.255.0]:

        (a) A Link State ID of 10.0.0.0 is used.

    (2) Router A then wants to originate an AS-external-LSA for
        [10.0.0.0,255.255.0.0]:

        (a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a
            new Link State ID of 10.0.0.255.

        (b) A Link State ID of 10.0.0.0 is used for
            [10.0.0.0,255.255.0.0].

    (3) Router A then wants to originate an AS-external-LSA for
        [10.0.0.0,255.0.0.0]:
Top   ToC   RFC2328 - Page 238
        (a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a
            new Link State ID of 10.0.255.255.

        (b) A Link State ID of 10.0.0.0 is used for
            [10.0.0.0,255.0.0.0].

        (c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID
            of 10.0.0.255.
Top   ToC   RFC2328 - Page 239
F. Multiple interfaces to the same network/subnet

    There are at least two ways to support multiple physical interfaces
    to the same IP subnet. Both methods will interoperate with
    implementations of RFC 1583 (and of course this memo). The two
    methods are sketched briefly below. An assumption has been made that
    each interface has been assigned a separate IP address (otherwise,
    support for multiple interfaces is more of a link-level or ARP issue
    than an OSPF issue).

    Method 1:
        Run the entire OSPF functionality over both interfaces, sending
        and receiving hellos, flooding, supporting separate interface
        and neighbor FSMs for each interface, etc. When doing this all
        other routers on the subnet will treat the two interfaces as
        separate neighbors, since neighbors are identified (on broadcast
        and NBMA networks) by their IP address.

        Method 1 has the following disadvantages:

        (1) You increase the total number of neighbors and adjacencies.

        (2) You lose the bidirectionality test on both interfaces, since
            bidirectionality is based on Router ID.

        (3) You have to consider both interfaces together during the
            Designated Router election, since if you declare both to be
            DR simultaneously you can confuse the tie-breaker (which is
            Router ID).

    Method 2:
        Run OSPF over only one interface (call it the primary
        interface), but include both the primary and secondary
        interfaces in your Router-LSA.

        Method 2 has the following disadvantages:

        (1) You lose the bidirectionality test on the secondary
            interface.

        (2) When the primary interface fails, you need to promote the
            secondary interface to primary status.
Top   ToC   RFC2328 - Page 240
G. Differences from RFC 2178

    This section documents the differences between this memo and RFC
    2178.  All differences are backward-compatible. Implementations of
    this memo and of RFCs 2178, 1583, and 1247 will interoperate.

    G.1 Flooding modifications

        Three changes have been made to the flooding procedure in
        Section 13.

        The first change is to step 4 in Section 13. Now MaxAge LSAs are
        acknowledged and then discarded only when both a) there is no
        database copy of the LSA and b) none of router's neighbors are
        in states Exchange or Loading. In all other cases, the MaxAge
        LSA is processed like any other LSA, installing the LSA in the
        database and flooding it out the appropriate interfaces when the
        LSA is more recent than the database copy (Step 5 of Section
        13). This change also affects the contents of Table 19.

        The second change is to step 5a in Section 13. The MinLSArrival
        check is meant only for LSAs received during flooding, and
        should not be performed on those LSAs that the router itself
        originates.

        The third change is to step 8 in Section 13. Confusion between
        routers as to which LSA instance is more recent can cause a
        disastrous amount of flooding in a link-state protocol (see
        [Ref26]). OSPF guards against this problem in two ways: a) the
        LS age field is used like a TTL field in flooding, to eventually
        remove looping LSAs from the network (see Section 13.3), and b)
        routers refuse to accept LSA updates more frequently than once
        every MinLSArrival seconds (see Section 13).  However, there is
        still one case in RFC 2178 where disagreements regarding which
        LSA is more recent can cause a lot of flooding traffic:
        responding to old LSAs by reflooding the database copy.  For
        this reason, Step 8 of Section 13 has been amended to only
        respond with the database copy when that copy has not been sent
        in any Link State Update within the last MinLSArrival seconds.
Top   ToC   RFC2328 - Page 241
    G.2 Changes to external path preferences

        There is still the possibility of a routing loop in RFC 2178
        when both a) virtual links are in use and b) the same external
        route is being imported by multiple ASBRs, each of which is in a
        separate area. To fix this problem, Section 16.4.1 has been
        revised. To choose the correct ASBR/forwarding address, intra-
        area paths through non-backbone areas are always preferred.
        However, intra-area paths through the backbone area (Area 0) and
        inter-area paths are now of equal preference, and must be
        compared solely based on cost.

        The reasoning behind this change is as follows. When virtual
        links are in use, an intra-area backbone path for one router can
        turn into an inter-area path in a router several hops closer to
        the destination. Hence, intra-area backbone paths and inter-area
        paths must be of equal preference. We can safely compare their
        costs, preferring the path with the smallest cost, due to the
        calculations in Section 16.3.

        Thanks to Michael Briggs and Jeremy McCooey of the UNH
        InterOperability Lab for pointing out this problem.

    G.3 Incomplete resolution of virtual next hops

        One of the functions of the calculation in Section 16.3 is to
        determine the actual next hop(s) for those destinations whose
        next hop was calculated as a virtual link in Sections 16.1 and
        16.2.  After completion of the calculation in Section 16.3, any
        paths calculated in Sections 16.1 and 16.2 that still have
        unresolved virtual next hops should be discarded.

    G.4 Routing table lookup

        The routing table lookup algorithm in Section 11.1 has been
        modified to reflect current practice. The "best match" routing
        table entry is now always selected to be the one providing the
        most specific (longest) match. Suppose for example a router is
        forwarding packets to the destination 192.9.1.1. A routing table
        entry for 192.9.1/24 will always be a better match than the
        routing table entry for 192.9/16, regardless of the routing
        table entries' path-types. Note however that when multiple paths
Top   ToC   RFC2328 - Page 242
        are available for a given routing table entry, the calculations
        in Sections 16.1, 16.2, and 16.4 always yield the paths having
        the most preferential path-type. (Intra-area paths are the most
        preferred, followed in order by inter-area, type 1 external and
        type 2 external paths; see Section 11).
Top   ToC   RFC2328 - Page 243
Security Considerations

    All OSPF protocol exchanges are authenticated. OSPF supports
    multiple types of authentication; the type of authentication in use
    can be configured on a per network segment basis. One of OSPF's
    authentication types, namely the Cryptographic authentication
    option, is believed to be secure against passive attacks and provide
    significant protection against active attacks. When using the
    Cryptographic authentication option, each router appends a "message
    digest" to its transmitted OSPF packets. Receivers then use the
    shared secret key and received digest to verify that each received
    OSPF packet is authentic.

    The quality of the security provided by the Cryptographic
    authentication option depends completely on the strength of the
    message digest algorithm (MD5 is currently the only message digest
    algorithm specified), the strength of the key being used, and the
    correct implementation of the security mechanism in all
    communicating OSPF implementations.  It also requires that all
    parties maintain the secrecy of the shared secret key.

    None of the OSPF authentication types provide confidentiality. Nor
    do they protect against traffic analysis. Key management is also not
    addressed by this memo.

    For more information, see Sections 8.1, 8.2, and Appendix D.

Author's Address

    John Moy
    Ascend Communications, Inc.
    1 Robbins Road
    Westford, MA 01886

    Phone: 978-952-1367
    Fax:   978-392-2075
    EMail: jmoy@casc.com
Top   ToC   RFC2328 - Page 244
Full Copyright Statement

    Copyright (C) The Internet Society (1998).  All Rights Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph
    are included on all such copies and derivative works.  However, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for
    copyrights defined in the Internet Standards process must be
    followed, or as required to translate it into languages other than
    English.

    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assigns.

    This document and the information contained herein is provided on an
    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.