Events generated as a result of routing table changes 153

Changes to routing table entries sometimes cause the OSPF area border routers to take additional actions. These routers need to act on the following routing table changes:

o The cost or path type of a routing table entry has changed.

If the destination described by this entry is a Network or AS boundary router, and this is not simply a change of AS external routes, new summary-LSAs may have to be generated (potentially one for each attached area, including the backbone). See Section

12.4.3 for more information. If a previously advertised entry has been deleted, or is no longer advertisable to a particular area, the LSA must be flushed from the routing domain by setting its LS age to MaxAge and reflooding (see Section 14.1).

o A routing table entry associated with a configured virtual link has changed. The destination of such a routing table entry is an area border router. The change indicates a modification to the virtual link’s cost or viability.

If the entry indicates that the area border router is newly

reachable, the corresponding virtual link is now operational. An InterfaceUp event should be generated for the virtual link, which will cause a virtual adjacency to begin to form (see Section 10.3). At this time the virtual link’s IP interface address and the virtual neighbor’s Neighbor IP address are also calculated.

If the entry indicates that the area border router is no longer reachable, the virtual link and its associated adjacency should be destroyed. This means an InterfaceDown event should be generated for the associated virtual link.

If the cost of the entry has changed, and there is a fully

established virtual adjacency, a new router-LSA for the backbone must be originated. This in turn may cause further routing table changes.

16.8. Equal-cost multipath

The OSPF protocol maintains multiple equal-cost routes to all

destinations. This can be seen in the steps used above to calculate the routing table, and in the definition of the routing table

structure.

Each one of the multiple routes will be of the same type (intra-area, inter-area, type 1 external or type 2 external), cost, and will have the same associated area. However, each route specifies a separate next hop and Advertising router.

There is no requirement that a router running OSPF keep track of all possible equal-cost routes to a destination. An implementation may choose to keep only a fixed number of routes to any given

destination. This does not affect any of the algorithms presented in this specification.

Footnotes

[1]The graph’s vertices represent either routers, transit networks, or stub networks. Since routers may belong to multiple areas, it is not possible to color the graph’s vertices.

[2]It is possible for all of a router’s interfaces to be unnumbered point-to-point links. In this case, an IP address must be assigned to the router. This address will then be advertised in the router’s router-LSA as a host route.

[3]Note that in these cases both interfaces, the non-virtual and the virtual, would have the same IP address.

[4]Note that no host route is generated for, and no IP packets can be addressed to, interfaces to unnumbered point-to-point networks. This is regardless of such an interface’s state.

[5]It is instructive to see what happens when the Designated Router for the network crashes. Call the Designated Router for the network RT1, and the Backup Designated Router RT2. If Router RT1 crashes (or maybe its interface to the network dies), the other routers on the network will detect RT1’s absence within RouterDeadInterval seconds.

All routers may not detect this at precisely the same time; the routers that detect RT1’s absence before RT2 does will, for a time, select RT2 to be both Designated Router and Backup Designated Router.

When RT2 detects that RT1 is gone it will move itself to Designated Router. At this time, the remaining router having highest Router Priority will be selected as Backup Designated Router.

[6]On point-to-point networks, the lower level protocols indicate whether the neighbor is up and running. Likewise, existence of the neighbor on virtual links is indicated by the routing table

calculation. However, in both these cases, the Hello Protocol is still used. This ensures that communication between the neighbors is bidirectional, and that each of the neighbors has a functioning

routing protocol layer.

[7]When the identity of the Designated Router is changing, it may be quite common for a neighbor in this state to send the router a

Database Description packet; this means that there is some momentary disagreement on the Designated Router’s identity.

[8]Note that it is possible for a router to resynchronize any of its fully established adjacencies by setting the adjacency’s state back to ExStart. This will cause the other end of the adjacency to process a SeqNumberMismatch event, and therefore to also go back to ExStart state.

[9]The address space of IP networks and the address space of OSPF Router IDs may overlap. That is, a network may have an IP address which is identical (when considered as a 32-bit number) to some router’s Router ID.

[10]"Discard" entries are necessary to ensure that route

summarization at area boundaries will not cause packet looping.

[11]It is assumed that, for two different address ranges matching the destination, one range is more specific than the other.

contiguous subnet masks can be configured to violate this assumption.

Such subnet mask configurations cannot be handled by the OSPF protocol.

[12]MaxAgeDiff is an architectural constant. It indicates the maximum dispersion of ages, in seconds, that can occur for a single LSA instance as it is flooded throughout the routing domain. If two LSAs differ by more than this, they are assumed to be different instances of the same LSA. This can occur when a router restarts and loses track of the LSA’s previous LS sequence number. See Section 13.4 for more details.

[13]When two LSAs have different LS checksums, they are assumed to be separate instances. This can occur when a router restarts, and loses track of the LSA’s previous LS sequence number. In the case where the two LSAs have the same LS sequence number, it is not possible to determine which LSA is actually newer. However, if the wrong LSA is accepted as newer, the originating router will simply originate another instance. See Section 13.4 for further details.

