Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1247

OSPF Version 2

Pages: 189
Obsoletes:  1131
Obsoleted by:  1583
Updated by:  1349
Part 7 of 7 – Pages 166 to 189
First   Prev   None

ToP   noToC   RFC1247 - Page 166   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.

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 traffic.  The following items
must be configured for an area:
ToP   noToC   RFC1247 - Page 167
Area ID
    This is a 32-bit number that identifies the area.  The Area ID of 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 [IP address, mask] pairs.  Each
    pair describes a range of IP addresses.  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.  Routing information is condensed at area
    boundaries.  External to the area, a single route is advertised for
    each address range.

    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 internet mask.  A single route would
    be advertised external to the area, describing the entire subnetted
    network.

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

External routing capability
    Whether AS external advertisements will be flooded into/throughout
    the area.  If AS external advertisements 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 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.
ToP   noToC   RFC1247 - Page 168
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
    This  denotes  the  portion  of  the  IP  interface  address  that
    identifies  the  attached  network.   This  is  often  referred  to
    as  the subnet  mask.

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.

RxmtInterval
    The number of seconds between link state advertisement
    retransmissions, for adjacencies belonging to this interface.  Also
    used when retransmitting Database Description and Link State Request
    Packets.  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 seconds.

InfTransDelay
    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 for 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
ToP   noToC   RFC1247 - Page 169
    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.

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 hello interval, the
    faster topological changes will be detected, but more routing
    traffic will ensue.  Sample value for a X.25 PDN network: 30
    seconds.  Sample value for a local area network: 10 seconds.

RouterDeadInterval
    The number of seconds that a router's Hellos have not been seen
    before its neighbors declare the router down.  This is also
    advertised in the router's Hello Packets in the DeadInt 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.

Authentication key
    This configured data allows the authentication procedure to generate
    and/or verify the authentication field in the OSPF header.  For
    example, if the authentication type 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 protocol packets it sends along the
ToP   noToC   RFC1247 - Page 170
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 many be many routers attached to the
network, a Designated Router is selected for the 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 DR
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.

PollInterval
    If a neighboring router has become inactive (hellos have not been
    seen for RouterDeadInterval seconds), it may still be necessary to
    send Hellos to the dead neighbor.  These Hellos 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.
ToP   noToC   RFC1247 - Page 171
C.6 Host route parameters

Host routes are advertised in network 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 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   RFC1247 - Page 172
D. Required Statistics

An OSPF implementation must provide a minimum set of statistics
indicating the operational state of the protocol.  These statistics must
be accessible to the user; this will probably be accomplished through
some sort of network management interface.

It is hoped that these statistics will aid in the debugging of the
implementation, and in the analysis of the protocol's performance.

The statistics can be broken into two broad categories.  The first
consists of what we will call logging messages.  These are messages
produced in real time, with generally a single message produced as the
result of a single protocol event.  Such messages are also commonly
referred to as traps.

The second category will be referred to as cumulative statistics.  These
are counters whose value have collected over time, such as the count of
link state retransmissions over the last hour.  Also falling into this
category are dumps of the various routing data structures.


D.1 Logging messages

A logging message should be produced on every significant protocol
event.  The major events are listed below.  Most of these events
indicate a topological change in the routing domain.  However, some
number of logging messages can be expected even when the routing domain
remains intact for long periods of time.  For example, link state
originations will still happen due to the link state refresh timer
firing.

Any of the messages that refer to link state advertisements should print
the area associated with the advertisement.  There is no area associated
with AS external link advertisements.

The following list of logging messages indicate topological changes in
the routing domain:


T1  The state of a router interface changes.  Interface state changes
    are documented in Section 9.3.  In general, they will cause new link
    state advertisements to be originated.  The logging message produced
    should include the interface's IP address (or other name), interface
    type (virtual link, etc.)  and old and new state values (as
    documented in Section 9.1).
ToP   noToC   RFC1247 - Page 173
T2  The state of a neighbor changes.  Neighbor state changes are
    documented in Section 10.3.  The logging message produced should
    include the neighbor IP address, and old and new state values.

T3  The (Backup) Designated Router has changed on one of the attached
    networks.  See Section 9.4.  The logging message produced should
    include the network IP address, and the old and new (Backup)
    Designated Routers.

T4  The router is originating a new instance of a link state
    advertisement.  The logging message produced should indicate the LS
    type, Link State ID and Advertising Router associated with the
    advertisement (see Section 12.4).

