tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 1247

 
 
 

OSPF Version 2

Part 2 of 7, p. 24 to 54
Prev RFC Part       Next RFC Part

 


prevText      Top       Page 24 
4. Functional Summary

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

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

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

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

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

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

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


4.1 Inter-area routing

The previous section described the operation of the protocol within a
single area.  For intra-area routing, no other routing information is

Top       Page 25 
pertinent.  In order to be able to route to destinations outside of the
area, the area border routers inject additional routing information into
the area.  This additional information is a distillation of the rest of
the Autonomous System's topology.

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


4.2 AS external routes

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

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


4.3 Routing protocol packets

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

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

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



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


                        Table 8: OSPF packet types.


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

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


LS     Advertisement        Advertisement description
type   name
____________________________________________________________________________
1      Router links advs.   Originated by all routers. This
       advs.                advertisement describes the collected
                            states of the router's interfaces to an
                            area. Flooded throughout a single area
                            only.
____________________________________________________________________________
2      Network links        Originated for multi-access networks by
       advs.                the Designated Router. This
                            advertisement contains the list of
                            routers connected to the network.
                            Flooded throughout a single area only.

Top       Page 27 
LS     Advertisement        Advertisement description
type   name
____________________________________________________________________________
____________________________________________________________________________
3,4    Summary link         Originated by area border routers, and
       advs.                flooded throughout their associated
                            area. Each summary link advertisement
                            describes a route to a destination
                            outside the area, yet still inside the
                            AS (i.e., an inter-area route). Type 3
                            advertisements describe routes to
                            networks. Type 4 advertisements
                            describe routes to AS boundary routers.
____________________________________________________________________________
5      AS external          Originated by AS boundary routers, and
       link advs.           flooded throughout the AS. Each external
                            advertisement describes a route to a
                            destination in another Autonomous
                            System. Default routes for the AS can
                            also be described by AS external advertisements.


                Table 9: OSPF link state advertisements.

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


4.4 Basic implementation requirements

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


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

    Interval timers should be implemented to avoid drift.  In some

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

IP multicast
    Certain OSPF packets use IP multicast.  Support for receiving and
    sending IP multicasts, along with the appropriate lower-level
    protocol support, is required.  These IP multicast packets never
    travel more than one hop.  For information on IP multicast, see [RFC
    1112].

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

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

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

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

Top       Page 29 
4.5 Optional OSPF capabilities

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

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

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

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

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


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

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

Top       Page 30 
    zero TOS paths.


5. Protocol Data Structures

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


Router ID
    a 32-bit number that uniquely identifies this router in the AS.  One
    possible implementation strategy would be to use the smallest IP
    interface address belonging to the router.

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

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

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

List of external routes
    These are routes to destinations external to the Autonomous System,
    that have been gained either through direct experience with another
    routing protocol (such as EGP), or through configuration
    information, or through a combination of the two (e.g., dynamic
    external info.  to be advertised by OSPF with configured metric).
    Any router having these external routes is called an AS boundary

Top       Page 31 
    router.  These routes are advertised by the router to the entire AS
    through AS external link advertisements.

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

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

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


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



6. The Area Data Structure

The area data structure contains all the information used to run the
basic routing algorithm.  Remember that each area maintains its own
topological database.  Router interfaces and adjacencies belong to a


                _______________________________________

                (Figure not included in text version.)

                Figure 9: Router RT10's Data Structures
                _______________________________________

Top       Page 32 
single area.

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

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


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

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

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

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

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

List of summary links advertisements
    Summary link advertisements originate from the area's area border
    routers.  They describe routes to destinations internal to the

Top       Page 33 
    Autonomous System, yet external to the area.

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

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

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

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


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


7. Bringing Up Adjacencies

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


7.1 The Hello Protocol

The Hello Protocol is responsible for establishing and maintaining
neighbor relationships.  It also ensures that communication between
neighbors is bidirectional.  Hello packets are sent periodically out all

Top       Page 34 
router interfaces.  Bidirectional communication is indicated when the
router sees itself listed in the neighbor's Hello Packet.