[14]There is one instance where a lookup must be done based on partial information. This is during the routing table calculation, when a network-LSA must be found based solely on its Link State ID.

The lookup in this case is still well defined, since no two LSAs can have the same Link State ID.

[15]This is the way RFC 1583 specified point-to-point representation.

It has three advantages: a) it does not require allocating a subnet to the point-to-point link, b) it tends to bias the routing so that packets destined for the point-to-point interface will actually be received over the interface (which is useful for diagnostic purposes) and c) it allows network bootstrapping of a neighbor, without

requiring that the bootstrap program contain an OSPF implementation.

[16]This is the more traditional point-to-point representation used by protocols such as RIP.

[17]This clause covers the case: Inter-area routes are not summarized to the backbone. This is because inter-area routes are always

associated with the backbone area.

[18]This clause is only invoked when a non-backbone Area A supports transit data traffic (i.e., has TransitCapability set to TRUE). For example, in the area configuration of Figure 6, Area 2 can support transit traffic due to the configured virtual link between Routers RT10 and RT11. As a result, Router RT11 need only originate a single summary-LSA into Area 2 (having the collapsed destination N9-N11,H1), since all of Router RT11’s other eligible routes have next hops

belonging to Area 2 itself (and as such only need be advertised by other area border routers; in this case, Routers RT10 and RT7).

[19]By keeping more information in the routing table, it is possible for an implementation to recalculate the shortest path tree for only a single area. In fact, there are incremental algorithms that allow an implementation to recalculate only a portion of a single area’s shortest path tree [Ref1]. However, these algorithms are beyond the scope of this specification.

[20]This is how the Link state request list is emptied, which eventually causes the neighbor state to transition to Full. See Section 10.9 for more details.

[21]It should be a relatively rare occurrence for an LSA’s LS age to reach MaxAge in this fashion. Usually, the LSA will be replaced by a more recent instance before it ages out.

[22]Strictly speaking, because of equal-cost multipath, the algorithm does not create a tree. We continue to use the "tree" terminology because that is what occurs most often in the existing literature.

[23]Note that the presence of any link back to V is sufficient; it need not be the matching half of the link under consideration from V to W. This is enough to ensure that, before data traffic flows

between a pair of neighboring routers, their link state databases will be synchronized.

[24]When the forwarding address is non-zero, it should point to a router belonging to another Autonomous System. See Section 12.4.4 for more details.

References

[Ref1] McQuillan, J., I. Richer and E. Rosen, "ARPANET Routing Algorithm Improvements", BBN Technical Report 3803, April 1978.

[Ref2] Digital Equipment Corporation, "Information processing systems -- Data communications -- Intermediate System to Intermediate System Intra-Domain Routing Protocol", October 1987.

[Ref3] McQuillan, J. et.al., "The New Routing Algorithm for the ARPANET", IEEE Transactions on Communications, May 1980.

[Ref4] Perlman, R., "Fault-Tolerant Broadcast of Routing Information", Computer Networks, December 1983.

[Ref5] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981.

[Ref6] McKenzie, A., "ISO Transport Protocol specification ISO DP 8073", RFC 905, ISO, April 1984.

[Ref7] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, Stanford University, May 1988.

[Ref8] McCloghrie, K., and M. Rose, "Management Information Base for network management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991.

[Ref9] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994.

[Ref10] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT, OARnet, September 1993.

[Ref11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.

[Ref12] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.

[Ref13] Leiner, B., et.al., "The DARPA Internet Protocol Suite", DDN Protocol Handbook, April 1985.

[Ref14] Bradley, T., and C. Brown, "Inverse Address Resolution Protocol", RFC 1293, January 1992.

[Ref15] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF Over Frame Relay Networks", RFC 1586, March 1994.

[Ref16] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Volume 19, Number 2, pp. 32-38, April 1989.

[Ref17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.

[Ref18] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc., March 1994.

[Ref19] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, RainbowBridge Communications, Stanford University, March 1994.

[Ref20] Ferguson, D., "The OSPF External Attributes LSA", work in progress.

[Ref21] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, Cascade, April 1995.

[Ref22] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, DECWRL, Stanford University, November 1990.

[Ref23] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco Systems, March 1995.

[Ref24] Hinden, R., "Internet Routing Protocol Standardization Criteria", BBN, October 1991.

A. OSPF data formats

This appendix describes the format of OSPF protocol packets and OSPF LSAs. The OSPF protocol runs directly over the IP network layer.

Before any data formats are described, the details of the OSPF encapsulation are explained.

Next the OSPF Options field is described. This field describes various capabilities that may or may not be supported by pieces of the OSPF routing domain. The OSPF Options field is contained in OSPF Hello packets, Database Description packets and in OSPF LSAs.

OSPF packet formats are detailed in Section A.3. A description of OSPF LSAs appears in Section A.4.