rfc1247.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

[Moy]                                                          [Page 23]

RFC 1247                     OSPF Version 2                    July 1991


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



[Moy]                                                          [Page 24]

RFC 1247                     OSPF Version 2                    July 1991


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]).




[Moy]                                                          [Page 25]

RFC 1247                     OSPF Version 2                    July 1991


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.




[Moy]                                                          [Page 26]

RFC 1247                     OSPF Version 2                    July 1991


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



[Moy]                                                          [Page 27]

RFC 1247                     OSPF Version 2                    July 1991


    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.




[Moy]                                                          [Page 28]

RFC 1247                     OSPF Version 2