On multi-access networks, the Hello Protocol elects a Designated Router
for the network.  Among other things, the Designated Router controls
what adjacencies will be formed over the network (see below).

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

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

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


7.2 The Synchronization of Databases

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

This sending and receiving of Database Description packets is called the
"Database Exchange Process".  During this process, the two routers form

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

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

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

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


7.3 The Designated Router

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

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

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

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

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

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


7.4 The Backup Designated Router

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

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

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

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


7.5 The graph of adjacencies

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

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

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

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


8. Protocol Packet Processing

This section discusses the general processing of routing protocol
packets.  It is very important that the router topological databases

Top       Page 38 
remain synchronized.  For this reason, routing protocol packets should
get preferential treatment over ordinary data packets, both in sending
and receiving.

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

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



8.1 Sending protocol packets

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


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

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

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

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


                 ______________________________________

                 (Figure not included in text version.)

                  Figure 10: The graph of adjacencies
                   Figure 11: Interface state changes
                 ______________________________________

Top       Page 39 
Area ID
    The area that the packet is being sent into.

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

Autype and Authentication
    Each OSPF packet exchange is authenticated.  Authentication types
    are assigned by the protocol and documented in Appendix E.  A
    different authentication scheme can be used for each OSPF area.  The
    64-bit authentication field is set by the appropriate authentication
    procedure (determined by Autype).  This procedure should be the last
    called when forming the packet to be sent.  The setting of the
    authentication field is determined by the packet contents and the
    authentication key (which is configurable on a per-interface basis).


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

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

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

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



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


             Table 10: Sections describing packet transmission.



8.2 Receiving protocol packets

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

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


o   The IP checksum must be correct.

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

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

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

Top       Page 41 
Next, the OSPF packet header is verified.  The fields specified in the
header must match those configured for the receiving interface.  If they
do not, the packet should be discarded:


o   The version number field must specify protocol version 2.

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

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

    (1) Match the Area ID of the receiving interface.  In this case, the
        packet has been sent over a single hop.  Therefore, the packet's
        IP source address must be on the same network as the receiving
        interface.  This can be determined by comparing the packet's IP
        source address to the interface's IP address, after masking both
        addresses with the interface mask.

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

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

o   The Authentication type specified must match the authentication type
    specified for the associated area.


Next, the packet must be authenticated.  This depends on the
authentication type specified (see Appendix E).  The authentication
procedure may use an Authentication key, which can be configured on a
per-interface basis.  If the authentication fails, the packet should be
discarded.

If the packet type is Hello, it should then be further processed by the
Hello Protocol (see Section 10.5).  All other packet types are
sent/received only on adjacencies.  This means that the packet must have

Top       Page 42 
been sent by one of the router's active neighbors.  If the receiving
interface is a multi-access network (either broadcast or non-broadcast)
the sender is identified by the IP source address found in the packet's
IP header.  If the receiving interface is a point-to-point link or a
virtual link, the sender is identified by the Router ID (source router)
found in the packet's OSPF header.  The data structure associated with
the receiving interface contains the list of active neighbors.  Packets
not matching any active neighbor are discarded.

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



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


              Table 11: Sections describing packet reception.



9. The Interface Data Structure

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

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

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

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

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

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

IP interface mask
    This indicates the portion of the IP interface address that
    identifies the attached network.  This is often referred to as the
    subnet mask.  Masking the IP interface address with this value
    yields the IP network number of the attached network.

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

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

RouterDeadInterval
    The number of seconds before the router's neighbors will declare it
    down, when they stop hearing the router's hellos.  Advertised in
    Hello packets sent out this interface.

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

Router Priority
    An 8-bit unsigned integer.  When two routers attached to a network
    both attempt to become Designated Router, the one with the highest

Top       Page 44 
    Router Priority takes precedence.  A router whose Router Priority is
    set to 0 is ineligible to become Designated Router on the attached
    network.  Advertised in Hello packets sent out this interface.

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

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

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

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

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

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 links advertisement.  There may be a
    separate cost for each IP Type of Service.  The cost of an interface
    must be greater than zero.

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

Authentication key
    This configured data allows the authentication procedure to generate
    and/or verify the authentication field in the OSPF header.  The
    authentication key can be configured on a per-interface basis.  For
    example, if the 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, and there could be a separate password for each
    network.