T5  The router has received a new instance of a link state
    advertisement.  The router receives these in Link State Update
    packets.  This will cause recalculation of the routing table.  The
    logging message produced should indicate the advertisement's LS
    type, Link State ID and Advertising Router.  The message should also
    include the neighbor from whom the advertisement was received.

T6  An entry in the routing table has changed (see Section 11).  The
    logging message produced should indicate the Destination type,
    Destination ID, and the old and new paths to the destination.


The following logging messages may indicate that there is a network
configuration error:


C1  A received OSPF packet is rejected due to errors in its IP/OSPF
    header.  The reasons for rejection are documented in Section 8.2.
    They include OSPF checksum failure, authentication failure, and
    inability to match the source with an active OSPF neighbor.  The
    logging message produced should include the IP source and
    destination addresses, the router ID in the OSPF header, and the
    reason for the rejection.

C2  An incoming Hello packet is rejected due to mismatches between the
    Hello's parameters and those configured for the receiving interface
    (see Section 10.5).  This indicates a configuration problem on the
    attached network.  The logging message should include the Hello's
    source, the receiving interface, and the non-matching parameters.

C3  An incoming Database Description packet, Link State Request Packet,
    Link State Acknowledgment Packet or Link State Update packet is
    rejected due to the source neighbor being in the wrong state (see
    Sections 10.6, 10.7, 13.7 , and 13 respectively).  This can be
ToP   noToC   RFC1247 - Page 174
    normal when the identity of the network's Designated Router changes,
    causing momentary disagreements over the validity of adjacencies.
    The logging message should include the source neighbor, its state,
    and the packet's type.

C4  A Database Description packet has been retransmitted.  This may mean
    that the value of RxmtInterval that has been configured for the
    associated interface is too small.  The logging message should
    include the neighbor to whom the packet is being sent.


The following messages can be caused by packet transmission errors, or
software errors in an OSPF implementation:


E1  The checksum in a received link state advertisement is incorrect.
    The advertisement is discarded (see Section 13).  The logging
    message should include the advertisement's LS type, Link State ID
    and Advertising Router (which may be incorrect).  The message should
    also include the neighbor from whom the advertisement was received.

E2  During the aging process, it is discovered that one of the link
    state advertisements in the database has an incorrect checksum.
    This indicates memory corruption or a software error in the router
    itself.  The router should be dumped and restarted.


The following messages are an indication that a router has restarted,
losing track of its previous LS sequence number.  Should these messages
continue, it may indicate the presence of duplicate Router IDs:


R1  Two link state advertisements have been seen, whose LS type, Link
    State ID, Advertising Router and LS sequence number are the same,
    yet with differing LS checksums.  These are considered to be
    different instances of the same advertisement.  The instance with
    the larger checksum is accepted as more recent (see Section 12.1.7,
    13.1).  The logging message should include the LS type, Link State
    ID, Advertising Router, LS sequence number and the two differing
    checksums.

R2  Two link state advertisements have been seen, whose LS type, Link
    State ID, Advertising Router, LS sequence number and LS checksum are
    the same, yet can be distinguished by their LS age fields.  This
    means that one of the advertisement's LS age is MaxAge, or the two
    LS age fields differ by more than MaxAgeDiff.  The logging message
    should include the LS type, Link State ID, Advertising Router, LS
    sequence number and the two differing ages.
ToP   noToC   RFC1247 - Page 175
R3  The router has received an instance of one of its self-originated
    advertisements, that is considered to be more recent.  This forces
    the router to originate a new advertisement (see Section 13.4).  The
    logging message should include the advertisement's LS type, Link
    State ID, and Advertising Router along with the neighbor from whom
    the advertisement was received.

R4  An acknowledgment has been received for an instance of an
    advertisement that is not currently contained in the router's
    database (see Section 13.7).  The logging message should detail the
    instance being acknowledged and the database copy (if any), along
    with the neighbor from whom the acknowledgment was received.

R5  An advertisement has been received through the flooding procedure
    that is LESS recent the the router's current database copy (see
    Section 13).  The logging message should include the received
    advertisement's LS type, Link State ID, Advertising Router, LS
    sequence number, LS age and LS checksum.  Also, the message should
    display the neighbor from whom the advertisement was received.


The following messages are indication of normal, yet infrequent protocol
events.  These messages will help in the interpretation of some of the
above messages:


N1  The Link state refresh timer has fired for one of the router's
    self-originated advertisements (see Section 12.4).  A new instance
    of the advertisement must be originated.  The message should include
    the advertisement's LS type, Link State ID and Advertising Router.

N2  One of the advertisements in the router's link state database has
    aged to MaxAge (see Section 14).  At this point, the advertisement
    is no longer included in the routing table calculation, and is
    reflooded.  The message should list the advertisement's LS type,
    Link State ID and Advertising Router.

N3  An advertisement of age MaxAge has been flushed from the router's
    database.  This occurs after the advertisement has been acknowledged
    by all adjacent neighbors.  The message should list the
    advertisement's LS type, Link State ID and Advertising Router.


D.2 Cumulative statistics

These statistics display collections of the routing data structures.
They should be able to be obtained interactively, through some kind of
network management facility.
ToP   noToC   RFC1247 - Page 176
All the following statistics displays, with the exception of the area
list, routing table and the AS external links, are specific to a single
area.  As noted in Section 4, most OSPF protocol mechanisms work on each
area separately.

The following statistics displays should be available:


(1) A list of all the areas attached to the router, along with the
    authentication type to use for the area, the number of router
    interfaces attaching to the area, and the total number of nets and
    routers belonging to the area.

    For example, consider the router RT3 pictured in Figure 15.  It has
    interfaces to two separate areas, Area 1 and the backbone (Area 0).
    Table 20 then indicates that the backbone is using a simple password
    for authentication, and that Area 1 is not using any authentication.
    The number of nets includes IP networks, subnets, and hosts (this is
    the reason for 2 backbone nets -- they are the host routes
    corresponding to the serial line between backbone routers RT6 and
    RT10).



                 Area ID   # ifcs   AuType   # nets   # routers
                 ______________________________________________
                 0         1        1        2        7
                 1         2        0        4        4


                      Table 20: Sample OSPF area display.



(2) A list of all the router's interfaces to an area, along with their
    addresses, output cost, current state, the (Backup) Designated
    Router for the attached network, and the number of neighbors
    currently associated with the interface.  Some number of these
    neighbors will have become adjacent, the number of these is noted in
    the display also.

    Again consider router RT3 in Figure 15.  Table 21 below indicates
    that RT4 has been selected as Designated Router for network N3, and
    router RT1 has been selected as Backup.  Adjacencies have been
    established to both of these routers.  There are no routers besides
    RT3 attached to network N4, so it becomes DR, yet still advertises
    the network as a stub in its router links advertisements.
ToP   noToC   RFC1247 - Page 177
   Ifc IP address   state      cost   DR          Backup      # nbrs   # adjs
   __________________________________________________________________________
   192.1.1.3        DR other   1      192.1.1.4   192.1.1.1   3        2
   192.1.4.3        DR         2      192.1.4.3   none        0        0


                    Table 21: Sample OSPF interface display.



(3) The list of neighbors associated with a particular interface.  Each
    neighbor's IP address, router ID, state, and the length of the three
    link state advertisement queues (see Section 10) to the neighbor is
    displayed.

    Suppose router RT4 is the Designated Router for network N3, and
    router RT1 is the Backup Designated router.  Suppose also that the
    adjacency between router RT3 and RT1 has not yet fully formed.  The
    display of router RT3's neighbors (associated with its interface to
    network N3) may then look like Table 22.  The display indicates that
    RT3 and RT1 are still in the database exchange procedure, Router RT3
    has more Database Description packets to send to RT1, and RT1 has at
    least one link state advertisement that RT3 doesn't.  Also, there is
    a single link state advertisement that has been flooded, but not
    acknowledged, to each neighbor that participates in the flooding
    procedure (state >= Exchng).  (In the following examples we assume
    that a router's Router ID is assigned to be its smallest IP
    interface address).



  Nbr IP address   Router ID   state    LS rxmt len   DB summ len   LS req len
  ____________________________________________________________________________
  192.1.1.1        192.1.1.1   Exchng   1             10            1
  192.1.1.2        192.1.1.2   2-Way    0             0             0
  192.1.1.4        192.1.1.4   Full     1             0             0


                    Table 22: Sample OSPF neighbor display.



(4) A list of the area's link state database.  This is the same in all
    of the routers attached to the area.  It is composed of that area's
    router links, network links, and summary links advertisements.
    Also, the AS external link advertisements are a part of all the
    areas' databases.
