RFCs in HTML Format


RFC 1583

                             OSPF Version 2


    OSPF Version 2 was originally documented in RFC 1247. The
    differences between RFC 1247 and this memo are explained in Appendix
    E. The differences consist of bug fixes and clarifications, and are
    backward-compatible in nature. Implementations of RFC 1247 and of
    this memo will interoperate.

    Please send comments to ospf@gated.cornell.edu.








Moy                                                             [Page 1]

RFC 1583 OSPF Version 2 March 1994 Table of Contents 1 Introduction ........................................... 5 1.1 Protocol Overview ...................................... 5 1.2 Definitions of commonly used terms ..................... 6 1.3 Brief history of link-state routing technology ......... 9 1.4 Organization of this document .......................... 9 2 The Topological Database .............................. 10 2.1 The shortest-path tree ................................ 13 2.2 Use of external routing information ................... 16 2.3 Equal-cost multipath .................................. 20 2.4 TOS-based routing ..................................... 20 3 Splitting the AS into Areas ........................... 21 3.1 The backbone of the Autonomous System ................. 22 3.2 Inter-area routing .................................... 22 3.3 Classification of routers ............................. 23 3.4 A sample area configuration ........................... 24 3.5 IP subnetting support ................................. 30 3.6 Supporting stub areas ................................. 31 3.7 Partitions of areas ................................... 32 4 Functional Summary .................................... 34 4.1 Inter-area routing .................................... 35 4.2 AS external routes .................................... 35 4.3 Routing protocol packets .............................. 35 4.4 Basic implementation requirements ..................... 38 4.5 Optional OSPF capabilities ............................ 39 5 Protocol data structures .............................. 41 6 The Area Data Structure ............................... 42 7 Bringing Up Adjacencies ............................... 45 7.1 The Hello Protocol .................................... 45 7.2 The Synchronization of Databases ...................... 46 7.3 The Designated Router ................................. 47 7.4 The Backup Designated Router .......................... 48 7.5 The graph of adjacencies .............................. 49 8 Protocol Packet Processing ............................ 50 8.1 Sending protocol packets .............................. 51 8.2 Receiving protocol packets ............................ 53 9 The Interface Data Structure .......................... 55 9.1 Interface states ...................................... 58 9.2 Events causing interface state changes ................ 61 9.3 The Interface state machine ........................... 62 9.4 Electing the Designated Router ........................ 65 9.5 Sending Hello packets ................................. 67 9.5.1 Sending Hello packets on non-broadcast networks ....... 68 10 The Neighbor Data Structure ........................... 69 10.1 Neighbor states ....................................... 72 10.2 Events causing neighbor state changes ................. 75 10.3 The Neighbor state machine ............................ 77 Moy [Page 2]
RFC 1583 OSPF Version 2 March 1994 10.4 Whether to become adjacent ............................ 83 10.5 Receiving Hello Packets ............................... 83 10.6 Receiving Database Description Packets ................ 86 10.7 Receiving Link State Request Packets .................. 89 10.8 Sending Database Description Packets .................. 89 10.9 Sending Link State Request Packets .................... 90 10.10 An Example ............................................ 91 11 The Routing Table Structure ........................... 93 11.1 Routing table lookup .................................. 96 11.2 Sample routing table, without areas ................... 97 11.3 Sample routing table, with areas ...................... 98 12 Link State Advertisements ............................ 100 12.1 The Link State Advertisement Header .................. 101 12.1.1 LS age ............................................... 102 12.1.2 Options .............................................. 102 12.1.3 LS type .............................................. 103 12.1.4 Link State ID ........................................ 103 12.1.5 Advertising Router ................................... 105 12.1.6 LS sequence number ................................... 105 12.1.7 LS checksum .......................................... 106 12.2 The link state database .............................. 107 12.3 Representation of TOS ................................ 108 12.4 Originating link state advertisements ................ 109 12.4.1 Router links ......................................... 112 12.4.2 Network links ........................................ 118 12.4.3 Summary links ........................................ 120 12.4.4 Originating summary links into stub areas ............ 123 12.4.5 AS external links .................................... 124 13 The Flooding Procedure ............................... 126 13.1 Determining which link state is newer ................ 130 13.2 Installing link state advertisements in the database . 130 13.3 Next step in the flooding procedure .................. 131 13.4 Receiving self-originated link state ................. 134 13.5 Sending Link State Acknowledgment packets ............ 135 13.6 Retransmitting link state advertisements ............. 136 13.7 Receiving link state acknowledgments ................. 138 14 Aging The Link State Database ........................ 139 14.1 Premature aging of advertisements .................... 139 15 Virtual Links ........................................ 140 16 Calculation Of The Routing Table ..................... 142 16.1 Calculating the shortest-path tree for an area ....... 143 16.1.1 The next hop calculation ............................. 149 16.2 Calculating the inter-area routes .................... 150 16.3 Examining transit areas' summary links ............... 152 16.4 Calculating AS external routes ....................... 154 16.5 Incremental updates -- summary link advertisements ... 156 16.6 Incremental updates -- AS external link advertisements 157 16.7 Events generated as a result of routing table changes 157 Moy [Page 3]
RFC 1583 OSPF Version 2 March 1994 16.8 Equal-cost multipath ................................. 158 16.9 Building the non-zero-TOS portion of the routing table 158 Footnotes ............................................ 161 References ........................................... 164 A OSPF data formats .................................... 166 A.1 Encapsulation of OSPF packets ........................ 166 A.2 The Options field .................................... 168 A.3 OSPF Packet Formats .................................. 170 A.3.1 The OSPF packet header ............................... 171 A.3.2 The Hello packet ..................................... 173 A.3.3 The Database Description packet ...................... 175 A.3.4 The Link State Request packet ........................ 177 A.3.5 The Link State Update packet ......................... 179 A.3.6 The Link State Acknowledgment packet ................. 181 A.4 Link state advertisement formats ..................... 183 A.4.1 The Link State Advertisement header .................. 184 A.4.2 Router links advertisements .......................... 186 A.4.3 Network links advertisements ......................... 190 A.4.4 Summary link advertisements .......................... 192 A.4.5 AS external link advertisements ...................... 194 B Architectural Constants .............................. 196 C Configurable Constants ............................... 198 C.1 Global parameters .................................... 198 C.2 Area parameters ...................................... 198 C.3 Router interface parameters .......................... 200 C.4 Virtual link parameters .............................. 202 C.5 Non-broadcast, multi-access network parameters ....... 203 C.6 Host route parameters ................................ 203 D Authentication ....................................... 205 D.1 AuType 0 -- No authentication ........................ 205 D.2 AuType 1 -- Simple password .......................... 205 E Differences from RFC 1247 ............................ 207 E.1 A fix for a problem with OSPF Virtual links .......... 207 E.2 Supporting supernetting and subnet 0 ................. 208 E.3 Obsoleting LSInfinity in router links advertisements . 209 E.4 TOS encoding updated ................................. 209 E.5 Summarizing routes into transit areas ................ 210 E.6 Summarizing routes into stub areas ................... 210 E.7 Flushing anomalous network links advertisements ...... 210 E.8 Required Statistics appendix deleted ................. 211 E.9 Other changes ........................................ 211 F. An algorithm for assigning Link State IDs ............ 213 Security Considerations .............................. 216 Author's Address ..................................... 216 Moy [Page 4]
RFC 1583 OSPF Version 2 March 1994 1. Introduction This document is a specification of the Open Shortest Path First (OSPF) TCP/IP internet routing protocol. OSPF is classified as an Interior Gateway Protocol (IGP). This means that it distributes routing information between routers belonging to a single Autonomous System. The OSPF protocol is based on link-state or SPF technology. This is a departure from the Bellman-Ford base used by traditional TCP/IP internet routing protocols. The OSPF protocol was developed by the OSPF working group of the Internet Engineering Task Force. It has been designed expressly for the TCP/IP internet environment, including explicit support for IP subnetting, TOS-based routing and the tagging of externally-derived routing information. OSPF also provides for the authentication of routing updates, and utilizes IP multicast when sending/receiving the updates. In addition, much work has been done to produce a protocol that responds quickly to topology changes, yet involves small amounts of routing protocol traffic. The author would like to thank Fred Baker, Jeffrey Burgan, Rob Coltun, Dino Farinacci, Vince Fuller, Phanindra Jujjavarapu, Milo Medin, Kannan Varadhan and the rest of the OSPF working group for the ideas and support they have given to this project. 1.1. Protocol overview OSPF routes IP packets based solely on the destination IP address and IP Type of Service found in the IP packet header. IP packets are routed "as is" -- they are not encapsulated in any further protocol headers as they transit the Autonomous System. OSPF is a dynamic routing protocol. It quickly detects topological changes in the AS (such as router interface failures) and calculates new loop-free routes after a period of convergence. This period of convergence is short and involves a minimum of routing traffic. In a link-state routing protocol, each router maintains a database describing the Autonomous System's topology. Each participating router has an identical database. Each individual piece of this database is a particular router's local state (e.g., the router's usable interfaces and reachable neighbors). The router distributes its local state throughout the Autonomous System by flooding. All routers run the exact same algorithm, in parallel. From the topological database, each router constructs a tree of shortest paths with itself as root. This shortest-path tree gives the Moy [Page 5]
RFC 1583 OSPF Version 2 March 1994 route to each destination in the Autonomous System. Externally derived routing information appears on the tree as leaves. OSPF calculates separate routes for each Type of Service (TOS). When several equal-cost routes to a destination exist, traffic is distributed equally among them. The cost of a route is described by a single dimensionless metric. OSPF allows sets of networks to be grouped together. Such a grouping is called an area. The topology of an area is hidden from the rest of the Autonomous System. This information hiding enables a significant reduction in routing traffic. Also, routing within the area is determined only by the area's own topology, lending the area protection from bad routing data. An area is a generalization of an IP subnetted network. OSPF enables the flexible configuration of IP subnets. Each route distributed by OSPF has a destination and mask. Two different subnets of the same IP network number may have different sizes (i.e., different masks). This is commonly referred to as variable length subnetting. A packet is routed to the best (i.e., longest or most specific) match. Host routes are considered to be subnets whose masks are "all ones" (0xffffffff). All OSPF protocol exchanges are authenticated. This means that only trusted routers can participate in the Autonomous System's routing. A variety of authentication schemes can be used; a single authentication scheme is configured for each area. This enables some areas to use much stricter authentication than others. Externally derived routing data (e.g., routes learned from the Exterior Gateway Protocol (EGP)) is passed transparently throughout the Autonomous System. This externally derived data is kept separate from the OSPF protocol's link state data. Each external route can also be tagged by the advertising router, enabling the passing of additional information between routers on the boundaries of the Autonomous System. 1.2. Definitions of commonly used terms This section provides definitions for terms that have a specific meaning to the OSPF protocol and that are used throughout the text. The reader unfamiliar with the Internet Protocol Suite is referred to [RS-85-153] for an introduction to IP. Moy [Page 6]
RFC 1583 OSPF Version 2 March 1994 Router A level three Internet Protocol packet switch. Formerly called a gateway in much of the IP literature. Autonomous System A group of routers exchanging routing information via a common routing protocol. Abbreviated as AS. Interior Gateway Protocol The routing protocol spoken by the routers belonging to an Autonomous system. Abbreviated as IGP. Each Autonomous System has a single IGP. Separate Autonomous Systems may be running different IGPs. Router ID A 32-bit number assigned to each router running the OSPF protocol. This number uniquely identifies the router within an Autonomous System. Network In this memo, an IP network/subnet/supernet. It is possible for one physical network to be assigned multiple IP network/subnet numbers. We consider these to be separate networks. Point-to-point physical networks are an exception - they are considered a single network no matter how many (if any at all) IP network/subnet numbers are assigned to them. Network mask A 32-bit number indicating the range of IP addresses residing on a single IP network/subnet/supernet. This specification displays network masks as hexadecimal numbers. For example, the network mask for a class C IP network is displayed as 0xffffff00. Such a mask is often displayed elsewhere in the literature as 255.255.255.0. Multi-access networks Those physical networks that support the attachment of multiple (more than two) routers. Each pair of routers on such a network is assumed to be able to communicate directly (e.g., multi-drop networks are excluded). Interface The connection between a router and one of its attached networks. An interface has state information associated with it, which is obtained from the underlying lower level protocols and the routing protocol itself. An interface to a network has associated with it a single IP address and Moy [Page 7]
RFC 1583 OSPF Version 2 March 1994 mask (unless the network is an unnumbered point-to-point network). An interface is sometimes also referred to as a link. Neighboring routers Two routers that have interfaces to a common network. On multi-access networks, neighbors are dynamically discovered by OSPF's Hello Protocol. Adjacency A relationship formed between selected neighboring routers for the purpose of exchanging routing information. Not every pair of neighboring routers become adjacent. Link state advertisement Describes the local state of a router or network. This includes the state of the router's interfaces and adjacencies. Each link state advertisement is flooded throughout the routing domain. The collected link state advertisements of all routers and networks forms the protocol's topological database. Hello Protocol The part of the OSPF protocol used to establish and maintain neighbor relationships. On multi-access networks the Hello Protocol can also dynamically discover neighboring routers. Designated Router Each multi-access network that has at least two attached routers has a Designated Router. The Designated Router generates a link state advertisement for the multi-access network and has other special responsibilities in the running of the protocol. The Designated Router is elected by the Hello Protocol. The Designated Router concept enables a reduction in the number of adjacencies required on a multi-access network. This in turn reduces the amount of routing protocol traffic and the size of the topological database. Lower-level protocols The underlying network access protocols that provide services to the Internet Protocol and in turn the OSPF protocol. Examples of these are the X.25 packet and frame levels for X.25 PDNs, and the ethernet data link layer for ethernets. Moy [Page 8]
RFC 1583 OSPF Version 2 March 1994 1.3. Brief history of link-state routing technology OSPF is a link state routing protocol. Such protocols are also referred to in the literature as SPF-based or distributed- database protocols. This section gives a brief description of the developments in link-state technology that have influenced the OSPF protocol. The first link-state routing protocol was developed for use in the ARPANET packet switching network. This protocol is described in [McQuillan]. It has formed the starting point for all other link-state protocols. The homogeneous Arpanet environment, i.e., single-vendor packet switches connected by synchronous serial lines, simplified the design and implementation of the original protocol. Modifications to this protocol were proposed in [Perlman]. These modifications dealt with increasing the fault tolerance of the routing protocol through, among other things, adding a checksum to the link state advertisements (thereby detecting database corruption). The paper also included means for reducing the routing traffic overhead in a link-state protocol. This was accomplished by introducing mechanisms which enabled the interval between link state advertisement originations to be increased by an order of magnitude. A link-state algorithm has also been proposed for use as an ISO IS-IS routing protocol. This protocol is described in [DEC]. The protocol includes methods for data and routing traffic reduction when operating over broadcast networks. This is accomplished by election of a Designated Router for each broadcast network, which then originates a link state advertisement for the network. The OSPF subcommittee of the IETF has extended this work in developing the OSPF protocol. The Designated Router concept has been greatly enhanced to further reduce the amount of routing traffic required. Multicast capabilities are utilized for additional routing bandwidth reduction. An area routing scheme has been developed enabling information hiding/protection/reduction. Finally, the algorithm has been modified for efficient operation in TCP/IP internets. 1.4. Organization of this document The first three sections of this specification give a general overview of the protocol's capabilities and functions. Sections Moy [Page 9]
RFC 1583 OSPF Version 2 March 1994 4-16 explain the protocol's mechanisms in detail. Packet formats, protocol constants and configuration items are specified in the appendices. Labels such as HelloInterval encountered in the text refer to protocol constants. They may or may not be configurable. The architectural constants are explained in Appendix B. The configurable constants are explained in Appendix C. The detailed specification of the protocol is presented in terms of data structures. This is done in order to make the explanation more precise. Implementations of the protocol are required to support the functionality described, but need not use the precise data structures that appear in this memo. 2. The Topological Database The Autonomous System's topological database describes a directed graph. The vertices of the graph consist of routers and networks. A graph edge connects two routers when they are attached via a physical point-to-point network. An edge connecting a router to a network indicates that the router has an interface on the network. The vertices of the graph can be further typed according to function. Only some of these types carry transit data traffic; that is, traffic that is neither locally originated nor locally destined. Vertices that can carry transit traffic are indicated on the graph by having both incoming and outgoing edges. Vertex type Vertex name Transit? _____________________________________ 1 Router yes 2 Network yes 3 Stub network no Table 1: OSPF vertex types. OSPF supports the following types of physical networks: Point-to-point networks A network that joins a single pair of routers. A 56Kb serial line is an example of a point-to-point network. Moy [Page 10]
RFC 1583 OSPF Version 2 March 1994 Broadcast networks Networks supporting many (more than two) attached routers, together with the capability to address a single physical message to all of the attached routers (broadcast). Neighboring routers are discovered dynamically on these nets using OSPF's Hello Protocol. The Hello Protocol itself takes advantage of the broadcast capability. The protocol makes further use of multicast capabilities, if they exist. An ethernet is an example of a broadcast network. Non-broadcast networks Networks supporting many (more than two) routers, but having no broadcast capability. Neighboring routers are also discovered on these nets using OSPF's Hello Protocol. However, due to the lack of broadcast capability, some configuration information is necessary for the correct operation of the Hello Protocol. On these networks, OSPF protocol packets that are normally multicast need to be sent to each neighboring router, in turn. An X.25 Public Data Network (PDN) is an example of a non- broadcast network. The neighborhood of each network node in the graph depends on whether the network has multi-access capabilities (either broadcast or non-broadcast) and, if so, the number of routers having an interface to the network. The three cases are depicted in Figure 1. Rectangles indicate routers. Circles and oblongs indicate multi- access networks. Router names are prefixed with the letters RT and network names with the letter N. Router interface names are prefixed by the letter I. Lines between routers indicate point-to- point networks. The left side of the figure shows a network with its connected routers, with the resulting graph shown on the right. Two routers joined by a point-to-point network are represented in the directed graph as being directly connected by a pair of edges, one in each direction. Interfaces to physical point-to-point networks need not be assigned IP addresses. Such a point-to-point network is called unnumbered. The graphical representation of point-to-point networks is designed so that unnumbered networks can be supported naturally. When interface addresses exist, they are modelled as stub routes. Note that each router would then have a stub connection to the other router's interface address (see Figure 1). When multiple routers are attached to a multi-access network, the directed graph shows all routers bidirectionally connected to the network vertex (again, see Figure 1). If only a single router is attached to a multi-access network, the network will appear in the Moy [Page 11]
RFC 1583 OSPF Version 2 March 1994 **FROM** * |RT1|RT2| +---+Ia +---+ * ------------ |RT1|------|RT2| T RT1| | X | +---+ Ib+---+ O RT2| X | | * Ia| | X | * Ib| X | | Physical point-to-point networks **FROM** +---+ +---+ |RT3| |RT4| |RT3|RT4|RT5|RT6|N2 | +---+ +---+ * ------------------------ | N2 | * RT3| | | | | X | +----------------------+ T RT4| | | | | X | | | O RT5| | | | | X | +---+ +---+ * RT6| | | | | X | |RT5| |RT6| * N2| X | X | X | X | | +---+ +---+ Multi-access networks **FROM** +---+ * |RT7| * |RT7| N3| +---+ T ------------ | O RT7| | | +----------------------+ * N3| X | | N3 * Stub multi-access networks Figure 1: Network map components Networks and routers are represented by vertices. An edge connects Vertex A to Vertex B iff the intersection of Column A and Row B is marked with an X. Moy [Page 12]
RFC 1583 OSPF Version 2 March 1994 directed graph as a stub connection. Each network (stub or transit) in the graph has an IP address and associated network mask. The mask indicates the number of nodes on the network. Hosts attached directly to routers (referred to as host routes) appear on the graph as stub networks. The network mask for a host route is always 0xffffffff, which indicates the presence of a single node. Figure 2 shows a sample map of an Autonomous System. The rectangle labelled H1 indicates a host, which has a SLIP connection to Router RT12. Router RT12 is therefore advertising a host route. Lines between routers indicate physical point-to-point networks. The only point-to-point network that has been assigned interface addresses is the one joining Routers RT6 and RT10. Routers RT5 and RT7 have EGP connections to other Autonomous Systems. A set of EGP-learned routes have been displayed for both of these routers. A cost is associated with the output side of each router interface. This cost is configurable by the system administrator. The lower the cost, the more likely the interface is to be used to forward data traffic. Costs are also associated with the externally derived routing data (e.g., the EGP-learned routes). The directed graph resulting from the map in Figure 2 is depicted in Figure 3. Arcs are labelled with the cost of the corresponding router output interface. Arcs having no labelled cost have a cost of 0. Note that arcs leading from networks to routers always have cost 0; they are significant nonetheless. Note also that the externally derived routing data appears on the graph as stubs. The topological database (or what has been referred to above as the directed graph) is pieced together from link state advertisements generated by the routers. The neighborhood of each transit vertex is represented in a single, separate link state advertisement. Figure 4 shows graphically the link state representation of the two kinds of transit vertices: routers and multi-access networks. Router RT12 has an interface to two broadcast networks and a SLIP line to a host. Network N6 is a broadcast network with three attached routers. The cost of all links from Network N6 to its attached routers is 0. Note that the link state advertisement for Network N6 is actually generated by one of the attached routers: the router that has been elected Designated Router for the network. 2.1. The shortest-path tree When no OSPF areas are configured, each router in the Autonomous System has an identical topological database, leading to an Moy [Page 13]
RFC 1583 OSPF Version 2 March 1994 + | 3+---+ N12 N14 N1|--|RT1|\ 1 \ N13 / | +---+ \ 8\ |8/8 + \ ____ \|/ / \ 1+---+8 8+---+6 * N3 *---|RT4|------|RT5|--------+ \____/ +---+ +---+ | + / | |7 | | 3+---+ / | | | N2|--|RT2|/1 |1 |6 | | +---+ +---+8 6+---+ | + |RT3|--------------|RT6| | +---+ +---+ | |2 Ia|7 | | | | +---------+ | | N4 | | | | | | N11 | | +---------+ | | | | | N12 |3 | |6 2/ +---+ | +---+/ |RT9| | |RT7|---N15 +---+ | +---+ 9 |1 + | |1 _|__ | Ib|5 __|_ / \ 1+----+2 | 3+----+1 / \ * N9 *------|RT11|----|---|RT10|---* N6 * \____/ +----+ | +----+ \____/ | | | |1 + |1 +--+ 10+----+ N8 +---+ |H1|-----|RT12| |RT8| +--+SLIP +----+ +---+ |2 |4 | | +---------+ +--------+ N10 N7 Figure 2: A sample Autonomous System Moy [Page 14]
RFC 1583 OSPF Version 2 March 1994 **FROM** |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| ----- --------------------------------------------- RT1| | | | | | | | | | | | |0 | | | | RT2| | | | | | | | | | | | |0 | | | | RT3| | | | | |6 | | | | | | |0 | | | | RT4| | | | |8 | | | | | | | |0 | | | | RT5| | | |8 | |6 |6 | | | | | | | | | | RT6| | |8 | |7 | | | | |5 | | | | | | | RT7| | | | |6 | | | | | | | | |0 | | | * RT8| | | | | | | | | | | | | |0 | | | * RT9| | | | | | | | | | | | | | | |0 | T RT10| | | | | |7 | | | | | | | |0 |0 | | O RT11| | | | | | | | | | | | | | |0 |0 | * RT12| | | | | | | | | | | | | | | |0 | * N1|3 | | | | | | | | | | | | | | | | N2| |3 | | | | | | | | | | | | | | | N3|1 |1 |1 |1 | | | | | | | | | | | | | N4| | |2 | | | | | | | | | | | | | | N6| | | | | | |1 |1 | |1 | | | | | | | N7| | | | | | | |4 | | | | | | | | | N8| | | | | | | | | |3 |2 | | | | | | N9| | | | | | | | |1 | |1 |1 | | | | | N10| | | | | | | | | | | |2 | | | | | N11| | | | | | | | |3 | | | | | | | | N12| | | | |8 | |2 | | | | | | | | | | N13| | | | |8 | | | | | | | | | | | | N14| | | | |8 | | | | | | | | | | | | N15| | | | | | |9 | | | | | | | | | | H1| | | | | | | | | | | |10| | | | | Figure 3: The resulting directed graph Networks and routers are represented by vertices. An edge of cost X connects Vertex A to Vertex B iff the intersection of Column A and Row B is marked with an X. Moy [Page 15]
RFC 1583 OSPF Version 2 March 1994 **FROM** **FROM** |RT12|N9|N10|H1| |RT9|RT11|RT12|N9| * -------------------- * ---------------------- * RT12| | | | | * RT9| | | |0 | T N9|1 | | | | T RT11| | | |0 | O N10|2 | | | | O RT12| | | |0 | * H1|10 | | | | * N9| | | | | * * RT12's router links N9's network links advertisement advertisement Figure 4: Individual link state components Networks and routers are represented by vertices. An edge of cost X connects Vertex A to Vertex B iff the intersection of Column A and Row B is marked with an X. identical graphical representation. A router generates its routing table from this graph by calculating a tree of shortest paths with the router itself as root. Obviously, the shortest- path tree depends on the router doing the calculation. The shortest-path tree for Router RT6 in our example is depicted in Figure 5. The tree gives the entire route to any destination network or host. However, only the next hop to the destination is used in the forwarding process. Note also that the best route to any router has also been calculated. For the processing of external data, we note the next hop and distance to any router advertising external routes. The resulting routing table for Router RT6 is pictured in Table 2. Note that there is a separate route for each end of a numbered serial line (in this case, the serial line between Routers RT6 and RT10). Routes to networks belonging to other AS'es (such as N12) appear as dashed lines on the shortest path tree in Figure 5. Use of this externally derived routing information is considered in the next section. 2.2. Use of external routing information After the tree is created the external routing information is examined. This external routing information may originate from another routing protocol such as EGP, or be statically Moy [Page 16]
RFC 1583 OSPF Version 2 March 1994 RT6(origin) RT5 o------------o-----------o Ib /|\ 6 |\ 7 8/8|8\ | \ / | \ | \ o | o | \7 N12 o N14 | \ N13 2 | \ N4 o-----o RT3 \ / \ 5 1/ RT10 o-------o Ia / |\ RT4 o-----o N3 3| \1 /| | \ N6 RT7 / | N8 o o---------o / | | | /| RT2 o o RT1 | | 2/ |9 / | | |RT8 / | /3 |3 RT11 o o o o / | | | N12 N15 N2 o o N1 1| |4 | | N9 o o N7 /| / | N11 RT9 / |RT12 o--------o-------o o--------o H1 3 | 10 |2 | o N10 Figure 5: The SPF tree for Router RT6 Edges that are not marked with a cost have a cost of of zero (these are network-to-router links). Routes to networks N12-N15 are external information that is considered in Section 2.2 Moy [Page 17]
RFC 1583 OSPF Version 2 March 1994 Destination Next Hop Distance __________________________________ N1 RT3 10 N2 RT3 10 N3 RT3 7 N4 RT3 8 Ib * 7 Ia RT10 12 N6 RT10 8 N7 RT10 12 N8 RT10 10 N9 RT10 11 N10 RT10 13 N11 RT10 14 H1 RT10 21 __________________________________ RT5 RT5 6 RT7 RT10 8 Table 2: The portion of Router RT6's routing table listing local destinations. configured (static routes). Default routes can also be included as part of the Autonomous System's external routing information. External routing information is flooded unaltered throughout the AS. In our example, all the routers in the Autonomous System know that Router RT7 has two external routes, with metrics 2 and 9 OSPF supports two types of external metrics. Type 1 external metrics are equivalent to the link state metric. Type 2 external metrics are greater than the cost of any path internal to the AS. Use of Type 2 external metrics assumes that routing between AS'es is the major cost of routing a packet, and eliminates the need for conversion of external costs to internal link state metrics. As an example of Type 1 external metric processing, suppose that the Routers RT7 and RT5 in Figure 2 are advertising Type 1 external metrics. For each external route, the distance from Router RT6 is calculated as the sum of the external route's cost and the distance from Router RT6 to the advertising router. For every external destination, the router advertising the shortest route is discovered, and the next hop to the advertising router becomes the next hop to the destination. Moy [Page 18]
RFC 1583 OSPF Version 2 March 1994 Both Router RT5 and RT7 are advertising an external route to destination Network N12. Router RT7 is preferred since it is advertising N12 at a distance of 10 (8+2) to Router RT6, which is better than Router RT5's 14 (6+8). Table 3 shows the entries that are added to the routing table when external routes are examined: Destination Next Hop Distance __________________________________ N12 RT10 10 N13 RT5 14 N14 RT5 14 N15 RT10 17 Table 3: The portion of Router RT6's routing table listing external destinations. Processing of Type 2 external metrics is simpler. The AS boundary router advertising the smallest external metric is chosen, regardless of the internal distance to the AS boundary router. Suppose in our example both Router RT5 and Router RT7 were advertising Type 2 external routes. Then all traffic destined for Network N12 would be forwarded to Router RT7, since 2 < 8. When several equal-cost Type 2 routes exist, the internal distance to the advertising routers is used to break the tie. Both Type 1 and Type 2 external metrics can be present in the AS at the same time. In that event, Type 1 external metrics always take precedence. This section has assumed that packets destined for external destinations are always routed through the advertising AS boundary router. This is not always desirable. For example, suppose in Figure 2 there is an additional router attached to Network N6, called Router RTX. Suppose further that RTX does not participate in OSPF routing, but does exchange EGP information with the AS boundary router RT7. Then, Router RT7 would end up advertising OSPF external routes for all destinations that should be routed to RTX. An extra hop will sometimes be introduced if packets for these destinations need always be routed first to Router RT7 (the advertising router). To deal with this situation, the OSPF protocol allows an AS Moy [Page 19]
RFC 1583 OSPF Version 2 March 1994 boundary router to specify a "forwarding address" in its external advertisements. In the above example, Router RT7 would specify RTX's IP address as the "forwarding address" for all those destinations whose packets should be routed directly to RTX. The "forwarding address" has one other application. It enables routers in the Autonomous System's interior to function as "route servers". For example, in Figure 2 the router RT6 could become a route server, gaining external routing information through a combination of static configuration and external routing protocols. RT6 would then start advertising itself as an AS boundary router, and would originate a collection of OSPF external advertisements. In each external advertisement, Router RT6 would specify the correct Autonomous System exit point to use for the destination through appropriate setting of the advertisement's "forwarding address" field. 2.3. Equal-cost multipath The above discussion has been simplified by considering only a single route to any destination. In reality, if multiple equal-cost routes to a destination exist, they are all discovered and used. This requires no conceptual changes to the algorithm, and its discussion is postponed until we consider the tree-building process in more detail. With equal cost multipath, a router potentially has several available next hops towards any given destination. 2.4. TOS-based routing OSPF can calculate a separate set of routes for each IP Type of Service. This means that, for any destination, there can potentially be multiple routing table entries, one for each IP TOS. The IP TOS values are represented in OSPF exactly as they appear in the IP packet header. Up to this point, all examples shown have assumed that routes do not vary on TOS. In order to differentiate routes based on TOS, separate interface costs can be configured for each TOS. For example, in Figure 2 there could be multiple costs (one for each TOS) listed for each interface. A cost for TOS 0 must always be specified. When interface costs vary based on TOS, a separate shortest path Moy [Page 20]
RFC 1583 OSPF Version 2 March 1994 tree is calculated for each TOS (see Section 2.1). In addition, external costs can vary based on TOS. For example, in Figure 2 Router RT7 could advertise a separate type 1 external metric for each TOS. Then, when calculating the TOS X distance to Network N15 the cost of the shortest TOS X path to RT7 would be added to the TOS X cost advertised by RT7 for Network N15 (see Section 2.2). All OSPF implementations must be capable of calculating routes based on TOS. However, OSPF routers can be configured to route all packets on the TOS 0 path (see Appendix C), eliminating the need to calculate non-zero TOS paths. This can be used to conserve routing table space and processing resources in the router. These TOS-0-only routers can be mixed with routers that do route based on TOS. TOS-0-only routers will be avoided as much as possible when forwarding traffic requesting a non-zero TOS. It may be the case that no path exists for some non-zero TOS, even if the router is calculating non-zero TOS paths. In that case, packets requesting that non-zero TOS are routed along the TOS 0 path (see Section 11.1). 3. Splitting the AS into Areas OSPF allows collections of contiguous networks and hosts to be grouped together. Such a group, together with the routers having interfaces to any one of the included networks, is called an area. Each area runs a separate copy of the basic link-state routing algorithm. This means that each area has its own topological database and corresponding graph, as explained in the previous section. The topology of an area is invisible from the outside of the area. Conversely, routers internal to a given area know nothing of the detailed topology external to the area. This isolation of knowledge enables the protocol to effect a marked reduction in routing traffic as compared to treating the entire Autonomous System as a single link-state domain. With the introduction of areas, it is no longer true that all routers in the AS have an identical topological database. A router actually has a separate topological database for each area it is connected to. (Routers connected to multiple areas are called area border routers). Two routers belonging to the same area have, for that area, identical area topological databases. Moy [Page 21]
RFC 1583 OSPF Version 2 March 1994 Routing in the Autonomous System takes place on two levels, depending on whether the source and destination of a packet reside in the same area (intra-area routing is used) or different areas (inter-area routing is used). In intra-area routing, the packet is routed solely on information obtained within the area; no routing information obtained from outside the area can be used. This protects intra-area routing from the injection of bad routing information. We discuss inter-area routing in Section 3.2. 3.1. The backbone of the Autonomous System The backbone consists of those networks not contained in any area, their attached routers, and those routers that belong to multiple areas. The backbone must be contiguous. It is possible to define areas in such a way that the backbone is no longer contiguous. In this case the system administrator must restore backbone connectivity by configuring virtual links. Virtual links can be configured between any two backbone routers that have an interface to a common non-backbone area. Virtual links belong to the backbone. The protocol treats two routers joined by a virtual link as if they were connected by an unnumbered point-to-point network. On the graph of the backbone, two such routers are joined by arcs whose costs are the intra-area distances between the two routers. The routing protocol traffic that flows along the virtual link uses intra- area routing only. The backbone is responsible for distributing routing information between areas. The backbone itself has all of the properties of an area. The topology of the backbone is invisible to each of the areas, while the backbone itself knows nothing of the topology of the areas. 3.2. Inter-area routing When routing a packet between two areas the backbone is used. The path that the packet will travel can be broken up into three contiguous pieces: an intra-area path from the source to an area border router, a backbone path between the source and destination areas, and then another intra-area path to the destination. The algorithm finds the set of such paths that have the smallest cost. Looking at this another way, inter-area routing can be pictured Moy [Page 22]
RFC 1583 OSPF Version 2 March 1994 as forcing a star configuration on the Autonomous System, with the backbone as hub and each of the areas as spokes. The topology of the backbone dictates the backbone paths used between areas. The topology of the backbone can be enhanced by adding virtual links. This gives the system administrator some control over the routes taken by inter-area traffic. The correct area border router to use as the packet exits the source area is chosen in exactly the same way routers advertising external routes are chosen. Each area border router in an area summarizes for the area its cost to all networks external to the area. After the SPF tree is calculated for the area, routes to all other networks are calculated by examining the summaries of the area border routers. 3.3. Classification of routers Before the introduction of areas, the only OSPF routers having a specialized function were those advertising external routing information, such as Router RT5 in Figure 2. When the AS is split into OSPF areas, the routers are further divided according to function into the following four overlapping categories: Internal routers A router with all directly connected networks belonging to the same area. Routers with only backbone interfaces also belong to this category. These routers run a single copy of the basic routing algorithm. Area border routers A router that attaches to multiple areas. Area border routers run multiple copies of the basic algorithm, one copy for each attached area and an additional copy for the backbone. Area border routers condense the topological information of their attached areas for distribution to the backbone. The backbone in turn distributes the information to the other areas. Backbone routers A router that has an interface to the backbone. This includes all routers that interface to more than one area (i.e., area border routers). However, backbone routers do not have to be area border routers. Routers with all interfaces connected to the backbone are considered to be internal routers. Moy [Page 23]
RFC 1583 OSPF Version 2 March 1994 AS boundary routers A router that exchanges routing information with routers belonging to other Autonomous Systems. Such a router has AS external routes that are advertised throughout the Autonomous System. The path to each AS boundary router is known by every router in the AS. This classification is completely independent of the previous classifications: AS boundary routers may be internal or area border routers, and may or may not participate in the backbone. 3.4. A sample area configuration Figure 6 shows a sample area configuration. The first area consists of networks N1-N4, along with their attached routers RT1-RT4. The second area consists of networks N6-N8, along with their attached routers RT7, RT8, RT10 and RT11. The third area consists of networks N9-N11 and Host H1, along with their attached routers RT9, RT11 and RT12. The third area has been configured so that networks N9-N11 and Host H1 will all be grouped into a single route, when advertised external to the area (see Section 3.5 for more details). In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are area border routers. Finally, as before, Routers RT5 and RT7 are AS boundary routers. Figure 7 shows the resulting topological database for the Area 1. The figure completely describes that area's intra-area routing. It also shows the complete view of the internet for the two internal routers RT1 and RT2. It is the job of the area border routers, RT3 and RT4, to advertise into Area 1 the distances to all destinations external to the area. These are indicated in Figure 7 by the dashed stub routes. Also, RT3 and RT4 must advertise into Area 1 the location of the AS boundary routers RT5 and RT7. Finally, external advertisements from RT5 and RT7 are flooded throughout the entire AS, and in particular throughout Area 1. These advertisements are included in Area 1's database, and yield routes to Networks N12-N15. Routers RT3 and RT4 must also summarize Area 1's topology for distribution to the backbone. Their backbone advertisements are shown in Table 4. These summaries show which networks are contained in Area 1 (i.e., Networks N1-N4), and the distance to these networks from the routers RT3 and RT4 respectively. Moy [Page 24]
RFC 1583 OSPF Version 2 March 1994 ........................... . + . . | 3+---+ . N12 N14 . N1|--|RT1|\ 1 . \ N13 / . | +---+ \ . 8\ |8/8 . + \ ____ . \|/ . / \ 1+---+8 8+---+6 . * N3 *---|RT4|------|RT5|--------+ . \____/ +---+ +---+ | . + / \ . |7 | . | 3+---+ / \ . | | . N2|--|RT2|/1 1\ . |6 | . | +---+ +---+8 6+---+ | . + |RT3|------|RT6| | . +---+ +---+ | . 2/ . Ia|7 | . / . | | . +---------+ . | | .Area 1 N4 . | | ........................... | | .......................... | | . N11 . | | . +---------+ . | | . | . | | N12 . |3 . Ib|5 |6 2/ . +---+ . +----+ +---+/ . |RT9| . .........|RT10|.....|RT7|---N15. . +---+ . . +----+ +---+ 9 . . |1 . . + /3 1\ |1 . . _|__ . . | / \ __|_ . . / \ 1+----+2 |/ \ / \ . . * N9 *------|RT11|----| * N6 * . . \____/ +----+ | \____/ . . | . . | | . . |1 . . + |1 . . +--+ 10+----+ . . N8 +---+ . . |H1|-----|RT12| . . |RT8| . . +--+SLIP +----+ . . +---+ . . |2 . . |4 . . | . . | . . +---------+ . . +--------+ . . N10 . . N7 . . . .Area 2 . .Area 3 . ................................ .......................... Figure 6: A sample OSPF area configuration Moy [Page 25]
RFC 1583 OSPF Version 2 March 1994 Network RT3 adv. RT4 adv. _____________________________ N1 4 4 N2 4 4 N3 1 1 N4 2 3 Table 4: Networks advertised to the backbone by Routers RT3 and RT4. The topological database for the backbone is shown in Figure 8. The set of routers pictured are the backbone routers. Router RT11 is a backbone router because it belongs to two areas. In order to make the backbone connected, a virtual link has been configured between Routers R10 and R11. Again, Routers RT3, RT4, RT7, RT10 and RT11 are area border routers. As Routers RT3 and RT4 did above, they have condensed the routing information of their attached areas for distribution via the backbone; these are the dashed stubs that appear in Figure 8. Remember that the third area has been configured to condense Networks N9-N11 and Host H1 into a single route. This yields a single dashed line for networks N9-N11 and Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary routers; their externally derived information also appears on the graph in Figure 8 as stubs. The backbone enables the exchange of summary information between area border routers. Every area border router hears the area summaries from all other area border routers. It then forms a picture of the distance to all networks outside of its area by examining the collected advertisements, and adding in the backbone distance to each advertising router. Again using Routers RT3 and RT4 as an example, the procedure goes as follows: They first calculate the SPF tree for the backbone. This gives the distances to all other area border routers. Also noted are the distances to networks (Ia and Ib) and AS boundary routers (RT5 and RT7) that belong to the backbone. This calculation is shown in Table 5. Next, by looking at the area summaries from these area border routers, RT3 and RT4 can determine the distance to all networks outside their area. These distances are then advertised internally to the area by RT3 and RT4. The advertisements that Router RT3 and RT4 will make into Area 1 are shown in Table 6. Moy [Page 26]
RFC 1583 OSPF Version 2 March 1994 **FROM** |RT|RT|RT|RT|RT|RT| |1 |2 |3 |4 |5 |7 |N3| ----- ------------------- RT1| | | | | | |0 | RT2| | | | | | |0 | RT3| | | | | | |0 | * RT4| | | | | | |0 | * RT5| | |14|8 | | | | T RT7| | |20|14| | | | O N1|3 | | | | | | | * N2| |3 | | | | | | * N3|1 |1 |1 |1 | | | | N4| | |2 | | | | | Ia,Ib| | |15|22| | | | N6| | |16|15| | | | N7| | |20|19| | | | N8| | |18|18| | | | N9-N11,H1| | |19|16| | | | N12| | | | |8 |2 | | N13| | | | |8 | | | N14| | | | |8 | | | N15| | | | | |9 | | Figure 7: Area 1's Database. Networks and routers are represented by vertices. An edge of cost X connects Vertex A to Vertex B iff the intersection of Column A and Row B is marked with an X. Moy [Page 27]
RFC 1583 OSPF Version 2 March 1994 **FROM** |RT|RT|RT|RT|RT|RT|RT |3 |4 |5 |6 |7 |10|11| ------------------------ RT3| | | |6 | | | | RT4| | |8 | | | | | RT5| |8 | |6 |6 | | | RT6|8 | |7 | | |5 | | RT7| | |6 | | | | | * RT10| | | |7 | | |2 | * RT11| | | | | |3 | | T N1|4 |4 | | | | | | O N2|4 |4 | | | | | | * N3|1 |1 | | | | | | * N4|2 |3 | | | | | | Ia| | | | | |5 | | Ib| | | |7 | | | | N6| | | | |1 |1 |3 | N7| | | | |5 |5 |7 | N8| | | | |4 |3 |2 | N9-N11,H1| | | | | | |1 | N12| | |8 | |2 | | | N13| | |8 | | | | | N14| | |8 | | | | | N15| | | | |9 | | | Figure 8: The backbone's database. Networks and routers are represented by vertices. An edge of cost X connects Vertex A to Vertex B iff the intersection of Column A and Row B is marked with an X. Moy [Page 28]
RFC 1583 OSPF Version 2 March 1994 Area border dist from dist from router RT3 RT4 ______________________________________ to RT3 * 21 to RT4 22 * to RT7 20 14 to RT10 15 22 to RT11 18 25 ______________________________________ to Ia 20 27 to Ib 15 22 ______________________________________ to RT5 14 8 to RT7 20 14 Table 5: Backbone distances calculated by Routers RT3 and RT4. Note that Table 6 assumes that an area range has been configured for the backbone which groups Ia and Ib into a single advertisement. The information imported into Area 1 by Routers RT3 and RT4 enables an internal router, such as RT1, to choose an area border router intelligently. Router RT1 would use RT4 for traffic to Network N6, RT3 for traffic to Network N10, and would load share between the two for traffic to Network N8. Destination RT3 adv. RT4 adv. _________________________________ Ia,Ib 15 22 N6 16 15 N7 20 19 N8 18 18 N9-N11,H1 19 26 _________________________________ RT5 14 8 RT7 20 14 Table 6: Destinations advertised into Area 1 by Routers RT3 and RT4. Moy [Page 29]
RFC 1583 OSPF Version 2 March 1994 Router RT1 can also determine in this manner the shortest path to the AS boundary routers RT5 and RT7. Then, by looking at RT5 and RT7's external advertisements, Router RT1 can decide between RT5 or RT7 when sending to a destination in another Autonomous System (one of the networks N12-N15). Note that a failure of the line between Routers RT6 and RT10 will cause the backbone to become disconnected. Configuring a virtual link between Routers RT7 and RT10 will give the backbone more connectivity and more resistance to such failures. Also, a virtual link between RT7 and RT10 would allow a much shorter path between the third area (containing N9) and the router RT7, which is advertising a good route to external network N12. 3.5. IP subnetting support OSPF attaches an IP address mask to each advertised route. The mask indicates the range of addresses being described by the particular route. For example, a summary advertisement for the destination 128.185.0.0 with a mask of 0xffff0000 actually is describing a single route to the collection of destinations 128.185.0.0 - 128.185.255.255. Similarly, host routes are always advertised with a mask of 0xffffffff, indicating the presence of only a single destination. Including the mask with each advertised destination enables the implementation of what is commonly referred to as variable- length subnetting. This means that a single IP class A, B, or C network number can be broken up into many subnets of various sizes. For example, the network 128.185.0.0 could be broken up into 62 variable-sized subnets: 15 subnets of size 4K, 15 subnets of size 256, and 32 subnets of size 8. Table 7 shows some of the resulting network addresses together with their masks: Network address IP address mask Subnet size _______________________________________________ 128.185.16.0 0xfffff000 4K 128.185.1.0 0xffffff00 256 128.185.0.8 0xfffffff8 8 Table 7: Some sample subnet sizes. Moy [Page 30]
RFC 1583 OSPF Version 2 March 1994 There are many possible ways of dividing up a class A, B, and C network into variable sized subnets. The precise procedure for doing so is beyond the scope of this specification. This specification however establishes the following guideline: When an IP packet is forwarded, it is always forwarded to the network that is the best match for the packet's destination. Here best match is synonymous with the longest or most specific match. For example, the default route with destination of 0.0.0.0 and mask 0x00000000 is always a match for every IP destination. Yet it is always less specific than any other match. Subnet masks must be assigned so that the best match for any IP destination is unambiguous. The OSPF area concept is modelled after an IP subnetted network. OSPF areas have been loosely defined to be a collection of networks. In actuality, an OSPF area is specified to be a list of address ranges (see Section C.2 for more details). Each address range is defined as an [address,mask] pair. Many separate networks may then be contained in a single address range, just as a subnetted network is composed of many separate subnets. Area border routers then summarize the area contents (for distribution to the backbone) by advertising a single route for each address range. The cost of the route is the minimum cost to any of the networks falling in the specified range. For example, an IP subnetted network can be configured as a single OSPF area. In that case, the area would be defined as a single address range: a class A, B, or C network number along with its natural IP mask. Inside the area, any number of variable sized subnets could be defined. External to the area, a single route for the entire subnetted network would be distributed, hiding even the fact that the network is subnetted at all. The cost of this route is the minimum of the set of costs to the component subnets. 3.6. Supporting stub areas In some Autonomous Systems, the majority of the topological database may consist of AS external advertisements. An OSPF AS external advertisement is usually flooded throughout the entire AS. However, OSPF allows certain areas to be configured as "stub areas". AS external advertisements are not flooded into/throughout stub areas; routing to AS external destinations in these areas is based on a (per-area) default only. This reduces the topological database size, and therefore the memory requirements, for a stub area's internal routers. Moy [Page 31]
RFC 1583 OSPF Version 2 March 1994 In order to take advantage of the OSPF stub area support, default routing must be used in the stub area. This is accomplished as follows. One or more of the stub area's area border routers must advertise a default route into the stub area via summary link advertisements. These summary defaults are flooded throughout the stub area, but no further. (For this reason these defaults pertain only to the particular stub area). These summary default routes will match any destination that is not explicitly reachable by an intra-area or inter-area path (i.e., AS external destinations). An area can be configured as stub when there is a single exit point from the area, or when the choice of exit point need not be made on a per-external-destination basis. For example, Area 3 in Figure 6 could be configured as a stub area, because all external traffic must travel though its single area border router RT11. If Area 3 were configured as a stub, Router RT11 would advertise a default route for distribution inside Area 3 (in a summary link advertisement), instead of flooding the AS external advertisements for Networks N12-N15 into/throughout the area. The OSPF protocol ensures that all routers belonging to an area agree on whether the area has been configured as a stub. This guarantees that no confusion will arise in the flooding of AS external advertisements. There are a couple of restrictions on the use of stub areas. Virtual links cannot be configured through stub areas. In addition, AS boundary routers cannot be placed internal to stub areas. 3.7. Partitions of areas OSPF does not actively attempt to repair area partitions. When an area becomes partitioned, each component simply becomes a separate area. The backbone then performs routing between the new areas. Some destinations reachable via intra-area routing before the partition will now require inter-area routing. In the previous section, an area was described as a list of address ranges. Any particular address range must still be completely contained in a single component of the area partition. This has to do with the way the area contents are summarized to the backbone. Also, the backbone itself must not partition. If it does, parts of the Autonomous System will become unreachable. Backbone partitions can be repaired by Moy [Page 32]
RFC 1583 OSPF Version 2 March 1994 configuring virtual links (see Section 15). Another way to think about area partitions is to look at the Autonomous System graph that was introduced in Section 2. Area IDs can be viewed as colors for the graph's edges.[1] Each edge of the graph connects to a network, or is itself a point-to- point network. In either case, the edge is colored with the network's Area ID. A group of edges, all having the same color, and interconnected by vertices, represents an area. If the topology of the Autonomous System is intact, the graph will have several regions of color, each color being a distinct Area ID. When the AS topology changes, one of the areas may become partitioned. The graph of the AS will then have multiple regions of the same color (Area ID). The routing in the Autonomous System will continue to function as long as these regions of same color are connected by the single backbone region. Moy [Page 33]
RFC 1583 OSPF Version 2 March 1994 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. Moy [Page 34]
RFC 1583 OSPF Version 2 March 1994 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 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. An 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 into 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 Moy [Page 35]
RFC 1583 OSPF Version 2 March 1994 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]). 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. As mentioned above, OSPF routing packets (with the exception of Hellos) are sent only over adjacencies. Note that this means that all OSPF 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 Moy [Page 36]
RFC 1583 OSPF Version 2 March 1994 LS Advertisement Advertisement description type name _________________________________________________________ 1 Router links Originated by all routers. advertisements This 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 advertisements networks by the Designated Router. This advertisement contains the list of routers connected to the network. Flooded throughout a single area only. _________________________________________________________ 3,4 Summary link Originated by area border advertisements routers, and flooded through- out the advertisement's associated area. Each summary link advertisement describes a route to a destination out- side 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 link Originated by AS boundary advertisements routers, and flooded through- out the AS. Each AS external link advertisement describes a route to a destination in another Autonomous System. Default routes for the AS can also be described by AS external link advertisements. Table 9: OSPF link state advertisements. Moy [Page 37]
RFC 1583 OSPF Version 2 March 1994 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 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 take the form of IP multicast datagrams. Support for receiving and sending IP multicast datagrams, along with the appropriate lower-level protocol support, is required. The IP multicast datagrams used by OSPF never travel more than one hop. For this reason, the ability to forward IP multicast datagrams is not required. For information on IP multicast, see [RFC 1112]. Variable-length subnet support The router's IP protocol support must include the ability to divide a single IP class A, B, or C network number into many subnets of various sizes. This is commonly called variable-length subnetting; see Section 3.5 for details. IP supernetting support The router's IP protocol support must include the ability to aggregate contiguous collections of IP class A, B, and C networks into larger quantities called supernets. Supernetting has been proposed as one way to improve the Moy [Page 38]
RFC 1583 OSPF Version 2 March 1994 scaling of IP routing in the worldwide Internet. For more information on IP supernetting, see [RFC 1519]. 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 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 an X.25 PDN a dead neighboring 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 collection of 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. 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 Moy [Page 39]
RFC 1583 OSPF Version 2 March 1994 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 Packet 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 ExternalRoutingCapability (see below). Other capabilities can be negotiated during the Database Exchange process. This is accomplished by specifying the optional capabilities in Database Description packets. A capability mismatch with a neighbor in 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. ExternalRoutingCapability 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-zero TOS paths. Moy [Page 40]
RFC 1583 OSPF Version 2 March 1994
RFC 1583 OSPF Version 2 March 1994 Separate costs may be advertised for each IP Type of Service. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. Note that the cost for TOS 0 must be included, and is always listed first. If the T-bit is reset in the advertisement's Option field, only a route for TOS 0 is described by the advertisement. Otherwise, routes for the other TOS values are also described; if a cost for a certain TOS is not included, its cost defaults to that specified for TOS 0. Network Mask For Type 3 link state advertisements, this indicates the destination network's IP address mask. For example, when advertising the location of a class A network the value 0xff000000 would be used. This field is not meaningful and must be zero for Type 4 link state advertisements. For each specified Type of Service, the following fields are defined. The number of TOS routes included can be calculated from the link state advertisement header's length field. Values for TOS 0 must be specified; they are listed first. Other values must be listed in order of increasing TOS encoding. For example, the cost for TOS 16 must always follow the cost for TOS 8 when both are specified. TOS The Type of Service that the following cost concerns. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. metric The cost of this route. Expressed in the same units as the interface costs in the router links advertisements. Moy [Page 193]
RFC 1583 OSPF Version 2 March 1994 A.4.5 AS external link advertisements AS external link advertisements are the Type 5 link state advertisements. These advertisements are originated by AS boundary routers. A separate advertisement is made for each destination (known to the router) which is external to the AS. For details concerning the construction of AS external link advertisements, see Section 12.4.3. AS external link advertisements usually describe a particular external destination. For these advertisements the Link State ID field specifies an IP network number (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix F for details). AS external link advertisements are also used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the Link State ID is always set to DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Route Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Separate costs may be advertised for each IP Type of Service. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. Note that the cost for TOS 0 must be included, and is Moy [Page 194]
RFC 1583 OSPF Version 2 March 1994 always listed first. If the T-bit is reset in the advertisement's Option field, only a route for TOS 0 is described by the advertisement. Otherwise, routes for the other TOS values are also described; if a cost for a certain TOS is not included, its cost defaults to that specified for TOS 0. Network Mask The IP address mask for the advertised destination. For example, when advertising a class A network the mask 0xff000000 would be used. For each specified Type of Service, the following fields are defined. The number of TOS routes included can be calculated from the link state advertisement header's length field. Values for TOS 0 must be specified; they are listed first. Other values must be listed in order of increasing TOS encoding. For example, the cost for TOS 16 must always follow the cost for TOS 8 when both are specified. bit E The type of external metric. If bit E is set, the metric specified is a Type 2 external metric. This means the metric is considered larger than any link state path. If bit E is zero, the specified metric is a Type 1 external metric. This means that is is comparable directly (without translation) to the link state metric. Forwarding address Data traffic for the advertised destination will be forwarded to this address. If the Forwarding address is set to 0.0.0.0, data traffic will be forwarded instead to the advertisement's originator (i.e., the responsible AS boundary router). TOS The Type of Service that the following cost concerns. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. metric The cost of this route. Interpretation depends on the external type indication (bit E above). External Route Tag A 32-bit field attached to each external route. This is not used by the OSPF protocol itself. It may be used to communicate information between AS boundary routers; the precise nature of such information is outside the scope of this specification. Moy [Page 195]
RFC 1583 OSPF Version 2 March 1994 B. Architectural Constants Several OSPF protocol parameters have fixed architectural values. These parameters have been referred to in the text by names such as LSRefreshTime. The same naming convention is used for the configurable protocol parameters. They are defined in Appendix C. The name of each architectural constant follows, together with its value and a short description of its function. LSRefreshTime The maximum time between distinct originations of any particular link state advertisement. When the LS age field of one of the router's self-originated advertisements reaches the value LSRefreshTime, a new instance of the link state advertisement is originated, even though the contents of the advertisement (apart from the link state header) will be the same. The value of LSRefreshTime is set to 30 minutes. MinLSInterval The minimum time between distinct originations of any particular link state advertisement. The value of MinLSInterval is set to 5 seconds. MaxAge The maximum age that a link state advertisement can attain. When an advertisement's LS age field reaches MaxAge, it is reflooded in an attempt to flush the advertisement from the routing domain (See Section 14). Advertisements of age MaxAge are not used in the routing table calculation. The value of MaxAge must be greater than LSRefreshTime. The value of MaxAge is set to 1 hour. CheckAge When the age of a link state advertisement (that is contained in the link state database) hits a multiple of CheckAge, the advertisement's checksum is verified. An incorrect checksum at this time indicates a serious error. The value of CheckAge is set to 5 minutes. MaxAgeDiff The maximum time dispersion that can occur, as a link state advertisement is flooded throughout the AS. Most of this time is accounted for by the link state advertisements sitting on router output queues (and therefore not aging) during the flooding process. The value of MaxAgeDiff is set to 15 minutes. Moy [Page 196]
RFC 1583 OSPF Version 2 March 1994 LSInfinity The metric value indicating that the destination described by a link state advertisement is unreachable. Used in summary link advertisements and AS external link advertisements as an alternative to premature aging (see Section 14.1). It is defined to be the 24-bit binary value of all ones: 0xffffff. DefaultDestination The Destination ID that indicates the default route. This route is used when no other matching routing table entry can be found. The default destination can only be advertised in AS external link advertisements and in stub areas' type 3 summary link advertisements. Its value is the IP address 0.0.0.0. Moy [Page 197]
RFC 1583 OSPF Version 2 March 1994 C. Configurable Constants The OSPF protocol has quite a few configurable parameters. These parameters are listed below. They are grouped into general functional categories (area parameters, interface parameters, etc.). Sample values are given for some of the parameters. Some parameter settings need to be consistent among groups of routers. For example, all routers in an area must agree on that area's parameters, and all routers attached to a network must agree on that network's IP network number and mask. Some parameters may be determined by router algorithms outside of this specification (e.g., the address of a host connected to the router via a SLIP line). From OSPF's point of view, these items are still configurable. C.1 Global parameters In general, a separate copy of the OSPF protocol is run for each area. Because of this, most configuration parameters are defined on a per-area basis. The few global configuration parameters are listed below. Router ID This is a 32-bit number that uniquely identifies the router in the Autonomous System. One algorithm for Router ID assignment is to choose the largest or smallest IP address assigned to the router. If a router's OSPF Router ID is changed, the router's OSPF software should be restarted before the new Router ID takes effect. Before restarting in order to change its Router ID, the router should flush its self-originated link state advertisements from the routing domain (see Section 14.1), or they will persist for up to MaxAge minutes. TOS capability This item indicates whether the router will calculate separate routes based on TOS. For more information, see Sections 4.5 and 16.9. C.2 Area parameters All routers belonging to an area must agree on that area's configuration. Disagreements between two routers will lead to an inability for adjacencies to form between them, with a resulting hindrance to the flow of routing protocol and data Moy [Page 198]
RFC 1583 OSPF Version 2 March 1994 traffic. The following items must be configured for an area: Area ID This is a 32-bit number that identifies the area. The Area ID of 0.0.0.0 is reserved for the backbone. If the area represents a subnetted network, the IP network number of the subnetted network may be used for the Area ID. List of address ranges An OSPF area is defined as a list of address ranges. Each address range consists of the following items: [IP address, mask] Describes the collection of IP addresses contained in the address range. Networks and hosts are assigned to an area depending on whether their addresses fall into one of the area's defining address ranges. Routers are viewed as belonging to multiple areas, depending on their attached networks' area membership. Status Set to either Advertise or DoNotAdvertise. Routing information is condensed at area boundaries. External to the area, at most a single route is advertised (via a summary link advertisement) for each address range. The route is advertised if and only if the address range's Status is set to Advertise. Unadvertised ranges allow the existence of certain networks to be intentionally hidden from other areas. Status is set to Advertise by default. As an example, suppose an IP subnetted network is to be its own OSPF area. The area would be configured as a single address range, whose IP address is the address of the subnetted network, and whose mask is the natural class A, B, or C address mask. A single route would be advertised external to the area, describing the entire subnetted network. AuType Each area can be configured for a separate type of authentication. See Appendix D for a discussion of the defined authentication types. ExternalRoutingCapability Whether AS external advertisements will be flooded into/throughout the area. If AS external advertisements are Moy [Page 199]
RFC 1583 OSPF Version 2 March 1994 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. C.3 Router interface parameters Some of the configurable router interface parameters (such as IP interface address and subnet mask) actually imply properties of the attached networks, and therefore must be consistent across all the routers attached to that network. The parameters that must be configured for a router interface are: IP interface address The IP protocol address for this interface. This uniquely identifies the router over the entire internet. An IP address is not required on serial lines. Such a serial line is called "unnumbered". IP interface mask Also referred to as the subnet mask, this indicates the portion of the IP interface address that identifies the attached network. Masking the IP interface address with the IP interface mask yields the IP network number of the attached network. On point-to-point networks and virtual links, the IP interface mask is not defined. On these networks, the link itself is not assigned an IP network number, and so the addresses of each side of the link are assigned independently, if they are assigned at all. Interface output cost(s) The cost of sending a packet on the interface, expressed in the link state metric. This is advertised as the link cost for this interface in the router's router links advertisement. There may be a separate cost for each IP Type of Service. The interface output cost(s) must always be greater than 0. Moy [Page 200]
RFC 1583 OSPF Version 2 March 1994 RxmtInterval The number of seconds between link state advertisement retransmissions, for adjacencies belonging to this interface. Also used when retransmitting Database Description and Link State Request Packets. This should be well over the expected round-trip delay between any two routers on the attached network. The setting of this value should be conservative or needless retransmissions will result. It will need to be larger on low speed serial lines and virtual links. Sample value for a local area network: 5 seconds. InfTransDelay The estimated number of seconds it takes to transmit a Link State Update Packet over this interface. Link state advertisements contained in the update packet must have their age incremented by this amount before transmission. This value should take into account the transmission and propagation delays of the interface. It must be greater than 0. Sample value for a local area network: 1 second. Router Priority An 8-bit unsigned integer. When two routers attached to a network both attempt to become Designated Router, the one with the highest Router Priority takes precedence. If there is still a tie, the router with the highest Router ID takes precedence. A router whose Router Priority is set to 0 is ineligible to become Designated Router on the attached network. Router Priority is only configured for interfaces to multi-access networks. HelloInterval The length of time, in seconds, between the Hello Packets that the router sends on the interface. This value is advertised in the router's Hello Packets. It must be the same for all routers attached to a common network. The smaller the HelloInterval, the faster topological changes will be detected, but more OSPF routing protocol traffic will ensue. Sample value for a X.25 PDN network: 30 seconds. Sample value for a local area network: 10 seconds. RouterDeadInterval After ceasing to hear a router's Hello Packets, the number of seconds before its neighbors declare the router down. This is also advertised in the router's Hello Packets in their RouterDeadInterval field. This should be some multiple of the HelloInterval (say 4). This value again must be the same for all routers attached to a common Moy [Page 201]
RFC 1583 OSPF Version 2 March 1994 network. Authentication key This configured data allows the authentication procedure to generate and/or verify the authentication field in the OSPF header. This value again must be the same for all routers attached to a common network. For example, if the AuType indicates simple password, the Authentication key would be a 64-bit password. This key would be inserted directly into the OSPF header when originating routing protocol packets. There could be a separate password for each network. C.4 Virtual link parameters Virtual links are used to restore/increase connectivity of the backbone. Virtual links may be configured between any pair of area border routers having interfaces to a common (non-backbone) area. The virtual link appears as an unnumbered point-to-point link in the graph for the backbone. The virtual link must be configured in both of the area border routers. A virtual link appears in router links advertisements (for the backbone) as if it were a separate router interface to the backbone. As such, it has all of the parameters associated with a router interface (see Section C.3). Although a virtual link acts like an unnumbered point-to-point link, it does have an associated IP interface address. This address is used as the IP source in OSPF protocol packets it sends along the virtual link, and is set dynamically during the routing table build process. Interface output cost is also set dynamically on virtual links to be the cost of the intra-area path between the two routers. The parameter RxmtInterval must be configured, and should be well over the expected round-trip delay between the two routers. This may be hard to estimate for a virtual link; it is better to err on the side of making it too large. Router Priority is not used on virtual links. A virtual link is defined by the following two configurable parameters: the Router ID of the virtual link's other endpoint, and the (non-backbone) area through which the virtual link runs (referred to as the virtual link's Transit area). Virtual links cannot be configured through stub areas. C.5 Non-broadcast, multi-access network parameters OSPF treats a non-broadcast, multi-access network much like it treats a broadcast network. Since there may be many routers attached to the network, a Designated Router is selected for the Moy [Page 202]
RFC 1583 OSPF Version 2 March 1994 network. This Designated Router then originates a networks links advertisement, which lists all routers attached to the non-broadcast network. However, due to the lack of broadcast capabilities, it is necessary to use configuration parameters in the Designated Router selection. These parameters need only be configured in those routers that are themselves eligible to become Designated Router (i.e., those router's whose Router Priority for the network is non-zero): List of all other attached routers The list of all other routers attached to the non-broadcast network. Each router is listed by its IP interface address on the network. Also, for each router listed, that router's eligibility to become Designated Router must be defined. When an interface to a non-broadcast network comes up, the router sends Hello Packets only to those neighbors eligible to become Designated Router, until the identity of the Designated Router is discovered. PollInterval If a neighboring router has become inactive (Hello Packets have not been seen for RouterDeadInterval seconds), it may still be necessary to send Hello Packets to the dead neighbor. These Hello Packets will be sent at the reduced rate PollInterval, which should be much larger than HelloInterval. Sample value for a PDN X.25 network: 2 minutes. C.6 Host route parameters Host routes are advertised in router links advertisements as stub networks with mask 0xffffffff. They indicate either router interfaces to point-to-point networks, looped router interfaces, or IP hosts that are directly connected to the router (e.g., via a SLIP line). For each host directly connected to the router, the following items must be configured: Host IP address The IP address of the host. Cost of link to host The cost of sending a packet to the host, in terms of the link state metric. There may be multiple costs configured, one for each IP TOS. However, since the host probably has Moy [Page 203]
RFC 1583 OSPF Version 2 March 1994 only a single connection to the internet, the actual configured cost(s) in many cases is unimportant (i.e., will have no effect on routing). Moy [Page 204]
RFC 1583 OSPF Version 2 March 1994 D. Authentication All OSPF protocol exchanges are authenticated. The OSPF packet header (see Section A.3.1) includes an authentication type field, and 64-bits of data for use by the appropriate authentication scheme (determined by the type field). The authentication type is configurable on a per-area basis. Additional authentication data is configurable on a per-interface basis. For example, if an area uses a simple password scheme for authentication, a separate password may be configured for each network contained in the area. Authentication types 0 and 1 are defined by this specification. All other authentication types are reserved for definition by the IANA (iana@ISI.EDU). The current list of authentication types is described below in Table 20. AuType Description ___________________________________________ 0 No authentication 1 Simple password All others Reserved for assignment by the IANA (iana@ISI.EDU) Table 20: OSPF authentication types. D.1 AuType 0 -- No authentication Use of this authentication type means that routing exchanges in the area are not authenticated. The 64-bit field in the OSPF header can contain anything; it is not examined on packet reception. D.2 AuType 1 -- Simple password Using this authentication type, a 64-bit field is configured on a per-network basis. All packets sent on a particular network must have this configured value in their OSPF header 64-bit authentication field. This essentially serves as a "clear" 64- bit password. Moy [Page 205]
RFC 1583 OSPF Version 2 March 1994 This guards against routers inadvertently joining the area. They must first be configured with their attached networks' passwords before they can participate in the routing domain. Moy [Page 206]
RFC 1583 OSPF Version 2 March 1994 E. Differences from RFC 1247 This section documents the differences between this memo and RFC 1247. These differences include a fix for a problem involving OSPF virtual links, together with minor enhancements and clarifications to the protocol. All differences are backward-compatible. Implementations of this memo and of RFC 1247 will interoperate. E.1 A fix for a problem with OSPF Virtual links In RFC 1247, certain configurations of OSPF virtual links can cause routing loops. The root of the problem is that while there is an information mismatch at the boundary of any virtual link's Transit area, a backbone path can still cross the boundary. RFC 1247 attempted to compensate for this information mismatch by adjusting any backbone path as it enters the transit area (see Section 16.3 in RFC 1247). However, this proved not to be enough. This memo fixes the problem by having all area border routers determine, by looking at summary links, whether better backbone paths can be found through the transit areas. This fix simplifies the OSPF virtual link logic, and consists of the following components: o A new bit has been defined in the router links advertisement, called bit V. Bit V is set in a router's router links advertisement for Area A if and only if the router is an endpoint of an active virtual link that uses Area A as its Transit area (see Sections 12.4.1 and A.4.2). This enables the other routers attached to Area A to discover whether the area supports any virtual links (i.e., is a transit area). This discovery is done during the calculation of Area A's shortest-path tree (see Section 16.1). o To aid in the description of the algorithm, a new parameter has been added to the OSPF area structure: TransitCapability. This parameter indicates whether the area supports any active virtual links. Equivalently, it indicates whether the area can carry traffic that neither originates nor terminates in the area itself. o The calculation in Section 16.3 of RFC 1247 has been replaced. The new calculation, performed by area border routers only, examines the summary links belonging to all attached transit areas to see whether the transit areas can provide better paths than those already found in Sections 16.1 and 16.2. Moy [Page 207]
RFC 1583 OSPF Version 2 March 1994 o The incremental calculations in Section 16.5 have been updated as a result of the new calculations in Section 16.3. E.2 Supporting supernetting and subnet 0 In RFC 1247, an OSPF router cannot originate separate AS external link advertisements (or separate summary link advertisements) for two networks that have the same address but different masks. This situation can arise when subnet 0 of a network has been assigned (a practice that is generally discouraged), or when using supernetting as described in [RFC 1519] (a practice that is generally encouraged to reduce the size of routing tables), or even when in transition from one mask to another on a subnet. Using supernetting as an example, you might want to aggregate the four class C networks 192.9.4.0-192.9.7.0, advertising one route for the aggregation and another for the single class C network 192.9.4.0. The reason behind this limitation is that in RFC 1247, the Link State ID of AS external link advertisements and summary link advertisements is set equal to the described network's IP address. In the above example, RFC 1247 would assign both advertisements the Link State ID of 192.9.4.0, making them in essence the same advertisement. This memo fixes the problem by relaxing the setting of the Link State ID so that any of the "host" bits of the network address can also be set. This allows you to disambiguate advertisements for networks having the same address but different masks. Given an AS external link advertisement (or a summary link advertisement), the described network's address can now be obtained by masking the Link State ID with the network mask carried in the body of the advertisement. Again using the above example, the aggregate can now be advertised using a Link State ID of 192.9.4.0 and the single class C network advertised simultaneously using the Link State ID of 192.9.4.255. Appendix F gives one possible algorithm for setting one or more "host" bits in the Link State ID in order to disambiguate advertisements. It should be noted that this is a local decision. Each router in an OSPF system is free to use its own algorithm, since only those advertisements originated by the router itself are affected. It is believed that this change will be more or less compatible with implementations of RFC 1247. Implementations of RFC 1247 will probably either a) install routing table entries that won't be used or b) do the correct processing as outlined in this memo or c) mark the advertisement as unusable when presented with a Moy [Page 208]
RFC 1583 OSPF Version 2 March 1994 Link State ID that has one or more of the host bits set. However, in the interest of interoperability, implementations of this memo should only set the host bits in Link State IDs when absolutely necessary. The change affects Sections 12.1.4, 12.4.3, 12.4.5, 16.2, 16.3, 16.4, 16.5, 16.6, A.4.4 and A.4.5. E.3 Obsoleting LSInfinity in router links advertisements The metric of LSInfinity can no longer be used in router links advertisements to indicate unusable links. This is being done for several reasons: o It removes any possible confusion in an OSPF area as to just which routers/networks are reachable in the area. For example, the above virtual link fix relies on detecting the existence of virtual links when running the Dijkstra. However, when one-directional links (i.e., cost of LSInfinity in one direction, but not the other) are possible, some routers may detect the existence of virtual links while others may not. This may defeat the fix for the virtual link problem. o It also helps OSPF's Multicast routing extensions (MOSPF), because one-way reachability can lead to places that are reachable via unicast but not multicast, or vice versa. The two prior justifications for using LSInfinity in router links advertisements were 1) it was a way to not support TOS before TOS was optional and 2) it went along with strong TOS interpretations. These justifications are no longer valid. However, LSInfinity will continue to mean "unreachable" in summary link advertisements and AS external link advertisements, as some implementations use this as an alternative to the premature aging procedure specified in Section 14.1. This change has one other side effect. When two routers are connected via a virtual link whose underlying path is non-TOS- capable, they must now revert to being non-TOS-capable routers themselves, instead of the previous behavior of advertising the non-zero TOS costs of the virtual link as LSInfinity. See Section 15 for details. E.4 TOS encoding updated The encoding of TOS in OSPF link state advertisements has been updated to reflect the new TOS value (minimize monetary cost) Moy [Page 209]
RFC 1583 OSPF Version 2 March 1994 defined by [RFC 1349]. The OSPF encoding is defined in Section 12.3, which is identical in content to Section A.5 of [RFC 1349]. E.5 Summarizing routes into transit areas RFC 1247 mandated that routes associated with Area A are never summarized back into Area A. However, this memo further reduces the number of summary links originated by refusing to summarize into Area A those routes having next hops belonging to Area A. This is an optimization over RFC 1247 behavior when virtual links are present. For example, in the area configuration of Figure 6, Router RT11 need only originate a single summary link having the (collapsed) destination N9-N11,H1 into its connected transit area Area 2, since all of its other eligible routes have next hops belonging to Area 2 (and as such only need be advertised by other area border routers; in this case, Routers RT10 and RT7). This is the logical equivalent of a Distance Vector protocol's split horizon logic. This change appears in Section 12.4.3. E.6 Summarizing routes into stub areas RFC 1247 mandated that area border routers attached to stub areas must summarize all inter-area routes into the stub areas. However, while area border routers connected to OSPF stub areas must originate default summary links into the stub area, they need not summarize other routes into the stub area. The amount of summarization done into stub areas can instead be put under configuration control. The network administrator can then make the trade-off between optimal routing and database size. This change appears in Sections 12.4.3 and 12.4.4. E.7 Flushing anomalous network links advertisements Text was added indicating that a network links advertisement whose Link State ID is equal to one of the router's own IP interface addresses should be considered to be self-originated, regardless of the setting of the advertisement's Advertising Router. If the Advertising Router of such an advertisement is not equal to the router's own Router ID, the advertisement should be flushed from the routing domain using the premature aging procedure specified in Section 14.1. This case should be rare, and it indicates that the router's Router ID has changed since originating the advertisement. Moy [Page 210]
RFC 1583 OSPF Version 2 March 1994 Failure to flush these anomalous advertisements could lead to multiple network links advertisements having the same Link State ID. This in turn could cause the Dijkstra calculation in Section 16.1 to fail, since it would be impossible to tell which network links advertisement is valid (i.e., more recent). This change appears in Sections 13.4 and 14.1. E.8 Required Statistics appendix deleted Appendix D of RFC 1247, which specified a list of required statistics for an OSPF implementation, has been deleted. That appendix has been superseded by the two documents: the OSPF Version 2 Management Information Base and the OSPF Version 2 Traps. E.9 Other changes The following small changes were also made to RFC 1247: o When representing unnumbered point-to-point networks in router links advertisements, the corresponding Link Data field should be set to the unnumbered interface's MIB-II [RFC 1213] ifIndex value. o A comment was added to Step 3 of the Dijkstra algorithm in Section 16.1. When removing vertices from the candidate list, and when there is a choice of vertices closest to the root, network vertices must be chosen before router vertices in order to necessarily find all equal-cost paths. o A comment was added to Section 12.4.3 noting that a summary link advertisement cannot express a reachable destination whose path cost equals or exceeds LSInfinity. o A comment was added to Section 15 noting that a virtual link whose underlying path has cost greater than hexadecimal 0xffff (the maximum size of an interface cost in a router links advertisement) should be considered inoperational. o An option was added to the definition of area address ranges, allowing the network administrator to specify that a particular range should not be advertised to other OSPF areas. This enables the existence of certain networks to be hidden from other areas. This change appears in Sections 12.4.3 and C.2. Moy [Page 211]
RFC 1583 OSPF Version 2 March 1994 o A note was added reminding implementors that bit E (the AS boundary router indication) should never be set in a router links advertisement for a stub area, since stub areas cannot contain AS boundary routers. This change appears in Section 12.4.1. Moy [Page 212]
RFC 1583 OSPF Version 2 March 1994 F. An algorithm for assigning Link State IDs In RFC 1247, the Link State ID in AS external link advertisements and summary link advertisements is set to the described network's IP address. This memo relaxes that requirement, allowing one or more of the network's host bits to be set in the Link State ID. This allows the router to originate separate advertisements for networks having the same addresses, yet different masks. Such networks can occur in the presence of supernetting and subnet 0s (see Section E.2 for more information). This appendix gives one possible algorithm for setting the host bits in Link State IDs. The choice of such an algorithm is a local decision. Separate routers are free to use different algorithms, since the only advertisements affected are the ones that the router itself originates. The only requirement on the algorithms used is that the network's IP address should be used as the Link State ID (the RFC 1247 behavior) whenever possible. The algorithm below is stated for AS external link advertisements. This is only for clarity; the exact same algorithm can be used for summary link advertisements. Suppose that the router wishes to originate an AS external link advertisement for a network having address NA and mask NM1. The following steps are then used to determine the advertisement's Link State ID: (1) Determine whether the router is already originating an AS external link advertisement with Link State ID equal to NA (in such an advertisement the router itself will be listed as the advertisement's Advertising Router). If not, set the Link State ID equal to NA (the RFC 1247 behavior) and the algorithm terminates. Otherwise, (2) Obtain the network mask from the body of the already existing AS external link advertisement. Call this mask NM2. There are then two cases: o NM1 is longer (i.e., more specific) than NM2. In this case, set the Link State ID in the new advertisement to be the network [NA,NM1] with all the host bits set (i.e., equal to NA or'ed together with all the bits that are not set in NM1, which is network [NA,NM1]'s broadcast address). o NM2 is longer than NM1. In this case, change the existing advertisement (having Link State ID of NA) to reference the new network [NA,NM1] by incrementing the sequence number, changing the mask in the body to NM1 and using the cost for the new network. Then originate a new advertisement for the Moy [Page 213]
RFC 1583 OSPF Version 2 March 1994 old network [NA,NM2], with Link State ID equal to NA or'ed together with the bits that are not set in NM2 (i.e., network [NA,NM2]'s broadcast address). The above algorithm assumes that all masks are contiguous; this ensures that when two networks have the same address, one mask is more specific than the other. The algorithm also assumes that no network exists having an address equal to another network's broadcast address. Given these two assumptions, the above algorithm always produces unique Link State IDs. The above algorithm can also be reworded as follows: When originating an AS external link state advertisement, try to use the network number as the Link State ID. If that produces a conflict, examine the two networks in conflict. One will be a subset of the other. For the less specific network, use the network number as the Link State ID and for the more specific use the network's broadcast address instead (i.e., flip all the "host" bits to 1). If the most specific network was originated first, this will cause you to originate two link state advertisements at once. As an example of the algorithm, consider its operation when the following sequence of events occurs in a single router (Router A). (1) Router A wants to originate an AS external link advertisement for [10.0.0.0,255.255.255.0]: (a) A Link State ID of 10.0.0.0 is used. (2) Router A then wants to originate an AS external link advertisement for [10.0.0.0,255.255.0.0]: (a) The advertisement for [10.0.0,0,255.255.255.0] is reoriginated using a new Link State ID of 10.0.0.255. (b) A Link State ID of 10.0.0.0 is used for [10.0.0.0,255.255.0.0]. (3) Router A then wants to originate an AS external link advertisement for [10.0.0.0,255.0.0.0]: (a) The advertisement for [10.0.0.0,255.255.0.0] is reoriginated using a new Link State ID of 10.0.255.255. (b) A Link State ID of 10.0.0.0 is used for [10.0.0.0,255.0.0.0]. Moy [Page 214]
RFC 1583 OSPF Version 2 March 1994 (c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID of 10.0.0.255. Moy [Page 215]
RFC 1583 OSPF Version 2 March 1994



Back to RFC index

 

Associates:

 



Sponsered-Sites:

Register domain name and transfer | Cheap webhosting service | Domain name registration

 

 

""