9.1 Interface states

The various states that router interface may attain is documented in
this section.  The states are listed in order of progressing
functionality.  For example, the inoperative state is listed first,
followed by a list of intermediate states before the final, fully
functional state is achieved.  The specification makes use of this
ordering by sometimes making references such as "those interfaces in
state greater than X".

Figure 11 shows the graph of interface state changes.  The arcs of the
graph are labelled with the event causing the state change.  These
events are documented in Section 9.2.  The interface state machine is
described in more detail in Section 9.3.


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

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

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

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

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

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

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

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

Top       Page 47 
9.2 Events causing interface state changes

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


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

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

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

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

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

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

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

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

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

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

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

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


9.3 The Interface state machine

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

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

Some of the required actions below involve generating events for the
neighbor state machine.  For example, when an interface becomes
inoperative, all neighbor connections associated with the interface must
be destroyed.  For more information on the neighbor state machine, see
Section 10.3.


 State(s):  Down

Top       Page 49 
    Event:  Interface Up

New state:  Depends on action routine

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

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


 State(s):  Waiting

    Event:  Backup Seen

New state:  Depends upon action routine.

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


 State(s):  Waiting

    Event:  Wait Timer

New state:  Depends upon action routine.

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


 State(s):  DR Other, Backup or DR

Top       Page 50 
    Event:  Neighbor Change

New state:  Depends upon action routine.

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


 State(s):  Any State

    Event:  Interface Down

New state:  Down

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


 State(s):  Any State

    Event:  Loop Ind

New state:  Loopback

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


 State(s):  Loopback

    Event:  Unloop Ind

New state:  Down

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

Top       Page 51 
9.4 Electing the Designated Router

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

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


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

(2) Calculate the new Backup Designated Router for the network as
    follows.  Only those routers on the list that have not declared
    themselves to be Designated Router are eligible to become Backup
    Designated Router.  If one or more of these routers have declared
    themselves Backup Designated Router (i.e., they are currently
    listing themselves as Backup Designated Router, but not as
    Designated Router, in their Hello Packets) the one having highest
    Router Priority is declared to be Backup Designated Router.  In case
    of a tie, the one having the highest Router ID is chosen.  If no
    routers have declared themselves Backup Designated Router, choose
    the router having highest Router Priority, (again excluding those
    routers who have declared themselves Designated Router), and again
    use the Router ID to break ties.

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

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

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

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

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


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

If Router X is not itself eligible to become Designated Router, it is
possible that neither a Backup Designated Router nor a Designated Router
will be selected in the above procedure.  Note also that if Router X is
the only attached router that is eligible to become Designated Router,
it will select itself as Designated Router and there will be no Backup
Designated Router for the network.

Top       Page 53 
9.5 Sending Hello packets

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

The format of a Hello packet is detailed in Section A.3.2.  The Hello
Packet contains the router's Router Priority (used in choosing the
Designated Router), and the interval between Hello broadcasts
(HelloInterval).  The Hello Packet also indicates how often a neighbor
must be heard from to remain active (RouterDeadInterval).  Both
HelloInterval and RouterDeadInterval must be the same for all routers
attached to a common network.  The Hello packet also contains the IP
address mask of the attached network (Network Mask).  On unnumbered
point-to-point networks and on virtual links this field should be set to
0.

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

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

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


9.5.1 Sending Hello packets on non-broadcast networks

Static configuration information is necessary in order for the Hello
Protocol to function on non-broadcast networks (see Section C.5).  Every
attached router which is eligible to become Designated Router has a

Top       Page 54 
configured list of all of its neighbors on the network.  Each listed
neighbor is labelled with its Designated Router eligibility.

The interface state must be at least Waiting for any hellos to be sent.
Hellos are then sent directly (as unicasts) to some subset of a router's
neighbors.  Sometimes an hello is sent periodically on a timer; at other
times it is sent as a response to a received hello.  A router's hello-
sending behavior varies depending on whether the router itself is
eligible to become Designated Router.

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

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

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




(page 54 continued on part 3)

Next RFC Part