ToP   noToC   RFC1247 - Page 178
    The link state database for Area 1 in Figure 15 might look like
    Table 23 (compare this with Figure 7).  Assume the the Designated
    Router for network N3 is router RT4, as above.  Both routers RT3 and
    RT4 are originating summary link advertisements into Area 1, since
    they are area border routers.  Routers RT5 and RT7 are AS external
    routers.  Their location must be described in summary links
    advertisements.  Also, their AS external link advertisements are
    flooded throughout the entire AS.

    Router RT3 can locate its self-originated advertisements by looking
    for its own router ID (192.1.1.3) in advertisements' Advertising
    Router fields.

    The LS sequence number, LS age, and LS checksum fields indicate the
    advertisement's instance.  Their values are stored in the
    advertisement's link state header; we have not bothered to make up
    values for the example.


LS type   Link State ID   Advertising Router   LS seq no   LS age   LS checksum
_______________________________________________________________________________
1         192.1.1.1       192.1.1.1            *           *        *
1         192.1.1.2       192.1.1.2            *           *        *
1         192.1.1.3       192.1.1.3            *           *        *
1         192.1.1.4       192.1.1.4            *           *        *
_______________________________________________________________________________
2         192.1.1.4       192.1.1.4            *           *        *
_______________________________________________________________________________
3         Ia,Ib           192.1.1.3            *           *        *
3         N6              192.1.1.3            *           *        *
3         N7              192.1.1.3            *           *        *
3         N8              192.1.1.3            *           *        *
3         N9-N11,H1       192.1.1.3            *           *        *
3         Ia,Ib           192.1.1.4            *           *        *
3         N6              192.1.1.4            *           *        *
3         N7              192.1.1.4            *           *        *
3         N8              192.1.1.4            *           *        *
3         N9-N11,H1       192.1.1.4            *           *        *
4         RT5             192.1.1.3            *           *        *
4         RT7             192.1.1.3            *           *        *
4         RT5             192.1.1.4            *           *        *
4         RT7             192.1.1.4            *           *        *
_______________________________________________________________________________
4         N12             RT5's ID             *           *        *
4         N13             RT5's ID             *           *        *
4         N14             RT5's ID             *           *        *
4         N12             RT7's ID             *           *        *
ToP   noToC   RFC1247 - Page 179
LS type   Link State ID   Advertising Router   LS seq no   LS age   LS checksum
_______________________________________________________________________________
4         N15             RT7's ID             *           *        *


             Table 23: Sample OSPF link state database display.


(5) The contents of any particular link state advertisement.  For
    example, a listing of the router links advertisement for Area 1,
    with LS type = 1 and Link State ID = 192.1.1.3 is shown in Section
    12.4.1.

(6) A listing of the entire routing table.  Several examples are shown
    in Section 11.  The routing table is calculated from the combined
    databases of each attached area (see Section 16).  It may be
    desirable to sort the routing table by Type of Service, or by
    destination, or a combination of the two.
ToP   noToC   RFC1247 - Page 180
E. 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 24.



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


                    Table 24: OSPF authentication types.



E.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 reception.


E.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.

This guards against routers inadvertently coming up in the area.  They
must first be configured with their attached networks' passwords before
they can join the routing domain.
ToP   noToC   RFC1247 - Page 181
F. Version 1 differences

This section documents the changes between OSPF version 1 and OSPF
version 2.  The impetus for these changes derives from comments received
on RFC 1131 and recent field experience with the OSPF protocol.
Unfortunately, the changes are not backward-compatible.  For that
reason, OSPF version 1 will not interoperate with OSPF version 2.
However, the changes are small in scope and should not greatly affect
any existing implementations.  In addition, some of the proposed changes
should enable future protocol additions to be made in a backward-
compatible manner (see Section F.4).


F.1 Protocol Enhancements

The following enhancements were made to the OSPF protocol.


F.1.1 Stub area support

In many Autonomous Systems, the majority of the OSPF link state database
consists of AS external advertisements.  In these Autonomous Systems,
some OSPF areas may be organized in such a way that external
advertisements can be safely ignored, enabling a reduction of the area's
database size.  This applies to OSPF areas where there is only a single
exit/entry that is used by all externally addressed packets, or to cases
where some sub-optimality of external routing is acceptable.

Therefore, an OSPF area configuration option has been added (see
Sections 3.6 and C.2) allowing the import of external advertisements to
be disabled for an area.  When this option is enabled, no AS external
advertisements will be flooded into the area (Sections 13, 13.3 and
10.3).  Instead, within the area all data traffic to external
destinations will follow a (per-area) default route.  These areas are
called "stub" areas.

To implement this, all area border routers attached to stub areas will
originate a default summary link advertisement for the area (Section
12.4.3).  This will direct all internal routers to an area border router
when forwarding externally addressed packets.  In addition, to ensure
that stub areas are configured consistently, an Options field has been
added to OSPF Hello packets (Sections A.2 and A.3.2).  A bit is reset in
the Options field indicating that the attached area is a stub area
(Section 9.5).  A router will not accept a neighbor's hellos unless they
both agree on the area's ability to process AS external advertisements
(Section 10.5).  In this way, a system administrator will be able to
discover incorrectly configured routers, and data traffic will be routed
around them (in order to avoid potential looping situations) until their
ToP   noToC   RFC1247 - Page 182
configuration can be repaired.


F.1.2 Optional TOS support

In OSPF there is conceptually a separate routing table for each TOS; the
calculations detailed in steps 1-5 of Section 16 must be done separately
for each TOS.  (Note however that link and summary costs need not be
specified separately for each TOS; costs for unspecified TOS values
default to the cost of TOS 0).

In version 1 of the OSPF specification, all OSPF routers were required
to route based on TOS.  However, producing a separate routing table for
each TOS may prove costly, both in terms of memory and processor
resources.  For this reason, version 2 allows the system administrator
to configure routers to calculate/use only a single routing table (the
TOS 0 table).  When this is done, some traffic may take non-optimal
routes.  But all packets will still be delivered, and routing will
remain loop free (see Section 2.4).

In order to avoid routing loops, a router (router X) using a single
table must communicate this information to its peers.  This is done by
resetting the new TOS-capable bit in the router X's router links
advertisement (Section 12.4.1).  Then, when its peers perform the
Dijkstra calculation (Section 16.1) for non-zero TOS values, they will
omit router X from the calculation.  In effect, an attempt will be made
to bypass router X when forwarding non-zero TOS traffic.  Summary link
and AS external link advertisements can also indicate their non-
availability for non-zero TOS traffic (Sections 12.4.3 and 12.4.4).

The result may be that no route can be found for some non-zero value of
TOS.  When this happens, the packet is routed along the TOS 0 route
instead (Section 11.1).

It is still mandatory for all OSPF implementations to be able to
construct separate routing tables for each TOS value, if desired by the
system administrator.


F.1.3 Preventing external extra-hops

In some cases, version 1 of the OSPF specification will introduce
extra-hops when calculating routes to external destinations.  This is
because it is implicit in the format of AS external advertisements that
packets should be forwarded through the advertising router.  However,
consider the situation where multiple OSPF routers share a LAN with an
external router (call it router Y) , and only one OSPF router (call it
router X) exchanges routing information with Y.  The OSPF routers on the
ToP   noToC   RFC1247 - Page 183
LAN other than X will forward packets destined for Y and beyond through
X, generating an extra hop (see Section 2.2).

To fix this, a new field has been added to AS external advertisements.
This field (called the forwarding address) will indicate the router
address to which packets should be forwarded (Section 12.4.4).  In the
above example, router X will put Y's IP address into this field.  If the
field is 0, packets are (as before) forwarded to the originator of the
advertisement.  A different forwarding address can be specified for each
TOS value.

Whenever possible, this new field should be set to 0.  This is because
setting it to an actual router address incurs additional cost during the
routing table build process (Section 16.4).

Besides preventing extra-hops, there are two other applications for this
field.  The first is for use by "route servers".  Using the forwarding
address, a router in the middle of the Autonomous System can gather
external routing information and originate AS external advertisements
that specify the correct exit route to use for each external destination
(Section 2.2).

The other application possibly enables the reduction of the number of AS
external advertisements that need be imported.  Suppose in the example
at the beginning of this section that there are two routers (X and Z)
exchanging EGP information with the non-OSPF router Y.  It is then
likely that both X and Z will originate the same set of external routes.
Two AS external advertisements that specify the same (non-zero)
forwarding address, destination and cost are obviously functionally
equivalent, regardless of their originators (advertising routers).  The
OSPF specification dictates that the advertisement originated by the
router with the largest Router ID will always be used.  This allows the
other router to flush its equivalent advertisement (Section 12.4.4).


F.2 Corrected problems

The following problems in OSPF version 1 have been corrected in version
2.


F.2.1 LS sequence number space changes

The LS sequence number space has been changed from version 1's lollipop
shape to a linear sequence space (Section 12.1.6).  Sequence numbers
will now be compared as signed 32-bit integers.  Link state
advertisements having larger sequence numbers will be considered more
recent.  The sequence number space will still begin at (-N+1) (where N =
ToP   noToC   RFC1247 - Page 184
2**31).  The value of -N remains reserved.  The LS sequence number of
successive instances of an advertisement will continue to be incremented
until it reaches the maximum possible value: N-1.  At this point, when a
new instance of the advertisement must be originated (due either to
topological change of the expiration of the LS refresh timer) the
current instance must first be "prematurely aged".

There will be a new section discussing premature aging (Section 14.1).
This is a method for flushing a link state advertisement from the
routing domain: the advertisement's age is set to MaxAge and
advertisement is reflooded just as if it were a newly received
advertisement.  As soon as the new flooding is acknowledged by all of
the router's adjacent neighbors, the advertisement is flushed from the
database.

Premature aging can also be used when, for example, a previously
advertised external route is no longer reachable.  In this circumstance,
premature aging is preferable to the alternative, which is to originate
a new advertisement for the destination specifying a metric of
LSInfinity.

A router may only prematurely age its own (self-originated) link state
advertisements.  These are the link state advertisements having the
router's own OSPF router ID in the Advertising Router field.


F.2.2 Flooding of unexpected MaxAge advertisements

Version 1 of the OSPF omitted the handling of a special case in the
flooding procedure: the reception of a MaxAge advertisement that has no
database instance.  A paragraph has been added to Section 13 to deal
with this occurrence.  Without this paragraph, retransmissions of MaxAge
advertisements could possibly delay their being flushed from the routing
domain.


F.2.3 Virtual links and address ranges

When summarizing information into a virtual link's transit area, version
2 of the OSPF specification prohibits the collapsing of multiple
backbone IP networks/subnets into a single summary link.  This
restriction has been added to deal with certain anomalous OSPF area
configurations.  See Sections 15 and 12.4.3 for more information.
ToP   noToC   RFC1247 - Page 185
F.2.4 Routing table lookup explained

When forwarding an IP data packet, a router looks up the packet's IP
destination in the routing table.  This determines the packet's next
hop.  A new section (Section 11.1) has been added describing the routing
table lookup (instead of just specifying a "best match").  This section
clarifies OSPF's four level routing hierarchy (i.e., intra-area, inter-
area, external type 1 and external type 2 routes).  It also specifies
the effect of TOS on routing.


F.2.5 Sending Link State Request packets

OSPF Version 2 eases the restrictions on the sending of Link State
Request packets.  Link State Request packets can now be sent to a
neighboring router before a complete set of Database Description packets
have been exchanged.  This enables a more efficient use of a router's
memory resources; an OSPF version 2 implementation may limit the size of
the neighbor Link state request lists.  See Sections 10.9, 10.7 and 10.3
for more details.


F.2.6 Changes to the Database description process

The specification has been modified to ensure that, when two routers are
synchronizing their databases during the Database Description process,
none of the component link state advertisements can have their sequence
numbers decrease.  A link state advertisement's sequence number
decreases when it is flushed from the routing domain via premature-
aging, and then reoriginated with the smallest sequence number
0x80000001 (see Section 14.1).  So the specification now dictates that
an advertisement cannot be flushed from a router's database until both
a) it no longer appears on any neighbor Link State Retransmission lists
and b) none of the router's neighbors are in states Exchange or Loading.
See Sections 13 (step 4c) and 14.1 for more details.

In addition, a new step has been added to the flooding procedure
(Section 13) in order to make the Database Description process more
robust.  This step detects when a neighbor lists one instance of an
advertisement in its Database Description packets, but responds to Link
State Request packets by sending another (earlier) instance.  This
behavior now causes the event BadLSReq to be generated, which restarts
the Database Description process with the neighbor.  In OSPF version 1,
the neighbor event BadLSReq erroneously did not restart the Database
Description process.
ToP   noToC   RFC1247 - Page 186
F.2.7 Receiving OSPF Hello packets

The section detailing the receive processing of OSPF Hello packets
(Section 10.5) has been modified to include the generation of the
neighbor Backup Seen event.  In addition, the section detailing the
Designated Router election algorithm (Section 9.4) has been modified to
include the algorithm's initial state.


F.2.8 Network mask defined for default route

The network mask for the default route, when it appears as the
destination in either an AS external link advertisement or in a summary
link advertisement, has been set to 0.0.0.0.  See Sections A.4.4 and
A.4.5 for more details.


F.2.9 Rate limit imposed on flooding

When an advertisement is installed in the link state database, it is
timestamped.  The flooding procedure is then not allowed to install a
new instance of the advertisement until MinLSInterval seconds have
elapsed.  This enforces a rate limit on the flooding procedure; a new
instance can be flooded only once every MinLSInterval seconds.  This
guards against routers that disregard the limit on self-originated
advertisements (already present in OSPF version 1) of one origination
every MinLSInterval seconds.  For more information, see Section 13.


F.3 Packet format changes

The following changes have been made to the format of OSPF packets and
link state advertisements.  Some of these changes were required to
support the added functionality listed above.  Other changes were made
to further simplify the parsing of OSPF packets.


F.3.1 Adding a Capability bitfield

To support the new "stub area" and "optional TOS" features, a bitfield
listing protocol capabilities has been added to the Hello packet,
Database Description packet and all link state advertisements.  When
used in Hello packets, this allows a router to reject a neighbor because
of a capability mismatch.  Alternatively, when capabilities are
exchanged in Database Description packets a router can choose not to
forward certain link state advertisements to a neighbor because of its
reduced functionality.  Lastly, listing capabilities in link state
advertisements allows routers to route traffic around reduced
ToP   noToC   RFC1247 - Page 187
functionality router, by excluding them from parts of the routing table
calculation.  See Section A.2 for more details.


F.3.2 Packet simplification

To simplify the format of Database Description packets and Link State
Acknowledgment packets, their description of link state advertisements
has been modified.  Each advertisement is now be described by its 20-
byte link state header (see Section A.4).  This does not consume any
additional space in the packets.  The one additional piece of
information that will be present is the LS length.  However, this field
need not be used when processing the Database Description and Link State
Acknowledgment packets.


F.3.3 Adding forwarding addresses to AS external advertisements

As discussed in Section F.1.3, a forwarding address field has been added
to the AS external advertisement.


F.3.4 Labelling of virtual links

Virtual links will be labelled as such in router links advertisements.
This separates virtual links from unnumbered point-to-point links,
allowing all backbone routers to discover whether any virtual links are
in use.  See Section 12.4.1 for more details.


F.3.5 TOS costs ordered

When a link state advertisement specifies a separate cost depending on
TOS, these costs must be ordered by increasing TOS value.  For example,
the cost for TOS 16 must always follow the cost for TOS 8.


F.3.6 OSPF's TOS encoding redefined

The way that OSPF encodes TOS in its link state advertisements has been
redefined in version 2. OSPF's encoding of the Delay (D), Throughput (T)
and Reliability (R) TOS flags defined by [RFC 791] is described in
Section 12.3.
ToP   noToC   RFC1247 - Page 188
F.4 Backward-compatibility provisions

Additional functionality will probably be added to OSPF in the future.
One example of this is a multicast routing capability, which is
currently under development.  In order to be able to add such features
in a backward-compatible manner, the following provisions have been made
in the OSPF specification.

New capabilities will probably involve the introduction of new link
state advertisements.  If a router receives a link state advertisement
of unknown type during the flooding procedure, the advertisement is
simply ignored (Section 13.  The router should not attempt to further
flood the advertisement, nor acknowledge it.  The advertisement should
not be installed into the link state database.  If the router receives
an advertisement of unknown type during the Database Description
process, this is an error (see Sections 10.6 and 10.3).  The Database
Description process is then restarted.

There is also an Options field in both the Hello packets, Database
Description packets and the link state advertisement headers.
Unrecognized capabilities found in these places should be ignored, and
should not affect the normal processing of protocol packets/link state
advertisements (see Sections 10.5 and 10.6).  Routers will originate
their Hello packets, Database Description packets and link state
advertisements with unrecognized capabilities set to 0 (see Sections
9.5, 10.8 and 12.1.2).
ToP   noToC   RFC1247 - Page 189
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 E.


Author's Address

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

Phone: (508) 898-2800
EMail: jmoy@proteon.com